COCOMO II Overview
description
Transcript of COCOMO II Overview
(c) 2005-08 USC CSSE 1
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO II Overview
A Winsor Brown (especially from page 50 on)(Based on original by Ray Madachy [email protected])
CSCI 510 September 22, 2008
(c) 2005-08 USC CSSE 2
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Agenda• COCOMO introduction• Basic estimation formulas• Cost factors• Reuse model• Sizing• USC COCOMO tool demo• Data collection
(c) 2005-08 USC CSSE 3
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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 is the most widely used, thoroughly documented and calibrated cost model
– Price-to-win– Top-down– Bottom-up
(c) 2005-08 USC CSSE 4
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO Background• COCOMO - the “COnstructive COst MOdel”
– COCOMO II is the update to COCOMO 1981– ongoing research with annual calibrations made available
• Originally developed by Dr. Barry Boehm and published in 1981 book Software Engineering Economics
• COCOMO II described in new book Software Cost Estimation with COCOMO II
• COCOMO can be used as a framework for cost estimation and related activities
(c) 2005-08 USC CSSE 5
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
• Effect of uncertaintiesover time
Software Estimation Accuracy
Feasibility Plans/Rqts. Design Develop and Test
Phases and Milestones
Relative Size
Range
OperationalConcept
Life Cycle Objectives
Life Cycle Architecture
Initial Operating Capability
x
0.5x
0.25x
4x
2x
(c) 2005-08 USC CSSE 6
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO Black Box Model
COCOMO II
product size estimate
product, process, platform, and personnel attributes
reuse, maintenance, and increment parameters
organizational project data
development, maintenance cost and schedule estimates
cost, schedule distribution by phase, activity, increment
recalibration to organizational data
(c) 2005-08 USC CSSE 7
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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
(c) 2005-08 USC CSSE 8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO Uses for Software Decision Making
• Making investment decisions and business-case analyses • Setting project budgets and schedules • Performing tradeoff analyses• Cost risk management• Development vs. reuse decisions• Legacy software phaseout decisions• Software reuse and product line decisions• Process improvement decisions
(c) 2005-08 USC CSSE 9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Productivity Ranges• COCOMO provides natural framework to identify high
leverage productivity improvement factors and estimate their payoffs.
4.14
3.37
2.21
1.85
1.72
1.67
1.64
1.60
1.57
1.49
1.48
1.29
1.28
1.27
1 1.5 2 2.5 3 3.5 4 4.5
Personnel Capability
Personnel Experience
Product Complexity
Required Reliability
Use of Software Tools
Execution Time Constraint
Required Reuse
Multisite Development
Main Storage Constraint
Platform Volatility
Personnel Continuity
Required Development Schedule
Database Size
Documentation
Cos
t Fac
tor
Productivity Range
(c) 2005-08 USC CSSE 10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO Submodels• Applications Composition involves rapid development or prototyping efforts
to resolve potential high-risk issues such as user interfaces, software/system interaction, performance, or technology maturity. It’s sized with application points (weighted screen elements, reports and 3GL modules).
• The Early Design model involves exploration of alternative software/system architectures and concepts of operation using function points and a course-grained set of 7 cost drivers.
• The Post-Architecture model involves the actual development and maintenance of a software product using source instructions and / or function points for sizing, with modifiers for reuse and software breakage; a set of 17 multiplicative cost drivers; and a set of 5 factors determining the project's scaling exponent.
(c) 2005-08 USC CSSE 11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Agenda• COCOMO introduction• Basic estimation formulas• Cost factors• Reuse model• Sizing• USC COCOMO tool demo• Data collection
(c) 2005-08 USC CSSE 12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO Effort Formulation # of cost drivers
Effort (person-months) = A (Size)B 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– B is an exponent for the diseconomy of scale dependent on five additive scale
drivers according to b = .91 + .01*SFi,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
(c) 2005-08 USC CSSE 13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Diseconomy of Scale• Nonlinear relationship when exponent > 1
0
2000
4000
6000
8000
10000
12000
14000
16000
0 500 1000
KSLOC
Per
son
Mon
ths B=1.226
B=1.00
B=0.91
(c) 2005-08 USC CSSE 14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
• 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– B is the sum of project scale factors – 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.
COCOMO Schedule FormulationSchedule (months) = C (Effort)(.33+0.2(B-1.01)) x SCED%/100
(c) 2005-08 USC CSSE 15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Coverage of Different Processes• COCOMO II provides a framework for tailoring the model
to any desired process• Original COCOMO was predicated on the waterfall process
– single-pass, sequential progression of requirements, design, code, test
• Modern processes are concurrent, iterative, incremental, and cyclic
– e.g. Rational Unified Process (RUP), the USC Model-Based Architecting and Software Engineering (MBASE) process
• Effort and schedule are distributed among different phases and activities per work breakdown structure of chosen process
(c) 2005-08 USC CSSE 16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Common Process Anchor Points• Anchor points are common process milestones around
which cost and schedule budgets are organized• COCOMO II submodels address different
development stages anchored by these generic milestones:
– Life Cycle Objectives (LCO)• inception: establishing a sound business case
– Life Cycle Architecture (LCA)• elaboration: commit to a single architecture and elaborate it to cover all major risk
sources– Initial Operational Capability (IOC)
• construction: commit to transition and support operations
(c) 2005-08 USC CSSE 17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
MBASE Phase Distributions
125118Project Total
100100COCOMO Total
12.512Transition
62.576Construction
37.524Elaboration
12.56Inception
Schedule %Effort %Phase
• see COCOMO II book for complete phase/activity distributions
(c) 2005-08 USC CSSE 18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Waterfall Phase Distributions
125119Project Total
100100COCOMO Total
12.512
Integration & Test
4858Programming
2617Product Design
207Plans & rqts
Schedule %Effort %Phase
Transition
25 26
(c) 2005-08 USC CSSE 19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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. Stage Optimistic
EstimatePessimistic
Estimate
1 0.50 E 2.0 E
2 0.67 E 1.5 E
3 0.80 E 1.25 E
(c) 2005-08 USC CSSE 20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO Tailoring & Enhancements• Calibrate effort equations to organizational experience
– USC COCOMO has a calibration capability• Consolidate or eliminate redundant cost driver
attributes• Add cost drivers applicable to your organization• Account for systems engineering, hardware and
software integration
(c) 2005-08 USC CSSE 21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Agenda• COCOMO introduction• Basic estimation formulas• Cost factors• Reuse model• Sizing• USC COCOMO tool demo• Data collection
(c) 2005-08 USC CSSE 22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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
(c) 2005-08 USC CSSE 23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Scale Drivers• Precedentedness (PREC)
– 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
(c) 2005-08 USC CSSE 24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Cost Drivers• Product 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)
(c) 2005-08 USC CSSE 25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Example Cost Driver - 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? Very Low Low Nominal High Very High Extra High
RELY slightinconvenience
low, easilyrecoverablelosses
moderate,easilyrecoverablelosses
high financialloss
risk to humanlife
(c) 2005-08 USC CSSE 26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Example Effort Multiplier Values for RELY
Very Low Low High Very High
Slight Inconvenience
Low, Easily Recoverable
Losses
High Financial Loss
Risk to Human Life
1.15
0.75
0.88
1.39
1.0Moderate, Easily
Recoverable Losses
Nominal
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)
(c) 2005-08 USC CSSE 27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Scale Factors
• Sum scale factors Wi across all of the factors to determine a scale exponent, B, using B = .91 + .01 Wi
Scale Factors (Wi) Very Low Low Nominal High Very High Extra High
Precedentedness(PREC)
thoroughlyunprecedented
largelyunprecedented
somewhatunprecedented
generallyfamiliar
largelyfamiliar
throughlyfamiliar
DevelopmentFlexibility (FLEX)
rigorous occasionalrelaxation
somerelaxation
generalconformity
someconformity
generalgoals
Architecture/RiskResolution (RESL)*
little (20%) some (40%) often (60%) generally(75%)
mostly(90%)
full (100%)
Team Cohesion(TEAM)
very difficultinteractions
some difficultinteractions
basicallycooperativeinteractions
largelycooperative
highlycooperative
seamlessinteractions
Process Maturity(PMAT)
Weighted average of “Yes” answers to CMM Maturity Questionnaire
* % significant module interfaces specified, % significant risks eliminated
(c) 2005-08 USC CSSE 28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Precedentedness (PREC) and Development Flexibility (FLEX)
• Elaboration of the PREC and FLEX rating scales:
Feature Very Low Nominal / High Extra High
PrecedentednessOrganizational understanding of productobjectives
General Considerable Thorough
Experience in working with related softwaresystems
Moderate Considerable Extensive
Concurrent development of associated newhardware and operational procedures
Extensive Moderate Some
Need for innovative data processingarchitectures, algorithms
Considerable Some Minimal
Development FlexibilityNeed for software conformance with pre-established requirements
Full Considerable Basic
Need for software conformance withexternal interface specifications
Full Considerable Basic
Premium on early completion High Medium Low
(c) 2005-08 USC CSSE 29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Architecture / Risk Resolution (RESL)• Use a subjective weighted average of the
characteristics:Characteristic Very Low Low Nominal High Very High Extra High
Risk Management Plan identifies all criticalrisk items, establishes milestones forresolving them by PDR.
None Little Some Generally Mostly Fully
Schedule, budget, and internal milestonesthrough PDR compatible with RiskManagement Plan
None Little Some Generally Mostly Fully
Percent of development schedule devotedto establishing architecture, given generalproduct objectives
5 10 17 25 33 40
Percent of required top software architectsavailable to project
20 40 60 80 100 120
Tool support available for resolving riskitems, developing and verifyingarchitectural specs
None Little Some Good Strong Full
Level of uncertainty in Key architecturedrivers: mission, user interface, COTS,hardware, technology, performance.
Extreme Significant Considerable Some Little Very Little
Number and criticality of risk items > 10Critical
5-10Critical
2-4Critical
1Critical
> 5 Non-Critical
< 5 Non-Critical
(c) 2005-08 USC CSSE 30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Team Cohesion (TEAM)• Use a subjective weighted average of the
characteristics to account for project turbulence and entropy due to difficulties in synchronizing the project's stakeholders.
• Stakeholders include users, customers, developers, maintainers, interfacers, and others
Characteristic Very Low Low Nominal High Very High Extra HighConsistency of stakeholderobjectives and cultures
Little Some Basic Considerable Strong Full
Ability, willingness of stakeholders toaccommodate other stakeholders'objectives
Little Some Basic Considerable Strong Full
Experience of stakeholders inoperating as a team
None Little Little Basic Considerable Extensive
Stakeholder teambuilding to achieveshared vision and commitments
None Little Little Basic Considerable Extensive
(c) 2005-08 USC CSSE 31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Process Maturity (PMAT)• Two methods based on the Software Engineering
Institute's Capability Maturity Model (CMM)• Method 1:
Overall Maturity Level (CMM Level 1 through 5)
• Method 2: Key Process Areas(see next slide)
(c) 2005-08 USC CSSE 32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Key Process Areas• Decide the percentage of compliance for each of the
KPAs as determined by a judgement-based averaging across the goals for all 18 Key Process Areas.
Key Process Areas Almost Always(>90%)
Frequently(60-90%)
About Half(40-60%)
Occasionally(10-40%)
Rarely If Ever(<10%)
Does NotApply
Don'tKnow
1 RequirementsManagement
2 Software ProjectPlanning
3 Software ProjectTracking and Oversight
4 Software SubcontractManagement
(See COCOMO II Model Definition Manual for remaining details)
PMAT = 5 1005181
18
KPAi
i
%
(c) 2005-08 USC CSSE 33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Cost Drivers
• Product Factors • Platform Factors • Personnel Factors • Project Factors
(c) 2005-08 USC CSSE 34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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
Very Low Low Nominal High Very High Extra HighRELY slight
inconveniencelow, easilyrecoverable losses
moderate, easilyrecoverable losses
high financial loss risk to human life
(c) 2005-08 USC CSSE 35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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):
)()(
SLOCSizeProgramByteszeDataBaseSi
PD
Very Low Low Nominal High Very High Extra HighDATA DB bytes/ Pgm SLOC < 10 10 D/P < 100 100 D/P < 1000 D/P > 1000
(c) 2005-08 USC CSSE 36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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
(c) 2005-08 USC CSSE 37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.Very Low Low Nominal High Very High Extra High
ControlOperations
Straightline codewith a few non-nested structuredprogrammingoperators: DOs,CASEs,IFTHENELSEs.Simple modulecomposition viaprocedure calls orsimple scripts.
Straightforwardnesting ofstructuredprogrammingoperators.Mostly simplepredicates.
Mostly simplenesting. Someintermodulecontrol. Decisiontables. Simplecallbacks ormessagepassing,includingmiddleware-supporteddistributedprocessing.
Highly nestedstructuredprogrammingoperators with manycompoundpredicates. Queueand stack control.Homogeneous, dist.processing. Singleprocessor soft real-time ctl.
Reentrant andrecursive coding.Fixed-priorityinterrupt handling.Task synchronization,complex callbacks,heterogeneous dist.processing. Single-processor hard real-time ctl.
Multiple resourcescheduling withdynamically changingpriorities. Microcode-level control.Distributed hard real-time control.
ComputationalOperations
Evaluation ofsimpleexpressions: e.g.,A=B+C*(D-E)
Evaluation ofmoderate-levelexpressions:e.g.,D=SQRT(B**2-4.*A*C)
Use of standardmath andstatisticalroutines. Basicmatrix/vectoroperations.
Basic numericalanalysis: multivariateinterpolation, ordinarydifferential eqns.Basic truncation,roundoff concerns.
Difficult but structurednumerical analysis:near-singular matrixequations, partialdifferential eqns.Simpleparallelization.
Difficult andunstructurednumerical analysis:highly accurateanalysis of noisy,stochastic data.Complexparallelization.
(c) 2005-08 USC CSSE 38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.Very Low Low Nominal High Very High Extra High
Device-dependentOperations
Simple read,writestatementswith simpleformats.
No cognizanceneeded of particularprocessor or I/Odevicecharacteristics. I/Odone at GET/PUTlevel.
I/O processingincludes deviceselection, statuschecking and errorprocessing.
Operations at physicalI/O level (physicalstorage addresstranslations; seeks,reads, etc.).Optimized I/O overlap.
Routines for interruptdiagnosis, servicing,masking.Communication linehandling.Performance-intensiveembedded systems.
Device timing-dependent coding,micro-programmedoperations.Performance-critical embeddedsystems.
DataManagementOperations
Simple arraysin mainmemory.Simple COTS-DB queries,updates.
Single file subsettingwith no data structurechanges, no edits, nointermediate files.Moderately complexCOTS-DB queries,updates.
Multi-file input andsingle file output.Simple structuralchanges, simpleedits. ComplexCOTS-DB queries,updates.
Simple triggersactivated by datastream contents.Complex datarestructuring.
Distributed databasecoordination. Complextriggers. Searchoptimization.
Highly coupled,dynamic relationaland objectstructures. Naturallanguage datamanagement.
UserInterfaceManagement
Simple inputforms, reportgenerators.
Use of simple graphicuser interface (GUI)builders.
Simple use ofwidget set.
Widget setdevelopment andextension. Simplevoice I/O, multimedia.
Moderately complex2D/3D, dynamicgraphics, multimedia.
Complexmultimedia, virtualreality.
(c) 2005-08 USC CSSE 39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.
Very Low Low Nominal High Very High Extra HighRUSE none across project across program across product line across multiple product lines
Very Low Low Nominal High Very High Extra HighDOCU Many life-cycle
needs uncoveredSome life-cycleneeds uncovered
Right-sized to life-cycle needs
Excessive for life-cycle needs
Very excessive forlife-cycle needs
(c) 2005-08 USC CSSE 40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Platform Factors• Platform
– 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.
Very Low Low Nominal High Very High Extra High
TIME 50% use of available execution time 70% 85% 95%
(c) 2005-08 USC CSSE 41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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).
Very Low Low Nominal High Very High Extra High
STOR 50% use of available storage 70% 85% 95%
Very Low Low Nominal High Very High Extra High
PVOL major change every 12 mo.;minor change every 1 mo.
major: 6 mo.;minor: 2 wk.
major: 2 mo.;minor: 1 wk.
major: 2 wk.;minor: 2 days
(c) 2005-08 USC CSSE 42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.
Very Low Low Nominal High Very High Extra HighACAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile
Very Low Low Nominal High Very High Extra HighPCAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile
(c) 2005-08 USC CSSE 43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.
Very Low Low Nominal High Very High Extra High
AEXP 2 months 6 months 1 year 3 years 6 years
Very Low Low Nominal High Very High Extra High
PEXP 2 months 6 months 1 year 3 years 6 year
(c) 2005-08 USC CSSE 44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.
Very Low Low Nominal High Very High Extra High
LTEX 2 months 6 months 1 year 3 years 6 years
Very Low Low Nominal High Very High Extra HighPCON 48% / year 24% / year 12% / year 6% / year 3% / year
(c) 2005-08 USC CSSE 45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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. Very Low Low Nominal High Very High Extra High
edit, code,debug
simple,frontend,backend CASE,little integration
basic lifecycletools, moderatelyintegrated
strong, maturelifecycle tools,moderatelyintegrated
strong, mature,proactive lifecycletools, well integratedwith processes,methods, reuse
(c) 2005-08 USC CSSE 46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.
Very Low Low Nominal High Very High Extra High
SITE:Collocation
International Multi-city andMulti-company
Multi-city orMulti-company
Same city ormetro. area
Same building orcomplex
Fully collocated
SITE:Communications
Some phone,mail
Individual phone,FAX
Narrowbandemail
Widebandelectroniccommunication
Wideband elect.comm, occasionalvideo conf.
Interactivemultimedia
Very Low Low Nominal High Very High Extra High
SCED 75% of nominal 85% 100% 130% 160%
(c) 2005-08 USC CSSE 47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Cost Factor Rating
• Whenever an assessment of a cost driver is between the rating levels: – always round to the Nominal rating – e.g. if a cost driver rating is between High
and Very High, then select High.
(c) 2005-08 USC CSSE 48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Cost Driver Rating Level Summary
Very Low Low Nominal High Very High Extra High
RELY slightinconvenience
low, easilyrecoverablelosses
moderate, easilyrecoverable losses
high financial loss risk to human life
DATA DB bytes/Pgm SLOC < 10
10 D/P < 100 100 D/P 1000 D/P > 1000
CPLX (see Complexity Table)
RUSE none across project across program across product line across multipleproduct lines
DOCU Many life-cycleneeds uncovered
Some life-cycleneeds uncovered
Right-sized to life-cycle needs
Excessive forlife-cycle needs
Very excessive forlife-cycle needs
TIME 50% use ofavailable executiontime
70% 85% 95%
STOR 50% use ofavailable storage
70% 85% 95%
PVOL major changeevery 12 mo.;minor changeevery 1 mo.
major: 6 mo.;minor: 2 wk.
major: 2 mo.;minor: 1 wk.
major: 2 wk.;minor: 2 days
(c) 2005-08 USC CSSE 49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Cost Driver Rating Level Summary cont’d
Very Low Low Nominal High Very High Extra High
ACAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile
PCAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile
PCON 48% / year 24% / year 12% / year 6% / year 3% / year
AEXP 2 months 6 months 1 year 3 years 6 years
PEXP 2 months 6 months 1 year 3 years 6 year
LTEX 2 months 6 months 1 year 3 years 6 year
TOOL edit, code,debug
simple, frontend,backend CASE,little integration
basic lifecycletools, moderatelyintegrated
strong, maturelifecycle tools,moderatelyintegrated
strong, mature, proactivelifecycle tools, wellintegrated with processes,methods, reuse
SITE:Collocation
International Multi-city andMulti-company
Multi-city orMulti-company
Same city ormetro. area
Same building or complex Fullycollocated
SITE:Commu-nications
Some phone,mail
Individual phone,FAX
Narrowband email Widebandelectroniccommunication.
Wideband elect. comm,occasional video conf.
Interactivemultimedia
SCED 75% of nominal 85% 100% 130% 160%
(c) 2005-08 USC CSSE 50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Agenda• COCOMO introduction• Basic estimation formulas• Cost factors• Reuse model• Sizing• USC COCOMO tool demo• Data collection
(c) 2005-08 USC CSSE 51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.
(c) 2005-08 USC CSSE 52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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.
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]
(c) 2005-08 USC CSSE 53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO Reuse Model• A nonlinear estimation model to convert
adapted (reused or modified) software into equivalent size of new software:
A A F D M C M I M 0 4 0 3 0 3. ( ) . ( ) . ( )
E S L O CA S L O C A A A A F S U U N F M
A A F
[ ( . ( ) ( ) ) ]
, .1 0 0 2
1 0 00 5
E S L O CA S L O C A A A A F S U U N F M
A A F
[ ( ) ( ) ]
, .1 0 0
0 5
(c) 2005-08 USC CSSE 54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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).
(c) 2005-08 USC CSSE 55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Assessment and Assimilation Increment (AA)
AA Increment Level of AA Effort0 None
2 Basic module search and documentation
4 Some module Test and Evaluation (T&E), documentation
6 Considerable module T&E, documentation
8 Extensive module T&E, documentation
(c) 2005-08 USC CSSE 56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
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).Very Low Low Nominal High Very High
Structure Very lowcohesion, highcoupling,spaghetti code.
Moderately lowcohesion, highcoupling.
Reasonably well-structured; someweak areas.
High cohesion, lowcoupling.
Strong modularity,information hiding indata / controlstructures.
ApplicationClarity
No matchbetween programand applicationworld views.
Some correlationbetween programand application.
Moderatecorrelationbetween programand application.
Good correlationbetween programand application.
Clear match betweenprogram andapplication world-views.
Self-Descriptiveness
Obscure code;documentationmissing, obscureor obsolete
Some codecommentary andheaders; someusefuldocumentation.
Moderate level ofcodecommentary,headers,documentations.
Good codecommentary andheaders; usefuldocumentation;some weak areas.
Self-descriptive code;documentation up-to-date, well-organized,with design rationale.
SU Incrementto ESLOC
50 40 30 20 10
(c) 2005-08 USC CSSE 57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Programmer Unfamiliarity (UNFM)
UNFM Increment Level of Unfamiliarity0.0 Completely familiar
0.2 Mostly familiar
0.4 Somewhat familiar
0.6 Considerably familiar
0.8 Mostly unfamiliar
1.0 Completely unfamiliar
• Only applies to modified software
(c) 2005-08 USC CSSE 58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Commercial Off-the-Shelf (COTS) Software
• Current best approach is to treat as reused piece• A COTS cost model is under development• Calculate effective size from external interface files
and breakage• Have identified candidate COTS cost drivers
(c) 2005-08 USC CSSE 59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Reuse Parameter Guidelines
(c) 2005-08 USC CSSE 60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Agenda• COCOMO introduction• Basic estimation formulas• Cost factors• Reuse model• Sizing• USC COCOMO tool demo• Data collection
(c) 2005-08 USC CSSE 61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Lines of Code• Source Lines of Code (SLOCs) = logical source
statements• Logical source statements = data declarations +
executable statements• Executable statements cause runtime actions• Declaration statements are nonexecutable
statements that affect an assembler's or compiler's interpretation of other program elements
• Codecount tool available on USC web site
(c) 2005-08 USC CSSE 62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Lines of Code Counting Rules• Standard definition for
counting lines– Based on SEI definition
checklist from CMU/SEI-92-TR-20
– Modified for COCOMO II
• When a line or statement contains more than one type, classify it as the type with the highest precedence. Order of precedence is in ascending order
Statement type Includes Excludes
1. Executable
2. Non-executable:
3. Declarations
4. Compiler directives
5. Comments:
6. On their own lines
7. On lines with source code
8. Banners and non-blank spacers
9. Blank (empty) comments
10. Blank lines
(c) 2005-08 USC CSSE 63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Lines of Code Counting Rules cont’d• (See COCOMO II
book for remaining details)
How produced Includes Excludes1. Programmed
2. Generated with source code generators
3. Converted with automated translators
4. Copied or reused without change
5. Modified
6. Removed
Origin Includes Excludes
1. New work: no prior existence
2. Prior work: taken or adapted from:
3. A previous version, build, or release
4. Commercial, off-the-shelf software (COTS), other than libraries
5. Government furnished software (GFS), other than reuse libraries
6. Another product
7. A vendor-supplied language support library (unmodified)
8. A vendor-supplied operating system or utility (unmodified)
9. A local or modified language support library or operating system
(c) 2005-08 USC CSSE 64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Counting with Function Points• Used in both the Early Design and the Post-
Architecture models.• Based on the amount of functionality in a
software product and project factors using information available early in the project life cycle.
• Quantify the information processing functionality with the following user function types:
(c) 2005-08 USC CSSE 65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Counting with Function Points cont’d– External Input (Inputs)
• Count each unique user data or user control input type that both
– Enters the external boundary of the software system being measured
– Adds or changes data in a logical internal file.
– External Output (Outputs)• Count each unique user data or control output type that
leaves the external boundary of the software system being measured.
(c) 2005-08 USC CSSE 66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Counting with Function Points cont’d– Internal Logical File (Files)
• Count each major logical group of user data or control information in the software system as a logical internal file type. Include each logical file (e.g., each logical group of data) that is generated, used, or maintained by the software system.
– External Interface Files (Interfaces)• Files passed or shared between software systems should
be counted as external interface file types within each system.
(c) 2005-08 USC CSSE 67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Counting with Function Points cont’d– External Inquiry (Queries)
• Count each unique input-output combination, where an input causes and generates an immediate output, as an external inquiry type.
• Each instance of the user function types is then classified by complexity level. The complexity levels determine a set of weights, which are applied to their corresponding function counts to determine the Unadjusted Function Points quantity.
(c) 2005-08 USC CSSE 68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Counting with Function Points cont’d
• The usual Function Point procedure involves assessing the degree of influence of fourteen application characteristics on the software project.
• The contributions of these characteristics are inconsistent with COCOMO experience, so COCOMO II uses Unadjusted Function Points for sizing.
(c) 2005-08 USC CSSE 69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Unadjusted Function Points Counting• Step 1 - Determine function counts by type.
– The unadjusted function counts should be counted by a lead technical person based on information in the software requirements and design documents.
– The number of each of the five user function types should be counted
• Internal Logical File (ILF)– Note: The word file refers to a logically related group of data and not the physical
implementation of those groups of data.
• External Interface File (EIF)• External Input (EI)• External Output (EO)• External Inquiry (EQ))
(c) 2005-08 USC CSSE 70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Unadjusted Function Points Counting Procedure cont’d
• Step 2 - Determine complexity-level function counts. – Classify each function count into Low, Average and High complexity
levels depending on the number of data element types contained and the number of file types referenced. Use the following scheme:
For ILF and EIF For EO and EQ For EI
RecordElements
Data Elements FileTypes
Data Elements FileTypes
Data Elements
1 - 19 20 - 50 51+ 1 - 5 6 - 19 20+ 1 - 4 5 - 15 16+
1 Low Low Avg 0 or 1 Low Low Avg 0 or 1 Low Low Avg
2 - 5 Low Avg High 2 - 3 Low Avg High 2 - 3 Low Avg High
6+ Avg High High 4+ Avg High High 3+ Avg High High
(c) 2005-08 USC CSSE 71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Unadjusted Function Points Counting Procedure cont’d
• Step 3 - Apply complexity weights. – Weight the number in each cell using the following scheme. The weights
reflect the relative value of the function to the user.
• Step 4 - Compute Unadjusted Function Points. – Add all the weighted functions counts to get one number, the Unadjusted
Function Points.
Function Type Complexity-WeightLow Average High
Internal Logical Files 7 10 15
External Interfaces Files 5 7 10
External Inputs 3 4 6
External Outputs 4 5 7
External Inquiries 3 4 6
(c) 2005-08 USC CSSE 72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Agenda• COCOMO introduction• Basic estimation formulas• Cost factors• Reuse model• Sizing• USC COCOMO tool demo• Data collection
(c) 2005-08 USC CSSE 73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
USC COCOMO Demo
(c) 2005-08 USC CSSE 74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Agenda• COCOMO introduction• Basic estimation formulas• Cost factors• Reuse model• Sizing• USC COCOMO tool demo• Data collection
(c) 2005-08 USC CSSE 75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Cost Driver Ratings Profile
• Need to rate cost drivers in a consistent and objective fashion within an organization.
• Cost driver ratings profile:– Graphical depiction of historical ratings to be
used as a reference baseline to assist in rating new projects
– Used in conjunction with estimating tools to gauge new projects against past ones objectively
(c) 2005-08 USC CSSE 76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Example Cost Driver Ratings Profile
Very Low Low Nominal High Very High Extra High
RELY - required softwarereliability PROJ1
PROJ4
PROJ2PROJ3PROJ5PROJ6
effect: slightinconvenience
low, easilyrecoverable
losses
moderate,easily
recoverablelosses
high financialloss
risk to humanlife
DATA - data base size PROJ2PROJ3PROJ4
PROJ1PROJ5PROJ6
DBbytes/Prog.
SLOCS 10
10 D/P 100 100 D/P1000
D/P 1000
CPLX - product complexityPROJ3PROJ5PROJ1 PROJ4
PROJ2PROJ6
see attachedtable
____________ ____________ ____________ ____________ ____________
(c) 2005-08 USC CSSE 77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Techniques to Generate Cost Driver Ratings Profile
• Single person – Time efficient, but may impose bias and person
may be unfamiliar with all projects• Group
– Converge ratings in a single meeting (dominant individual problem)
– Wideband Delphi technique (longer calendar time, but minimizes biases). See Software Engineering Economics, p. 335
(c) 2005-08 USC CSSE 78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
COCOMO Dataset Cost Metrics
• Size (SLOCS, function points)• Effort (Person-hours)• Schedule (Months)• Cost drivers• Scale drivers• Reuse parameters
(c) 2005-08 USC CSSE 79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Recommended Project Cost Data
• For each project, report the following at the end of each month and for each release:– SIZE
• Provide total system size developed to date, and report new code size and reused / modified code size separately. This can be at a project level or lower level as the data supports and is reasonable. For languages not supported by tools such as assembly code, report the number of physical lines separately for each language.
– EFFORT• Provide cumulative staff-hours spent on software development per
project at the same granularity as the size components.
(c) 2005-08 USC CSSE 80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Recommended Project Cost Data cont’d– COST DRIVERS AND SCALE DRIVERS
• For each reported size component, supply the cost driver ratings for product, platform, personnel and project attributes. For each reported size component, supply scale driver ratings.
– REUSE PARAMETERS• For each component of reused/modified code,
supply reuse parameters AA, SU, UNFM, DM, CM and IM.
• See Appendix C in COCOMO II book for additional data items
• Post-mortem reports are highly recommended
(c) 2005-08 USC CSSE 81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Effort Staff-Hours Definition• Standard definition
– Based on SEI definition checklist in CMU/SEI-92-TR-21– Adapted for COCOMO II
• Does not include unpaid overtime, production and deployment activities, customer training activities
• Includes all personnel except level 3 or higher software management (i.e. directors or above who timeshare among projects)
• Person-month is defined as 152 hours
(c) 2005-08 USC CSSE 82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Sep. 2008
Further Information• B. Boehm, C. Abts, W. Brown, S. Chulani, B. Clark, E.
Horowitz, R. Madachy, D. Reifer, B. Steece, Software Cost Estimation with COCOMO II, Prentice-Hall, 2000
• B. Boehm, Software Engineering Economics. Englewood Cliffs, NJ, Prentice-Hall, 1981
• Main COCOMO website at USC: http://sunset.usc.edu/research/COCOMOII
• COCOMO information at USC: (213) 740-6470• COCOMO email: [email protected]