การประมาณการแรงงานด้วยวิธีโคโคโม

1. การประมาณการแรงงานด้วยวิธีโคโคโมการประมาณการแรงงานด้วยวิธีโคโคโม อ.วิวัฒน์ ชินนาทศิริกุล

2. บทนำ • COCOMOย่อมาจาก COnstruction COst MOdelพัฒนาโดย โบแอม (ค.ศ.1981) เรียกว่า COCOMO81หรือ COCOMOI • วัตถุประสงค์ เพื่อประมาณการแรงงานและเวลาที่ต้องใช้ในการพัฒนาซอฟแวร์ • ปี ค.ศ.2004 โบแอม ได้พัฒนาปรับปรุงตัวแบบ COCOMOใหม่ให้สอดคล้องกับวิธีการพัฒนาซอฟแวร์ที่เปลี่ยนไปจากเดิม ตัวแบบใหม่เรียกว่า COCOMO2000หรือ COCOMOII

3. COCOMOI • COCOMOIเป็นตัวแบบที่ประมาณการแรงงาน (effort)และระยะเวลาที่ใช้จำนวนบรรทัดของโปรแกรม (LOC) • ประกอบด้วยตัวแบบ 3 แบบ คือ 1.ตัวแบบระดับพื้นฐาน (Basic Model) 2.ตัวแบบระดับกลาง (Intermediate model) 3.ตัวแบบระดับสูง (Advance Model)

4. ตัวแบบระดับพื้นฐาน ประมาณการแรงงาน โดยไม่มีตัวปรับค่า • ตัวแบบระดับกลาง เป็นตัวแบบที่มีการพัฒนาจากตัวแบบระดับพื้นฐาน แต่มีความละเอียดมากขึ้น โดยมีการปรับค่าที่ได้จากตัวแบบแรกด้วยตัวขับเคลื่อนค่าใช้จ่าย (Cost Driven) • ตัวแบบระดับสูง มีการประมาณการแบบเดียวกับตัวแบบระดับกลาง แต่การคำนวณแรงงาน และการประเมินตัวขับเคลื่อนค่าใช้จ่าย จะทำในแต่ละเฟสของการพัฒนาระบบงาน

5. ขั้นตอนการประมาณการ 1.จัดประเภทของระบบงานที่กำลังพิจารณา มี 3 ประเภท 1.1 ประเภทออกานิก (Organic Model) 1.2 ประเภทเซมิดีเทช (Semi-detached Model) 1.3 ประเภทเอมเบดเด็ด (Embedded Model) 2.คำนวณหาแรงงานปกติ และระยะเวลาการพัฒนาระบบงาน 3.คำนวณหาปัจจัยปรับแรงงาน (Effort Adjustment Factor)

6. 1.1ประเภทออกานิก (Organic Model) • ทีมงานที่พัฒนามีขนาดเล็ก • ระบบงานมีขนาดเล็ก ประมาณไม่เกิน 50 KLOC • พัฒนาภายในสภาวะแวดล้อมภายในองค์กร (in-house environment) • ทีมงานมีความคุ้นเคย หรือมีประสบการณ์กับระบบงานที่จะพัฒนา • สามารถต่อรอง ขอปรับเปลี่ยนรายละเอียดของซอฟแวร์ได้ • ระบบงานพัฒนาอยู่บนสภาพแวดล้อมที่คงที่ (static environment) • อัลกอริทึมของการประมวลผลไม่มีความซับซ้อน • ระยะเวลาในการพัฒนาไม่เป็นตัวกดดันต่อผู้พัฒนามากนัก

7. 1.2ประเภทเซมิดีเทช (Semi-detached Model) • คนในทีม มีทั้งคนที่มี และไม่มีประสบการณ์ในระบบงานที่กำลังพัฒนา • คนในทีมทุกคนมีประสบการณ์ในระบบงานที่เกี่ยวข้องปานกลาง • มีแรงกดดันจากระยะเวลาของโครงการบ้าง • ระบบงานมีขนาดปานกลาง ประมาณไม่เกิน 300 KLOC • อัลกอริทึมของการประมวลผลมีความซับซ้อนพอประมาณ

