SW Economics & COCOMO II November 25, 2005 Jongmoon Baik, Ph.D. School of Engineering Information and Communications University

2 What is Software Economics? “Software Economics is the study of how scarce project resources are allocated for software projects” Software Economics Software Economics Software Development Psychology Organizational Behavior Social Psychology Economics Statistics

Information and Communications University 3 Macro vs. Micro Economics  Macro economics  SE supports a commercial S/W sector that earns $200B to $240B in US  SE drove $1T of economic growth in US  Micro economics  About ¼ of software projects are delivered successfully  Commercial developers typically write 12K lines of code per year  Government developers typically write 1.5K lines of code per year

Information and Communications University 4 Software Economics Roadmap  Goal  Develop fundamental knowledge to enable significant measurable increases in the value created over time  Better decision making:  Key enabler of greater value added  In richer design spaces

Information and Communications University 5 Current Issues in SEE  Global Software Economics  Free (Open) Software Economics  etc.

Information and Communications University 6 Why is it important to Software Cost??  Software cost is big and growing  Many useful software products are not getting developed  Get us better software not just more software Boehm et. Al, “Understanding and Controlling Software Cost”, IEEE TSE, SE4, 10, pp

Information and Communications University 7 WHAT IS COCOMO? Beach Boys – KoKoMo (1988)

Information and Communications University 8 WHAT IS COCOMO? “ COCOMO (COnstructive COst MOdel)” is a model designed by Barry Boehm to give an estimate of the number of programmer-months it will take to develop a software product.” Barry Boehm - Wikipedia, the free encyclopedia -

Information and Communications University 9 Software Estimation Techniques

Information and Communications University 10 Software Cost Estimation Steps 1. Establish Objectives  Rough Sizing  Make-or-Buy  Detailed Planning 2. Allocate Enough Time, Dollars, Talent 3. Pin down Software Requirements  Documents Definition, Assumption 4. Work out as much detail as Objectives permit 5. Use several independent Techniques + Sources  Top-Down vs. Bottom-Up  Algorithm Vs. Expert-Judgement 6. Compare and iterate estimates  Pin down and resolve inconsistencies  Be Conservative 7. Follow up

Information and Communications University 11 COCOMO II Overview - I  COCOMO II Baseline Overview  Application Composition Model  Sizing Methods (SLOC & UFP)  Early Design & Post Architecture Models  Software Reuse Model

Information and Communications University 12 COCOMO II Overview - II Software product size estimate Software product, process, computer, and personnel attributes Software reuse, maintenance, and increment parameters Software organization’s project data Software development, maintenance cost and schedule estimates Cost, schedule distribution by phase, activity, increment COCOMO recalibrated to organization’s data COCOMO II

Information and Communications University 13 COCOMO II Overview - III  Open interfaces and internals  Published in Software Cost Estimation with COCOMO II, Boehm et. al., 2000 COCOMO – Software Engineering Economics, Boehm, 1981  Numerous Implementation, Calibrations, Extensions  Incremental Development, Ada, new environment technology  Arguably the most frequently-used software cost model worldwide

Information and Communications University 14 COCOMO II User Objectives  Making investment or other financial decisions involving a software development  Setting project budgets and schedules as a basis for planning and control  Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance or quality factors  Making software cost and schedule risk management decisions  Deciding which parts of a software system to develop, reuse, lease or purchase  Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc.  Setting mixed investment strategies to improve your organization ’ s software capability, via reuse, tools, process maturity, outsourcing, etc.  Deciding how to implement a process improvement strategy

Information and Communications University 15 COCOMO II Objectives  Provide accurate cost and schedule estimates for both current and likely future software projects.  Enabling organizations to easily recalibrate, tailor or extend COCOMO II to better fit their unique situations.  Provide careful, easy-to-understand definition of the model ’ s inputs, outputs and assumptions.  Provide constructive model.  Provide a normative model.  Provide evolving model.

Information and Communications University 16 S/W Estimation Accuracy vs. Phase Plans and Rqts. Devel. and Test Phases and Milestones Size (DSI) + Cost ($) x 2x 1.5x 1.25x x 0.25x 0.5x Relative Size Range Completed Programs USAF/ESD Proposals Feasibility Product Design Detail Design Concept of Operation Rqts. Spec. Product Design Spec. Detail Design Spec. Accepted Software “Corn of Software Cost Estimation”

Information and Communications University 17 MBASE/Rational Anchor Point Milestones App. Compos. InceptionElaboration, Construction LCO, LCA IOC Waterfall Rqts. Prod. Des. LCA Development LCO Sys Devel IOC Transition SRR PDR Construction SAT Trans. Inception Phase Elaboration

Information and Communications University 18 Application Composition Model  Challenge:  Modeling rapid application composition with graphical user interface (GUI) builders, client-server support, object-libraries, etc.  Responses:  Application-Point Sizing and Costing Model  Reporting estimate ranges rather than point estimate

