Chapter 6

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 เฟส SDLC 3 2 4 1 5

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. Phase Deliverable Activities/Tasks Deliverable Completion Phase completion Work Breakdown Structure

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 สามารถช่วยสนับสนุนการสร้าง WBS

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) • - เปรียบเทียบใบเสนราคาจากสามแหล่ง (three 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. 4 5 3 (EIF) 1 2 The Application Boundary for Function Point Analysis

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) _3x 7 = 21 _2x 10 = 20 _1x 15 = 15 56 External Interface Files (EIF) __ x 5 = __ _2 x 7 = 14 __ x 10 = __ 14 External Input (EI) _3x 3 = 9 _5 x 4 = 20 _4x 6 = 24 53 External Output (EO) _4x 4 = 16 _2 x 5 = 10 _1x 7 = 7 33 External Inquiry (EQ) _2 x 3 = 6 _5 x 4 = 20 _3x 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. 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 Source: http://www.theadvisors.com/langcomparison.htm

44. COCOMO – COnstructive COst MOdel • 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-Detachedequation ได้เป็น Person-Months = 3.0 * KDSI1.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 * Effort0.38 • Semi-Detached • Duration = 2.5 * Effort0.35 • Embedded • Duration = 2.5 * Effort0.32

47. COCOMO Duration Example จากตัวอย่างที่แล้ว ต้องการ 42.21 person-months ดังนั้น duration of development จะคำนวณได้จาก Duration = 2.5 * Effort0.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