Chapter 6

 The Work Breakdown Structure

and Project Estimation
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.
Project Time Management as defined
in PMBOK

 Project Time Management ประกอบด้วย

 การกำาหนดการดำาเนินงาน (Activity definition)
 การจัดอนุกรมของการดำาเนินงาน (Activity
sequencing)
 การประมาณช่วงเวลาในการดำาเนินงาน (Activity
duration estimation)
 การสร้างตารางเวลา (Schedule development)
 การควบคุมให้เป็นไปตามตารางเวลา (Schedule
control)
 ในบทนี้จะมุ่งไปที่ Activity Definition และ Activity
The Work Breakdown Structure
(WBS)

 WBS แสดงถึงการแยกย่อยงานที่ตอ ้ งกระทำาอย่างเป็น

ตรรกะ และ มุ่งเน้นว่า ผลผลิต การให้บริการ หรือ
ผลลัพธ์ที่ได้ จากการจัดแบ่งข้างต้นเป็นอย่างไร ดังนั้น
WBS จึงเป็นโครงร่างที่แสดงให้เห็นว่างานอะไรบ้างที่
ต้องทำา
 Gregory T. Haugan (2002)

 A work breakdown structure (WBS) คือ กลุ่มของ

งาน(ในเชิง deliverable)ที่ตอ
้ งทำาในโครงการหนึ่ง ๆ
ตามที่กำาหนดไว้ในขอบเขตของโครงการทั้งหมด
Work Package

 การแตกงานออกมา (WBS decompose) หรือแบ่งงาน

(subdivide) ของโครงการหนึ่ง ๆ ออกเป็นองค์
ประกอบเล็ก ๆ (small component) เพื่อให้เป็นหน่วย
งานที่บริหารจัดการได้ง่าย เรียกว่า Work package จึง
ถือว่าเป็นเอกสารพื้นฐานในการบริหารโครงการ เพราะ
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
Developing the WBS

 Develop work packages for each of the phases

and deliverables defined in the Deliverable
Structure Chart (DSC)
 Approaches to Developing WBSs

 การใช้แนวทาง: บางองค์กร เช่น DoD ได้ให้แนวทาง

(guideline) ในการเตรียม WBS เอาไวดังนี้
 Analogy approach: ทบทวน WBS จากโครงการต่าง ๆที่
คล้ายกัน แล้วทำาการปรับแต่งโครงการของท่าให้เหมาะ
สม
 Top-down approach: เริ่มด้วย largest items ของ
โครงการแล้วแตกแยกย่อยออกมาเรื่อย ๆ
 Bottom-up approach: เริ่มด้วย detailed tasks แล้วจึง
รวมเข้าหากัน
 Mind-mapping approach: เขียนงานต่าง ๆ ในเชิง non-
Project Life Cycle ประกอบไปด้วย 5
เฟส

SDLC
3

2 4
1 5
 Systems Development Life Cycle
(SDLC)

พัฒนาระบบ (โปรแกรม) อะไรสักอย่างหนึ่ง จะประกอบไปด้วย 5 เ

The Relationship Between the PLC &
SDLC
An IT Project Methodology
ดูให้เข้าใจส่วนใดคือ PLC ส่วนใดคือ
SDLC

ในบล็อกนี้คือSDLC

และมันก็คอ
ื Execute
And Control ของ PL
Work Breakdown Structure
Phase

Deliverable

Activities/Tasks

Deliverable Completion

Phase completion
The WBS Should Follow the Work
Package Concept
Developing the WBS

 WBS ควรอยู่ในรูปของ Deliverable-Oriented

(Project ต้องสร้างบางสิ่งบางอย่างออกมาเสมอ ไม่งั้น
ก็ไม่รู้ว่าจะทำาไปทำาไม)
 WBS ต้องสนับสนุน Project's MOV
 ต้องมั่นใจว่า WBS สอดรับกับการส่งมอบ project’s
