UNIT-25 COCOMO [CONSTRUCTIVE COST MODEL]

1. UNIT-25COCOMO [CONSTRUCTIVE COST MODEL] UNIT STRUCTURE 25.1 Introduction to COCOMO 25.2 COCOMO 25.3 Basic Effort and Schedule Estimating Formulas 25.4 Assumptions 25.5 Life-Cycle Description 25.6 Software work breakdown structure 25.7 A Typical COCOMO Project Profile 25.8 EXAMPLE

2. INTRODUCTION TO THE UNIT This chapter will cover the software cost estimation of COCOMO model. This model has the components of basic effort and schedule. A case study is also discussed in this chapter. UNIT LEARNING OBJECTIVES: After reading this chapter the user will estimate the software products using COCOMO by the following components: COCOMO Basic Effort and Schedule Estimating Formulas Assumptions Life-Cycle Description Software work breakdown structure A Typical COCOMO Project Profile

3. 25.1 Introduction to COCOMO One popular, open, and well-documented software cost model is the Constructive Cost Model (COCOMO) developed by Barry Boehm. The evolution of COCOMO provides an interesting window for observing the evolution of software engineering economics over the fast 20 years. The COCOMO estimating equations follow this simple form: Effort = C1 EAF (size)p1 Time = C2 (Effort)p2 Where: Effort = number of staff-months C1 = a constant scaling coefficient for effort EAF = an effort adjustment factor that characterizes the domain, personnel, environment, and tools used to produce the artifacts of the process Size = size of the end product (in human-generated source code), measured by the number of delivered source instructions (DSI) required to develop the required functionality P1 = an exponent that characterizes the economics of scale inherent in the process used to produce the end product, in particular the ability of the process to avoid non-value-adding activities (rework, bureaucratic delays, communication overhead) Time = total number of months C2 = a constant scaling coefficient for schedule P2 = an exponent that characterizes the inherent inertia and parallelism in managing a software development effort

4. 25.2 COCOMO The original COCOMO model [Boehm, 1981] was one of the minor breakthroughs in software engineering during the early 1980s. It was breakthrough partly because of its inherent technology contribution but primarily because it provided a well-defined framework for communication of trade-offs and priorities associated with software cost and schedule management. A huge benefit offered by the COCOMO model was the ability to make an estimate, reference a credible basis for it, reason about its strengths and weaknesses, and negotiate with the stakeholders. The original COCOMO model was based on a database of 56 projects. Its three modes reflected the differences in process across a range of software domain. These modes were identified as organic, semidetached, and embedded. Organic mode projects were characterized by in-house, less-complex developments that had flexible processes. Features, qualities, cost, and schedule could be freely changed with minimal overhead. Embedded mode systems represented typical defense community projects: Complexity, reliability, and real-time issues were dominant, and the contractual nature of the business resulted in a highly rigorous process. Features, qualities, costs, and schedules were tightly controlled, and changes required approvals by many stakeholders. Semidetached mode projects represented something in between.

5. 25.3 Basic Effort and Schedule Estimating Formulas These were the original COCOMO cost estimation relationships: Organic mode Effort = 3.2 EAF (size)1.05 Time (in months) = 2.5 (Effort)0.38 Semidetached mode Effort = 3.0 EAF (size)1.12 Time (in months) = 2.5 (Effort)0.35 Embedded mode Effort = 2.8 EAF (size)1.2 Time (in months) = 2.5 (Effort)0.32 Where: Effort = number staff-months EAF = product of 15 effort adjustment factors Size = number of delivered source instructions (in units of thousands of lines of code) The effort adjustment factor (EAF) multiplier represents the combined effects of multiple parameters. These parameters allow the project to be characterized and normalized against the projects in the COCOMO database. Each parameter is assessed as very low, low, normal, high, or very high. The effect of each parameter setting is a multiplier that typically ranges from 0.5 to 1.5. The product of these 15 effects is used as the coefficient in the cost equation.

7. 25.4 Assumptions Several assumptions are inherent in the COCOMO formulas. Delivered source instructions include all (noncomment) lines of computer- processed code. The development life cycle starts at the beginning of product design and ends with acceptance test at the conclusion of integration and rest phase. The activities include only direct-charged project efforts and exclude typical overhead activities such as administration support, facilities, and capital equipment. A staff-month consists of 152 hours. The project will be well managed. The project will experience stable requirements. 25.5 Life-Cycle Description The COCOMO life cycle includes five basic phases: Plan and requirements. Product design. Detailed design. Code and unit test. Integration and test. COCOMO provides recommendation for distributing the effort and schedule across the basic phases of conventional waterfall model. These recommendation vary some what with mode and scale; The table below provides a typical profile for a large, embedded mode project. COCOMO estimates the effort and schedule to develop the solution. Formulating the problem is estimated as an additional percentage over and above the development effort and schedule.

9. 25.6 Software work breakdown structure Most conventional work breakdown structures are organized around the product subsystem at the higher level and around the detailed at the lower levels. The standard activities estimated by COCOMO and included in software WBS are requirement analysis, product design, programming, test planning, verification, project office functions, configuration management and quality assurance, and manual. COCOMO also recommends a top-level distribution of effort across the activities of the WBS. Again, these profiles are dependent on mode and scale. The table below shows the expenditure profile among the activities in the WBS for large, embedded mode project. An important caveat is that in COCOMO, the �programming� activity includes detailed design, coding, unit testing and integration.

11. 25.7 A Typical COCOMO Project Profile The following discussion focuses on a specific example project in order to illuminate some of the project planning implication. Assume a large, 100000 source-line (100-KDSI) mission-critical system built under contract for a government agency. Figure B1 illustrates the COCOMO � estimated profile for this project. COCOMO would estimate 900 staff-month for development plus 72 staff-month for requirement specification for this project. The schedule required would be 22 month from initiation of design through test, plus 8 month for requirements. 25.8 EXAMPLE: 100,000-SLOC project that require 972 staff-month of effort and 30 month of schedule Effort = 2.8 EAF (KDSI)1.2 = 2.8 (1.28) (100)1.2 = 900 Staff-month of development effort + 72 staff-month for plans, requirements = 972 staff-months of total effort

13. Time =2.5 (Effort)0.32 =2.5 (900)0.32 =22 months of development schedule + 8 months for plans, requirements =30 months

17. The COCOMO life-cycle schedule distribution and activity vary depending on the scale, domain, and business context. The schedule phases and activity mix illustrated here are typical. Summary This chapter has covered the detailed estimation of software products using COCOMO model. The details is shown in the form of a case study for further understanding. Review Questions What is COCOMO? What are the formula�s used in COCOMO? How will you calculate the Basic Effort and Schedule Estimating for COCOMO? List down the Assumptions of COCOMO? Explain the Life-Cycle Descriptions used in COCOMO? What do you understand by Software work breakdown structure? Explain the case study which is given in the chapter? References Stephen Kan, �Software Quality Metrics and Models�, Pearson Education, Asia, New Delhi 2000. Walker Royce, Software Project Management� � A unified framework, Pearson Education Asia, New Delhi 2000. Alan Gillies, �Software Quality � Theory & Management�, Thomson Learning, 2003.