550 likes | 724 Vues
310414 Software Engineering. Cost Estimation. Cost Estimation. การวิเคราะห์ต้นทุน วิเคราะห์ก่อนโครงงานจะเริ่มต้น. [Jalote1991]. Why do we estimate?. เพื่อเอื้อโอกาสให้ทีมพัฒนาและลูกค้าได้มีโอกาสวิเคราะห์กำไรต้นทุน. [Jalote1991]. เป็นสิ่งสำคัญมากในการควบคุมการดำเนินโครงงาน
E N D
310414Software Engineering Cost Estimation 310414 - Lecture
Cost Estimation • การวิเคราะห์ต้นทุน • วิเคราะห์ก่อนโครงงานจะเริ่มต้น 310414 - Lecture [Jalote1991]
Why do we estimate? • เพื่อเอื้อโอกาสให้ทีมพัฒนาและลูกค้าได้มีโอกาสวิเคราะห์กำไรต้นทุน 310414 - Lecture [Jalote1991]
เป็นสิ่งสำคัญมากในการควบคุมการดำเนินโครงงานเป็นสิ่งสำคัญมากในการควบคุมการดำเนินโครงงาน ความคลาดเคลื่อนจากการประมาณสามารถใช้เป็นเกณฑ์ในการ วัดสถานะของโครงงาน วัดคุณภาพในการจัดการบุคคลากร การประมาณต้นทุน จัดเป็นขั้นตอนหลักของการวางแผน Cost Estimation for Developers 310414 - Lecture [Jalote1991]
Uncertainties in Cost Estimation • ความไม่แน่นอนในการประมาณต้นทุน ความคลาดเคลื่อนในการประมาณ 310414 - Lecture [Jalote1991]
เทคนิคในการประเมินราคาซอฟต์แวร์เทคนิคในการประเมินราคาซอฟต์แวร์ • ความแม่นยำในการประเมินราคามีความสำคัญดังนี้คือ • สามารถคิดกำไรที่ได้มาและระบบการเงินในบริษัท • สามารถคำนวณการใช้ทรัพยากร HW/SW ได้อย่างถูกต้อง • สามารถคำนวณราคาต่อโปรเจ็คย่อย ๆ ได้ • ในการประเมินราคาเราควรที่จะบวกค่าความเที่ยงตรงไว้ + - 20% 310414 - Lecture
Estimation Basics • Models • Metrics • Historical Data 310414 - Lecture
Estimation Accuracy • แม่นยำในการประมาณขนาด • แม่นยำในการประมาณกำลังบุคลากรและเวลาที่ใช้จากขนาด • แม่นยำในการวางแผนที่แสดงถึงความสามารถที่แท้จริงของทีมงาน • ความคงที่ของความต้องการของผลิตภัณฑ์ และสภาพแวดล้อมต่างๆ 310414 - Lecture
HOW NOT TO ESTIMATE COST มีองค์ประกอบภายนอกที่ทำให้การประมาณค่าไม่อาจทำได้หรือไม่ต้องทำ เช่น • โครงการซอฟต์แวร์ผู้บริหารกำหนดให้ทำเสร็จภายใน 12 เดือน ดังนั้นผู้พัฒนาระบบซอฟต์แวร์จะมีเวลาไม่เกินนี้จะต้องทำให้เสร็จ • โครงการซอฟต์แวร์ที่ต้องมีการประกวดราคาซึ่งเราทราบว่าคู่แข่งเสนอราคา 1 ล้านบาท เมื่อเป็นเช่นนี้เราต้องชนะการประกวดจึงเสนอราคาไป 9 แสนบาท • จริงๆแล้วโครงการใช้เวลา 1 ปีแต่ไม่สามารถบอกหัวหน้าได้หรือบอกเขาก็ไม่เชื่อจึงต้องกำหนดเวลาพัฒนาไว้ 10 เดือน 310414 - Lecture
DELPHI METHOD • ผู้บริหารหรือผู้มีอำนาจในองค์กรมีอิทธิพลต่อการประมาณราคาและเวลาในการพัฒนา • Delphi Method คือวิธีที่ผู้เชี่ยวชาญแต่ละคนเขียนรายละเอียดการประมาณการลงบนกระดาษแล้วผู้ประสานงานจะเก็บผลการประมาณการมารวมกัน แล้วแจกจ่ายให้แต่ละผู้เชี่ยวชาญพิจารณาของกันและกัน ทำวนเวียนเช่นนี้จนกระทั่งผลลัพธ์ที่ได้เห็นพ้องกันระหว่างผู้เชี่ยวชาญในกลุ่ม 310414 - Lecture
An Expected Value • ให้ผู้เชี่ยวชาญประมาณการค่าใช้จ่าย 3 ค่า คือ • ค่าแรกเป็นค่าดีที่สุดเช่นกรณีที่เสร็จก่อนเวลาเรียกว่า Optimistic Estimateแทนด้วยQ • ค่าที่สองเป็นค่าที่คิดว่าตรงความเป็นจริงหรือเป็นไปได้มากที่สุดเรียก Realistic Estimateแทนด้วย R • ค่าที่สาม เป็นค่าที่คิดว่าเลวร้ายที่สุดหรือแย่ที่สุดเท่าที่เป็นไปได้ เรียกว่า Pessimistic Estimateแทนด้วย S • แล้วใช้ความรู้เกี่ยวกับ beta distribution หาความสัมพันธ์ 310414 - Lecture
An Expected Value • EV = (Q + 2R + P) / 4 หรือ • EV = (Q + 4R + P) / 6 • Q = optimistic estimation • R = realistic estimation • P = prestimistic estimation [Conger1994] [Pressman1997] aka a 3-point estimated value 310414 - Lecture
Estimation Techniques (1) • Decomposition Techniques : • กระจายงานออกเป็นงานย่อยๆ เพื่อที่จะประมาณได้ โดยในงานย่อยนั้นอาจจะนำวิธีการคำนวณทางคณิตศาสตร์มาใช้ก็ได้ • Empirical models (Algorithmic Cost Modeling) : • ใช้การคำนวณทางคณิตศาสตร์ หาความสัมพันธ์ระหว่างสิ่งที่ประมาณได้กับอีกสิ่งหนึ่ง • Based on last projects (Estimation by analogy) 310414 - Lecture ([Boehm1981] in [Sommerville1996]) and ([Pressman1997])
Estimation Techniques (2) • Expert judgement • Parkinson’s Law : • ต้นทุนขึ้นกับทรัพยากรที่มีให้ • Pricing to win • ต้นทุนที่ใช้ก็ต้นทุนที่มีให้ 310414 - Lecture ([Pressman1997])
Decomposition Techniques • Problem-Based Estimation • Process-Based Estimation 310414 - Lecture
Problem-Based Decomposition • แบ่งงานเป็นงานย่อยๆ โดยใช้ขั้นตอนตามปัญหา • ใช้ LOC และ FP 310414 - Lecture
Function user interface and control facilities two-dimensional geometric analysis three-dimensional geometric analysis … estimated line of code Estm. LOC 2300 5300 6800 … 33200 An Example of LOC Estm. Using 3-point estimated values 310414 - Lecture
An Example of FP Estm info domain value number of inputs number of outputs … count-total opt. 20 12 … likely 24 15 … pess. 30 22 … ets. 24 16 … w 4 5 … FP 96 80 … 318 FP estm = count-total * factor FP estm = 372 310414 - Lecture
Process-Based Decomposition • แบ่งการประมาณเป็นงานย่อย ตามกระบวนการขั้นตอนพัฒนา • Planning • Analysis • Design • Code • Test 310414 - Lecture
Empirical Models • เป็นการประมาณกำลังบุคลากรจากขนาดของงานที่อาจจะประมาณโดยใช้วิธีต่างๆ โดยการกระจายงาน • Models : • Single-Variable Models • COCOMO Model 310414 - Lecture
Single-Variable Model b • EFFORT = a * SIZE • EFFORT = a * SIZE + b • ฯลฯ • ค่าคงที่ a และ b คำนวณจากข้อมูลในอดีต 310414 - Lecture
b • E = a (KLOC) x EAF • D = c E d COCOMO Model effort (person-month) duration (month) • a b c และ d : constant ที่ขึ้นกับประเภทของ software • EAF : Effort Adjustment Factor 310414 - Lecture [Boehm1981,1984] from [Jalote1991] and [Pressman1997]
COCOMO project types • Organic • a simple small application developed by a small team with good application experience. • Semidetached • โครงการที่มีขนาดหรือความซับซ้อนปลานกลาง • Embedded • โครงการพัฒนาซอฟต์แวร์ทีมีข้อจำกัดสูง. 310414 - Lecture
Organic • ใช้ทีมขนาดเล็ก(1-3คน) ภายใต้ HW, SW และการประยุกต์ที่คุ้นเคย • บุคลากรที่เกี่ยวข้องกับการพัฒนามีประสบการณ์เป็นอย่างดีเกี่ยวกับซอฟต์แวร์ที่มีลักษณะคล้ายๆกันมาก่อน • กิจกรรมต่างๆเริ่มต้นได้อย่างรวดเร็ว • มีขนาดเล็ก 310414 - Lecture
Embedded • เป็นซอฟต์แวร์ที่พัฒนาภายใต้สิ่งแวดล้อมที่มีความซับซ้อน มีความเสี่ยงสูงและมีเงื่อนไขที่ยุ่งยาก • ซอฟต์แวร์ที่พัฒนาแล้วจะถูกนำไปใช้ภายใต้สิ่งแวดล้อมที่ไม่มีความยืดหยุ่น • เช่นซอฟต์แวร์ที่ใช้ควบคุมการขึ้นลงของเครื่องบิน ซอฟต์แวร์ควบคุมการยิงขีปนาวุธ 310414 - Lecture
Semi-detached • เป็นซอฟแวร์ที่มีขนาดและความยากปานกลาง • ทีมงานประกอบด้วยกลุ่มบุคคลที่มีทั้งประสบการณ์และไม่มีประสบการณ์ • อยู่ระหว่างประเภท Organic และ Embeded 310414 - Lecture
System organic semidetached embedded a 3.2 3.0 2.8 b 1.05 1.12 1.20 c 2.5 2.5 2.5 d 0.38 0.35 0.32 Constants fordifferent project types 310414 - Lecture
Effective Adjustment Factor • Factor ที่คิดจากความต้องการในคุณสมบัติต่างๆ ของ software นั้น (cost driver attributes) • product attribute • computer attribute • personal attribute • project attribute • โดย Factor นี้จะมีค่ามากหรือน้อยขึ้นกับระดับของคุณลักษณะต่างๆ 310414 - Lecture
Product Attributes • Reliability requirement • Database size • Product complexity 310414 - Lecture
Computer attributes • Execution time constraints • Storage constaints • Virtual machine volatility • Computer turnround time 310414 - Lecture
Personnel attributes • Analyst capability • Virtual machine experience • Programmer capability • Programming language experience • Application experience 310414 - Lecture
Project attributes • Modern programming practices • Software tools • Required development schedule 310414 - Lecture
Example • จากการประมาณขนาดโดยใช้ problem-based decomp. ได้ว่า • 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 310414 - Lecture
Example (cont.) • EAF = 1.15 * 1.06 * 1.13 * 1.17 = 1.61 • Ei = 3.2 * (3 ^ 1.05) = 10.14 PM • E = 1.61 * 10.14 = 16.5 PM • ใช้กำลังบุคลากรประมาณ 16.5 คน-เดือน • D = 2.5 (16.5 ^ 0.38) = 7.23 M • ใช้เวลาประมาณ 7.23 เดือน 310414 - Lecture
การใช้ Function Point • วัดขนาดและความซับซ้อนโดยใช้เป็น Function ที่ต้องพัฒนา • ไม่ขึ้นอยู่กับภาษา เครื่องมือหรือ กรรมวิธี • สามารถประเมินใหม่ได้เนื่องจาก Function สามารถเปลี่ยนแปลงได้ง่าย • ไม่ค่อยเหมาะกับโปรแกรมทางด้านเทคนิคเท่าไหร่ 310414 - Lecture
การคิดค่า FP สามารถหาได้จากสมการดังนี้ • FP = Total weighted count * (0.65 + (0.1* SUM(complexity adjustments))) • Total weighted count - ได้จากตารางที่กำหนดให้ • complexity adjustments - ได้จากการตอบคำถาม 14 คำถาม 310414 - Lecture
Function Point Questions( Rating Scale from 0 to 5) 1. Is reliable backup and recovery required? 2. Are data communications required? 3. Are any functions distributed? 4. Is performance critical? 5. Is operational environment volume high? 6. Is on-line data entry required? 7. Does on-lines data entry require multiple screens or operations? 310414 - Lecture
Function Point Questions( Rating Scale from 0 to 5) 8. Is on-line files update used? 9. Are quires, screens, reports, or files complex? 10. Is processing complex? 11. Is code design for reuse? 12. Does implementation include conversion and installation? 13. Are multiple installations and/or multiple organizations involved? 14. Does application design facilitate user changes? 310414 - Lecture
Function Point Weight • Simple = 22 • Average = 30 • Complex = 44 FP = 22 * ( 0.65 + ( 0.1 * 36)) = 93.5 310414 - Lecture
Line of Code/FP Language 25 4GL 25 SQL 100 Cobol • Number of Lines of Code per Function Point * Number of Function Points = Total Line of Code เพราะฉะนั้น KLOC = 93.5*25 = 2.337 K 310414 - Lecture
นำไปคิดกับ COCOMO Model • E = 2.4 x (2.33)1.05 • E = 5.83 คน ต่อ เดือน • D = 2.5 x (5.83)0.38 • D = 4.88เดือน 310414 - Lecture
ปัจจัยอื่นที่มีผลต่อราคาปัจจัยอื่นที่มีผลต่อราคา • ขนาดฐานข้อมูล • ความซับซ้อน • ข้อจำกัดด้านฮาร์ดแวร์ • ความสามารถประสบการณ์ของโปรแกรมเมอร์ • การใช้ Tool ในการพัฒนา • กำหนดการส่งงาน • ประสบการณ์ด้านการพัฒนา 310414 - Lecture
ปัจจัยความต้องการ - ความต้องการ - ราคาของ ปัจจัยข้อจำกัด - การเงิน - ทรัพยากร กระบวนการประเมิน ราคาซอฟต์แวร์ Effort ปัจจัยอื่น ๆ - ความเสี่ยง - ฯลฯ 310414 - Lecture
ควรใช้โมเดลในการประเมินราคาหรือไม่ ? • ความไม่น่าเชื่อถือของโมเดล • ความต่างกันของการใช้ค่าคงที่ • ดังนั้น • อาศัยการเปรียบเทียบจากโครงการเก่า ๆ ที่เคยทำ • ประสบการณ์ของผู้ประเมิน 310414 - Lecture
การประเมินราคา • การประเมินราคาไม่ได้ทำเพียงครั้งเดียวจบ • ระยะแรกก่อนการประมูล • ระยะสองทำหลังการประมูล • หัวหน้าทีมต้องพยายามประเมินราคาบ่อย ๆ เพื่อให้เหมาะสมกับราคาปัจจุบัน 310414 - Lecture
การประเมินราคาในทางปฏิบัติการประเมินราคาในทางปฏิบัติ • ดูความต้องการหลัก แล้วแบ่งให้เป็นความต้องการย่อย • งานที่ต้องทำ & ผลลัพธ์ที่ต้องได้ • แปลงเป็นหน้าจอที่ต้องสร้าง • หน้าจอกรอกข้อมูล • หน้าจอสอบถามข้อมูล • หน้าจอรายงาน • หน้าจอบริหารระบบ 310414 - Lecture
การประเมินราคาในทางปฏิบัติการประเมินราคาในทางปฏิบัติ • คำนวณหน้าจอที่ต้องสร้างเป็น N หน้าจอ แล้วให้ B เป็นราคาต่อหน้าจอ • B ? • ค่าของ B อยู่ในช่วง 3,000-20,000 ~ 5,000-13,000 310414 - Lecture
ตัวอย่าง • สมมุติประเมินว่าระบบต้องมีหน้าจอ 65 หน้าจอ รายงานที่ต้องทำ 15 รายงาน รวมเป็น 65 ชิ้นงาน • ใช้ราคากลางที่ 9,000 บาทต่อชิ้น ราคาเบื้องต้นน่าจะเป็น 585,000 บาท • โปรแกรมเมอร์หนึ่งคนเฉลี่ยทำได้ 6 หน้าจอต่อเดือน งานชิ้นนี้น่าจะใช้ 10 คน-เดือน • ระยะเวลางาน 5 เดือนเพราะฉะนั้นใช้โปรแกรมเมอร์ 10/5=2 คนช่วยกันทำงาน 310414 - Lecture
ทีมงานประกอบด้วย • หัวหน้าโครงการ 1 คน ตลอดโครงการ (นั้นคือ 0.2 คนต่อเดือน = อาทิตย์ละครั้ง) • เลขานุการพิมพ์เอกสาร 2 คน (ใช้สองเดือนหลัง) • โปรแกรมเมอร์ 2 คน • หัวหน้าโครงการ 80,000 x 1 = 80,000 เลขานุการ 20,000 x 2 = 40,000 โปรแกรมเมอร์ 60,000 x 5 x 2 = 600,000 720,000 310414 - Lecture
5 Individual-Simple Program Team- Large Complexity จำนวนบรรทัดต่อปี ต่อคน Team-Medium-Complexity 1000 ขนาดของโปรแกรม x 1000 บรรทัด ตัวประกอบที่มีผลต่อโครงการ • ระดับโครงการ • เงินเดือนของโปรแกรมเมอร์ • ระยะเวลาการพัฒนา • กรรมวิธีการพัฒนา 310414 - Lecture