USC C S E University of Southern California

Скачать презентацию USC C S E University of Southern California

819b95938ebd8982137c79abd28e78ee.ppt

Количество слайдов: 113

USC C S E University of Southern California Center for Software Engineering COCOMO Suite Marilee Wheaton CSCI 510 1

USC C S E University of Southern California Center for Software Engineering Agenda • • COCOMO II refresher Modeling methodology and model status Suite overview Emerging extensions Model unification Addendum: selected model details References and further information 2

USC C S E University of Southern California Center for Software Engineering COCOMO II Overview 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 3

USC University of Southern California C S E Center for Software Engineering 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 4

USC C S E University of Southern California Center for Software Engineering COCOMO II Model Stages 5

USC C S E University of Southern California Center for Software Engineering COCOMO II Scope of Outputs • Provides the estimated software development effort and schedule for MBASE/RUP LCO LCA IOC – Elaboration – Construction 6

USC C S E University of Southern California Center for Software Engineering Agenda • • COCOMO II refresher COCOMO II in modern Sys. DLCs Modeling methodology and model status Suite overview Emerging extensions Model unification Addendum: selected model details References and further information 7

USC C S E University of Southern California Center for Software Engineering COCOMO II in Modern Sys. DLCs • COCOMO I for Waterfall • COCOMO II for MBASE[ICM]/RUP – Allows Waterfall as a subset – MBASE [ICM] recognize • Concurrent Engineering/Activities • System vs. Software in Software Intensive Systems • “Phases” beyond Elaboration and Construction [Architecting and Implementing] • See separate presentation: EC-09 b(SDLCs. Intro)V 2. doc 8

USC C S E University of Southern California Center for Software Engineering USC-CSE Modeling Methodology Analyze existing literature Step 1 Perform Behavioral analyses Step 2 Concurrency and feedback implied… Identify relative significance Step 3 Perform expert-judgment Delphi assessment, formulate a-priori model Step 4 Gather project data Determine Bayesian Step 5 A-Posteriori model Step 6 Gather more data; refine model Step 7 10

USC C S E Status of Models University of Southern California Center for Software Engineering Significa Exper Data, nt t Bayesia Behavi Variable Delph n or s i Tool Doc’d Literatur e COCOMO II Sw. CEw. CII * * * COPSEMO Sw. CEw. CII * * Timeof. LC A? CORADMO Sw. CEw. CII * * * COPROMO Sw. CEw. CII * * * COQUALMO Sw. CEw. CII * * 6, Y Excel Sw. CEw. CII * * 20, N Excel Model COCOTS * >161, Y Product Excel; COINCOM O 10, N Excel i. DAVE Ph. D Thesis Excel COPLIMO Ph. D Thesis Excel COSECMO COSYSMO * Ph. D * * COINCOM O * * 42, N 11 Excel

USC C S E University of Southern California Center for Software Engineering General COCOMO Form PM = A * ( Size) B * (EM) MULTIPLICATIVE ADDITIVE EXPONENTIAL 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 12

USC University of Southern California C S E Center for Software Engineering COCOMO Suite: Quantities Estimated Effort by Phase Schedule COCOMO II X X X COQUALMO X Model X i. DAVE Defects ROI Improvement Graphs X X COPLIMO X CORADMO X X COPROMO X X COCOTS X COSYSMO X COSOSIMO X X 14

USC C S E University of Southern California Center for Software Engineering COCOMO Suite: Sizing Volatility Reuse Complexity Components Algorithms Scenarios Interfaces Requirement s FP + Lang SLOC Model X X COCOMO II Module X X CORADMO X X COQUALMO X X X X COSYSMO Glue X X X COSOSIMO Glue X COCOTS 15

USC University of Southern California C S E Center for Software Engineering COCOMO Suite: Phase/Activity Distribution Model Inception Elaboration Construction Transition COCOMO II COQUALMO i. DAVE COPLIMO CORADMO COPROMO COCOTS COSYSMO COSOSIMO 16

USC C S E University of Southern California Center for Software Engineering Typical Model Usage 17

