Process Development : CMMI

Development Process with CMMI

บริษัทมีกระบวนการวิธีในการดำเนินงานและบริหารโครงการ ที่ชื่อ CMMI (Capability Maturity Model Integration) ซึ่งได้ผ่านการประเมินมาตรฐานใน Level 3 ประกอบกับ Agile Method ซึ่งเป็นมาตรฐานในการบริหารโครงการของบริษัท โดย CMMI เริ่มตั้งแต่กระบวนการนำเสนอแผนงานระบบ Project Planning จนกระทั่งถึงการบำรุงรักษาระบบภายหลังส่งมอบงาน ดังนั้นมาตรฐาน CMMI 3 จะมีขอบเขตที่กว้างกว่า Software Development Life Cycle (SDLC) โดยทั่วไป เพื่อให้ครอบคลุมตลอดระยะเวลาโครงการ

กระบวนการดำเนินงานโครงการ (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 : จัดการด้านเอกสารของโครงการ