Cost Estimation with COCOMO II Barry Boehm CS 510, Fall 2016 Edited & presented by Jim Alstad Based on 2015 “v3”. Deleted next slide (“Outline”).

Software Cost Estimation Methods Cost estimation: prediction of both the person-effort and elapsed time of a project Methods: Algorithmic Expert judgement Estimation by analogy Parkinsonian Best approach is a combination of methods compare and iterate estimates, reconcile differences COCOMO - the “COnstructive COst MOdel” COCOMO II is the update to Dr. Barry Boehm’s COCOMO 1981 COCOMO is the most widely used, thoroughly documented and calibrated cost model Price-to-win Top-down Bottom-up ©USC-CSSE

Software Estimation Accuracy 4x Effect of uncertainties over time 2x Relative Size Range x 0.5x Initial Operating Capability Operational Concept Life Cycle Objectives Life Cycle Architecture 0.25x Feasibility Plans/Rqts. Design Develop and Test Phases and Milestones ©USC-CSSE

COCOMO Black Box Model COCOMO II product size estimate development, maintenance cost and schedule estimates product, process, platform, and personnel attributes COCOMO II reuse, maintenance, and increment parameters cost, schedule distribution by phase, activity, increment On recalibration: “not considered further in this course”. organizational project data recalibration to organizational data ©USC-CSSE

Major COCOMO II Features Multi-model coverage of different development sectors Variable-granularity cost model inputs Flexibility in size inputs SLOCS function points application points other (use cases ...?) Range vs. point estimates per funnel chart ©USC-CSSE

COCOMO Effort Formulation # of cost drivers Effort (person-months) = A (Size)E P EMi i=1 Where: A is a constant derived from historical project data (currently A = 2.94 in COCOMOII.2000) Size is in KSLOC (thousand source lines of code), or converted from function points or object points E is an exponent for the diseconomy of scale dependent on five additive scale factors according to b = .91 + .01*SSFi, where SFi is a weighting factor for ith scale driver EMi is the effort multiplier for the ith cost driver. The geometric product results in an overall effort adjustment factor to the nominal effort. Automated translation effects are not included “scale drivers” changed to “scale factors” by Jim. After going over slide, show where material is in EP-0. ©USC-CSSE

Diseconomy of Scale Nonlinear relationship when exponent > 1 ©USC-CSSE

COCOMO Schedule Formulation Where: Schedule is the calendar time in months from the requirements baseline to acceptance C is a constant derived from historical project data (currently C = 3.67 in COCOMOII.2000) Effort is the estimated person-months excluding the SCED effort multiplier E is the exponent in the effort equation SCED% is the compression / expansion percentage in the SCED cost driver This is the COCOMOII.2000 calibration Formula can vary to reflect process models for reusable and COTS software, and the effects of application composition capabilities. Schedule (months) = C (Effort)(.28+0.2(E-0.91)) x SCED%/100 ©USC-CSSE

Relations to ICSM-Sw/MBASE*/RUP Anchor Point Milestones Application Compos. Inception Elaboration, Construction Transition IOC COCOMO II estimates SRR PDR Slide moved (to precede next slide)—was 3 slides earlier. Waterfall Rqts. System Devel. Prod. Des. Development Inception Phase Elaboration Construction Transition LCA LCO *MBASE: Model-Based (System) Architecting and Software Engineering ©USC-CSSE 9

MBASE Phase Distributions see COCOMO II book for complete phase/activity distributions Phase Effort % Schedule % Inception 6 12.5 Elaboration 24 37.5 Construction 76 62.5 Transition 12 12.5 COCOMO Total 100 100 Project Total 118 125 ©USC-CSSE

COCOMO II Output Ranges COCOMO II provides one standard deviation optimistic and pessimistic estimates. Reflect sources of input uncertainties per funnel chart (“cone of uncertainty”). Apply to effort or schedule for all of the stage models. Represent 80% confidence limits: below optimistic or pessimistic estimates 10% of the time. “Cone of uncertainty” added by Jim. ©USC-CSSE

Reused and Modified Software Effort for adapted software (reused or modified) is not the same as for new software. Approach: convert adapted software into equivalent size of new software. ©USC-CSSE

Nonlinear Reuse Effects The reuse cost function does not go through the origin due to a cost of about 5% for assessing, selecting, and assimilating the reusable component. Small modifications generate disproportionately large costs primarily due the cost of understanding the software to be modified, and the relative cost of interface checking. ©USC-CSSE

