Chapter 3

1. Chapter 3 การประเมินขนาดซอฟต์แวร์ (Product)

2. องค์ประกอบของ Product • การประมาณการ Product มี 4 ส่วนหลักด้วยกันคือ • ขนาด (Size) • บุคลากร (People) • ระยะเวลา (Period) • ค่าใช้จ่าย (Price)

3. การประมาณการซอฟต์แวร์การประมาณการซอฟต์แวร์ การประมาณการซอฟต์แวร์ถือว่าเป็นส่วนสำคัญในการวางแผน เนื่องจากการวางแผนจะอยู่บนพื้นฐานของสิ่งที่ต้องการทำการจัดสร้างหรือพัฒนา โดยในการพัฒนาซอฟต์แวร์นั้นมีมุมมองในการประมาณการถึง ขนาด (Size) ค่าใช้จ่าย (Cost) บุคลากรที่ใช้พัฒนา (Effort) รวมไปถึงระยะเวลา(Schedule)

4. ขั้นตอนในการประมาณการขั้นตอนในการประมาณการ • ประกอบด้วย 7 ขั้นตอนดังนี้ • การเลือกกรรมวิธีการวัดลักษณะของซอฟต์แวร์(Measurement Method) • เลือกวิธีที่ใช้ในการประมาณการ (Estimation Techniques) • ทำการประมาณการในส่วนของ ขนาด ค่าใช้จ่าย บุคลากร ระยะเวลา และทรัพยากรที่จำเป็น (Product Estimation) • ทำการวิเคราะห์ความเสี่ยง หรือ ผลกระทบจากปัจจัยต่างๆ (Risk Assessment /Impact Analysis) • ทำการตรวจทาน ตรวจสอบ และ ปรับแก้ให้เหมาะสม (Review/Revise/Refine/Document) • ทำการติดตามและวัดผลผลิตภัณฑ์หรือซอฟต์แวร์ที่ได้ทำการพัฒนาจริง(Tracking/Product Measurement) • ทำการปรับปรุงแก้ไขกระบวนการ(Process Improvement)

5. การวัดขนาดซอฟต์แวร์ • การวัดขนาดของซอฟต์แวร์มีวัตถุประสงค์เพื่อ • ชี้ให้เห็นถึงคุณภาพของผลิตภัณฑ์ • เพื่อประเมินผลที่เกิดจากบุคลากรผู้ทำการผลิต • เพื่อคาดคะเนผลกำไร • เพื่อจัดเตรียมแนวทางในการประเมิน • เพื่อจัดสรรเครื่องมือและอุปกรณ์ต่างๆในการพัฒนา

6. การประมาณการขนาดของซอฟต์แวร์การประมาณการขนาดของซอฟต์แวร์ • สิ่งแรกก่อนที่จะทำการประมาณการซอฟต์แวร์ได้จะต้องทำการวัดขนาดของซอฟต์แวร์เสียก่อน โดยสามารถแบ่งลักษณะของการวัดออกเป็น 2 เชิงด้วยกันคือ • การวัดเชิงปริมาณ (Software Quantitative) • วัดในเชิงขนาดบุคลากร ระยะเวลา อัตราความผิดพลาดในการพัฒนา ค่าใช้จ่าย • การวัดเชิงคุณภาพ(Software Qualitative) • วัดในเชิงลักษณะของการผลิต ทีมงาน ความซับซ้อน การบริหารจัดการ และ เทคโนโลยีที่นำมาใช้

7. หน่วยที่ใช้วัดในการประเมินราคาซอฟต์แวร์หน่วยที่ใช้วัดในการประเมินราคาซอฟต์แวร์ • ในการประเมินราคาซอฟต์แวร์โดยทั่วไป มักเริ่มจากการวัดขนาดของซอฟต์แวร์โดยทางตรง หรือ ทางอ้อม หรือ อาจจะนำทั้ง 2 แบบมาประกอบกัน โดยส่วนใหญ่หน่วยที่ใช้ในการประเมินคือ กำลังคน (Effort) ในการพัฒนาซอฟต์แวร์ ซึ่งอาจจะคิดเป็น คน-ชั่วโมง คน-วัน คน-เดือน หรือคน-ปี ซึ่งหน่วยที่นิยมมากที่สุดคือ คน-เดือน

