Presentation is loading. Please wait.

Presentation is loading. Please wait.

COCOMO II Overview LiGuo Huang Computer Science and Engineering

Similar presentations


Presentation on theme: "COCOMO II Overview LiGuo Huang Computer Science and Engineering"— Presentation transcript:

1 COCOMO II Overview LiGuo Huang Computer Science and Engineering
Southern Methodist University 1

2 Agenda COCOMO Introduction Basic Estimation Formulas Cost Factors
Reuse Model Sizing Software Maintenance Effort COCOMO Tool Demo Data Collection 2

3 COCOMO Background COCOMO - the “COnstructive COst MOdel”
COCOMO II is the update to COCOMO 1981 ongoing research with annual calibrations made available Originally developed by Dr. Barry Boehm and published in 1981 book Software Engineering Economics COCOMO II described in new book Software Cost Estimation with COCOMO II COCOMO can be used as a framework for cost estimation and related activities 3

4 COCOMO II Model Objectives
Provide accurate cost and schedule estimates for software projects Enable organizations to easily recalibrate, tailor, or extend COCOMO II to better fit their unique situations Provide careful, easy-to-understand definitions of the model’s inputs, outputs, and assumptions Provide a constructive model Provide a normative model Provide a evolving model 4

5 COCOMO II Black Box Model
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

6 Software Estimation Accuracy
Effect of uncertainties over time 4x 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 6

7 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

8 COCOMO Uses for Software Decision Making
Making investment decisions and business-case analyses Setting project budgets and schedules Performing tradeoff analyses Cost risk management Development vs. reuse decisions Legacy software phaseout decisions Software reuse and product line decisions Process improvement decisions 8

9 Productivity Ranges COCOMO provides natural framework to identify high leverage productivity improvement factors and estimate their payoffs. 9

10 COCOMO Submodels Applications Composition Model: involves rapid development or prototyping efforts to resolve potential high-risk issues such as user interfaces, software/system interaction, performance, or technology maturity. sized with application points (weighted screen elements, reports and 3GL modules) Early Design model: explore alternative software/system architectures and concepts of operation sized with function points a coarse-grained set of 7 cost drivers Post-Architecture model: the actual development and maintenance of a software product source instructions and / or function points for sizing, with modifiers for reuse and software breakage; a set of 17 multiplicative cost drivers; and a set of 5 factors determining the project's scaling exponent 10

11 Agenda COCOMO Introduction Basic Estimation Formulas Cost Factors
Reuse Model Sizing Software Maintenance Effort COCOMO Tool Demo Data Collection 11 11 11

12 COCOMO Nominal-schedule Effort Formulation
# of cost drivers PMNS(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 drivers; where, B= 0.91, SFj is a weighting factor for jth 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. # of cost drivers = 16 (exclude SCED) Automated translation effects are not included 12

13 COCOMO Effort Formulation
# of cost drivers PM(person-months) = A× (Size)E× P EMi i =1 # of cost drivers = 17 (including SCED) 13

14 Diseconomy of Scale Nonlinear relationship when exponent > 1 E 14

15 COCOMO Schedule Formulation
TDEV (months) = C× (PMNS)F×(SCED%/100) Where: TDEV is the schedule estimate of 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) PMNS is the estimated person-months excluding the SCED effort multiplier where D = 0.28, B = 0.91 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. 15

16 Multiple Module Effort Estimation
Sum the sizes for all components: Apply the project-level drivers, the Scale Factors and the SCED to the aggregated size to derive the overall basic effort for the total project: Determine each component’s basic effort: Apply the component-level cost drivers (excluding SCED) to each component’s basic effort: Sum each component’s effort: Schedule is estimated by repeating steps 2 to 5 without SCED used in step 2. Then use the schedule estimating formula. 16 16 16

17 Coverage of Different Processes
COCOMO II provides a framework for tailoring the model to any desired process Original COCOMO was predicated on the waterfall process single-pass, sequential progression of requirements, design, code, test Modern processes are concurrent, iterative, incremental, and cyclic e.g. Rational Unified Process (RUP), the USC Model-Based Architecting and Software Engineering (MBASE) process Effort and schedule are distributed among different phases and activities per work breakdown structure of chosen process 17

