กระบวนการผลิตซอฟต์แวร์ ( Software Process)

1. กระบวนการผลิตซอฟต์แวร์ (Software Process)

2. SDLC (Software Development Life Cycle) • วงจรการพัฒนาระบบ คือ กระบวนการทางความคิด ( Logical Process)ในการพัฒนาระบบสารสนเทศเพื่อแก้ปัญหาทางธุรกิจและตอบสนองความต้องการของผู้ใช้ได้ โดยภายในวงจรนั้นแบ่งกระบวนการพัฒนาออกเป็นระยะ ( Phase ) ได้แก่ ระยะการวางแผน( Planning Phase) ระยะการวิเคราะห์ ( Analysis Phase) ระยะการออกแบบ ( Design Phase) และระยะการสร้างและพัฒนา( Implementation Phase )โดยแต่ละระยะจะประกอบไปด้วยขั้นตอน ( Steps ) ต่าง ๆ ซึ่งแต่ละโครงการพัฒนาระบบจะมีการแบ่งระยะและขั้นตอนในแต่ละระยะแตกต่างกัน ทำให้ปัจจุบันมีรูปแบบของวงจรการพัฒนาระบบแตกแขนงออกไปมาก

3. ประเภทของ SDLC • Waterfall • V-Shaped • Spiral • Increment • Agile

4. Waterfall model • SDLC แบบ Waterfall มีหลักการเปรียบเสมือนกับน้ำตก ซึ่งไหลจากที่สูงลงที่ต่ำ และไม่สามารถไหลกลับมาในทางตรงกันข้ามได้อีก • การพัฒนาระบบงานด้วยหลักการนี้ เมื่อทำขั้นตอนหนึ่งแล้วจะไม่สามารถย้อนกลับมาที่ขั้นตอนก่อนหน้าได้อีก • ซึ่งจะมองเห็นจุดอ่อนของหลักการนี้ว่า หากมีข้อผิดพลาดเกิดขึ้นที่ขั้นตอนก่อนหน้านี้แล้ว จะไม่สามารถย้อนกลับมาแก้ไขได้ ดังนั้น การพัฒนาระบบด้วยหลักการนี้ จำเป็นต้องมีการวางแผนที่ดี เพื่อให้สามารถป้องกันการผิดพลาดได้มากที่สุด ซึ่งทำได้ยากมาก ยกเว้นระบบงานนั้นมีรูปแบบการพัฒนาที่ดี และตายตัวอยู่แล้ว

5. ………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………… Waterfall model • Waterfall Model เป็นแบบจำลองกระบวนการพัฒนาระบบแบบดั้งเดิม โดยมีแนวคิดว่ากิจกรรมหนึ่งจะเริ่มต้นดำเนินการได้ก็ต่อเมื่อกิจกรรมก่อนหน้าได้ทำเสร็จสิ้นสมบูรณ์แล้ว • ในปัจจุบันนักพัฒนาระบบได้ตระหนักแล้วว่า Waterfall Model ไม่เหมาะสมกับการนำมาใช้เป็นแบบแผนของการพัฒนาระบบอีกต่อไป • เนื่องจากระบบในปัจจุบันมีความซับซ้อน นักพัฒนาระบบเองไม่สามารถตอบได้อย่างแน่นอนว่ากิจกรรมที่ได้ดำเนินการนั้นได้ทำเสร็จสิ้นสมบูรณ์แล้วหรือยัง • ถ้านำ Product ที่ยังไม่สมบูรณ์ไปพัฒนาต่อในขั้นตอนกิจกรรมต่อไปก็จะทำให้ Product ที่จะได้จากขั้นตอนต่อไปไม่สมบูรณ์เช่นกัน เปรียบเสมือนการส่งมอบความเสี่ยงให้กันเป็นทอดๆ • ตัวอย่างเช่น การวิเคราะห์ความต้องการเราไม่อาจบอกได้ว่าความต้องการที่วิเคราะห์มานั้นเป็นความต้องการที่ถูกต้องแน่นอนและครบถ้วนสมบูรณ์ ซึ่งในความเป็นจริงความต้องการมีการเปลี่ยนแปลงได้ตลอดเวลาและสามารถเกิดความต้องการใหม่ๆได้เสมอ ถ้าเรานำความต้องการทั้งหมดมาพัฒนาในครั้งเดียวเราจะทราบอีกครั้งว่า ความต้องการใดที่ไม่ถูกต้องก็ต่อเมื่อระบบได้พัฒนาเสร็จและได้รับการประเมินจากผู้ใช้แล้ว ซึ่งใช้เวลานานกว่าจะทราบได้

