วิศวกรรมซอฟต์แวร์ และโมเดลการพัฒนาซอฟต์แวร์ อาจารย์ศรีนวล ฟองมณี

วิศวกรรมซอฟต์แวร์ (Software Engineering) เนื่องจากกระบวนการพัฒนาซอฟต์แวร์มีความซับซ้อนประกอบกับเทคโนโลยีมีการเปลี่ยนแปลงจึงจำเป็นจะต้องมีบุคคลที่ทำหน้าที่เป็นนักวิศวกรรมซอฟต์แวร์เข้ามาควบคุมดูแลการผลิตตั้งแต่การเก็บรวบรวมความต้องการการออกแบบ การนำกระบวนการมาใช้กับซอฟต์แวร์ การตรวจสอบ การติดตามและประเมินผล รวมถึงการประเมินต้นทุน เพื่อให้โครงการซอฟต์แวร์มีมาตรฐานและสามารถวัดผลได้

วิศวกรรมซอฟต์แวร์ (Software Engineering) หมายถึงการประยุกต์ความรู้ทางวิศวกรรมศาสตร์มาใช้ในกระบวนการพัฒนาระบบสารสนเทศหรือซอฟต์แวร์คอมพิวเตอร์ โดยมีการกำหนดขั้นตอนในการปฏิบัติงานที่ชัดเจน เพื่อทำให้สามารถตรวจสอบและควบคุมคุณภาพของงานได้ง่าย ทำหน้าที่ควบคุมดูแลโครงการพัฒนาซอฟต์แวร์หรือโครงการพัฒนาระบบสารสนเทศ ตั้งแต่กิจกรรมแรกจนกระทั่งสิ้นสุดโครงการ เพื่อให้กระบวนการทำงานของโครงการพัฒนาระบบมีมาตรฐานและสามารถวัดผลได้

เป้าหมายหลักของวิศวกรรมซอฟต์แวร์ - ลดการพึ่งพาความสามารถของบุคคลใดบุคคลหนึ่งโดยเฉพาะ - ต้องการเพิ่มผลผลิตที่ดี (Productivity)

กิจกรรมพื้นฐานของกระบวนการทางวิศวกรรมซอฟต์แวร์ 1. ข้อกำหนดซอฟต์แวร์ (Software Specification) เป็นการระบุข้อกำหนดด้วยการกำหนดฟังก์ชั่นหน้าที่ของซอฟต์แวร์ รวมถึงเงื่อนไขข้อบังคับการปฏิบัติงานที่กำหนดขึ้น หรือเรียกว่า วิศวกรรมความต้องการ (Requirements Engineering) ประกอบด้วยกิจกรรมหลัก 4 ส่วน คือ 1) การศึกษาความเป็นไปได้ (Feasibility Study) 2) การวิเคราะห์ความต้องการ (Requirements Analysis) 3) การสรุปเป็นข้อกำหนดลงในเอกสาร (Requirements Specification) 4) การตรวจสอบความต้องการ (Requirements Validation)

กิจกรรมพื้นฐานของกระบวนการทางวิศวกรรมซอฟต์แวร์ 2 การพัฒนาซอฟต์แวร์ (Software Development) คือการพัฒนาหรือสร้างผลิตภัณฑ์ให้ตรงตามข้อกำหนด ด้วยการนำระเบียบวิธีการพัฒนาซอฟต์แวร์ (Methodology) มาใช้กับการพัฒนาซอฟต์แวร์ เพื่อให้กระบวนการพัฒนาซอฟต์แวร์มีมาตรฐาน และตัวผลิตภัณฑ์ซอฟต์แวร์มีคุณภาพ 3 การตรวจสอบความถูกต้องของซอฟต์แวร์ (Software Validation) ซอฟต์แวร์จะต้องได้รับการตรวจสอบความถูกต้อง เพื่อให้แน่ใจว่าซอฟต์แวร์ที่พัฒนาขึ้นนั้น เป็นผลิตภัณฑ์ที่ตรงกับความต้องการของลูกค้าหรือผู้ใช้งาน 4 วิวัฒนาการของซอฟต์แวร์ (Software Evolution) เพื่อรองรับวิวัฒนาการที่สามารถเปลี่ยนแปลงไปตามความต้องการของผู้ใช้ได้อย่างเหมาะสม

คุณสมบัติของซอฟต์แวร์ที่มีคุณภาพ ถูกต้อง (Correctness) ความน่าเชื่อถือ (Reliability) ใช้งานง่าย (User Friendliness) บำรุงรักษาง่าย (Maintainability) การนำกลับมาใช้งานใหม่ได้ (Reusability) มีความคงทน (Robustness) มีประสิทธิภาพ (Efficiency) ความสะดวกในการเคลื่อนย้าย (Portability) มีความปลอดภัย (Security Safety) 1 ถูกต้อง (Correctness) มีการประมวลผลที่ถูกต้องและตรงตามความต้องการของผู้ใช้ 2 ความน่าเชื่อถือ (Reliability) สารสนเทศที่ประมวลผลถูกต้องมีความน่าเชื่อถือและมีความสำคัญต่อการตัดสินใจ 3 ใช้งานง่าย (User Friendliness) เรียนรู้และใช้งานง่าย มีส่วนช่วยเหลือสนับสนุนหรือคำอธิบายที่ครบถ้วน 4 บำรุงรักษาง่าย (Maintainability) เพื่อง่ายต่อการปรับปรุงซอฟต์แวร์ในอนาคตให้เป็นไปตามความต้องการ 5 การนำกลับมาใช้งานใหม่ได้ (Reusability) สามารถนำโปรแกรมมาใช้ใหม่ ช่วยลดต้นทุนและเวลาการพัฒนา 6 มีความคงทน (Robustness) ซอฟต์แวร์สามารถทำงานได้แม้จะมีปัจจัยที่ก่อให้เกิดความผันแปร 7 มีประสิทธิภาพ (Efficiency) ผลของการใช้งานซอฟต์แวร์ ทำให้การทำงานดีขึ้น ค่าใช้จ่ายลดลงและเพิ่มผลผลิต 8 ความสะดวกในการเคลื่อนย้าย (Portability) สามารถเคลื่อนย้ายไปใช้งานบนสภาวะแวดล้อมใหม่ได้โดยง่าย 9 มีความปลอดภัย (Security Safety) ความมั่นคงปลอดภัยในข้อมูลที่ถูกจัดเก็บไว้

สรุป วิศวกรรมซอฟต์แวร์ วิศวกรรมซอฟต์แวร์ คือ ระเบียบแบบแผนทางวิศวกรรมที่นำมาใช้ควบคุม และดำเนินการผลิตซอฟต์แวร์ให้มีประสิทธิภาพ สามารถตรวจสอบข้อผิดพลาดและแก้ไขซอฟต์แวร์ในระหว่างการผลิตซอฟต์แวร์ได้

ระเบียบวิธีการพัฒนาซอฟต์แวร์ (Software Development Methodology) หรือโมเดลการพัฒนาซอฟต์แวร์ คือแบบจำลองที่ใช้สำหรับเป็นตัวชี้นำถึงกิจกรรมหลัก (Key Activities) ในการพัฒนาซอฟต์แวร์ ด้วยการกำหนดรายละเอียดหรือข้อบัญญัติต่างๆ ไว้ในแต่ละกิจกรรม เพื่อให้การพัฒนาซอฟต์แวร์ดำเนินต่อไปให้เกิดปัญหาน้อยที่สุด โดยสามารถนำมาประยุกต์กับการพัฒนาซอฟต์แวร์ตั้งแต่เริ่มต้นจนกระทั่งเสร็จสิ้นกระบวนการ

สาเหตุที่จำเป็นต้องใช้โมเดลการพัฒนาซอฟต์แวร์ เนื่องจาก (1) โมเดลการพัฒนาซอฟต์แวร์ มีการแตกกระบวนการพัฒนาซอฟต์แวร์เป็นระยะ (2) ซอฟต์แวร์ที่พัฒนามีความซับซ้อน (3) การแบ่งกระบวนการพัฒนาเป็นระยะ (Phase) ทำให้ง่ายต่อการบริหารจัดการ (4) แต่ละระยะมีแนวทางต่างๆ ให้เลือกปฏิบัติ

ระเบียบวิธีการพัฒนาซอฟต์แวร์ 1) Built-and-Fix Model 2) Water Fall Model 3) Incremental Model 4) Spiral Model 5) Joint Application Development (JAD) 6) Rapid Application Development (RAD) 7) Unified Process (UP) 8) Agile Methodologies

Built-and-Fix Model เป็นโมเดลการพัฒนาซอฟต์แวร์ที่ว่าด้วยการเขียนโปรแกรม และแก้ไขโปรแกรมไปเรื่อยๆ ด้วยการลองผิดลองถูก จนกระทั่งพอใจหรือคิดว่าผลลัพธ์ที่ได้ตามความต้องการของผู้ใช้ ทำให้สูญเสียเวลาไปกับการดีบั๊กโปรแกรม และการบำรุงรักษาระบบ แต่อย่างไรก็ตาม กระบวนการพัฒนาซอฟต์แวร์ด้วยวิธีนี้ ใช้ได้ดีกับโปรแกรมขนาดเล็กที่ไม่มีความซับซ้อน หรือเหมาะกับงานที่เมื่อเกิดข้อผิดพลาดแล้ว ไม่ส่งผลกระทบต่อระบบมากนัก แต่ไม่เหมาะกับโครงการซอฟต์แวร์ขนาดใหญ่

ขั้นตอนของโมเดล Built-and-Fix Model (1) เขียนโค้ดคำสั่งโปรแกรมบางส่วนที่สามารถแก้ไขปัญหาได้ (2) คอมไพล์ และรันโปรแกรมเพื่อทดสอบ (3) หากพบข้อผิดพลาดในโปรแกรม ก็ดำเนินการแก้ไขปรับปรุง (4) กลับไปทำซ้ำตาม ขั้นตอนที่ 1-4 จนกระทั่งมีความรู้สึกว่าดีเพียงพอแล้ว

