การพัฒนาซอฟต์แวร์อย่างยืดหยุ่น

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

๑. พัฒนาต้นแบบซอฟต์แวร์ก่อน 

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

๒. พัฒนาซอฟต์แวร์แบบต่อเติม 

      การพัฒนาซอฟต์แวร์แบบต่อเติม (Incremental mode) เป็นวิธีที่จะทำให้ได้รับซอฟต์แวร์โดยเร็ว ถ้าผู้ใช้ต้องการซอฟต์แวร์ที่ทำงานได้ ๑๐ หน้าที่ก็อาจเริ่มพัฒนาซอฟต์แวร์ที่ทำงานได้ ๑-๒ หน้าที่ก่อนแล้วจึงนำไปทดลองใช้ ถ้ายังไม่พอใจก็ค่อย ๆ แก้ไขจนกว่าจะพอใจแล้วจึงเพิ่มหน้าที่อื่น ๆ สลับกับการทดลองใช้เป็นระยะ ๆ ซอฟต์แวร์ที่ได้มักได้รับการยอมรับจากผู้ใช้แต่ไม่สามารถกำหนดเวลาที่จะเสร็จได้แน่นอนเพราะความต้องการของผู้ใช้เปลี่ยนแปลงไปได้ทุกระยะ 

๓. พัฒนาซอฟต์แวร์แบบวนเวียน 

วิธีการพัฒนาแบบ "วนเวียน" (spiral model) นี้จะวนเวียนอยู่ระหว่าง
      (๑) ตั้งเป้าหมาย ดูทางเลือก และข้อจำกัด 
      (๒) ทดลองทำและวิเคราะห์แม่แบบแบบวนเวียนความเสี่ยง
      (๓) ทำจริงและ 
      (๔) ประเมินผลและวางแผนช่วงต่อไป 

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

๔. เน้นพัฒนาข้อกำหนดซอฟต์แวร์ 

      วิธีนี้จะเน้นการเขียนข้อกำหนดซอฟต์แวร์ไว้อย่างชัดเจนมากจนกระทั่งในบางกรณีวิธีนี้ทำให้คอมพิวเตอร์สามารถเขียนชุดคำสั่งที่ต้องใช้แทนมนุษย์ได้เลย  วิธีนี้ถูกใช้ในซอฟต์แวร์ที่ต้องเน้นความปลอดภัย เช่น ซอฟต์แวร์ที่ใช้บริหารการสับหลีกรถไฟซึ่งถ้าพลาดแล้วอาจทำให้ผู้โดยสารเสียชีวิตได้จึงมีความสำคัญมากที่ต้องพิสูจน์ว่าข้อกำหนดซอฟต์แวร์ไม่มีความผิดพลาดอย่างแน่นอน ในกรณีเช่นนี้การเขียนข้อกำหนดซอฟต์แวร์ที่เป็นคำอธิบายทั่ว ๆ ไปจะไม่สามารถพิสูจน์ความถูกต้องได้  ดังนั้นจึงต้องเขียนข้อกำหนดในเชิงคณิตศาสตร์และพิสูจน์ความถูกต้องทางคณิตศาสตร์ให้ได้ แต่การเขียนข้อกำหนดในเชิงคณิตศาสตร์ค่อนข้างจะยากมากวิธีนี้จึงยังไม่เป็นที่นิยมในประเทศไทย 
      อีกวิธีหนึ่งเป็นการใช้ซอฟต์แวร์ประเภทที่มีเครื่องมือช่วยสร้างโปรแกรมได้โดยอัตโนมัติส่วนใหญ่เป็นซอฟต์แวร์ที่ใช้งานในสำนักงานทั่ว ๆ ไป เช่น งานการเงินการบัญชี งานจัดซื้อจัดจ้าง ฯลฯ ซึ่งมีหลักการทำงานที่ชัดเจนอยู่แล้ว  ในบางกรณีโปรแกรมที่ทำหน้าที่ (function) ในรายละเอียดมีอยู่ครบแล้วแต่ละองค์กรสามารถเลือกได้ว่าจะเก็บโปรแกรมที่มีหน้าที่ใดเอาไว้และต้องปรับในส่วนใด เพื่อให้ได้ซอฟต์แวร์ที่เหมาะสมเฉพาะองค์กร (customized)