8. การวัดขนาดของซอฟต์แวร์การวัดขนาดของซอฟต์แวร์ • มี 2 ลักษณะ • การใช้ Model ในการประเมินราคาซอฟต์แวร์ • Function Point (FP)

9. การใช้ Model ในการประเมินราคาซอฟต์แวร์ • วิธีของ LaBolle ได้เสนอวิธีที่เน้นเทคนิคทางคณิตศาสตร์ • การประเมินราคาจะต้องพิจารณาถึงวิธีการในการคำนวณอย่างน้อย 1 วิธีการดังนี้ • ราคาต่อหน่วย เช่น ราคาต่อคำสั่ง ต่อโปรแกรมย่อย ต่อชุดคำสั่ง หรือ ต่อโมดูล หรือ ราคาต่อระบบ และ ราคาต่อการทำกิจกรรมอย่างหนึ่ง • เปอร์เซ็นต์จากราคารวม เช่น ให้ราคาโปรแกรมคอมพิวเตอร์เป็น x% ของค่าพัฒนาทั้งหมด • การเปรียบเทียบจำเพาะ เช่น ความคล้ายคลึงของโปรแกรมที่ต้องการพัฒนาใหม่กับโปรแกรมที่มีอยู่แล้ว เช่น อาจเพิ่มความต้องการในโปรแกรมใหม่ ดังนั้นราคาจะเท่ากับ ราคาของโปรแกรมเก่า บวกกับราคาของการพัฒนาความต้องการ Cost ,C = K1X+K2Y+K3Z X= จำนวนหน้าจอ Y=จำนวนชิ้นโปรแกรม Z=จำนวนข้อมูล / K1,K2,K3= เป็นค่าคงที่ที่กำหนดค่าไว้

10. การใช้ Model ในการประเมินราคาซอฟต์แวร์(ต่อ) • Wolverton ได้เสนอเทคนิคการจัดโมเดลในการประเมินราคาซอฟต์แวร์ไว้อีกทางหนึ่ง • การประเมินแบบ Top-down • ผู้ประเมินจะยึดเอาราคาทั้งหมดของงานส่วนใหญ่ในโครงการที่ทำมาก่อนเป็นหลัก และด้วยประวัติที่ผ่านมาพิจารณาประกอบกับการแสดงความคิดเห็นก็จะสามารถประเมินราคาใหม่ได้ • การประเมินราคาโดยพิจารณาจากความเหมือนและความแตกต่าง • ผู้ประเมินจะแบ่งงานการประเมินโดยคำนึงถึงรายละเอียดของโปรแกรมใหม่ ที่พัฒนาขึ้น โดยเปรียบเทียบความเหมือนและความแตกต่างกันกับโปรแกรมในโครงการเก่า สำหรับงานที่ไม่สามารถเปรียบเทียบได้ก็จะใช้วิธีอื่น • กระประเมินโดยใช้วิธี Bottom-up • วิธีนี้ที่ใช้กันอย่างกว้างขวางในหน่วยงานการประเมินของรัฐบาล โดยงานทั้งหมดจะถูกแบ่งออกเป็นชิ้นย่อยๆ และจะแบ่งให้เล็กลงเรื่อยๆ จนถึงขั้นที่สามารถสร้างได้อย่างชัดเจน จากนั้นจึงทำการประเมินราคาของแต่ละผลงานและนำมารวมกันเป็นราคาของโครงการทั้งหมด