8. 1.3 ประเภทเอมเบดเด็ด (Embedded Model) • ทีมงาน ไม่มีความคุ้นเคย หรือไม่มีประสบการณ์กับระบบงานที่จะพัฒนา • ข้อกำหนดของระบบงานที่พัฒนา ไม่สามารถเปลี่ยนแปลงได้ เนื่องมาจากข้อจำกัดต่างๆ • ต้องพัฒนาระบบงานที่ทำงานร่วมกับอุปกรณ์เฉพาะ หรือระบบพัฒนาขึ้นโดยผูกกับกฎ ระเบียบ หรือขั้นตอนการดำเนินงานอย่างเคร่งครัด • ต้องพัฒนาระบบงานภายในเวลาที่กำหนด • อัลกอริทึมของการประมวลผลมีความซับซ้อน • ต้องทดสอบความถูกต้องอย่างมาก

9. การคำนวณหาแรงงาน และระยะเวลา • ตัวแบบพื้นฐาน แรงงาน (คน-เดือน) = axKLOCb ระยะเวลาการพัฒนา = cXแรงงานd โดยที่ a, b, c, dมีค่าตามตาราง

10. ตาราง แสดงค่าพารามิเตอร์สำหรับตัวแบบระดับพื้นฐาน

11. ตัวอย่างระบบงานมีขนาด 33.3 KLOCเป็นระบบแบบเซมิดีเทช จงคำนวณหาแรงงาน ระยะเวลา และจำนวนคน • แรงงาน (คน-เดือน) = 3.0 x KLOC1.12 =3.0 x 33.31.12 = 152คน-เดือน • ระยะเวลา = 2.5 x 152 =14.5เดือน • จำนวนคน = 152/14.5 =11คน

12. ตัวแบบระดับกลาง แรงงาน (คน-เดือน) = a xKLOCbxตัวขับเคลื่อนค่าใช้จ่าย ระยะเวลาการพัฒนา = c Xแรงงานd โดยที่ a, b, c, d มีค่าตามตาราง

13. ตัวอย่าง • จากการประมาณขนาดซอฟแวร์ ของโครงการแบบ organicพบว่า • data entry 0.6 KLOC • data update 0.6 KLOC • query 0.8 KLOC • report gen. 1.0 KLOC • TOTAL 3.0 KLOC • cost driver attribute • Complexity high 1.15 • Storage high 1.06 • Experience low 1.13 • Programmer capability low 1.17

14. ตัวขับเคลื่อนค่าใช้จ่าย = = • แรงงาน (คน-เดือน) =axKLOCbxตัวขับเคลื่อนค่าใช้จ่าย = = • ระยะเวลา =c Xแรงงานd =

15. การคำนวณหาปัจจัยปรับแรงงานการคำนวณหาปัจจัยปรับแรงงาน • ถ้าการคำนวณแรงงาน ใช้ตัวแบบระดับกลาง ผู้จัดการโครงการต้องปรับค่าของแรงงานปกติ ที่คำนวณได้จากข้อ 2ด้วยปัจจัยปรับแรงงาน ซึ่งได้จากตัวขับเคลื่อนค่าใช้จ่าย (Cost Driver) ที่มี 15ตัว แบ่งออกเป็น 4กลุ่ม ดังตาราง

17. ตัวขับเคลื่อนคาใชจายแตละตัว จะมีอัตราแตกตางกัน ตั้งแตต่ำมาก (very low) จนกระทั่ง สูงเปนพิเศษ (extra high) • ผูจัดการโครงการจะตองระบุใหไดวาตัวขับเคลื่อนคาใชจายแตละตัวมีคา เทาไร แลวจึงนําคาของตัวขับเคลื่อนคาใชจายทุกตัวมาคูณกัน • จากนั้นจึงนําผลคูณของตัวขับเคลื่อนคาใชจายทั้งหมดไปคูณกับแรงงานปกติที่ไดจากขอ 2 • ตารางที่ 6.11 และ 6.12 จะชวยใหผูจัดการโครงการสามารถกําหนดระดับของตัวขับเคลื่อนคาใชจายแตละตัว เชน ความเชื่อถือของระบบงาน (RELY) จะไดระดับสูงมาก (1.40) ถาระบบงานนั้นมีผลกระทบตอ ชีวิตมนุษย หรือสถานภาพการเงินของงคการอยางรุนแรง

