7​ ​ขั้น​ตอน​ของ​ ​Software​ ​Development​ ​Life​ ​Cycle​ ​และ​สิ่ง​ที่​ควร​ส่ง​มอบ​ใน​แต่ละ​ช่วง

การแบ่ง ขั้นตอน SDLC เป็นเจ็ดช่วงช่วยให้คนต่างหน้าที่เห็นว่าต้องตัดสินใจและส่งต่อข้อมูลใดบ้าง รายการนี้เป็นกรอบอธิบาย ไม่ใช่กฎว่าทุกโครงการต้องมีเอกสารหนาเท่ากัน หรือห้ามย้อนกลับไปแก้งานช่วงก่อน

1–2 วางแผนและวิเคราะห์ความต้องการ

Planning ระบุปัญหา เป้าหมาย ผู้ใช้ ขอบเขต งบและความเสี่ยง สิ่งส่งมอบอาจเป็น Project Brief สั้น ๆ ที่บอกว่าอะไรอยู่และไม่อยู่ในรอบนี้ Requirement Analysis ตรวจขั้นตอนงานจริง คำศัพท์ของแต่ละฝ่าย กฎธุรกิจ และกรณีผิดปกติ สิ่งส่งมอบอาจเป็นรายการความต้องการพร้อมตัวอย่างและเกณฑ์รับงาน

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

ภาพที่ 1: แต่ละช่วงควรส่งต่อข้อสรุปที่ตรวจได้ พร้อมช่องให้ย้อนกลับเมื่อพบข้อมูลใหม่

3–4 ออกแบบและพัฒนา

Design กำหนดเส้นทางผู้ใช้ โครงสร้างข้อมูล สิทธิ์ อินเทอร์เฟซ และการเชื่อมต่อ สิ่งส่งมอบอาจเป็นภาพหน้าจอ แผนภาพสถานะ ER Diagram หรือสัญญา API เท่าที่ปัญหาต้องใช้ Development แปลงแบบเป็นซอฟต์แวร์ที่ทำงานได้ ควรมีโค้ดที่ตรวจร่วมกัน การตั้งค่าที่จัดการปลอดภัย และวิธีรันในสภาพแวดล้อมทดสอบ

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

5–7 ทดสอบ เปิดใช้ และดูแลรักษา

Testing ตรวจว่าระบบตรง Requirement และรับมือข้อมูลผิด กรณีปฏิเสธสิทธิ์ และส่วนที่อาจเสียจากการแก้ สิ่งส่งมอบคือผลทดสอบและข้อบกพร่องที่ยังเหลือ Deployment เปิดใช้พร้อมแผนย้ายข้อมูล ตรวจระบบ และวิธีกลับเมื่อมีปัญหา สิ่งส่งมอบคือระบบที่เข้าถึงได้และบันทึกการเปิดใช้ Maintenance ดูเหตุขัดข้อง แก้บั๊ก ปรับตามความต้องการใหม่ และติดตามความเสี่ยง สิ่งส่งมอบคือบันทึกการเปลี่ยนแปลงและสถานะการดูแล

ตัวอย่างสมมติและเกณฑ์ตรวจ

สำหรับระบบอนุมัติคำขอ Requirement อาจระบุว่า “ผู้ตรวจอนุมัติได้เฉพาะคำขอในทีม” แบบต้องมีความสัมพันธ์ระหว่างคำขอกับทีม โค้ดต้องตรวจสิทธิ์ที่เซิร์ฟเวอร์ และการทดสอบต้องลองส่งคำขอข้ามทีม หลังเปิดใช้ควรมีวิธีตรวจเหตุการณ์ถูกปฏิเสธผิดปกติ นี่คือเส้นเชื่อมงานหนึ่งข้อผ่านหลายช่วงของ SDLC

ในการทำรายงาน อาจจัดตารางสี่คอลัมน์: ช่วงงาน วัตถุประสงค์ สิ่งส่งมอบ และเกณฑ์ยอมรับ ระบุสิ่งที่ทำแล้วกับสิ่งที่ยังเป็นข้อเสนอแยกกัน เพราะรายการเอกสารที่ “ควรมี” ไม่ได้พิสูจน์ว่าโครงการจริงได้ทำครบ

อ่าน ภาพรวม SDLC และ Requirement Analysis ก่อนกำหนดขอบเขต Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ ตารางช่วงงานพร้อม Requirement, แบบออกแบบ, โค้ด, ผลทดสอบ และบันทึกเปิดใช้ ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• IBM: What is the software development life cycle? — ตัวอย่างการแบ่งเจ็ดช่วงและสิ่งส่งมอบ
• ISO/IEC/IEEE 29148: Requirements engineering — บทบาทของข้อกำหนดที่ตรวจสอบได้