cocomo
TRANSCRIPT
Work Break Down Structure
Work Breakdown Structure (WBS)
2
A detailed, hierarchical (from general to specific) tree structure of deliverables and tasks that need to be performed to complete a project.
Purpose: to identify actual tasks to be done in a project. Serves as basis for project planning.
An extension to PERT.
Work Breakdown Structure3
Identify the major task categories Identify sub-tasks, and sub-sub-tasks Use verb-noun to imply action to
something
Create WBS4
Decomposition of project deliverables and activities into smaller, more manageable parts
The lowest level in WBS is a Work Package based on Statement Of Work (SOW)
Needs to be S.M.A.R.T (Specific, Measurable, Attainable, Realistic, Timely)
Work Breakdown Structure
System Hardware Replacement
RFP Development Vendor Selection Hardware ImplementationStaff Training
Needs Assessment
Needs Analysis
Write RFP
Finalize with Purchasing
Research Vendors
Research Sites
Select Vendors to mail RFP
Review Proposals
Identify training Plan
Schedule Training
Train
Schedule Installation
Prepare Site
Arrange Vendor Support
Rank Proposals
Recommendation
Configure System
Install System
5
Work Breakdown Structure6
System Hardware Replacement
RFP Development Vendor Selection Hardware ImplementationStaff Training
Assess Needs
Analyze Needs
Write RFP
Finalize with Purchasing
Research Vendors
Research Sites
Select Vendors to mail RFP
Review Proposals
Identify training Plan
Schedule Training
Train Sysadmins
Schedule Installation
Prepare Site
Arrange Vendor Support
Rank Proposals
Make Recommendations
Configure System
Install System
WBS Dictionary7
A companion document to the WBS May have detailed content of the components
contained in a WBS, including work packages and control accounts
For each WBS component, the WBS dictionary includes a code of account identifier, a statement of work, responsible organization, and a list of schedule milestones
Can include a list of associated schedule activities, resources required, and an estimate of cost
Each WBS component is cross-referenced, as appropriate, to other WBS components
Software Cost Estimation
What is cost ?
Dictionary: es·ti·mate (es′ti mit), n.an approximate judgment or
calculation, as of the value or amount of something
Real life view a prediction that is equally likely to be
above or below the actual result
Why Estimate Software?
30% of project never complete100-200% cost overruns not uncommonAverage project exceeds cost by 90%;
Schedule by 120%15% of large project never deliver anythingOnly 16.2% of projects are successfulsource: 1998, 1999, 2000 Standish report, Choas
Fundamental estimation questionsHow much effort is required to complete an
activity?How much calendar time is needed to
complete an activity?What is the total cost of an activity?Project estimation and scheduling and
interleaved management activities
Software cost components
Hardware and software costsTravel and training costsEffort costs (the dominant factor in most
projects) salaries of engineers involved in the project Social and insurance costs
Effort costs must take overheads into account costs of building, heating, lighting costs of networking and communications costs of shared facilities (e.g library, staff restaurant,
etc.)
What Do You Estimate?
Time (schedule)ResourcesCost
Software Cost Factors
Programmer AbilityProduct ComplexityProduct SizeAvailable TimeRequired Level of ReliabilityLevel of Technology
Estimation Options
Expert Judgment Estimation done by panel of experts
Bottom-Up Approach Project separated into components Estimate components, then combined
Algorithmic Models Use of software metrics, formulas Historical models
Expert Judgment
One or more experts are consulted to provide estimates, given information on the software project
Inherently top-down approachCommon approach is to have a panel of
experts, who will agree on estimates by consensus
May be affected by group dynamicsInteresting variation: Delphi technique
Delphi Technique
Developed by Rand CorporationCoordinator provide estimator informationEstimator provides estimation individually,
without discussion with each otherCoordinator summarises estimations and
other responses, distributes for another round of estimation
Estimation repeated as much as required
Often called Delphi method, proposed by Dr. Barry Boehm in his book, Software Engineering Economics.
Useful in assessing differences between past projects and new ones for which no historical precedent exists.
Methodology Expert Opinion
Pros: Little or no historical data needed. Suitable for new or unique projects.
Cons: Very subjective. Experts may introduce bias.
Larger number of experts will help to reduce bias Qualification of experts may be questioned.
Methodology Expert Opinion (cont’d)
MethodologiesExpert Opinion - Steps Gather a group of experts together, Describe overall program in enough detail
so experts can provide an estimate, Each member of the expert group then
does an independent of the resources needed,
Estimates are gathered anonymously and compared,
If there exists significant divergence among the estimates, the estimates will be returned to the expert group,
The expert group then discusses the estimates and the divergence and works to resolve differences, and
The expert group once again submits anonymous, independent estimates which continues until a stable estimate results.
Methodology Expert Opinion - Example
Three software engineers are renown in the ERP software development.
You hold interviews which each explaining the requirements,
sizing level, and development process for your new system.
Bottom-Up Approach
Product or requirements broken down into smaller components
Estimates done for components, then combined for overall estimate
Applies to Work Breakdown Structure, or other similar methods of decomposing the project
Bottom-Up Approach (Continued)
Easier to estimate, more accurate and detailed estimate can be done
However, the product may be more than the total of the components
Additional cost may be required to consolidate the components
Analogy
Estimates costs by comparing proposed programs with similar, previously completed programs for which historical data is available. Actual costs of similar existing system are adjusted for
complexity, technical, or physical differences to derive new cost estimates
Analogies are used early in a program cycle when there is insufficient actual cost data to use as a detailed approach
Compares similarities and differencesFocus is on main cost drivers.
MethodologiesAnalogy (cont’d)
Often use single historical data point.May have several analogy estimates of sub elements to
make up the total cost.Comparison process is key to success.
May have to add or delete functionality from historical costs to match new program
Consult technical experts for advice on complexity factors, technical, performance or physical differences.
Impact of differences on cost is subjective.
Algorithmic Models
Costs are analyzed using mathematical formulae linking costs with metrics
Common methods use kLOCExample: 3-point estimationDetailed studies of software project provides
empirical estimation modelsExample: COCOMO
Algorithmic cost modelling
Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: Effort = A SizeB M A is an organisation-dependent constant, B reflects the
disproportionate effort for large projects and M is a multiplier reflecting product, process and people attributes.
The most commonly used product attribute for cost
estimation is code size.Most models are similar but they use different
values for A, B and M.
COCOMO
Constructive Cost Model (COCOMO) is one of the earliest cost models widely used by the cost estimating community.
COCOMO was originally published in Software Engineering Economics by Dr. Barry Boehm in 1981.
COCOMO is a regression-based model that considers various historical programs software size and multipliers.
COCOMO (cont.)
COCOMO’s most fundamental calculation is the use of the Effort Equation to estimate the number of Person-Months required to develop a project. Example: # of person months * loaded labor rate =
Estimated CostMost of the other estimates (requirements,
maintenance, etc) are derived from this quantity.
COCOMO Mode & ModelThree development environments (modes)
Organic Mode Semidetached Mode Embedded Mode
Three increasingly complex models Basic Model Intermediate Model Detailed Model
COCOMO Modes
Organic Mode Developed in familiar, stable environment Product similar to previously developed product <50,000 DSIs (ex: accounting system)
Semidetached Mode somewhere between Organic and Embedded
Embedded Mode new product requiring a great deal of innovation inflexible constraints and interface requirements
(ex: real-time systems)
COCOMO Models
Basic Model Used for early rough, estimates of project cost,
performance, and schedule Accuracy: within a factor of 2 of actual 60% of time
Intermediate Model Uses Effort Adjustment Factor (EAF) from 15 cost
drivers Doesn’t account for 10 - 20 % of cost (trng, maint,
TAD, etc) Accuracy: within 20% of actuals 68% of time
Detailed Model Uses different Effort Multipliers for each phase of
project (everybody uses intermediate model)
Basic Model Effort Equation (COCOMO 81)
Effort=A(size)exponent
A is a constant based on the developmental mode organic = 2.4 semi = 3.0 embedded = 3.6
Size = 1000s Source Lines of Code (KSLOC) Exponent is constant given mode
organic = 1.05 semi = 1.12 embedded = 1.20
Basic COCOMO
Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs
It does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on software costs, which limits its accuracy
Basic COCOMO Model: Formula
E=ab (KLOC or KDSI) bb
D=cb (E) db
P=E/D where E is the effort applied in person-months, D is the development time in chronological months, KLOC / KDSI is the estimated number of delivered lines of code for the project (expressed in thousands), and P is the number of people required. The coefficients ab, bb, cb and db are given in next slide.
Contd…
Software project ab bb cb db Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32
Basic COCOMO Model: Equation
Mode Effort Schedule
Organic E=2.4*(KDSI)1.05 TDEV=2.5*(E)0.38
Semidetached E=3.0*(KDSI)1.12 TDEV=2.5*(E)0.35
Embedded E=3.6*(KDSI)1.20 TDEV=2.5*(E)0.32
Basic COCOMO Model: Limitation
Its accuracy is necessarily limited because of its lack of factors which have a significant influence on software costs
The Basic COCOMO estimates are within a factor of 1.3 only 29% of the time, and within a factor of 2 only 60% of the time
Basic COCOMO Model: Example
We have determined our project fits the characteristics of Semi-Detached mode
We estimate our project will have 32,000 Delivered Source Instructions. Using the formulas, we can estimate:
Effort = 3.0*(32) 1.12 = 146 man-months Schedule = 2.5*(146) 0.35 = 14 months Productivity = 32,000 DSI / 146 MM
= 219 DSI/MM Average Staffing = 146 MM /14 months
= 10 FSP
Intermediate COCOMO
Takes basic COCOMO as starting point Identifies personnel, product, computer
and project attributes which affect cost and development time.
Multiplies basic cost by attribute multipliers which may increase or decrease costs
Intermediate ModelEffort Equation (COCOMO 81)
Effort=EAF*A(size)exponent
EAF (effort adjustment factor) is the product of effort multipliers corresponding to each cost driver rating
A is a constant based on the developmental mode organic = 3.2 semi = 3.0 embedded = 2.8
Size = 1000s Delivered Source Instruction (KDSI) Exponent is constant given mode
COCOMO COST DRIVERSRatings range: VL, L, N, H, VH, XH
RELY Reliability PCAP Programmer Capability
DATA Database Size AEXP Applications Experience
CPLX Complexity PEXP Platform Experience
RUSE Required Reusability LTEX Language and Tool Experience
DOCU Documentation PCON Personnel Continuity
TIME Execution Time Constant TOOL Use of Software Tools
STOR Main Storage Constraint SITE Multisite Development
PVOL Platform Volatility SCED Required Schedule
ACAP Analyst Capability
Gone:VIRT,TURN,MDDP,VEXP New: RUSE, DOCU, PVOL, PCON
Project Scale FactorsPMestimated
3.67i
(Size)(SF) EMi
SF .0.910.01 wi
Scale Factors(Wi)
Very Low Low Nominal High Very High Extra High
PREC thoroughlyunprecedented
largelyunprecedented
somewhatunprecedented
generallyfamiliar
largely familiar throughlyfamiliar
FLEX rigorous occasionalrelaxation
somerelaxation
generalconformity
someconformity
general goals
RESL little (20%) some (40%) often (60%) generally(75%)
mostly (90%) full (100%)
TEAM very difficultinteractions
some difficultinteractions
basicallycooperativeinteractions
largelycooperative
highlycooperative
seamlessinteractions
PMAT weighted sum of 18 KPA achievement levels
Early Design and Post-Architecture Model
FactorsScaleProcessSizeEffort
sMultiplier
Environment
Environment: Product, Platform, People, Project Factors
Size: Nonlinear reuse and volatility effects
Process: Constraint, Risk/Architecture, Team, Maturity Factors
FactorsScaleProcess EffortSchedule Multiplier
Relativecost
Amount Modified
1.0
0.75
0.5
0.25
0.25 0.5 0.75 1.0
0.55
0.70
1.0
0.046
Usual LinearAssumption
Data on 2954NASA modules
[Selby, 1988]
Nonlinear Reuse Effects
COCOMO Model ComparisonsCOCOMO Ada COCOMO COCOMO II:
Application CompositionCOCOMO II:Early Design
COCOMO II:Post-Architecture
Size Delivered Source Instructions(DSI) or Source Lines ofCode (SLOC)
DSI or SLOC Application Points Function Points (FP) andLanguage or SLOC
FP and Language or SLOC
Reuse Equivalent SLOC = Linear(DM,CM,IM)
Equivalent SLOC = Linear(DM,CM,IM)
Implicit in Model Equivalent SLOC = nonlinear(AA, SU,UNFM,DM,CM,IM)
Equivalent SLOC = nonlinear(AA, SU,UNFM,DM,CM,IM)
Rqts. Change Requirements Volatilityrating: (RVOL)
RVOL rating Implicit in Model Change % : RQEV
Maintenance Annual Change Traffic(ACT) = %added + %modified
ACT Object Point ACT (ACT,SU,UNFM) (ACT,SU,UNFM)
Scale (b) inMMNOM=a(Size)b
Organic: 1.05 Semidetached:1.12 Embedded: 1.20
Embedded: 1.04 -1.24depending on degree of: early risk elimination solid architecture stable requirements Ada process maturity
1.0 .91-1.23 depending on thedegree of: precedentedness conformity early architecture, risk
resolution team cohesion process maturity (SEI)
.91-1.23 depending on thedegree of: precedentedness conformity early architecture, risk
resolution team cohesion process maturity (SEI)
Product Cost Drivers RELY, DATA, CPLX RELY*, DATA, CPLX*,RUSE
None RCPX*, RUSE* RELY, DATA, DOCU*,CPLX, RUSE*
Platform Cost Drivers TIME, STOR, VIRT, TURN TIME, STOR, VMVH,VMVT, TURN
None Platform difficulty: PDIF * TIME, STOR, PVOL(=VIRT)
Personnel CostDrivers
ACAP, AEXP, PCAP,VEXP, LEXP
ACAP*, AEXP, PCAP*,VEXP, LEXP*
None Personnel capability andexperience: PERS*, PREX*
ACAP*, AEXP, PCAP*,PEXP*, LTEX*, PCON*
Project Cost Drivers MODP, TOOL, SCED MODP*, TOOL*, SCED,SECU
None SCED, FCIL* TOOL*, SCED, SITE*
* Different Multipliers Different Rating Scale
RQEV
Percentage of sample projects within 30% of actuals
-Without and with calibration to data source
COCOMO II Estimation Accuracy:
COCOMO81 COCOMOII.2000COCOMOII.1997
# Projects 63 83 161
Effort
Schedule
81% 52%64%
75%80%
61%62%
72%81%
65%