6. ข้อดีของ Waterfall • ง่ายต่อการทำความเข้าใจ, ง่ายต่อการใช้งาน • มีโครงสร้างที่ชัดเจนเหมาะสำหรับผู้เริ่มต้นในการออกแบบ • มี Milestones ที่เข้าใจได้ง่าย • Sets requirements stability (ความต้องการของระบบหรือความต้องการของ user ไม่เปลี่ยนแปลง หรือ เปลี่ยนแปลงน้อยมาก) • มีการจัดการและการควบคุมที่ดี(plan, staff, track) • ทำงานได้ดีเพื่อเน้นประสิทธิภาพ มากกว่าเน้นค่าใช้จ่ายและตารางเวลาที่จำกัด ไมล์สโตน (Milestone) หมายถึง การระบุผลผลิตของงาน (output) ที่ต้องการจะให้เกิดขึ้นในแผน เพื่อใช้เป็นเครื่องมือในการตรวจสอบและติดตามผลงานที่เกิดขึ้น

7. ข้อด้อยของ Waterfall • ความต้องการทั้งหมดจะต้องถูกวิเคราะห์อย่างถูกต้องมาก่อน • เมื่อส่งมอบงานแล้ว การแก้ไขแต่ละขั้นตอนมีความยืดหยุ่นน้อย • อาจมีความผิดพลาดบ้างในแต่ละขั้นตอน • แก้ปัญหาการพัฒนาซอฟต์แวร์ไม่ได้ทั้งหมด • อาจมีปัญหาในตอนท้ายหากต้องทำการรวมกับ Module อื่น • ลูกค้ามีโอกาสน้อยที่จะมองภาพระบบโดยรวมก่อนใช้งาน

8. จะใช้Waterfall Model เมื่อไร • ความต้องการของ User มีความแน่นอนไม่เปลี่ยนแปลง • ระบบมีความเสถียร • User ยอมรับเทคโนโลยีใหม่ ๆ • การถ่ายโอนซอฟต์แวร์จาก platform เดิมไป platform ใหม่

9. Adapted Waterfall model SDLC แบบ Adapted Waterfall เป็นรูปแบบในการพัฒนาระบบงานที่ปรับปรุงมาจากแบบ waterfall โดยในแต่ละขั้นตอนเมื่อดำเนินงานอยู่ สามารถย้อนกลับมายังขั้นตอนก่อนหน้าเพื่อแก้ไขข้อผิดพลาดหรือสามารถย้อนกลับข้ามขั้น โดยไม่จำเป็นต้องเป็นขั้นตอนที่ติดกันได้

10. V-Shaped model • เป็น Model ที่เน้นการตรวจสอบ(verification) และการรับรองความถูกต้อง(validation) ควบคู่กันไป • การทดสอบของผลิตภัณฑ์กระทำขนานกันไปกับการวางแผนในการพัฒนา Software

11. V-Shaped model • Project and Requirements Planning – การจัดสรรทรัพยากร • Product Requirements and Specification Analysis – กำหนด spec ที่สมบูรณ์ของ Software • Architecture or High-Level Design – กำหนดวิธีการทำงานที่ตอบสนองต่อการออกแบบ Software • Detailed Design – การพัฒนาอัลกอริทึมสำหรับองค์ประกอบต่าง ๆ • Production, operation and maintenance – การเพิ่มประสิทธิภาพและการแก้ไข • System and acceptance testing – ตรวจสอบสภาพแวดล้อมของ Software • Integration and Testing – ตรวจสอบการเชื่อมต่อแต่ละ Module ว่าถูกต้องหรือไม่ • Unit testing – ตรวจสอบการทำงานของแต่ module ว่าทำงานถูกต้องตามเป้าหมาย • Coding – เปลี่ยน Algorithm เป็น Software

12. ข้อดีของ V-Shaped model • เน้นการวางแผนสำหรับการ Verification และ Validation ของผลิตภัณฑ์ในขั้นเริ่มต้นของการพัฒนาผลิตภัณฑ์ • งานที่ส่งมอบต้องสามารถทดสอบได้ทุกขั้นตอน • สามารถติดตามความก้าวหน้าได้ทุกขั้นตอน • เข้าใจง่ายและใช้งานได้ง่าย

