COST ESTIMATION: APPROACH AND METHODS

Cost estimation should never be an activity that is performed independently of technical work. 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 design trade studies and early risk analysis. Later on in the life-cycle, cost estimation supports management 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, and manage 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 software development process. For a given set of requirements, 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. These estimates are needed before development is initialised. For a software development process accurate cost and schedule estimates are essential for managing the project.

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, software system engineer, and subsystem engineer for functional design, software requirements, and interface specification. Labour for data systems engineering, which is often forgotten, should also be considered. 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 and procedures to performing any level of test above unit testing.

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 the software 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 support equipment, 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 at project-related conferences

• Training

The COCOMO Model (Barry Boehm 1981):

The COnstructive COst MOdel (COCOMO) is an example of regression models used for estimating software cost and effort. These methods use a basic formula with parameters that are determined via a historical database and current project characteristics.

The COCOMO Model is the most widely used and accepted of the cost / effort estimation models. 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. This method is generally used in conjunction with one of the size estimation models such as function points.

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

Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs, 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 and techniques, and other project attributes known to have a significant influence on software costs. Intermediate COCOMO includes these factors in terms of their aggregate impact on overall project costs. Detailed COCOMO accounts for the influence of these additional factors on individual project phases.

The Development Mode:

There are several modes of software development .These different software development modes have cost-estimating relationships which are similar in form, but which yield significantly different cost estimates for software products of the same size. In the COCOMO Model, one of the most important factors contributing to a project's duration and cost is the Development mode. Every project is considered to be developed in one of three modes:

Organic Mode. Semidetached Mode Embedded Mode

 To estimate the effort and development time, COCOMO use the same equations but with different coefficients ( a, b, c, d in the effort and schedule equations ) for each development mode. Therefore before using the COCOMO model we must be able to recognise the development mode of our project.

1. Organic Mode:

In the organic mode the project is developed in a familiar, stable environment and the product is similar to previously developed products. The product is relatively small, and requires little innovation. 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, 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. If a situation

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

2. Semidetached Mode:

In this mode project's characteristics are intermediate between Organic and Embedded. "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 related systems.

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

3. Embedded Mode:

In this development mode Project is characterized by tight , inflexible constraints and interface requirements. The product must operate within a strongly coupled complex of hardware, software, regulations, and operational procedures. 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 therefore need more effort to accommodate changes and fixes. The embedded mode project is generally charting its way through unknown territory to a greater extent than the organic mode project. This lead the 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 to bring on a very large team of programmers to perform detailed design, coding and unit testing in parallel. Otherwise the project would take much longer to complete. This strategy as we will see leads to the higher peaks in the personnel curves of embedded-mode projects, and to the greater amount of effort consumed compared to an organic mode project working to the same 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:

TDEV= c * ( SM )d

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

SM = 2.4 * ( KDSI )1.05

TDEV= 2.50 * ( SM )0.38

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

SM = 3.0 * ( KDSI )1.12

TDEV= 2.50 * ( SM )0.35

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

SM = 3.6 * ( KDSI )1.20

TDEV= 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 effort equation. 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. An estimator looks closely at many factors of a project such as amount of external storage required, execution speed constraints, experience of the programmers on the team, experience with the implementation language, use of software tools, etc., for each characteristic, the estimator 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 project is 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. 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, which

results in EAF=1, and 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 ModeIntermediate Effort Equation

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 size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes. This extension considers a set of four "cost drivers", each with a number of subsidiary attributes:-

Product attributes o Required software reliabilityo Size of application databaseo Complexity of the product

Hardware attributes o Run-time performance constraintso Memory constraintso Volatility of the virtual machine environmento Required turnabout time

Personnel attributes o Analyst capabilityo Software engineering capabilityo Applications experienceo Virtual machine experienceo Programming language experience

Project attributes o Use of software toolso Application of software engineering methodso Required development schedule

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). An effort multiplier from the table below

applies 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 cost drivers given according to each phase of the life cycle. The phases used in Detailed COCOMO are the requirements planning and product design, detailed design, code and unit test, and the integration testing.

Effort = (a*sizeb ) * EAF * sum(Wi).

(Wi) 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 KDSI early on in the project, when most effort estimates are required

• KDSI, 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

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). The major difference between DSI and SLOC is that a single 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.

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

• COCOMO'81 provides point estimates of effort and schedule, but COCOMO II provides 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 the three development modes)

• Changes in cost drivers are:

§ Added cost drivers (7): DOCU, RUSE, PVOL, PLEX, LTEX, PCON, SITE

§ Deleted cost drivers (5): VIRT, TURN, VEXP, LEXP, 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, but COCOMO'81 made little accommodation for these factors

• COCOMO II accounts for requirements volatility in its estimates