18. แตถาระบบงานลมเหลวแลวมีผลเพียงแคทําใหเกิดความไมสะดวกในการทํางานเทานั้นคาระดับของ RELYในกรณีนี้จะต่ำมาก (0.75) สําหรับความซับซอนของระบบงาน (CPLX) นั้น • ผูจัดการโครงการจะกําหนดระดับของตัวขับเคลื่อนคาใชจายไดโดยพิจารณาจากตารางที่ 6.12 ถาระบบงานมีการคํานวณที่มีสูตรการคํานวณทางคณิตศาสตรหรือสถิติที่ซับซอน คาระดับของ CPLXจะสูงมาก (1.30) • แตถาเปนการคํานวณงายๆ คาระดับของ CPLXจะต่ำ (0.70) สวนตารางที่ 6.13คือ ตัวอยางการกําหนดระดับและคาของตัวขับเคลื่อน คาใชจาย

24. COCOMOII • โบแอมไดพิจารณาถึงการเปลี่ยนแปลงการพัฒนาซอฟตแวรหรือระบบงาน ในปจจุบันที่มีวิธีการพัฒนาที่แตกตางไปจากป ค.ศ. 1981 • COCOMO81 มีสมมติฐานวา ซอฟตแวรพัฒนาตามกระบวนการแบบ น้ำตก และซอฟตแวรสวนใหญพัฒนาจากจุดเริ่มตนทั้งหมด เมื่อมีการ เปลี่ยนวิธีการพัฒนาซอฟตแวรอย่างมากมายตั้งแตรุนแรกที่นําเสนอผูใช เชน การพัฒนาใชวิธีการพัฒนาตนแบบ (prototyping) • การพัฒนาโดยการนําซอฟตแวรแตละสวนมาประกอบเปนระบบงาน (components composition) หรือการพัฒนาดวยภาษารุนที่ 4 (4th generation language) ระบบงานเดิมที่มีอยูถูกรื้อปรับเพื่อสราง ซอฟตแวรใหม

25. ดังนั้น ตัวแบบที่กําหนดใน COCOMOI จึงไมเหมาะสมกับวิธีการพัฒนาแบบใหมดังกลาว • โบแอมจึงทําการวิจัยและนําเสนอตัวแบบใหมสําหรับการประมาณการแรงงาน ตัวแบบใหมจึงเรียก COCOMOIIซึ่งมี 3 ตัวแบบ • COCOMOIIเปนตัวแบบสําหรับการประมาณการเปนระยะๆ ตามรายละเอียดของขอมูลที่ผูจัดการโครงการ/นักวิเคราะหระบบไดรับ ซึ่งจะทําใหการปรับคาแรงงานที่ตองใชใกลเคียงความเปนจริงมากยิ่งขึ้น

26. ตัวแบบ 3 ระดับของ COCOMOIIได้แก่ 1.ระยะการพัฒนาต้นแบบช่วงต้น 2.ระยะการออกแบบช่วงต้น 3.ระยะหลังจากการออกแบบสถาปัตยกรรม

27. 1.ระยะการพัฒนาต้นแบบช่วงต้น1.ระยะการพัฒนาต้นแบบช่วงต้น • เป็นตัวแบบที่ใช้สำหรับการประมาณแรงงาน ในช่วงเริ่มต้นโครงการ ผู้จัดการโครงการ ยังไม่ทราบรายละเอียดของระบบงาน แต่ทราบฟังก์ชันงานคร่าวๆ • การประมาณการจึงใช้ อ็อบเจกต์พอยต์ (Object Points) ตัวแบบนี้เหมาะกับการพัฒนาระบบด้วยวิธีการใช้ซอฟแวร์ต่างๆที่มีมาประกอบกัน

28. 2.ระยะการออกแบบช่วงต้น2.ระยะการออกแบบช่วงต้น • เป็นตัวแบบที่ใช้สำหรับประมาณแรงงาน เมื่อผู้จัดการโครงการ ทราบความต้องการแล้ว • การประมาณการนี้ จะประมาณการโดยใช้ฟังก์ชันพอยต์ แล้วปรับเป็น LOCและมีชุดของปัจจัยที่ไม่ยุ่งยากมาใช้ในการปรับค่าที่ได้ประมาณการ

