1. Cost Estimation with COCOMO II
Barry Boehm
CS 577a, Fall 2012

2. Outline
Model Overview
Model Reinterpretation for CS 577
©USC-CSSE

3. Software Cost Estimation Methods
Cost estimation: prediction of both the person-effort and elapsed time of a project
Methods:
Algorithmic
Expert judgement
Estimation by analogy
Parkinsonian
Best approach is a combination of methods
compare and iterate estimates, reconcile differences
COCOMO - the “COnstructive COst MOdel”
COCOMO II is the update to Dr. Barry Boehm’s COCOMO 1981
COCOMO is the most widely used, thoroughly documented and calibrated cost model
Price-to-win
Top-down
Bottom-up
©USC-CSSE

4. Software Estimation Accuracy4x
Effect of uncertainties over time 2x
Relative Size Range x
0.5x
Initial Operating Capability
Operational Concept
Life Cycle Objectives
Life Cycle Architecture
0.25x
Feasibility
Plans/Rqts.
Design
Develop and Test
Phases and Milestones
©USC-CSSE

5. COCOMO Black Box Model COCOMO II product size estimate
development, maintenance
cost and schedule estimates
product, process,
platform, and personnel
attributes
COCOMO II
reuse, maintenance,
and increment parameters
cost, schedule distribution by
phase, activity, increment
organizational
project data
recalibration to
organizational data
©USC-CSSE

6. Major COCOMO II Features
Multi-model coverage of different development sectors
Variable-granularity cost model inputs
Flexibility in size inputs
SLOCS
function points
application points
other (use cases ...?)
Range vs. point estimates per funnel chart
©USC-CSSE

7. Relations to ICSM-Sw/MBASE*/RUP Anchor Point Milestones
Application Compos.
Inception
Elaboration, Construction
Transition
IOC
COCOMO II estimates
SRR
PDR
Waterfall Rqts.
System Devel.
Prod. Des.
Development
Inception Phase
Elaboration
Construction
Transition
LCA
LCO
*MBASE: Model-Based (System) Architecting and Software Engineering
©USC-CSSE 7

8. COCOMO Effort Formulation
# of cost drivers
Effort (person-months) = A (Size)E P EMi
i=1
Where:
A is a constant derived from historical project data (currently A = 2.94 in COCOMOII.2000)
Size is in KSLOC (thousand source lines of code), or converted from function points or object points
E is an exponent for the diseconomy of scale dependent on five additive scale drivers according to b = *SSFi, where SFi is a weighting factor for ith scale driver
EMi is the effort multiplier for the ith cost driver. The geometric product results in an overall effort adjustment factor to the nominal effort.
Automated translation effects are not included
©USC-CSSE

9. Diseconomy of Scale Nonlinear relationship when exponent > 1
©USC-CSSE

10. COCOMO Schedule Formulation
Where:
Schedule is the calendar time in months from the requirements baseline to acceptance
C is a constant derived from historical project data (currently C = 3.67 in COCOMOII.2000)
Effort is the estimated person-months excluding the SCED effort multiplier
E is the exponent in the effort equation
SCED% is the compression / expansion percentage in the SCED cost driver
This is the COCOMOII.2000 calibration
Formula can vary to reflect process models for reusable and COTS software, and the effects of application composition capabilities.
Schedule (months) = C (Effort)( (E-1.01)) x SCED%/100
©USC-CSSE

11. MBASE Phase Distributions
see COCOMO II book for complete phase/activity distributions
Phase
Effort %
Schedule %
Inception 6
12.5
Elaboration 24
37.5
Construction 76
62.5
Transition 12
12.5
COCOMO Total
100
100
Project Total
118
125
©USC-CSSE

12. COCOMO II Output Ranges
COCOMO II provides one standard deviation optimistic and pessimistic estimates.
Reflect sources of input uncertainties per funnel chart.
Apply to effort or schedule for all of the stage models.
Represent 80% confidence limits: below optimistic or pessimistic estimates 10% of the time.
©USC-CSSE

13. Reused and Modified Software
Effort for adapted software (reused or modified) is not the same as for new software.
Approach: convert adapted software into equivalent size of new software.
©USC-CSSE

14. Nonlinear Reuse Effects
The reuse cost function does not go through the origin due to a cost of about 5% for assessing, selecting, and assimilating the reusable component.
Small modifications generate disproportionately large costs primarily due the cost of understanding the software to be modified, and the relative cost of interface checking.
©USC-CSSE

15. COCOMO Reuse Model
A nonlinear estimation model to convert adapted (reused or modified) software into equivalent size of new software:
©USC-CSSE

