COCOMO II : MODEL FOR ESTIMATING SOFTWARE COST

  • Published on
    25-Nov-2014

  • View
    6

  • Download
    0

DESCRIPTION

This article introduces the reader to the constructive cost model (COCOMO) II a well known model used in software cost and schedule estimation. First, the background of the model is presented, tracing the history of COCOMO from its inception to the present time. We then briefly examine its current status. Next, we present a moderately-detailed architectural overview. Thereafter, advantages and disadvantages of making use of the model are described shortly. We then compare two research papers in the area and finally conclude with future work suggestions.

Transcript

COCOMO II : MODEL FOR ESTIMATING SOFTWARE COST

PRESENTED TO DR. BAHRAM KHALILI AS PART OF HONORS CREDIT CONTRACT

CSE 3310, FALL 2008, KAPIL VYAS, CSE, 1000502888i

TABLE OF CONTENTS1. ABSTRACT......................................................................................................3 2. HISTORY .........................................................................................................42.1 Boehm, Barry: ........................................................................................................................ 4 2.2 Cocomo Background: ............................................................................................................ 4

3

CURRENT STATUS ......................................................................................63.1 Available Computerized Editions of Cocomo II:..................................................................... 6

4. ARCHITECTURAL OVERVIEW ......................................................................74.1 Applications Compositional Model ......................................................................................... 7 4.2 Early Design and Post-Architecture Models .......................................................................... 8

5. PAPER COMPARISON .................................................................................105.1 Early Design Model: ............................................................................................................. 10 5.2 Post Architecture Model:...................................................................................................... 10 5.3 A Cross-Comparison Between The Two Models:................................................................ 10

6. ADVANTAGES AND DISADVANTAGES ......................................................126.1 Significant Aspects of Cocomo II: ........................................................................................ 12 6.2 What is Being Worked On? ................................................................................................. 12

7. CONCLUSION AND FUTUREWORK............................................................13 REFERENCES....................................................................................................14

1. AbstractThis article introduces the reader to the constructive cost model (COCOMO) II a well known model used in software cost and schedule estimation. First, the background of the model is presented, tracing the history of COCOMO from its inception to the present time. We then briefly examine its current status. Next, we present a moderately-detailed architectural overview. Thereafter, advantages and disadvantages of making use of the model are described shortly. We then compare two research papers in the area and finally conclude with future work suggestions.

2. History 2.1 BOEHM, BARRY:One of the most prominent contributions of Barry is the Constructive Cost Model (COCOMO) used in estimating Software cost. COCOMO II is a well known model used in software cost and schedule estimation. Barry Boehm is TRW professor of software engineering and Computer Science Department Director. He received his BA degree from Harvard in 1957 and his MS and PhD degrees from UCLA in 1961 and 1964, all in mathematics. His current research interest include software process modeling, software requirements engineering, software architectures, software metrics and cost models, software engineering environments, and knowledge-based software engineering. Besides his COCOMO contributions to the field, others are the Spiral Model of the software process, the Theory W (win-win) approach to software management and requirements determination, and two advanced software engineering environments: the TRW Software Productivity System and Quantum Leap Environment.

2.2 COCOMO BACKGROUND:Significant research on software cost modeling began with the extensive 1965 SDC study of the 104 attributes of 169 software projects (Nelson, 1966). This led to some useful partial models in the late 1960s and early 1970s. In the late 1970s, several sophisticated software cost estimating models developed in response to the demand for control of escalating software costs. The proprietary RCA PRICE-S model, now the PRICE-S model, was released in 1977 and was instantly successful (Park, 1988). A year later, Lawrence Putnams Quantitative Software management Company marketed the first edition of the proprietary Software Life Cycle Model (SLIM), which has also been successful (Putnam and Myers, 1992). Barry W. Boehm, then employed by TRW Corporation, was considering the same approach: to develop a proprietary algorithmic (or parametric) software cost model to be released to the public, much like PRICE-S and SLIM. However, Boehm (1981) decided to use a different approach; he wrote the book Software Engineering Economics, which completely described and explained COCOMO. COCOMO quickly became popular because it was not proprietary, free to use, and relatively easy to learn and operate. COCOMO users groups emerged throughout the world, and several computerized editions soon became available. As the years passed COCOMOs popularity increased but the model experienced difficulties in estimating software projects of the 1990s as a result of new practices such as non-sequential and rapid-development process models; reuse-driven approached involving commercial-off-the-shelf (COTS) packages, reengineering, applications composition , and application generation capabilities; object-oriented approaches supported by distributed middleware; software process maturity effects and process-driven quality estimation. There was a need to develop COCOMO II to meet the changing