29. 3.ระยะหลังจากการออกแบบสถาปัตยกรรม3.ระยะหลังจากการออกแบบสถาปัตยกรรม • เป็นตัวแบบที่ใช้ในการประมาณการขนาดของซอฟแวร์ ให้แม่นยำมากขึ้นหลังจากออกแบบสถาปัตยกรรมระบบงานแล้ว • ตัวแบบของระดับนี้ มีสูตรคำนวณ เช่นเดียวกับระดับการออกแบบระยะแรก แต่มีชุดของปัจจัยที่เข้มข้นมาปรับค่าอีกชุด

30. แรงงาน การประมาณการแรงงาน สำหรับระยะการพัฒนาต้นแบบช่วงต้น • ตัวแบบการคำนวณแรงงาน คือ โดยที่ PM =แรงงาน (คน-เดือน) NOP =อ็อบเกจต์พอยต์ใหม่ (New Object Point) %reuse =ร้อยละของซอฟแวร์ที่นำกลับมาใช้ใหม่ PROD =ผลผลิตเพิ่ม

31. ขั้นตอนการคำนวณ 1.นับจำนวนอ็อบเจกต์พอยต์ ที่ประกอบกันเป็นระบบงาน อ็อบเจกต์ได้แก่ จอภาพ รายงาน และส่วนประกอบที่เป็น 3 GL (3 General Language) 2.จัดระดับของอ็อบเจกต์แต่ละอ็อบเจกต์ ซึ่งมี 3ระดับคือ ง่าย ปานกลาง และยาก การจัดว่าแต่ละอ็อบเจกต์อยู่ในระดับใด ให้พิจารณาตามประเภทของ อ็อบเจกต์ ออกเป็น 2ประเภทคือ จอภาพ และรายงาน

32. ระดับของอ็อบเจกต์ แต่ละประเภท แสดงดังตาราง

33. 3. ให้น้ำหนักความยาก-ง่าย ของแต่ละอ็อบเจกต์ เพื่อสะท้อนให้เห็นถึงแรงงานที่ต้องใช้ในการสร้างอ็อบเจกต์นั้นๆ น้ำหนักความยากง่าย ของอ็อบเจกต์ แต่ละประเภทแสดงดังตาราง

34. 4.หาผลรวมของอ็อบเจกต์พอยต์ หลังจากถ่วงน้ำหนักของอ็อบเจกต์พอยต์ทุกๆตัวแล้ว 5.ประมาณร้อยละของการนำโปรแกรมกลับมาใช้หใม่ แล้วคำนวณหาอ็อบเจกต์พอยต์ใหม่ที่ต้องพัฒนา (NOP)โดยมีสูตรการคำนวณดังนี้ 6.กำหนดระดับผลผลิตเพิ่ม (PROD) โดยที่ PROD หาได้จากตาราง 7.ประมาณการ แรงงานที่ต้องใช้ (PM) = NOP/PROD

35. การประมาณการแรงงาน สำหรับระยะการออกแบบช่วงต้น • ตัวแบบการประมาณแรงงาน ระดับนี้คือ แรงงาน (effort) =2.94 X sizeB x M + PMauto โดยที่ sizeคือ ขนาดของระบบงานวัดเป็นกิโลบรรทัด (KLOC)ซึ่งคำนวณได้จากจำนวนฟังก์ชันพอยต์ Mคือ ผลคูณของตัวคูณแรงงาน (effort multipliers)เพื่อปรับค่าของแรงงานให้สอดคล้องกับลักษณะของระบบงานและโครงการ ตัวคูณมีทั้งหมด 7ตัวคือ

36. RCPXความน่าเชื่อถือและความซับซ้อนของระบบงาน (Reliability and complexity) • RUSEโปรแกรมที่นำกลับมาใช้ใหม่ (reuse requires) • PDIFความยากของแพล็ตฟอร์ม (Platform difficulty) • PERS ความสามารถของบุคลากร (Personal Capability) • PREXประสบการณ์ของบุคลากร (Personal Experience) • FCILสิ่งอำนวยความสะดวกในการพัฒนาระบบงาน (SupportFacilities) • SCEDแรงกดดันจากตารางเวลาการพัฒนา (Schedule) M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED