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

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

ขั้นตอนการพัฒนาซอฟต์แวร์

    การจัดสร้างซอฟต์แวร์ต่าง ๆ นั้น เราต้องดำเนินการเป็นขั้นตอนที่เรียกว่า วัฏจักรของซอฟต์แวร์ ซึ่งแบ่งออกเป็นหลายขั้นตอน ดังนี้

1. ศึกษาความต้องการ (Requirements)
2. ขั้นวิเคราะห์และกำหนดคุณลักษณะของซอฟต์แวร์ (Specification)
3. วางแผน (Planning)
4. ออกแบบ (Design)
5. เขียนรหัสคำสั่ง (Implementation)
6. ทดสอบ (Testing)
7. รวบรวมหน่วยย่อยต่าง ๆ เป็นระบบซอฟต์แวร์ (Integration)
8. บำรุงรักษาซอฟต์แวร์ (Maintenance)

    ขั้นตอนในการพัฒนาซอฟต์แวร์สามารถแบ่งเป็นขั้นตอนใหญ่ ๆ ได้ 3 ขั้นตอน คือ ขั้นตอนเกี่ยวกับกำหนดความต้องการ (Requirements and Specification) ขั้นตอนพัฒนาโปรแกรม (Planning, Design, Implementation, Testing and Integration) และขั้นตอนเกี่ยวกับการบำรุงรักษาซอฟต์แวร์(Maintenance) ในระหว่างใช้งาน ดังรูป

แสดงวงจรการพัฒนาซอฟต์แวร์

ลักษณะการออกแบบที่ดี

    การออกแบบที่ดีควรยึดคุณสมบัติให้สามารถปรับปรุงแก้ไขได้ทุกขั้นตอน และการแก้ไขนั้น ๆ ให้มีผลกระทบกับส่วนอื่น ๆ น้อยที่สุดเพราะไม่ว่าจะคิดออกแบบ รูปแบบใด ๆ ก็ตาม โอกาสที่มีข้อผิดพลาดย่อมเกิดขึ้นได้เสมอ ดังนั้นการออกแบบจึงต้องมี ลักษณะที่เอื้อต่อการปรับปรุงได้ตลอดเวลา ปัจจัยที่เอื้อต่อการปรับปรุงแก้ไขมี 2 ประการ คือ

• ความเป็นโมดุล (Modularity)
• ระดับความเป็นนามธรรม (Level of Abstraction)

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

    เมื่อพิจารณาความเป็นโมดุลร่วมกับความเป็นนามธรรม จะพบว่าโมดุลที่อยู่ระดับ สูงกว่า      ย่อมเป็นนามธรรมมากกว่าโมดุลที่อยู่ระดับต่ำกว่า โมดุลที่อยู่ระดับต่ำกว่าจะมี รายละเอียดมาก และเป็นรูปธรรมมากกว่าโมดุลที่อยู่ระดับสูงกว่า ซึ่งมีความเป็นนามธรรมมากกว่า เช่น มีการซ่อนข้อมูล (Information Hiding) มากขึ้น

    ลักษณะการออกแบบที่ดีคือการทำกิจกรรมให้เป็นโมดุลโดยมีระดับนามธรรม น้อยที่สุด โดยใช้กลยุทธ์ในการออกแบบดังนี้

• จัดโมดุลให้มีความเกาะยึดสูง
• จัดโมดุลให้มีความสัมพันธ์ต่ำ
• จัดขนาดโมดุลไม่ให้ใหญ่หรือเล็กเกินไป
• จัดโมดุลให้มีผลลัพธ์ส่งออกจำนวนน้อย (Fan-out ต่ำ) และมีข้อมูลส่งเข้า จำนวนมาก (Fan-in สูง)

วัฏจักรของซอฟต์แวร์ (Software Life Cycle)

    รูปแบบวงจรชีวิตของซอฟต์แวร์มีจำนวนมาก ที่นิยมใช้กันกว้างขวางที่สุดมี 2 แบบ คือ Waterfall Model และ Rapid Prototyping Model นอกจากสองแบบนี้แล้ว ในปัจจุบันยังมีอีกรูปแบบหนึ่งซึ่งกำลังเป็นที่สนใจอย่างมากคือ Spiral Model และเมื่อพิจารณาถึงข้อดีข้อเสียของทั้ง 3 แบบแล้ว รูปแบบอื่นก็ควรจะต้องกล่าวถึงด้วย นั่นคือ แบบ Incremental Model และแบบที่ไม่ได้รับความนิยมเลยคือ Build-and-Fix Model

Build-and Fix Model

ภาพเปรียบเทียบค่าใช้จ่ายขั้นตอนต่าง ๆ ของ Build-and-fix Model

Waterfall Model

Rapid Prototyping Model

Incremental Model

Sprial Model

ศึกษาเนื้อหาโดยละเอียดได้จากหนังสือเสริม ....