Water Fall Model หรือโมเดลน้ำตก ถูกเผยแพร่ใช้งานเมื่อราวปี คศ. 1970 และโมเดลนี้ยังเป็นที่นิยมใช้เพื่อการพัฒนาระบบงานจนถึงปัจจุบัน เนื่องจากเป็นโมเดลที่ง่ายต่อการใช้งาน ประกอบด้วยกิจกรรม - การรวบรวมความต้องการ - การวิเคราะห์ - การออกแบบ - การเขียนโปรแกรม - การทดสอบ - การบำรุงรักษา

Water Fall Model (a) โมเดลน้ำตกแบบดั้งเดิม การวางแผน การวิเคราะห์ระบบ การออกแบบระบบ การพัฒนาระบบ การบำรุงรักษาระบบ การวางแผน การวิเคราะห์ระบบ การออกแบบระบบ การพัฒนาระบบ การบำรุงรักษาระบบ (a) โมเดลน้ำตกแบบดั้งเดิม (b) โมเดลน้ำตกรูปแบบใหม่แบบทวนซ้ำ

Water Fall Model ข้อดีของโมเดลน้ำตกคือได้ระบบสารสนเทศที่ตรงตามความต้องการของผู้ใช้ เนื่องจากมีการสอบถามความต้องการจากผู้ใช้และจัดทำเอกสารข้อตกลงความต้องการ ข้อเสียจะได้ระบบสารสนเทศที่สมบูรณ์ก็ต่อเมื่อสิ้นสุดขั้นตอนสุดท้ายของโมเดล ซึ่งใช้เวลานาน - ข้อดีของโมเดลน้ำตกคือได้ระบบสารสนเทศที่ตรงตามความต้องการของผู้ใช้ เนื่องจากมีการสอบถามความต้องการจากผู้ใช้และจัดทำเอกสารข้อตกลงความต้องการ เพื่อความถูกต้องตรงกันก่อนดำเนินการพัฒนาระบบ ข้อเสียคือใช้เวลาในการดำเนินงานบางกิจกรรม เช่นกิจกรรมการวิเคราะห์และออกแบบระบบค่อนข้างมาก เพราะต้องออกแบบระบบให้เสร็จสิ้นก่อน จึงทำการพัฒนาโปรแกรม - ข้อเสียดังนั้นจะได้ระบบสารสนเทศที่สมบูรณ์ก็ต่อเมื่อสิ้นสุดขั้นตอนสุดท้ายของโมเดล ซึ่งใช้เวลานาน และหากระบบสารสนเทศที่ได้มีคุณสมบัติไม่ตรงตามความต้องการของผู้ใช้ จะต้องแก้ไขปรับปรุง ทำให้เสียเวลาเพิ่มขึ้นและยังสิ้นเปลืองค่าใช้จ่าย เพราะต้องกลับไปกิจกรรมการวิเคราะห์และออกแบบระบบใหม่อีกรอบ

Incremental Model - หรือโมเดลแบบก้าวหน้า เป็นโมเดลที่วิวัฒนาการมาจาก Water Fall Model - หลักการของ Incremental Model คือ การแบ่งระบบงานออกเป็นระบบย่อยต่างๆ โดยระบบย่อยเรียกว่า Increment ซึ่งเปรียบเสมือนกับโครงการขนาดเล็ก (Mini-Project) โดยจะทำการพัฒนาระบบงานที่เป็นแกนหลักของระบบก่อน จากนั้นจึงค่อยพัฒนา ต่อเติมในแต่ละ Increment ตามลำดับ - เนื่องจาก Water Fall Model ข้อเสียคือโครงการจะได้รับการพัฒนาก็ต่อเมื่อมีการวิเคราะห์และออกแบบระบบเสร็จเรียบร้อยก่อน ซึ่งอาจต้องใช้เวลามาก โดยเฉพาะกับโครงการพัฒนาซอฟต์แวร์ขนาดใหญ่ซึ่งกระบวนการทดสอบอยู่ในลำดับท้ายๆ ถือว่ามีความเสี่ยงสูงกับโอกาสที่จะต้องย้อนกลับไปเริ่มต้นโครงการใหม่ทั้งหมด หากมีการวางแผนจัดการที่ไม่ดีพอ

