Cost estimate

1. CSE322 Summary: Software Cost Estimation
การประเมิ น ต้ น ทุ น ซอฟต์ แ วร์
ในการประเมินค่าใช้จ่ายในการพัฒนาซอฟต์แวร์เป็นเรื่องสำาคัญเพราะจะ
เป็นสิ่งบอกถึงการได้มาซึ่งโครงการนั้นๆ ถ้ามีการประเมินราคาผิดพลาดมากกว่า
ความเป็นจริง ก็อาจจะส่งผลเสียต่อองค์กรคือ อาจจะทำาให้ลูกค้าไม่พอใจหรือเสีย
โอกาสทางการตลาดได้ แต่ถ้า ประเมินราคาตำ่าเกินไป ก็อาจจะส่งผลให้ในการ
ทำางานจริงนั้น อาจจะทำาให้ขาดทุนในระหว่างดำาเนินการได้
ดังนั้นในการประเมินค่าใช้จ่ายจะต้องทำาการประเมินอย่างรอบคอบ ทั้งค่า
ใช้จ่ายในการพัฒนาและค่าใช้จ่ายในส่วนอื่นๆอย่างเหมาะสม ซึ่งในการประเมิน
ค่าใช้จ่ายให้ได้อย่างเหมาะสมนั้นจะต้องเลือกวิธีการในการประเมินราคาที่เหมาะ
สมกับองค์กรด้วย การประเมินราคานั้นถึงจะมีประสิทธิภาพสูงสุด
เทคนิ ค ที ่ ใ ช้ ใ นการประเมิ น ต้ น ทุ น ซอฟต์ แ วร์
เทคนิคที่ใช้ในการประเมินต้นทุนซอฟต์แวร์ ได้แก่ การใช้แบบจำาลองอัลกอ
ริทึมเป็นฐานในการประเมิน (Algorithmic cost modeling) การประเมินโดยผู้เชี่ยวชาญ
(Expert judgment) การประเมินโดยการเทียบเคียงกับระบบที่เคยพัฒนามาแล้ว (Estimate
by analogy) การประเมินโดยใช้สูตรการคำานวณ (Parkinson’s law) การประเมินจากราคา
ที่ที่จะทำาให้ได้งาน (Pricing to win) ฯลฯ
การใช้แบบจำาลองอัลกอริทึมเป็นฐานในการประเมิน (Algorithmic cost modeling)
พิจารณาจากการพัฒนาระบบในอดีตซึ่งสามารถบอกได้ว่าการพัฒนาระบบโดย
ขั้นตอนวิธีที่ใช้จะมีบรรทัดคำาสั่งมากน้อยเท่าใด และประเมินต้นทุนและแรงงาน
จากปริมาณบรรทัดคำาสั่งที่ต้องเขียน
การประเมินโดยผู้เชี่ยวชาญ (Expert judgment) เป็นเทคนิคที่ใช้ผู้เชี่ยวชาญ
หลายคนเป็นที่ปรึกษาโครงการ ผู้เชี่ยวชาญแต่ละคนจะประเมินต้นมุนและนำาเข้าที่
ประชุมเพื่อทำาการเปรียบเทียบและทำาการตกลงกำาหนดเป็นต้นทุนของการพัฒนา
ระบบ
การประเมินโดยการเทียบเคียงกับระบบที่เคยพัฒนามาแล้ว (Estimate by
analogy) เป็นเทคนิคการประเมินต้นทุนการพัฒนาซอฟต์แวร์ใหม่โดยเทียบกับ
ซอฟต์แวร์ในโดเมนเดียวกันที่ได้พัฒนาสำาเร็จแล้ว
การประเมินโดยใช้สูตรการคำานวณ (Parkinson’s law) ตามกฎของ Parkinson
แรงงานที่ใช้ในการทำางานขั้นอยู่กับขึ้นอบู่กับทรัยากรที่มีอยู่มากกว่า ตัวอย่างเช่น
ถ้าต้องทำาการส่งมอบซอฟต์แวร์ภายใน ١٢ เดือน และมีแรงงานอยู่ ٥ คน

2. หมายความว่างานนี้จะต้องใช้แรงงานในการพัฒนาระบบ เท่ากับ ١٢ x 5 คน-เดือน
(person-months)
การประเมินจากราคาที่ที่จะทำาให้ได้งาน (Pricing to win) เป็นการประมาณ
ต้นทุนจากงบประมาณที่ลูกค้ามีให้สำาหรับโครงการการพัฒนาระบบ เทคนิคการ
ประเมินต้นทุนแบบนี้จะขึ้นอยู่กับงบประมาณของโครงการมากว่าฟังก์ชันการ
ทำางานของซอฟต์แวร์
การวั ด ขนาดของซอฟต์ แ วร์
การประเมินต้นทุนซอฟต์แวร์ขึ้นอยู่กับกรรมวิธีที่ใช้ในการวัดขนาดของ
ซอฟต์แวร์ ซึ่งมี 2 ลักษณะ คือ Line of Code (LOC) และ Function Point (FP)
วิธีการวัดขนาดของซอฟต์แวร์แต่ละแบบมีหลักการดังนี้
วิธีการวัดขนาดของซอฟต์แวร์ แบบนับบรรทัดของคำาสั่ง (Line of Code -
LOC)
- นับเฉพาะบรรทัดที่มีการจัดส่งเป็น Source Code ไม่นับรวม
ส่วนของการทดสอบ (Test Driver) หรือส่วนงานที่รองรับการ
ทำางานอื่นๆ
- นับเฉพาะบรรทัดที่พัฒนาโดยบุคลากร ไม่นับรวมสิ่งที่ระบบ
งานสามารถ Generate ได้อัตโนมัติ
- ถือว่าหนึ่งคำาสั่ง คือ หนึ่ง Line of Code <LOC>
- นับส่วนของการประกาศค่า (Declaration) เป็นส่วนของ
Instruction
- ไม่นับส่วนของการขยายความ หรือ Comment
วิธีการวัดขนาดของซอฟต์แวร์แบบฟังก์ชันพอยต์ (Function Point - FP)
- เป็นการวัดขนาดของซอฟต์แวร์ด้วยการนับจำานวนฟังก์ชันการ
ทำางานของโปรแกรม การวัดด้วยฟังก์ชันพอยต์ จะมุ่งเน้นที่
การวัดด้วยฟังก์ชัน หรือการวัดโดยผ่านมุมมองความต้องการ
ของซอฟต์แวร์
- ช่วยลดปัญหาด้านความแตกต่างของภาษาโปรแกรมที่ใช้
FP (Function Point) เป็นลักษณะของการวัดขนาดของซอฟต์แวร์ที่ไม่ได้
มุ่งเน้นในเรื่องของ จำานวนบรรทัด เพราะ บางทีการเขียนโปรแกรม ในเรื่อง
เดียวกัน แต่ใช้คนละภาษาแต่ผลลัพธ์ออกมาเหมือนกัน อาจจะได้ LOC ที่ไม่เท่ากัน
ก็ได้ ซึ่งไม่สามารถวัดได้ว่า คนที่เขียนโปรแกรมด้วย ขนาดของ LOC ที่ยาวกว่า

3. จะมีประสิทธิภาพการทำางานที่ดีกว่า เสมอไป ในการวัดขนาดแบบ FP จะไม่สนใจ
ความยาวของโปรแกรม และไม่สนใจว่าจะเขียนจากภาษาใด แต่จะนับจากผลลัพธ์
ฟังก์ชันที่ระบบสามารถรองรับความต้องการของผู้ใช้งานได้
กระบวนการนับ FP มี ٦ ขั้นตอน
ขั้นที่ 1 นำา ความต้องการที่จัดการเก็บรวมรวมไว้มาทำาการแบ่งประเภท
ของฟังก์ชันพอยต์
ขั้นที่ 2 ประเมินความซับซ้อนของฟังก์ชัน
ขั้นที่ 3 เปรียบเทียบความซำ้าซ้อน เพื่อให้ได้ระดับความซำ้าซ้อนเพื่อ
คำานวณฟังก์ชันพอยต์ที่ยังไม่ได้ปรับค่า
ขั้นที่ 4 คำานวณตัวแปรปรับค่าตามลักษณะเฉพาะ
ขั้นที่ 5 คำานวณจำานวนฟังก์ชนที่ผ่านการปรับค่า
ั
ขั้นที่ 6 ฟังก์ชันพอยต์ที่ผ่านการปรับค่า สามารถนำาไปคำานวณแบบ LOC
ได้
แบบจำ า ลองการประมาณต้ น ทุ น ซอฟต์ แ วร์
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 : จะรวมปัจจัยที่มีผลกระทบต่อราคา
ทั้งหมดในทุกๆขั้นตอน เช่น ในกรณีการวิ้เคราะห์ และ การออกแบบ
The COCOMO model สามารถแบ่งออกเป็น 3 ประเภทโครงการดังนี้
• ประเภท Organic เหมาะสำาหรับใช้กับโครงการพัฒนาซอฟต์แวร์ที่มีขนาด
เล็ก มีนวัตกรรมใหม่เพียงเล็กน้อย เวลาที่ใช้ในการพัฒนามีความยืดหยุ่น
มากและการพัฒนามีลักษณะคงที่
• ประเภท Semi Detached เหมาะสำาหรับใช้กับโครงการพัฒนาซอฟต์แวร์ที่
มีขนาดกลาง มีนวัตกรรมใหม่เป็นบางส่วน ระยะเวลาที่มีความเหมาะเหมาะ
สมและไม่มีข้อจำากัดมากนัก ลักษณะการพัฒนมีความซับซ้อนในระดับปาน
กลาง

4. • ประเภท Embedded เหมาะสำาหรับใช้กับโครงการพัฒนาซอฟต์แวร์ที่มี
ขนาดใหญ่ มีนวัตกรรมใหม่ค่อนข้างมาก ใช้ระยะเวลาสั้น ต้องเร่งด่วน และ
มีข้อจำากัดสูง ลักษณะการพัฒนมีความซับซ้อน
COCOMO model มีการประมาณการ E=Effort และ D=Development Time
ดังนี้
ตั ว อย่ า ง สมมติให้โครงการพัฒนาซอฟต์แวร์ในระดับ Organic หนึ่งได้ทำาการ
คำานวณ จำานวนบรรทัดออกมาได้ 33.2 KLOC จงหาว่าโครงการนี้จะต้องใช้
จำานวนทั้งหมดกี่คน และ ระยะเวลาประมาณเท่าไหร่