13. ข้อด้อยของ V-Shaped Model • ยากต่อการจัดการเหตุการณ์ที่เกิดขึ้นพร้อมกัน • ยากต่อการจัดการกับ Requirement ที่มีการเปลี่ยนแปลงบ่อยๆ • ไม่มีระบบการจัดการความเสี่ยง (Risk Management)

14. จะใช้ V-shaped Model เมื่อไร • ใช้ในระบบที่ต้องการความเสถียรสูง (high reliability) เช่น ระบบเกี่ยวการจัดการภายในโรงพยาบาล (hospital patient control applications) • ระบบที่มี Requirement ที่พร้อมและค่อนข้างครบถ้วน

15. Spiral model

16. Spiral model • แบบจำลองspiral แบ่งออกได้เป็นส่วนย่อยๆ โดยปกติจะแบ่งเป็น 3 ส่วน หรือ 6 ส่วนงานเช่น • การติดต่อสื่อสารกันระหว่างผู้ใช้ และผู้พัฒนาระบบ • การวางแผน • การวิเคราะห์ความเสี่ยง • วิศวกรรม • การสร้างและนำไปใช้ • การประเมินผลจากผู้ใช้

17. Spiral model • แต่ละรอบของการทำซ้ำ • วิเคราะห์ความเสี่ยง • พัฒนาต้นแบบสำหรับตรวจสอบความเป็นไปได้และความต้องการ • เมื่อพบความเสี่ยงผู้จัดการโครงการจะต้องตัดสินใจทีจะกำจัดหรือลดความเสี่ยง

18. Spiral model • แต่ละรอบของการทำซ้ำ • วิเคราะห์ความเสี่ยง • พัฒนาต้นแบบสำหรับตรวจสอบความเป็นไปได้และความต้องการ • เมื่อพบความเสี่ยงผู้จัดการโครงการจะต้องตัดสินใจทีจะกำจัดหรือลดความเสี่ยง

19. Spiral model • ปัญหาของการใช้แบบจำลองบันไดเวียน ในการพัฒนาซอฟต์แวร์ คือการโน้มน้าวให้ผู้ใช้ระบบเห็นชอบกับวิธีการที่เป็นกระบวนทำซ้ำแบบมีวิวัฒนาการ • ความสำเร็จของการใช้ แบบจำลองบันไดเวียน ผู้พัฒนาจะต้องมีความเชี่ยวชาญในด้านการประเมินผลความเสี่ยง

20. Spiral model • เป็น model ที่ใช้ความเสี่ยงเป็นเครื่องตัดสินใจว่าจะกระทำอะไรต่อไป (risk-driven) • ขั้นตอนในแต่ละรอบ • วิเคราะห์เป้าหมาย แนวทางเลือกต่างๆ เงื่อนไขต่างๆ • วิเคราะห์ความเสี่ยง • พยายามลดความเสี่ยงนั้น เช่น ทำ Prototype เพื่อทดสอบ • พัฒนา product • นำ product ให้ลูกค้าทดสอบ

21. Iterative and Incremental Model Iteration1 Iteration2 Iteration3 Requirement1 Requirement2 Requirement3 SA SA SA SD SD SD Imp Imp Imp Op Op Op Built1 Built1 Built2 Built1 Built2 Built3

22. Iterative and Incremental Model • เป็นแบบจำลองกระบวนการซึ่งรองรับความไม่แน่นอนต่างๆ ที่จะเกิดขึ้นในการพัฒนาระบบโดยมีแนวคิดว่า การค่อยๆพัฒนาระบบจากเล็กไปใหญ่เป็นการลดความเสี่ยงของการพัฒนา • การพัฒนานั้นประกอบด้วยหลายรอบของ SDLC • แต่ละรอบจะพัฒนาเฉพาะส่วน (ไม่ใช่ทีเดียวทั้งหมด) แล้วค่อยๆ เพิ่มเติมให้ระบบใหญ่ขึ้นจนกว่าจะเสร็จสมบูรณ์ (ผู้ใช้ยอมรับ) • ไม่อาจคาดการณ์อย่างแน่นอนได้ว่าจะต้องใช้รอบในการพัฒนากี่รอบ