18 Common Process Anchor Points
Anchor points are common process milestones around which cost and schedule budgets are organized COCOMO II submodels address different development stages anchored by these generic milestones: Life Cycle Objectives (LCO) inception: establishing a sound business case Life Cycle Architecture (LCA) elaboration: commit to a single architecture and elaborate it to cover all major risk sources Initial Operational Capability (IOC) construction: commit to transition and support operations 18

19 RUP Phase Distributions
Effort % Schedule % Inception 5 10 Elaboration 20 30 Construction 65 50 Transition 10 10 COCOMO Total 100 100 Project Total 100 100 19

20 Waterfall Phase Distributions
Effort % Schedule % Plans & rqts 7 20 Product Design 17 26 Programming 58 48 Integrate and Test 25 26 Transition 12 12.5 COCOMO Total 100 100 Project Total 119 132.5 20

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

22 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. 22

23 COCOMO Tailoring and Enhancements
Calibrate effort equations to organizational experience USC COCOMO has a calibration capability Consolidate or eliminate redundant cost driver attributes Add cost drivers applicable to your organization Account for systems engineering, hardware and software integration 23

24 Agenda COCOMO Introduction Basic Estimation Formulas Cost Factors
Reuse Model Sizing Software Maintenance Effort COCOMO Tool Demo Data Collection 24 24 24

25 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 May be difficult to quantify, but better than ignoring important project factors (e.g. basic vs. intermediate accuracies) 25

26 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 26

27 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) 27

28 Example Cost Driver - 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? 28

29 Example Effort Multiplier Values for RELY
0.8 0.9 1.0 1.1 1.2 1.3 Slight inconvenience Low, easily recoverable loss Moderate recoverable loss High Financial Loss Loss of Human Life Defect Impact Commercial quality leader 1.10 In-house support software Commercial cost leader 0.92 0.82 Safety-critical 1.26 Relative Cost/Source Instruction High RELY Rating Very High Nominal Low Very Low 12 22 34 54 Added Testing Time (%) Early beta-test 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 85% more than a very low reliability system (1.26/.82=1.54) 29

30 Scale Factors Sum scale factors Wi across all of the factors to determine a scale exponent, E, using E = S Wi 30

31 Precedentedness (PREC) and Development Flexibility (FLEX)
Elaboration of the PREC and FLEX rating scales: 31

32 Architecture / Risk Resolution (RESL)
Use a subjective weighted average of the characteristics: 32

33 Team Cohesion (TEAM) Use a subjective weighted average of the characteristics to account for project turbulence and entropy due to difficulties in synchronizing the project's stakeholders. Stakeholders include users, customers, developers, maintainers, interfacers, and others 33

34 Process Maturity (PMAT)
Two methods based on the Software Engineering Institute's Capability Maturity Model (CMM) Method 1: Overall Maturity Level (CMM Level 1 through 5) Method 2: Key Process Areas (see next slide) 34

35 Key Process Areas Decide the percentage of compliance for each of the KPAs as determined by a judgement-based averaging across the goals for all 18 Key Process Areas. 35

36 Cost Drivers Product Factors Platform Factors Personnel Factors
Project Factors 36

37 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 37

38 Product Factors (cont.)
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): 38

39 Product Factors (cont.)
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 39

40 Product Factors (cont.)
Module Complexity Ratings vs. Type of Module Use a subjective weighted average of the attributes, weighted by their relative product importance. 40

41 Product Factors (cont.)
Module Complexity Ratings vs. Type of Module Use a subjective weighted average of the attributes, weighted by their relative product importance. 41

42 Product Factors (cont.)
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. 42

43 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. 43

44 Platform Factors (cont.)
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). 44

45 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. 45

46 Personnel Factors (cont.)
Applications Experience (APEX) Assess the project team's equivalent level of experience with this type of application. Platform Experience (PLEX) Assess the project team's equivalent level of experience with this platform including the OS, graphical user interface, database, networking, and distributed middleware. 46

47 Personnel Factors (cont.)
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. 47

