Transcript Project Estimation Paul Sorenson Department of Computing Science University of Alberta

Project Estimation
Paul Sorenson
Department of Computing Science
University of Alberta
CMPUT 402
Software Engineering
5/25/2016
CMPUT 402 - Project Estimation
1
Topic Overview
• The “Bad News”
• Why is project estimation difficult?
• What can be done about? Some approaches.
• Practical estimation
• COCOMO Model
5/25/2016
CMPUT 402 - Project Estimation
2
How many LOC?
// Initialize the OLE libraries
hRslt = CoInitializeEx(NULL, COINIT_MULTITHREADED);
if (SUCCEEDED(hRslt)) {
hRslt = CreateFileMoniker(wcsPath, &pmk);
if (SUCCEEDED(hRslt))
hRslt = BindMoniker(pmk, 0, IID_IHello, (void **)&pHello);
if (SUCCEEDED(hRslt)) {
// print a string out
pHello->PrintSz(wcsT);
Sleep(2000);
ulCnt = pHello->Release();
}
else
printf("Failure to connect, status: %lx", hRslt);
// Tell OLE we are going away.
CoUninitialize();
}
return(0);
5/25/2016
CMPUT 402 - Project Estimation
3
How good/bad are we?
US DOD Sustaining Base Information Services
(SBIS) Program Example (source Scientific Am. Apr’96)
• 10 year project to replace 3,700 automated applications
with 1,500 new applications by the year 2002.
• Decided to split it into phases - 1st phase was common
infrastructure plus 89 applications
• IBM won contract with bid of $474M but were soon
dropped for non-delivery
• After investing $158M in first three years not on single
replacement system was delivered.
• Latest estimate for a reduced 1st phase is $1.4B with
only 19 of 89 systems - uncertain if 2002 date can be met.
5/25/2016
CMPUT 402 - Project Estimation
4
More Bad News
A Standish Group survey of 8,000 software projects in
the mid-’90s found that the average project exceeded
its planned budget by 90 percent and its schedule by
120 percent. Several industry studies have reported that
fewer than half of software projects finish within their
allotted schedules and budgets.
5/25/2016
CMPUT 402 - Project Estimation
5
Reasons for Runaway Projects
A study conducted by KPMG Pete Marwick found these
causes of software runaways:
•
•
•
•
•
•
Project Objectives Not Fully Specified (51%)
Bad Planning and Estimating (48%)
Technology New to the Organization (45%)
Inadequate/No Project Management Methodology (42%)
Insufficient Senior Staff on the Team (42%)
Poor Performance by Suppliers of Hardware/Software (42%)
5/25/2016
CMPUT 402 - Project Estimation
6
Why is it so difficult?
5/25/2016
CMPUT 402 - Project Estimation
7
It’s difficult because . . .
• We often begin with a fuzzy picture
 poor set of requirements?
• Software development is then a gradual process
of refinements of requirements.
 an estimate can come into focus only