deliverable ทุก ๆ เรื่องที่ได้กำาหนดไว้ใน project
scope
 ต้องครบถ้วน 100% (100 percent rule)
 ระดับของรายละเอียดต้องสนับสนุนการวางแผนและ
การควบคุมโครงการ
Basic Principles for Creating WBSs
 1. หน่วยงานหนึ่ง ๆ จะต้องปรากฏอยูท ่ ี่เดียวใน WBS.
 2. งานภายใต้ WBS item หนึ่ง ๆ คือ ผลรวมของรายการ
ทั้งหลายของ WBS ที่อยู่ตำ่าลงไป
 3. แต่ละ WBS item คือ การสนองตอบ (หรือทำางาน)ใน
แต่ละเรื่อง ไม่ว่าจะใช้คนทำาเรื่องนั้น ๆ กี่คนก็ตาม
 4. WBS จะต้องใช้แนวทางเช่นเดียวกันเสมอในการที่จะ
ทำางานหนึ่ง ๆ และมันจะต้องสนับสนุน project team
ก่อน ส่วนเรือ
่ งอืน่ ค่อยทำาถ้าเป็นไปได้
 5. Project team members จะต้องมีส่วนร่วมในการ
พัฒนา WBS เพือ ่ มั่นใจได้ว่าจะมีความต่อเนื่องและเข้าใจ
 6. แต่ละรายการของ WBS จะต้องจัดทำาเป็นเอกสาร
เพื่อมั่นใจได้ว่ามีความเข้าใจชัดเจนถึงขอบเขตของ
งาน (อะไรที่รวมอยู่และต้องทำา อะไรที่บันทึกไว้แต่ไม่
ต้องทำา)
 7. WBS ต้องเป็นเครื่องมือที่มีความยืดหยุ่นเพีอ
่ รองรับ
การเปลี่ยนแปลงใด ๆ ที่อาจเกิดขึ้นได้ แต่ในขณะ
เดียวกัน จะต้องรักษาการควบคุมการทำางานใน
โครงการให้เป็นไปตาม scope statement.
Project Estimation
 เมล็ดพันธุ์แห่งความหายนะหลัก ๆ ของซอฟท์แวร์มักจะ
ถูกหว่านลงไปไปในช่วงสามเดือนแรกของการเริ่มต้น
โครงการทางด้านซอฟต์แวร์ ตารางเวลาที่เร่งรีบ คำา
สัญญาที่ไร้เหตุผล เทคนิคการประมาณการไม่เป็นแบบ
มืออาชีพ และ ปราศจากการใส่ใจของฟังก์ชน ั เกี่ยวกับ
การบริหารโครงการ สิ่งเหล่านี้คอ ื แฟกเตอร์ทั้งหลายที่
ก่อให้เกิดปัญหาต่าง ๆ ขึน้ มา เมื่อโครงการเดินหน้าไป
อย่างไร้ทิศทางไปสู่วน
ั ส่งมอบที่เป็นไปได้ยาก หายนะ
ในส่วนที่เหลือย่อมเกิดขึน
้ อย่างยากที่จะหลบเลี่ยง

 T. Capers Jones
Pricing and Estimating

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

 Order of magnitude estimates

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

 Definitive (or detailed) estimates

 - จัดเตรียมจากข้อมูลเชิงวิศวกรรมหรือผูแ
้ ทน
จำาหน่ายที่ถกู กำาหนดเอาไว้ อย่างดีแล้ว
 - ใช้ใบเสนอราคา หน่วยราคา ฯลฯ ความถูก
ต้อง +- 5%
 Estimating manual
 - ถูกพัฒนาขึ้นมาจากช่วงเวลาที่ผ่านมา
 - ใช้ราคาตามสิ่งที่ได้มา (จากการสืบค้น) ความ