48 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. 48

49 Project Factors (cont.)
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. 49

50 Cost Factor Rating Whenever an assessment of a cost driver is between the rating levels: always round to the lower rating e.g. if a cost driver rating is between High and Very High, then select High. 50

51 Cost Driver Rating Level Summary
51

52 Cost Driver Rating Level Summary (cont.)
52

53 Dependencies of Cost Factor Ratings
RUSE, RELY and DOCU: RELY should be rated at least one level below the RUSE rating DOCU rating should be at least Nominal for Nominal and High RUSE ratings; at least High for Very High and Extra High RUSE ratings 53

54 Agenda COCOMO Introduction Basic Estimation Formulas Cost Factors
Reuse Model Sizing Software Maintenance Effort COCOMO Tool Demo Data Collection 54 54 54

55 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. 55

56 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 to the cost of understanding the software to be modified, and the relative cost of interface checking. 56

57 COCOMO Reuse Model A nonlinear estimation model to convert adapted (reused or modified) software into equivalent size of new software: 57

58 COCOMO Reuse Model (cont.)
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). 58

59 Assessment and Assimilation Increment (AA)
59

60 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). 60

61 Programmer Unfamiliarity (UNFM)
Only applies to modified software 61

62 Commercial Off-the-Shelf (COTS) Software
Current best approach is to treat as reuse A COTS cost model is under development Calculate effective size from external interface files and breakage Have identified candidate COTS cost drivers 62

63 Reuse Parameter Guidelines
63

64 Automatically Translated Code
Reengineering vs. conversion Automated translation is considered separate activity from development Add the term (1- AT/100) to the equation for ESLOC 64 64 64

65 Agenda COCOMO Introduction Basic Estimation Formulas Cost Factors
Reuse Model Sizing Software Maintenance Effort COCOMO Tool Demo Data Collection 65 65 65

66 Lines of Code Code size is expressed in KSLOC
Source Lines of Code (SLOCs) = logical source statements Logical source statements = data declarations + executable statements Executable statements cause runtime actions Declaration statements are nonexecutable statements that affect an assembler's or compiler's interpretation of other program elements 66

67 Lines of Code Counting Rules
Standard definition for counting lines Based on SEI definition checklist from CMU/SEI-92-TR-20 Modified for COCOMO II When a line or statement contains more than one type, classify it as the type with the highest precedence. Order of precedence is in ascending order 67

68 Lines of Code Counting Rules (cont.)
(See COCOMO II book for remaining details) 68

69 Counting with Function Points
Used in both the Early Design and the Post-Architecture models. Based on the amount of functionality in a software product and project factors using information available early in the project life cycle. Quantify the information processing functionality with the following user function types: 69

70 Counting with Function Points (cont.)
External Input (Inputs) Count each unique user data or user control input type that both Enters the external boundary of the software system being measured Adds or changes data in a logical internal file. External Output (Outputs) Count each unique user data or control output type that leaves the external boundary of the software system being measured. 70

71 Counting with Function Points (cont.)
Internal Logical File (Files) Count each major logical group of user data or control information in the software system as a logical internal file type. Include each logical file (e.g., each logical group of data) that is generated, used, or maintained by the software system. External Interface Files (Interfaces) Files passed or shared between software systems should be counted as external interface file types within each system. 71

72 Counting with Function Points (cont.)
External Inquiry (Queries) Count each unique input-output combination, where an input causes and generates an immediate output, as an external inquiry type. Each instance of the user function types is then classified by complexity level. The complexity levels determine a set of weights, which are applied to their corresponding function counts to determine the Unadjusted Function Points (UFP) quantity. 72

73 Counting with Function Points (cont.)
The usual Function Point procedure involves assessing the degree of influence of fourteen application characteristics on the software project. The contributions of these characteristics are inconsistent with COCOMO experience, so COCOMO II uses Unadjusted Function Points for sizing. 73

74 Unadjusted Function Points Counting Procedure
Step 1 - Determine function counts by type The unadjusted function counts should be counted by a lead technical person based on information in the software requirements and design documents. The number of each of the five user function types should be counted Internal Logical File (ILF) Note: The word file refers to a logically related group of data and not the physical implementation of those groups of data. External Interface File (EIF) External Input (EI) External Output (EO) External Inquiry (EQ)) 74