23. Agile Process • Agile แปลว่า คล่องแคล่ว ฉลาด ฉับไว • Agile Process เป็นกระบวนการผลิตซอฟต์แวร์รูปแบบใหม่ที่ถูกกำหนดขึ้นตามระเบียบวิธีปฏิบัติแบบ Agile • เป็นระเบียบวิธีที่แตกแขนงจาก RAD (Rapid Application Development) ที่เน้นการผลิตซอฟต์แวร์แบบเร่งด่วน • ปี ค.ศ. 1970 กระบวนการผลิตซอฟต์แวร์มีลักษณะเชิงบังคับให้ทำตามลำดับขั้นตอนอย่างต่อเนื่อง • ปี ค.ศ. 1990 นักพัฒนาซอฟต์แวร์ได้คิดค้นวิธีการพัฒนาซอฟต์แวร์แบบใหม่ที่มีอิสระ ทำให้มีความคล่องตัวสูงในการทำงาน วิธีนี้เรียกว่า “Agile Method”

24. Agile Process • Agile มีบทบัญญัติ 4 ประการที่ต้องคำนึงเมื่อต้องพัฒนาซอฟต์แวร์ ดังนี้ [Agile Alliance 2001] 1. ทีมงานทุกคนมีคุณค่าในตัวเองมากพอที่จะทำงานอย่างอิสระได้ 2. ทีมงานพอใจที่จะใช้เวลาส่วนใหญ่ในการเขียนโปรแกรมเพื่อสร้างซอฟต์แวร์มากกว่าการใช้เวลาเพื่อจัดทำเอกสาร 3. ทีมงานมุ่งเน้นการทำงานร่วมกับลูกค้าโดยตรง แทนการเจรจาอย่างเป็นทางการตามสัญญาว่าจ้าง 4. ทีมงานให้ความสำคัญกับการแก้ไขงานทันทีที่มีการเปลี่ยนแปลง มากกว่าการวางแผนก่อนลงมือทำงานเมื่อมีการเปลี่ยนแปลง

25. Agile Process • Agile • XP • ASD • Scrum • DSDM • Crystal • FDD • AM

26. Extreme Programming (XP) • คิดค้นโดย Kent Beck • ค.ศ. 1999 • พัฒนาตามแบบ Iteration and Incremental • เป็นแบบจำลองกระบวนการผลิตซอฟต์แวร์ที่ใช้แนวทางเชิงวัตถุเป็นหลัก • มี 4 ขั้นตอน ได้แก่ การวางแผน ออกแบบ เขียนโปรแกรม และการทดสอบ

27. Extreme Programming (XP) User Story Iteration Plan Simple Design Spike Solution : Prototype วางแผน (Planning) ออกแบบ (Design) Release Software Increment ทดสอบ (Testing) เขียนโปรแกรม (Coding) Unit Test Continuous integration Acceptance Test Pair Programming Unit Test Continuous Integrations

28. Adaptive Software Development (ASD) • การพัฒนาซอฟต์แวร์แบบปรับตัว-เอเอสดีนำเสนอ โดย Jim Highsmith • ให้เป็นเทคนิคสำหรับสร้างระบบที่ซับซ้อน • เน้นการทำงานร่วมกันระหว่างบุคคล และการจัดระเบียบทีมงานด้วยตนเอง • การเรียนรู้ของทีมงานที่ดี และแบ่งงานอย่างเป็นระบบและชัดเจน

29. Adaptive Software Development (ASD) Adaptive cycle planning Mission statement Project constraints Basic requirements Time-boxed release plan Requirements gathering JAD Mini-specs Speculation Collaboration Release Learning Software increment adjustments for subsequent cycles Components implemented/tested Focus groups for feedback Formal technical reviews postmortems

30. Adaptive Software Development (ASD) • การคาดเดา (Speculation) • โครงการเริ่มต้นขึ้นและมีการทำแผนวงจรการปรับตัว • ใช้ข้อมูลเบื้องต้น ได้แก่ ข้อความแสดงภารกิจของลูกค้า เงื่อนไขต่าง ๆ ของโครงการและความต้องการพื้นฐาน เพื่อกำหนดชุดของวงจรรีลิส(release) คือ รุ่นต่าง ๆ ของซอฟต์แวร์ที่โครงการต้องผลิต • การร่วมมือ (Collaboration) • คือ การจูงใจบุคคลให้ทำงานร่วมกันในทางที่เพิ่มพูนผลลัพธ์ที่สร้างสรรค์และเฉลียวฉลาด • การร่วมมือเป็นวิธีที่ใช้ในทุก ๆ วิธีการแบบ Agile • การร่วมมือมักไม่ใช่เรื่องง่าย

