The-Cocomo-Model in progress

8/7/2019 The-Cocomo-Model in progress

1/12


2/12

COST ESTIMATION: APPROACH AND METHODS

Cost estimation should never be an activity that is performed independently of technicalwork. In the early life-cycle phases, cost estimation is closely related to design activities,where the interaction between these activities is iterated many times as part of doing designtrade studies and early risk analysis. Later on in the life-cycle, cost estimation supportsmanagement activities primarily detailed planning, scheduling, and risk management.

The purpose of software cost estimation is to:

Define the resources needed to produce, verify, and validate the software product, andmanage these activities.

Quantify, insofar as is practical, the uncertainty and risk inherent in this estimate.

Cost Estimation

Software cost estimation is the process of predicting the resources required for the softwaredevelopment process. For a given set of requirements, it is desirable to know how much itwill cost to develop the software to satisfy the given requirements and how much timedevelopment will take. These estimates are needed before development is initialised. For asoftware development process accurate cost and schedule estimates are essential for managing the project.

Total SW Project cost = SW Development Labour cost + Other Labourcost + Non-labour cost

SW Development Labour costs include:

Software Systems Engineering performed by the software architect, software systemengineer, and subsystem engineer for functional design, software requirements, and interfacespecification. Labour for data systems engineering, which is often forgotten, should also beconsidered. This includes science product definition and data management.

Software Engineering performed by the cognizant engineer and developers to unit design,develop code, unit test, and integrate software components

Software Test Engineering covers test engineering activities from writing test plans andprocedures to performing any level of test above unit testing.


3/12

Other labour cost includes:

Software management and support performed by the project element manager (PEM), software manager, technical lead, and system administration to plan and direct thesoftware project and software configuration management

Test-bed development Development Environment Support Software system-level test support, including development and simulation software Assembly, Test, & Launch Operations (ATLO) support for flight projects

Administration and Support Costs Software Quality Assurance Independent Verification & Validation (IV&V) Other review or support charges

Non-labour cost includes:

Support and services, such as workstations, test-bed boards & simulators, ground supportequipment, network and phone charges, etc.

Software procurements such as development environment, compilers, licenses, CM tools,test tools, and development tools

Travel and trips related to customer reviews and interfaces, vendor visits, plus attendance atproject-related conferences

TrainingOverview of COCOMO

The COCOMO cost estimation model is used by thousands of software project managers, andis based on a study of hundreds of software projects. Unlike other cost estimation models,COCOMO is an open model, so all of the details are published, including:

y The underlying cost estimation equationsy Every assumption made in the model (e.g. "the project will enjoy good management")y Every definition (e.g. the precise definition of the Product Design phase of a project)y The costs included in an estimate are explicitly stated (e.g. project managers are

included, secretaries aren't)

Because COCOMO is well defined, and because it doesn't rely upon proprietary estimationalgorithms, Costar offers these advantages to its users:


4/12

y COCOMO estimates are more objective and repeatable than estimates made bymethods relying on proprietary models

y COCOMO can be calibrated to reflect your software development environment, andto produce more accurate estimates

Costar is a faithful implementation of the COCOMO model that is easy to use on smallprojects, and yet powerful enough to plan and control large projects.

Introduction to the COCOMO Model

The most fundamental calculation in the COCOMO model is the use of the Effort Equation toestimate the number of Person-Months required to develop a project. Most of the other COCOMO results, including the estimates for Requirements and Maintenance, are derivedfrom this quantity.

Source Lines of Code

The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code ( SLOC). SLOC is defined such that:

y Only Source lines that are DELIVERE D as part of the product are included -- testdrivers and other support software is excluded

y SOURCE lines are created by the project staff -- code created by applicationsgenerators is excluded

y One SLOC is one logical line of codey Declarations are counted as SLOCy Comments are not counted as SLOC

The original COCOMO 81 model was defined in terms of Delivered Source Instructions,which are very similar to SLOC. The major difference between DS I and SLOC is that asingle Source Line of Code may be several physical lines. For example, an "if-then-else"statement would be counted as one SLOC, but might be counted as several DSI.

The Scale Drivers

In the COCOMO II model, some of the most important factors contributing to a project'sduration and cost are the Scale Drivers. You set each Scale Driver to describe your project;these Scale Drivers determine the exponent used in the Effort Equation.

The 5 Scale Drivers are:

y Precedentednessy Development Flexibility


5/12

y Architecture / Risk Resolutiony Team Cohesiony Process Maturity

Note that the Scale Drivers have replaced the Development Mode of COCOMO 81. The first

two Scale Drivers, Precedentedness and Development Flexibility actually describe much thesame influences that the original Development Mode did.

Cost Drivers

COCOMO II has 17 cost drivers you assess your project, development environment, andteam to set each cost driver. The cost drivers are multiplicative factors that determine theeffort required to complete your software project. For example, if your project will developsoftware that controls an airplane's flight, you would set the Required Software Reliability(RELY) cost driver to Very High. That rating corresponds to an effort multiplier of 1.26,meaning that your project will require 26% more effort than a typical software project.

The COCOMO Model (Barry Boehm 1981):

The Co nstructive Co st Mo del (COCOMO) is an example of regression models used for estimating software cost and effort. These methods use a basic formula with parameters thatare determined via a historical database and current project characteristics.

The COCOMO Model is the most widely used and accepted of the cost / effort estimationmodels. This model as a size-driven model is highly dependent upon the manager's ability toestimate the size of the software system at an early stage. This method is generally used inconjunction with one of the size estimation models such as function points.

The COCOMO exists in a hierarchy of increasingly detailed and accurate forms. The toplevel model, Basic COCOMO is applicable to the large majority of software projects: smallto medium products developed in a familiar in-house software development environment.

Basic COCOMO is good for quick, early, rough order of magnitude estimates of softwarecosts, but its accuracy is necessarily limited because of its lack of factors to account for difference in hardware constraints, personnel quality and experience, use of modern tools andtechniques, and other project attributes known to have a significant influence on softwarecosts. Intermediate COCOMO includes these factors in terms of their aggregate impact onoverall project costs. Detailed COCOMO accounts for the influence of these additionalfactors on individual project phases.


6/12

Historical Overview of COCOMO Suite of Models

In the late 1970s and the early 1980s as software engineering was starting to take shape,software managers found they needed a way to estimate the cost of software development andto explore options with respect to software project organization, characteristics, and

cost/schedule. Along with a number of commercial and proprietary cost/schedule estimationmodels, one of the answers to this need was the open-internal Constructive Cost Model(COCOMO). This and other models allowed users to reason about the cost and scheduleimplications of their development decisions, investment decisions, established project budgetand schedules client negotiations and requested changes,cost/schedule/performance/functionality tradeoffs, risk management decisions, and processimprovement decisions By the mid-1990s, software engineering practices had changedsufficiently to motivate a new version called COCOMO II, plus a number of complementarymodels addressing special needs of the software estimation community. Figure 1 shows thevariety of cost models that have been developed at the University of Southern California

(USC) Center for Software Engineering (C SE) to support the planning and estimating of software-intensive systems as the technologies and approaches have evolved since thedevelopment of the original COCOMO in 1981. Figure 1 also shows the evolution of theCOCOMO suite categorized by software models, software extensions, and independentmodels. The more mature models have been calibrated with historical project data as well asexpert data via Delphi surveys. The newer models have only been calibrated by expert data.


7/12

T Deve l ent Mode:

There are severa l modes of sof t are deve lopmen t .These d ifferen t sof t are deve lopmen t

modes have cos t estimating re lationsh ips wh ich are s imilar in form, bu t which y ieldsignif ican tly d ifferen t cos t estimates for sof tware produc ts of the same s i e. In the C C M Mode l, one of the mos t impor tan t fac tors con tr ibuting to a pro ject s dura tion and cos t is the

eve lopmen t mode. Every pro ject is cons idered to be deve loped in one of three modes :

y Orga n i Mode. y S em idet ach ed Modey E mbedded Mode

To es timate the effor t and deve lopmen t time, C C M use the same equa tions bu t with

differen t coeff icients ( a, b, c, d in the effor t and schedu le equa tions ) for each deve lopmen t mode. Therefore before us ing the C C M mode l we mus t be ab le to recogn ise thedeve lopmen t mode of our pro ject.

1. Orga n ic Mode:

In the organ ic mode the pro ject is deve loped in a fam iliar, s tab le env ironmen t and theproduc t is s imilar to prev ious ly deve loped produc ts. The produc t is re latively sma ll,


8/12

and requires little innovation. Most people connected with the project have extensiveexperience in working with related systems within the organization and therefore canusefully contribute to the project in its early stages, without generating a great deal of project communication overhead. An organic mode project is relatively relaxed aboutthe way the software meets its requirements and interface specifications. If a situation

arises where an exact correspondence of the software product to the originalrequirements would cause an extensive rework, the project team can generallynegotiate a modification of the specifications that can be developed more easily.

2. Semidetached Mode:

In this mode project's characteristics are intermediate between Organic andEmbedded. "Intermediate" may mean either of two things:

1. An intermediate level of project characteristics.2. A mixture of the organic and embedded mode characteristics.

Therefore in an Semidetached mode project, it is possible that:

o The team members all have an intermediate level of experience with relatedsystems.

o The team has a wide mixture of experienced and inexperienced people.o The team members have experience related to some aspects of the system

under development, but not others.

The size of a Semidetached mode product generally extends up to 300 K DSI.

3. Embedded Mode:

In this development mode Project is characterized by tight , inflexible constraints andinterface requirements. The product must operate within a strongly coupled complex of hardware, software, regulations, and operational procedures. The embedded-mode projectdoes not generally have the option of negotiating easier software changes and fixes bymodifying the requirements and interface specifications. The project therefore need moreeffort to accommodate changes and fixes. The embedded mode project is generally chartingits way through unknown territory to a greater extent than the organic mode project. This leadthe project to use a much smaller team of analyst in the early stages, as a large number of people would get swamped in communication overhead.

Once the embedded mode project has completed its product design, its best strategy is tobring on a very large team of programmers to perform detailed design, coding and unit testingin parallel. Otherwise the project would take much longer to complete. This strategy as wewill see leads to the higher peaks in the personnel curves of embedded-mode projects, and to


9/12

the greater amount of effort consumed compared to an organic mode project working to thesame total development schedule.

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:

T DEV= c * ( SM ) d

The Basic COCOMO Effort and schedule equations for organic mode softwareprojects are:

SM = 2.4 * ( KDSI ) 1.05

T DEV= 2.50 * ( SM ) 0.38

The Basic COCOMO Effort and schedule equations for organic mode softwareprojects are:

SM = 3.0 * ( KDSI ) 1.12

T DEV= 2.50 * ( SM ) 0.35

4. The Basic COCOMO Effort and schedule equations for organic mode softwareprojects are:

SM = 3.6 * ( KDSI ) 1.20

T DEV= 2.50 * ( SM ) 0.32

Intermediate COCOMO Model:The Intermediate COCOMO is an extension of the basic COCOMO model. Here we use the

same basic equation for the model. But coefficients are slightly different for the effortequation. Also in addition to the size as the basic cost driver we use 15 more predictor variables. These added cost drivers help to estimate effort and cost with more accuracy. Anestimator looks closely at many factors of a project such as amount of external storagerequired, execution speed constraints, experience of the programmers on the team, experience


10/12

with the implementation language, use of software tools, etc., for each characteristic, theestimator decide where on the scale of "very low" , " low", " Nominal", "High", "Very High"and "High" the project falls. Each characteristic gives an adjustment factor( from the table 7 )and all factors are multiplied together to give an Effort Adjustment Factor ( EAF).If a projectis judged normal in some characteristic the adjustment factor will be 1 for that characteristic (

Nominal column in Table 7 ), which means that that factor has no effect on overall EAF. Theeffort 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, which results in EAF=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, but the " b" parameter is the same. The effort

equation for different modes of Intermediate COCOMO is given in the following table:

Development Mode Intermediate EffortEquation

Organic: SM = EAF * 3.2 * ( KDSI ) 1.05

Semi Detached SM = EAF * 3.0 * ( KDSI ) 1.12

Embedded SM = EAF * 2.8 * ( KDSI ) 1.20

Intermediate COCOMO computes software development effort as function of program sizeand a set of "cost drivers" that include subjective assessment of product, hardware, personneland project attributes. This extension considers a set of four "cost drivers", each with anumber of subsidiary attributes:-

y Product attributeso Required software reliabilityo Size of application databaseo Complexity of the product

y Hardware attributeso Run-time performance constraintso Memory constraintso Volatility of the virtual machine environmento Required turnabout time

y Personnel attributeso Analyst capabilityo Software engineering capability


11/12

o Applications experienceo Virtual machine experienceo Programming language experience

y Project attributeso Use of software tools

o Application of software engineering methodso Required development schedule

Each of the 15 attributes receives a rating on a six-point scale that ranges from "verylow" to "extra high" (in importance or value). An effort multiplier from the table belowapplies to the rating. The product of all effort multipliers results in an effort adjustment factor (EAF) . Typical values for EAF range from 0.9 to 1.4.

Detailed COCOMO

In detailed COCOMO, the effort is calculated as function of program size and a set of costdrivers given according to each phase of the life cycle. The phases used in DetailedCOCOMO are the requirements planning and product design, detailed design, code and unittest, and the integration testing.

Effort = (a*size b ) * EAF * sum(W i).

(W i) is the weights of life cycle model. The life cycle activities like requirements planning,system design, detailed design, code and unit testing, integration and testing.

ADVANTAGES OF COCOMO'81

COCOMO is transparent; 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 K DSI early on in the project, when most effortestimates are required

K DSI, actually, 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, using

historical data which is not always available


12/12

DIFFERENCES BETWEEN COCOMO I AND COCOMO II

The major differences between COCOMO I AN D COCOMO II are: COCOMO'81requires software size in K DSI as an input, but COCOMO II is based on K SLOC(logical code). The major difference between DSI and SLOC is that a single SourceLine of Code may be several physical lines. For example, an "if-then-else" statementwould be counted as one SLOC, but might be counted as several DSI.

COCOMO II addresses the following three phases of the spiral life cycle: applicationsdevelopment, early design and post architecture

COCOMO'81 provides point estimates of effort and schedule, but COCOMO IIprovides likely ranges of estimates that represent one standard deviation around the

most likely estimate. The estimation equation exponent is determined by five scale factors (instead of thethree development modes)

Changes in cost drivers are:

Added cost drivers (7): DOCU, RU SE, PVOL, PLEX, LTEX, PCON, SITE

Deleted cost drivers (5): VIRT, TURN, VEXP, LEXP, MO DP

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 areused for translation of existing software, but COCOMO'81 made littleaccommodation 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. To date,the difficulty has been to determine how much value. Better understandingof the field requires that the effect of systems engineering tasks be quantified. Suchquantification assists managers to set appropriate budgets, and it assists practitioners to selectthe appropriate tasks for a project of given characteristics.

The-Cocomo-Model in progress

Documents

Transcript of The-Cocomo-Model in progress