11. การใช้ Model ในการประเมินราคาซอฟต์แวร์(ต่อ) • Walston และ Felix ได้เริ่มเก็บข้อมูลตั้งแต่ปี ค.ศ. 1973 และในปี 1977 สามารถสรุปได้ในรูปแบบสมการดังนี้คือ E = 5.2(KDSI)0.91 E = Effort มีหน่วยเป็น คน-เดือน KDSI = Kilo(1000 บรรทัด) of Delivered Source Instruction

12. DSI • นิยามของ DSI • นับเฉพาะบรรทัดที่มีการจัดส่งเป็น Source Code ไม่นับรวมส่วนของการทดสอบ หรือ ส่วนงานที่รองรับการทำงานอื่นๆ • นับเฉพาะบรรทัดที่พัฒนาโดยบุคลากร ไม่นับรวมสิ่งที่ระบบงานสามารถ สร้างขึ้นมาได้อัตโนมัติ • ถือว่า 1 คำสั่งคือ 1 Line of Code • นับส่วนของการประกาศค่า (Declaration) เป็นส่วนของ Instruction • ไม่นับในส่วนขยายความ หรือ Comment

13. การใช้ Model ในการประเมินราคาซอฟต์แวร์(ต่อ) • Boehm B.W. ได้พัฒนาโมเดล COCOMO (Constructive Cost Model) ขึ้นในปี ค.ศ. 1981 โดยใช้การวิเคราะห์ข้อมูลจาก 63 โครงการ วิธีการของ COCOMO นี้เป็นวิธีการวัด Effort ในการพัฒนาซอฟต์แวร์ที่คิดเป็น คน-เดือน โดยได้กำหนดปัจจัยที่มีผลต่อราคาซอฟต์แวร์ได้ 4 อย่างกว้างๆ คือ ผลผลิคอมพิวเตอร์ บุคลากร โครงการ โดยรูปแบบของโมเดลจะแบ่งออกเป็น 3 ลักษณะด้วยกันคือ • Basic COCOMO Model : เป็นโมเดลที่มีการกำหนดค่าคงที่ค่าเดียวเพื่อการคำนวณในการพัฒนาซอฟต์แวร์เป็นขนาดโปรแกรมซึ่งปรากฏในรูปแบบ Lines of Code (LOC) • Intermediate COCOMO Model : คำนวณ Effort ในการพัฒนาซอฟต์แวร์เป็นขนาดของโปรแกรมและรวมปัจจัยที่มีผลกระทบต่อราคา • Advanced COCOMO Model : จะรวมปัจจัยที่มีผลกระทบต่อราคาทั้งหมดในทุกๆขั้นตอน เช่น ในกรณีการวิ้เคราะห์ และ การออกแบบ

14. COCOMO Model สามารถแบ่งออกเป็น 3 ประเภทโครงการดังนี้

15. Effort Estimation Metric (COCOMO) มีการประมาณการ E=Effort และ D=Development Time ดังนี้

16. Effort Estimation Metric (COCOMO) ตัวอย่าง สมมติให้โครงการพัฒนาซอฟต์แวร์ในระดับ Organicหนึ่งได้ทำการคำนวณ จำนวนบรรทัดออกมาได้ 33.2 KLOCจงหาว่าโครงการนี้จะต้องใช้จำนวนทั้งหมดกี่คน และ ระยะเวลาประมาณเท่าไหร่

17. FP (Function Point) • เป็นลักษณะของการวัดขนาดของซอฟต์แวร์ที่ไม่ได้มุ่งเน้นในเรื่องของ จำนวนบรรทัด เพราะ บางทีการเขียนโปรแกรม ในเรื่องเดียวกัน แต่ใช้คนละภาษาแต่ผลลัพธ์ออกมาเหมือนกัน อาจจะได้ LOC ที่ไม่เท่ากันก็ได้ ซึ่งไม่สามารถวัดได้ว่า คนที่เขียนโปรแกรมด้วย ขนาดของ LOC ที่ยาวกว่า จะมีประสิทธิภาพการทำงานที่ดีกว่า เสมอไป • ในการวัดขนาดแบบ FP จะไม่สนใจความยาวของโปรแกรม และไม่สนใจว่าจะเขียนจากภาษาใด แต่จะนับจากผลลัพธ์ฟังก์ชันที่ระบบสามารถรองรับความต้องการของผู้ใช้งานได้

