1. University of Southern California Center for Systems and Software Engineering Cost Estimation with COCOMO II Barry Boehm CS 510, Fall 2015 v3: Slide 10 edited by Jim Alstad

2. University of Southern California Center for Systems and Software Engineering ©USC-CSSE2 Outline Model Overview Model Reinterpretation for CS 577

3. University of Southern California Center for Systems and Software Engineering ©USC-CSSE3 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

4. University of Southern California Center for Systems and Software Engineering ©USC-CSSE4 Effect of uncertainties over time Software Estimation Accuracy FeasibilityPlans/Rqts.DesignDevelop and Test Phases and Milestones Relative Size Range Operational Concept Life Cycle Objectives Life Cycle Architecture Initial Operating Capability x 0.5x 0.25x 4x 2x

5. University of Southern California Center for Systems and Software Engineering ©USC-CSSE5 COCOMO Black Box Model COCOMO II product size estimate product, process, platform, and personnel attributes reuse, maintenance, and increment parameters organizational project data development, maintenance cost and schedule estimates cost, schedule distribution by phase, activity, increment recalibration to organizational data

6. University of Southern California Center for Systems and Software Engineering ©USC-CSSE6 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

7. University of Southern California Center for Systems and Software Engineering ©USC-CSSE7 7 Relations to ICSM-Sw/MBASE*/RUP Anchor Point Milestones Application Compos. IOC System Devel. InceptionElaboration, ConstructionTransition Waterfall Rqts. Prod. Des. LCA Development LCO SRR PDR ElaborationInception Phase ConstructionTransition COCOMO II estimates *MBASE: Model-Based (System) Architecting and Software Engineering

8. University of Southern California Center for Systems and Software Engineering ©USC-CSSE8 COCOMO Effort Formulation # of cost drivers Effort (person-months) = A (Size) E  EM i 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 drivers according to b =.91 +.01*  SF i, where SF i is a weighting factor for i th scale driver –EM i is the effort multiplier for the i th cost driver. The geometric product results in an overall effort adjustment factor to the nominal effort. Automated translation effects are not included

9. University of Southern California Center for Systems and Software Engineering ©USC-CSSE9 Diseconomy of Scale Nonlinear relationship when exponent > 1

10. University of Southern California Center for Systems and Software Engineering ©USC-CSSE10 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

11. University of Southern California Center for Systems and Software Engineering ©USC-CSSE11 MBASE Phase Distributions 125118Project Total 100 COCOMO Total 12.512Transition 62.576Construction 37.524Elaboration 12.56Inception Schedule %Effort %Phase see COCOMO II book for complete phase/activity distributions

12. University of Southern California Center for Systems and Software Engineering ©USC-CSSE12 COCOMO II Output Ranges COCOMO II provides one standard deviation optimistic and pessimistic estimates. Reflect sources of input uncertainties per funnel chart. Apply to effort or schedule for all of the stage models. Represent 80% confidence limits: below optimistic or pessimistic estimates 10% of the time.

13. University of Southern California Center for Systems and Software Engineering ©USC-CSSE13 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.

14. University of Southern California Center for Systems and Software Engineering ©USC-CSSE14 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.

15. University of Southern California Center for Systems and Software Engineering ©USC-CSSE15 COCOMO Reuse Model A nonlinear estimation model to convert adapted (reused or modified) software into equivalent size of new software:

16. University of Southern California Center for Systems and Software Engineering ©USC-CSSE16 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-CSSE16

17. University of Southern California Center for Systems and Software Engineering ©USC-CSSE17 Assessment and Assimilation Increment (AA) ©USC-CSSE17

18. University of Southern California Center for Systems and Software Engineering ©USC-CSSE18 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).

19. University of Southern California Center for Systems and Software Engineering ©USC-CSSE19 Programmer Unfamiliarity (UNFM) Only applies to modified software

20. University of Southern California Center for Systems and Software Engineering ©USC-CSSE20 Cost Factors Significant factors of development cost: –scale drivers 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

21. University of Southern California Center for Systems and Software Engineering ©USC-CSSE21 Scale Factors Precedentedness (PREC) –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

22. University of Southern California Center for Systems and Software Engineering ©USC-CSSE22 Scale Factor Rating

23. University of Southern California Center for Systems and Software Engineering ©USC-CSSE23 Cost Drivers Product 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) 23

24. University of Southern California Center for Systems and Software Engineering ©USC-CSSE24 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 24

25. University of Southern California Center for Systems and Software Engineering ©USC-CSSE25 Example Effort Multiplier Values for RELY 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) 25 Very Low Low High Very High Slight Inconvenience Low, Easily Recoverable Losses High Financial Loss Risk to Human Life 1.10 0.82 0.92 1.26 1.0 Moderate, Easily Recoverable Losses Nominal

26. University of Southern California Center for Systems and Software Engineering ©USC-CSSE26 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): 26

27. University of Southern California Center for Systems and Software Engineering ©USC-CSSE27 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 27

28. University of Southern California Center for Systems and Software Engineering ©USC-CSSE28 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. 28

29. University of Southern California Center for Systems and Software Engineering ©USC-CSSE29 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. 29

30. University of Southern California Center for Systems and Software Engineering ©USC-CSSE30 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. 30

31. University of Southern California Center for Systems and Software Engineering ©USC-CSSE31 Platform Factors Platform –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. 31

32. University of Southern California Center for Systems and Software Engineering ©USC-CSSE32 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). 32

33. University of Southern California Center for Systems and Software Engineering ©USC-CSSE33 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. 33

34. University of Southern California Center for Systems and Software Engineering ©USC-CSSE34 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. 34

35. University of Southern California Center for Systems and Software Engineering ©USC-CSSE35 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. 35

36. University of Southern California Center for Systems and Software Engineering ©USC-CSSE36 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-CSSE36

37. University of Southern California Center for Systems and Software Engineering ©USC-CSSE37 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. 37

38. University of Southern California Center for Systems and Software Engineering ©USC-CSSE38 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

39. University of Southern California Center for Systems and Software Engineering ©USC-CSSE39 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

40. University of Southern California Center for Systems and Software Engineering ©USC-CSSE40 Using COCOMO II in CS 577 Begin with COCOMO II bottom-up team estimate –Source lines of code (SLOC) –Using adjustments to CS 577 below –Focus on 577b Construction phase Cross-check with estimate –Using Fast Function Point sizing –Effort by activity, rough 577b milestone plan Adjust, try to reconcile both estimates

41. University of Southern California Center for Systems and Software Engineering ©USC-CSSE41 COCOMO II Estimates for 577b Disregard COCOMO II (CII) schedule estimates Use COCOMO II effort estimates to determine how large a team needed for 12-week fixed schedule –Assuming 12 hours/week of dedicated effort per person –Assuming 10 of the 12 weeks fill COCOMO II Construction phase (72% of total effort estimate) –Assuming 100 hours/person-month for COCOMO estimates For 577b Construction phase, these are equivalent: –1 577b team member effort = (10 weeks)(12 hours/week) = 120 hrs –1.67*[est'd COCOMO II person month] = (1.67)(100 hours)(0.72) = 120 hrs So, one 577b team member effort = 1.67 CII person mon's And 6 577b team members’ effort = 6*1.67 = 10 CII person mon's – 5 on-campus students + 1 off-campus student Or, N/1.67 577b team members’ effort = N CII person