บริษัทมีกระบวนการวิธีในการดำเนินงานและบริหารโครงการ ที่ชื่อ CMMI (Capability Maturity Model Integration) ซึ่งได้ผ่านการประเมินมาตรฐานใน Level 3 ประกอบกับ Agile Method ซึ่งเป็นมาตรฐานในการบริหารโครงการของบริษัท โดย CMMI เริ่มตั้งแต่กระบวนการนำเสนอแผนงานระบบ Project Planning จนกระทั่งถึงการบำรุงรักษาระบบภายหลังส่งมอบงาน ดังนั้นมาตรฐาน CMMI 3 จะมีขอบเขตที่กว้างกว่า Software Development Life Cycle (SDLC) โดยทั่วไป เพื่อให้ครอบคลุมตลอดระยะเวลาโครงการ
![1.1](https://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 ของลูกค้า
แบบไหนถึงเรียกว่า เป็น CR
- เพิ่ม Feature ใหม่ที่ไม่เคยระบุในเอกสาร
- เปลี่ยน รูปแบบ Feature จาก A ไปเป็น B
- เป็นการเพิ่ม เช่น ตัวเลือกมี 3 แบบ แต่ให้เพิ่มเป็น 4 แบบ
- โดยใช้การอ้างอิงจากเอกสารเป็นหลัก
ผลกระทบของ 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
แนวทางการ Get Requirement
ขั้นตอนการ Get Requirement ถือเป็นขั้นตอนสำคัญมากที่สุด เนื่องจากจะเป็นทิศทางการดำเนินการทั้งหมด และ สามารถประเมินในเบื้องต้นได้เลยว่า โครงการจะจบแบบไหน เช่น ถ้า Requirement พูดออกมาแล้วไม่สามารถสรุปได้เป็น Metric ชัดเจน แต่ออกเป็นแนว เล่าให้ฟัง แล้วก็บันทึกข้อมูล Requirement แบบ เขียนไปเรื่อย ๆ แบบนี้ก็ชัดแล้ว ว่าตอนจบ ไม่สวย
Requirement ที่ดี ความมีลักษณะดังนี้
- แยกเป็นหัวข้อที่สำคัญ ชัดเจน เช่น
- Role ของผู้ใช้งานในระบบ
- Permission ของแต่ละ Role ในแต่ละพื้นที่ และ สถานะของข้อมูล
- Action การดำเนินการที่สามารถทำได้ในแต่ละ Role
- Field ข้อมูลในแต่ละเรื่อง
- สามารถระบุ ชนิด ประเภท และ จำนวน Field ทั้งหมด และกำหนดเป็นหมายเลข ID ของแต่ละ Field
- กำหนด Field ที่เป็น Master Data และ การจัดเตรียมหน้า Admin สำหรับบริหารจัดการ
- Reference Field ของระบบ กับ ของ User แยกกันชัดเจน
- Process Flow ของระบบ
- สามารถแยกออกมาเป็นข้อ ๆ และมีเลข ID สำหรับเป็น Reference
- การพิจารณาเรื่องการเลือก ข้อมูลที่จะดำเนินการ เช่น เลือกเป็น กลุ่ม หรือ เลือกที่ละรายการ
- การแสดงผลข้อมูล ในแบบ List แต่ละ Role
- สามารถระบุได้ชัดเจนว่า แต่ละ Role จะมีการแสดงผลภายใต้เงื่อนไข แบบไหน
- กำหนด จำนวนเงื่อนไขที่จะนำมาพิจารณาได้ชัดเจน
- การจัดทำเอกสาร ต้องสรุปเป็นตาราง Config ได้ ไม่จำเป็นต้องยึดรูปแบบเอกสารที่เป็น Word
Development Team
- Project Manager : ควบคุมแผนงาน Scope of work ให้อยู่ในขอบเขตที่สามารถส่งงานได้ตามแผน นำเสนอ สถานะโครงการต่อที่ประชุม
- Business Analysis : ออกแบบการใช้งานระบบ Flow การทำงาน ให้สอดคล้องกับความต้องการของ User และเป้าหมายของการใช้งานระบบ
- System Analysis : ออกแบบและควบคุม Data Flow , Data Dic , ER Diagram การออกแบบ ระบบการเชื่อมต่อข้อมูลทั้งภายในและภายนอก
- Senior Programmer : ควบคุมแนวทางการ Code ให้ได้มาตราฐาน
- Programmer : Coding
- Tester : ออกแบบการทดสอบระบบก่อนการส่งมอบ
- Admin : จัดการด้านเอกสารของโครงการ