5.

3 COCOMO model

● An empirical model based on project experience

● Well documented independent model which is not tied to a specific software vendor.
Boehm introduces a hierarchy of software estimation models bearing the generic name
COCOMO for constructive cost model.

● The basic COCOMO model is static single valued model that computes software
development effort as a function of program size expressed in estimated lines of code.

● The intermediate COCOMO model computes software development efforts as a function

of program size and a set of cost drivers that includes subjective assessments of the
product, hardware, personnel and project attributes.

The COCOMO models are defined for the three classes of software projects:

1.. Organic mode: Relatively small, simple software projects in which small team with
good application experience work to set of less than rigid requirements.

2. Semi- detached mode: An intermediate software projects in which teams with mixed
experience levels must meet a blend of rigid and less than rigid requirements

3. Embedded mode: software projects must be developed within a set of tight hardware
software

(i) product attributes

* required s/w reliability

* size of application data

* complexity of product.

(ii) Hardware attributes:

Run-time performance constraints.

Memory constraints

Required turn around time

(iii) personal attributes

 analyst capability

software engineer capability

application experience

virtual machine experience

(iv)project attributes:

use of software tools

application of software engineering methods

required developed schedule

COCOMO II is actually a hierarchy of estimation models that address the following areas:

•​ Application composition model.

Used during the early stages of software engineering, when prototyping of user interfaces,
consideration of software and system interaction, assessment of performance, and evaluation of
technology maturity are paramount

• ​Early design stage model.

Used once requirements have been stabilized and basic software architecture has been
established.

• ​Post-architecture-stage model.

Used during the construction of the software. Like all estimation models for software, the
COCOMO II models require sizing information. Three different sizing options are available as
part of the model hierarchy: object points, function points, and lines of source code

The COCOMO II application composition model uses object points. More sophisticated
estimation models (using FP and KLOC) are also available as part of COCOMO II.

Like function points, the object point is an indirect software measure that is computed using
counts of the number of

(1) screens (at the user interface),

 (2) reports, and

(3) components likely to be required to build the application.

● Each object instance (e.g., a screen or report) is classified into one of three complexity levels
(i.e., simple, medium, or difficult) using criteria suggested by Boehm .

● Complexity is a function of the number and source of the client and server data tables that
are required to generate the screen or report and the number of views or sections presented as
part of the screen or report. Once complexity is determined, the number of screens, reports,
and components are weighted according to the table

Complexity Weighting for object types

When component-based development or general software reuse is to be applied, the percent of

reuse (%reuse) is estimated and the object point count is adjusted:

​ NOP = (object points) * [(100 - %reuse)/100]

where NOP is defined as new object points.

To derive an estimate of effort based on the computed NOP value, a “productivity rate” must be
derived.

​PROD = NOP / person - month

for different levels of developer experience and development environment maturity.

 Once the productivity rate has been determined, an estimate of project effort is computed using

Estimated effort = NOP / PROD

In more advanced COCOMO II models, a variety of scale factors, cost drivers, and adjustment
procedures are required.

COCOMO 2 LEVELS:

● COCOMO 2 model is a 3 level model that allows increasingly detailed estimates to be

prepared as development progresses.

● Early prototyping level.

● Estimates based on object points and a simple formula is used for effort estimation.

● Early design level.

● The advanced COCOMO model incorporates all characteristics of the intermediate

version with an assessment of the driver’s impact on each step of the software
engineering process.

Each of the fifteen attributes is rated on a six point scale that ranges from very low to extra high.
Based on this rating an effort multiplier is determined from the tables.

Early prototyping level:

● supports prototyping projects and projects where there is extensive reuse

● based on standard estimates of developer productivity

● takes case tool use into account Object point productivity:

 Early design level:

● estimates can be made a after the requirements have been agreed based on standard
formula for algorithmic models

● PM=A? Size B ? M + PMm where M=PERS ? RCPX ? RUSE ? PDIF ? PREX ? FCIL ?
SCED

​Multipliers:

Multipliers reflect the capability of the developers, he non-functional requirements,

the familiar with the development platform, etc.

● RCPF – producer reliability and complexity

● RUSE – the reuse required

● PDIF – platform difficulty

● PREX – personnel experience

● PERS – personnel capability

● SCED – required schedule

● FCIL – the team support facilities

● PM reflects the amount of automatically generated code

Post-architectural level:

● Uses same facilities as early design estimates 

● Estimates of size is adjusted to take into account 

● Requirements volatility. rework required to support change 

● Extend of possible reuse. Reuse is non-linear and has associated costs so this is not a
simple reduction in LOC

ESLOC = ASLOC ? (AA + SU +0.4DM + 0.3CM + 0.31M)/100

 ● ESLOC is equivalent number of lines of new code ASLOC is the number of lines of
reusable code which must be modified, DM is the % of design modified , CM is the % of
the code that is modified.

Projects Planning:

● Algorithmic cost models provide a basis for projects planning as they allow alternative
strategies to be compared.

● Embedded space craft system must be reliable must minimize weight multipliers on
reliability and computer constraints.

● Cost components

● Target hardware

● Development platform

● Effort required

Project duration and staffing:

● As well as effort estimation, managers must estimate the calendar time required to
complete a project and when staff will be required

● Calendar time can be estimated using COCOMO-2 formula

● PM is effort computation and B is the exponent computed as discussed above.

● The time required is independent of the number of people working o the project.

Staffing requirements:

● Staff required cannot be computed by dividing the development time by required

schedule The number of people working on a project varies depending on the phase of
the project The more people who work on project more total effort is usually required

Key Points:
 ● Factors affecting productivity include individual aptitude domain experience the
development project, the project size, tool support

● Software may be priced to gain a contract and functionality

● Algorithmic cost estimation is difficult because of the need to estimate attributes

● The time to complete a project is not proportional to the number of people working on
the project Required level of reliability:

● Software reliability can be defined as the probability that a program will perform a
required function.

​Level of technology:

The better level of technology and higher productivity so lower cost because the time taken to
complete the project would be less and the lesser number of resources will be used.