75 Unadjusted Function Points Counting Procedure (cont.)
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 referenced. Use the following scheme: 75

76 Unadjusted Function Points Counting Procedure (cont.)
Step 3 - Apply complexity weights Weight the number in each cell using the following scheme. The weights reflect the relative value of the function to the user. Step 4 - Compute Unadjusted Function Points Add all the weighted functions counts to get one number, the Unadjusted Function Points. 76

77 Requirement Volatility (REVL)
REVL: adjust the effective size cause by requirements evolution and volatility SizeD: reuse-equivalent of the delivered software 77 77

78 Sizing Software Maintenance
(Size)M = [(Base Code Size) * MCF] * MAF Maintenance Change Factor (MCF): (Size)M = (Size Added + Size Modified) * MAF Maintenance Adjustment Factor (MAF): 78 78

79 Agenda COCOMO Introduction Basic Estimation Formulas Cost Factors
Reuse Model Sizing Software Maintenance Effort COCOMO Tool Demo Data Collection 79 79 79

80 Software Maintenance SCED cost driver is not used in maintenance effort estimation RUSE cost driver is not used in maintenance effort estimation RELY cost driver has a different set of effort multipliers: See Table 2.41 in COCOMO II book Apply the scaling exponent E to the number of changed KSLOC (added and modified, not deleted) rather than the total legacy system: The average maintenance staffing level: FSPM = PMM /TM May use any desired maintenance activity duration TM 80 80

81 COCOMO II Demo 81

82 Agenda COCOMO Introduction Basic Estimation Formulas Cost Factors
Reuse Model Sizing Software Maintenance Effort COCOMO Tool Demo Data Collection 82 82 82

83 Cost Driver Ratings Profile
Need to rate cost drivers in a consistent and objective fashion within an organization. Cost driver ratings profile: Graphical depiction of historical ratings to be used as a reference baseline to assist in rating new projects Used in conjunction with estimating tools to gauge new projects against past ones objectively 83

84 Example Cost Driver Ratings Profile
84

85 Techniques to Generate Cost Driver Ratings Profile
Single person Time efficient, but may impose bias and person may be unfamiliar with all projects Group Converge ratings in a single meeting (dominant individual problem) Wideband Delphi technique (longer calendar time, but minimizes biases). See Software Engineering Economics, p. 335 85

86 COCOMO Dataset Cost Metrics
Size (SLOCS, function points) Effort (Person-hours) Schedule (Months) Cost drivers Scale drivers Reuse parameters 86

87 Recommended Project Cost Data
For each project, report the following at the end of each month and for each release: SIZE Provide total system size developed to date, and report new code size and reused / modified code size separately. This can be at a project level or lower level as the data supports and is reasonable. For languages not supported by tools such as assembly code, report the number of physical lines separately for each language. EFFORT Provide cumulative staff-hours spent on software development per project at the same granularity as the size components. 87

88 Recommended Project Cost Data (cont.)
COST DRIVERS AND SCALE DRIVERS For each reported size component, supply the cost driver ratings for product, platform, personnel and project attributes. For each reported size component, supply scale driver ratings. REUSE PARAMETERS For each component of reused/modified code, supply reuse parameters AA, SU, UNFM, DM, CM and IM. See Appendix C in COCOMO II book for additional data items Post-mortem reports are highly recommended 88

89 Effort Staff-Hours Definition
Standard definition Based on SEI definition checklist form CMU/SEI-92-TR-21 Modified for COCOMO II Does not include unpaid overtime, production and deployment activities, customer training activities Includes all personnel except level 3 or higher software management (i.e. directors or above who timeshare among projects) Person-month is defined as 152 hours 89

90 Further Information 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 B. Boehm, Software Engineering Economics. Englewood Cliffs, NJ, Prentice-Hall, 1981 90


Download ppt "COCOMO II Overview LiGuo Huang Computer Science and Engineering"

Similar presentations


Ads by Google