บริษัทมีกระบวนการวิธีในการดำเนินงานและบริหารโครงการ ที่ชื่อ CMMI (Capability Maturity Model Integration) ซึ่งได้ผ่านการประเมินมาตรฐานใน Level 3 ประกอบกับ Agile Method ซึ่งเป็นมาตรฐานในการบริหารโครงการของบริษัท โดย CMMI เริ่มตั้งแต่กระบวนการนำเสนอแผนงานระบบ Project Planning จนกระทั่งถึงการบำรุงรักษาระบบภายหลังส่งมอบงาน ดังนั้นมาตรฐาน CMMI 3 จะมีขอบเขตที่กว้างกว่า Software Development Life Cycle (SDLC) โดยทั่วไป เพื่อให้ครอบคลุมตลอดระยะเวลาโครงการ
![1.1](http://www.fusionsol.com/wp-content/uploads/sites/2/2017/10/1.1-1024x367.jpg)
กระบวนการดำเนินงานโครงการ (Project Process) ตาม CMMI ซึ่งแบ่งการดำเนินการออกเป็นกระบวนการ ดังนี้
1. กระบวนการนำเสนอระบบ (Contract)
2. กระบวนการวางแผน (Planning Process)
2.1 กระบวนการนำเสนอระบบ (Contract)
2.2 กระบวนการวางแผน (Planning Process)
3. กระบวนการกำหนดความต้องการ (Requirement Definition)
3.1 ขั้นตอนการกำหนดข้อมูลความต้องการของระบบ (System Requirement Specification : SRS)
3.2 ขั้นตอนการกำหนดข้อมูลการออกแบบระบบ (System Design Specification : SDS)
4. กระบวนการพัฒนาระบบ (Development Process)
4.1 ขั้นตอนการพัฒนาทางด้านฟังก์ชั่น (Source code และ Application)
4.2 ขั้นตอนการทดสอบฟังก์ชั่น (Functional test)
4.3 ขั้นตอนการทดสอบการเชื่อมโยงในแต่ละส่วนของระบบหลังประกอบกัน (Integration test)
5. กระบวนการทดสอบและนำระบบไปใช้งาน (Operational Test and Transition)
5.1 ขั้นตอนการวางแผนทำ User Acceptance Test (UAT test plan)
5.2 ขั้นตอนในการทำกรณีทดสอบระบบ ต้องทำการประเมินและสรุปผลการทดสอบ (UAT test case & result)
5.3 ขั้นตอนการอบรมผู้ที่กี่ยวข้องกับระบบ (Training)
5.4 คู่มือการใช้งานระบบ (User Manual)
5.5 คู่มือการตั้งค่าสำหรับระบบ (Administration & Configuration Manual)
6. กระบวนการบำรุงรักษาระบบ (Operation Maintenance)
6.1 Maintenance Agreement
6.2 Maintenance Issues List
Change Requirement Management
ขบวนการพัฒนา Application สิ่งที่ไม่สามารถหลีกได้คือ Change Requirement ซึ่งสาเหตุ และ สิ่งที่เป็นผลกระทบ จะมีผลต่อโครงการเป็นอย่างมาก ดังนั้น ขบวนการบริหารจัดการเรื่องนี้ต้องมีการตกลงกันให้ชัดเจน
ก่อนอื่นมาดูที่สาเหตุของการเกิด Change Requirement กันก่อน
- คนให้ข้อมูลไม่เชี่ยวชาญในเรื่องที่กำลังจะทำ
- เป็นระบบที่ Design ใหม่โดยที่ยังไม่เคยมีใครทำมาก่อน
- ส่วนของ Supplier ไม่เข้าใจ Business ของลูกค้า
ผลกระทบของ Change Requirement
- กรณีที่ CR ในช่วงก่อน Get Requirement
- ผลกระทบน้อยเนื่องจากยังไม่ได้เริ่มพัฒนาระบบจริง
- ถือว่าเป็นส่วนหนึ่งใน Requirement ได้
- กรณีที่ CR ในช่วง Design
- มีผลกระทบเนื่องจากปกติจะเข้าสู่ขั้นตอนพัฒนาไปแล้วบางส่วน เช่น Front , Design Layout
- ขึ้นกับประเภทของ CR ด้วยเช่น การเพิ่ม รายละเอียด Field , Validate Condition จะกระทบไม่มาก
- การทำ CR เช่น เพิ่ม Feature ต้อง Check กับ Requirement Spec ก่อน เพราะอาจจะเป็นเรื่อง out off scope
- กรณีที่ CR ช่วง Development
- มีผลกระทบกับ Time Line ของโครงการ เพราะต้องเข้าสู่ขั้นตอน Design ใหม่อีกรอบ
- ต้องดูว่าหัวข้อ CR นั้นมีความขัดแย้งกับสิ่งที่เคยแจ้งหรือไม่ หรืออาจจะขอให้เปลี่ยนขั้นตอนการทำงานไปเลย จะมีผลกระทบมาก
- กรณีที่ CR ช่วง UAT
- จะมีโอกาสเกิด CR มากเนื่องจาก User ผู้ใช้งานมาเกี่ยวข้องด้วย ซึ่งเป็นคนละทีมกับผู้ให้ Requirement และ User จำนวนมากไม่เคยเห็นระบบมาก่อน
- มีผลกระทบแน่นอนกับ Time Line และ Budget
การบริหารจัดการ Change Requirement
- ผู้พัฒนาต้องทำใจยอมรับว่า CR เป็นเรื่องธรรมชาติก่อน และใจเย็นๆ
- Project Manager ของ User ต้องวางแผนเรื่อง Budget ไว้ล่วงหน้า
- การเปิดโอกาสให้ End User มาเห็น Design และมีส่วนร่วมในการออกแบบในตอนต้นๆ ของโครงการ
- การเปิดเวที Kick Off และแจ้ง ขอบเขตงานในเบื้องต้นกับทีม UAT