needs of the 1990s and the twenty-first century. COCOMO II was an effort that was started to update software cost estimation models, such as the 1981 Constructive Cost Model and its 1987 Ada COCOMO (Boehm and Royce, 1987; Boehm, 1989) update. Every year the COCOMO Users Group meets at the University of Southern California chaired by Boehm who is the director of the Center of Software Engineering. At these meetings Boehm and the rest of the COCOMO II research team (in alphabetic order Chris Abts, Jongmoon Baik, A. Winsor Brown, Sunita Chulani, Brad Clark and others) usually unveil COCOMO enhancements, some of which are discussed later in this paper. Also, there are several computerized editions, some of which are discussed later in this paper.

3

Current StatusThe USC CSSE overlooks the progress of COCOMO II ever since it came into existence. Their website at http://csse.usc.edu/csse boasts around 42 industry and government affiliates who help them to keep current with the technology and economic trends through their annual workshops and collaborative projects. Their affiliates include Cisco, Boeing, IBM, Samsung, Microsoft, General Dynamics, DARPA, Motorola and Sun Microsystems among others. They also have courses wherein 5-student teams go from inception through to transition in 24 weeks, developing real-client e-service applications for campus (and some off-campus) organizations. They use a mix of industrial-grade tools (Rational Rose/Soda/Clear Case, MS Project, numerous Java and other development tools) and our own USC-developed tools (USC COCOMO II, Easy Win-Win) and the aforementioned methods. The website mentions of their upcoming 2009 CSSE-Annual Research Review at the USC Campus from March 16 to 19. The next event is International Forum on COCOMO and Systems/Software Cost Modeling on October 26 to 29 in Washington D.C. Based on these facts there is evidence that these models are heavily used in industry and there is on-going work to continuously improve the model while maintaining to the changing needs of the time.

3.1 AVAILABLE COMPUTERIZED EDITIONS OF COCOMO II:The three most widely used COCOMO II tools are Costar, Cost Xpert, and Estimate Professional. Costar is a commercial tool sold by Softstar Systems. It contains all COCOMO updates, from the COCOMO 81 to the Ada COCOMO and now COCOMO II, and provides many useful tables and graphs. This commercially available tool is the most widely COCOMO tool used. More information can be obtained athttp://www.softstarsystems.com

Cost Xpert is a commercial tool sold by Marotz, Inc. It supports seven different costing methodologies in addition to COCOMO II and Feature Points. More information of Cost Xpert can be found at http://www.marotz.com Estimate Professional is a tool sold by Software Productivity Centre, CA. It is a commercial management tool that combines the most well-known and reliable estimation models, COCOMO II and Putnams SLIM, with Monte Carlo simulation. For more information, please visit http://www.spc.ca.

4. Architectural OverviewThe COCOMO II models were developed to support the future software practices marketplace as described in (Boehm et al., 1995). The three main models [described in detail in the COCOMO II Model Definition Manual (University of Southern California, 1997, 2000) and summaries of which are presented below] are: 1. Applications Composition 2. Early Design 3. Post-Architecture 4.1 APPLICATIONS COMPOSITIONAL MODEL A rapidly increasing number of projects are being developed using Applications Composition (model) methods that rely on having an integrated computer-aided software engineering (ICASE) environment. In such environments, source lines of code (SLOC) and function points (FPs) are not a good measure of the software size due to their limitations of sizing systems developed using GUI builders and visual programming aids. The COCOMO II team found a highly attractive metric called Object Points, developed by (Banker et al., 1994) for estimation of ICASE-based financial applications. Object Points (OP) uses the number of screens, reports, and third-generation language (3GL) modules as basic sizing primitives. The function point convention of weighting these by complexity and adding them together to obtain an overall size metric, which they then adjusted for reuse, is used. The COCOMO II team adopted OPs counting rules with two changes: (1) added rating scales for determining a projects productivity rate in NOP/PM, where NOP stands for New Ops, in terms of the ICASE systems maturity and capability, and the developers experience and capability in using the ICase environment; and (2) changed the name from Object Points to Application Points, to avoid confusion with a number of sizing metrics for more conventional objectoriented applications. Figure 1 presents the baseline COCOMO II Application Point procedure for estimating the effort involved in Application Composition and prototyping projects. NOP: New Object Points (Object Point count adjusted for reuse) Srvr: number of server (mainframe or equivalent) data tables used in conjunction with the SCREEN or REPORT Clnt: number of client (personal workstation) data tables used in conjunction with the SCREEN or REPORT %reuse: the percentage of screens, reports, and 3GL modules reused from previous applications, prorated by degree of reuse. The Applications Composition model has been calibrated to the 19 data points from Banker et al. giving an accuracy of estimates within 30% of the

actuals less than 50% for the full sample. However, the percentage of estimates within a factor of 2 of the actuals is 89% for the full sample. This appears reasonable to associate a factor of 2 with the optimistic and pessimistic range limits for an Application Point estimate. The COCOMO II team has not been able to collect much further data on applications composition projects for calibration and hence classifies this model in its emerging extensions of COCOMO II.

4.2 EARLY DESIGN AND POST-ARCHITECTURE MODELS This subsection presents the Post-Architecture and Early Design models. The Post-Architecture model is a detailed model, and as the name suggests, it is used once the architecture of the system is well defined, namely, when the product is ready to develop and sustain a fielded system. Detailed information on cost driver inputs must be available so accurate cost estimates can be made. The Early Design model is a high level model that is used in the exploration of architectural alternatives or incremental development strategies. This level of detail is consistent with the general of estimation accuracy needed. The Post-Architecture and Early Design models use the same sizing approach and the same scale drivers. To simplify the flow of the discussion, these common modeling features will be presented first followed by a description of the Post-Architecture effort multipliers and then the Early Design effort multipliers. The effort equation for the Post-Architecture and Early Design models is as follows: PM = A * Size^(E) * Sum of product of EMi from i = 1 to n Where E = B + 0.01* sum of SFj from j =1 to 5 PM = effort in person-months A = baseline multiplicative constant B = baseline exponential constant EM = effort multiplier SF = scale factor For the Post-Architecture model, n = 17 and for the Early Design model, n = 7. The SFs are the same for both the models. The 2000 calibration of the models gave A = 2.94 and B = 0.91. The schedule equation for the Post-Architecture and Early Design models is: TDEV = C * (PMns)^F Where F = D + 0.2*(E-B) Here: TDEV = schedule in time for development in calendar months C = baseline multiplicative constant D = baseline exponential constant PMns = effort (i.e., PM) without the effects of required development schedule ( the SCED effort multiplier, PMns stands for PM with nominal schedule. The 2000 calibration of the models gave C = 3.67 and D = 0.28)

Sizing is one of the main inputs for the Post-Architecture and Early Design models of COCOMO II. Determining the size of product includes determining new code written, code reused from other sources, with or without modifications, and automatically translated code (SLOC) and/or unadjusted function points (IFPUG, 1994), which are then converted to SLOC. The Software Engineering Institute (SEI) definition checklist for a logical source statement is used in defining the LOC measure ( Park, 1992; Goethert et al 1992) The effect of reuse needs to be accounted for in the sizing metric and is done by the nonlinear model.

5. Paper ComparisonHere we compare 2 papers that discuss the Early Design and PostArchitecture Models.

5.1 EARLY DESIGN MODEL:This model is intended mainly for architectural design activities. It uses Unadjusted Function Point (UFP) counts which are converted to DSI. Application adjustment factors are not applied until after conversion to SLOC. effort, where PMNS = a x Size b x EMi (i = 1 to 6)

a = 2.94 (calibrated from 161 projects) b = 1.01 + 0.01 x SFj (j = 1 to 5)

and

EMi - effort multipliers for 6 different cost drivers SFi - exponential scale factors for 5 cost drivers NS - implies nominal schedule

5.2 POST ARCHITECTURE MODEL:This model is intended mainly for actual development activities. It is essentially a modern update to COCOMO 81. It considers a wide range of drivers. New cost drivers include reusability, documentation needs, personnel continuity and multisite teams. effort, where PMNS = a x Size b x EMi (i = 1 to 16)

a = 2.94 (calibrated from 161 projects) b = 1.01 + 0.01 x SFj (j = 1 to 5) EMi - effort multipliers for 16 different cost drivers SFi - exponential scale factors for 5 cost drivers NS - implies nominal schedule

and

5.3 A CROSS-COMPARISON BETWEEN THE TWO MODELS: Size:

o Early design and Post-Architecture both make use of Function Pont (FP) with language or SLOC Reuse: o Early design and Post-Architecture have Equivalent SLOC equal to nonlinear f(AA, SU, UNFM, DM, CM, IM) Requirements Change: o Both make use of REVL (requirements evolution) Maintenance: o Both use f(MCF, SU, UNFM) where MCF = (%added + %modified) Scale drivers, B o Both have the same equation: B = 0.91 1.23 depending on degree of precedentedness, development conformity, early architecture and risk resolution, team cohesion, and process maturity. Product cost drivers o Early design makes use of RCPC(a,b) and RUSE(a,b) o Post architecture makes use of RELY(a,b), DATA(a), DOCU(a,b), CPLX(a,b), RUSE(a,b). Platform Cost Drivers o In early design platform difficulty is given by PDIF(a,b) while in Post model we use TIME(a), STOR(a), PVOL(a) Project Cost Drivers: o Early design makes use of CED(a) and FCIL(a,b) o Post-architecture makes use of TOOL(a,b), SCED(a) and SITE(a,b).

6. Advantages and Disadvantages 6.1 SIGNIFICANT ASPECTS OF COCOMO II:Some of the many significant aspects of COCOMO II include: replacement of the 3 modes in COCOMO 81 with a single exponential equation for effort estimation and one for schedule estimation, five scale factors for adjusting the exponents of the equations, three sizing options, redefined and additional cost drivers, a requirements evolution and volatility factor, a non-linear reuse model, two levels of cost-driver granularity, phases and milestones for three types of development processes, and a Bayesian calibration method. Some of the major aspects are listed below: Aspect Elaboration Five exponential scale factors precedentedness, development flexibility, architecture/risk resolution, team cohesion, process maturity Adaptation Adjustment Multiplier non-linear cost of assessment and assimilation, software understanding, and unfamiliarity for reuse of software Three sizing options Three levels of cost model granularity Three development processes New cost drivers application points, function points, source lines of code Application Composition, Early Design, Post-Architecture waterfall, MBASE, incremental software reuse, required documentation, personnel continuity, and multiple development sites historical data plus expert judgment

Bayesian calibration

6.2 WHAT IS BEING WORKED ON?Recent work on COCOMO methodology at the USC Center for Software Engineering has focused on developing extensions to and new models based on COCOMO II, as well as work to unify the various models into a single, comprehensive estimation tool. A COCOMO II extension is an estimation model that uses the output of COCOMO II and modifies it in various ways. A new model is one based on the COCOMO approach to model building but which requires its separate inputs. New models can be used in conjunction with COCOMO II if desired. Information about COCOMO II extensions and new models can be found on the web site for the USC Center for Software Engineering.

7. Conclusion and Future workCOCOMO II, its extensions and new COCOMO-like models incorporate many innovations intended to accommodate a variety of modern approaches to software and software-intensive systems. This paper aimed at looking at the brief history of how the model came about, the current computerized editions that implement the model by various vendors. We then saw the architectural view discussing the three main classification models: Applications Composition model, early design model, and Post-architecture model. We eventually move onto looking at a detailed comparison between the seeming similar early design model and post-architecture model. In the end we look at significant aspects of COCOMO II that has made it the most popular model for software cost estimation. The next goal is to unify the various models into a single comprehensive estimation tool.

ReferencesBoehm, Barry, et al., Software Cost Estimation with COCOMO II , PrenticeHall, 2000. ISBN 0-13-026692-2. Marciniak, John J., Encyclopedia of Software Engineering, Volume 1, 2nd Edition, John Wiley & Sons Inc., New York 2002, Pg 79, 150-163 Stutzke, Richard, Estimating Software-Intensive Systems Projects, Products and Process, Pearson Education Inc., Upper Saddle River, NJ. April 2005 Fairley, Richard E.. "The Influence of COCOMO on Software Engineering Education and Training". IEEE Xplore. November 12th, 2008http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01617347

B. Boehm, Software Engineering Economics, Prentice-Hall, Englewoods Cliff, NJ, 1981. Boehm, C. Abts, A. W. Brown, S. Chulani, B. Clark, E. Horowitz, R. Madachy, D. Reifer, and B. Steece, Software Estimation with COCOMO II, Prentice Hall, Upper Saddle River, NJ, 2000. University of Southern California, COCOMO II Model Definition Manual, USC, Center for Software Engineering, Computer Science Department, Los Angeles, CA, 1997. Available at website:http://sunset.usc.edu/COCOMOII/cocomo.html

Schett, Nancy M., Seminar on Software Cost Estimation, University of Zurich, Switzerland, 2002-2003. Pg. 13

Recommended

View more >