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

งานนำเสนอเรื่อง: "วิศวกรรมซอฟต์แวร์ และโมเดลการพัฒนาซอฟต์แวร์"— ใบสำเนางานนำเสนอ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20 Spiral Model

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

22 Rapid Application Development (RAD)
คือวิธีการการพัฒนาระบบแบบรวดเร็ว โดยใช้เครื่องมือสนับสนุน (CASE Tools) ช่วยในการพัฒนาส่งผลให้แอปพลิเคชันที่พัฒนาด้วยเทคนิค RAD จะใช้ระยะเวลาสั้น ด้วยการมุ่งเน้นด้านการลดต้นทุนและระยะเวลาในการพัฒนา

23 Rapid Application Development (RAD)

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

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

26 โครงสร้างของ JAD 1 การสนทนาร่วมกันในที่ประชุม 2 กลุ่มผู้ใช้ 3 นักพัฒนาที่มีความเชี่ยวชาญด้านเทคโนโลยีสารสนเทศ 4 ผู้ที่มีอำนาจ ที่สามารถตัดสินใจและชี้ขาดได้ ในกรณีเกิดข้อขัดแย้งระหว่างกันในที่ประชุมและไม่สามารถตกลงกันได้ 5 ผู้สังเกตการณ์มีหน้าที่สังเกตการณ์เท่านั้น ไม่ต้องวิจารณ์สิ่งใดๆ 6 บุคคลที่มีความเชี่ยวชาญในระบบงานทางธุรกิจและเทคโนโลยีสารสนเทศที่สามารถสรุปผลเกี่ยวกับเนื้อหาสาระสำคัญๆได้สั้น กระชับและชัดเจน

27 Unified Process (UP) คือวิธีการพัฒนาระบบเชิงวัตถุ ที่ถูกพัฒนาขึ้นโดย Rational Software กระบวนการของ Unified Process ประกอบด้วย Phase,Iterations และ Disciplines

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

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

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