การพัฒนาซอฟต์แวร์อย่างยืดหยุ่น
แม่แบบแบบขั้นน้ำตกนี้จัดว่าเป็น แม่แบบของกระบวนการการพัฒนาซอฟต์แวร์ (Software development model) แบบแรกของโลก จึงมีผู้ใช้กันแพร่หลายทั่วโลก แต่เมื่อผ่านไปหลายสิบปี ผู้ใช้หลายคนพบว่า โครงการพัฒนาซอฟต์แวร์ใหญ่ๆ หลายโครงการ ที่ใช้แม่แบบแบบนี้ประสบความล้มเหลวได้ง่าย ปัญหาที่เด่นชัดที่สุดคือ ผู้ใช้ไม่ทราบว่า ตนเองต้องการอะไร และมักจะเปลี่ยนแปลงข้อกำหนดของซอฟต์แวร์บ่อยๆ
เมื่อมีการว่าจ้างให้พัฒนาซอฟต์แวร์ ผู้ว่าจ้างมักจะเซ็นชื่อรับรองว่า นี่คือ ข้อกำหนดซึ่งตรงกับที่เขาต้องการแล้ว แต่ปรากฏว่า เมื่อผู้พัฒนาซอฟต์แวร์ทำงานเสร็จเรียบร้อยตรงตามข้อกำหนดของผู้ว่าจ้างอย่างเคร่งครัด แต่ความต้องการของผู้ว่าจ้างกลับเปลี่ยนไป ผลก็คือ ผู้ว่าจ้างไม่ยอมตรวจรับงาน และไม่ยอมจ่ายเงิน หรือขอให้แก้ไขซอฟต์แวร์ จนกว่าจะพอใจ และถึงแม้ว่าจะยอมจ่ายเงิน ผู้ว่าจ้างก็ไม่สามารถนำซอฟต์แวร์ไปใช้ประโยชน์ตามที่ต้องการได้ ปัญหานี้เคยทำให้โครงการซอฟต์แวร์ระดับพันล้านบาทของไทยต้องล้มเหลว เนื่องจากไม่มีใครกล้าเซ็นรับรองเอกสาร ที่ระบุข้อกำหนดความต้องการของผู้ใช้ และเอกสารที่ระบุคุณลักษณะซอฟต์แวร์
การพัฒนาซอฟต์แวร์ตามแม่แบบแบบขั้นน้ำตก เปรียบเทียบได้กับการวัดตัวเด็กเล็ก เพื่อใช้ตัดเสื้อหลายสิบตัว แต่รอส่งมอบพร้อมกันทุกตัว ซึ่งต้องใช้เวลานานหลายเดือน กว่าจะได้เสื้อ เด็กก็โตขึ้นแล้ว เสื้อจึงคับไป ทั้งที่ช่างได้ตัดเสื้อตามขนาดที่วัดไว้ทุกอย่าง หากไม่มีการว่าจ้างต่อเนื่อง เพื่อให้ช่างแก้เสื้อให้มีขนาดที่เด็กสามารถใส่ได้ ผู้ว่าจ้างก็จะเสียเงินโดยเปล่าประโยชน์
ผลการวัดตัวเด็กเปรียบเสมือนข้อกำหนดของซอฟต์แวร์ ตัวเด็กก็เสมือนองค์กร ที่ว่าจ้างพัฒนาซอฟต์แวร์ ดังนั้น วิธีการว่าจ้างพัฒนาซอฟต์แวร์โดยมีข้อกำหนดซอฟต์แวร์เสร็จสมบูรณ์ตายตัว ก่อนจะเริ่มว่าจ้างพัฒนาระบบ ซึ่งเป็นวิธีที่ยึดถือปฏิบัติในปัจจุบัน จึงไม่สอดคล้องกับวิวัฒนาการของซอฟต์แวร์ เนื่องจากความต้องการของผู้ใช้ซอฟต์แวร์นั้น เปลี่ยนไปได้ทุกระยะ และโจทย์ปัญหาที่ตั้งใจจะให้พัฒนาซอฟต์แวร์ ก็เปลี่ยนไปได้ทุกระยะเช่นกัน
ดังนั้น ในทางปฏิบัติ ผู้พัฒนาซอฟต์แวร์ทั้งหลายจึงหันมาหาแนวทางใหม่ๆ ที่จะทำให้การพัฒนาซอฟต์แวร์ตรงตามที่ผู้ใช้ต้องการ มีความยืดหยุ่น และสอดคล้องกับวิวัฒนาการของซอฟต์แวร์มากขึ้น ตัวอย่างได้แก่
๑. พัฒนาต้นแบบซอฟต์แวร์ก่อน
การเน้นการพัฒนาต้นแบบ (prototype) ของซอฟต์แวร์ เหมาะสำหรับซอฟต์แวร์ที่ผู้ใช้ก็ไม่ค่อยจะแน่ใจว่า ตนเองต้องการอะไร หรือซอฟต์แวร์ประเภทใหม่ที่อยู่ในช่วงการทำวิจัย และพัฒนา หรือซอฟต์แวร์ที่เน้นการออกแบบวิธีการติดต่อกับผู้ใช้ (User Interface) เป็นหลัก เมื่อผู้ใช้เห็นต้นแบบแล้ว จึงเริ่มวิเคราะห์ได้ว่า เขาชอบส่วนใด หรือไม่ชอบส่วนใด ประสิทธิภาพของวิธีการที่ใช้ในซอฟต์แวร์มีข้อดี หรือข้อเสียอย่างไร ผู้พัฒนาต้นแบบอาจลองผิดลองถูกจนกว่าข้อกำหนดซอฟต์แวร์จะเกิดความชัดเจนได้ในที่สุด ปัญหาคือต้นแบบประเภทนี้ทำนุบำรุงยาก เพราะการลองผิดลองถูกมักทำให้ชุดคำสั่งภายในซับซ้อน ดังนั้น ถ้าใช้วิธีนี้ก็ต้องทิ้งซอฟต์แวร์ต้นแบบ แล้วเริ่มต้นพัฒนาซอฟต์แวร์ขึ้นมาใหม่
๒. พัฒนาซอฟต์แวร์แบบต่อเติม
การพัฒนาซอฟต์แวร์แบบต่อเติม (Incremental mode) เป็นวิธีที่จะทำให้ได้รับซอฟต์แวร์โดยเร็ว ถ้าผู้ใช้ต้องการซอฟต์แวร์ที่ทำงานได้ ๑๐ หน้าที่ ก็อาจเริ่มพัฒนาซอฟต์แวร์ที่ทำงานได้ ๑-๒ หน้าที่ก่อน แล้วจึงนำไปทดลองใช้ ถ้ายังไม่พอใจก็ค่อยๆ แก้ไข จนกว่าจะพอใจ แล้วจึงเพิ่มหน้าที่อื่นๆ สลับกับการทดลองใช้เป็นระยะๆ ซอฟต์แวร์ที่ได้มักได้รับการยอมรับจากผู้ใช้ แต่ไม่สามารถกำหนดเวลาที่จะเสร็จได้แน่นอน เพราะความต้องการของผู้ใช้เปลี่ยนแปลงไปได้ทุกระยะ
๓. พัฒนาซอฟต์แวร์แบบวนเวียน
วิธีการพัฒนาแบบ "วนเวียน" (spiral model) นี้ จะวนเวียนอยู่ระหว่าง
(๑) ตั้งเป้าหมาย ดูทางเลือก และข้อจำกัด
(๒) ทดลองทำ และวิเคราะห์แม่แบบแบบวนเวียนความเสี่ยง
(๓) ทำจริง และ
(๔) ประเมินผล และวางแผนช่วงต่อไป
วิธีนี้จะเน้นเรื่องการวิเคราะห์ความเสี่ยงในช่วงที่ ๒ ซึ่งการวิเคราะห์ความเสี่ยง (risk-analysis) เป็นการวิเคราะห์ว่า ในการพัฒนาซอฟต์แวร์มีปัญหาอะไรบ้าง แต่ละปัญหาอาจส่งผลกระทบรุนแรงในระดับใด และมีโอกาสเกิดขึ้นได้มากเพียงใด แล้วรีบจัดการกับปัญหาที่มีโอกาสเกิดขึ้น และมีผลกระทบสูงก่อน ปัญหาดังกล่าวไม่จำเป็นว่า จะต้องเป็นปัญหาทางด้านเทคนิค แต่อาจจะเป็นปัญหาในการบริหารงานโครงการ ปัญหาเรื่องคน ฯลฯ เพื่อให้โครงการประสบความสำเร็จได้มากขึ้น ตัวอย่างเช่น หัวหน้าโครงการกำลังคิดจะลาอออก ซึ่งถ้าลาออกจริง โครงการก็จะล้มเหลว การเจรจากับหัวหน้าโครงการจึงเป็นเรื่องเร่งด่วนกว่าเรื่องเทคนิคทั้งหมด
รูปแบบการพัฒนาแบบนี้จะมีความยืดหยุ่นมาก การพัฒนาซอฟต์แวร์ในโครงการเดียวกัน อาจผสมการพัฒนาต้นแบบ และการพัฒนาแบบต่อเติมด้วย หรือเสริมให้แต่ละขั้นตอนที่ระบุไว้ของแม่แบบแบบขั้นน้ำตก มีการวนเวียน ในลักษณะวางแผน-ทดลอง-ทำ-ประเมิน ก็ได้ เพราะจะช่วยให้พบข้อผิดพลาดได้ตั้งแต่ระยะเริ่มแรก
ในประเทศญี่ปุ่นพบว่า การพัฒนาซอฟต์แวร์ จะใช้เวลาน้อยลง หากใช้รูปแบบการพัฒนาซอฟต์แวร์แบบนี้ พร้อมกับมีคลังซอฟต์แวร์ชิ้นส่วน (Software components) ด้วย เพราะเมื่อผู้พัฒนาซอฟต์แวร์ต้องการจะเพิ่มหน้าที่บางอย่างให้แก่ซอฟต์แวร์ เขาก็ต้องพิจารณาก่อนว่า ซอฟต์แวร์ชิ้นส่วนที่ทำหน้าที่ที่ต้องการได้ มีอยู่แล้วหรือไม่ ถ้ามีก็เอามาใช้ได้เลย โดยไม่ต้องพัฒนาขึ้นมาใหม่
๔. เน้นพัฒนาข้อกำหนดซอฟต์แวร์
วิธีนี้จะเน้นการเขียนข้อกำหนดซอฟต์แวร์ไว้อย่างชัดเจนมาก จนกระทั่งในบางกรณี วิธีนี้ทำให้คอมพิวเตอร์สามารถเขียนชุดคำสั่ง ที่ต้องใช้แทนมนุษย์ได้เลย
วิธีนี้ถูกใช้ในซอฟต์แวร์ที่ต้องเน้นความปลอดภัย เช่น ซอฟต์แวร์ที่ใช้บริหารการสับหลีกรถไฟ ซึ่งถ้าพลาดแล้ว อาจทำให้ผู้โดยสารเสียชีวิตได้ จึงมีความสำคัญมาก ที่ต้องพิสูจน์ว่า ข้อกำหนดซอฟต์แวร์ไม่มีความผิดพลาดอย่างแน่นอน ในกรณีเช่นนี้ การเขียนข้อกำหนดซอฟต์แวร์ ที่เป็นคำอธิบายทั่วๆ ไป จะไม่สามารถพิสูจน์ความถูกต้องได้ ดังนั้น จึงต้องเขียนข้อกำหนดในเชิงคณิตศาสตร์ และพิสูจน์ความถูกต้องทางคณิตศาสตร์ให้ได้ แต่การเขียนข้อกำหนดในเชิงคณิตศาสตร์ ค่อนข้างจะยากมาก วิธีนี้จึงยังไม่เป็นที่นิยม ในประเทศไทย
อีกวิธีหนึ่งเป็นการใช้ซอฟต์แวร์ประเภทที่มีเครื่องมือช่วยสร้างโปรแกรมได้โดยอัตโนมัติ ส่วนใหญ่เป็นซอฟต์แวร์ที่ใช้งานในสำนักงานทั่วๆ ไป เช่น งานการเงินการบัญชี งานจัดซื้อจัดจ้าง ฯลฯ ซึ่งมีหลักการทำงานที่ชัดเจนอยู่แล้ว ในบางกรณี โปรแกรมที่ทำหน้าที่ (function) ในรายละเอียดมีอยู่ครบแล้ว แต่ละองค์กรสามารถเลือกได้ว่า จะเก็บโปรแกรมที่มีหน้าที่ใดเอาไว้ และต้องปรับในส่วนใด เพื่อให้ได้ซอฟต์แวร์ ที่เหมาะสมเฉพาะองค์กร (customized)