Unit II Cocomo

8/10/2019 Unit II Cocomo

1/24

UNIT-II

COCOMO


2/24

BACKGROUND

COCOMO (COnstructive COst estimation MOdel) considers the

size of the software and several other characteristics of the

proposed software. Dr Berry Boehm in 1981 proposed this

approach when software engineers started using OOD,

automated tools for code generation, testing and so on.

A series of mathematical formulae are used to predict effort

base on software size and other factors such as maturity of

process and capability of development team, risk etc.

COCOMO considers the software product attributes, platform

attributes, development team attributes and project

management attributes and weighs them suitably to improve

the estimation.


3/24

BACKGROUND

According to Boehm any software project can be classified into

any of the three categories based upon the development

complexity.

Organic: If the project is deals with developing a well-understoodapplication program, the size of the development team is reasonably

small, and the team members are experienced in developing similar

types of projects.

Semidetached: A development project can be considered to be of

semidetached type, if the development team consists of a mixture ofexperienced and inexperienced staff. Team members may have limited

experience on related systems by may be unfamiliar with some aspects

of the system being developed.

Embedded: A development project is considered to be of embeddedtype, if the software being developed is strongly coupled to complex


4/24

STAGES

According to Boehm, Software cost estimation should be done

through three stages:

Basic COCOMO Intermediate COCOMO

Complete COCOMO.


5/24

BASIC COCOMO

The Basic COCOMO model gives an approximate estimate of the

project parameters. The basic COCOMO estimation model is

given by the following expressions:

Effort= a1 X (KLOC)a2

PM

Tdev= b1 X (Effort)b2Months

Where:

a) KLOC is the estimated size of the software product expressed in Kilo

Lines of code.b) a1,a2,b1,b2 are constants for each category of software products.

c) Tdev is the estimated time to develop the software, expressed in

months,

d)

Effort is the total effort required to develop the software product,expressed in person months.

E ti ti f d l t


6/24

-Estimation of developmenteffort

- Estimation of development

timeFor the three classes of software products, the formulas forestimating the effort based on the code size are shown below:

Organic: Effort: 2.4(KLOC)1.05

PM

Semidetached Effort: 2.4(KLOC)1.12

PM

Embedded Effort: 2.4(KLOC)1.20

PM

For the three classes of software products, the formulas for

estimating the development time based on the effort are given

below:

Organic: Tdev= 2.5 (Effort)0.38Months

Semidetached: Tdev= 2.5 (Effort)0.35

Months

Embedded: Tdev= 2.5 (Effort)0.32

Months


7/24

BASIC COCOMO Example

Assume that the size of an organic type software product has

been estimated to be 32,000 lines of source code. Assume that

the average salary of software developers is 15,000 per month.

Determine the effort required to develop the software product, the

nominal development time, and the cost to develop the product.

From the basic COCOMO estimation formula for organic software:

Effort = 2.4 X (32)

1.05

PM = 91 Person monthNominal development time = 2.5 X (91) 0.38= 14 months

Cost required to develop the product = 91 X 15,000 = 1,465,000


8/24

INTERMEDIATE COCOMO

The basic COCOMO model assumes that effort and development

time are functions of the product size alone. But beside size

some other project parameters is required to develop the product

as well as the development time.

In order to obtain an accurate estimation of the effort and project

duration, the effect of all relevant parameters must be taken into

account. The intermediate COCOMO model recognizes this fact

and refines the initial estimate obtained using the basic

COCOMO expressions by using a set of 15 cost drivers based onvarious attributes of software development.


9/24

INTERMEDIATE COCOMO

Ratings upon the 15 cost drivers are asked from project managers

on a scale of one to three. Depending on these ratings,

appropriate cost driver values which should be multiplied with the

initial estimate obtained using the basic COCOMO. The cost

drivers can be classified as being attributes of the following items:

Product:

Computer:Personnel:

Development environment:


10/24

INTERMEDIATE COCOMO

The Intermediate COCOMO formula now takes the form:

Effort=ai(KLoC)(b

i).EAF

Where E is the effort applied in person-months, KLOCis the

estimated number of thousands of delivered lines of code for the

project, and EAFis the factor calculated above. The value of ai

and bi are given in the next table.

The Development time calculation uses Effortin the same way as

in the Basic COCOMO.

Software project ai bi

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20


11/24

COMPLETE COCOMO

A major shortcoming of both the basic and the intermediate

COCOMO models is that they consider a software product as a

single homogeneous entity. Most of the times large systems are

made up of several smaller subsystems.

The complete COCOMO model considers these differences in

characteristics of the subsystems and estimates the effort and

development time as the sum of the estimates for the individual

subsystems. The cost of each subsystem is estimated separately.

This approach reduces the margin of error in the final estimate.


12/24

COMPLETE COCOMO

In case of a Distributed Management Information System product

for an organization having offices at several places across the

country can have the following sub components:

Database Part

Graphical User Interface Part

Communication Part

The communication part can be considered as embeddedsoftware. The database part could be semidetached software,

and the GUI part can be considered as Organic Software. The

costs for these three components can be estimated separately,

and summed up to give the overall cost of the system.


13/24

COCOMO - II

The latest version of COCOMO model is COCOMO-II, released in

1997. This model has three estimation model to estimate effort

and cost. The models are:

Application Suite Model/Application Composition Model:

This model as the name suggests, can be used to estimate cost

for prototyping, e.g. to resolve user interface issues.

Early Design Model: This supports estimates of cost at the

architectural design stage.

Post Architectural Model/ Final Design Architectural Model:

This provides cost estimation during detailed design and coding

stage. The post architectural model can be considered as an

update of the original COCOMO.


14/24

uModel/Application Composition

ModelThe Application composition model is based on counting the

number of screens, reports and 3GL modules. Each of these

components is considered to be an object.

Effort is estimated in the application composition model as follows:

1) Estimate the number of screens, reports and 3GL components from an

analysis of the SRS document.

2) Determine the complexity level of each screen and report and rate these as

either simple, medium or difficult.

Screen Complexity table:Number of views Tables


15/24


Model3. Determine the number of object points

4. Estimate percentage of reuse expected in the system. Then

evaluate new object point.

5. Determine a productivity rate, PROD=NOP/person-month. Theproductivity depends on the experience of the developers as

well as the maturity of the CASE environment used.

Developers

experience

Very low Low Nominal High Very high

CASE

maturity

Very low Low Nominal High Very high

PROD 4 7 13 25 50


16/24


ModelThe object points count needs modification by way of reduction as

the software may use reusable components and libraries.

Therefore:

Revised Object Point (ROP)=Object Point X

For this ROP, the effort in man month is computed using a

productivity constant, based on the software developmentteams experience and capability. COCOMO-II prescribes

productivity constant expressed as the number of object points

per man month as shown in previous table.

=


17/24


ModelFor example, object points, say are 40 and the re-use possibility is

10%, then

ROP= = 40 X 0.90 = 36

Further, if the development teamsexperience and maturity is at

level normal, then productivity constant is 13. hence

MME= 36/13 = 3 Man Months


18/24

Early Design Model

The COCOMO uses the base equation:

MME = A X (size)B

Where:MME = Man month effort

A = constant representing nominal productivity

B = factor indicating economies/diseconimies of scale. B is known

as scaling factor.Size = KLOC.


19/24

Early Design Model

The emphasis in the COCOMO-II model is on scaling factors,

which together give rise to B. The model uses five factors for

arriving at economies/diseconimies in scale, namely

precedentness, development flexibility, risk resolution, team

cohesion and organization process maturity.

B is the value of scaling factor is computed as below:

B = 0.91 + 0.01( Ratings)

The rating for each of the five factors is based on the

organization's level on each of these factors.


20/24

Early Design Model

Factor Code Very low Low Nominal High Factor Name

PREC 6.20 4.96 3.72 2.48 Precedentness

FLEX 5.07 4.05 3.04 2.03 Flexibility

RESL 7.07 5.65 4.24 2.83 Risk Resolution

TEAM 5.48 4.38 3.29 2.19 Team CohesionPMAT 7.80 6.24 4.68 3.12 Process Maturity

Let us assume that in a given software development scenario, the

organization's level on these factors is very low.

Then B= 0.91 + 0.01 X(6.20 +5.07+7.07+5.48+7.80) = 1.2262

A=13, size=10 KLOC, then MME=13 X (10)1.2262person month.


21/24

Post Architectural Model

In addition to the 5 factors that affect development efforts, some

factors have a large impact on MME. In Post Architectural

Model the MME(Modified) is calculated based upon 16 more

factors which are significant.

MME(Modified) = MME X (Product of ratings of 16 factors)


22/24


Code Name Very

low

Low Nomina

l

High

Product Factors

RELY Software Reliability 0.82 0.92 1.00 1.10

DATA Database Size 0.80 0.90 1.00 1.14

CPLX Software Complexity 0.73 0.87 1.00 1.17

RUSE Required Reusability 0.85 0.95 1.00 1.07

DOC

U

Documentation 0.81 0.91 1.00 1.11

Platform Factors

TIME Time constraint on execution NRA NRA 1.00 1.11

STPR Main storage constraint NRA NRA 1.00 1.05

PVOL PLATFORM VOLATILITY NRA NRA 1.00 1.15


23/24


Code Name Very

low

Low Nomina

l

High

Personnel Factors

ACAP Analyst capability 1.42 1.19 1.00 0.85

PCAP Programmer capability 1.34 1.15 1.00 0.88

AEXP Analyst experience 1.22 1.10 1.00 0.88

PEXP Programmer experience 1.19 1.09 1.00 0.91

LTXP Language and tool experience 1.20 1.09 1.00 0.91

PCON

Personnel Continuity 1.29 1.12 1.00 0.90

Project Factors

TOOL Use of software tools 1.17 1.09 1.00 0.90

SITE Site environment 1.22 1.09 1.00 0.93


24/24


Suppose we have to calculate the MME(Modified) in a post architectural

scenario according to the previous example where the size is 10 KLOC.

Let us evaluate tow possibilities of an extreme nature. One assumption is that

the organization scores very low on all architectural factors, and the second

possibility is that the organization scores high on all factors.

Possibility 1: (All ratings are very low)

Product of ratings of 16 factors = 2.01

Possibility 2: (All ratings are high)Product of ratings of 16 factors = 0.98

MME 1 = 220 X 2.01 = 442 Man Months

MME 2 = 142 X 0.98 = 139 Man Months

Documents

Unit II Cocomo