This action might not be possible to undo. Are you sure you want to continue?
should also be considered. Cost Estimation Software cost estimation is the process of predicting the resources required for the software development process. insofar as is practical. it is desirable to know how much it will cost to develop the software to satisfy the given requirements and how much time development will take. This includes science product definition and data management. where the interaction between these activities is iterated many times as part of doing design trade studies and early risk analysis. Later on in the life-cycle. software system engineer. and risk management. Software Engineering ± performed by the cognizant engineer and developers to unit design. and manage these activities. cost estimation is closely related to design activities. software requirements. Quantify. the uncertainty and risk inherent in this estimate. . unit test. The purpose of software cost estimation is to: Define the resources needed to produce. For a given set of requirements. develop code. and subsystem engineer for functional design. These estimates are needed before development is initialised. cost estimation supports management activities ± primarily detailed planning. Labour for data systems engineering. In the early life-cycle phases. which is often forgotten. For a software development process accurate cost and schedule estimates are essential for managing the project.COST ESTIMATION: APPROACH AND METHODS Cost estimation should never be an activity that is performed independently of technical work. and interface specification. verify. Total SW Project cost = SW Development Labour cost + Other Labour cost + Non-labour cost SW Development Labour costs include: Software Systems Engineering ± performed by the software architect. and validate the software product. and integrate software components Software Test Engineering ± covers test engineering activities from writing test plans and procedures to performing any level of test above unit testing. scheduling.
and is based on a study of hundreds of software projects. technical lead. software manager. Unlike other cost estimation models. so all of the details are published. including: y y y y The underlying cost estimation equations Every assumption made in the model (e. project managers are included. etc. and development tools Travel and trips related to customer reviews and interfaces. test-bed boards & simulators.g. Costar offers these advantages to its users: . such as workstations. including development and simulation Assembly. & Launch Operations (ATLO) support for flight projects Administration and Support Costs Software Quality Assurance Independent Verification & Validation (IV&V) Other review or support charges software Non-labour cost includes: Support and services. vendor visits. licenses. and system administration to plan and direct the software project and software configuration management Test-bed development Development Environment Support Software system-level test support. secretaries aren't) Because COCOMO is well defined. CM tools.g. and because it doesn't rely upon proprietary estimation algorithms. test tools. COCOMO is an open model. plus attendance at project-related conferences Training Overview of COCOMO The COCOMO cost estimation model is used by thousands of software project managers. network and phone charges. Test. Software procurements such as development environment.g. "the project will enjoy good management") Every definition (e. ground support equipment. compilers.Other labour cost includes: Software management and support ± performed by the project element manager (PEM). the precise definition of the Product Design phase of a project) The costs included in an estimate are explicitly stated (e.
The major difference between DSI and SLOC is that a single Source Line of Code may be several physical lines. but might be counted as several DSI. The 5 Scale Drivers are: y y Precedentedness Development Flexibility . some of the most important factors contributing to a project's duration and cost are the Scale Drivers. SLOC is defined such that: y y y y y Only Source lines that are DELIVERED as part of the product are included -. Source Lines of Code The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code (SLOC). The Scale Drivers In the COCOMO II model. which are very similar to SLOC. these Scale Drivers determine the exponent used in the Effort Equation.test drivers and other support software is excluded SOURCE lines are created by the project staff -. Most of the other COCOMO results. and yet powerful enough to plan and control large projects. You set each Scale Driver to describe your project. are derived from this quantity. including the estimates for Requirements and Maintenance.y y COCOMO estimates are more objective and repeatable than estimates made by methods relying on proprietary models COCOMO can be calibrated to reflect your software development environment. For example. an "if-then-else" statement would be counted as one SLOC.code created by applications generators is excluded One SLOC is one logical line of code Declarations are counted as SLOC Comments are not counted as SLOC The original COCOMO 81 model was defined in terms of Delivered Source Instructions. Introduction to the COCOMO Model The most fundamental calculation in the COCOMO model is the use of the Effort Equation to estimate the number of Person-Months required to develop a project. and to produce more accurate estimates Costar is a faithful implementation of the COCOMO model that is easy to use on small projects.
Detailed COCOMO accounts for the influence of these additional factors on individual project phases. use of modern tools and techniques. if your project will develop software that controls an airplane's flight. The COCOMO Model is the most widely used and accepted of the cost / effort estimation models. Cost Drivers COCOMO II has 17 cost drivers ± you assess your project. For example. Precedentedness and Development Flexibility actually describe much the same influences that the original Development Mode did. The COCOMO Model (Barry Boehm 1981): The Constructive Cost Model (COCOMO) is an example of regression models used for estimating software cost and effort.26. These methods use a basic formula with parameters that are determined via a historical database and current project characteristics. you would set the Required Software Reliability (RELY) cost driver to Very High. The COCOMO exists in a hierarchy of increasingly detailed and accurate forms. and team to set each cost driver. Basic COCOMO is applicable to the large majority of software projects: small to medium products developed in a familiar in-house software development environment. Intermediate COCOMO includes these factors in terms of their aggregate impact on overall project costs. personnel quality and experience. This model as a size-driven model is highly dependent upon the manager's ability to estimate the size of the software system at an early stage. rough order of magnitude estimates of software costs. The cost drivers are multiplicative factors that determ the ine effort required to complete your software project. and other project attributes known to have a significant influence on software costs. This method is generally used in conjunction with one of the size estimation models such as function points. Basic COCOMO is good for quick. but its accuracy is necessarily limited because of its lack of factors to account for difference in hardware constraints. meaning that your project will require 26% more effort than a typical software project. . early. development environment.y y y Architecture / Risk Resolution Team Cohesion Process Maturity Note that the Scale Drivers have replaced the Development Mode of COCOMO 81. That rating corresponds to an effort multiplier of 1. The first two Scale Drivers. The top level model.
The more mature models have been calibrated with historical project data as well as expert data via Delphi surveys. and independent models. risk management decisions. Figure 1 also shows the evolution of the COCOMO suite categorized by software models. one of the answers to this need was the open-internal Constructive Cost Model (COCOMO). and cost/schedule. established project budget and schedules client negotiations and requested changes. Along with a number of commercial and proprietary cost/schedule estimation models.Historical Overview of COCOMO Suite of Models In the late 1970s and the early 1980s as software engineering was starting to take shape. This and other models allowed users to reason about the cost and schedule implications of their development decisions. characteristics. . plus a number of complementary models addressing special needs of the software estimation community. software managers found they needed a way to estimate the cost of software development and to explore options with respect to software project organization. Figure 1 shows the variety of cost models that have been developed at the University of Southern California (USC) Center for Software Engineering (CSE) to support the planning and estimating of software-intensive systems as the technologies and approaches have evolved since the development of the original COCOMO in 1981. investment decisions. software extensions. software engineering practices had changed sufficiently to motivate a new version called COCOMO II. The newer models have only been calibrated by expert data. and process improvement decisions By the mid-1990s. cost/schedule/performance/functionality tradeoffs.
stable environment and the product is similar to previously developed products.These different soft are development modes have cost estimating relationships which are similar in form. b. 1. one of the most important factors contributing to a project s duration and cost is the evelopment mode. Semidetached Mode Embedded Mode To estimate the effort and development time. Organic Mode: In the organic mode the project is developed in a familiar. d in the effort and schedule equations ) for each development mode. Every project is considered to be developed in one of three modes: y y y Organi Mode. but which yield significantly different cost estimates for software products of the same si e. C C M use the same equations but with different coefficients ( a. . The product is relatively sm all. Therefore before using the C C M model we must be able to recognise the development mode of our project.T Devel ent Mode: There are several modes of soft are development . In the C C M Model. c.
An intermediate level of project characteristics. Most people connected with the project have extensive experience in working with related systems within the organization and therefore can usefully contribute to the project in its early stages. The product must operate within a strongly coupled complex of hardware. without generating a great deal of project communication overhead. An organic mode project is relatively relaxed about the way the software meets its requirements and interface specifications. inflexible constraints and interface requirements. "Intermediate" may mean either of two things: 1. coding and unit testing in parallel. 2. If a situation arises where an exact correspondence of the software product to the original requirements would cause an extensive rework. This lead the project to use a much smaller team of analyst in the early stages. The embedded mode project is generally charting its way through unknown territory to a greater extent than the organic mode project. The project therefore need more effort to accommodate changes and fixes. its best strategy is to bring on a very large team of programmers to perform detailed design. 2. o The team members have experience related to some aspects of the system under development. The embedded-mode project does not generally have the option of negotiating easier software changes and fixes by modifying the requirements and interface specifications. the project team can generally negotiate a modification of the specifications that can be developed more easily. Once the embedded mode project has completed its product design. but not others. A mixture of the organic and embedded mode characteristics. Therefore in an Semidetached mode project. The size of a Semidetached mode product generally extends up to 300 KDSI.and requires little innovation. and operational procedures. Semidetached Mode: In this mode project's characteristics are intermediate between Organic and Embedded. Otherwise the project would take much longer to complete. Embedded Mode: In this development mode Project is characterized by tight . and to . o The team has a wide mixture of experienced and inexperienced people. it is possible that: o The team members all have an intermediate level of experience with related systems. This strategy as we will see leads to the higher peaks in the personnel curves of embedded-mode projects. 3. software. regulations. as a large number of people would get swamped in communication overhead.
12 TDEV= 2.6 * ( KDSI )1.the greater amount of effort consumed compared to an organic mode project working to the same total development schedule.50 * ( SM ) 0. execution speed constraints. experience .35 4.50 * ( SM ) 0. The Basic COCOMO Effort and schedule equations for organic mode software projects are: SM = 3. An estimator looks closely at many factors of a project such as amount of external storage required.20 TDEV= 2.32 Intermediate COCOMO Model: The Intermediate COCOMO is an extension of the basic COCOMO model.05 TDEV= 2. experience of the programmers on the team. Also in addition to the size as the basic cost driver we use 15 more predictor variables.0 * ( KDSI )1. But coefficients are slightly different for the effort equation. The Basic COCOMO Model: The Basic Model makes its estimates of required effort (measured in Staff-Months SM ) based primarily on your estimate of the software project's size ( as measured in thousands of Delivered Source Instructions KDSI ): SM = a * ( KDSI )b The Basic model also presents an equation for estimating the development schedule (Time of Develop TDEV ) of the project in months: TDEV= c * ( SM )d The Basic COCOMO Effort and schedule equations for organic mode software projects are: SM = 2. These added cost drivers help to estimate effort and cost with more accuracy.50 * ( SM ) 0. Here we use the same basic equation for the model.38 The Basic COCOMO Effort and schedule equations for organic mode software projects are: SM = 3.4 * ( KDSI )1.
each with a number of subsidiary attributes:y y y Product attributes o Required software reliability o Size of application database o Complexity of the product Hardware attributes o Run-time performance constraints o Memory constraints o Volatility of the virtual machine environment o Required turnabout time Personnel attributes o Analyst capability o Software engineering capability . etc.12 SM = EAF * 2. for each characteristic. the estimator decide where on the scale of "very low" .05 SM = EAF * 3. This extension considers a set of four "cost drivers".0* ( KDSI )1. " low". "High". use of software tools.If a project is judged normal in some characteristic the adjustment factor will be 1 for that characteristic ( Nominal column in Table 7 ). "Very High" and "High" the project falls. but the " b" parameter is the same. which results in EAF=1.with the implementation language. hardware.20 Intermediate COCOMO computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product. Each characteristic gives an adjustment factor( from the table 7 ) and all factors are multiplied together to give an Effort Adjustment Factor ( EAF). personnel and project attributes. The effort equation for the intermediate model has the form of: SM = EAF * a * ( KDSI )b If we assume that the project is "Nominal" in every aspect then all adjustment factors would be 1. an d the effort equation would have the same form as the Basic mode. in addition to the EAF the model parameter " a" is slightly different in Intermediate COCOMO.. which means that that factor has no effect on overall EAF. The effort equation for different modes of Intermediate COCOMO is given in the following table: Development Mode Organic: Semi Detached Embedded Intermediate Effort Equation SM = EAF * 3.8* ( KDSI )1.2 * ( KDSI )1. " Nominal".
integration and testing. The phases used in Detailed COCOMO are the requirements planning and product design. one can see how it works unlike other models such as SLIM Drivers are particularly helpful to the estimator to understand the impact of different factors that affect project costs DRAWBACKS OF COCOMO'81 It is hard to accurately estimate KDSI early on in the project. detailed design. actually. when most effort estimates are required KDSI. (Wi) is the weights of life cycle model. Effort = (a*sizeb ) * EAF * sum(Wi). is not a size measure it is a length measure Extremely vulnerable to mis-classification of the development mode Success depends largely on tuning the model to the needs of the organization.4. An effort multiplier from the table below applies to the rating. system design.9 to 1. the effort is calculated as function of program size and a set of cost drivers given according to each phase of the life cycle. detailed design.y Applications experience o Virtual machine experience o Programming language experience Project attributes o Use of software tools o Application of software engineering methods o Required development schedule o Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in importance or value). Detailed COCOMO In detailed COCOMO. The life cycle activities like requirements planning. The product of all effort multipliers results in an effort adjustment factor (EAF). and the integration testing. using historical data which is not always available . ADVANTAGES OF COCOMO'81 COCOMO is transparent. Typical values for EAF range from 0. code and unit test. code and unit testing.
and it assists practitioners to select the appropriate tasks for a project of given characteristics. PCON. COCOMO II addresses the following three phases of the spiral life cycle: applications development. For example. The major difference between DSI and SLOC is that a single Source Line of Code may be several physical lines. but might be counted as several DSI. but COCOMO'81 made little accommodation for these factors COCOMO II accounts for requirements volatility in its estimates CONCLUSIONS There is little doubt that doing the right amount of systems engineering has value. VEXP. . RUSE. MODP § Alter the retained ratings to reflect more up-do-date software practices Data points in COCOMO I: 63 and COCOMO II: 161 COCOMO II adjusts for software reuse and reengineering where automated tools are used for translation of existing software. The estimation equation exponent is determined by five scale factors (instead of the three development modes) Changes in cost drivers are: § Added cost drivers (7): DOCU. SITE § Deleted cost drivers (5): VIRT. Such quantification assists managers to set appropriate budgets. an "if-then-else" statement would be counted as one SLOC. To date. LEXP. TURN. early design and post architecture COCOMO'81 provides point estimates of effort and schedule. PLEX.DIFFERENCES BETWEEN COCOMO I AND COCOMO II The major differences between COCOMO I AND COCOMO II are: COCOMO'81 requires software size in KDSI as an input. but COCOMO II is based on KSLOC (logical code). LTEX. Better understanding of the field requires that the effect of systems engineering tasks be quantified. PVOL. the difficulty has been to determine how much value. but COCOMO II provides likely ranges of estimates that represent one standard deviation around the most likely estimate.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.