1. Chapter 6 The Work Breakdown Structure and Project Estimation

2. Chapter 6 Objectives การสร้าง work breakdown structure. อธิบายถึงความแตกต่างระหว่าง deliverable และ milestone. อธิบายถึงวิธีการประมาณโครงการแบบต่าง ๆ และการนำมาใช้งาน อันได้แก่ Delphi technique, time boxing, top-down estimation, และ bottom-up estimation. อธิบายถึงแนวทาง software engineering estimation และการนำมาใช้งาน อันได้แก่ lines of code (LOC), function point analysis, COCOMO, และ heuristics.

3. Project Time Management as defined in PMBOK Project Time Management ประกอบด้วย การกำหนดการดำเนินงาน ( Activity definition) การจัดอนุกรมของการดำเนินงาน ( Activity sequencing) การประมาณช่วงเวลาในการดำเนินงาน ( Activity duration estimation) การสร้างตารางเวลา ( Schedule development) การควบคุมให้เป็นไปตามตารางเวลา ( Schedule control) ในบทนี้จะมุ่งไปที่ Activity Definition และ Activity Estimation

4. The Work Breakdown Structure (WBS) WBS แสดงถึงการแยกย่อยงานที่ต้องกระทำอย่างเป็นตรรกะ และ มุ่งเน้นว่า ผลผลิต การให้บริการ หรือ ผลลัพธ์ที่ได้ จากการจัดแบ่งข้างต้นเป็นอย่างไร ดังนั้น WBS จึงเป็นโครงร่างที่แสดงให้เห็นว่างานอะไรบ้างที่ต้องทำ Gregory T. Haugan (2002) A work breakdown structure (WBS) คือ กลุ่มของงาน ( ในเชิง deliverable) ที่ต้องทำในโครงการหนึ่ง ๆ ตามที่กำหนดไว้ในขอบเขตของโครงการทั้งหมด ถือว่าเป็นเอกสารพื้นฐานในการบริหารโครงการ เพราะว่า มันจะถูกนำมาใช้การ วางแผนและบริหารโครงการในแง่ของตารางเวลา ค่าใช้จ่าย และ การเปลี่ยนแปลง

5. Work Package การแตกงานออกมา ( WBS decompose) หรือแบ่งงาน (subdivide) ของโครงการหนึ่ง ๆ ออกเป็นองค์ประกอบเล็ก ๆ ( small component) เพื่อให้ เป็นหน่วยงานที่บริหารจัดการได้ง่าย เรียกว่า Work package จึงถือว่าเป็นเอกสารพื้นฐานในการบริหารโครงการ เพราะว่า มันจะถูกนำมาใช้การ วางแผนและบริหารโครงการในแง่ของตารางเวลา ค่าใช้จ่าย และ การเปลี่ยนแปลง

6. Deliverables and Milestones มุมมองที่ได้จาก WBS จะรวมถึง milestone เอาไว้ด้วย ดังนั้น milestone จะหมายถึง เหตุการณ์ ( event) หรือสิ่งที่ได้รับ (achievement) ที่สำคัญ ( significant) อันเป็นสถานการณ์ที่แสดงให้ว่า สิ่งที่ต้องส่งมอบ (deliverable) สำเร็จเสร็จสิ้นแล้ว หรือ เฟสนั้น ๆ ได้ถูกดำเนินการจนเสร็จสิ้นแล้ว Deliverable กับ Milestone จะมีความสัมพันธ์กันอย่างใกล้ชิด แต่ไม่ใช่สิ่งเดียวกัน Deliverables ( มักจะเป็นสิ่งของ ) Tangible, verifiable work products หรือ Reports, presentations, prototypes, etc. Milestones ( มักจะเป็นสิ่งที่ต้องการที่จะไปให้ถึง หรือ ได้มา มองในเชิงเป้าหมายมากกว่า ) Significant events or achievements Acceptance of deliverables or phase completion Cruxes (proof of concepts) Quality control Keeps team focused

7. Developing the WBS Develop work packages for each of the phases and deliverables defined in the Deliverable Structure Chart (DSC)

8. Approaches to Developing WBSs การใช้แนวทาง : บางองค์กร เช่น DoD ได้ให้แนวทาง (guideline) ในการเตรียม WBS เอาไวดังนี้ Analogy approach : ทบทวน WBS จากโครงการต่าง ๆที่คล้ายกัน แล้วทำการปรับแต่งโครงการของท่าให้เหมาะสม Top-down approach : เริ่มด้วย largest items ของโครงการแล้วแตกแยกย่อยออกมาเรื่อย ๆ Bottom-up approach : เริ่มด้วย detailed tasks แล้วจึงรวมเข้าหากัน Mind-mapping approach : เขียนงานต่าง ๆ ในเชิง non-linear format และ สร้าง WBS ขึ้นมา

9. Project Life Cycle ประกอบไปด้วย 5 เฟส 1 2 3 4 5 SDLC

10. Systems Development Life Cycle (SDLC) เวลาเราจะพัฒนาระบบ ( โปรแกรม ) อะไรสักอย่างหนึ่ง จะประกอบไปด้วย 5 เฟส เช่นกัน

11. The Relationship Between the PLC & SDLC

12. An IT Project Methodology

13. ดูให้เข้าใจส่วนใดคือ PLC ส่วนใดคือ SDLC ในบล็อกนี้คือ SDLC และมันก็คือ Execute And Control ของ PLC

14. Work Breakdown S tructure Phase Deliverable Activities/Tasks Deliverable Completion Phase completion

15. The WBS Should Follow the Work Package Concept

16. Developing the WBS WBS ควรอยู่ในรูปของ Deliverable-Oriented (Project ต้องสร้างบางสิ่งบางอย่างออกมาเสมอ ไม่งั้นก็ไม่รู้ว่าจะทำไปทำไม ) WBS ต้องสนับสนุน Project's MOV ต้องมั่นใจว่า WBS สอดรับกับการส่งมอบ project’s deliverable ทุก ๆ เรื่องที่ได้กำหนดไว้ใน project scope ต้องครบถ้วน 100% ( 100 percent rule) ระดับของรายละเอียดต้องสนับสนุนการวางแผนและการควบคุมโครงการ การสร้าง WBS ควรผู้ที่จะต้องทำงานเข้ามาร่วมด้วย Learning Cycles และ Lessons Learned สามารถช่วยสนับสนุนการสร้าง W BS

17. Basic Principles for Creating WBSs 1. หน่วยงานหนึ่ง ๆ จะต้องปรากฏอยู่ที่เดียวใน WBS. 2. งานภายใต้ WBS item หนึ่ง ๆ คือ ผลรวมของรายการทั้งหลายของ WBS ที่อยู่ต่ำลงไป 3. แต่ละ WBS item คือ การสนองตอบ ( หรือทำงาน ) ในแต่ละเรื่อง ไม่ว่าจะใช้คนทำเรื่องนั้น ๆ กี่คนก็ตาม 4. WBS จะต้องใช้แนวทางเช่นเดียวกันเสมอในการที่จะทำงานหนึ่ง ๆ และมันจะต้องสนับสนุน project team ก่อน ส่วนเรื่องอื่นค่อยทำถ้าเป็นไปได้ 5. Project team members จะต้องมีส่วนร่วมในการพัฒนา WBS เพื่อมั่นใจได้ว่าจะมีความต่อเนื่องและเข้าใจ

18. 6. แต่ละรายการของ WBS จะต้องจัดทำเป็นเอกสารเพื่อมั่นใจได้ว่ามีความเข้าใจชัดเจนถึงขอบเขตของงาน ( อะไรที่รวมอยู่และต้องทำ อะไรที่บันทึกไว้แต่ไม่ต้องทำ ) 7. WBS ต้องเป็นเครื่องมือที่มีความยืดหยุ่นเพี่อรองรับการเปลี่ยนแปลงใด ๆ ที่อาจเกิดขึ้นได้ แต่ในขณะเดียวกัน จะต้องรักษาการควบคุมการทำงานในโครงการให้เป็นไปตาม scope statement.

19. Project Estimation เมล็ดพันธุ์แห่งความหายนะหลัก ๆ ของซอฟท์แวร์มักจะถูกหว่านลงไปไปในช่วงสามเดือนแรกของการเริ่มต้นโครงการทางด้านซอฟต์แวร์ ตารางเวลาที่เร่งรีบ คำสัญญาที่ไร้เหตุผล เทคนิคการประมาณการไม่เป็นแบบมืออาชีพ และ ปราศจากการใส่ใจของฟังก์ชันเกี่ยวกับการบริหารโครงการ สิ่งเหล่านี้คือแฟกเตอร์ทั้งหลายที่ก่อให้เกิดปัญหาต่าง ๆ ขึ้นมา เมื่อโครงการเดินหน้าไปอย่างไร้ทิศทางไปสู่วันส่งมอบที่เป็นไปได้ยาก หายนะในส่วนที่เหลือย่อมเกิดขึ้นอย่างยากที่จะหลบเลี่ยง T. Capers Jones

