Transcript CPSC 333 Lecture 1

310414
Software Engineering
Cost Estimation
310414 - Lecture
1
Cost Estimation
การวิเคราะห์ตน้ ทุน
วิเคราะห์ก่อนโครงงานจะเริ่ มต้น
310414 - Lecture
2
[Jalote1991]
Why do we estimate?
เพื่อเอื้อโอกาสให้ทีมพัฒนาและลูกค้าได้มีโอกาสวิเคราะห์กาไรต้นทุน
310414 - Lecture
3
[Jalote1991]
Cost Estimation for Developers
เป็ นสิ่ งสาคัญมากในการควบคุมการดาเนิ นโครงงาน
ความคลาดเคลื่อนจากการประมาณสามารถใช้เป็ นเกณฑ์ในการ


วัดสถานะของโครงงาน
วัดคุณภาพในการจัดการบุคคลากร
การประมาณต้นทุน จัดเป็ นขั้นตอนหลักของการวางแผน
310414 - Lecture
4
[Jalote1991]
Uncertainties in Cost
Estimation
ความไม่แน่นอนในการประมาณต้นทุน
ความคลาดเคลื่อนในการประมาณ
310414 - Lecture
5
[Jalote1991]
เทคนิคในการประเมินราคาซอฟต์ แวร์
ความแม่นยาในการประเมินราคามีความสาคัญดังนี้คือ



สามารถคิดกาไรที่ได้มาและระบบการเงินในบริ ษทั
สามารถคานวณการใช้ทรัพยากร HW/SW ได้อย่าง
ถูกต้อง
สามารถคานวณราคาตอโปรเจ็
คยอย
ๆ ได้
่
่
ในการประเมินราคาเราควรที่จะบวกค่าความเที่ยงตรงไว้ + 20%
310414 - Lecture
6
Estimation Basics
Models
Metrics
Historical Data
310414 - Lecture
7
Estimation Accuracy
แม่นยาในการประมาณขนาด
แม่นยาในการประมาณกาลังบุคลากรและเวลาที่ใช้จากขนาด
แม่นยาในการวางแผนที่แสดงถึงความสามารถที่แท้จริ งของทีมงาน
ความคงที่ของความต้องการของผลิตภัณฑ์ และสภาพแวดล้อมต่างๆ
310414 - Lecture
8
HOW NOT TO ESTIMATE COST
มีองค์ประกอบภายนอกที่ทาให้การประมาณค่าไม่อาจทาได้หรื อไม่ตอ้ งทา เช่น
โครงการซอฟต์แวร์ผบู้ ริ หารกาหนดให้ทาเสร็ จภายใน 12 เดือน ดังนั้นผูพ้ ฒั นา
ระบบซอฟต์แวร์จะมีเวลาไม่เกินนี้จะต้องทาให้เสร็ จ
โครงการซอฟต์แวร์ที่ตอ้ งมีการประกวดราคาซึ่งเราทราบว่าคู่แข่งเสนอราคา 1
ล้านบาท เมื่อเป็ นเช่นนี้เราต้องชนะการประกวดจึงเสนอราคาไป 9 แสนบาท
จริ งๆแล้วโครงการใช้เวลา 1 ปี แต่ไม่สามารถบอกหัวหน้าได้หรื อบอกเขาก็ไม่
เชื่อจึงต้องกาหนดเวลาพัฒนาไว้ 10 เดือน
310414 - Lecture
9
DELPHI METHOD
ผูบ้ ริ หารหรื อผูม้ ีอานาจในองค์กรมีอิทธิ พลต่อการประมาณราคาและเวลาใน
การพัฒนา
Delphi Method คือวิธีที่ผเู ้ ชี่ยวชาญแต่ละคนเขียนรายละเอียดการ
ประมาณการลงบนกระดาษแล้วผูป้ ระสานงานจะเก็บผลการประมาณการมา
รวมกัน แล้วแจกจ่ายให้แต่ละผูเ้ ชี่ยวชาญพิจารณาของกันและกัน ทาวนเวียน
เช่นนี้จนกระทัง่ ผลลัพธ์ที่ได้เห็นพ้องกันระหว่างผูเ้ ชี่ยวชาญในกลุ่ม
310414 - Lecture
10
An Expected Value
ให้ผเู ้ ชี่ยวชาญประมาณการค่าใช้จ่าย 3 ค่า คือ