31. Adaptive Software Development (ASD) • การร่วมมือ (Collaboration) • บุคคลที่ทำงานร่วมกันต้องมีความไว้วางใจกัน เพื่อ • การวิพากษ์วิจารณ์โดยปราศจากความข่มชื่น • การช่วยเหลือกันโดยปราศจากความเสียใจ • การทำงานอย่างหนักเท่าเทียมกัน • มีความชำนาญเฉพาะที่จะเป็นประโยชน์ต่องานที่ทำ • มีการพูดคุยถึงปัญหาหรือข้อกังวลสงสัยในทางที่นำไปสู่การกระทำที่ได้ประสิทธิผล

32. Adaptive Software Development (ASD) • การเรียนรู้ (Learning) • เมื่อทีมงานเริ่มพัฒนาชิ้นส่วนที่เป็นส่วนหนึ่งของวงจรปรับตัว ทีมงานจะเรียนรู้ไปพร้อม ๆ กับความก้าวหน้าไปสู่การเสร็จสิ้นวงจร • ทีมเอเอสดี เรียนรู้ได้ 3 วิธีคือ • กลุ่มเฉพาะทาง (Focus Groups) เมื่อลูกค้า/ผู้ใช้งานให้ผลตอบกลับในการใช้งาน โดยแต่ละรุ่นของซอฟต์แวร์ที่ส่งมอบไป สิ่งนี้จะเป็นตัวบ่งชี้ว่าผลิตภัณฑ์ได้ตอบสนองความจำเป็นทางธุรกิจหรือไม่ • การทบทวนเทคนิคอย่างเป็นทางการ (Formal Technical Review) ทีมเอเอสดีมีการทบทวนชิ้นส่วนซอฟต์แวร์ที่กำหนดพัฒนาอยู่ ขณะเดียวกับมีกาปรังปรุงคุณภาพและเรียนรู้ไปพร้อม ๆ กัน • การตรวจสอบภายหลัง (Postmortems) เมื่องานเสร็จสิ้นแล้ว ทีมงานกลายเป็นผู้วิจารณ์งานและคุณภาพของตนเอง ซึ่งเป็นเป้าหมายของการเรียนรู้เพื่อปรับปรุงวิธีการทำงาน

33. Scrum • Scrum พัฒนาโดย Jeff Sutherland • พัฒนาเมื่อต้นทศวรรษ 1990 • พัฒนาต่อโดย Schwaberและ Beedle

34. Scrum • หลักการของ Scrum คือ • จัดตั้งทีมทำงานขนาดเล็กที่ เกิดการสื่อสาร การแบ่งปันเทคนิค และข่าวสารที่ไม่เป็นทางการให้มากที่สุด ขณะที่ลดค่าใช้จ่ายส่วนเกินให้น้อยที่สุด • กระบวนการต้องสามารถปรับเข้ากับการเปลี่ยนแปลงทางธุรกิจและเทคนิคได้ เพื่อผลิตผลงานให้ดีที่สุด • กระบวนการต้องผลิตรุ่นซอฟต์แวร์ออกมาบ่อย ๆ เพื่อตรวจสอบ ปรับแต่ง ทดสอบ บันทึกและต่อยอดได้ • งานที่พัฒนาและนักพัฒนาจะแบ่งออกเป็น แพ็กเก็ตหรือพาร์ติชั่นที่สะอาดและขึ้นแก่กันน้อยที่สุด • มีการทดสอบและบันทึกเอกสารอย่างสม่ำเสมอขณะที่สร้างผลิตภัณฑ์ขึ้นมา • กระบวนการสครัมจะต้อง สามารถแจ้งว่า พัฒนาผลิตภัณฑ์เสร็จแล้ว เมื่อใดก็ตามที่ต้องการ อันเนื่องมาจากคู่แข่งออกผลิตภัณฑ์ที่เหมือนกัน หรือบริษัทต้องการเงิน หรือลูกค้าต้องการงาน เป็นต้น