20. Pricing and Estimating ผู้บริหารหลายคนถือว่าสิ่งเหล่านี้คือศิลป ( art ) ! สารสนเทศที่ให้แก่ผู้ประมูลรายหนึ่งโดยทั่วไปแล้วจะอยู่ในมือของรายอื่น ๆ ด้วย และนี่คือส่วนสำคัญของกระบวนการวางแผน ( planning process ) สร้างพื้นฐานในการจัดทำมาตรฐานในเรื่อง budgets, man-hours, material costs, contingencies, etc. กลยุทธ์ทางด้านราคาที่เหมาะสมจะถูกสร้างขึ้นมาในแต่ละสถานการณ์

21. Types of Estimates (1) Order of magnitude estimates - ทำโดยไม่มีรายละเอียดของข้อมูลเชิงวิศวกรรม ( engineering data ) - อาจใช้ประสบการณ์จากอดีต - ความถูกต้อง +- 35% ภายในขอบเขตของโครงการณ์ Approximate (rule of thumb) estimates - ทำโดยไม่มีรายละเอียดของข้อมูลเชิงวิศวกรรม - อาจใช้โครงการที่คล้ายกันที่เคยทำมาแล้ว - ความถูกต้อง +- 15%

22. Types of Estimates (2) Definitive (or detailed) estimates - จัดเตรียมจากข้อมูลเชิงวิศวกรรมหรือผู้แทนจำหน่ายที่ถูกกำหนดเอาไว้ อย่างดีแล้ว - ใช้ใบเสนอราคา หน่วยราคา ฯลฯ ความถูกต้อง +- 5% Estimating manual - ถูกพัฒนาขึ้นมาจากช่วงเวลาที่ผ่านมา - ใช้ราคาตามสิ่งที่ได้มา ( จากการสืบค้น ) ความถูกต้อง +-10%

23. Additional Estimating Methods (1) Direct Estimate - ทำการประมาณโดยใช้ผู้มีประสบการณ์ - ต้องการการตัดสินใจขั้นสุดท้าย Estimate by analogy - ทำการเปรียบเทียบโดยใช้การดำเนินการที่คล้ายกัน - ต้องการการตัดสินใจขั้นสุดท้าย Factored method - อาศัยข้อมูลในอดีต - ต้องใช้ equipment lists, sizes - เริ่มด้วยการเสนอราคาของเครื่องมือ ( equipment quotes )

24. Additional Estimating Methods (2) Gross proration method - อาศัยข้อมูลในอดีต - ทำการคัดลอกข้อมูลที่ใกล้เคียงกัน การประมาณลงไปในรายละเอียด ( Detailed estimate ) - ใช้หลักการของการแตกงาน ( WBS ) - ทำการแตกงานย่อยเป็นหลายระดับ วิธีการเสนอราคา ( Quotation method ) - เปรียบเทียบใบเสนราคาจากสามแหล่ง (t hree quotations) - เลือกจากใบเสนอราคาที่ดีที่สุด ( best quotation )

25. Additional Estimating Methods (3) อาศัยคู่มือต่าง ๆ ( Handbook manuals ) อาศัยกราฟการเรียนรู้ ( Learning curves )

26. Estimation Techniques - The Project Management Approach Guesstimating Delphi Technique Time Boxing Top-Down Bottom Up Analogous Estimates (Past experiences) Parametric Modeling (Statistical)

27. Project Estimation อาศัยการคาดเดา ( Guesstimating ) อยู่บนพื้นฐานของความรู้สึก ซึ่งไม่ใช่ความจริง ไม่ใช่วิธีการที่ดีแต่มักถูกนำมาใช้โดย inexperienced project managers อาศัย Delphi Technique ประกอบด้วยผู้ชำนาญการ ( ซึ่งไม่ทราบชื่อ ) หลายคน ให้แต่ละคนทำการประมาณการ ทำการเปรียบเทียบการประมาณการข้างต้น ถ้าใกล้เคียงกันให้นำมาหาค่าเฉลี่ย ถ้าต่างกันมากให้ทำใหม่จนกระทั่งผลที่ได้ใกล้เคียงกัน