ค่าแรกเป็ นค่าดีที่สุดเช่นกรณี ที่เสร็จก่อนเวลาเรี ยกว่า Optimistic
Estimate แทนด้วย Q
ค่าที่สองเป็ นค่าที่คิดว่าตรงความเป็ นจริ งหรื อเป็ นไปได้มากที่สุดเรี ยก Realistic
Estimate แทนด้วย R
คาที
่ าม เป็ นคาที
่ ด
ิ วาเลวร
ายที
ส
่ ุดหรือแยที
่ ุดเทาที
่ ส
่ ค
่
้
่ ส
่ ่
เป็ นไปได้ เรี ยกว่า Pessimistic Estimate แทนด้วย S
แล้วใช้ความรู ้เกี่ยวกับ beta distribution หาความสัมพันธ์
310414 - Lecture
11
An Expected Value
EV = (Q + 2R + P) / 4
EV = (Q + 4R + P) / 6



หรือ
[Conger1994]
[Pressman1997]
Q = optimistic estimation
R = realistic estimation
P = prestimistic estimation
aka a 3-point estimated value
310414 - Lecture
12
Estimation Techniques (1)
Decomposition Techniques :

กระจายงานออกเป็ นงานย่ อยๆ เพือ่ ทีจ่ ะประมาณได้ โดยในงานย่ อยนั้นอาจจะนา
วิธีการคานวณทางคณิตศาสตร์ มาใช้ กไ็ ด้
Empirical models (Algorithmic Cost Modeling)
:

ใช้ การคานวณทางคณิตศาสตร์ หาความสั มพันธ์ ระหว่ างสิ่ งทีป่ ระมาณได้ กับอีกสิ่ ง
หนึ่ง
Based on last projects (Estimation by
analogy)
([Boehm1981]
310414
- Lecture in [Sommerville1996]) and ([Pressman1997])
13
Estimation Techniques (2)
Expert judgement
Parkinson’s Law :

ต้ นทุนขึน้ กับทรัพยากรทีม่ ใี ห้
Pricing to win

ต้ นทุนทีใ่ ช้ กต็ ้ นทุนทีม่ ใี ห้
310414 - Lecture
([Pressman1997])
14
Decomposition Techniques
Problem-Based Estimation
Process-Based Estimation
310414 - Lecture
15
Problem-Based Decomposition
แบ่งงานเป็ นงานย่อยๆ โดยใช้ข้ นั ตอนตามปั ญหา
ใช้ LOC และ FP
310414 - Lecture
16
An Example of LOC Estm.
Function
Estm. LOC
user interface and control facilities
two-dimensional geometric analysis
three-dimensional geometric analysis
…
estimated line of code
2300
5300
6800
…
33200
Using 3-point estimated values
310414 - Lecture
17
An Example of FP Estm
info domain value
opt.
likely
pess.
ets.
w
FP
number of inputs
number of outputs
…
20
12
…
24
15
…
30
22
…
24
16
…
4
5
…
96
80
…
count-total
31
8
FP estm = count-total * factor
FP estm = 372
310414 - Lecture
18
Process-Based Decomposition
แบ่งการประมาณเป็ นงานย่อย ตามกระบวนการขั้นตอนพัฒนา
 Planning
 Analysis
 Design
 Code
 Test
310414 - Lecture
19
Empirical Models
เป็ นการประมาณกาลังบุคลากรจากขนาดของงานที่อาจจะประมาณโดยใช้วธิ ี
ต่างๆ โดยการกระจายงาน
Models :


Single-Variable Models
COCOMO Model
310414 - Lecture
20
Single-Variable Model
b
EFFORT = a * SIZE
EFFORT = a * SIZE + b
ฯลฯ
• ค่ าคงที่
a
และ
b
คานวณจากข้ อมูลในอดีต
310414 - Lecture
21
COCOMO Model


b
E = a (KLOC) x EAF
D = cE d
effort (person-month)
duration (month)
• a b c และ d : constant ที่ข้ ึนกับประเภทของ software
• EAF : Effort Adjustment Factor
[Boehm1981,1984]
from [Jalote1991] and [Pressman1997]
310414
- Lecture
22
COCOMO project types
Organic

a simple small application developed by a small
team with good application experience.
Semidetached

โครงการที่มีขนาดหรื อความซับซ้อนปลานกลาง
Embedded