ขั้นตอน Incremental Model (1) การศึกษาความเป็นไปได้ของระบบ (2) การวางแผนและการกำหนดความต้องการ (3) ขั้นตอนการออกแบบระบบ (Product Design) โดยแตกระบบเป็นระบบย่อย พัฒนาและตรวจสอบระบบย่อยทีละระบบ ในขั้นตอนนี้จะเกิดความก้าวหน้าของระบบ (Increment) โดยแต่ละรอบของการพัฒนาระบบย่อยประกอบด้วยขั้นตอนการทำงาน 5 ขั้นตอน และมีทวนซ้ำในแต่ละความก้าวหน้าของระบบย่อย ซึ่งขั้นตอนการทำงานของแต่ละรอบประกอบด้วย (3.1)การออกแบบรายละเอียดของระบบย่อย (3.2)เขียนโปรแกรม และทดสอบโปรแกรมหน่วยย่อยต่างๆ (Unit Testing) (3.3)นำโปรแกรมย่อยต่างๆ มาประกอบรวมกัน (Integration) และตรวจสอบความถูกต้องของผลิตภัณฑ์ (Product Verification) (3.4)การนำระบบไปใช้งาน จะมีการทดสอบระบบ (System Testing) (3.5)ขั้นตอนการดำเนินงานและบำรุงรักษา (1) การศึกษาความเป็นไปได้ของระบบ จากนั้นจะทำการตรวจสอบความถูกต้องของการศึกษาความเป็นไปได้ เมื่อผลของการศึกษาความเป็นไปได้ของการพัฒนาระบบมีความเหมาะสมในการพัฒนาระบบก็จะดำเนินการขั้นตอนต่อไป (2) การวางแผนและการกำหนดความต้องการ ในขั้นตอนนี้จะทำการวางแผนในการพัฒนาระบบและกำหนดความต้องการต่างๆ ของระบบ จากนั้นจะทำการตรวจสอบความถูกต้องของข้อกำหนดความต้องการ (3) ขั้นตอนการออกแบบระบบ (Product Design) โดยแตกระบบเป็นระบบย่อย พัฒนาและตรวจสอบระบบย่อยทีละระบบ ในขั้นตอนนี้จะเกิดความก้าวหน้าของระบบ (Increment) โดยแต่ละรอบของการพัฒนาระบบย่อยประกอบด้วยขั้นตอนการทำงาน 5 ขั้นตอน และมีทวนซ้ำในแต่ละความก้าวหน้าของระบบย่อย ซึ่งขั้นตอนการทำงานของแต่ละรอบประกอบด้วย (3.1) การออกแบบรายละเอียดของระบบย่อย พร้อมทั้งตรวจสอบความถูกต้อง (3.2) เขียนโปรแกรม และทดสอบโปรแกรมหน่วยย่อยต่างๆ (Unit Testing) (3.3) นำโปรแกรมย่อยต่างๆ มาประกอบรวมกัน (Integration) และตรวจสอบความถูกต้องของผลิตภัณฑ์ (Product Verification) ว่าทำงานได้อย่างถูกต้องหรือไม่ (3.4) การนำระบบไปใช้งาน จะมีการทดสอบระบบ (System Testing) ว่าระบบทำงานได้อย่างถูกต้อง และเป็นไปตามความต้องการของผู้ใช้หรือไม่ (3.5) ขั้นตอนการดำเนินงานและบำรุงรักษา จะเป็นการทบทวนเพื่อตรวจสอบความถูกต้อง ว่าระบบตรงตามความต้องการของผู้ใช้หรือไม่ (Revalidation) จากขั้นตอนการทำงาน ทั้ง 5 ขั้นตอนจะเกิดขึ้นในแต่ละรอบของการพัฒนาระบบย่อย และนำระบบย่อยมารวมกันจนเป็นระบบที่สมบูรณ์พร้อมใช้งานในที่สุด จากการพัฒนาซอฟต์แวร์โดยใช้โมเดลความก้าวหน้านี้ จะได้ซอฟต์แวร์ที่สามารถใช้งานได้ทีละส่วนงานย่อยโดยไม่ต้องรอให้เสร็จสิ้นกระบวนการของการพัฒนาซอฟต์แวร์

Validation และ Verification (V&V) - Verification เป็นการตรวจสอบความถูกต้องในมุมมองของระบบ ว่าเป็นไปตามข้อกำหนดความต้องการ (Requirements Specification) หรือไม่ เพื่อมั่นใจว่าแต่ละฟังก์ชั่นทำงานได้อย่างถูกต้อง - Validation เป็นการตรวจสอบความถูกต้องในมุมมองของผู้ใช้ ว่าระบบหรือผลิตภัณฑ์ที่ผู้สร้างได้พัฒนาขึ้นมานั้น ตรงตามความต้องการของผู้ใช้ (User’s Requirements) หรือไม่ เพื่อให้เกิดความมั่นใจว่าผู้ใช้จะได้ผลิตภัณฑ์ที่ตรงตามความต้องการ V&V เป็นกระบวนการตรวจสอบเพื่อยืนยันถึงความถูกต้องด้านการทำงานของระบบเพื่อมั่นใจว่าระบบที่พัฒนานั้น ตรงตามความต้องการของผู้ใช้ โดยที่ - การทวนซ้ำ (Iteration) คือการทวนซ้ำของงาน - การเพิ่มพูนความก้าวหน้า (Incremental) คือการแบ่งระบบงานออกเป็นระบบย่อย