28. อาศัยเวลา ( Time Boxing ) กำหนดเวลาของแต่ละการดำเนินการหรืองานหรือสิ่งที่ต้องส่งมอบ มุ่งเน้นที่ team ได้ถ้า team มีประสิทธิภาพ และสามารถทำให้ team เสื่อมลงได้ถ้าใช้บ่อย หรือ ใช้กับ team ที่ไม่มีประสิทธิภาพ เพราะการทำเช่นนี้เป็นการเพิ่ม stress หรือ pressure ให้กับ project team เพื่อให้งานเสร็จ

29. Project Estimation วิธีการประมาณจากบนลงล่าง ( Top-Down Estimating ) Top & middle managers เป็นผู้กำหนด overall project schedule และ / หรือ cost Lower level managers ถูกคาดหวังว่าจะเป็นผู้ breakdown schedule/budget estimates ลงไปสู่ specific activities (WBS) มักจะแสดงในเทอมของต้นทุนอะไรบ้างที่เกิดขึ้นในโครงการและจะใช้นานเท่าใดในเชิงเป็นไปตามคำสั่งของสมาชิกในกลุ่มผู้บริหารระดับสูงผู้คิดว่าพารามิเตอร์ต่าง ๆ ( parameters ) ต่าง ๆ เหล่านั้นถูกต้องเหมาะสม บางทีจะสนองตอบต่อสภาพแวดล้อมทางธุรกิจ บางทีอาจนำไปสู่การหยุดชะงักของโครงการ ( death march project )

30. Project Estimation การประมาณจากล่างขึ้นบน ( Bottom-Up Estimating ) เป็นรูปแบบที่ใช้ประมาณโครงการเป็นส่วนมาก ทำการแบ่งโครงการออกเป็นโมดูลย่อย ๆ แล้วประมาณจากโมดูลเหล่านี้โดยตรง เกี่ยวกับเวลา แรงงาน - ชั่วโมง สัปดาห์ หรือเดือนที่ต้องใช้ในแต่ละโมดูล การประมาณในรูปแบบที่ใกล้เคียงกัน ( Analogous estimating ) โดยอาศัยโครงการอื่น ๆ ที่ใกล้เคียงกับโครงการปัจจุบัน ประมาณฟังก์ชันของการดำเนินงานและระยะเวลา ( Parametric Modeling) โดยพิจารณาจาก : ความซับซ้อนของโมดูล โครงสร้างของโมดูล ทรัพยากรและการสนับสนุนที่กำหนดให้กับโมดูลนั้น ๆ

31. Example WBS with Estimated Task Durations 6.2 Test Results Report 6.2.1 Review test plan with client 1 day 6.2.2 Carry out test plan 5 days 6.2.3 Analyze results 2 days 6.2.4 Prepare test results report and presentation 3 days 6.2.5 Present test results to client 1 day 6.2.6 Address any software issues or problems 5 days

32. Estimating Pitfalls การแปลความหมายของ statement of work (SOW) ผิด การกำหนดขอบเขตไม่ครบถ้วนหรือไม่ถูกต้อง การกำหนดตารางเวลาอย่างหยาบ ๆ หรือ ไม่เหมาะสม ( overly optimistic schedule ) การแตกงานไม่ถูกต้องอย่างเพียงพอ ใช้ทักษะในระดับที่ไม่เหมาะสมกับงานต่าง ๆ บกพร่องในแง่การใส่ใจกับความเสี่ยงต่าง ๆ บกพร่องในแง่การทำความเข้าใจหรือใส่ใจต่อการประมาณต้นทุนหรือเกิดบานปลาย บกพร่องในแง่การใช้เทคนิคการประมาณต้นทุนไม่ถูกต้อง บกพร่องในแง่การใช้ forward pricing rates กับ overhead, general และ administrative, และ indirect costs

33. Software Engineering Metrics and Approaches Software engineering มุ่งเน้นที่กระบวนการ เครื่องมือ และวิธีการในการพัฒนาแนวทางที่มีคุณภาพในการพัฒนาซอฟต์แวร์ ตัววัด ( metric ) เป็นพื้นฐานสำหรับ software engineering และ ใช้อ้างแบบกว้าง ๆ ในการวัดเป้าประสงค์ในการประเมิน computer software. แบ่งได้เป็น 4 แนวทาง Lines of Code (LOC) Function Points COCOMO Heuristics