Information and Communications University 19 Application Point Estimation Procedure

Information and Communications University 20 Sizing Methods  Counting Source Lines of Code (SLOC)  SEI Definition Check List  Counting Unadjusted Function Points (UFP)  IFPUG

Information and Communications University 21 Source Lines of Code  Best Source : Historical data form previous projects  Expert-Judged Lines of Code  Expressed in thousands of source lines of code (KSLOC)  Difficult Definition – Different Languages  COCOMO II uses Logical Source Statement  SEI Source Lines of Code Check List  Excludes COTS, GFS, other products, language support libraries and operating systems, or other commercial libraries

Information and Communications University 22 SEI Source Lines of Code Checklist

Information and Communications University 23 Unadjusted Function Points - I  Based on the amount of functionality in a software project and a set of individual project factors.  Useful since they are based on information that is available early in the project life-cycle.  Measure a software project by quantifying the information processing functionality associated with major external data or control input, output, or file types.

Information and Communications University 24 Unadjusted Function Points - II Step 1. Determine function counts by type. The unadjusted function point counts should be counted by a lead technical person based on information in the software requirements and design documents. The number of each the five user function types should be counted (Internal Logical File (ILF), External Interface File (EIF), External Input (EI), External Output (EO), and External Inquiry (EQ)). Step 2. Determine complexity-level function counts. Classify each function count into Low, Average, and High complexity levels depending on the number of data element types contained and the number of file types reference. Use the following scheme. Step 3. Apply complexity weights. Weight the number in each cell using the following scheme. The weight reflect the relative value of the function to the user. Step 4. Compute Unadjusted Function Points. Add all the weight functions counts to get one number, the Unadjusted Function Points.

Information and Communications University 25 Relating UFPs to SLOC  USC-COCOMO II  Use conversion table (Backfiring) to convert UFPS into equivalent SLOC  Support 41 implementation languages and USR1-5 for accommodation of user ’ s additional implementation languages  Additional Ratios and Updates :

Information and Communications University 26 Early Design & Post-Architecture Models Early Design Model [6 EMs]: Post Architecture Model [16 EMs]: *Exclude SCED driver EMs: Effort multipliers to reflect characteristics of particular software under development A : Multiplicative calibration variable E : Captures relative (Economies/Diseconomies of scale) SF: Scale Factors A = 2.94B = 0.91 C = 3.67D = 0.28

Information and Communications University 27 Scale Factors & Cost Drivers  Project Level – 5 Scale Factors  Used for both ED & PA models  Early Design – 7 Cost Drivers  Post Architecture – 17 Cost Drivers  Product, Platform, Personnel, Project

Information and Communications University 28 Project Scale Factors - I  Relative economies or diseconomies of scale  E < 1.0 : economies of scale Productivity increase as the project size increase Achieved via project specific tools (e.g., simulation, testbed)  E = 1.0 : balance Linear model : often used for cost estimation of small projects  E > 1.0 : diseconomies of scale Main factors : growth of interpersonal communication overhead and growth of large-system overhead

Information and Communications University 29 Project Scale Factors - II

Information and Communications University 30 COCOMO II Effort Multipliers Product: RELY, DATA, RUSE, DOCU, CPLX Platform: TIME, STOR, PVOL Personnel: PCAP, ACAP, PCON, APEX, LTEX, PLEX Project: TOOL, SITE, SCED

Information and Communications University 31 ED EMs vs. PA EMs

Information and Communications University 32 Life Cycle Phases

Information and Communications University 33 Waterfall Phase Distribution

Information and Communications University 34 Software Reuse

Information and Communications University 35 Reuse & Product Line Mgmt.  Challenges - Estimate costs of both reusing software and developing software for future reuse - Estimate extra effects on schedule (if any)  Responses - New nonlinear reuse model for effective size - Cost of developing reusable software estimated by RUSE effort multiplier - Gathering schedule data

Information and Communications University 36 Non-Linear Reuse Effect

Information and Communications University 37 COCOMO II Reuse Model  Add Assessment & Assimilation increment (AA)  - Similar to conversion planning increment  Add software understanding increment (SU)  - To cover nonlinear software understanding effects  - Coupled with software unfamiliarity level (UNFM)  - Apply only if reused software is modified

Information and Communications University 38 Software Understanding

Information and Communications University 39 Assessment and Assimilation (AA)

Information and Communications University 40 Unfamiliarity (UNFM)

Information and Communications University 41 Guidelines for Quantifying Adapted Software

Information and Communications University 42 Requirement Evolution & Volatility (REVL)  Adjust the effective size of the product  Causal factors: user interface evolution, technology upgrades, or COTS volatility  Percentage of code discarded due to requirement evolution  E.g., SLOC = 100K and REVL = 20 Project effective size = 120K

Information and Communications University 43 USC-COCOMO II.2000 Demo.

Information and Communications University 44 Further Information  Book  Software Cost Estimation with COCOMO II  USC-CSE   Jongmoon Baik   Phone: