COCOMO Suite Barry Boehm CSCI 510 Fall 2013.

COCOMO Suite Barry Boehm CSCI 510 Fall 2013

Agenda COCOMO II refresher Modeling methodology and model status
Suite overview Emerging extensions Model unification Addendum: selected model details References and further information

COCOMO II Overview COCOMO Software product size estimate
Software product, process, computer, and personal attributes Software reuse, maintenance, and increment parameters Software organization’s Project data COCOMO Software development and maintenance: Costs (effort) Schedule estimates Distributed by phase, activity, increment COCOMO locally calibrated to organization’s data

Purpose of COCOMO II To help people reason about the cost and schedule implications of their software decisions Software investment decisions When to develop, reuse, or purchase What legacy software to modify or phase out Setting project budgets and schedules Negotiating cost/schedule/performance tradeoffs Making software risk management decisions Making software improvement decisions Reuse, tools, process maturity, outsourcing

COCOMO II Model Stages

COCOMO II Scope of Outputs
Provides the estimated software development effort and schedule for MBASE/RUP Elaboration Construction LCO LCA IOC

USC-CSE Modeling Methodology
Analyze existing literature Step 1 Concurrency and feedback implied… Perform Behavioral analyses Step 2 Identify relative significance Step 3 Perform expert-judgment Delphi assessment, formulate a-priori model Step 4 Gather project data Step 5 Determine Bayesian A-Posteriori model Step 6 Gather more data; refine model Step 7

Significant Variables
Status of Models Model Literature Behavior Significant Variables Delphi Data, Bayesian Tool COCOMO II * >200 Product COQUALMO 6 Excel iDAVE COPLIMO CORADMO 10 COPROMO COCOTS 20 COSYSMO 42 COSOSIMO n/a

PM = A * ( Size)B * (EM)
General COCOMO Form PM = A * ( Size)B * (EM) ADDITIVE EXPONENTIAL MULTIPLICATIVE Where: PM = 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

COCOMO Suite: Quantities Estimated
Model Effort Effort by Phase Schedule Defects ROI Improvement Graphs COCOMO II X COQUALMO iDAVE COPLIMO CORADMO COPROMO COCOTS COSYSMO COSOSIMO

COCOMO Suite: Sizing Requirements Components Algorithms Complexity
Model SLOC FP + Lang Requirements Interfaces Scenarios Algorithms Components Complexity Reuse Volatility COCOMO II Module X CORADMO COQUALMO COSYSMO COSOSIMO Glue COCOTS

COCOMO Suite: Phase/Activity Distribution
Model Inception Elaboration Construction Transition COCOMO II COQUALMO iDAVE COPLIMO CORADMO COPROMO COCOTS COSYSMO COSOSIMO

Typical Model Usage

High Level Partitioning of Cost Models
COSOSIMO SOS System of System Architecting COSYSMO Integration/Test System System Integration/Test Architecting Software Requirements Analysis Software Acceptance Test COCOMO II Preliminary Design Integration This diagram shows the relationships between COSOSIMO, COSYSMO, and COCOMO II. Efforts are currently underway to more precisely define the activities within each stage of development that are covered by each cost model. Detailed Design Unit Test Legend COCOMO COSYSMO COSOSIMO Coding COCOTS

Emerging Extensions COCOMO-Dependent Extensions
COQUALMO: software quality iDAVE: software dependability COPLIMO: product line investment CORADMO: rapid application software development COPROMO: productivity improvement Emerging Independent Extensions COCOTS: software commercial off the shelf COSYSMO: systems engineering COSOSIMO: systems of systems Dynamic COCOMO: dynamic vs. static modeling

Constructive Quality Model: COQUALMO
Predicts the number of residual defects in a software product Enables 'what-if' analyses that demonstrate the impact of various defect removal techniques effects of personnel, project, product and platform characteristics on software quality. Provides insights into Probable ship time Assessment of payoffs for quality investments Understanding of interactions amongst quality strategies

