Project%20Estimation

1
Project Estimation



Paul Sorenson Department of Computing
Science University of Alberta
CMPUT 402 Software Engineering
2
Topic Overview

• The Bad News
• Why is project estimation difficult?
• What can be done about? Some approaches.
• Practical estimation
• COCOMO Model

3
How many LOC?
// Initialize the OLE librarieshRslt
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-gtPrintSz(wcsT
) Sleep(2000) ulCnt
pHello-gtRelease() else
printf("Failure to connect, status lx",
hRslt) // Tell OLE we are going away.
CoUninitialize() return(0)
4
How good/bad are we?
US DOD Sustaining Base Information
Services (SBIS) Program Example (source
Scientific Am. Apr96)

• 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
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.
6
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)

7
Why is it so difficult?
8
Its 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.

9
Examples of uncertainty at each phase and
elsewhere . . .
Fuzziness Arch. knowledge/preferences Language
and develop. envir. Extensiveness (was quality
built in?) User acceptance Experience
expertise (101 factor) Multi-platform or not
10
V - Model for System Development
Implementation
11
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.

12
Estimation through Refinement
Project Cost (effort and size)
Project Schedule
4x 2x 1.5x 1.25x 1.0x 0.8x 0.67x 0.5x 0.25x
1.6x 1.25x 1.15x 1.10x 1.0x 0.9x 0.85x 0.8x
0.6x
Estimate-convergence graph
Initial Prod Defn
Approved Prod Defn
Product D. Specs
Detailed D. Specs
Req. Specs
Product Complete
13
Estimation vs Control
Product Size
Product Size
Initial desired feature set
Initial desired feature set
Features Resources
Features Resources
Initial available resources
Initial available resources
Evolution of Product
Evolution of Product
14
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 ? Parkinsons law drives
  up actual costs.

Estimate too high
Estimate too low
15
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).

16
Function Point Size Estimation

• championed by Caper Jones

4 5 4 10 7
6 7 6 15 10
3 4 3 7 5
17
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

18
Presenting Estimates
E.g., Risk-Quantification Estimates
Estimate 8 months, 3 months, -2 months
1 month for late delivery of database
system 1 month for new CASE tools not
working as planned 0.5 months for staff
unexpected staff leaves and sicknesses 0.5
months for underestimating size
-1 month for less delay in hiring -1 month
for new CASE tools working better than
planned
19
Case-Based Estimate
Confidence Factor 20 75 95
Case Best case Current case Worst case
Estimate December 10 January 15 February 22
20
Effort Estimation

• Caper Jones 1st order estimation practices
• Boehms empirical validation tables for
  shortest possible schedules

System Products Business Products Shrink-Wrap
Product
System Size 10,000 30,000 100,000 250,000 500,000

• COCOMO

21
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

22
COCOMO - COnstructive COst MOdel

• Early Design Cost Drivers (7)
• Personnel Capability (PERS)
• Product Reliability and Complexity (RCPX)
• Required Reuse (RUSE)
• Platform Difficulty (PDIF)
• Personnel Experience (PREX)
• Facilities (FCIL)
• Schedule (SCED)

23
COCOMO - COnstructive COst MOdel

• Post-Architecture
• Product Factors (5) - Required Software
  Reliability (RELY)
• - Data Base Size (DATA)
• - Product Complexity (CPLX)
• - Required Reusability (RUSE)
• - Documentation match to life-cycle needs
  (DOCU)

• Personnel Factors (6)
• - 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)

• Platform Factors (3) - Execution Time
  Constraint (TIME)
• - Main Storage Constraint (STOR)
• - Platform Volatility (PVOL)