Post on 30-Jan-2016
description
1
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite
Barry Boehm
CSCI 510
Fall 2011
2
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
3
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II OverviewSoftware product size estimate
Software product process computer and personal attributes
Software reuse maintenance and increment parameters
Software organizationrsquos Project data
COCOMO
Software development and maintenancebull Costs (effort)bull Schedule estimatesbull Distributed by phase activity increment
COCOMO locally calibrated to organizationrsquos data
4
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Purpose of COCOMO IIbull To help people reason about the cost and schedule
implications of their software decisionsndash Software investment decisions
bull When to develop reuse or purchasebull What legacy software to modify or phase out
ndash Setting project budgets and schedulesndash Negotiating costscheduleperformance tradeoffsndash Making software risk management decisionsndash Making software improvement decisions
bull Reuse tools process maturity outsourcing
5
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Feasibility
Concept ofOperation
RqtsSpec
Plansand
Rqts
ProductDesign
ProductDesignSpec
DetailDesignSpec
DetailDesign
Develand Test
AcceptedSoftware
Phases and Milestones
RelativeSize Range x
4x
2x
125x
15x
025x
05x ApplicationsComposition
(3 parameters)
Early Design(13 parameters)
Post-Architecture(23 parameters)067x
08x
COCOMO II Model Stages
6
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II Scope of Outputsbull Provides the estimated software
development effort and schedule for MBASERUPndash Elaborationndash Construction
LCO LCA IOC
7
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Analyze existing literature
Step 1 Perform Behavioral analysesStep 2 Identify relative
significance
Step 3 Perform expert-judgment Delphi assessment formulate a-priori modelStep 4
Gather project data
Step 5
Determine Bayesian A-Posteriori modelStep 6
Gather more data refine modelStep 7
Concurrency and feedback impliedhellip
USC-CSE Modeling Methodology
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
2
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
3
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II OverviewSoftware product size estimate
Software product process computer and personal attributes
Software reuse maintenance and increment parameters
Software organizationrsquos Project data
COCOMO
Software development and maintenancebull Costs (effort)bull Schedule estimatesbull Distributed by phase activity increment
COCOMO locally calibrated to organizationrsquos data
4
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Purpose of COCOMO IIbull To help people reason about the cost and schedule
implications of their software decisionsndash Software investment decisions
bull When to develop reuse or purchasebull What legacy software to modify or phase out
ndash Setting project budgets and schedulesndash Negotiating costscheduleperformance tradeoffsndash Making software risk management decisionsndash Making software improvement decisions
bull Reuse tools process maturity outsourcing
5
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Feasibility
Concept ofOperation
RqtsSpec
Plansand
Rqts
ProductDesign
ProductDesignSpec
DetailDesignSpec
DetailDesign
Develand Test
AcceptedSoftware
Phases and Milestones
RelativeSize Range x
4x
2x
125x
15x
025x
05x ApplicationsComposition
(3 parameters)
Early Design(13 parameters)
Post-Architecture(23 parameters)067x
08x
COCOMO II Model Stages
6
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II Scope of Outputsbull Provides the estimated software
development effort and schedule for MBASERUPndash Elaborationndash Construction
LCO LCA IOC
7
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Analyze existing literature
Step 1 Perform Behavioral analysesStep 2 Identify relative
significance
Step 3 Perform expert-judgment Delphi assessment formulate a-priori modelStep 4
Gather project data
Step 5
Determine Bayesian A-Posteriori modelStep 6
Gather more data refine modelStep 7
Concurrency and feedback impliedhellip
USC-CSE Modeling Methodology
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
3
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II OverviewSoftware product size estimate
Software product process computer and personal attributes
Software reuse maintenance and increment parameters
Software organizationrsquos Project data
COCOMO
Software development and maintenancebull Costs (effort)bull Schedule estimatesbull Distributed by phase activity increment
COCOMO locally calibrated to organizationrsquos data
4
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Purpose of COCOMO IIbull To help people reason about the cost and schedule
implications of their software decisionsndash Software investment decisions
bull When to develop reuse or purchasebull What legacy software to modify or phase out
ndash Setting project budgets and schedulesndash Negotiating costscheduleperformance tradeoffsndash Making software risk management decisionsndash Making software improvement decisions
bull Reuse tools process maturity outsourcing
5
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Feasibility
Concept ofOperation
RqtsSpec
Plansand
Rqts
ProductDesign
ProductDesignSpec
DetailDesignSpec
DetailDesign
Develand Test
AcceptedSoftware
Phases and Milestones
RelativeSize Range x
4x
2x
125x
15x
025x
05x ApplicationsComposition
(3 parameters)
Early Design(13 parameters)
Post-Architecture(23 parameters)067x
08x
COCOMO II Model Stages
6
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II Scope of Outputsbull Provides the estimated software
development effort and schedule for MBASERUPndash Elaborationndash Construction
LCO LCA IOC
7
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Analyze existing literature
Step 1 Perform Behavioral analysesStep 2 Identify relative
significance
Step 3 Perform expert-judgment Delphi assessment formulate a-priori modelStep 4
Gather project data
Step 5
Determine Bayesian A-Posteriori modelStep 6
Gather more data refine modelStep 7
Concurrency and feedback impliedhellip
USC-CSE Modeling Methodology
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
4
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Purpose of COCOMO IIbull To help people reason about the cost and schedule
implications of their software decisionsndash Software investment decisions
bull When to develop reuse or purchasebull What legacy software to modify or phase out
ndash Setting project budgets and schedulesndash Negotiating costscheduleperformance tradeoffsndash Making software risk management decisionsndash Making software improvement decisions
bull Reuse tools process maturity outsourcing
5
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Feasibility
Concept ofOperation
RqtsSpec
Plansand
Rqts
ProductDesign
ProductDesignSpec
DetailDesignSpec
DetailDesign
Develand Test
AcceptedSoftware
Phases and Milestones
RelativeSize Range x
4x
2x
125x
15x
025x
05x ApplicationsComposition
(3 parameters)
Early Design(13 parameters)
Post-Architecture(23 parameters)067x
08x
COCOMO II Model Stages
6
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II Scope of Outputsbull Provides the estimated software
development effort and schedule for MBASERUPndash Elaborationndash Construction
LCO LCA IOC
7
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Analyze existing literature
Step 1 Perform Behavioral analysesStep 2 Identify relative
significance
Step 3 Perform expert-judgment Delphi assessment formulate a-priori modelStep 4
Gather project data
Step 5
Determine Bayesian A-Posteriori modelStep 6
Gather more data refine modelStep 7
Concurrency and feedback impliedhellip
USC-CSE Modeling Methodology
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
5
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Feasibility
Concept ofOperation
RqtsSpec
Plansand
Rqts
ProductDesign
ProductDesignSpec
DetailDesignSpec
DetailDesign
Develand Test
AcceptedSoftware
Phases and Milestones
RelativeSize Range x
4x
2x
125x
15x
025x
05x ApplicationsComposition
(3 parameters)
Early Design(13 parameters)
Post-Architecture(23 parameters)067x
08x
COCOMO II Model Stages
6
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II Scope of Outputsbull Provides the estimated software
development effort and schedule for MBASERUPndash Elaborationndash Construction
LCO LCA IOC
7
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Analyze existing literature
Step 1 Perform Behavioral analysesStep 2 Identify relative
significance
Step 3 Perform expert-judgment Delphi assessment formulate a-priori modelStep 4
Gather project data
Step 5
Determine Bayesian A-Posteriori modelStep 6
Gather more data refine modelStep 7
Concurrency and feedback impliedhellip
USC-CSE Modeling Methodology
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
6
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II Scope of Outputsbull Provides the estimated software
development effort and schedule for MBASERUPndash Elaborationndash Construction
LCO LCA IOC
7
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Analyze existing literature
Step 1 Perform Behavioral analysesStep 2 Identify relative
significance
Step 3 Perform expert-judgment Delphi assessment formulate a-priori modelStep 4
Gather project data
Step 5
Determine Bayesian A-Posteriori modelStep 6
Gather more data refine modelStep 7
Concurrency and feedback impliedhellip
USC-CSE Modeling Methodology
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
7
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Analyze existing literature
Step 1 Perform Behavioral analysesStep 2 Identify relative
significance
Step 3 Perform expert-judgment Delphi assessment formulate a-priori modelStep 4
Gather project data
Step 5
Determine Bayesian A-Posteriori modelStep 6
Gather more data refine modelStep 7
Concurrency and feedback impliedhellip
USC-CSE Modeling Methodology
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Analyze existing literature
Step 1 Perform Behavioral analysesStep 2 Identify relative
significance
Step 3 Perform expert-judgment Delphi assessment formulate a-priori modelStep 4
Gather project data
Step 5
Determine Bayesian A-Posteriori modelStep 6
Gather more data refine modelStep 7
Concurrency and feedback impliedhellip
USC-CSE Modeling Methodology
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Status of Models
Model Literature BehaviorSignificant Variables
Delphi Data Bayesian
Tool
COCOMO II gt200 Product
COQUALMO 6 Excel
iDAVE Excel
COPLIMO Excel
CORADMO 10 Excel
COPROMO Excel
COCOTS 20 Excel
COSYSMO 42 Excel
COSOSIMO na Excel
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
10
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
General COCOMO FormPM = A ( Size)B (EM)
ADDITIVE EXPONENTIAL
MULTIPLICATIVE
WherePM = Person Months
A = calibration factor
Size = measure(s) of functional size of a software module that has an additive effect on software development effort
B = scale factor(s) that have an exponential or nonlinear effect on software development effort
EM = effort multipliers that influence software development effort
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
11
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Quantities Estimated
Model EffortEffort
by Phase
Schedule Defects ROIImprovement
Graphs
COCOMO II X X X
COQUALMO X X X
iDAVE X
COPLIMO X X
CORADMO X X X
COPROMO X X X
COCOTS X
COSYSMO X
COSOSIMO X
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite Sizing
Model SL
OC
FP
+ L
ang
Req
uirem
ents
Interfaces
Scen
arios
Algorith
ms
Com
pon
ents
Com
plexity
Reu
se V
olatility
COCOMO II Module Module X X
CORADMO X X X X
COQUALMO X X X X
COSYSMO X X X X X X X
COSOSIMO Glue X X X X X X
COCOTS Glue Glue X
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO Suite PhaseActivity Distribution
Model Inception Elaboration Construction Transition
COCOMO II
COQUALMO
iDAVE
COPLIMO
CORADMO
COPROMO
COCOTS
COSYSMO
COSOSIMO
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
15
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Typical Model Usage
Usehellip When scope of work to be performed ishellip COCOMO II Development of software components (software development)
COCOTS Assessment tailoring and integration of COTS products
COSYSMO Design specification and integration (system engineering) of system components to be separately developed for a single system
COSOSIMO Specification procurement and integration of two or more separately system-engineered and developed systems
COCOMO II with COCOTS Development of software components (software development) and a software system including assessment tailoring and glue-code for integration of COTS
COSYSMO and COCOMO II System engineering and software development for a single system with software-intensive components
COSYSMO and COSOSIMO System engineering of individual systems and integration of the multiple systems
COCOMO II COSYSMO COCOTS and COSOSIMO
System engineering software development and integration of multiple software-intensive systems and COTS products
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
16
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
High Level Partitioning of Cost Models
RequirementsAnalysis
PreliminaryDesign
DetailedDesign
Coding
Unit Test
Integration
Software Acceptance Test
Legend COCOMO COSYSMO COSOSIMO
SOS
SystemSystem
IntegrationTest
System of System
SoftwareArchitecting
Architecting
COSOSIMO
COSYSMO
COCOMO II
IntegrationTest
COCOTS
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
17
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Emerging Extensions
bull COCOMO-Dependent Extensionsndash COQUALMO software qualityndash iDAVE software dependabilityndash COPLIMO product line investmentndash CORADMO rapid application software development ndash COPROMO productivity improvement
bull Emerging Independent Extensionsndash COCOTS software commercial off the shelfndash COSYSMO systems engineeringndash COSOSIMO systems of systemsndash Dynamic COCOMO dynamic vs static modeling
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Quality Model COQUALMO
bull Predicts the number of residual defects in a software product bull Enables what-if analyses that demonstrate the impact of
ndash various defect removal techniquesndash effects of personnel project product and platform characteristics on software quality
bull Provides insights into ndash Probable ship timendash Assessment of payoffs for quality investments
ndash Understanding of interactions amongst quality strategies
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOMO II
COQUALMO
DefectIntroduction
Model
DefectRemoval
Model
Software platform Project product and personnel attributes
Software Size Estimate
Defect removal profile levelsAutomation Reviews Testing
Software development effort cost and schedule estimate
Number of residual defectsDefect density per unit of size
COQUALMO Operational Concept
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
21
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Rating Scales
Highly advanced
tools model-based test
More advance test tools
preparation
Dist-monitoring
Well-defined test seq and
basic test coverage tool
system
Basic test
Test criteria based on checklist
Ad-hoc test and debug
No testingExecution Testing and
Tools
Extensive review
checklist
Statistical control
Root cause analysis
formal follow
Using historical data
Formal review roles and Well-trained people
and basic checklist
Well-defined preparation
review minimal
follow-up
Ad-hoc informal walk-
through
No peer reviewPeer Reviews
Formalized specification verification
Advanced dist-
processing
More elaborate reqdesign
Basic dist-processing
Intermediate-level module
Simple reqdesign
Compiler extension
Basic req and design
consistency
Basic compiler capabilities
Simple compiler syntax
checking
Automated Analysis
Extra HighVery HighHighNominalLowVery Low
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
22
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COQUALMO Defect Removal Estimates- Nominal Defect Introduction Rates
60
285
14375
35 160
10
20
30
40
50
60
70
VL Low Nom High VH XH
Delivered Defects KSLOC
Composite Defect Removal Rating
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Information Dependability Attribute Value Estimator iDAVE
bull iDAVE estimates and tracks software dependability Return on Investment (ROI)ndash Help determine how much dependability is enough
ndash Help analyze and select the most cost-effective combination of software dependability techniques
ndash Use estimates as a basis for tracking performance
bull Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs)
bull Used to reason about the ROI of software dependability investments bull Dependability defined as a composite property that integrates such
attributes as availability reliability safety security survivability and maintainability
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
24
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Time-phased information processing capabilities
Project attributes
Time-phased dependability investments
IP Capabilities (size) project attributes
Cost estimating relationships (CERrsquos)
Dependability investments project attributes
Dependability attribute estimating relationships (DERrsquos)
Cost = f
Di = gi
Value estimating relationships (VERrsquos)
Vj = hj IP Capabilities dependability levels Di
Time-phased Cost Dependability
attribute levels Di Value components
Vj
Return on Investment
iDAVE Operational Concept
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
25
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Product Line Investment Model COPLIMO
bull Supports software product line cost estimation and ROI analysis within the scope of product line life cycle
bull Consists of two componentsndash Product line development cost model
ndash Annualized post-development life cycle extension
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18
diverse organizations
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Operational Concept
COPLIMO
For set of products
bull Average product size (COCOMO II cost drivers)
bull Percent mission-unique reused-with-modifications black-box reuse
bull Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors
As functions of products years in life cyclebull Non-product line
effortbull Product line
investment (effort)bull Product line savings
(ROI)
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
27
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Rapid Application Development Model CORADMO
bull Calculatespredicts for smaller rapid application development projectsndash Schedule
ndash Personnel
ndash Adjusted effort
bull Allocates effort and schedule to the stages which are anchored at points in a development life cycle
bull Scope includes inception elaboration and construction
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
28
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
CORADMO Factors
bull Reuse and Very High Level Languages
bull Development Process Reengineering and Streamlining
bull Collaboration Efficiency
bull ArchitectureRisk Resolution
bull Prepositioning Assets
bull RAD Capability and Experience
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
29
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive Productivity Model COPROMO
bull Determines impact of technology investments on model parameter settings
bull Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity
bull Uses COCOMO II COPSEMO and CORADMO models as assessment frameworkndash Well-calibrated to 161 projects for effort schedule
ndash Subset of 106 1990rsquos projects for current-practice baseline
ndash Extensions for Rapid Application Development formulated
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive COTS Model COCOTSbull Estimates the effort associated with the integration of
Commercial-Off-The-Shelf (COTS) software productsbull Scope includes inception elaboration and constructionbull Model has four components
ndash Assessmentndash Tailoringndash ldquoGluerdquo codendash System volatility
bull Effort reported by COCOTS is the sum of the efforts from each of the four components
bull Can be used in conjunction with COCOMO II to estimate new software development with COTS integration
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
31
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COCOTS Operational Conceptbull COTS Classes
bull CandidatesClass
bull Tailoring Complexity
bull Glue code size amp cost drivers
bull COCOMO II application effort (separate from COTS)
bull COTS volatility rework ()
bull Rework due to COTS requirements changes ()
bull Rework due to non-COTS requirements changes ()
Effort
Assessment
COCOTS
Tailoring
VolatilityldquoGluerdquo Code
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
32
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
ST
AF
FIN
G
TIME
COCOMO vs COCOTS Cost Sources
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
33
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
bull Covers full system engineering lifecycle (maps to ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
Constructive System Engineering Cost Model COSYSMO
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
34
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 Volatility Factors
- Application factors-8 factors
- Team factors-6 factors
- Schedule driver
WBS guided by EIAANSI 632
COSYSMO Operational Concept
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
35
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Effort Multipliers
bull Application Factorsndash Requirements understanding
ndash Architecture complexity
ndash Level of service requirements
ndash Migration complexity
ndash Technology Maturity
ndash Documentation Match to Life Cycle Needs
ndash and Diversity of InstallationsPlatforms
ndash of Recursive Levels in the Design
bull Team Factorsndash Stakeholder team
cohesion
ndash Personnelteam capability
ndash Personnel experiencecontinuity
ndash Process maturity
ndash Multisite coordination
ndash Tool support
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
36
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Cost Model COSOSIMO
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
ndash SoS abstractionndash Architectingndash Source selectionndash Systems acquisitionndash Integration and testndash Change management effort
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
37
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical
interfaces at SoS levelbull Number of operational
scenariosbull Number of components
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO
COSOSIMO Operational Concept
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
38
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model detailsbull References and further information
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
39
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Model Unification Main Issues
For each individual model as well as the unified model1 Objectives amp Strategies
2 Inputsscope of work
3 Outputscope of estimate
4 Assumptions of each model
5 Stakeholders for each model
6 Counting Rules
7 Sponsorship (FCS Model-Based Acq)
8 PhD dissertation critical mass
9 Data sources
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
40
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Unification Goalsbull Allow more
comprehensive cost exploration with respect tondash Development decisionsndash Investment decisionsndash Established project budget and
schedulesndash Client negotiations and
requested changesndash Cost schedule performance
and functionality tradeoffsndash Risk management decisionsndash Process improvement
decisions
bull Affiliate request Provide a single unified tool to allow users to ndash Specify
bull System and software components comprising the software system of interest
bull Composition and characteristics of components
ndash Receive bull A set of comprehensive outputs for
system engineering software development and system-of-systems integration
bull Adjusted using the appropriate special-purpose extensions
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
41
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 1 Objectives amp Strategies
bull First pass and future enhancementsbull Framework (Goal-Quality-Metric model approach)bull Restate objectives for existing models
ndash COCOMO IIndash COCOTSndash COSYSMOndash COSOSIMOndash CORADMOndash COQUALMO
bull Develop objectives for unified cost modelbull Operational scenario(s) for each model
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
42
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 2 Inputsscope of workbull Need to define on several levels
ndash To determine scope of work to be estimatedndash To determine system of interestviewpoint and system
component characteristicsndash To determine specific sub-model inputs
bull Life cycle modelbull Single user interfacebull A single definition for each parameterdriver (eg TEAM PMAT etc)
vs context-specific definitions for parameters with common names across models
bull Need to determine which ldquocomponentsrdquo can be estimated as relatively independent pieces vs tightly coupled components
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
43
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 3 Outputscope of estimatebull Single value for all integrated models (default 152 hours per person-
month)ndash Normalized PM for calibration
bull Backward compatibility to existing modelsbull What set of ldquobinsrdquo should be used for initial effort outputsbull What additional levels of granularity should be provided
ndash By phasestagendash By labor categoryndash By activitiesndash Break out by sub-modelsndash Increments (ie COINCOMO)
bull How will an Integrated Master Schedule be developedbull Effort amp schedule as a function of riskbull Projected productivity
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
44
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 4 Assumptions of each model
Model Life Cycle Stages
COCOMO II
COCOTS
COSYSMO
COSOSIMO
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
45
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 5 Users for each model
Acquirers SW developers estimators systems engineers managers executives or accountants who are interested inndash Software development (COCOMO II)
ndash Commercial off the shelf software (COCOTS)
ndash Systems engineering (COSYSMO)
ndash Software quality (COQUALMO)
ndash Software rapid application development (COPSEMO CORADMO)
ndash Software system of systems integration (COSOSIMO)
ndash ROIInvestment analysis (iDave COPLIMO)
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
46
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Issue 6 Counting Rules amp Definitions
bull Inputsndash Size drivers (VHLLs FPs APs Use Case Points KSLOC
REQS ALG IF SCEN Components etc)ndash Model inputs (cost drivers scale factors)
bull Outputsndash Effort distributions
bull Phase activity or labor categories
ndash Schedulendash Defectsndash $ costndash Riskndash Productivity
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
47
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Additional Analysis in Progress
bull Cost Drivers
bull Scale Factors
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
48
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Long Term Vision
UnifiedInterface
COSOSIMO
COSYSMO
COCOMOIICOQUALMO
COCOTS
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
COCOMOII extensionsbullRAD securitybullIncremental phaseactivitybullAgile risk Monte CarlobullROI (product line dependability)bullMaintenance
Output Analysis and Report Generation
Unified Model
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
49
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
50
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Software Integration Lifecycle
1) Qualify COTS product
2) Perform system requirements
3) Administer COTS software acquisition
4) Prototype the system including COTS software
5) Fully integrate COTS software and interface code
6) Test completed prototype
COTS Software Integration Lifecycle
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
51
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Integration Sources of Effort
bull COTS Assessment (pre- and post- commitment)
ndash Of functionality performance interoperability etc
bull COTS Tailoring and Tuning
ndash Effects of platform other COTS products
bull Glue Code Development
ndash Similar to other Cost Xpert estimation
bull Application Volatility Due to COTS
ndash COTS volatility shortfalls learning curve
bull Added Application VampV Effort
ndash COTS option and stress testing
ndash Debugging complications incorrect fixes
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
52
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Traditional vs COTS Cost Sources
Time
Sta
ffin
g 1) COTS Assessment
3) COTSApplication GlueCode Development
and Test2) COTS Tailoring
4) Increased Application Effort due to COTS Volatility
bullLCO ReqtsReview
Application Code Development
bull LCADesign Review
bull IOCBeta Test
COCOMO II COTS model
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
53
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Current Scope of COTS Model
bull COTS model coversndash assessmentndash tailoringndash glue code development and integrationndash impact of new releases (volatility)
bull It does not coverndash cost of re-engineering business processesndash vendor managementndash licensesndash training (for COTS integrators or end users)ndash COTS platform or tool experience or maturity
bull Covered by PLEX LTEX PVOL TOOL environmental factors
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
54
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Assessment Effort Inputs
bull Initial Filtering of COTS productsndash estimate of the total number of candidate COTS
components to be filtered
bull More detailed assessment of specific candidates against attributes that are importantndash class(es) of COTS components to be assessed
ndash for each classbull number assessed
bull attributes considered
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
55
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COTS Candidates in classfiltered
Initial Filtering Effort (IFE) =
Average Filtering Effort for product class
)( )(
Assessment Submodel
Over
all classes
COTS Candidates in classdetailed assessed
Detailed Assessment Effort (DAE) =
Average Assessment Effort for
product class
)( )(Over
all classesby project
domain
Final Project Assessment Effort (FPAE) = IFE + DAE
Qualified by assessment attributes most associated with that class
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
56
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Correctness Understandability PortabilityAccuracy Documentation quality Portability
Correctness SimplicityTestability Functionality
AvailabilityRobustness FunctionalityAvailability Ease of use
Fail safe UsabilityHuman Factors PriceFail soft Initial purchaselease
Fault tolerance Version Compatibility Recurring costsInput error tolerance Downward compatibility
Redundancy Upward compatibility MaturityReliability Product Maturity
Robustness Inter-component Compatibility Vendor MaturitySafety Compatibility with other components
Interoperability Vendor SupportSecurity Response time for critical problems
Security (Access related) Flexibility SupportSecurity (sabotage related) Extendability Warranty
FlexibilityProduct Performance User Training
Execution performance InstallationUpgrade Ease User trainingInformationdata capacity Installation Ease
Precision UpgradeRefresh ease Vendor ConcessionsMemory performance Willingness to escrow source code
Response time Willingness to make modificationsThroughput
Assessment Attributes
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
57
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Effort Inputs
bull COTS tailoring - activities required to prepare or initialize a component for use in a specific system
bull Tailoring includesndash parameter specificationndash script writingndash GUI screen specificationndash Report specificationndash SecurityAccess Protocol initialization and set up
bull For each class of COTS componentndash rate the complexity of tailoring for each of the above
activities
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
58
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Tailoring Submodel
where
COTS Tailored in class
Project Tailoring Effort (PTE) =
Average Tailoring Effort for product class
)[( )(
Over all classesby project
domain
bull TCQr class ]
TCQrclass = Tailoring Complexity Qualifier calibrated within a class for each of five possible ratings from Very Low to Very High
and with the TCQNOMINAL = 10
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
59
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Individual Activity amp Aid Complexity Ratings
TailoringActivities amp Aids
Very Low(point value = 1)
Low(point value = 2)
Nominal(point value = 3)
High(point value = 4)
Very High(point value = 5)
Corre-sponding
Points
ParameterSpecification
Zero to 50 parms tobe initialized
51 to 100 parms tobe initialized
101 to 500 parmsto be initialized
501 to 1000 parmsto be initialized
1001 or moreparms to beinitialized
-------Script Writing Menu driven
1 to 5 line scripts 1 to 5 scripts
needed
Menu driven 6 to 10 line scripts
6 to 15 scriptsneeded
Hand written 11 to 25 line
scripts 16 to 30 scripts
needed
Hand written 26 to 50 line
scripts 31 to 50 scripts
needed
Hand written 51 or more line
scripts 51 or more scripts
needed-------
IO Report amp GUIScreen Specification amp
Layout
Automated orstandard templates
used 1 to 5
reportsscreensneeded
Automated orstandard templates
used 6 to 15
reportsscreensneeded
Automated orstandard templates
used 16 to 25
reportsscreensneeded
Hand written orcustom designed
26 to 50reportsscreens
needed
Hand written orcustom designed
51 or morereportsscreens
needed -------
SecurityAccessProtocol Initialization
amp Set-up
1 security level1 to 20 user
profiles1 input screenuser
2 security levels21 to 50 user
profiles2 input
screensuser
3 security levels51 to 75 user
profiles3 input
screensuser
4 security levels76 to 100 user
profiles4 input
screensuser
5 or more securitylevels
101 or more userprofiles
5 or more inputscreensuser
-------
Availability of COTSTailoring Tools
No tools available NA NA NA Tools are available
-------
Total Point Score =
Tailoring Complexity Table
y Low Low Nominal High Very Hight Total lt 10 11 lt Point Total lt 15 16 lt Point Total lt 20 21lt Point Total lt 25 26 lt Point Total lt 30
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
60
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs
bull Definition of glue codendash code needed to facilitate data or information exchange
between the COTS component and the system into which it is being integrated
ndash code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component
bull Estimate of the total delivered lines of glue codebull Estimate of glue code rework due to COTS
volatility or requirements volatility
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
61
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)bull Integration Personnel
ndash Integrator experience with product (VL - VH)
ndash Integrator personnel capability (VL - VH)
ndash Integrator experience with COTS integration process (L - VH)
ndash Integrator personnel continuity (VL - VH)
bull COTS Componentndash COTS product maturity (VL - VH)
ndash COTS supplier product extension willingness (L - VH)
ndash COTS product interface complexity (L - VH)
ndash COTS supplier product support (L - VH)
ndash COTS supplier provided training and documentation (VL - VH)
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
62
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Glue Code Inputs (continued)
bull ApplicationSystemndash Constraints on systemsubsystem reliability (L -
VH)ndash Constraints on systemsubsystem technical
performance (N-VH)ndash System portability (N - VH)ndash Application architectural engineering (VL -
VH)
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
63
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
[(size)(1+breakage)]Total Effort = AB
(effort multipliers)
Glue Code Submodel
bull A - a linear scaling constantbull Size - of the glue code in SLOC or FPbull Breakage - of the glue code due to change in requirements andor COTS volatilitybull Effort Multipliers - 13 parameters each with settings ranging VL to VHbull B - an architectural scale factor with settings VL to VH
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
64
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Personnel Drivers
1) ACIEP - COTS Integrator Experience with Product2) ACIPC - COTS Integrator Personnel Capability3) AXCIP - Integrator Experience with COTS Integration Processes4) APCON - Integrator Personnel Continuity
COTS Component Drivers
5) ACPMT - COTS Product Maturity6) ACSEW - COTS Supplier Product Extension Willingness7) APCPX - COTS Product Interface Complexity8) ACPPS - COTS Supplier Product Support9) ACPTD - COTS Supplier Provided Training and Documentation
ApplicationSystem Drivers
10) ACREL - Constraints on Application SystemSubsystem Reliability11) AACPX - Application Interface Complexity12) ACPER - Constraints on COTS Technical Performance13) ASPRT - Application System Portability
Nonlinear Scale Factor
1) AAREN - Application Architectural Engineering
Glue Code Cost Drivers
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
65
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Volatility Inputs
bull Captures impact of new COTS releases on the customnew application effort
bull Inputsndash Estimate of new development effort (derived
via Cost Xpert - traditional)ndash Percentage of new development rework due to
bull requirements changesbull COTS volatility
bull Note This submodel is being revised
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
66
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Approximate Model
Detailed Model with Cost Xpert Parameters
BRAK COTS application code breakage due to COTS volatilityBRAK application code breakage otherwise Cost Xpert scale factor EAF Effort Adjustment Factor (product of effort multipliers)
[ ]BRAK COTS100
Total Effort = (Application Effort) bull (EAF)COTS
[ ]Total Effort = (Application Effort) ( )BRAK COTS1+BRAK
1+101+
-1 bull (EAF)COTS
Volatility Submodel
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
67
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
xTotal Integration Effort (in Person-Months) = Assessment Effort + Tailoring Effort + Glue Code Effort + Volatility Effort
where Assessment Effort = Filtering Effort + Final Selection Effort
Total integration Cost = (Total Integration Effort) bull ($$Person-Month)
Total COTS Integration Cost Estimate
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
68
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
69
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Background
bull Benefits vs Costs of product linebull Does product line pay off bull Traditional product line cost estimation models mostly
underestimate the ROI for product lines by focusing only on development savingsndash Apply RCWR surcharge to entire product not only to the reused
portionsndash If life cycle costs are considered high payoff comes from a
smaller code base to undergo maintenancebull COPLIMO life cycle model
ndash Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains
ndash Based on COCOMO II parameters calibrated to 161 projects empirical data on nonlinear reuse effects
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
70
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Model Overview
bull Based on COCOMO II software cost modelndash Statistically calibrated to 161 projects representing 18 diverse
organizations bull Based on standard software reuse economic terms
ndash RCWR Relative Cost of Writing for Reuse
ndash RCR Relative Cost of Reuse
bull Avoids investment overestimation savings underestimationndash Avoids RCWR for non-reused components
ndash Includes savings from smaller life-cycle code base
bull Provides experience-based default parameter valuesbull Simple Excel spreadsheet model
ndash Easy to modify extend interoperate
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
71
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO - RCWR bull Development for Reuse (RUSE)
ndash In COCOMO II database 11 out of 161 projects rated as VH for RUSE and 1 rated as XH
ndash Productivity Range of RUSEbull Highest rating Lowest rating = 124095 = 131
bull And two other contributing variablesndash Required Reliability (RELY) ndash Degree of Documentation (DOCU)
Rating Levels Very Low Low Nominal High Very High Extra High
RUSE Descriptors
None Across project
Across program
Across product line
Across multiple product lines
Effort Multipliers
na 095 1 107 115 124
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
72
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCWR (Cont)bull Required Reliability (RELY)
Constraints At least Nominal for Nominal and High RUSE ratings at least High for Very High and Extra High RUSE ratings
bull Degree of Documentation (DOCU)
Constraint No more than one level below the RUSE rating
Rating Levels
Very Low Low Nominal High Very High Extra High
RELY Descriptors
slight inconven-
ience
low easily recoverable
losses
moderate easily
recoverable losses
high financial loss
risk to human life
Effort Multipliers
082 092 1 11 126 na
Rating Levels
Very Low Low Nominal High Very High Extra High
DOCU Descriptors
Many life cycle needs uncovered
Some life cycle needs uncovered
Right-sized to life cycle needs
Excessive for life cycle
needs
Very excessive
for life cycle needsEffort
Multipliers081 091 1 111 123 na
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
73
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCRbull Reused or Black Box (unmodified code) RCR
model ndash Assessment and Assimilation (AA) factor
bull Adapted or White Box (modified code) RCR model ndash AA ndash Non-Linear Model
100
AAM Worst Case
AA = 0
Relative Modification of Size (AAF)
AAM Best Case
SU = 10 UNFM = 0
AAF = 05
Selby data
Relative Cost
10
15
0050
05
0045
AA = 8 SU = 50 UNFM = 1
AAF = 05
Selby data summary
Figure 1 Nonlinear Reuse Effects
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
74
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (1)
bull Simplifying assumptions about uniformity and
stability ndash Every product roughly the same size (PSIZE)
ndash Roughly the same fractions of product-specific (PFRAC)
adapted (AFRAC) and reused (RFRAC) software bull Inputs and outputs
For current set of similar products
As functions of products
Basic
COPLIMO
Average product size productivity
Percent product-specific adapted reused
RCR RCWR factors
Non-product line effort
Product line investment effort
Product line savings ROI
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
75
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (2)
bull RCWR ndash RCWR = RUSE DOCU RELY
bull 1 product development effort ndash Non-PL Effort for developing N
similar products bull PMNR (N) = N A (PSIZE)B Π (EM)
bull Where PSIZE is the general software product size A and B are the COCOMO II calibration coefficient and scale factor and Π (EM) is the product of the effort multipliers for the COCOMO II cost drivers
ndash PL Effort (the first product) bull PMR (1) = PMNR (1) [PFRAC +
RCWR(AFRAC+RFRAC)]
bull Note RCWR not applied to non-reused portion where many other models overestimate RCWR
Product-specific software(PFRAC)
04
Black-box plug-and-playreuse (RFRAC)
03
Reuse with modifications(AFRAC)
03
Assessment andassimilation factor (AA)
2
Software understandingincrement (SU)
10
Unfamiliarity factor(UNFM)
05
design modified (DM) 15
code modified (CM) 30
integration redone(IM)
40
bull RCR parameters
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
76
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO Output Summary
Summary of Inputs 7 year Product Line Effort Savings
AVPROD 300
AVSIZE 50000 (SLOC)
PFRAC 40 ()
AFRAC 30 ()
RFRAC 30 ()
RCR-PFRAC 100 ()
RCR-AFRAC 40 ()
RCR-RFRAC 5 ()
RCWR 185
Table of Results
of Products 0 1 2 3 4 5 6 7
Unique SLOC 0 20000 40000 60000 80000 100000 120000 140000
Adapted SLOC 0 15000 30000 45000 60000 75000 90000 105000
Reused SLOC 0 15000 30000 45000 60000 75000 90000 105000
Total Non-PL SLOC 0 50000 100000 150000 200000 250000 300000 350000
Non-PL Effort (PM) 0 166667 333333 500 666667 833333 1000 1166667
1-Product Equiv SLOC 0 75500 26750 26750 26750 26750 26750 26750
1-Product Equiv Effort 0 251667 891667 891667 891667 891667 891667 8916667
Cum Equiv PL SLOC 0 75500 102250 129000 155750 182500 209250 236000
Cum PL Effort 0 251667 340833 430 519167 608333 6975 7866667
PL Effort Savings 0 -85 -75 70 1475 225 3025 380
PL Reuse Investment 0 85
Return on Investment NA -1 -00882 082353 173529 264706 355882 4470588
Product Line Development Cost Estimation
-200-100
0100200300400500
0 1 2 3 4 5 6 7 8
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
77
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model
bull Annual Change Traffic (ACT) ndash Relative fraction of a productrsquos software that is modified per year
ndash Simplifying assumption Constant-ACT
bull Life cycle effort without reuse ndash N complete products undergo maintenance
bull Life cycle effort with reuse ndash PFRAC maintenance for N instances
ndash RFRAC maintenance for 1 instance
ndash AFRAC maintenance for 1 instance and N-1 variants
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
78
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Product Line Sizing InformaitonNote White cell is for input yellow area is output
Product Size (PSIZE) 100 KSLOC (Average size of each of products in the product line)
Product-specific (Portion of the software that is unique tofraction (PFRAC) 40 the particular product in the product line)Adapted-software (Portion of the product line software fraction (AFRAC) 30 that must be modified to work well)Reused-software (Portion of the product line software that canfraction (RFRAC) 30 be reused as a black box without modification)
of products in product line
DM 15 ( Design Modified)
CM 30 ( Code Modified)
IM 40 ( of Integration Required for the Adapted Software)
AAF = 27 AA 2 ( Assessment and Assimilation)
SU 10 ( Software Understanding)
UNFM 05(Programmer Unfamiliarity with Software)
AAM = 0317Adapted KSLOC 30 KSLOCEquivalent KSLOC of Adapted Portion= 951 KSLOC(PSIZE x AFRAC x (1-(AT100)) x AAM )
Equivalent KSLOC of Reused Portion= 06 KSLOC(PSIZE x RFRAC x AA)
New KSLOC 40 KSLOC(PSIZE x PFRAC)
SIZE = 4951 KSLOC((1+ (REVL100)) x (NEW KSLOC + Equivalent KSLOC of Adaption + Equivalent KSLOC of Reuse))ACT = 20 (Annual Change Traffic)
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
79
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Estimation SummaryPart I Product Line Development Cost Estimation Summary
of Products 0 1 2 3 4 5
Effort (PM)
No Reuse 0 294 588 882 1176 1470
Product Line 0 444 589 735 881 1026
Product Line Savings 0 -150 -1 147 295 444
ROI 0 -100 -001 098 197 296
Part II Product Line Annualized Life Cycle Cost Estimation Summary
of Products 0 1 2 3 4 5
AMSIZE-P 0 81 162 242 323 404
AMSIZE-R 0 61 61 61 61 61
AMSIZE-A 0 61 77 93 110 126
Total Equiv KSLOC 0 202 299 396 493 591
Effort (AM) (294) 0 594 880 1165 1451 1737
5-year Life Cycle PM 0 2969 4398 5826 7254 8683
PM(N 5)-R (+444) 0 7409 8837 10265 11694 13122
PM(N 5)-NR 0 5909 11819 17728 23638 29547
Product Line Savings (PM) 0 -1499 2982 7463 11944 16425
ROI 0 -100 199 498 797 1096
Devel ROI 0 -100 -001 098 197 296
3-year Life Cycle 0 -1420 1200 4800
AMSIZE Annually Maintained Software Size
Product Line Development Cost Estimation
-200
0
200
400
600
0 1 2 3 4 5 6
of products in product line
Net
dev
elo
pm
ent
effo
rt s
avin
gs
Product Line Annualized Life Cycle Cost Estimation
-200
-100
0
100
200
300
400
500
600
700
800
0 1 2 3 4 5 6
of products
Net
Pro
du
ct L
ine
Eff
ort
Sav
ing
s
5-year Life Cycle
3-year Life Cycle
Development
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
80
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Discussionsbull Software product line payoffs are significant
esp across life cyclebull This does not mean any attempt at product line
reuse will generate large savingsbull Challenges
ndash Technicalbull Domain engineering and product line architecting
ndash Management and Culture bull People unwilling to corporatebull ldquoNot invented hererdquo attitudesbull Success factor empowered product line manager
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
81
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Conclusionsbull Software product line payoffs are significant esp across life
cyclebull COPLIMO avoids investment overestimation amp savings
underestimationbull COPLIMO helps to determine whether and when it pays to
launch a product linebull COPLIMO enables assessment of situation-dependencies
hence lead to better product line decisionsbull Future work
bull Support for more sensitivity analysisbull Model refinement and calibrationbull Integration with other COCOMO II family models such as
COCOTS
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
82
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO Backup Charts
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
83
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COPLIMO ndash RCR
bull Reused or Black Box (unmodified code) RCR model ndash Assessment and
Assimilation (AA) factor bull Adapted or White Box
(modified code) RCR model ndash AA
ndash Non-Linear Model
AA Increment Level of AA Effort
0 None2 Basic module search and
documentation4 Some module Test and Evaluation
(TampE) documentation6 Considerable module TampE
documentation8 Extensive module TampE documentation
50AAFfor 100
UNFM)](SUAAF[AA
50AAFfor 100
UNFM))]SU002(AAF(1[AA
AAM
IM03CM03DM04AAF
AAM KSLOC AdaptedKSLOC Equivalent
ReuseParameter
Description
DM of Design Modified
CM of Code Modified
IM of Integration Required
SU of Software Understanding
UNFM Programmer Unfamiliarity with Software
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
84
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Guidelines for Quantifying
Adapted Software
DM CM IM AA SU UNFM
New All original software
0 - 100+IM usually
moderate and can be gt 100
0 ndash 8
0 - 50
0 - 1
Not applicable00
Reused
0 - 100 rarely 0 but could be
very small
Unchanged existing software
0 ndash 8
Reuse Parameters
Adapted
0 - 100 normally
gt 0
0+ - 100 usually
gtDM and must begt 0
Not applicable
Changes to pre-existing software
DescriptionCode Category
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
85
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Development Cost Model (3)
bull Determining RCR ndash Equiv size of product- specific portion
ndash Equiv size of reused portionndash Equiv size of adapted portion
ndash Total EKSLOC
ndash Effortndash ROI = (PL Effort Savings for K products - PL Reuse Investment) PL Reuse
Investment
KSLOC
KSLOC
40
100 04 EKSLOC P
KSLOCKSLOC 6010
210003 EKSLOC R
KSLOCKSLOC 110100)]11()27(2[30
100
)5010020(1()403030301540(2
KSLOC 100 03 EKSLOCA
KSLOC
KSLOC
EKSLOCEKSLOCEKSLOC ARP
750
)1106040(
EKSLOC
PMR (N) = N A (EKSIZE)B Π (EM)
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
86
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Basic COPLIMO ndash Annualized Life Cycle Cost Model (1)
bull Annual Change Traffic (ACT)ndash Relative fraction of a productrsquos software that is modified per year
bull Life cycle effort without reusendash Annual maintained software
ndash L times maintenance effort
bull Life cycle effort with reusendash Three categories of annual maintenance and AMSIZE
)100
1( UNFMSU
ACTPSIZEAMSIZE
)]()([)()( EMAMSIZEANLNPMLNPM BNRNR
)]1(1[)100
1(
)100
1(
)100
1(
NAAFUNFMSU
ACTAFRACPSIZEAMSIZE
UNFMSU
ACTRFRACPSIZEAMSIZE
UNFMSU
ACTPFRACPSIZEAMSIZE
A
R
P
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
87
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
88
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO Introductionbull Covers full system engineering lifecycle (maps to
ISOIEC 15288)
Life cycle stages being used in COSYSMO Project
bull Estimates standard Systems Engineering WBS tasks (based on EIAANSI 632)
bull Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation
Conceptualize DevelopOper Test amp Eval
Transition to Operation
Operate Maintain or Enhance
Replace orDismantle
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
89
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How is Systems Engineering Defined
EIAANSI 632
Processes for Engineering a Systembull Acquisition and Supply
ndash Supply Processndash Acquisition Process
bull Technical Managementndash Planning Processndash Assessment Processndash Control Process
bull System Designndash Requirements Definition Processndash Solution Definition Process
bull Product Realizationndash Implementation Processndash Transition to Use Process
bull Technical Evaluation
ndash Systems Analysis Process
ndash Requirements Validation Process
ndash System Verification Process
ndash End Products Validation Process
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
90
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSYSMO
SizeDrivers
EffortMultipliers
Effort
Calibration
Requirements Interfaces Scenarios Algorithms
+3 adjustment factors
- Application factors-8 factors
- Team factors-6 factors
COSYSMO Operational Concept
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
91
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Where PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = REQ IF ALG SCNwx = weight for ldquoeasyrdquo ldquonominalrdquo or ldquodifficultrdquo size driver
= quantity of ldquokrdquo size driverE = represents diseconomy of scale (currently equals 1)EM = effort multiplier for the jth cost driver The geometric product results in an
overall effort adjustment factor to the nominal effort
x
Model Form
14
1 )(
jj
E
kkdkdknknkekeNS EMwwwAPM
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
92
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (Effort Multipliers)
1 Requirements understanding
2 Architecture understanding
3 Level of service requirements
4 Migration complexity
5 Technology Maturity
6 Documentation Match to Life Cycle Needs
7 and Diversity of InstallationsPlatforms
8 of Recursive Levels in the Design
Application Factors (8)
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
93
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
14 Cost Drivers (continued)
1 Stakeholder team cohesion
2 Personnelteam capability
3 Personnel experiencecontinuity
4 Process maturity
5 Multisite coordination
6 Tool support
Team Factors (6)
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
94
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
95
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
How Much Effort to Integrate a System of Systems
bull Systems developed by system contractorsndash Total effort 3000 person-years
bull System of systems integration functionsndash SoS abstraction architecting source selection systems acquisition integration
test change management effort
bull How much to budget for integration
bull What factors make budget higher or lower
bull How to develop and validate an estimation model
System of Systems person-years (PY)
Sensing500 PY
Vehicles500 PY
Common400 PY
Infrastructure600 PY
Command amp Control1000 PY
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
96
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Constructive System-of-System Integration Cost Model (COSOSIMO)
bull Parametric model to estimate the effort associated with the definition and integration of software-intensive ldquosystem of systemsrdquo components
bull Includes at least one size driver and 6 exponential scale factors related to effort
bull Targets input parameters that can be determined in early phases
bull Goal is to have zero overlap with COCOMO II and COSYSMO
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
97
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Size Drivers
Exponential Scale Factors
SoSDefinition andIntegrationEffort
Calibration
bull Interface-related eKSLOCbull Number of logical interfaces at
SoS levelbull Number of componentsbull Number of operational scenarios
bull Integration simplicitybull Integration risk resolutionbull Integration stabilitybull Component readinessbull Integration capabilitybull Integration processes
COSOSIMO Operational Concept
COSOSIMO
Each size driver weighted by bull Complexitybull Volatilitybull Degree of COTSreuse
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
98
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model Equations
Level 1 IPM (Si) = Ai Size (Sij) Bi
j=1
ni
Level 0 IPM (SoS) = A0 IPM (Si) B0
i=1
mi
Two level model that bull First determines integration effort for first level subsystemshellipbull Then using subsystem integration effort and SoS characteristics determines SoS integration efforthellip
SOS
SmS2S1
S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn
helliphellip
helliphellip helliphellip helliphellip
Level 0
Level 1
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
99
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
COSOSIMO Model ParametersIPM Integration effort in Person MonthsSi The ith subsystem within the SoS
A Constant derived from historical project data Size Determined by computing the weighted average of the size driver(s) ni Number of Subsystem level 2 components comprising the ith subsystem
m Number of Subsystem level 1 components comprising the SoSBi Effort exponent for the ith subsystem based on the subsystemrsquos 6
exponential scale factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
B0 Effort exponent for the SoS based on the SOSrsquo 6 exponential scale
factors The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
100
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Agendabull COCOMO II refresherbull Modeling methodology and model statusbull Suite overviewbull Emerging extensionsbull Model unificationbull Addendum selected model details
ndash COCOTSndash COPLIMOndash COSYSMOndash COSOSIMO
bull References and further information
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
101
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Referencesbull Abts C Extending The COCOMO II Software Cost Model To Estimate Effort
And Schedule For Software Systems Using Commercial-off-the-shelf (COTS) Software Components The COCOTS Model USC PhD dissertation May 2004
bull 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
bull Chulani Bayesian Analysis of Software Cost and Quality Modelsldquo USC PhD dissertation April 1999
bull Clark B Clark B ldquoEarly COCOTSrdquo September 2004bull Lane J ldquoConstructive Cost Model for System-of-System Integrationrdquo 3rd ACM-
IEEE International Symposium on Empirical Software Engineering Redondo Beach CA August 2004
bull Valerdi R Boehm B Reifer D ldquoCOSYSMO A Constructive Systems Engineering Cost Model Coming Agerdquo Proceedings 13th Annual INCOSE Symposium Crystal City VA July 2003
bull Boehm B Valerdi R Lane J Brown W COCOMO Suite Methodology and Evolution Crosstalk 2005
bull Yang Y Boehm B Madachy R COPLIMO A Product-Line Investment Analysis Model Proceedings of the Eighteenth International Forum on COCOMO and Software Cost Modeling USC Los Angeles CA October 2003
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu
102
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Further Informationbull Main COCOMO website at USC
httpsunsetusceduresearchCOCOMOII
bull COCOMO information at USC (213) 740-6470
bull COCOMO email cocomo-infosunsetuscedu