USC University of Southern California C S E Center for Software Engineering High Level Partitioning of Cost Models COSOSIMO SOS Architecting System of System Integration/Test COSYSMO System Architecting Software Requirements Analysis System Integration/Test COCOMO II Preliminary Design Software Acceptance Test Integration Detailed Design Unit Test Legend COCOTS Coding COCOMO COSYSMO COSOSIMO 18

USC University of Southern California C S E Center for Software Engineering Emerging Extensions • COCOMO-Dependent Extensions – – – COQUALMO: software quality i. DAVE: 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 20

USC C S E University of Southern California Center for Software Engineering 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 21

USC C S E University of Southern California Center for Software Engineering COQUALMO Operational Concept COCOMO II COQUALMO Software Size Estimate Software platform, Project, product and personnel attributes Defect Introduction Model Software development effort, cost and schedule estimate Number of residual defects Defect density per unit of size Defect removal profile levels Automation, Reviews, Testing Defect Removal Model 22

USC C S E University of Southern California Center for Software Engineering COQUALMO Defect Removal Rating Scales Very Low Nominal High Very High Extra High Automated Analysis Simple compiler syntax checking Basic compiler capabilities Compiler extension Basic req. and design consistency Intermediatelevel module Simple req. /design More elaborate req. /design Basic distprocessing Formalized specification, verification. Advanced distprocessing Peer Reviews No peer review Ad-hoc informal walkthrough Well-defined preparation, review, minimal follow -up Formal review roles and Welltrained people and basic checklist Root cause analysis, formal follow Using historical data Extensive review checklist Statistical control Execution Testing and Tools No testing Ad-hoc test and debug Basic test Test criteria based on checklist Well-defined test seq. and basic test coverage tool system More advance test tools, preparation. Distmonitoring Highly advanced tools, modelbased test 23

USC C S E University of Southern California Center for Software Engineering COQUALMO Defect Removal Estimates - Nominal Defect Introduction Rates Delivered Defects / KSLOC Composite Defect Removal Rating 24

USC C S E University of Southern California Center for Software Engineering Information Dependability Attribute Value Estimator: i. DAVE • i. DAVE 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 25

USC C S E University of Southern California Center for Software Engineering i. DAVE Operational Concept 26

USC C S E University of Southern California Center for Software Engineering 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 27

USC C S E University of Southern California Center for Software Engineering COPLIMO Operational Concept For set of products: • Average product size (COCOMO II cost drivers) • Percent missionunique, reused-withmodifications, blackbox 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) 28

USC C S E University of Southern California Center for Software Engineering 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 29

USC C S E University of Southern California Center for Software Engineering Where, What & How • Where is CORADMO along the USC-CSSE Cost Estimating Modeling Methodology • CORADMO drivers • Illustrated need for COPSEMO 30

USC C S E University of Southern California Center for Software Engineering USC-CSSE Cost Estimating Modeling Methodology Analyze existing literature Step 1 Perform Behavioral analyses Step 2 Concurrency and feedback implied… Identify relative significance Step 3 Perform expert-judgment Delphi assessment, formulate a-priori model Step 4 Gather project data Determine Bayesian Step 5 A-Posteriori model Step 6 Gather more data; refine model Step 7 31

USC C S E University of Southern California Center for Software Engineering CORADMO Factors • Reuse and Very High Level Languages • Development Process Reengineering and Streamlining • Collaboration Efficiency • Architecture/Risk Resolution • Prepositioning Assets • RAD Capability and Experience 32

USC C S E University of Southern California Center for Software Engineering CORADMO Driver Example Architecture / Risk Resolution (RESL) • Same as COCOMO II RESL rating scale • Enables parallel construction – Assumes higher level of staffing available and used – Otherwise no schedule compression 33

USC C S E University of Southern California Center for Software Engineering MBASE/RUP Concurrent Activities 34

USC C S E University of Southern California Center for Software Engineering RUP & [Instructional] ICM for Sw Phase Distributions 35

USC C S E COPSEMO Distributes Effort & Center for Software Engineering Schedule University of Southern California 36

USC C S E University of Southern California Center for Software Engineering COPSEMO Demo • Done live in Class based on CSCI 577 a • See CSCI 577 a Tutorials (soon) for update 37

USC C S E University of Southern California Center for Software Engineering 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 106 1990’s projects for current-practice baseline – Extensions for Rapid Application Development formulated 38

USC University of Southern California C S E Center for Software Engineering 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 39

USC C S E University of Southern California Center for Software Engineering COCOTS Operational Concept • # COTS Classes • # Candidates/Class • Tailoring Complexity • Glue code size & cost drivers • COCOMO II application effort (separate from COTS) Assessment COCOTS • COTS volatility rework (%) • Rework due to COTS requirements changes (%) • Rework due to non-COTS requirements changes (%) Tailoring “Glue” Code Effort Volatility via COCOMOII 40

USC C S E University of Southern California Center for Software Engineering STAFFING COCOMO vs. COCOTS Cost Sources TIME 41

USC C S E University of Southern California Center for Software Engineering Constructive System Engineering Cost Model: COSYSMO • Covers full system engineering lifecycle (maps to ISO/IEC 15288) Conceptualize Develop Oper Test Transition to & Eval Operation Operate, Maintain, or Enhance Replace or Dismantle 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 42 sponsorship and INCOSE participation

USC C S E University of Southern California Center for Software Engineering COSYSMO Operational Concept # Requirements # Interfaces # Scenarios # Algorithms + 3 Volatility Factors Size Drivers Effort Multipliers - Application factors -8 factors - Team factors -6 factors - Schedule driver COSYSMO Effort Calibration WBS guided by EIA/ANSI 632 43

USC C S E University of Southern California Center for Software Engineering 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 44

USC C S E University of Southern California Center for Software Engineering 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 – – – So. S 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 45

USC C S E University of Southern California Center for Software Engineering COSOSIMO Operational Concept Size Drivers • Interface-related e. KSLOC • Number of logical interfaces at So. S level • Number of operational scenarios • Number of components Exponential Scale Factors • • • Integration simplicity Integration risk resolution Integration stability Component readiness Integration capability Integration processes COSOSIMO So. S Definition and Integration Effort Calibration 46

USC University of Southern California C S E Center for Software Engineering Model Unification Main Issues For each individual model as well as the unified model: 1. 2. 3. 4. 5. 6. 7. 8. 9. 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. ) Ph. D dissertation critical mass Data sources 48

USC C S E University of Southern California Center for Software Engineering 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-ofsystems integration • Adjusted using the appropriate special-purpose extensions 49

USC University of Southern California C S E Center for Software Engineering 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 50

USC C S E University of Southern California Center for Software Engineering 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 51

USC C S E University of Southern California Center for Software Engineering Issue #3: Output/scope of estimate • Single value for all integrated models (default 152 hours personmonth) – 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 52

USC C S E University of Southern California Center for Software Engineering Issue #4: Assumptions of each model Model Life Cycle Stages COCOMO II COCOTS COSYSMO COSOSIMO 53

USC C S E University of Southern California Center for Software Engineering Integration of Life Cycle Stages 54

USC C S E University of Southern California Center for Software Engineering Vision for COINCOMO 55

USC University of Southern California C S E Center for Software Engineering 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) 56 – ROI/Investment analysis (i. Dave, COPLIMO)

USC University of Southern California C S E Center for Software Engineering 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 57

USC C S E University of Southern California Center for Software Engineering Additional Analysis in Progress • Cost Drivers • Scale Factors 58

USC C S E University of Southern California Center for Software Engineering Long Term Vision 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 59

USC C S E University of Southern California Center for Software Engineering Agenda • • • COCOMO II refresher Modeling methodology and model status Suite overview Emerging extensions Model unification Addendum: selected model details – – COCOTS COPLIMO COSYSMO COSOSIMO • References and further information 60

USC C S E University of Southern California Center for Software Engineering COTS Software Integration Lifecycle COTS 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 61

USC C S E University of Southern California Center for Software Engineering 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 62