Spiral Model มีหลักการทำงานแบบวนเป็นรอบคล้ายก้นหอย (วนตามเข็มนาฬิกา) ความสำคัญของโมเดลนี้คือ เป็นวิธีการพัฒนาแบบค่อยเป็นค่อยไปทีละรอบ โดยเมื่อจบการทำงานในแต่ละรอบ ก็จะได้ผลงานที่มากขึ้นตามเวอร์ชั่นที่เพิ่มขึ้นในแต่ละรอบ ที่สำคัญในแต่ละรอบ จะมีการวิเคราะห์ความเสี่ยง เพื่อประเมินและวางแผนการทำงานในรอบถัดไป

Spiral Model

(2) การวิเคราะห์ความเสี่ยง (3) การพัฒนาและทดสอบตัวผลิตภัณฑ์ Spiral Model การทำงานแต่ละรอบของ Spiral Model จะถูกแบ่งออกเป็น 4 ส่วน (1) การวางแผน (2) การวิเคราะห์ความเสี่ยง (3) การพัฒนาและทดสอบตัวผลิตภัณฑ์ (4) การประเมิน วงจรการทำงานของ Spiral แบ่งออกเป็น 4 ส่วน ดังนี้ (1)การวางแผน (Planning) เป็นการกำหนดจุดมุ่งหมายของโครงการ กำหนดเงื่อนไขในการดำเนินงาน ระบุข้อกำหนดของระบบงานที่ต้องการ ระบุข้อจำกัดในด้านต่างๆ เช่นทีมงานในการดำเนินงาน สภาพแวดล้อมของการพัฒนาระบบและศึกษาหาแนวทางต่างๆที่นำมาใช้แก้ไขปัญหา รวมถึงการพิจารณาถึงต้นทุนที่ใช้ ผลประโยชน์ที่จะได้รับจากการใช้ระบบสารสนเทศที่พัฒนาเรียบร้อยแล้ว (2)การวิเคราะห์ความเสี่ยง (Risk analysis) เป็นการนำแนวทางในการแก้ไขปัญหาต่างๆ มาประเมินหาความเสี่ยง จากนั้นคัดเลือกแนวทางที่ดีที่สุดและมีความเป็นไปได้สูงสุดมาใช้ในการพัฒนาระบบ เพื่อจัดการความเสี่ยงหรือหลีกเลี่ยงความเสี่ยงที่จะเกิดขึ้น เช่น ความเสี่ยงของโครงการจะล้มเหลว ความเสี่ยงของคุณภาพระบบที่พัฒนาแล้วเสร็จ ความเสี่ยงทางธุรกิจที่เกิดจากการใช้งานระบบที่พัฒนาเรียบร้อยแล้ว ความเสี่ยงต่างๆ นี้ สามารถแก้ปัญหาได้ด้วยการพัฒนาต้นแบบ (Prototype) หรือการจำลองสถานการณ์เพื่อวิเคราะห์หาความเสี่ยง (3)การพัฒนาและทดสอบระบบ (Engineering) เป็นการพัฒนาตัวต้นแบบตามข้อกำหนดที่กำหนดไว้ในขั้นตอนการวางแผน และในขั้นตอนนี้จะเป็นการพัฒนาระบบต่อยอดจากของเดิมที่เคยพัฒนาในรอบก่อนหน้า ระบบที่พัฒนาจะมีความสามารถเพิ่มเติมจากระบบเดิมระบบงานที่ได้แต่ละรอบจะเรียกเป็นเวอร์ชั่น จากนั้นทำการทดสอบการทำงานของระบบให้ตรงตามข้อกำหนดที่กำหนดไว้ในขั้นตอนการวางแผน (4)การประเมิน (Evaluation) เป็นการทบทวนผลลัพธ์ของการทำงานในขั้นตอนที่ผ่านมาร่วมกับเจ้าของระบบ แล้วทำการวางแผนเพื่อเตรียมดำเนินการในรอบถัดไป โดยระบบที่ได้จะมีเวอร์ชั่นที่มีความก้าวหน้าและสมบูรณ์มากขึ้นเรื่อยๆ จนได้ระบบที่สมบูรณ์ในที่สุด

Joint Application Development (JAD) คือ วิธีการพัฒนาระบบร่วมกัน โดยนำบุคคลที่เกี่ยวข้องกับการพัฒนาระบบมาประชุมร่วมกัน เพื่อร่วมกัน - กำหนดความต้องการของระบบ - ขอบเขตการทำงานของระบบ - การวิเคราะห์และออกแบบระบบ Joint Application Development (JAD) คือวิธีการพัฒนาระบบร่วมกัน โดยนำบุคคลที่เกี่ยวข้องกับการพัฒนาระบบมาประชุมร่วมกัน เพื่อร่วมกันกำหนดความต้องการของระบบขอบเขตการทำงานของระบบ การวิเคราะห์และออกแบบระบบ บุคคลที่เกี่ยวข้องระบบประกอบด้วยเจ้าของระบบ ผู้ใช้งานระบบ นักวิเคราะห์และออกแบบระบบ โปรแกรมเมอร์ วิธีการนี้จะทำให้ช่วยลดเวลาและค่าใช้จ่ายในการดำเนินงานลง เนื่องจากนำบุคคลที่เกี่ยวข้องมาประชุมร่วมกันทำงาน ทำให้ได้ระบบที่พร้อมใช้งานในเวลาอันรวดเร็ว คุณภาพการทำงานของระบบตรงตามความต้องการของผู้ใช้

ผู้เข้าร่วมการดำเนินการวิธีการพัฒนาระบบ JAD (1)JAD Session Leader (2)Users (3)Manager (4)Sponsor (5)System Analyst (6)Scribe (7)IS Staff ผู้เข้าร่วมการดำเนินการวิธีการพัฒนาระบบร่วมกัน ประกอบด้วย (1)JAD Session Leader เป็นผู้ดำเนินการประชุม ต้องผ่านการอบรมการทำงานเป็นกลุ่มและเป็นผู้ที่คอยอำนวยความสะดวกระหว่างการประชุม จัดตั้งระเบียบวาระการประชุมควบคุมการประชุมให้อยู่ในวาระ เพื่อให้ได้ข้อมูลตรงจุด และเป็นผู้ชี้ขาดกรณีมีความขัดแย้งกันในระหว่างการประชุม (2)Users คือ ผู้ใช้ระบบ เนื่องจากเป็นผู้ที่ใช้ระบบเป็นประจำทุกวัน ดังนั้นจะมีความเข้าใจถึงการทำงานและปัญหาที่เกิดขึ้นเป็นอย่างดี และเป็นบุคคลที่สามารถตอบคำถามเกี่ยวกับความสามารถของระบบที่กำลังจะพัฒนา (3)Manager ผู้บริหารขององค์กร ซึ่งเป็นผู้ที่ใช้ระบบเช่นเดียวกับ User ผู้บริหารจะคอยเตรียมคำถามที่มุ่งไปที่ระบบที่ต้องการพัฒนาขึ้นมาใหม่ คอยจูงใจและคอยช่วยหาข้อสรุปในแต่ละวาระการประชุม (4)Sponsor คือ ผู้ที่รับผิดชอบเรื่องค่าใช้จ่ายในการพัฒนาระบบนั้นๆ ซึ่งอาจจะเป็นผู้บริหารระดับสูงสุดขององค์กร (5)System Analyst นักวิเคราะห์ระบบและทีมของนักวิเคราะห์ระบบ ทำหน้าที่เก็บข้อมูลจากการประชุมในแต่ละครั้ง (6)Scribe คือ ผู้ที่ทำหน้าที่จดสรุปรายละเอียดระหว่างการประชุม โดยทั่วไปอาจใช้เครื่องคอมพิวเตอร์แบบพกพาช่วยในการบันทึก (7)IS Staff ทีมของหน่วยบริการสารสนเทศองค์กรเช่น นักวิเคราะห์ระบบ โปรแกรมเมอร์ และผู้เชี่ยวชาญด้านฐานข้อมูล บุคคลเหล่านี้สามารถเสนอความคิดเห็นด้านเทคโนโลยีได้

Rapid Application Development (RAD) คือวิธีการการพัฒนาระบบแบบรวดเร็ว โดยใช้เครื่องมือสนับสนุน (CASE Tools) ประโยชน์คือ 1. ทำให้ได้ระบบที่สมบูรณ์ในเวลารวดเร็ว 2. ช่วยลดต้นทุนและเวลาในการพัฒนา เป็นการประยุกต์โมเดลการพัฒนาระบบแบบดั้งเดิมและวิธีการพัฒนแบบ JAD วิธีการพัฒนาระบบแบบรวดเร็ว โดยใช้เครื่องมือสนับสนุน (CASE Tools) ช่วยในการพัฒนาระบบ ทำให้ได้ระบบที่สมบูรณ์ในเวลารวดเร็ว ทำให้ช่วยลดต้นทุนและเวลาในการพัฒนา วิธีการนี้เป็นการประยุกต์โมเดลการพัฒนาระบบแบบดั้งเดิมและวิธีการพัฒนแบบ JAD โดยรวมขั้นตอน การวิเคราะห์ การออกแบบ การสร้าง และการทดสอบ ไว้ในการประชุมร่วมกันของผู้เกี่ยวข้อง เพื่อลดระยะเวลาในการพัฒนาระบบทีมงานที่ทำงานร่วมกันประกอบด้วย ทีมผู้เชี่ยวชาญด้านเทคโนโลยีสารสนเทศและกลุ่มผู้ใช้ วัตถุประสงค์ของ RAD คือต้องการรวมกระบวนการสำคัญต่างๆ เพื่อพัฒนาระบบในเวลาอันสั้น โดยใช้เครื่องมือ (CASE Tools) เช่น การใช้เครื่องมือสร้างแบบฟอร์มและรายงานแบบอัตโนมัติรวมถึงการนำภาษายุคที่ 4 เพื่อสร้างต้นแบบระบบขึ้นมาได้อย่างรวดเร็ว ภายในระยะเวลาที่จำกัด มากกว่าที่จะให้ระบบมีความสมบูรณ์แบบ