COQUALMO Operational Concept
COCOMO II Software development effort, cost and schedule estimate COQUALMO Software Size Estimate Defect Introduction Model Software platform, Project, product and personnel attributes Number of residual defects Defect density per unit of size Defect Removal Model Defect removal profile levels Automation, Reviews, Testing

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 testing Execution 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 review Peer Reviews Formalized specification, verification. Advanced dist-processing More elaborate req./design Basic dist-processing Intermediate-level module Simple req./design Compiler extension Basic req. and design consistency Basic compiler capabilities Simple compiler syntax checking Automated Analysis Extra High Very High High Nominal Low Very Low

COQUALMO Defect Removal Estimates
- Nominal Defect Introduction Rates Delivered Defects / KSLOC Composite Defect Removal Rating

Information Dependability Attribute Value Estimator: iDAVE
iDAVE estimates and tracks software dependability Return on Investment (ROI) Help determine how much dependability is enough Help analyze and select the most cost-effective combination of software dependability techniques Use estimates as a basis for tracking performance Based on COCOMO II and COQUALMO cost models and Value Estimating Relationships (VERs) Used to reason about the ROI of software dependability investments Dependability defined as a composite property that integrates such attributes as availability, reliability, safety, security, survivability and maintainability

iDAVE Operational Concept

Constructive Product Line Investment Model: COPLIMO
Supports software product line cost estimation and ROI analysis within the scope of product line life cycle Consists of two components Product line development cost model Annualized post-development life cycle extension Based on COCOMO II software cost model Statistically calibrated to 161 projects, representing 18 diverse organizations

COPLIMO Operational Concept
For set of products: Average product size (COCOMO II cost drivers) Percent mission-unique, reused-with-modifications, black-box reuse Relative cost of reuse (RCR) and relative cost of writing for reuse (RCWR) factors COPLIMO As functions of # products, # years in life cycle: Non-product line effort Product line investment (effort) Product line savings (ROI)

Constructive Rapid Application Development Model: CORADMO
Calculates/predicts for smaller, rapid application development projects Schedule Personnel Adjusted effort Allocates effort and schedule to the stages, which are anchored at points in a development life cycle Scope includes inception, elaboration, and construction

CORADMO Factors Reuse and Very High Level Languages
Development Process Reengineering and Streamlining Collaboration Efficiency Architecture/Risk Resolution Prepositioning Assets RAD Capability and Experience

Constructive Productivity Model: COPROMO
Determines impact of technology investments on model parameter settings Predicts the most cost effective allocation of investment resources in new technologies intended to improve productivity Uses COCOMO II, COPSEMO, and CORADMO models as assessment framework Well-calibrated to 161 projects for effort, schedule Subset of ’s projects for current-practice baseline Extensions for Rapid Application Development formulated

Constructive COTS Model: COCOTS
Estimates the effort associated with the integration of Commercial-Off-The-Shelf (COTS) software products Scope includes inception, elaboration, and construction Model has four components Assessment Tailoring “Glue” code System volatility Effort reported by COCOTS is the sum of the efforts from each of the four components Can be used in conjunction with COCOMO II to estimate new software development with COTS integration

COCOTS Operational Concept
# COTS Classes # Candidates/Class Tailoring Complexity Glue code size & cost drivers COCOMO II application effort (separate from COTS) COTS volatility rework (%) Rework due to COTS requirements changes (%) Rework due to non-COTS requirements changes (%) Assessment Tailoring COCOTS Effort “Glue” Code Volatility

COCOMO vs. COCOTS Cost Sources
STAFFING TIME

Constructive System Engineering Cost Model: COSYSMO
Covers full system engineering lifecycle (maps to ISO/IEC 15288) Life cycle stages being used in COSYSMO Project Estimates standard Systems Engineering WBS tasks (based on EIA/ANSI 632) Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation Conceptualize Operate, Maintain, or Enhance Transition to Operation Replace or Dismantle Oper Test & Eval Develop

COSYSMO Operational Concept
# Requirements # Interfaces # Scenarios # Algorithms + 3 Volatility Factors Size Drivers COSYSMO Effort Effort Multipliers Application factors 8 factors Team factors 6 factors Schedule driver Calibration WBS guided by EIA/ANSI 632

COSYSMO Effort Multipliers
Application Factors Requirements understanding Architecture complexity Level of service requirements Migration complexity Technology Maturity Documentation Match to Life Cycle Needs # and Diversity of Installations/Platforms # of Recursive Levels in the Design Team Factors Stakeholder team cohesion Personnel/team capability Personnel experience/continuity Process maturity Multisite coordination Tool support

Constructive System-of-System Cost Model: COSOSIMO
Parametric model to estimate the effort associated with the definition and integration of software-intensive “system of systems” components SoS abstraction Architecting Source selection Systems acquisition Integration and test Change management effort Includes at least one size driver and 6 exponential scale factors related to effort Targets input parameters that can be determined in early phases COSOSIMO

COSOSIMO Operational Concept
Size Drivers Interface-related eKSLOC Number of logical interfaces at SoS level Number of operational scenarios Number of components COSOSIMO SoS Definition and Integration Effort Exponential Scale Factors Integration simplicity Integration risk resolution Integration stability Component readiness Integration capability Integration processes Calibration

Model Unification Main Issues
For each individual model as well as the unified model: Objectives & Strategies Inputs/scope of work Output/scope of estimate Assumptions of each model Stakeholders for each model Counting Rules Sponsorship (FCS, Model-Based Acq.) PhD dissertation critical mass Data sources

Unification Goals Allow more comprehensive cost exploration with respect to Development decisions Investment decisions Established project budget and schedules Client negotiations and requested changes Cost, schedule, performance, and functionality tradeoffs Risk management decisions Process improvement decisions Affiliate request: Provide a single unified tool to allow users to Specify System and software components comprising the software system of interest Composition and characteristics of components Receive A set of comprehensive outputs for system engineering, software development, and system-of-systems integration Adjusted using the appropriate special-purpose extensions

Issue #1: Objectives & Strategies
First pass and future enhancements Framework (Goal-Quality-Metric model approach) Restate objectives for existing models COCOMO II COCOTS COSYSMO COSOSIMO CORADMO COQUALMO Develop objectives for unified cost model Operational scenario(s) for each model

Issue #2: Inputs/scope of work
Need to define on several levels To determine scope of work to be estimated To determine system of interest/viewpoint and system component characteristics To determine specific sub-model inputs Life cycle model Single user interface A single definition for each parameter/driver (eg. TEAM, PMAT, etc.) vs, context-specific definitions for parameters with common names across models Need to determine which “components” can be estimated as relatively independent pieces vs. tightly coupled components

Issue #3: Output/scope of estimate
Single value for all integrated models (default 152 hours per person-month) Normalized PM for calibration Backward compatibility to existing models What set of “bins” should be used for initial effort outputs? What additional levels of granularity should be provided? By phase/stage? By labor category? By activities? Break out by sub-models? Increments? (i.e., COINCOMO) How will an Integrated Master Schedule be developed? Effort & schedule as a function of risk Projected productivity

Issue #4: Assumptions of each model
Model Life Cycle Stages COCOMO II COCOTS COSYSMO COSOSIMO

Issue #5: Users for each model
Acquirers, SW developers, estimators, systems engineers, managers, executives, or accountants who are interested in: Software development (COCOMO II) Commercial off the shelf software (COCOTS) Systems engineering (COSYSMO) Software quality (COQUALMO) Software rapid application development (COPSEMO, CORADMO) Software system of systems integration (COSOSIMO) ROI/Investment analysis (iDave, COPLIMO)