USC C S E University of Southern California Center for Software Engineering Traditional vs. COTS Cost Sources Staffing • LCO/ Reqts. Review • LCA/ • IOC/ Design Review Beta Test 3) COTS/Application Glue Code Development 1) COTS 2) COTS and Test Assessment Tailoring Application Code Development 4) Increased Application Effort due to COTS Volatility COCOMO II COTS model Time 63

USC University of Southern California C S E Center for Software Engineering 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 64

USC C S E University of Southern California Center for Software Engineering 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 65

USC University of Southern California C S E Center for Software Engineering Assessment Submodel Initial Filtering Effort (IFE) = S ( Over all classes )( # COTS Candidates in class filtered ) Average Filtering Effort for product class Detailed Assessment Effort (DAE) = S ( Over all classes, by project domain )( # COTS Candidates in class detailed assessed ) Average Assessment Effort for product class* *Qualified by assessment attributes most associated with that class Final Project Assessment Effort (FPAE) = IFE + DAE 66

USC C S E University of Southern California Center for Software Engineering Assessment Attributes 67

USC University of Southern California C S E Center for Software Engineering 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 68

USC C S E University of Southern California Center for Software Engineering Tailoring Submodel Project Tailoring Effort (PTE) = ) S [(# COTS Tailored in class ( ) Average Tailoring Effort for product class ] • TCQr, class Over all classes, by project domain 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 69

USC C S E University of Southern California Center for Software Engineering Tailoring Complexity Table 70

USC C S E University of Southern California Center for Software Engineering 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 71

USC University of Southern California C S E Center for Software Engineering 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) 72

USC C S E University of Southern California Center for Software Engineering 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) 73

USC C S E University of Southern California Center for Software Engineering Glue Code Submodel B Total Effort = A [(size)(1+breakage)] (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 74

USC C S E University of Southern California Center for Software Engineering Glue Code Cost Drivers 75

USC C S E University of Southern California Center for Software Engineering 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 76

USC C S E University of Southern California Center for Software Engineering Volatility Submodel Approximate Model: Total Effort = (Application Effort) [ BRAK COTS 100 ] • (EAF) COTS Detailed Model with Cost Xpert Parameters: Total Effort = (Application Effort) [( 1+ BRAK COTS 1+BRAK ) 1. 01+ ] • -1 (EAF) COTS BRAK COTS: % application code breakage due to COTS volatility BRAK : % application code breakage otherwise : Cost Xpert scale factor EAF : Effort Adjustment Factor (product of effort multipliers) 77

USC C S E University of Southern California Center for Software Engineering Total COTS Integration Cost Estimate x. Total 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) 78

USC C S E University of Southern California Center for Software Engineering 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 80

USC C S E University of Southern California Center for Software Engineering 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 81

USC C S E University of Southern California Center for Software Engineering 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): 82

USC C S E University of Southern California Center for Software Engineering 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 83

USC C S E University of Southern California Center for Software Engineering COPLIMO – RCR • Reused, or Black Box (unmodified code) RCR model – Assessment and Assimilation (AA) factor • Adapted, or White Box (modified code) RCR model 1. 5 – AA – Non-Linear Model Relative Cost 1. 0 AAM Worst Case: AAF = 0. 5 AA = 8 SU = 50 UNFM = 1 AAM Best Case: Selby data summary AAF = 0. 5 AA = 0 SU = 10 UNFM = 0 0. 5 Selby data 0. 045 0. 0 50 Relative Modification of Size (AAF) Figure 1 Nonlinear Reuse Effects 100 84

USC C S E University of Southern California Center for Software Engineering 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, Average product size, productivity Non-product line effort Percent productspecific, adapted, reused RCR, RCWR factors Basic COPLIMO Product line investment, effort Product line savings, ROI 85

USC C S E University of Southern California Center for Software Engineering Basic COPLIMO – Development Cost Model (2) • RCWR: • RCR parameters – 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 86

USC C S E University of Southern California Center for Software Engineering 87

USC C S E University of Southern California Center for Software Engineering 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 88

USC C S E University of Southern California Center for Software Engineering 89

USC C S E University of Southern California Center for Software Engineering 90

USC C S E University of Southern California Center for Software Engineering 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 91