เทคนิคสำคัญของ RAD ประกอบด้วย (1) พัฒนาต้นแบบได้อย่างรวดเร็ว (2) เป็นแหล่งรวมเครื่องมือเพื่อการพัฒนาระบบ (3) มีทีมงานที่เชี่ยวชาญการใช้เครื่องมือเหล่านั้น (4) เป็นแนวร่วมปฏิบัติการกับ JAD (5) มีกรอบระยะเวลาการพัฒนาที่จำกัด เทคนิคสำคัญของ RAD ประกอบด้วย (1)พัฒนาต้นแบบได้อย่างรวดเร็ว (2)เป็นแหล่งรวมเครื่องมือเพื่อการพัฒนาระบบ (3)มีทีมงานที่เชี่ยวชาญการใช้เครื่องมือเหล่านั้น (4)เป็นแนวร่วมปฏิบัติการกับ JAD (5)มีกรอบระยะเวลาการพัฒนาที่จำกัด

Unified Process (UP) คือ วิธีการพัฒนาระบบเชิงวัตถุ ที่เน้นการสร้างโมเดลและจัดการโมเดลด้วยภาษา UML (Unified Modeling Language) Unified Process (UP) คือวิธีการพัฒนาระบบเชิงวัตถุ ที่ถูกพัฒนาขึ้นโดย Rational Software จุดประสงค์ของ Unified Process คือการพัฒนาซอฟต์แวร์ที่มีคุณภาพสูง ตรงตามความต้องการของผู้ใช้ ภายใต้งบประมาณและระยะเวลาที่กำหนดไว้ในโครงการ โดยพื้นฐานสำคัญของกระบวนการ Unified Process คือการสร้างโมเดลและจัดการโมเดลด้วยภาษา UML (Unified Modeling Language) นอกจากนี้ ในปัจจุบัน โมเดลนี้ยังได้รับการยอมรับอย่างกว้างขวาง ด้วยการกำหนดให้เป็นระเบียบวิธีมาตรฐานสำหรับการพัฒนาระบบเชิงวัตถุ ทั้งนี้ระเบียบวิธีของ Unified Process ถูกออกแบบมาเพื่อนำมาใช้กับโครงการผลิตซอฟต์แวร์ขนาดใหญ่ที่สะท้อนให้เห็นถึงวิวัฒนาการของกระบวนการผลิตซอฟต์แวร์สำหรับยุคปัจจุบันได้เป็นอย่างดี ขั้นตอนการพัฒนาระบบด้วย Unified Process ประกอบด้วย 4 ระยะดังนี้

(1)ระยะเริ่มต้น (Inception Phase) Unified Process (UP) (1)ระยะเริ่มต้น (Inception Phase) (2)ระยะเพิ่มเติมรายละเอียด (Elaboration Phase) (3)ระยะการสร้าง (Construction Phase) (4)ระยะการเปลี่ยนผ่าน (Transition Phase) (1)ระยะเริ่มต้น (Inception Phase) เป็นระยะเริ่มต้นของการดำเนินงาน ที่ผู้จัดการโครงการจะกำหนดขอบเขตของระบบ หน้าที่การทำงานหลักๆ ของโครงการที่ต้องทำสำเร็จ และวิสัยทัศน์สำหรับระบบใหม่ โดยการศึกษาถึงประโยชน์ที่ได้รับจากระบบใหม่ หากผลการศึกษาระบบพบว่า โครงการมีส่วนช่วยธุรกิจได้น้อยมาก โครงการพัฒนาซอฟต์แวร์นี้จะถูกยกเลิกโดยทันทีในระยะนี้ (2)ระยะเพิ่มเติมรายละเอียด (Elaboration Phase) การดำเนินงานในระยะนี้ ปกติจะต้องทำงานทวนซ้ำหลายรอบ ด้วยการทำความเข้าใจถึงปัญหาของระบบว่า ระบบจะทำงานได้อย่างไร การทำงานของระยะ Elaboration จะประกอบด้วย การวิเคราะห์ การออกแบบ และการสร้างสถาปัตยกรรมหลักของระบบ ซึ่งเกี่ยวข้องกับการรวบรวมแนวความคิดสำคัญต่างๆ ของผลิตภัณฑ์ โดยเมื่อถึงจุดสิ้นสุดของระยะนี้ ผู้จัดการโครงการจะสามารถประมาณต้นทุนโครงการและเวลาในการทำงานได้ชัดเจน หรือใกล้เคียงความจริงมากขึ้น แบบจำลองที่ใช้ประกอบด้วยไดอะแกรมต่างๆ คือ Use-Case Diagram, Class Diagrams, Sequence Diagrams และไดอะแกรมอื่นๆ ของ UML และการคาดการณ์ต้นทุน ผลกำไร และความเสี่ยง จะกระทำระยะนี้ (3)ระยะการสร้าง (Construction Phase) ระยะนี้จะทำงานทวนซ้ำหลายรอบเช่นกัน เกี่ยวข้องกับการออกแบบและการสร้างระบบ โดยส่วนประกอบสำคัญและคุณสมบัติต่างๆที่จำเป็นต้องมีในระบบทั้งหมด จะได้รับการพัฒนาและนำมาผนวกรวมเข้าด้วยกัน จากนั้น ระบบงานก็จะถูกนำมาทดสอบว่าทำงานถูกต้องหรือไม่ ตรงตามความต้องการของผู้ใช้หรือไม่ และผู้ใช้พึงพอใจหรือไม่ เพื่อพร้อมเข้าสู่การส่งมอบซอฟต์แวร์และการติดตั้งใช้งานจริงต่อไป (4)ระยะการเปลี่ยนผ่าน (Transition Phase) เป็นระยะการส่งมอบระบบให้แก่ลูกค้า ซึ่งถือเป็นระยะสุดท้าย โดยจะดำเนินการเพียงรอบเดียวหรือหลายรอบก็ได้ ระบบจะถูกติดตั้งและพร้อมสำหรับการปฏิบัติงานจริง มีการฝึกอบรมผู้ใช้ จัดทำเอกสารระบบ คู่มือการใช้ระบบ