ถูกต้อง +-10%
Additional Estimating Methods (1)
 Direct Estimate
 - ทำาการประมาณโดยใช้ผม ู้ ีประสบการณ์
 - ต้องการการตัดสินใจขั้นสุดท้าย
 Estimate by analogy
 - ทำาการเปรียบเทียบโดยใช้การดำาเนินการที่คล้าย
กัน
 - ต้องการการตัดสินใจขั้นสุดท้าย
 Factored method
 - อาศัยข้อมูลในอดีต
 - ต้องใช้ equipment lists, sizes
 - เริ่มด้วยการเสนอราคาของเครื่องมือ
Additional Estimating Methods (2)
 Gross proration method
 - อาศัยข้อมูลในอดีต
 - ทำาการคัดลอกข้อมูลที่ใกล้เคียงกัน
 การประมาณลงไปในรายละเอียด (Detailed
estimate)
 - ใช้หลักการของการแตกงาน (WBS)
 - ทำาการแตกงานย่อยเป็นหลายระดับ
 วิธีการเสนอราคา (Quotation method)
 - เปรียบเทียบใบเสนราคาจากสามแหล่ง (three
quotations)
Additional Estimating Methods (3)

 อาศัยคูม
่ ือต่าง ๆ (Handbook manuals)
 อาศัยกราฟการเรียนรู้ (Learning curves)
Estimation Techniques
- The Project Management Approach

 Guesstimating
 Delphi Technique
 Time Boxing
 Top-Down
 Bottom Up
 Analogous Estimates (Past experiences)
 Parametric Modeling (Statistical)
 Project Estimation
 อาศัยการคาดเดา (Guesstimating)
 อยู่บนพืน้ ฐานของความรู้สึก ซึง่ ไม่ใช่ความจริง
 ไม่ใช่วิธีการที่ดีแต่มักถูกนำามาใช้โดย inexperienced
project managers
 อาศัย Delphi Technique
 ประกอบด้วยผู้ชำานาญการ(ซึง่ ไม่ทราบชือ ่ )หลายคน
 ให้แต่ละคนทำาการประมาณการ
 ทำาการเปรียบเทียบการประมาณการข้างต้น
 ถ้าใกล้เคียงกันให้นำามาหาค่าเฉลี่ย
 ถ้าต่างกันมากให้ทำาใหม่จนกระทั่งผลที่ได้ใกล้เคียง
 อาศัยเวลา (Time Boxing)
 กำาหนดเวลาของแต่ละการดำาเนินการหรืองานหรือสิ่งที่
ต้องส่งมอบ
 มุ่งเน้นที่ team ได้ถา้ team มีประสิทธิภาพ
 และสามารถทำาให้ team เสื่อมลงได้ถ้าใช้บ่อย หรือ
ใช้กบั team ที่ไม่มีประสิทธิภาพ เพราะการทำาเช่นนี้
เป็นการเพิ่ม stress หรือ pressure ให้กับ project
team เพือ ่ ให้งานเสร็จ
 Project Estimation

 วิธีการประมาณจากบนลงล่าง (Top-Down Estimating)

 Top & middle managers เป็นผูก ้ ำาหนด overall
project schedule และ/หรือ cost
 Lower level managers ถูกคาดหวังว่าจะเป็นผู้
breakdown schedule/budget estimates ลงไปสู่
specific activities (WBS)
 มักจะแสดงในเทอมของต้นทุนอะไรบ้างที่เกิดขึ้นใน
โครงการและจะใช้นานเท่าใดในเชิงเป็นไปตามคำาสั่ง
ของสมาชิกในกลุ่มผูบ ้ ริหารระดับสูงผูค
้ ิดว่า
พารามิเตอร์ตา่ ง ๆ (parameters) ต่าง ๆ เหล่านั้นถูก
ต้องเหมาะสม
 Project Estimation
 การประมาณจากล่างขึ้นบน (Bottom-Up Estimating)
 เป็นรูปแบบที่ใช้ประมาณโครงการเป็นส่วนมาก
 ทำาการแบ่งโครงการออกเป็นโมดูลย่อย ๆ แล้วประมาณ
