COCOMO II Model Definition Manual

1 COCOMO II Model Definition ManualAcknowledgmentsCOCOMO II is an effort to update the well-known COCOMO (Constructive Cost Model ) software cost estimation modeloriginally published in Software Engineering Economics by Dr. Barry Boehm in 1981. It focuses on issues such as non-sequential and rapid-development process models; reuse-driven approaches involving commercial-off-the-shelf (COTS)packages, reengineering, applications composition, and application generation capabilities; object-oriented approachessupported by distributed middleware; software process maturity effects and process-driven quality estimation.

2 TheCOCOMO II research effort is being led by the Director of the Center for Software Engineering at USC, Dr. BarryBoehm, and the other researchers (in alphabetic order) are listed Abts Graduate Research AssistantBrad ClarkGraduate Research AssistantSunita Devnani-ChulaniGraduate Research AssistantEllis HorowitzChair, Computer Science Department, USCRay MadachyAdjunct Assistant ProfessorDon ReiferVisiting AssociateRick SelbyProfessor, UCIBert SteeceDeputy Dean of Faculty, Marshall School of Business, USCThis work is being supported both financially and technically by the COCOMO II Program Affiliates.

3 Aerospace, Air ForceCost Analysis Agency, Allied Signal, AT&T, Bellcore, EDS, Raytheon E-Systems, GDE Systems, Hughes, IDA, JPL, Litton,Lockheed Martin, Loral, MCC, MDAC, Motorola, Northrop Grumman, Rational, Rockwell, SAIC, SEI, SPC, Sun, TI, TRW,USAF Rome Lab, US Army Research Labs, successive versions of the tool based on the COCOMO Model have been developed as part of a Graduate Level CourseProject by several student development teams led by Dr. Ellis Horowitz. The current version, USC COCOMO , hasbeen developed by Jongmoon Model Definition 1 COCOMO II Models for the Software Marketplace Sectors 1 COCOMO II Model Rationale and Elaboration 1 Development Effort Estimates 4 Software Economies and Diseconomies of Scale 4 Previous Approaches 4 Scaling Drivers 5 Precedentedness (PREC) and Development Flexibility (FLEX) 6 Architecture / Risk Resolution (RESL) 6 Team Cohesion (TEAM) 7 Process Maturity (PMAT)

4 8 Overall Maturity Level 8 Key Process Areas 8 Adjusting Nominal Effort 9 Early Design Model 10 Post-Architecture Model 10 Development Schedule Estimation 10 Using COCOMO II 11 Determining Size 11 Lines of Code 11 Function Points 14 Counting Procedure for Unadjusted Function Points 15 Converting Function Points to Lines of Code 15 Breakage 16 Adjusting for Reuse 16 Nonlinear Reuse Effects 16A Reuse Model 18 Adjusting for Re-engineering or Conversion 19 Applications Maintenance 20 Effort Multipliers 21 Early Design 21 Overall Approach.

5 Personnel Capability (PERS) Example 22 Product Reliability and Complexity (RCPX) 23 Required Reuse (RUSE) 23 Platform Difficulty (PDIF) 23 Personnel Experience (PREX) 24 Facilities (FCIL) 24 Schedule (SCED) 24 Post-Architecture 25 Product Factors 25 Required Software Reliability (RELY) 25 Data Base Size (DATA) 25 Product Complexity (CPLX) 25 Required Reusability (RUSE) 27 Documentation match to life-cycle needs (DOCU) 27 Platform Factors 27 Execution Time Constraint (TIME) 27 Main Storage Constraint (STOR) 27 Platform Volatility (PVOL) 28 Personnel Factors 28 Analyst Capability (ACAP) 28 Programmer Capability (PCAP) 28 Applications Experience (AEXP) 28 Platform Experience (PEXP) 29 Language and Tool Experience (LTEX) 29 Personnel Continuity (PCON) 29 Project Factors 29 Use of Software Tools (TOOL) 29 Multisite Development (SITE) 29 Required Development Schedule (SCED) 30 Index 31 Overall Model DefinitionThe four main elements of the COCOMO II strategy are: Preserve the openness of the original COCOMO .

6 Key the structure of COCOMO II to the future software marketplace sectors described earlier; Key the inputs and outputs of the COCOMO II submodels to the level of information available; Enable the COCOMO II submodels to be tailored to a project's particular process II follows the openness principles used in the original COCOMO . Thus, all of its relationships andalgorithms will be publicly available. Also, all of its interfaces are designed to be public, well-defined, and parametrized, sothat complementary preprocessors (analogy, case-based, or other size estimation models), post-processors (project planningand control tools, project dynamics models, risk analyzers), and higher level packages (project management packages,product negotiation aids)

7 , can be combined straightforwardly with COCOMO support the software marketplace sectors above, COCOMO II provides a family of increasingly detailed softwarecost estimation models, each tuned to the sectors' needs and type of information available to support software cost II Models for the Software Marketplace SectorsThe COCOMO II capability for estimation of Application Generator, System Integration, or Infrastructure developments isbased on two increasingly detailed estimation models for subsequent portions of the life cycle, Early Design and II Model Rationale and ElaborationThe rationale for providing this tailorable mix of models rests on three primary , unlike the initial COCOMO situation in the late 1970's, in which there was a single, preferred software life cyclemodel, current and future software projects will be tailoring their processes to their particular process drivers.

8 These processdrivers include COTS or reusable software availability; degree of understanding of architectures and requirements; marketwindow or other schedule constraints; size; and required reliability (see [Boehm 1989, pp. 436-37] for an example of suchtailoring guidelines).Second, the granularity of the software cost estimation Model used needs to be consistent with the granularity of theinformation available to support software cost estimation. In the early stages of a software project, very little may be knownabout the size of the product to be developed, the nature of the target platform, the nature of the personnel to be involved inthe project, or the detailed specifics of the process to be I-1, extended from [Boehm 1981, p.]

9 311], indicates the effect of project uncertainties on the accuracy ofsoftware size and cost estimates. In the very early stages, one may not know the specific nature of the product to be developedto better than a factor of 4. As the life cycle proceeds, and product decisions are made, the nature of the products and itsconsequent size are better known, and the nature of the process and its consequent cost drivers1 are better known. The earlier completed programs size and effort data points in Figure I-1 are the actual sizes and efforts of seven software products builtto an imprecisely-defined specification [Boehm et.

10 Al. 1984]2. The later USAF/ESD proposals data points are from fiveproposals submitted to the Air Force Electronic Systems Division in response to a fairly thorough specification [Devenny1976].Third, given the situation in premises 1 and 2, COCOMO II enables projects to furnish coarse-grained cost driverinformation in the early project stages, and increasingly fine-grained information in later stages. Consequently, COCOMO IIdoes not produce point estimates of software cost and effort, but rather range estimates tied to the degree of Definition of theestimation inputs.