อุปกรณ์โมเดลคาสเคด
โมเดลน้ำตก หรือที่เรียกว่า Waterfall เป็นหนึ่งในแนวทางการพัฒนาซอฟต์แวร์ที่เป็นที่รู้จักมากที่สุด ผู้เขียนแบบจำลองคือ Winston Royce ในปี พ.ศ. 2513 เขาได้อธิบายสาระสำคัญของนวัตกรรมของเขาในบทความที่มีรายละเอียดข้อดีและข้อเสีย ในสถานที่เดียวกัน เขาอธิบายว่าโมเดลนี้สามารถปรับแต่งให้เป็นโมเดลแบบวนซ้ำได้อย่างไร ในขั้นต้น ในแบบจำลองน้ำตก ขั้นตอนการพัฒนาจะดำเนินไปตามลำดับต่อไปนี้:
- ความหมายและการประสานงานของข้อกำหนด
- การอนุมัติโครงการ
- การเข้ารหัส;
- การสร้างผลิตภัณฑ์ซอฟต์แวร์เวอร์ชันที่ใช้งานได้
- การทดสอบและการแก้จุดบกพร่อง;
- การติดตั้งซอฟต์แวร์
- สนับสนุน.
ตามโมเดลน้ำตก การดำเนินการของนักพัฒนาจะเกิดขึ้นตามลำดับ - ทีละจุด ในการเริ่มต้น งานจะเสร็จสมบูรณ์เพื่อกำหนดและยอมรับข้อกำหนดของซอฟต์แวร์ในรูปแบบของรายการที่ต้องทำให้เสร็จ
หลังจากนั้นจะมีการเปลี่ยนแปลงไปสู่การสร้างและการอนุมัติโครงการซึ่งเป็นผลมาจากเอกสารที่เขียนอธิบายวิธีการใช้ข้อกำหนดซอฟต์แวร์ที่ตกลงกันไว้ก่อนหน้านี้
หากการออกแบบเสร็จสิ้น นักพัฒนาจะดำเนินการดำเนินการ ถัดมาคือการรวมรหัส - การรวมส่วนต่าง ๆ ของโครงการซึ่งสมาชิกในทีมหลายคนทำงาน
ขั้นตอนต่อไปคือการทดสอบและดีบักผลิตภัณฑ์ แก้ไขข้อผิดพลาดที่พบก่อนหน้านี้ที่นี่
สุดท้าย โปรแกรมได้รับการติดตั้งและรองรับ มันเกี่ยวข้องกับการเปลี่ยนแปลงการทำงานหากจำเป็นและกำจัดข้อผิดพลาดที่พบ
โมเดลน้ำตกถือว่าคุณสามารถย้ายไปยังขั้นตอนต่อไปของการพัฒนาตามลำดับอย่างเคร่งครัด - หลังจากเสร็จสิ้นงานก่อนหน้าเท่านั้น ไม่มีความเป็นไปได้ของการย้อนกลับหรือความไม่สอดคล้องกันในเฟส
ข้อดีและข้อเสีย
น้ำตกจำลองถูกวิพากษ์วิจารณ์เป็นครั้งคราวเนื่องจากขาดความยืดหยุ่น หลายคนไม่ชอบมันเพราะเป้าหมายของการจัดการโครงการมีผลเหนือกว่าในขณะที่กำหนดเวลาต้นทุนและคุณภาพของการพัฒนามีความสำคัญมากกว่า
อย่างไรก็ตาม เมื่อพูดถึงโครงการขนาดใหญ่ ฝ่ายบริหารมักจะมีความสำคัญมากกว่าเนื่องจากจะช่วยลดความเสี่ยงของโครงการและเพิ่มความโปร่งใสในการทำงาน
แม้จะมีข้อบกพร่องPMBOKเวอร์ชันที่ 3 ระบุอย่างเป็นทางการเฉพาะวิธีการ "แบบจำลองคาสเคด" ไม่มีตัวเลือกอื่นๆ รวมถึงการจัดการโครงการแบบวนซ้ำ
ข้อดีของรูปแบบน้ำตก:
- การพัฒนาทีมควบคุมได้ง่ายขึ้น ลูกค้าคุ้นเคยกับสิ่งที่โปรแกรมเมอร์กำลังทำอยู่ เขาสามารถเปลี่ยนกำหนดเวลาและงบประมาณของโครงการได้
- ค่าใช้จ่ายในการพัฒนาได้รับการอนุมัติในระยะแรก หลังจากตกลงในทุกขั้นตอนของการใช้งาน ผลิตภัณฑ์ซอฟต์แวร์จะถูกเขียนอย่างต่อเนื่อง
- ไม่จำเป็นต้องมีผู้ทดสอบที่มีประสบการณ์ สำหรับขั้นตอนการทดสอบ คุณสามารถใช้เอกสารประกอบของโปรแกรม
ข้อเสียของรูปแบบน้ำตก:
- เนื่องจากการทดสอบเริ่มต้นที่ขั้นตอนของการพัฒนาให้เสร็จสิ้น หากพบจุดบกพร่อง การแก้ไขจะมีค่าใช้จ่ายสูงกว่าในระยะเริ่มต้น ท้ายที่สุด ผู้ทดสอบจะพบข้อผิดพลาดก็ต่อเมื่อผู้พัฒนาเขียนโค้ดเสร็จแล้วเท่านั้น และผู้เขียนคำโฆษณา - เอกสารประกอบ
- ลูกค้าจะทำความคุ้นเคยกับผลิตภัณฑ์สำเร็จรูปหลังจากการพัฒนาเสร็จสิ้น ดังนั้นเขาสามารถประเมินผลิตภัณฑ์ได้ก็ต่อเมื่อพร้อมเกือบสมบูรณ์แล้วเท่านั้น หากเขาไม่ชอบผลลัพธ์ ค่าใช้จ่ายของงบประมาณโครงการจะเพิ่มขึ้นอย่างชัดเจนเนื่องจากจำเป็นต้องแก้ไข
- ยิ่งมีเอกสารทางเทคนิคมากเท่าไหร่ การทำงานก็จะยิ่งใช้เวลานานขึ้นเท่านั้น เอกสารดังกล่าวต้องการการเปลี่ยนแปลงและการอนุมัติเพิ่มเติม
"น้ำตก" มักใช้ในโครงการในอุตสาหกรรมการแพทย์และการบินและอวกาศซึ่งมีเอกสารฐานกว้างอยู่แล้วซึ่งเป็นไปได้ที่จะกำหนดข้อกำหนดสำหรับซอฟต์แวร์ใหม่
เมื่อใช้โมเดลน้ำตก สิ่งสำคัญคือการเขียนข้อกำหนดโดยละเอียด ในระหว่างการทดสอบ ไม่ควรเปิดออกว่ามีข้อบกพร่องอยู่ที่ไหนสักแห่งที่ส่งผลเสียต่อโครงการทั้งหมด