35. Scrum • หลักการของ Scrum อยู่ภายใต้กิจกรรมกรอบงานต่อไปนี้ • ความต้องการ • การวิเคราะห์ • การออกแบบ • การวิวัฒน์ • และการส่งมอบ • แต่ละกิจกรรมกรอบงาน จะประกอบด้วยงานย่อย ๆ เกิดขึ้นภายใน เป็นแบบรูปกระบวนการ เรียกว่า สปริ้น (Sprint) • งานที่ทำภายใต้สปริ้นจะปรับตัวตามปัญหาที่พบขณะนั้น และถูกนิยามและปรับเปลี่ยนให้ทันต่อเหตุการณ์เฉพาะหน้าโดยทีมงานสครัม • Scrum สนับสนุนให้ใช้รูปแบบกระกวนการซอฟต์แวร์ (Software process pattern)

36. Dynamic System Development Method (DSDM) • DSDM หรือวิธีการพัฒนาระบบไม่หยุดนิ่ง เป็นวิธีการพัฒนาซอฟต์แวร์ที่มีการกำหนดกรอบงานสำหรับสร้างและบำรุงรักษาระบบที่มีข้อจำกัดด้านเวลา • โดยใช้การสร้างต้นแบบอย่างค่อยเพิ่มขึ้น • DSDM => 80% ของแอพพลิเคชัน จะเสร็จภายในเวลา 20% ของเวลาทั้งหมดที่ใช้พัฒนา • DSDM เป็นกระบวนการทำวนซ้ำ แต่ละรอบของวงจรจะเป็นไปตามกฎ 80% คือ ทำงานให้เพียงพอเท่าที่จำเป็นในแต่ละรุ่น เพื่อให้เคลื่อนไปสู่รุ่นที่เพิ่มขึ้นถัดไป ส่วนรายละเอียดที่เหลือสามารถทำให้เสร็จภายหลัง เมื่อได้รู้ความต้องการทางธุรกิจเพิ่มเติม หรือเมื่อได้รับการร้องขอให้เปลี่ยนแปลง

37. Dynamic System Development Method (DSDM) • กระบวนการ DSDM • การศึกษาความเป็นไปได้ (Feasibility Study) จัดทำความต้องการและข้อจำกัดทางธุรกิจพื้นฐานของแอพพลิเคชั่นที่จะสร้าง ประเมินความเป็นไปได้ • การศึกษาด้านธุรกิจ (Business Study) จัดสร้างความต้องการเชิงข่าวสาร และเชิงหน้าที่ของแอพพลิเคชั่น นิยามสถาปัตยกรรมและระบุความต้องการในการบำรุงรักษาแอพพลิเคชั่น • การทำวนซ้ำแบบจำลองเชิงหน้าที่ (Functional Model Iteration) ผลิตชุดของต้นแบบค่อยเพิ่มขึ้น ที่มีหน้าที่การทำงานตามที่ลูกค้าต้องการ ต้นแบบจะค่อย ๆ วิวัฒนาการไปเป็นแอพพลิเคชั่นที่ส่งมอบได้ การทำวนซ้ำเป็นการรวบรวมความต้องการเพิ่มเติมจากการตอบสนองกลับมาของผู้ใช้

38. Dynamic System Development Method (DSDM) • กระบวนการ DSDM • การทำวนซ้ำการออกแบบและการสร้าง (Design and Build Iteration) นำต้นแบบที่สร้างขึ้นระหว่างการทำวนซ้ำการสร้างแบบจำลองเชิงหน้าที่มาดูใหม่ • การอิมพลีเม้นต์ (Implementation หรือ coding) ใช้งานรุ่นของซอฟต์แวร์ล่าสุดภายใต้สิ่งแวดล้อมการทำงานจริง • รุ่นของซอฟต์แวร์อาจไม่ต้องสมบูรณ์ร้อยเปอร์เซ็นต์ • การร้องขอการเปลี่ยนแปลงอาจเกิดขึ้นได้ขณะใช้งานอยู่ • กระบวนการ DSDM อาจใช้ร่วมกับกระบวนการ XP เพื่อกำหนดแบบจำลองกระบวนการ