USC C S E University of Southern California Center for Software Engineering 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 92

USC C S E University of Southern California Center for Software Engineering COPLIMO Backup Charts 93

USC C S E University of Southern California Center for Software Engineering Guidelines for Quantifying Adapted Software 95

USC C S E University of Southern California Center for Software Engineering Basic COPLIMO – Development Cost Model (3) • Determining RCR – Equiv. size of product- specific portion: – Equiv. size of reused portion: – Equiv. size of adapted portion: – Total EKSLOC: PMR (N) = N · A· (EKSIZE)B · Π (EM) – Effort: – ROI = (PL Effort Savings for K products - PL Reuse Investment) / PL Reuse Investment 96

USC C S E University of Southern California Center for Software Engineering 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 97

USC C S E University of Southern California Center for Software Engineering COSYSMO Introduction • Covers full system engineering lifecycle (maps to ISO/IEC 15288) Conceptualize Develop Oper Test Transition to & Eval Operation Operate, Maintain, or Enhance Replace or Dismantle 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 99

USC C S E University of Southern California Center for Software Engineering 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 100

USC C S E University of Southern California Center for Software Engineering COSYSMO Operational Concept # Requirements # Interfaces # Scenarios # Algorithms + 3 adjustment factors Size Drivers Effort Multipliers - Application factors -8 factors - Team factors -6 factors COSYSMO Effort Calibration 101

USC C S E University of Southern California Center for Software Engineering 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. 102

USC C S E University of Southern California Center for Software Engineering 14 Cost Drivers (Effort Multipliers) Application Factors (8) 1. 2. 3. 4. 5. 6. 7. 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 103

USC C S E University of Southern California Center for Software Engineering 14 Cost Drivers (continued) Team Factors (6) 1. 2. 3. 4. 5. 6. Stakeholder team cohesion Personnel/team capability Personnel experience/continuity Process maturity Multisite coordination Tool support 104

USC C S E University of Southern California Center for Software Engineering How Much Effort to Integrate a System of Systems? 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 – So. S 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? 106

USC C S E University of Southern California Center for Software Engineering 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 107

USC C S E University of Southern California Center for Software Engineering COSOSIMO Operational Concept Size Drivers • Interface-related e. KSLOC • Number of logical interfaces at So. S level • Number of components • Number of operational scenarios Exponential Scale Factors • • • Integration simplicity Integration risk resolution Integration stability Component readiness Integration capability Integration processes COSOSIMO So. S Definition and Integration Effort Calibration Each size driver weighted by • Complexity • Volatility • Degree of COTS/reuse 108

USC C S E University of Southern California Center for Software Engineering COSOSIMO Model Equations ni Bi Level 1 IPM (Si) = Ai Size (Sij) j=1 mi Level 0 IPM (So. S) = A 0 IPM (Si) B 0 i=1 Two level model that • First determines integration effort for first level subsystems…. • Then, using subsystem integration effort and So. S characteristics, determines So. S integration effort… Level 0 Level 1 S 11 S 12 ……S 1 n SOS S 21 S 22 …… ……S 2 n Sm Sm 1 Sm 2 109 S …… mn

USC C S E University of Southern California Center for Software Engineering COSOSIMO Model Parameters IPM Si A Size ni m Bi B 0 Integration effort in Person Months The ith subsystem within the So. S Constant derived from historical project data Determined by computing the weighted average of the size driver(s) Number of Subsystem level 2 components comprising the ith subsystem Number of Subsystem level 1 components comprising the So. S 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. Effort exponent for the So. S 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. 110

USC C S E University of Southern California Center for Software Engineering 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 Ph. D 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 Ph. D dissertation, April 1999. Clark, B. , “Early COCOTS”, September 2004. Lane, J. “Constructive Cost Model for System-of-System Integration, ” 3 rd ACMIEEE 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, 13 th 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 112

USC C S E University of Southern California Center for Software Engineering Further Information • Main COCOMO website at USC: http: //sunset. usc. edu/research/COCOMOII • COCOMO information at USC: (213) 7406470 • COCOMO email: cocomo-info@sunset. usc. edu 113