แนวปฏิบัติการควบคุมกระบวนการพัฒนาระบบสารสนเทศตาม ISO/IEC 29110

งานพัฒนาระบบสารสนเทศ สำนักวิทยบริการและเทคโนโลยีสารสนเทศ

มหาวิทยาลัยเทคโนโลยีราชมงคลล้านนา

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

งานพัฒนาระบบสารสนเทศ สำนักวิทยบริการและเทคโนโลยีสารสนเทศ มหาวิทยาลัยเทคโนโลยีราชมงคลล้านนา จึงนำแนวทางของ ISO/IEC 29110 มาใช้เป็นกรอบในการควบคุมกระบวนการพัฒนาระบบสารสนเทศ ตั้งแต่เริ่มต้นโครงการจนถึงการส่งมอบและปิดโครงการ

ISO/IEC 29110 ไม่ใช่เพียงการจัดทำเอกสาร

หัวใจสำคัญของการนำมาตรฐานมาใช้ คือการทำให้กระบวนการพัฒนาระบบสามารถตอบคำถามสำคัญได้ว่า

ใครร้องขอ → ต้องการอะไร → ใครรับผิดชอบ → ออกแบบและพัฒนาอย่างไร → ตรวจสอบอย่างไร → ใครรับรอง → ส่งมอบอะไร

ดังนั้น Work Product ของ ISO/IEC 29110 จึงควรถูกมองว่าเป็น ผลผลิตและหลักฐานในการควบคุมกระบวนการ (Process Control Evidence) มากกว่าการเป็นเอกสารที่จัดทำขึ้นเพื่อรองรับการตรวจประเมินเท่านั้น

กระบวนการพัฒนาระบบสารสนเทศ

แนวทางการดำเนินงานสามารถสรุปเป็นวงจรได้ดังนี้

Request → Agreement → Plan → Requirement → Design → Develop → Test → UAT → Release → Acceptance → Maintenance

โดยระหว่างกระบวนการจะมีการควบคุมเรื่อง Progress, Risk, Change, Correction, Version Control, Traceability และ Repository ควบคู่กันไปตลอดโครงการ

1. เริ่มต้นและกำหนดขอบเขตโครงการ

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

Work Product สำคัญ เช่น

1. Agreement / Statement of Work - กำหนดขอบเขตและข้อตกลงของโครงการ
2. Project Plan - กำหนดแผนงาน ระยะเวลา ทีมงาน ทรัพยากร ความเสี่ยง และสิ่งส่งมอบ
3. Meeting Record - บันทึกข้อตกลง การตัดสินใจ และงานที่ต้องดำเนินการต่อ

จุดประสงค์คือทำให้ทีมพัฒนาและหน่วยงานเจ้าของระบบมีความเข้าใจตรงกันก่อนเริ่มดำเนินงาน

2. วิเคราะห์และยืนยันความต้องการ

ความต้องการของผู้ใช้งานจะถูกนำมาวิเคราะห์และจัดทำเป็น Requirements Specification (SRS) เพื่อกำหนดว่าระบบต้องสามารถทำอะไรได้บ้าง รวมถึงข้อกำหนดด้านการทำงาน ความปลอดภัย ประสิทธิภาพ และข้อจำกัดต่าง ๆ

Requirement ที่กำหนดไว้อย่างชัดเจนจะกลายเป็น Baseline สำหรับการออกแบบ พัฒนา และทดสอบระบบในขั้นตอนต่อไป

3. ออกแบบระบบก่อนการพัฒนา

Requirement ที่ได้รับการยืนยันจะถูกนำมาจัดทำ Software Design (SDS) เช่น

Architecture, Module, Database, ER Diagram, API, User Interface, Workflow และ Security Design

แนวทางนี้ช่วยลดความคลาดเคลื่อนระหว่าง Requirement กับ Software ที่พัฒนาขึ้น และทำให้ Developer มีแบบอ้างอิงร่วมกัน

4. พัฒนาและควบคุม Software

การพัฒนาระบบต้องมีการควบคุม Source Code และ Software Components ด้วย Version Control เช่น Git รวมถึงกำหนด Development, Testing และ Production Environment ให้ชัดเจน