39. Crystal • พัฒนาโดย Alistair Cockburn และ Jim Highsmith • Crystal มีความสามารถในการนำร่อง คือ • มีทรัพยากรจำกัด ทีมงานต้องร่วมมือกัน ในการประดิษฐ์และการสื่อสาร • โดยมีเป้าหมายหลักคือ ส่งมอบซอฟต์แวร์ที่มีประโยชน์ทำงานได้ • เป้าหมายรองคือ จัดเตรียมความพร้อมสำหรับงานถัดไป • เพื่อให้บรรลุความสามารถในการนำร่อง Cockburn และ Highsmithได้นิยามชุดของกรรมวิธี และกรรมวิธีมีชิ้นส่วนหลัก ๆ เหมือน ๆ กัน และมีบทบาท กระบวนการผลิตผลงาน และวิธีปฏิบัติที่แตกต่างกันเฉพาะตัว • ครอบครัวคริสตัล ก็คือ ชุดกระบวนการ Agile ที่ได้พิสูจน์แล้วว่าได้ผลดีสำหรับโครงการชนิดต่าง ๆ

40. Crystal • วิธีการพัฒนาแบบ Crystal เน้นที่การแบ่งแยกงานออกตามคุณลักษณะ ของตัวโครงงาน • แบ่งตามขนาดของทีมงานพัฒนา หรือแบ่งตามความสำคัญของระบบ และความสำคัญตามลำดับก่อนหลังของตัวโครงงาน • โดยการแบ่งจะแยกออกเป็นสีเช่น Crystal Yellow, Crystal Orange เป็นต้น • ทุกแบบจะมีชื่อเรียกรวมกันว่า Crystal Family • สาเหตุที่ต้องมีการแบ่งตามลักษณะดังกล่าวก็เพราะว่ามีการตระหนักถึงความต้องการรูปแบบการพัฒนาที่แตกต่างกันไปตามแต่ละโครงงาน

41. Crystal Crystal จะประกอบด้วย 3 ส่วนที่สำคัญ คือ • “Human-powered” • “Ultralight” • “Stretch-to-fit”

42. Feature Driven Development (FDD) • การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะของซอฟต์แวร์ • คิดค้น โดย Peter Coad และคณะ • เพื่อใช้เป็นแบบจำลองกระบวนการเชิงปฏิบัติการของวิศวกรรมซอฟต์แวร์เชิงวัตถุ • Stephen Palmer และ John Felsingได้ขยายและเพิ่มเติมงานของ Coad • คุณลักษณะ หน้าที่ที่ลูกค้าเห็นว่ามีคุณค่า ที่สามารถอิมพลีเมนต์ได้ภายเวลาสองสัปดาห์หรือน้อยว่า

43. Feature Driven Development (FDD) • นิยามของคุณลักษณะให้ประโยชน์ต่อไปนี้ • เนื่องจากคุณลักษณะเป็นส่วนเล็ก ๆ ของซอฟต์แวร์ที่ทำงานได้ ผู้ใช้จึงสามารถอธิบายได้ง่าย เข้าใจความสัมพันธ์ระหว่างกันได้ง่ายกว่า และสามารถทบทวนได้ดีกว่าเมื่อมีความคลุมเครือ ข้อผิดพลาด หรือการหลงลืม • คุณลักษณะอาจถูกจัดระเบียบ เป็นกลุ่มลำดับชั้นที่มีความสัมพันธ์ทางธุรกิจได้ • เนื่องจากลักษณะเป็นรุ่น ๆ ของคุณลักษณะของซอฟต์แวร์ที่ต้องส่งมอบได้ในการพัฒนาแบบ FDD ทีมงานจะมุ่งพัฒนาซอฟต์แวร์ให้มีคุณลักษณะใหม่ ๆ ที่ทำงานได้ทุก ๆ สองสัปดาห์ • เนื่องจากคุณลักษณะมีขนาดเล็ก ตัวแบบและตัวโค้ดของคุณลักษณะจึงง่ายต่อการตรวจทานอย่างละเอียด • การวางแผนโครงการ การจัดตารางงาน และติดตามจะขับเคลื่อนด้วยคุณลักษณะตามลำดับชั้น ซึ่งดีกว่าการใช้ชุดงานย่อยที่เลือกมาแบบสุ่ม

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