34. Software Engineering Estimation Model

35. Software Engineering Metrics and Approaches Lines of Code (LOC) มักใช้กันทั่ว ๆ ไปเพื่อเป็นตัววัดขนาดของโครงการ ( project sizing ) ข้อโต้แย้งที่พบเห็นกันส่วนมากได้แก่ จะนับ comments ด้วยหรือไม่ ? จะนับการประกาศตัวแปรด้วยหรือไม่ ? Efficient code vs. code bloat ความแตกต่างของภาษาที่ใช้เขียน ง่ายเมื่อนับภายหลังจากเขียนเมื่อเทียบกับการประมาณล่วงหน้า

36. Software Engineering Metrics and Approaches Function Points การวิเคราะห์ทำบนพื้นฐานของการประเมินชนิดของข้อมูลและการดำเนินกิจกรรม ( data and transactional types ) : Internal Logical File (ILF) คือ Logical file ที่เก็บข้อมูลภายใน application boundary External Interface File (EIF) พิจารณาคล้ายกับ ILF แต่เป็น file ที่ต้องใช้โดย application System อื่น ๆ External Input (EI) คือ process หรือ transaction data ที่เกิดภายนอกและต้องข้ามเข้ามาภายใน ( จากนอกวิ่งเข้าสู่ใน ) External Output (EO) คือ process หรือ transaction data ที่เกิดภายในและต้องข้ามออกไปภายนอก ( จากในวิ่งออกไปสู่ข้างนอก ) External Inquiry (EQ) คือ process หรือ transaction ที่เกิดการรวมอินพุตและเอาต์พุตจากการดึงข้อมูลจากไฟล์ภายนอกหรือภายนอกก็ตามเข้ามาใน application นั้น ๆ อ่านเพิ่มเติมจาก IFPUG standards (www.ifpug.org)

37. The Application Boundary for Function Point Analysis 1 (EIF) 2 3 4 5

38. สมมติว่า ทำการ review application system แล้ว ได้ผลดังนี้ ILF: 3 low, 2 average, 1 complex EIF: 2 averages EI: 3 low, 5 average, 4 complex EO: 4 low, 2 average, 1 complex EQ: 2 low, 5 average, 3 complex แล้วนำไปคำนวณตามตารางดังหน้าถัดไป เพื่อหาค่า UAF (Unadjusted Function Point)

39. Complexity Low Average High Total Internal Logical Files (ILF) _ 3 x 7 = 21 _ 2 x 10 = 20 _ 1 x 15 = 15 56 External Interface Files (EIF) __ x 5 = __ _ 2 x 7 = 14 __ x 10 = __ 14 External Input (EI) _ 3 x 3 = 9 _ 5 x 4 = 20 _ 4 x 6 = 24 53 External Output (EO) _ 4 x 4 = 16 _ 2 x 5 = 10 _ 1 x 7 = 7 33 External Inquiry (EQ) _ 2 x 3 = 6 _ 5 x 4 = 20 _ 3 x 6 = 18 44 Total Unadjusted Function Points (UAF) 200

40. ขั้นตอนต่อไปคือการคำนวณหา VAF Value Adjustment Factor (VAF) based on Degrees of Influence (DI) มักเรียกว่า Processing Complexity Adjustment (PCA) ซึ่งหามาจาก General Systems Characteristics (GSC) ดังแสดงไว้ในหน้าถัดไป โดยกำหนด scale เอาไว้ดังนี้ 0 = not present หรือ not influence 1 = incidental influence 2 = moderate influence 3 = average influence 4 = significant influence 5 = strong influence จะคำนวณหา Total adjusted function points

41. General System Characteristic Degree of Influence Data Communications 3 Distributed Data Processing 2 Performance 4 Heavily Used Configuration 3 Transaction Rate 3 On-line Data Entry 4 End User Efficiency 4 Online Update 3 Complex Processing 3 Reusability 2 Installation Ease 3 Operational Ease 3 Multiple Sites 1 Facilitate Change 2 Total Degrees of Influence 40 Value Adjustment Factor VAF = (TDI * 0.01) + .65 VAF = (40 * .01) + .65 = 1.05 Total Adjusted Function Points = FP = UAF * VAF FP = 200 * 1.05 = 210