การเปลี่ยนแปลง Source Code ควรสามารถตรวจสอบย้อนหลังได้ว่า

ใครแก้ไข → แก้ไขอะไร → เมื่อใด → เกี่ยวข้องกับ Requirement หรือ Issue ใด

5. Verification และ Validation

หนึ่งในกลไกสำคัญของกระบวนการคือการแยกระหว่าง Verification และ Validation

Verification — “เราทำสิ่งนั้นถูกต้องตามข้อกำหนดหรือไม่?”

เป็นการตรวจสอบภายใน เช่น Project Plan ครบถ้วนหรือไม่, SRS มี Requirement ครบหรือไม่, SDS ออกแบบสอดคล้องกับ SRS หรือ Test Case ครอบคลุม Requirement หรือไม่

ส่วน

Validation — “สิ่งที่เราทำตรงกับสิ่งที่ผู้ใช้งานต้องการจริงหรือไม่?”

เป็นการยืนยันร่วมกับหน่วยงานเจ้าของระบบ เช่น การรับรอง Requirement, Design และการทำ User Acceptance Test (UAT)

จึงช่วยลดความเสี่ยงของการพัฒนาระบบที่ “ถูกต้องตามแบบ แต่ไม่ตรงกับความต้องการของผู้ใช้งาน”

6. การทดสอบ Software

ก่อนนำระบบไปใช้งานจริง ต้องกำหนด Test Cases และ Test Procedures ที่สามารถตรวจสอบผลได้

การทดสอบอาจประกอบด้วย Unit Test, Integration Test, System Test และ User Acceptance Test ตามความเหมาะสมของโครงการ

ผลการทดสอบต้องสามารถระบุได้ว่า

Expected Result → Actual Result → Pass/Fail → Defect → Correction → Retest

เพื่อให้มีหลักฐานว่าระบบผ่านเกณฑ์คุณภาพก่อนนำไปใช้งานจริง

7. การควบคุมการเปลี่ยนแปลงและปัญหา

Requirement สามารถเปลี่ยนแปลงได้ระหว่างโครงการ แต่การเปลี่ยนแปลงต้องได้รับการควบคุมผ่าน Change Request

ก่อนดำเนินการต้องพิจารณาผลกระทบ เช่น

Scope / Schedule / Cost / Technical / Requirement / Testing

ขณะที่ปัญหาหรือข้อผิดพลาดที่พบระหว่างดำเนินงานจะถูกติดตามผ่าน Correction Register เพื่อให้ทุกปัญหามีผู้รับผิดชอบ วิธีแก้ไข และสถานะที่ตรวจสอบได้

8. Traceability — การสอบกลับได้

Requirement แต่ละข้อควรสามารถตรวจสอบย้อนกลับได้ตลอดกระบวนการ เช่น

Requirement → Design → Software Component → Test Case → Test Result → UAT

โดยใช้ Traceability Record หรือ Requirement Traceability Matrix (RTM) เป็นเครื่องมือเชื่อมโยง

ตัวอย่าง

REQ-001 → SDS-01 → MODULE-01 → TC-001 → PASS → UAT-001

ทำให้สามารถตรวจสอบได้ว่า Requirement ทุกข้อได้รับการออกแบบ พัฒนา และทดสอบครบถ้วน

9. การส่งมอบและการดูแลรักษา

Software Product ที่ส่งมอบไม่ควรประกอบด้วยโปรแกรมเพียงอย่างเดียว แต่ควรมีองค์ความรู้ที่จำเป็นสำหรับการใช้งานและดูแลระบบ เช่น

1. Software User Documentation — คู่มือสำหรับผู้ใช้งาน
2. Product Operation Guide — คู่มือสำหรับผู้ดูแลระบบ
3. Maintenance Documentation — คู่มือสำหรับบำรุงรักษาและพัฒนาระบบต่อ
4. Software Product — Software Release ที่ผ่านกระบวนการทดสอบและรับรอง
5. Acceptance Record — หลักฐานการตรวจรับและส่งมอบ

