กิจกรรมต่างๆ ที่มีโครงสร้างเป็นระบบ ที่จำเป็นในการพัฒนาระบบซอฟต์แวร์
มีเยอะแยะมากมาย แต่มีส่วนที่เหมือนกัน ได้แก่
- ข้อกำหนด (Specification) - การกำหนดสิ่งที่ระบบควรทำ
- การออกแบบและการสร้าง (Design and Implementation) - การกำหนดองค์ประกอบและการสร้างซอฟต์แวร์
- การตรวจสอบความถูกต้อง (Validation) - การตรวจสอบว่าซอฟต์แวร์ทำในสิ่งที่ลูกค้าต้องการ
- วิวัฒนาการ (Evolution) – การปรับเปลี่ยนซอฟต์แวร์เพื่อตอบสนองความต้องการของลูกค้าที่เปลี่ยนแปลงไป
เป็นตัวกำหนดนิยามกระบวนการผลิตซอฟต์แวร์ กล่าวถึงสิ่งต่อไปนี้
- กิจกรรมที่ต้องทำในการพัฒนาซอฟต์แวร์ เช่น การกำหนดนิยามข้อมูล ออกแบบส่วนติดต่อผู้ใช้ เป็นต้น
- ลำดับขั้นตอนในการพัฒนาซอฟต์แวร์
- ผลิตภัณฑ์ (Products) - เป็นผลผลิตที่ได้จากกระบวนการพัฒนา ประกอบด้วย อะไรบ้าง?
- บทบาท (Roles) – ระบุความรับผิดชอบของคนที่เกี่ยวข้องในกระบวนการ ประกอบด้วย ใครบ้าง?
- เงื่อนไขก่อนและหลัง (Pre- and post-conditions) – เป็นข้อความที่ระบุข้อเท็จจริงทั้งก่อนและหลังการดำเนินกระบวนการหรือการสร้างผลิตภัณฑ์ได้สำเร็จ
ในการพัฒนาซอฟต์แวร์ เราไม่สามารถบอกได้ชัดเจนว่า กระบวนการแบบใดถูกหรือผิด แต่... คุ้มค่า
- เวลาในการพัฒนา
- การบำรุงรักษา
- การบริการทรัพยากร เช่น programmer
เป็นโมเดลแบบ Plan-driven – มีการแยกส่วน specification และ development อย่างชัดเจน
- Requirements analysis and definition
- System and software design
- Implementation and unit testing
- Integration and system testing
- Operation and maintenance
ข้อจำกัดที่สำคัญของแบบจำลองน้ำตกคือ ความยากลำบากในการเปลี่ยนแปลงในขณะที่กระบวนการในแต่ละขั้นเริ่มดำเนินการไปแล้ว โดยหลักการแล้ว แต่ละ phase จะต้องเสร็จสมบูรณ์ก่อนจะก้าวสู่ phase ถัดไป
- ตอบสนองต่อการเปลี่ยนแปลงความต้องการของลูกค้าได้ยาก
- กระบวนการแบบน้ำตก จะใช้ได้ผลดี เมื่อรู้ความต้องการที่ชัดเจน
- ระบบส่วนใหญ่ มักจะไม่มีความต้องการที่ชัดเจนและตายตัว ดังนั้นจึงเป็นไปไม่ได้ ที่จะไม่มีการเปลี่ยนแปลงความต้องการ ในขณะที่กำลังดำเนินกระบวนการในขั้นตอนต่างๆ
- กระบวนการแบบน้ำตก นิยมใช้ในโครงการขนาดใหญ่
- อาจจะเป็นโครงการที่แยกส่วนย่อย เพื่อช่วยกันสร้างแล้วนำกลับมารวมกันในภายหลัง
- อาจจะใช้แนวทางที่เรียกว่า plan-driven ในการขับเคลื่อนระบบ
- อาจมีการทับซ้อนกันในส่วนของ Specification, development และ validation
- เป็นได้ทั้งแบบ plan-driven หรือ agile
- ค่าใช้จ่ายในการรองรับการเปลี่ยนแปลงความต้องการของลูกค้าจะลดลง
- ปริมาณของการวิเคราะห์และเอกสารที่จะต้องทำใหม่ในแต่ละขั้นตอน มีน้อยกว่าแบบจำลองน้ำตก
- สามารถที่จะรับข้อมูลป้อนกลับจากลูกค้าได้เร็วกว่าแบบจำลองน้ำตก
- ลูกค้าสามารถแสดงความคิดเห็น จากซอฟต์แวร์ต้นแบบได้ทันที และสามารถรับรู้ถึงความคืบหน้าในการพัฒนาซอฟต์แวร์ของตนเอง
- สามารถส่งซอฟต์แวร์ในส่วนที่สำคัญไปให้ลูกค้าใช้งานก่อน
- ลูกค้าได้รับประโยชน์จากเงินลงทุนได้เร็วกว่าแบบจำลองน้ำตก
- ไม่สามารถเห็นกระบวนการพัฒนาที่ชัดเจนได้
- ดูเหมือนว่าต้องมีการส่งมอบงานบ่อย (ใน intermediate version) เพื่อให้เห็นถึงความคืบหน้าของงาน
- การทำเอกสารที่สอดคล้องกับทุกรุ่นที่มีการเปลี่ยนแปลงทำได้ยากมาก และอาจจะไม่คุ้มทุน
- โครงสร้างของระบบ อาจจะแย่ลงเมื่อมีการเพิ่มเติมเนื้องานตามความต้องการมากขึ้น
- การทำ refactoring ในขณะปรับปรุงซอฟต์แวร์เป็นจำนวนรุ่นย่อย ๆ ที่มากเกินไป จะทำให้เกิดความสิ้นเปลืองเป็นอย่างมาก
- ถ้าทำเอกสารไม่ดี จะไม่สามารถติดตามการเปลี่ยนแปลงได้
- ระบบที่ถูกสร้างจากระบบที่มีอยู่ (ซึ่งถูกออกแบบให้เป็น component ที่ configurable)
- เป็นได้ทั้งแบบ plan-driven หรือ agile
- กระบวนการนี้ จะอยู่บนพื้นฐาน software reuse โดยทั้งระบบจะเป็นการนำ software ที่มีอยู่แล้วมาทำการ config เพื่อให้เข้ากับความต้องการของลูกค้า
- บางที่จะเรียกว่า COTS ย่อมาจาก Commercial-off-the-shelf
- ชิ้นส่วนของ software จะถูก configured เสียใหม่ เพื่อให้มี behaviour และ functionality ที่ตรงตาม requirement ของผู้ใช้
- ปัจจุบันถือว่า reuse เป็นวิธีการมาตรฐานอย่างหนึ่งในการพัฒนาซอฟต์แวร์
- เราจะเรียนในสัปดาห์ที่ 9 เรื่องการเขียนซอฟต์แวร์ให้ใช้ได้ใหม่ (Software Reuse)
- Application แบบ Stand-alone (บางทีก็เรียก COTS) เป็นระบบที่นำซอฟต์แวร์สำเร็จ มาconfigured ใหม่ เพื่อให้เข้ากับสภาพแวดล้อมที่ลูกค้าต้องการ
- Collections ของ objects หรือชิ้นส่วนซอฟต์แวร์ ที่ถูกพัฒนาขึ้น เพื่อทำงานร่วมกับ component framework เช่น .NET หรือ J2EE
- Web services ที่ถูกพัฒนาขึ้นตาม service standards และสามารถถูกเรียกใช้จากระยะไกล ผ่านเว็บบราวเซอร์ หรือระบบอื่น ๆ
- กำหนดความต้องการ (Requirements specification)
- ค้นหาและประเมินซอฟต์แวร์ที่มีอยู่แล้ว (Software discovery and evaluation)
- ปรับปรุงความต้องการ (Requirements refinement) ให้สอดคล้องกับซอฟต์แวร์ที่มีอยู่
- ปรับแต่งซอฟต์แวร์ (Application system configuration)
- ปรับแต่งและรวมชิ้นส่วนซอฟต์แวร์ (Component adaptation and integration)
- Advantages
- ลดต้นทุนและความเสี่ยง เนื่องจากพัฒนาซอฟต์แวร์ขึ้นใหม่เป็นจำนวนน้อย
- ส่งมอบได้เร็ว
- disadvantages
- อาจจะไม่ตรงกับความต้องการทั้งหมด/ที่แท้จริงของผู้ใช้
- อาจจะต้องทำ refinement หรือ develop บางชิ้นส่วนของซอฟต์แวร์ใหม่
- ไม่สามารถควบคุม evolution หรือการ reused ของชิ้นส่วน
- บางชิ้นส่วนที่ถูกแก้ไขโดยเจ้าของ อาจไม่ backward compatible กับรุ่นที่เรานำมาปรับใช้
ในทางปฏิบัติ ระบบขนาดใหญ่ถูกพัฒนาขึ้นจากกระบวนการที่หลากหลายและอาจจะใช้ทุกแบบจำลองที่มีอยู่
- ทรัพยากรที่มีจำกัดคือ คน การเลือกใช้โมเดลใดมักจะขึ้นอยู่กับความเชี่ยวชาญของคนเป็นปัจจัยหลัก