18. FP (Function Point)ต่อ • ลักษณะของการวัด FP นั้น จะมุ่งเน้นที่การวัดโดยผ่านมุมมองความต้องการของผู้ใช้ ซึ่งสามารถนำไปพิจารณาจัดสรรสิ่งต่างๆที่ตามมาได้เช่น จัดสรรคน งบประมาณ เวลาได้

19. กระบวนการนับ FP • ขั้นที่ 1 นำ ความต้องการที่จัดการเก็บรวมรวมไว้มาทำการแบ่งประเภทของฟังก์ชันพอยต์ • ขั้นที่ 2 ประเมินความซับซ้อนของฟังก์ชัน • ขั้นที่ 3 เปรียบเทียบความซ้ำซ้อน เพื่อให้ได้ระดับความซ้ำซ้อนเพื่อคำนวณฟังก์ชันพอยต์ที่ยังไม่ได้ปรับค่า • ขั้นที่ 4 คำนวณตัวแปรปรับค่าตามลักษณะเฉพาะ • ขั้นที่ 5 คำนวณจำนวนฟังก์ชันที่ผ่านการปรับค่า • ขั้นที่ 6 ฟังก์ชันพอยต์ที่ผ่านการปรับค่า สามารถนำไปคำนวณแบบLOC ได้

20. ประเภทของฟังก์ชันพอยต์ประเภทของฟังก์ชันพอยต์ • ฟังก์ชันพอยต์ในระบบงานคอมพิวเตอร์สามารถแบ่งออกได้เป็น 5 ลักษณะ ดังนี้คือ • Internal Logical File (ILF) • External Interface File (EIF) • External Input (EI) • External Output (EO) • External Inquiry (EQ)

21. Context Diagram User User User External Input External Output External Inquiries Internal Logical File Other Application Application External InterfaceFile

22. Cost Estimation องค์ประกอบในการประเมินราคาซอฟต์แวร์ • ขนาด (Size) • ราคา (Cost) • ระยะเวลา (Schedule)

23. Cost Estimation • กระบวนการประเมินราคาซอฟต์แวร์ Software Sizing Method Selection Software Costing Comparison Refining

24. Summary of Cost Estimation ในการประเมินค่าใช้จ่ายในการพัฒนาซอฟต์แวร์เป็นเรื่องสำคัญเพราะจะเป็นสิ่งบอกถึงการได้มาซึ่งโครงการนั้นๆ ถ้ามีการประเมินราคาผิดพลาดมากกว่าความเป็นจริง ก็อาจจะส่งผลเสียต่อองค์กรคือ อาจจะทำให้ลูกค้าไม่พอใจหรือเสียโอกาสทางการตลาดได้ แต่ถ้า ประเมินราคาต่ำเกินไป ก็อาจจะส่งผลให้ในการทำงานจริงนั้น อาจจะทำให้ขาดทุนในระหว่างดำเนินการได้ ดังนั้นในการประเมินค่าใช้จ่ายจะต้องทำการประเมินอย่างรอบคอบ ทั้งค่าใช้จ่ายในการพัฒนาและค่าใช้จ่ายในส่วนอื่นๆอย่างเหมาะสม ซึ่งในการประเมินค่าใช้จ่ายให้ได้อย่างเหมาะสมนั้นจะต้องเลือกวิธีการในการประเมินราคาที่เหมาะสมกับองค์กรด้วย การประเมินราคานั้นถึงจะมีประสิทธิภาพสูงสุด