45. Agile Modeling (AM) • AM มีเอกลักษณ์ดังนี้ • สร้างแบบจำลองอย่างมีเป้าหมาย (Model with a purpose) • ใช้แบบจำลองหลาย ๆ ตัว (Use multiple models) • เดินทางอย่างเบาตัว (Travel light) • เนื้อหาสำคัญกว่ารูปแบบ (Content is more important than representation) • รู้จักแบบจำลองและเครื่องมือที่เลือกใช้ให้ดี (Know the models and the tools you use to create them) • ปรับตัวตามสถานการณ์ (Adapt locally)

46. CMM (ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ) • วิศวกรรมซอฟต์แวร์ เป้าหมายสำคัญคือ การผลิตซอฟต์แวร์ให้มีคุณภาพ • คุณภาพ • ผลิตภัณฑ์ • กระบวนการ ผลิตซอฟต์แวร์ที่เลือกใช้ • จำเป็นต้องมีการปรับกระบวนการให้สอดคล้องกับเทคนิค ระเบียบวิธี หรือเครื่องมือชนิดใหม่เข้ามา ประยุกต์ใช้ • การปรับปรุงกระบวนการ (Process Improvement) • กลยุทธ์ในการปรับปรุงกระบวนการ • Total Quality Management (TQM) • Business Process Redesign (BPR) • Continuous Process Improvement (CPI) • Six Sigma • CMM

47. CMM(ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ)CMM(ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ) • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM) • SW-CMM (Software Capability Maturity Model) • คิดค้นโดย สถาบันวิศวกรรมซอฟต์แวร์ (Software EngineeringInstitute : SEI) แห่งมหาวิทยาลัยคาร์เนกีเมลอน ประเทศสหรัฐอเมริกา • มีวัตถุประสงค์เพื่อช่วยเหลือองค์กรหรือหน่วยงานผลิตซอฟต์แวร์ให้สามารถปรับปรุงการดำเนินงานได้อย่างมีระบบ มีความต่อเนื่อง • แบบจำลอง CMM มีลักษณะเป็นระดับชั้น เพื่อให้ทราบว่าองค์กรมีวุฒิภาวะของความสามารถเติบโตเต็มที่ (Capability Maturity)

48. ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM) มีการปรับปรุงกระบวนการอย่างต่อเนื่อง ระดับที่ 5 ดุลยภาพ (Optimizing) การบริหารการเปลี่ยนแปลง ระดับที่ 4 การจัดการ (Managed) มีการควบคุมกระบวนการ การบริหารเชิงปริมาณ ระดับที่ 3 การกำหนดนิยาม (Defined) มีการพัฒนากระบวนการ การบริหารวิศวกรรม ระดับที่ 2 การกระทำซ้ำได้ (Repeatable) มีสภาพแวดล้อมที่มั่นคง การบริหารโครงการ ระดับที่ 1 การเริ่มต้น (Initial)

49. ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM) • วุฒิภาวะระดับที่ 1 ระดับการเริ่มต้น (The initial Level) • องค์กรไม่มีความแน่นอนในการพัฒนาและการบำรุงรักษาซอฟต์แวร์ • ปัญหาที่พบ การไม่บรรลุถึงข้อตกลงต่าง ๆ ที่ต้องปฏิบัติตามกระบวนการอย่างเป็นขั้นตอนที่ได้กำหนดไว้ • การผลิตซอฟต์แวร์ในวุฒิภาวะระดับนี้จะต้องคำนึงถึงประสบการณ์และความสามารถของหัวหน้าและทีมงาน

50. ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM) • วุฒิภาวะระดับที่ 2 ระดับการกระทำซ้ำได้ (The Repeatable Level) • องค์กรจะมีการกำหนดนโยบาย การจัดตั้งทีมงาน และการบริหารโครงการซอฟต์แวร์ เป็นไปอย่างมีแบบแผนและชัดเจน • การผลิตซอฟต์แวร์ในวุฒิภาวะระดับนี้จะต้องคำนึงถึงนโยบายและความมีระเบียบวินัยเป็นสำคัญ • มีการติดตามผลการทำงานตลอดเวลา โดยเฉพาะด้านต้นทุนและระยะเวลา • ความสำเร็จที่ได้จากการพัฒนาซอฟต์แวร์ของโครงการหนึ่ง จึงสามารถนำไปใช้ได้กับโครงการต่อไปในอนาคต (Repeatable)