Software Engineering Economics

(SE-231)
(Lecture 19-20)

Instructor:
Gul Sher Ali

Department of Software Engineering

______________________________________________________
University of Gujrat – Hafiz Hayat Campus

1
The Exponent B
Scale Factor(SF) - COCOMO II

Exponent B for effort calculation

B = 1.01 + 0.01 x sum [SF (i)] , i=1,…, 5
SF = Scale Factor
Each SF is rated on 6-point scale (ranging from 0 to 5)
:
very low (5), low ( 4), nominal (3), high (2), very high (1), extra high
(0)
5 Scale Factor (exponent drivers)
Precedenteness
Development flexibility
Architecture/risk resolution
Team cohesion
Process maturity
The exponent term

This depends on 5 scale factors (see next slide). Their

sum/100 is added to 1.01
A company takes on a project in a new domain. The
client has not defined the process to be used and has
not allowed time for risk analysis. The company has a
CMM level 2 rating.
Precedenteness - new project (4)
Development flexibility - no client involvement - Very high (1)
Architecture/risk resolution - No risk analysis - V. Low .(5)
Team cohesion - new team - nominal (3)
Process maturity - some control - nominal (3)
Scale factor is therefore 1.17.
Exponent scale factors
Precedentedness Reflects the previous experience of the organisation with this type of
projec t. Very low means no previous experience, Extra high means
that the organis ation is completely familiar with this application
domain.
Development Reflects the degree of flexibility in the development process. Very
flexibility low means a prescribed process is used; Extra high means that the
client only sets general goals .
Architecture/risk Reflects the extent of risk analysis carried out. Very low means little
resolution analysis, Extra high means a complete a thorough risk analysis.
Team cohesion Reflects how well the development team know each other and work
together. Very low means very difficult interactions, Extra high
means an integrated and effective team with no communication
problems.
Process maturity Reflects the process maturity of the organisation. The computation
of this value depends on the CMM Maturity Questionnaire but an
estimate can be achieved by subtracting the CMM process maturity
level from 5.
Multipliers

Product attributes
Concerned with required characteristics of the software product
being developed.
Computer attributes
Constraints imposed on the software by the hardware platform.
Personnel attributes
Multipliers that take the experience and capabilities of the
people working on the project into account.
Project attributes
Concerned with the particular characteristics of the software
development project.
Effects of cost drivers
Maximum & Minimum Data are from ref: Boehm, 1997
Exponent value 1.17
System size (including factors for reuse 128, 000 DSI
and requirements volatility)
Initial COCOMO estimate without 730 person-months
cost drivers (M=1)
Reliability Very high, multiplier = 1.39
Complexity Very high, multiplier = 1.3
Memory constraint Maximum High, multiplier = 1.21
Tool use Low, multiplier = 1.12
Schedule Accelerated, multiplier = 1.29
Adjusted COCOMO estimate: 2306 person-months

Reliability Very low, multiplier = 0.75

Complexity Very low, multiplier = 0.75
Memory constraint Minimum None, multiplier = 1
Tool use Very high, multiplier = 0.72
Schedule Normal, multiplier = 1
Adjusted COCOMO estimate: 295 person-months
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 a COCOMO 2
formula
TDEV = 3  (PM)(0.33+0.2*(B-1.01))
PM is the effort computation and B is the exponent computed as
discussed above (B is 1 for the early prototyping model). This
computation predicts the nominal schedule for the project.
The time required is independent of the number of
people working on the project.
Staffing requirements

Staff required can’t be computed by diving the

development time by the required schedule.
The number of people working on a project
varies depending on the phase of the project.
The more people who work on the project, the
more total effort is usually required.
A very rapid build-up of people often correlates
with schedule slippage.
Key points

There is not a simple relationship between the

price charged for a system and its development
costs.
Factors affecting productivity include individual
aptitude, domain experience, the development
project, the project size, tool support and the
working environment.
Software may be priced to gain a contract and
the functionality adjusted to the price.
Key points
Different techniques of cost estimation should be used
when estimating costs.
The COCOMO model takes project, product, personnel
and hardware attributes into account when predicting
effort required.
Algorithmic cost models support quantitative option
analysis as they allow the costs of different options to be
compared.
The time to complete a project is not proportional to the
number of people working on the project.
 Software Project Cost Estimation

Overview of COCOMO

The COCOMO II calculations are based on estimates

of a project's size in Source Lines of Code (SLOC).
SLOC is defined such that:
 Only Source lines that are DELIVERED as part of
the product are included -- test drivers and other
support software is excluded
 SOURCE lines are created by the project staff --
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
 Software Project Cost Estimation
Overview of COCOMO

COCOMO 81 DSI - “Delivered Source Instructions”

COCOMO II SLOC - “Source Lines Of Code”

The original COCOMO 81 model was defined in terms

of Delivered Source Instructions, which are very similar
to SLOC. 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.
Software development life-cycle

Early researchers found that labor distribution of

hardware and software development follows a
Rayleigh distribution

 t2 
t  − 2 

PY = pm 2  e  tD 

 tD 
Where t = month, tD = month at peak effort
Rayleigh Curves
Peak effort at 7 months - Requiring 5 People
Rayleigh Curve

5.0

4.5
4.0

3.5
Person-months

3.0

2.5
2.0

1.5
1.0
0.5
0.0
0 5 10 15 20 25 30
Calendar Months
 Life-Cycle
Requirements Design Code Test Maintenance
Rayleigh Curve

9.0

8.0
7.0
Person-months

6.0
5.0

4.0
3.0

2.0
1.0

0.0
0 5 10 15 20 25 30
Calendar Months
16
17