โครงการพัฒนาซอฟต์แวร์ทีมีขอ้ จากัดสู ง.
310414 - Lecture
23
Organic
ใช้ทีมขนาดเล็ก(1-3คน) ภายใต้ HW, SW และการประยุกต์ที่คุน้ เคย
บุคลากรที่เกี่ยวข้องกับการพัฒนามีประสบการณ์เป็ นอย่างดีเกี่ยวกับ
ซอฟต์แวร์ ที่มีลกั ษณะคล้ายๆกันมาก่อน
กิจกรรมต่างๆเริ่ มต้นได้อย่างรวดเร็ ว
มีขนาดเล็ก
310414 - Lecture
24
Embedded
เป็ นซอฟต์แวร์ ที่พฒั นาภายใต้สิ่งแวดล้อมที่มีความซับซ้อน มีความเสี่ ยงสูง
และมีเงื่อนไขที่ยงุ่ ยาก
ซอฟต์แวร์ ที่พฒั นาแล้วจะถูกนาไปใช้ภายใต้สิ่งแวดล้อมที่ไม่มีความยืดหยุน่
เช่นซอฟต์แวร์ ที่ใช้ควบคุมการขึ้นลงของเครื่ องบิน ซอฟต์แวร์ ควบคุมการยิง
ขีปนาวุธ
310414 - Lecture
25
Semi-detached
เป็ นซอฟแวร์ที่มีขนาดและความยากปานกลาง
ทีมงานประกอบด้วยกลุ่มบุคคลที่มีท้ งั ประสบการณ์และไม่มีประสบการณ์
อยูร่ ะหว่างประเภท Organic และ Embeded
310414 - Lecture
26
Constants for
different project types
System
organic
semidetached
embedded
a
b
c
d
3.2
3.0
2.8
1.05
1.12
1.20
2.5
2.5
2.5
0.38
0.35
0.32
310414 - Lecture
27
Effective Adjustment Factor
Factor ที่คิดจากความต้องการในคุณสมบัติต่างๆ ของ software นั้น
(cost driver attributes)




product attribute
computer attribute
personal attribute
project attribute
โดย Factor นี้จะมีค่ามากหรื อน้อยขึ้นกับระดับของคุณลักษณะต่างๆ
310414 - Lecture
28
Product Attributes
Reliability requirement
Database size
Product complexity
310414 - Lecture
29
Computer attributes
Execution time constraints
Storage constaints
Virtual machine volatility
Computer turnround time
310414 - Lecture
30
Personnel attributes
Analyst capability
Virtual machine experience
Programmer capability
Programming language experience
Application experience
310414 - Lecture
31
Project attributes
Modern programming practices
Software tools
Required development schedule
310414 - Lecture
32
Example
จากการประมาณขนาดโดยใช้ problem-based decomp. ได้วา่





data entry
data update
query
report gen.
TOTAL
cost driver attribute




0.6 KLOC
0.6 KLOC
0.8 KLOC
1.0 KLOC
3.0 KLOC
Complexity
Storage
Experience
Programmer capability
310414 - Lecture
high
high
low
low
1.15
1.06
1.13
1.17
33
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
34
การใช้ Function Point
วัดขนาดและความซับซ้อนโดยใช้เป็ น Function ที่ตอ้ งพัฒนา
ไม่ข้ ึนอยูก่ บั ภาษา เครื่ องมือหรื อ กรรมวิธี
สามารถประเมินใหม่ได้เนื่องจาก Function สามารถเปลี่ยนแปลงได้ง่าย
ไม่ค่อยเหมาะกับโปรแกรมทางด้านเทคนิคเท่าไหร่
310414 - Lecture
35
การคิดค่า FP สามารถหาได้จากสมการดังนี้
FP = Total weighted count * (0.65 +
(0.1* SUM(complexity adjustments)))


Total weighted count - ได้จากตารางที่กาหนดให้
complexity adjustments - ได้จากการตอบคาถาม 14
คาถาม
310414 - Lecture
36
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
37
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
38
Function Point Weight
Simple = 22
Average = 30
Complex = 44
FP = 22 * ( 0.65 + ( 0.1 * 36)) = 93.5
310414 - Lecture
39
Line of Code/FP
25
25
100
Language
4GL
SQL
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
40
นาไปคิดกับ 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
41
ปัจจัยอืน่ ที่มผี ลต่ อราคา
ขนาดฐานข้อมูล
ความซับซ้อน
ขอจ
ดแวร
้ ากัดดานฮาร
้
์
์
ความสามารถประสบการณของโปรแกรมเมอร
์
์
การใช้ Tool ในการพัฒนา
กาหนดการส่งงาน
ประสบการณด้์ านการพัฒนา
310414 - Lecture
42
ปัจจัยความต้องการ
- ความต้องการ
- ราคาของ
ปัจจัยข้อจากัด
- การเงิน
- ทรัพยากร
กระบวนการประเมิน
ราคาซอฟต์แวร์
Effort
ปัจจัยอื่น ๆ
- ความเสี่ ยง
- ฯลฯ
310414 - Lecture
43
ควรใช้ โมเดลในการประเมินราคาหรือไม่ ?
ความไมน
่ ถือของโมเดล
่ ่ าเชือ
ความตางกั
นของการใช้คาคงที
่
่
่
ดังนั้น


อาศัยการเปรี ยบเทียบจากโครงการเก่า ๆ ที่เคยทา
ประสบการณของผู
้ประเมิน
์
310414 - Lecture
44
การประเมินราคา
การประเมินราคาไม่ได้ทาเพียงครั้งเดียวจบ



ระยะแรกก่อนการประมูล
ระยะสองทาหลังการประมูล
หัวหน้าทีมตองพยายามประเมิ
นราคาบอย
ๆ
้
่
เพื่อให้เหมาะสมกับราคาปั จจุบนั
310414 - Lecture
45
การประเมินราคาในทางปฏิบัติ
ดูความต้องการหลัก แล้วแบ่งให้เป็ นความต้องการย่อย
งานที่ตอ้ งทา & ผลลัพธ์ที่ตอ้ งได้
แปลงเป็ นหน้าจอที่ตอ้ งสร้าง




หน้าจอกรอกขอมู
้ ล
หน้าจอสอบถามขอมู
้ ล
หน้าจอรายงาน
หน้าจอบริหารระบบ
310414 - Lecture
46
การประเมินราคาในทางปฏิบัติ
คานวณหน้าจอที่ตอ้ งสร้างเป็ น N หน้าจอ แล้วให้ B เป็ นราคาต่อ
หน้าจอ
B?

ค่าของ B อยูใ่ นช่วง 3,000-20,000
~
5,000-13,000
310414 - Lecture
47
ตัวอย่าง
สมมุติประเมินว่าระบบต้องมีหน้าจอ 65 หน้าจอ รายงานที่ตอ้ งทา 15
รายงาน รวมเป็ น 65 ชิ้นงาน
ใช้ราคากลางที่ 9,000 บาทต่อชิ้น ราคาเบื้องต้นน่าจะเป็ น 585,000
บาท
โปรแกรมเมอร์หนึ่งคนเฉลี่ยทาได้ 6 หน้าจอต่อเดือน งานชิ้นนี้น่าจะใช้
10 คน-เดือน
ระยะเวลางาน 5 เดือนเพราะฉะนั้นใช้โปรแกรมเมอร์ 10/5=2 คน
ช่วยกันทางาน
310414 - Lecture
48
ทีมงานประกอบด้วย




หัวหน้าโครงการ 1 คน ตลอดโครงการ (นั้นคือ 0.2 คนต่อเดือน = อาทิตย์ละ
ครั้ง)
เลขานุ การพิมพเอกสาร
2 คน (ใช้สองเดือนหลัง)
์
โปรแกรมเมอร์ 2 คน
หัวหน้าโครงการ 80,000 x 1
= 80,000
เลขานุ การ
= 40,000
โปรแกรมเมอร์ 60,000 x 5 x 2
20,000 x 2
= 600,000
720,000
310414 - Lecture
49
ตัวประกอบทีม่ ีผลต่ อโครงการ
ระดับโครงการ
• เงินเดือนของโปรแกรมเมอร ์
• ระยะเวลาการพัฒนา
• กรรมวิธก
ี ารพัฒนา
Individual-Simple Program
จานวนบรรทัดต่อปี ต่อคน
5
Team- Large Complexity
Team-Medium-Complexity
1000
ขนาดของโปรแกรม x 1000 บรรทัด
310414 - Lecture
50
• ความเข้าใจกับลูกค้า
ระดับองค์ กร
• คุณภาพของผู้บริหาร
• โปรแกรมเมอร ์
ระดับชิ้นงาน
• เอกสาร
• ภาษาโปรแกรมทีใ่ ช้
• ความซับซ้อนของงาน
310414 - Lecture
51