ทำให้ระบบสามารถใช้งานและดูแลต่อได้ แม้มีการเปลี่ยนแปลงผู้รับผิดชอบในอนาคต

การควบคุม Work Product

เพื่อให้ Work Product สามารถนำมาใช้ควบคุมโครงการได้จริง ควรกำหนดข้อมูลสำคัญอย่างน้อย 5 ส่วนในแต่ละรายการ ได้แก่

ตัวอย่างเช่น Requirements Specification (SRS) อาจกำหนดให้ System Analyst เป็น Owner, Project Manager เป็น Reviewer, หน่วยงานเจ้าของระบบเป็นผู้ Validation/รับรอง และจัดเก็บฉบับที่ผ่านการควบคุมไว้ใน Baseline Repository

แนวทางนี้ทำให้ Work Product แต่ละรายการมี เจ้าของ มีผู้ตรวจ มีช่วงเวลาที่ชัดเจน และรู้ว่าต้องค้นหาหลักฐานจากที่ใด

การจัดการ Repository

เอกสารและหลักฐานของโครงการควรแยกตามสถานะอย่างเหมาะสม เช่น

Working Space

พื้นที่สำหรับเอกสารที่อยู่ระหว่างจัดทำและแก้ไข

↓

Verification / Validation

↓

Baseline

เอกสารที่ผ่านกระบวนการตรวจสอบหรือรับรอง และถูกกำหนดให้เป็น Reference ของโครงการ

ส่วน Supporting Evidence เช่น Meeting Record, Test Evidence, Change Request, Correction Register หรือข้อมูลประกอบอื่น สามารถจัดเก็บในพื้นที่ที่กำหนดโดยยังคงสามารถตรวจสอบย้อนหลังได้

สำหรับ Source Code ควรใช้ Git Repository หรือ Version Control System เพื่อควบคุม Version และประวัติการเปลี่ยนแปลง

ตัวอย่างการนำไปใช้กับ RMUTL e-Asset

ในการดำเนินโครงการ RMUTL e-Asset มีการนำแนวทางดังกล่าวมาใช้จัดการ Work Product และหลักฐานของโครงการ เช่น

Agreement → Project Plan → SRS → Verification/Validation → SDS → Software Components → Test Plan/Test Report → RTM → UAT → User/Operation/Maintenance Documentation → Software Product → Acceptance

รวมถึงมีการจัดการ Change Request, Correction Register, Meeting Record, Project Schedule, Project Repository และหลักฐานประกอบอื่น เพื่อสนับสนุนการตรวจสอบย้อนหลังของกระบวนการพัฒนา

แนวทางดังกล่าวทำให้ ISO/IEC 29110 ไม่ได้แยกออกจากงานพัฒนาระบบ แต่กลายเป็นส่วนหนึ่งของ Software Development Lifecycle

จากมาตรฐานสู่แนวปฏิบัติขององค์กร

เป้าหมายของการนำ ISO/IEC 29110 มาใช้จึงไม่ใช่การสร้างเอกสารจำนวนมาก แต่คือการสร้าง กระบวนการพัฒนาระบบสารสนเทศที่เป็นมาตรฐานเดียวกัน

ทุกโครงการควรสามารถตอบได้ว่า

เรากำลังพัฒนาอะไร?

ใครเป็นผู้รับผิดชอบ?

Requirement ได้รับการยืนยันหรือยัง?

Software ที่พัฒนาตรงกับ Requirement หรือไม่?

ผ่านการทดสอบและรับรองหรือยัง?

สามารถตรวจสอบย้อนหลังได้หรือไม่?

และเมื่อส่งมอบแล้ว ใครสามารถดูแลระบบต่อได้?

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

ISO/IEC 29110 จึงไม่ใช่เพียงมาตรฐานสำหรับการตรวจประเมิน แต่เป็นกรอบการทำงานที่ช่วยเปลี่ยนการพัฒนาระบบจาก “การทำงานตามบุคคล” ไปสู่ “การทำงานตามกระบวนการที่ตรวจสอบและพัฒนาต่อได้”