16. COCOMO Reuse Model cont’d
ASLOC - Adapted Source Lines of Code
ESLOC - Equivalent Source Lines of Code
AAF - Adaptation Adjustment Factor
DM - Percent Design Modified. The percentage of the adapted software's design which is modified in order to adapt it to the new objectives and environment.
CM - Percent Code Modified. The percentage of the adapted software's code which is modified in order to adapt it to the new objectives and environment.
IM - Percent of Integration Required for Modified Software. The percentage of effort required to integrate the adapted software into an overall product and to test the resulting product as compared to the normal amount of integration and test effort for software of comparable size.
AA - Assessment and Assimilation effort needed to determine whether a fully-reused software module is appropriate to the application, and to integrate its description into the overall product description. See table.
SU - Software Understanding. Effort increment as a percentage. Only used when code is modified (zero when DM=0 and CM=0). See table.
UNFM - Unfamiliarity. The programmer's relative unfamiliarity with the software which is applied multiplicatively to the software understanding effort increment (0-1).
©USC-CSSE
©USC-CSSE 16

17. Assessment and Assimilation Increment (AA)
©USC-CSSE
©USC-CSSE 17

18. Software Understanding Increment (SU)
Take the subjective average of the three categories.
Do not use SU if the component is being used unmodified (DM=0 and CM =0).
©USC-CSSE

19. Programmer Unfamiliarity (UNFM)
Only applies to modified software
©USC-CSSE

20. Cost Factors Significant factors of development cost:
scale drivers are sources of exponential effort variation
cost drivers are sources of linear effort variation
product, platform, personnel and project attributes
effort multipliers associated with cost driver ratings
Defined to be as objective as possible
Each factor is rated between very low and very high per rating guidelines
relevant effort multipliers adjust the cost up or down
May be difficult to quantify, but better than ignoring important project factors (e.g. b asic vs. intermediate accuracies)
©USC-CSSE

21. Scale Factors Precedentedness (PREC) Development Flexibility (FLEX)
Degree to which system is new and past experience applies
Development Flexibility (FLEX)
Need to conform with specified requirements
Architecture/Risk Resolution (RESL)
Degree of design thoroughness and risk elimination
Team Cohesion (TEAM)
Need to synchronize stakeholders and minimize conflict
Process Maturity (PMAT)
SEI CMM process maturity rating
©USC-CSSE

22. Scale Factor Rating
©USC-CSSE

23. Cost Drivers Product Factors Platform Factors Personnel factors
Reliability (RELY)
Data (DATA)
Complexity (CPLX)
Reusability (RUSE)
Documentation (DOCU)
Platform Factors
Time constraint (TIME)
Storage constraint (STOR)
Platform volatility (PVOL)
Personnel factors
Analyst capability (ACAP)
Program capability (PCAP)
Applications experience (APEX)
Platform experience (PLEX)
Language and tool experience (LTEX)
Personnel continuity (PCON)
Project Factors
Software tools (TOOL)
Multisite development (SITE)
Required schedule (SCED)
©USC-CSSE 23

24. Product Factors Required Software Reliability (RELY)
Measures the extent to which the software must perform its intended function over a period of time.
Ask: what is the effect of a software failure
©USC-CSSE 24

25. Example Effort Multiplier Values for RELY
1.39
1.15
Very Low
Low
Nominal
High
Very High
1.0
Slight Inconvenience
Low, Easily Recoverable Losses
Moderate, Easily Recoverable Losses
High Financial Loss
Risk to Human Life
0.88
0.75
E.g. a highly reliable system costs 39% more than a nominally reliable system 1.39/1.0=1.39) or a highly reliable system costs 85% more than a very low reliability system (1.39/.75=1.85)
©USC-CSSE 25

26. Product Factors cont’d
Data Base Size (DATA)
Captures the effect large data requirements have on development to generate test data that will be used to exercise the program
Calculate the data/program size ratio (D/P):
©USC-CSSE 26

27. Product Factors cont’d
Product Complexity (CPLX)
Complexity is divided into five areas:
control operations,
computational operations,
device-dependent operations,
data management operations, and
user interface management operations.
Select the area or combination of areas that characterize the product or a sub-system of the product.
See the module complexity table, next several slides
©USC-CSSE 27

28. Product Factors cont’d
Module Complexity Ratings vs. Type of Module
Use a subjective weighted average of the attributes, weighted by their relative product importance.
©USC-CSSE 28