42. เมื่อได้ Total Adjusted Function Points (TAFP) แล้ว จะ transformed into development estimates หรือ converted in equivalent LOC ดังตารางในหน้าถัดไป T. Capers Jones ได้ใช้เทคนิคเรียกว่า Backfiring เพื่อทำ direct conversion จาก application’s source code ไปให้ทัดเทียมกับ function point count

43. Source: http://www.theadvisors.com/langcomparison.htm Language Average Source LOC per Function Pont Average Source LOC for a 210 FP Application Access 38 7,980 Basic 107 22,470 C 128 26,880 C++ 53 11,130 COBOL 107 22,470 Delphi 29 6,090 Java 53 11,130 Machine Language 640 134,440 Visual Basic 5 29 6,090

44. COCOMO – C O nstructive CO st MO del Parametric Model ถูกพัฒนาโดย Barry Boehm in 1981 Project types Organic ( Person-Months = 2.4 x (KDSI) 1.05 ) Routine projects เมื่องานที่ต้องทำคาดว่าจะราบลื่นอาจมีปัญหาเล็กน้อยไม่กี่ปัญหา Embedded ( Person-Months = 3.0 x ( KDSI ) 1.12 ) Challenging projects ที่อาจมีหลักการใหม่ ( new ground ) เกิดกับองค์กรหรือ project team Semi-detached ( Person Months 3.36 x ( KDSI ) 1.20 ) อยู่ระหว่าง organic และ embedded Projects อาจไม่ง่ายและตรงไปตรงมาแต่มีระดับความเชื่อมั่นสูงว่า project team จะพบกับสิ่งที่ท้าทาย KDSI = thousands of delivered source instructions, i.e. LOC

45. COCOMO – Effort Example สมมติว่า จะพัฒนา application ที่มีประมาณ 200 total adjusted function point จากตารางที่ผ่านมา สมมติว่า application พัฒนาบน Java จะได้ Line of code ออกมา = 10,600 lines of code ( คำนวณได้จาก 10,600 Java LOC = 200 FP * 53 โดยอาศัยตารางท่านมา ให้ดูในชิ่งของ Java ) และโครงการเป็นแบบ medium difficult จะใช้ Semi-Detached equation ได้เป็น Person-Months = 3.0 * KDSI 1.12 = 3.0 * (10.6) 1.12 = 42.21 1 person-month คือ คนหนึ่งคนทำงาน 152 ชั่วโมง ดังนั้น 42.21 person-months จะใช้คนกี่คน ?

46. COCOMO Models (Duration) Frederick Brooks ชี้ให้เห็นว่า people และ month จะเปลี่ยนกันไม่ได้ เพราะคนแต่ละคนจะทำงานได้ไม่เท่ากัน จึงเสนอแนวทางการคำนวณ duration ดังนี้ Organic Duration = 2.5 * Effort 0.38 Semi-Detached Duration = 2.5 * Effort 0.35 Embedded Duration = 2.5 * Effort 0.32

47. COCOMO Duration Example จากตัวอย่างที่แล้ว ต้องการ 42.21 person-months ดังนั้น duration of development จะคำนวณได้จาก Duration = 2.5 * Effort 0.35 = 2.5 *(42.21) 0.35 = 9.26 months และสามารถคำนวณจำนวณคนได้จาก People Required = Effort / Duration = 42.21 / 9.26 = 4.55

48. The Mythical Man-Month – Frederick Brooks ประการแรก เทคนิคของเราที่ใช้ประมาณการยังไม่ดีพอและไม่สะท้อนให้เห็นถึงสมมติฐานที่ไม่แสดงออกมา ซึ่งจะทำให้โครงการเดินไปได้ด้วยดี ประการที่สอง เทคนิคที่ใช้ประมาณการของเราทำให้สับสนในเชิงผิดหลักการและเหตุผลทางด้านความคืบหน้า และยังแฝงเร้นสมมติฐานว่า จำนวนคนและจำนวนเดือน ( ระยะเวลาที่ทำ ) สามารถสลับเปลี่ยนกันได้ ประการที่สาม เพราะการประมาณเกิดความไม่แน่นอน ส่วน software managers มักจะดื้อรั้นแบบอ้างเหตุผลต่าง ๆ นา เช่น กุ๊กทำอาหารมักจะกล่าวว่า การทำอาหารที่ดีต้องใช้เวลา ดังนั้นท่านต้องรอ แล้วเขาจะบริการคุณดีขึ้น เขาจะเออกเอาใจคุณ ประการที่สี่ การก้าวหน้าตามตารางเวลาขาดการเฝ้ามอง การพิสูจน์ทางเทคนิคและวินัยทางด้านวิศวกรรมถูกพิจารณาว่า software engineering เป็นนวัตกรรมที่เปลี่ยนแปลงอย่างรวดเร็ว