COCOMO Reuse Model A nonlinear estimation model to convert adapted (reused or modified) software into equivalent size of new software: Bounce back and forth with next slide. ©USC-CSSE

COCOMO Reuse Model cont’d ASLOC - Adapted Source Lines of Code ESLOC - Equivalent Source Lines of Code AAF - Adaptation Adjustment Factor DM - Percent Design Modified. The percentage of the adapted software's design which is modified in order to adapt it to the new objectives and environment. CM - Percent Code Modified. The percentage of the adapted software's code which is modified in order to adapt it to the new objectives and environment. IM - Percent of Integration Required for Modified Software. The percentage of effort required to integrate the adapted software into an overall product and to test the resulting product as compared to the normal amount of integration and test effort for software of comparable size. AA - Assessment and Assimilation effort needed to determine whether a fully-reused software module is appropriate to the application, and to integrate its description into the overall product description. See table. SU - Software Understanding. Effort increment as a percentage. Only used when code is modified (zero when DM=0 and CM=0). See table. UNFM - Unfamiliarity. The programmer's relative unfamiliarity with the software which is applied multiplicatively to the software understanding effort increment (0-1). ©USC-CSSE ©USC-CSSE 15

Assessment and Assimilation Increment (AA) ©USC-CSSE ©USC-CSSE 16

Software Understanding Increment (SU) Take the subjective average of the three categories. Do not use SU if the component is being used unmodified (DM=0 and CM =0). ©USC-CSSE

Programmer Unfamiliarity (UNFM) Only applies to modified software ©USC-CSSE

Cost Factors Significant factors of development cost: scale factors are sources of exponential effort variation cost drivers are sources of linear effort variation product, platform, personnel and project attributes effort multipliers associated with cost driver ratings Defined to be as objective as possible Each factor is rated between very low and very high per rating guidelines relevant effort multipliers adjust the cost up or down “scale drivers” changed to “scale factors” by Jim. May be difficult to quantify, but better than ignoring important project factors (e.g. basic vs. intermediate accuracies) ©USC-CSSE

Scale Factors Precedentedness (PREC) Development Flexibility (FLEX) Degree to which system is new and past experience applies Development Flexibility (FLEX) Need to conform with specified requirements Architecture/Risk Resolution (RESL) Degree of design thoroughness and risk elimination Team Cohesion (TEAM) Need to synchronize stakeholders and minimize conflict Process Maturity (PMAT) SEI CMM process maturity rating ©USC-CSSE

Scale Factor Rating ©USC-CSSE

Cost Drivers Product Factors Platform Factors Personnel factors Reliability (RELY) Data (DATA) Complexity (CPLX) Reusability (RUSE) Documentation (DOCU) Platform Factors Time constraint (TIME) Storage constraint (STOR) Platform volatility (PVOL) Personnel factors Analyst capability (ACAP) Program capability (PCAP) Applications experience (APEX) Platform experience (PLEX) Language and tool experience (LTEX) Personnel continuity (PCON) Project Factors Software tools (TOOL) Multisite development (SITE) Required schedule (SCED) ©USC-CSSE 22

Product Factors Required Software Reliability (RELY) Measures the extent to which the software must perform its intended function over a period of time. Ask: what is the effect of a software failure ©USC-CSSE 23

Example Effort Multiplier Values for RELY 1.26 1.10 Very Low Low Nominal High Very High 1.0 Slight Inconvenience Low, Easily Recoverable Losses Moderate, Easily Recoverable Losses High Financial Loss Risk to Human Life 0.92 0.82 E.g. a highly reliable system costs 26% more than a nominally reliable system 1.26/1.0=1.26) or a highly reliable system costs 54% more than a very low reliability system (1.26/.82=1.54) ©USC-CSSE 24

Product Factors cont’d Data Base Size (DATA) Captures the effect large data requirements have on development to generate test data that will be used to exercise the program Calculate the data/program size ratio (D/P): ©USC-CSSE 25

Product Factors cont’d Product Complexity (CPLX) Complexity is divided into five areas: control operations, computational operations, device-dependent operations, data management operations, and user interface management operations. Select the area or combination of areas that characterize the product or a sub-system of the product. See the module complexity table, next several slides ©USC-CSSE 26

Product Factors cont’d Module Complexity Ratings vs. Type of Module Use a subjective weighted average of the attributes, weighted by their relative product importance. ©USC-CSSE 27