along with the software itself
• Yet, in the face of existing evidence, some
companies want cost estimates to within  10%.
5/25/2016
CMPUT 402 - Project Estimation
8
Examples of uncertainty
at each phase and elsewhere . . .
• Requirements?
Fuzziness
• Design?
Arch. knowledge/preferences
• Implementation? Language and develop. envir.
• Testing?
Extensiveness
• Deployment?
User acceptance
• Personnel?
Experience & expertise
• Technology?
Multi-platform or not
• Others?
5/25/2016
CMPUT 402 - Project Estimation
(was quality built in?)
(10:1 factor)
9
V - Model
for System Development
Req.
Defn
Accept.
Testing
Arch.
Design
Detailed
Design
Integration
Testing
Unit
Testing
Implementation
5/25/2016
CMPUT 402 - Project Estimation
10
Common Estimation Methods
• Decomposition techniques - project is decomposed into
tasks until an estimate for each task can be made.
• Empirical models for the estimation using past experience
to predict cost and effort.
• Automated estimation tools that use a combination of
decomposition and empirical models, but develop the
estimates automatically from project information.
5/25/2016
CMPUT 402 - Project Estimation
11
Estimation through Refinement
Project Cost
Project Schedule
(effort and size)
4x
1.6x
Estimate-convergence
graph
2x
1.25x
1.5x
1.25x
1.0x
0.8x
0.67x
1.15x
1.10x
1.0x
0.9x
0.85x
0.5x
0.8x
0.25x
0.6x
Initial
Approved Req.
Prod Defn Prod Defn Specs
5/25/2016
Product
D. Specs
CMPUT 402 - Project Estimation
Detailed
D. Specs
Product
Complete
12
Estimation vs Control
Product
Size
Product
Size
Initial desired
feature set
Initial desired
feature set
Features
Resources
Features
Resources
Initial available
resources
Evolution of Product
5/25/2016
Initial available
resources
Evolution of Product
CMPUT 402 - Project Estimation
13
Cooperation & Covergence
• Help customers by telling
the parts you are able to
estimate accurately
• Tell customers you will
refine estimates at the end
of various phases.
• Estimates too low 
planning inefficiencies
which drive costs up
• Estimates too high 
Parkinson’s law drives
up actual costs.
5/25/2016
Actual
Schedule
Estimate
too high
minimum
actual
schedule
actual
schedule =
estimated
schedule
Estimate
too low
Estimated
Schedule
CMPUT 402 - Project Estimation
14
Estimation Process Overview
Three Steps:
• Estimate size of the product (LOC, function
points and/or history of similar projects)
• Estimate the effort (person months)
• Estimate the schedule (calendar months).
5/25/2016
CMPUT 402 - Project Estimation
15
Function Point Size Estimation
• championed by Caper Jones
Program
Characteristic
Number of inputs
Number of outputs
Number of inquiries
Logical internal files
External interface files
Low
Medium
Complexity Complex
6 *3
7 *4
0 *3
5 *7
9 *5
=18
=28
=0
=35
=45
2 *4 =8
7 *5 =35
2 *4 =8
2 *10 =20
0 *7 =0
Unadjusted function-point total
Influence multiplier
Adjusted function-point total
5/25/2016
CMPUT 402 - Project Estimation
High
Complex Total
3 *6 =18
0 *7 =0
4 *6 =24
3 *15=45
2 *10=20
44
53
32
100
65
304
1.15
350
16
Good Estimation Practices
•
•
•
•
•
•
•
•
•
•
•
Avoid off-the-cuff estimates - pressure from management
Allow time for estimating and plan for it.
Use historical data. (Whose data?)
Use developer-based estimates.
Estimate by walk-through
Estimate by category
Estimate at a low level of detail
Include common tasks -e.g. cut-over, client demos
Use estimation tools (if their good)
Use several techniques - LOC, function-points, 1st order
Change estimation practice as project proceeds
- bounded historical at project defn,
- COCOMO at requirements defn
- module level estimates at architectural design
5/25/2016
CMPUT 402 - Project Estimation
17
Presenting Estimates
E.g., Risk-Quantification Estimates
Estimate: 8 months, +3 months, -2 months
+1 month for late
-1 month for less delay in
delivery of database system
hiring
+1 month for new CASE
tools not working as planned
-1 month for new CASE
tools working better
than planned
+0.5 months for staff unexpected
staff leaves and sicknesses
+0.5 months for underestimating
size
5/25/2016
CMPUT 402 - Project Estimation
18
Case-Based Estimate
Confidence
Factor
Case
Estimate
Best case
December 10
20%
Current case
January 15
75%
Worst case
February 22
95%
5/25/2016
CMPUT 402 - Project Estimation
19
Effort Estimation
• Caper Jone’s 1st order estimation practices
• Boehm’s empirical validation tables for shortest
possible schedules
System Products Business Products Shrink-Wrap Product
System Size Sched. Effort
Sched. Effort
Sched. Effort
10,000
30,000
100,000
250,000
500,000
6
9
15
22
30
25
110
540
1650
3900
3.5
5.5
9
13
17
5
22
110
330
780
4.2
7
11
15
20
8
37
190
580
1400
• COCOMO
5/25/2016
CMPUT 402 - Project Estimation
20
COCOMO -
COnstructive COst MOdel
• Screen-oriented, interactive software
package and model (COCOMO II) that assists in
budgetary planning and schedule estimation of a
software development project.
(Model base on his book Software Engineering Economics)
• The model is based on two general set of cost drivers:
- Early Design
- Post Architecture
5/25/2016
CMPUT 402 - Project Estimation
21
COCOMO -
COnstructive COst MOdel
Early Design Cost Drivers (7)
•
•
•
•
•
•
•
5/25/2016
Personnel Capability (PERS)
Product Reliability and Complexity (RCPX)
Required Reuse (RUSE)
Platform Difficulty (PDIF)
Personnel Experience (PREX)
Facilities (FCIL)
Schedule (SCED)
CMPUT 402 - Project Estimation
22
COCOMO -
COnstructive COst MOdel
Post-Architecture
• Personnel Factors (6)
• Product Factors (5)
- Required Software Reliability
(RELY)
- Data Base Size (DATA)
- Product Complexity (CPLX)
- Required Reusability (RUSE)
- Documentation match to
life-cycle needs (DOCU)
• Platform Factors (3)
- Execution Time Constraint (TIME)
- Main Storage Constraint (STOR)
- Platform Volatility (PVOL)
5/25/2016
-
Analyst Capability (ACAP)
Programmer Capability (PCAP)
Applications Experience (AEXP)
Platform Experience (PEXP)
Language and Tool Experience
(LTEX)
- Personnel Continuity (PCON)
• Project Factors (3)
- Use of Software Tools (TOOL)
- Multisite Development (SITE)
- Required Development
Schedule (SCED)
CMPUT 402 - Project Estimation
23