49. The Mythical Man-Month – Frederick Brooks ประการที่ห้า เมื่อตารางเวลาถูกรับรู้ว่าเลื่อนออกไป การสนองตอบทั่ว ๆ ไปจะเป็นการเพิ่ม manpower ให้มากขึ้น เหมือนกับทำการดับไฟด้วยน้ำมันมีแต่ทำให้เลวร้ายลงไป ไฟก็จะลุกมากขึ้นก็จะใช้น้ำมันมากขึ้น แน่นอนว่ามันคงจบลงด้วยความหายนะอย่างแน่นอน

50. COCOMO – COnstructive COst MOdel COCOMO Model Types Basic ( ตัวอย่างที่ผ่านมาใช้โมเดลนี้ ) Intermediate Advanced COCOMO II SLIM vs. COCOMO

51. Software Engineering Metrics and Approaches Heuristics Rules of thumb approach to estimating Estimating Software Costs – Jones ตัวอย่างเช่น When for scheduling a software task: 30% – Planning 20% – Coding 25% – Component test and early system test 25% – System test, all components in hand

52. Automated Estimating Tools COCOMO II SLIM CHECKPOINT

53. Some Examples of Heuristics from Estimating Software Costs by Capers Jones (1988) Each formal design inspection will find and remove 65 percent of the bugs present. Each formal code inspection will find and remove 60 percent of the bugs present. Function points raised to the 0.4 power predict the approximate development schedule in calendar months. Function points divided by 150 predict the approximate number of personnel required for the application. อ่านเพิ่มเติมในหน้า 150

54. What Is the Best Way to Estimate IT Projects? ใช้มากกว่าหนึ่งเทคนิคในการประมาณต้นทุน ถ้าการประมาณได้จากเทคนิคที่แตกต่างกันและใกล้คียงกันให้ใช้ค่าเฉลี่ย การปรับค่าประมาณการ จะขึ้นกับประสบการณ์เป็นหลัก การเจรจาตกลงกันอาจนำไปสู่การประมาณการที่ไม่สอดคล้องกับความเป็นจริง ( unrealistic estimations )

55. Pricing out a Project แสดงถึงการกำหนดงานที่ต้องทำอย่างครบถ้วน พัฒนา / สร้าง Logic Network Diagram. สร้าง WBS และประมาณการดำเนินการต่างในในแง่ time/cost ทบทวน time/cost ข้างต้นกับ functional manager ที่เกี่ยวข้อง ตัดสินใจเกี่ยวกับ course of action . จัดให้มี acceptable costs ของแต่ละ WBS-activity. ทวนสอบ base costs กับ sponsor ของท่าน สร้าง pricing cost report. จัดทำให้เป็นเอกสารและเก็บไว้ใน project file.

56. Pricing Method งานคือราคาที่ได้มาจากแผนกหนึ่ง ๆ โดยเฉลี่ย และงานทั้งหมดที่ทำไปแล้วจะคิดเงิน ( charge ) จากโครงการโดยใช้เงินเดือนเฉลี่ยจากแผนกนั้น ๆ โดยไม่ต้องสนใจว่า ใครเป็นผู้ทำงานจนแล้วเสร็จ ดังนั้น งานคือราคาเฉลี่ยจากแผนกหนึ่ง ๆ แต่งานทุก ๆ งานที่ทำไปแล้วจะเรียกเก็บเงินจากโครงการตามเงินเดือนจริงของพนักงานที่ทำงานนั้น ๆ นั่นหมายความว่า งานคือราคาที่เทียบเท่ากับเงินเดือนของพนักงานที่จะทำงานนั้น ๆ และถือเป็นค่าใช้จ่ายที่ต้องเรียกเก็บในทำนองเดียวกัน

57. จบหัวข้อ 6 คำถาม ……… ..