cocomo suite

102
1 University of Southern California Center for Software Engineering C S E USC COCOMO Suite Barry Boehm CSCI 510 Fall 2011

Upload: duscha

Post on 30-Jan-2016

75 views

Category:

Documents


1 download

DESCRIPTION

COCOMO Suite. Barry Boehm CSCI 510 Fall 2011. Agenda. COCOMO II refresher Modeling methodology and model status Suite overview Emerging extensions Model unification Addendum: selected model details References and further information. Software product size estimate - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: COCOMO  Suite

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

Page 2: COCOMO  Suite

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

Page 3: COCOMO  Suite

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

Page 4: COCOMO  Suite

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

Page 5: COCOMO  Suite

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

Page 6: COCOMO  Suite

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

Page 7: COCOMO  Suite

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

Page 8: COCOMO  Suite

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

Page 9: COCOMO  Suite

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

Page 10: COCOMO  Suite

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

Page 11: COCOMO  Suite

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

Page 12: COCOMO  Suite

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

Page 13: COCOMO  Suite

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

Page 14: COCOMO  Suite

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

Page 15: COCOMO  Suite

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

Page 16: COCOMO  Suite

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

Page 17: COCOMO  Suite

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

Page 18: COCOMO  Suite

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

Page 19: COCOMO  Suite

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

Page 20: COCOMO  Suite

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

Page 21: COCOMO  Suite

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

Page 22: COCOMO  Suite

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

Page 23: COCOMO  Suite

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

Page 24: COCOMO  Suite

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

Page 25: COCOMO  Suite

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

Page 26: COCOMO  Suite

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

Page 27: COCOMO  Suite

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

Page 28: COCOMO  Suite

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

Page 29: COCOMO  Suite

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

Page 30: COCOMO  Suite

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

Page 31: COCOMO  Suite

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

Page 32: COCOMO  Suite

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

Page 33: COCOMO  Suite

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

Page 34: COCOMO  Suite

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

Page 35: COCOMO  Suite

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

Page 36: COCOMO  Suite

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

Page 37: COCOMO  Suite

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

Page 38: COCOMO  Suite

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

Page 39: COCOMO  Suite

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

Page 40: COCOMO  Suite

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

Page 41: COCOMO  Suite

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

Page 42: COCOMO  Suite

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

Page 43: COCOMO  Suite

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

Page 44: COCOMO  Suite

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

Page 45: COCOMO  Suite

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

Page 46: COCOMO  Suite

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

Page 47: COCOMO  Suite

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

Page 48: COCOMO  Suite

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

Page 49: COCOMO  Suite

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

Page 50: COCOMO  Suite

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

Page 51: COCOMO  Suite

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

Page 52: COCOMO  Suite

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

Page 53: COCOMO  Suite

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

Page 54: COCOMO  Suite

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

Page 55: COCOMO  Suite

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

Page 56: COCOMO  Suite

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

Page 57: COCOMO  Suite

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

Page 58: COCOMO  Suite

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

Page 59: COCOMO  Suite

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

Page 60: COCOMO  Suite

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

Page 61: COCOMO  Suite

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

Page 62: COCOMO  Suite

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

Page 63: COCOMO  Suite

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

Page 64: COCOMO  Suite

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

Page 65: COCOMO  Suite

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

Page 66: COCOMO  Suite

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

Page 67: COCOMO  Suite

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

Page 68: COCOMO  Suite

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

Page 69: COCOMO  Suite

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

Page 70: COCOMO  Suite

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

Page 71: COCOMO  Suite

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

Page 72: COCOMO  Suite

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

Page 73: COCOMO  Suite

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

Page 74: COCOMO  Suite

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

Page 75: COCOMO  Suite

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

Page 76: COCOMO  Suite

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

Page 77: COCOMO  Suite

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

Page 78: COCOMO  Suite

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

Page 79: COCOMO  Suite

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

Page 80: COCOMO  Suite

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

Page 81: COCOMO  Suite

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

Page 82: COCOMO  Suite

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

Page 83: COCOMO  Suite

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

Page 84: COCOMO  Suite

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

Page 85: COCOMO  Suite

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

Page 86: COCOMO  Suite

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

Page 87: COCOMO  Suite

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

Page 88: COCOMO  Suite

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

Page 89: COCOMO  Suite

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

Page 90: COCOMO  Suite

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

Page 91: COCOMO  Suite

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

Page 92: COCOMO  Suite

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

Page 93: COCOMO  Suite

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

Page 94: COCOMO  Suite

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

Page 95: COCOMO  Suite

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

Page 96: COCOMO  Suite

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

Page 97: COCOMO  Suite

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

Page 98: COCOMO  Suite

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

Page 99: COCOMO  Suite

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

Page 100: COCOMO  Suite

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

Page 101: COCOMO  Suite

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

Page 102: COCOMO  Suite

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