Product Factors cont’d Module Complexity Ratings vs. Type of Module Use a subjective weighted average of the attributes, weighted by their relative product importance. ©USC-CSSE 28

Product Factors cont’d Required Reusability (RUSE) Accounts for the additional effort needed to construct components intended for reuse. Documentation match to life-cycle needs (DOCU) What is the suitability of the project's documentation to its life-cycle needs. ©USC-CSSE 29

Platform Factors Platform Execution Time Constraint (TIME) Refers to the target-machine complex of hardware and infrastructure software (previously called the virtual machine). Execution Time Constraint (TIME) Measures the constraint imposed upon a system in terms of the percentage of available execution time expected to be used by the system. ©USC-CSSE 30

Platform Factors cont’d Main Storage Constraint (STOR) Measures the degree of main storage constraint imposed on a software system or subsystem. Platform Volatility (PVOL) Assesses the volatility of the platform (the complex of hardware and software the software product calls on to perform its tasks). ©USC-CSSE 31

Personnel Factors Analyst Capability (ACAP) Analysts work on requirements, high level design and detailed design. Consider analysis and design ability, efficiency and thoroughness, and the ability to communicate and cooperate. Programmer Capability (PCAP) Evaluate the capability of the programmers as a team rather than as individuals. Consider ability, efficiency and thoroughness, and the ability to communicate and cooperate. ©USC-CSSE 32

Personnel Factors cont’d Applications Experience (AEXP) Assess the project team's equivalent level of experience with this type of application. Platform Experience (PEXP) Assess the project team's equivalent level of experience with this platform including the OS, graphical user interface, database, networking, and distributed middleware. ©USC-CSSE 33

Personnel Factors cont’d Language and Tool Experience (LTEX) Measures the level of programming language and software tool experience of the project team. Personnel Continuity (PCON) The scale for PCON is in terms of the project's annual personnel turnover. ©USC-CSSE 34

Project Factors Use of Software Tools (TOOL) Assess the usage of software tools used to develop the product in terms of their capabilities and maturity. ©USC-CSSE ©USC-CSSE 35

Project Factors cont’d Multisite Development (SITE) Assess and average two factors: site collocation and communication support. Required Development Schedule (SCED) Measure the imposed schedule constraint in terms of the percentage of schedule stretch-out or acceleration with respect to a nominal schedule for the project. ©USC-CSSE 36

Estimating with a Non-Nominal Schedule (a Complicated Case) Start by computing nominal schedule (“NS”) effort and schedule, taking SCED to be Nominal (100%): Compute EffortNS = A (Size)E P EMi Compute TDEVNS = C (Effort)(.28+0.2(E-0.91)) Now compute actual effort & schedule: Compute SCED percentage = planned schedule / TDEVNS Applying SCED (see section 2.3.2.1), calculate Effort = A (Size)E P EMi Double check schedule by calculating TDEV = C (Effort)(.28+0.2(E-0.91)) x SCED%/100 See also sections 2.1.2 & 2.4. Jim added slide. Use example of TDEVNS = 10 months, planned schedule = 8.5 months. Show Table 2.34 from EP-2 ©USC-CSSE

Demos COCOMO II 2000.3 (standalone, in C) See http://greenbay.usc.edu/csci577/fall2010/site/tools/index.html http://greenbay.usc.edu/csci577/tools/cocomo/COCOMOII_2000_3.exe COCOMO II 2000.3 (web-Based) See http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html for http://csse.usc.edu/tools/COCOMOII.php NOTE: no separate modules ©USC-CSSE

Fast (dangerous?) Function Point Sizing Count number of files of different types File: grouping of data elements handled similarly by software External Input EI: files entering software system External Output EO: files exiting software system Internal Logical IL: internal files used by software system External Interface EIF: files passed/shared between software systems External Query EQ: input and immediate output response Use Average complexity weights for all files FP = 4 * EI + 5 * EO + 10 * IL + 7 * EIF + 4 * EQ USC COCOMO II FP = 4(12) + 5(7) + 10(7) + 0 + 0 = 153 Java, C++ SLOC = 153(50) = 7650 SLOC HTML, Power Builder = 153(20) = 3060 SLOC Can use averages for mixes of languages See COCOMO II book for detailed function point procedure Two following slides (directed at CS 577) deleted by Jim. At end of lecture, go to D2L Discussion “COCOMO: Assumptions for 510”. ©USC-CSSE