จากโมดูลเหล่านี้โดยตรง เกี่ยวกับเวลา แรงงาน-ชัว่ โมง
สัปดาห์ หรือเดือนที่ต้องใช้ในแต่ละโมดูล
 การประมาณในรูปแบบที่ใกล้เคียงกัน (Analogous
estimating)
 โดยอาศัยโครงการอื่น ๆ ที่ใกล้เคียงกับโครงการปัจจุบัน
 ประมาณฟังก์ชน ั ของการดำาเนินงานและระยะเวลา
(Parametric Modeling)โดยพิจารณาจาก:
 ความซับซ้อนของโมดูล
 โครงสร้างของโมดูล
Example WBS with Estimated Task
6.2 Test Results Report
Durations
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
Estimating Pitfalls
 การแปลความหมายของ statement of work (SOW)
ผิด
 การกำาหนดขอบเขตไม่ครบถ้วนหรือไม่ถก ู ต้อง
 การกำาหนดตารางเวลาอย่างหยาบ ๆ หรือ ไม่เหมาะสม
(overly optimistic schedule)
 การแตกงานไม่ถก ู ต้องอย่างเพียงพอ
 ใช้ทักษะในระดับที่ไม่เหมาะสมกับงานต่าง ๆ
 บกพร่องในแง่การใส่ใจกับความเสี่ยงต่าง ๆ
 บกพร่องในแง่การทำาความเข้าใจหรือใส่ใจต่อการ
ประมาณต้นทุนหรือเกิดบานปลาย
 บกพร่องในแง่การใช้เทคนิคการประมาณต้นทุนไม่ถกู
Software Engineering Metrics and
Approaches
 Software engineering
 มุ่งเน้นที่กระบวนการ เครื่องมือ และวิธีการในการ
พัฒนาแนวทางที่มีคณ ุ ภาพในการพัฒนาซอฟต์แวร์
 ตัววัด (metric)
 เป็นพื้นฐานสำาหรับ software engineering และ ใช้
อ้างแบบกว้าง ๆ ในการวัดเป้าประสงค์ในการประเมิน
computer software.
 แบ่งได้เป็น 4 แนวทาง
 Lines of Code (LOC)
 Function Points
 COCOMO
Software Engineering Estimation Model
Software Engineering Metrics and
Approaches

 Lines of Code (LOC)

 มักใช้กันทั่ว ๆ ไปเพื่อเป็นตัววัดขนาดของโครงการ
(project sizing)
 ข้อโต้แย้งที่พบเห็นกันส่วนมากได้แก่
 จะนับ comments ด้วยหรือไม่ ?
 จะนับการประกาศตัวแปรด้วยหรือไม่ ?
 Efficient code vs. code bloat
 ความแตกต่างของภาษาที่ใช้เขียน
 ง่ายเมื่อนับภายหลังจากเขียนเมื่อเทียบกับการ
ประมาณล่วงหน้า
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 ที่
The Application Boundary for
Function Point Analysis
4

5
3

(EI
1
F) 2
 สมมติวา่ ทำาการ 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)
 Complexity

Low Average High Total

Internal
Logical Files
_3 x 7 = 21 _2 x 10 = 20 _1 x 15 = 15 56
(ILF)

External
Interface Files
__ x 5 = __ _2 x 7 = 14 __ x 10 = __ 14
(EIF)

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
 ขัน
้ ตอนต่อไปคือการคำานวณหา 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
จะคำานวณหา Total adjusted function p
 3 = average influence
 4 = significant influence
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

 เมื่อได้ 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
 Language Average Source LOC Average Source LOC
per Function Pont 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
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
อาจไม่ง่ายและตรงไปตรงมาแต่มีระดับความเชือ ่
 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 * KDSI1.12
= 3.0 * (10.6) 1.12
= 42.21
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
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
The Mythical Man-Month – Frederick
Brooks
 ประการแรก เทคนิคของเราที่ใช้ประมาณการยังไม่ดีพอ
และไม่สะท้อนให้เห็นถึงสมมติฐานที่ไม่แสดงออกมา ซึง่
จะทำาให้โครงการเดินไปได้ดว้ ยดี
 ประการที่สอง เทคนิคที่ใช้ประมาณการของเราทำาให้
สับสนในเชิงผิดหลักการและเหตุผลทางด้านความคืบ
หน้า และยังแฝงเร้นสมมติฐานว่า จำานวนคนและจำานวน
เดือน(ระยะเวลาที่ทำา) สามารถสลับเปลี่ยนกันได้
 ประการที่สาม เพราะการประมาณเกิดความไม่แน่นอน
ส่วน software managers มักจะดือ ้ รั้นแบบอ้างเหตุผล
ต่าง ๆ นา เช่น กุ๊กทำาอาหารมักจะกล่าวว่า การทำาอาหาร
ที่ดีตอ
้ งใช้เวลา ดังนั้นท่านต้องรอ แล้วเขาจะบริการคุณดี
ขึน
้ เขาจะเออกเอาใจคุณ
The Mythical Man-Month – Frederick
Brooks

 ประการที่หา้ เมือ
่ ตารางเวลาถูกรับรู้ว่าเลื่อนออกไป
การสนองตอบทั่ว ๆ ไปจะเป็นการเพิ่ม manpower ให้
มากขึ้น เหมือนกับทำาการดับไฟด้วยนำ้ามันมีแต่ทำาให้
เลวร้ายลงไป ไฟก็จะลุกมากขึน ้ ก็จะใช้นำ้ามันมากขึ้น
แน่นอนว่ามันคงจบลงด้วยความหายนะอย่างแน่นอน
COCOMO – COnstructive COst MOdel

 COCOMO Model Types

 Basic (ตัวอย่างที่ผา่ นมาใช้โมเดลนี)้
 Intermediate
 Advanced
 COCOMO II
 SLIM vs. COCOMO
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
 Automated Estimating Tools
 COCOMO II
 SLIM
 CHECKPOINT
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
What Is the Best Way to Estimate IT
Projects?

 ใช้มากกว่าหนึ่งเทคนิคในการประมาณต้นทุน
 ถ้าการประมาณได้จากเทคนิคที่แตกต่างกันและใกล้คี
ยงกันให้ใช้คา่ เฉลี่ย
 การปรับค่าประมาณการ จะขึน้ กับประสบการณ์เป็น
หลัก
 การเจรจาตกลงกันอาจนำาไปสู่การประมาณการที่ไม่
สอดคล้องกับความเป็นจริง (unrealistic estimations)
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.
 Pricing Method
 งานคือราคาที่ได้มาจากแผนกหนึ่ง ๆ โดยเฉลี่ย และงาน
ทั้งหมดที่ทำาไปแล้วจะคิดเงิน (charge) จากโครงการโดย
ใช้เงินเดือนเฉลี่ยจากแผนกนั้น ๆ โดยไม่ตอ้ งสนใจว่า ใคร
เป็นผู้ทำางานจนแล้วเสร็จ
 ดังนั้น งานคือราคาเฉลี่ยจากแผนกหนึ่ง ๆ แต่งานทุก ๆ
งานที่ทำาไปแล้วจะเรียกเก็บเงินจากโครงการตามเงินเดือน
จริงของพนักงานที่ทำางานนั้น ๆ
 นั่นหมายความว่า งานคือราคาที่เทียบเท่ากับเงินเดือนของ
พนักงานที่จะทำางานนั้น ๆ และถือเป็นค่าใช้จ่ายที่ตอ
้ งเรียก
เก็บในทำานองเดียวกัน
จบหัวข้อ 6

 คำาถาม ………..