Issue #6: Counting Rules & Definitions
Inputs Size drivers (VHLLs, FPs, APs, Use Case Points, KSLOC, REQS, ALG, I/F, SCEN, Components, etc.) Model inputs (cost drivers, scale factors) Outputs Effort distributions Phase, activity, or labor categories Schedule Defects $ cost Risk Productivity

Additional Analysis in Progress
Cost Drivers Scale Factors

Long Term Vision Unified Model COSOSIMO COSYSMO Unified Interface
COCOMOII/ COQUALMO COCOTS COCOMOII extensions RAD, security Incremental, phase/activity Agile, risk, Monte Carlo ROI (product line, dependability) Maintenance Output Analysis and Report Generation Unified Model

Suite overview Emerging extensions Model unification Addendum: selected model details COCOTS COPLIMO COSYSMO COSOSIMO References and further information

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 Integration Sources of Effort
COTS Assessment (pre- and post- commitment) Of functionality, performance, interoperability, etc. COTS Tailoring and Tuning Effects of platform, other COTS products Glue Code Development Similar to other Cost Xpert estimation Application Volatility Due to COTS COTS volatility, shortfalls, learning curve Added Application V&V Effort COTS option and stress testing Debugging complications, incorrect fixes

Traditional vs. COTS Cost Sources
LCO/ Reqts. Review LCA/ Design Review IOC/ Beta Test 3) COTS/Application Glue Code Development and Test 1) COTS Assessment 2) COTS Tailoring Staffing Application Code Development 4) Increased Application Effort due to COTS Volatility COCOMO II COTS model Time

Current Scope of COTS Model
COTS model covers assessment tailoring glue code development and integration impact of new releases (volatility) It does not cover cost of re-engineering business processes vendor management licenses training (for COTS integrators or end users) COTS platform or tool experience or maturity Covered by PLEX, LTEX, PVOL, TOOL environmental factors

Assessment Effort Inputs
Initial Filtering of COTS products estimate of the total number of candidate COTS components to be filtered More detailed assessment of specific candidates against attributes that are important class(es) of COTS components to be assessed for each class, number assessed attributes considered

( ) ( ) ( ) ( ) Assessment Submodel S S
Initial Filtering Effort (IFE) = ( ) ( ) S Average Filtering Effort for product class # COTS Candidates in class filtered Over all classes Detailed Assessment Effort (DAE) = ( ) ( ) S Average Assessment Effort for product class* # COTS Candidates in class detailed assessed Over all classes, by project domain *Qualified by assessment attributes most associated with that class Final Project Assessment Effort (FPAE) = IFE + DAE

Assessment Attributes

Tailoring Effort Inputs
COTS tailoring - activities required to prepare or initialize a component for use in a specific system Tailoring includes parameter specification script writing GUI screen specification Report specification Security/Access Protocol initialization and set up For each class of COTS component, rate the complexity of tailoring for each of the above activities

# COTS Tailored in class Average Tailoring Effort
Tailoring Submodel # COTS Tailored in class Project Tailoring Effort (PTE) = Average Tailoring Effort for product class ) [( ( S Over all classes, by project domain • TCQr, class ] where TCQr,class = Tailoring Complexity Qualifier, calibrated within a class, for each of five possible ratings from Very Low to Very High, and with the TCQNOMINAL = 1.0

Tailoring Complexity Table

Glue Code Inputs Definition of glue code:
code needed to facilitate data or information exchange between the COTS component and the system into which it is being integrated code needed to provide required functionality missing in the COTS component AND which depends on or must interact with the COTS component Estimate of the total delivered lines of glue code Estimate of glue code rework due to COTS volatility or requirements volatility

Glue Code Inputs (continued)
Integration Personnel Integrator experience with product (VL - VH) Integrator personnel capability (VL - VH) Integrator experience with COTS integration process (L - VH) Integrator personnel continuity (VL - VH) COTS Component COTS product maturity (VL - VH) COTS supplier product extension willingness (L - VH) COTS product interface complexity (L - VH) COTS supplier product support (L - VH) COTS supplier provided training and documentation (VL - VH)

Glue Code Inputs (continued)
Application/System Constraints on system/subsystem reliability (L - VH) Constraints on system/subsystem technical performance (N-VH) System portability (N - VH) Application architectural engineering (VL - VH)

Glue Code Submodel A - a linear scaling constant
P [(size)(1+breakage)] Total Effort = A B (effort multipliers) A - a linear scaling constant Size - of the glue code in SLOC or FP Breakage - of the glue code due to change in requirements and/or COTS volatility Effort Multipliers - 13 parameters, each with settings ranging VL to VH B - an architectural scale factor with settings VL to VH

Glue Code Cost Drivers

Volatility Inputs Captures impact of new COTS releases on the custom/new application effort Inputs: Estimate of new development effort (derived via Cost Xpert - traditional) Percentage of new development rework due to requirements changes COTS volatility Note: This submodel is being revised

[ ] [ ] ( ) Volatility Submodel • (EAF) • (EAF) Approximate Model:
Detailed Model with Cost Xpert Parameters: BRAK COTS: % application code breakage due to COTS volatility BRAK : % application code breakage otherwise S : Cost Xpert scale factor EAF : Effort Adjustment Factor (product of effort multipliers) [ ] BRAK COTS 100 Total Effort = (Application Effort) • (EAF) COTS [ ] Total Effort = (Application Effort) ( ) BRAK COTS 1+BRAK 1+ 1.01+ S -1 • (EAF) COTS

Total COTS Integration Cost Estimate
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) • ($$/Person-Month)

COPLIMO Background Benefits vs. Costs of product line
Does product line pay off? Traditional product line cost estimation models mostly underestimate the ROI for product lines by focusing only on development savings Apply RCWR surcharge to entire product not only to the reused portions If life cycle costs are considered, high payoff comes from a smaller code base to undergo maintenance COPLIMO life cycle model Addresses the shortfalls with a representative set of parameters based on experience in aircraft and spacecraft product line domains Based on COCOMO II parameters calibrated to 161 projects, empirical data on nonlinear reuse effects Benefits: large-scale productivity gains decreased time-to-market increased product quality increased customer satisfaction These benefits give organizations a competitive advantage. Costs: However, launching a software product line is really a big business decision that should not be made randomly. Usually there are some typical additional cost associated with the achievement of each benefits. Software product line requires a substantial start-up investment as well as ongoing costs to maintain the core assets. Before people start PL, they want to know if PL is the right strategy for their organization, why do I need to adopt this approach? Does PL really pays off?

COPLIMO Model Overview
Based on COCOMO II software cost model Statistically calibrated to 161 projects, representing 18 diverse organizations Based on standard software reuse economic terms RCWR: Relative Cost of Writing for Reuse RCR: Relative Cost of Reuse Avoids investment overestimation, savings underestimation Avoids RCWR for non-reused components Includes savings from smaller life-cycle code base Provides experience-based default parameter values Simple Excel spreadsheet model Easy to modify, extend, interoperate