Agile Methodologies เป็นเทคนิคมุ่งตอบสนองความเปลี่ยนแปลงมากกว่าการปฏิบัติงานตามแผนไม่มุ่งเน้นการจัดทำเอกสารที่ไม่จำเป็น ด้วยการเน้นความเป็นเรียบง่าย ตรงไปตรงมา และต้องทำให้ตรงตามความประสงค์ Agile Methodologies เป็นเทคนิคมุ่งตอบสนองความเปลี่ยนแปลงมากกว่าการปฏิบัติงานตามแผน รวมถึงไม่มุ่งเน้นการจัดทำเอกสารที่ไม่จำเป็น ด้วยการเน้นความเป็นเรียบง่าย ตรงไปตรงมา และต้องทำให้ตรงตามความประสงค์ การพัฒนาระบบตามแนวทางของ Agile ประกอบด้วย

การพัฒนาระบบตามแนวทางของ Agile ประกอบด้วย 1. มุ่งตอบสนองการเปลี่ยนแปลงมากกว่าการดำเนินงานตามแผน 2. มุ่งความสำคัญที่ตัวบุคคลและการปฏิสัมพันธ์มากกว่ากระบวนการและเครื่องมือ 3. เน้นผลผลิตของซอฟต์แวร์มากกว่าเอกสาร 4. เน้นการทำงานร่วมกันกับลูกค้า มากกว่าการต่อรองเจราจาเรื่องสัญญา (1)มุ่งตอบสนองการเปลี่ยนแปลงมากกว่าการดำเนินงานตามแผน หมายความว่า Agile ได้มองเห็นความจริงว่า แผนการต่างๆ ที่กำหนดขึ้นในโครงการ เมื่อนำมาปฏิบัติจริงแล้ว อาจไม่สามารถดำเนินงานตรงตามแผนได้ทุกครั้งไป (2)มุ่งความสำคัญที่ตัวบุคคลและการปฏิสัมพันธ์มากกว่ากระบวนการและเครื่องมือ เทคนิค Agile จะเน้นการปฏิสัมพันธ์ด้วยการสื่อสารระหว่างทีมงานกับผู้ใช้ เพื่อให้ได้มาซึ่งสิ่งที่ต้องการจริงๆ มากกว่าการมุ่งเน้นที่ทฤษฏี กระบวนการ และเครื่องมือมากมาย (3)เน้นผลผลิตของซอฟต์แวร์มากกว่าเอกสาร Agile จะเน้นชิ้นงานหรือผลผลิตซอฟต์แวร์ที่สามารถนำไปใช้งานได้จริง ซึ่งปกติ Agile จะส่งมอบชิ้นงานทางซอฟต์แวร์เป็นระยะๆ เพื่อให้ลูกค้าเห็นความคืบหน้าของชิ้นงานและเกิดความพึงพอใจ (4)เน้นการทำงานร่วมกันกับลูกค้า มากกว่าการต่อรองเจราจาเรื่องสัญญา Agile จะมุ่งเน้นให้ลูกค้าเข้ามามีส่วนร่วมในการกำหนดความต้องการกับทีมงานอย่างต่อเนื่อง

สรุป กระบวนการทางวิศวกรรมซอฟต์แวร์มุ่งเน้นการเพิ่มผลผลิตที่ดี กิจกรรมพื้นฐานของกระบวนการทางซอฟต์แวร์ประกอบด้วย 4 ส่วนหลักๆ คือ -ข้อกำหนด - การพัฒนาซอฟต์แวร์ - การตรวจสอบความถูกต้องของซอฟต์แวร์ - วิวัฒนาการของซอฟต์แวร์ ระเบียบวิธีการพัฒนาซอฟต์แวร์ หรือเรียกว่า โมเดลการพัฒนาซอฟต์แวร์ คือแบบจำลองที่ใช้สำหรับเป็นตัวชี้นำถึงกิจกรรมหลัก การพัฒนาซอฟต์แวร์ปัจจุบันมีโมเดลการพัฒนาซอฟต์แวร์ให้ใช้หลายโมเดล โดยเฉพาะโมเดลสมัยใหม่ตามหลักวิศวกรรมซอฟต์แวร์