29. Product Factors cont’d
Module Complexity Ratings vs. Type of Module
Use a subjective weighted average of the attributes, weighted by their relative product importance.
©USC-CSSE 29

30. Product Factors cont’d
Required Reusability (RUSE)
Accounts for the additional effort needed to construct components intended for reuse.
Documentation match to life-cycle needs (DOCU)
What is the suitability of the project's documentation to its life-cycle needs.
©USC-CSSE 30

31. Platform Factors Platform Execution Time Constraint (TIME)
Refers to the target-machine complex of hardware and infrastructure software (previously called the virtual machine).
Execution Time Constraint (TIME)
Measures the constraint imposed upon a system in terms of the percentage of available execution time expected to be used by the system.
©USC-CSSE 31

32. Platform Factors cont’d
Main Storage Constraint (STOR)
Measures the degree of main storage constraint imposed on a software system or subsystem.
Platform Volatility (PVOL)
Assesses the volatility of the platform (the complex of hardware and software the software product calls on to perform its tasks).
©USC-CSSE 32

33. Personnel Factors Analyst Capability (ACAP)
Analysts work on requirements, high level design and detailed design. Consider analysis and design ability, efficiency and thoroughness, and the ability to communicate and cooperate.
Programmer Capability (PCAP)
Evaluate the capability of the programmers as a team rather than as individuals. Consider ability, efficiency and thoroughness, and the ability to communicate and cooperate.
©USC-CSSE 33

34. Personnel Factors cont’d
Applications Experience (AEXP)
Assess the project team's equivalent level of experience with this type of application.
Platform Experience (PEXP)
Assess the project team's equivalent level of experience with this platform including the OS, graphical user interface, database, networking, and distributed middleware.
©USC-CSSE 34

35. Personnel Factors cont’d
Language and Tool Experience (LTEX)
Measures the level of programming language and software tool experience of the project team.
Personnel Continuity (PCON)
The scale for PCON is in terms of the project's annual personnel turnover.
©USC-CSSE 35

36. Project Factors Use of Software Tools (TOOL)
Assess the usage of software tools used to develop the product in terms of their capabilities and maturity.
©USC-CSSE
©USC-CSSE 36

37. Project Factors cont’d
Multisite Development (SITE)
Assess and average two factors: site collocation and communication support.
Required Development Schedule (SCED)
Measure the imposed schedule constraint in terms of the percentage of schedule stretch-out or acceleration with respect to a nominal schedule for the project.
©USC-CSSE 37

38. Demos
COCOMO II (standalone, in C) See
COCOMO II (web-Based) See for NOTE: no separate modules
©USC-CSSE

39. Fast (dangerous?) Function Point Sizing
Count number of files of different types
File: grouping of data elements handled similarly by software
External Input EI: files entering software system
External Output EO: files exiting software system
Internal Logical IL: internal files used by software system
External Interface EIF: files passed/shared between software systems
External Query EQ: input and immediate output response
Use Average complexity weights for all files
FP = 4 * EI + 5 * EO + 10 * IL + 7 * EIF + 4 * EQ
USC COCOMO II FP = 4(12) + 5(7) + 10(7) = 153
Java, C++ SLOC = 153(50) = 7650 SLOC
HTML, Power Builder = 153(20) = 3060 SLOC
Can use averages for mixes of languages
See COCOMO II book for detailed function point procedure
©USC-CSSE

40. Using COCOMO II in CS 577 Begin with COCOMO II bottom-up team estimate
Source lines of code (SLOC)
Using adjustments to CS 577 below
Focus on 577b Construction phase
Cross-check with estimate
Using Fast Function Point sizing
Effort by activity, rough 577b milestone plan
Adjust, try to reconcile both estimates
©USC-CSSE

41. COCOMO II Estimates for 577b
Disregard COCOMO II (CII) schedule estimates
Use COCOMO II effort estimates to determine how large a team needed for 12-week fixed schedule
Assuming 12 hours/week of dedicated effort per person
Assuming 10 of the 12 weeks fill COCOMO II Construction phase (72% of total effort estimate)
Assuming 100 hours/person-month for COCOMO estimates
For 577b Construction phase, these are equivalent:
1 577b team member effort = (10 weeks)(12 hours/week) = 120 hrs
1.67*[est'd COCOMO II person month] = (1.67)(100 hours)(0.72) = 120 hrs
So, one 577b team member effort = 1.67 CII person mon's
And 6 577b team members’ effort = 6*1.67 = 10 CII person mon's
5 on-campus students + 1 off-campus student
Or, N/ b team members’ effort = N CII person
©USC-CSSE