COPLIMO - RCWR Development for Reuse (RUSE)
In COCOMO II database, 11 out of 161 projects rated as VH for RUSE, and 1 rated as XH Productivity Range of RUSE Highest rating / Lowest rating = 1.24/0.95 = 1.31 And two other contributing variables Required Reliability (RELY): Degree of Documentation (DOCU): The factor productivity range gives the ratio of the project’s productivity for the best factor rating to the worst factor rating (where all other factors remain constant.

COPLIMO – RCWR (Cont.) Required Reliability (RELY)
Constraints: At least Nominal for Nominal and High RUSE ratings, at least High for Very High and Extra High RUSE ratings Degree of Documentation (DOCU) Constraint: No more than one level below the RUSE rating Investing in High or Very High DOCU level for product line software might not be excessive, since it increase the understandability of the software, and reduce the relative cost of reuse later on.

Figure 1 Nonlinear Reuse Effects
COPLIMO – RCR Reused, or Black Box (unmodified code) RCR model Assessment and Assimilation (AA) factor Adapted, or White Box (modified code) RCR model AA Non-Linear Model 100 AAM Worst Case: AA = 0 Relative Modification of Size (AAF) AAM Best Case: SU = 10 UNFM = 0 AAF = 0.5 Selby data Relative Cost 1.0 1.5 0.0 50 0.5 0.045 AA = 8 SU = 50 UNFM = 1 Selby data summary Figure 1 Nonlinear Reuse Effects Two options. Each determines an equivalent amount of newly developed software to include in the total equivalent size of the software application. AA: accounts for the effort required to assess the candidate reusable components and choose the most appropriate one, plus the effort required to assimilate the component’s code and doc into the new application. 0, 2,4,6,8, five levels (percentage). White box RCR model: AA, plus several other factors within a non-linear model, such as DM, CM, IM, SU, UNFM. To determine the equivalent amount of new SLOC. The calculation of equivalent SLOC is based on the product size being adapted and a modifier that accounts for the effort involved in fitting adapted code into an existing product. The figure here shows the range of AAM

Basic COPLIMO – Development Cost Model (1)
Simplifying assumptions about uniformity and stability Every product roughly the same size (PSIZE) Roughly the same fractions of product-specific (PFRAC), adapted (AFRAC), and reused (RFRAC) software 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

RCR parameters RCWR: RCWR = RUSE * DOCU * RELY 1 product development effort: Non-PL Effort for developing N similar products: PMNR (N) = N · A· (PSIZE)B · Π (EM) 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 PL Effort (the first product): PMR (1) = PMNR (1) * [PFRAC + RCWR*(AFRAC+RFRAC)] Note: RCWR not applied to non-reused portion, where many other models overestimate RCWR

Basic COPLIMO – Annualized Life Cycle Cost Model
Annual Change Traffic (ACT) Relative fraction of a product’s software that is modified per year Simplifying assumption: Constant-ACT Life cycle effort without reuse N complete products undergo maintenance Life cycle effort with reuse PFRAC: maintenance for N instances RFRAC: maintenance for 1 instance AFRAC: maintenance for 1 instance and N-1 variants

The lower left table summaries the components and total life cycle sizes, effort for development with and without reuse across development and life cycle maintenance for a maintenance period of 5 years, as a function of number of similar products developed. Right chart: the comparative ROIs between a life-cycle model and a development-only model shows that higher ROI obtained when considering life cycle effects. Even after present-value discounting for future cash flows, the life cycle savings remain highly significant. Recent work by Cohen shows similar results.

Discussions Software product line payoffs are significant esp. across life cycle This does not mean any attempt at product line reuse will generate large savings Challenges: Technical: Domain engineering and product line architecting Management and Culture: People unwilling to corporate “Not invented here” attitudes Success factor: empowered product line manager

Conclusions Software product line payoffs are significant esp. across life cycle COPLIMO avoids investment overestimation & savings underestimation COPLIMO helps to determine whether and when it pays to launch a product line COPLIMO enables assessment of situation-dependencies, hence lead to better product line decisions. Future work: Support for more sensitivity analysis Model refinement and calibration Integration with other COCOMO II family models, such as COCOTS

COPLIMO Backup Charts

COPLIMO – RCR Reused, or Black Box (unmodified code) RCR model
Assessment and Assimilation (AA) factor Adapted, or White Box (modified code) RCR model AA Non-Linear Model

Guidelines for Quantifying Adapted Software

Determining RCR Equiv. size of product- specific portion: Equiv. size of reused portion: Equiv. size of adapted portion: Total EKSLOC: Effort: ROI = (PL Effort Savings for K products - PL Reuse Investment) / PL Reuse Investment PMR (N) = N · A· (EKSIZE)B · Π (EM)

Basic COPLIMO – Annualized Life Cycle Cost Model (1)
Annual Change Traffic (ACT) Relative fraction of a product’s software that is modified per year Life cycle effort without reuse Annual maintained software L times maintenance effort Life cycle effort with reuse Three categories of annual maintenance and AMSIZE

COSYSMO Introduction Covers full system engineering lifecycle (maps to ISO/IEC 15288) Life cycle stages being used in COSYSMO Project Estimates standard Systems Engineering WBS tasks (based on EIA/ANSI 632) Developed with USC-CSE Corporate Affiliate sponsorship and INCOSE participation Conceptualize Operate, Maintain, or Enhance Transition to Operation Replace or Dismantle Oper Test & Eval Develop

How is Systems Engineering Defined?
EIA/ANSI 632 Processes for Engineering a System: Acquisition and Supply Supply Process Acquisition Process Technical Management Planning Process Assessment Process Control Process System Design Requirements Definition Process Solution Definition Process Product Realization Implementation Process Transition to Use Process Technical Evaluation Systems Analysis Process Requirements Validation Process System Verification Process End Products Validation Process

COSYSMO Operational Concept
# Requirements # Interfaces # Scenarios # Algorithms + 3 adjustment factors Size Drivers COSYSMO Effort Effort Multipliers Application factors 8 factors Team factors 6 factors Calibration

Model Form Where: PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data k = {REQ, IF, ALG, SCN} wx = weight for “easy”, “nominal”, or “difficult” size driver = quantity of “k” size driver E = 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.

14 Cost Drivers (Effort Multipliers)
Application Factors (8) Requirements understanding Architecture understanding Level of service requirements Migration complexity Technology Maturity Documentation Match to Life Cycle Needs # and Diversity of Installations/Platforms # of Recursive Levels in the Design

14 Cost Drivers (continued)
Team Factors (6) Stakeholder team cohesion Personnel/team capability Personnel experience/continuity Process maturity Multisite coordination Tool support

How Much Effort to Integrate a System of Systems?
? person-years (PY) Sensing 500 PY Command & Control 1000 PY Vehicles 500 PY Common 400 PY Infrastructure 600 PY Systems developed by system contractors Total effort 3000 person-years System of systems integration functions SoS abstraction, architecting, source selection, systems acquisition, integration, test, change management effort How much to budget for integration? What factors make budget higher or lower? How to develop and validate an estimation model? We are seeing a growing trend in industry and DoD to “quickly” incorporate new technologies and expand the capabilities of legacy systems by integrating them with other legacy systems, COTS products, and new systems. And with this development approach, we see new activities being performed to define the new architecture, identify sources to either supply or develop the required components, and then to integrate and test test these high level components. Along with this “system-of-systems” development approach, we have seen a new role in the development process evolve to perform these activities: that of the Lead System Integrator (LSI). Much of this component-level effort can be estimated by COSYSMO and COCOMO II. However, neither of these models includes many of the LSI activities such as the definition of the SoS architecture, the solicitation and procurement process for the SoS components, and the integration of the SoS components into the SOS framework. As we see more and more of this type of development, it is important to get a handle on such questions as “how much to budget for SoS integration activities?”, what factors or characteristics make actual effort higher or lower?”, and “how can we make the estimation process ‘repeatable’?”. COSOSIMO is a parametric model to compute just this effort.

Constructive System-of-System Integration Cost Model (COSOSIMO)
Parametric model to estimate the effort associated with the definition and integration of software-intensive “system of systems” components Includes at least one size driver and 6 exponential scale factors related to effort Targets input parameters that can be determined in early phases Goal is to have zero overlap with COCOMO II and COSYSMO This is the basic definition of what COSOSIMO is. As you can see from the way the definition is worded, it is early in the development of this model and we are still working out some of the details. Our primary goals are to: Keep it simple (with as few inputs as possible) Develop a fairly accurate model using inputs that are easy to estimate or collect in the very early stages of development (inception and early elaboration stages). In addition, we are working to define clean boundaries between the various COCOMO models… and if there is overlap, provide guidance on how to eliminate the overlap when using multiple models.

COSOSIMO Operational Concept
Size Drivers Interface-related eKSLOC Number of logical interfaces at SoS level Number of components Number of operational scenarios COSOSIMO SoS Definition and Integration Effort Exponential Scale Factors Integration simplicity Integration risk resolution Integration stability Component readiness Integration capability Integration processes The “keep it simple” model: with one or two size drivers and about six cost drivers, think we can accurately estimate the amount of effort required to define an SoS architecture at the top level, to identify and acquire the specific components that will make up the architecture, and then to integrate the software-intensive components to into a functioning system of systems. More detailed definitions of the proposed size and cost drivers are coming in the next few slides Calibration Each size driver weighted by Complexity Volatility Degree of COTS/reuse

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 First determines integration effort for first level subsystems…. Then, using subsystem integration effort and SoS characteristics, determines SoS integration effort… Basically, COSOSIMO is a 2-tiered calculation. In order to determine the SoS integration effort (in person months), need to first calculate the Level 1 integration efforts for each of the Level 1 systems. The Level 1 integration efforts are based on the Level 2 subsystem sizes – these sizes are the effective KSLOC associated with subsystem software changes required to support the integration of the component into the SoS architecture. If components have nice cohesive interfaces, eKSLOC may be relatively small for even large components. Likewise, if changes are pervasive throughout the component, eKSLOC may include most of the component. The eKSLOC of each subsystem are then summed and then adjusted using an exponential scale factor. The exponential scale factor is the sum of the 6 scale factor adjustments added to the nominal exponent value for the Level 1 system. The Level 0 integration person months is then calculated by summing the integration person months for the level 1 systems and adjusting the sum using the SoS exponential scale factor values. Level 0 SOS Level 1 S1 S2 …… Sm S11 S12 S1n S21 S22 S2n Sm1 Sm2 Smn …… …… ……

COSOSIMO Model Parameters
IPM Integration effort in Person Months Si 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 SoS Bi Effort exponent for the ith subsystem based on the subsystem’s 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 SOS’ 6 exponential scale factors. The sum of the scale factors results in an overall exponential effort adjustment factor to the nominal effort. Definition of parameters discussed on previous slide.

References 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 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 Chulani, "Bayesian Analysis of Software Cost and Quality Models“, USC PhD dissertation, April 1999. Clark, B., Clark, B., “Early COCOTS”, September 2004. Lane, J. “Constructive Cost Model for System-of-System Integration,” 3rd ACM-IEEE International Symposium on Empirical Software Engineering, Redondo Beach, CA, August, 2004 Valerdi, R., Boehm, B., Reifer, D., “COSYSMO: A Constructive Systems Engineering Cost Model Coming Age,” Proceedings, 13th Annual INCOSE Symposium, Crystal City, VA. July 2003. Boehm B, Valerdi R Lane J, Brown W, COCOMO Suite Methodology and Evolution, Crosstalk, 2005 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

Further Information Main COCOMO website at USC: COCOMO information at USC: (213) COCOMO

COCOMO Suite Barry Boehm CSCI 510 Fall 2013.

Similar presentations

Presentation on theme: "COCOMO Suite Barry Boehm CSCI 510 Fall 2013."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

COCOMO Suite Barry Boehm CSCI 510 Fall 2013.

Similar presentations

Presentation on theme: "COCOMO Suite Barry Boehm CSCI 510 Fall 2013."— Presentation transcript:

Similar presentations

About project

Feedback