Basic COCOMO

 Basic COCOMO computes software development effort (and cost) as a function of program size.
 Program size is expressed in estimated thousands of source lines of code (SLOC, KLOC).

COCOMO applies to three classes of software projects:

 Organic projects - "small" teams with "good" experience working with "less than rigid"
requirements (simple business system, simple inventory management system etc.)
 Semi-detached projects - "medium" teams with mixed experience working with a mix
of rigid and less than rigid requirements ( new OS or DBMS, complex inventory
management system etc.)
 Embedded projects - developed within a set of "tight" constraints. It is also
combination of organic and semi-detached projects.(hardware, software, operational, ...)
(embedded avionics, real time command system etc.)
 The basic COCOMO equations take the form
Effort Applied (E) = ab(KLOC)bb  [ man-months ]
Development Time (D) = cb(Effort Applied)db  [months] 
People required (P) = Effort Applied / Development Time [count] 
where, KLOC is the estimated number of delivered lines ,expressed in thousands of lines of code for project.
The coefficients ab, bb, cb and db are given in the following table:

Software
ab bb cb db
project

Organic 2.4 1.05 2.5 0.38

Semi-
3.0 1.12 2.5 0.35
detached

Embedded 3.6 1.20 2.5 0.32

 Basic COCOMO is good for quick estimate of software costs.

 However it does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, etc
Effort estimation are of two types

This approach of determining total effort from the total size is what we refer
to as the top-down approach, as overall effort is first determined and then
from this the effort for different parts are obtained.

Another approach for effort estimation is the bottom-up approach. In this approach, the
project is first divided into tasks and then estimates for the different tasks of the project
are first obtained. Prom the estimates of the different tasks, the overall estimate is
determined. That is, the overall estimate of the project is derived from the estimates of its
parts. This type of approach is also called activity-based estimation
The basic steps in the COCOMO model are:

1. Obtain an initial estimate of the development effort from the estimate of thousands
of delivered lines of source code (KLOC).
2. Determine a set of 15 multiplying factors from different attributes of the project.
3. Adjust the effort estimate by multiplying the initial estimate with all the multiplying
factors.

To determine the initial effort Ei in person-months the equation used is of the type

The value of the constants a and b depend on the project type. In COCOMO
projects are categorized into three types-organic, semidetached, and embedded
Intermediate COCOMO

 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:-

Examples of the attributes are required software reliability (RELY), product

complexity (CPLX), analyst capability (ACAP), application experience (AEXP), use
of modern tools (TOOL), and required development schedule (SCHD) etc.
As an example, suppose a system for office automation has to be designed. From the
requirements, it is clear that there will be four major modules in the system: data
entry, data update, query, and report generator. It is also clear from the
requirements that this project will fall in the organic category.

The sizes for the different modules and the overall system are estimated to be:

Data Entry 0.6 KLOC

Data Update 0.6 KLOC
Query 0.8 KLOC
Reports 1.0 KLOC
TOTAL 3.0 KLOC
All other factors had a nominal rating. From these, the effort adjustment factor (EAF) is

Total Size is 3.0 KLOC And for the Organic category the constant values for a=3.2 and for b=1.05

Hence ,The initial effort estimate for the project is

The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF. That is, E = EAF * Ei

Using the EAF, the adjusted effort estimate is

The percentage of total effort spent in a phase varies with the type and size of the
project. The percentages for an organic software project are given in Table. Using this
table, the estimate of the effort required for each phase can be determined from the
total effort estimate

The office automation system's size estimate is 3 KLOC, so we will have to use
interpolation to get the appropriate percentage (the two end values for interpolation
will be the percentages for 2 KLOC and 8 KLOC). The percentages for the different
phases are: design—16%, detailed design—25.83%, code and unit test—41.66%, and
integration and testing—16.5%. With these, the effort estimates for the different
phases are:
 The office automation system's size estimate is 3 KLOC, so we will have to use
interpolation to get the appropriate percentage (the two end values for interpolation
will be the percentages for 2 KLOC and 8 KLOC). The percentages for the different
phases are: design—16%, detailed design—25.83%, code and unit test—41.66%, and
integration and testing—16.5%. With these, the effort estimates for the different
phases are:

Effort Estimates for the different phases are:

Percentage of Phase-wise distribution of effort * Effort estimate E

These effort estimates will be used later during personnel planning

Average Duration Estimation

In COCOMO, the schedule is determined by using the equation, for an organic type of software is

For other project types, the constants vary only slightly. The duration or schedule of the different phases is
obtained in the same manner as in effort distribution. The percentages for the different phases are given in
Table

In this COCOMO table, the detailed design, coding, and unit testing phases are combined
into one "programming phase."
overall size estimate for the project is 3 KDLOC, and the final effort estimate obtained
was 16.34 PM. As this is an organic system, the overall duration will be determined by
the equation
Using this we get the project duration D as

Using the preceding table, which gives the duration of the different phases as a percentage of the total project duration,
we can obtain the duration of the different phases. The duration of the different phases is:
 Software Size Metrics

• LOC (Lines of Code):

– Simplest and most widely used
metric.
– Comments and blank lines should not
be counted.

13
 Disadvantages of Using LOC

• Size can vary with coding style.

• Focuses on coding activity alone.
• Correlates poorly with quality and
efficiency of code.
• Penalizes higher level programming
languages, code reuse, etc.
14
 Function Point Metric

• Overcomes some of the shortcomings of

the LOC metric
• Proposed by Albrecht in early 80's:
– FP=4 #inputs + 5 #Outputs + 4
#inquiries +
10 #files + 10 #interfaces
• Input:
– A set of related inputs is counted as one input.

15
 Function Point Metric
• Output:
– A set of related outputs is counted as one output.
• Inquiries:
– Each user query type is counted.
• Files:
– Files are logically related data and thus can be
data structures or physical files.
• Interface:
– Data transfer to other systems.

16
 Function Point Metric (CONT.)

• adv:
– • Gives almost an actual value

– • Independent of Programming
language used

– • Eg. Function Count

17
 Empirical Size Estimation
Techniques
• Expert Judgement:
– An euphemism for guess made by an
expert.
– Suffers from individual bias.
• Delphi Estimation:
– overcomes some of the problems of
expert judgement.
18
 Expert judgement

• Experts divide a software product into

component units:
– e.g. GUI, database module, data
communication module, billing
module, etc.
• Add up the guesses for each of the
components.
19
 Delphi Estimation:

• Team of Experts and a coordinator.

• Experts carry out estimation
independently:
– mention the rationale behind
their estimation.
– coordinator notes down any
extraordinary rationale:
• circulates among experts.
20
 Delphi Estimation:

• Experts re-estimate.
• Experts never meet each other
– to discuss their viewpoints.

21
 Heuristic Estimation Techniques
• Single Variable Model:
– Parameter to be Estimated(effort,duration
etc.)=C1(constants ,data collected from past
projects)*e(characteristics of s/w such as size)^D1
• Multivariable Model:
– Assumes that the parameter to be
estimated depends on more than one
characteristic.
– Parameter to be Estimated=C1(Estimated
Characteristic)d1+ C2(Estimated
Characteristic)d2+…
– Usually more accurate than single
variable models. 22
 COCOMO Model

• COCOMO (COnstructive COst MOdel)

proposed by Boehm.
• Divides software product developments
into 3 categories:
– Organic
– Semidetached
– Embedded

23
 COCOMO Product classes
• Roughly correspond to:
– application, utility and system
programs respectively.
• Data processing and scientific programs are
considered to be application programs.
• Compilers, linkers, editors, etc., are utility
programs.
• Operating systems and real-time system
programs, etc. are system programs.
24
 Elaboration of Product classes
• Organic:
– Relatively small groups
• working to develop well-understood applications.
• Semidetached:
– Project team consists of a mixture of experienced
and inexperienced staff.
• Embedded:
– The software is strongly coupled to complex
hardware, or real-time systems.

25
 COCOMO Model (CONT.)

• For each of the three product categories:

– From size estimation (in KLOC), Boehm provides
equations to predict:
• project duration in months
• effort in programmer-months
• Boehm obtained these equations:
– examined historical data collected from a large
number of actual projects.

26
 COCOMO Model (CONT.)

• Software cost estimation is done

through three stages:
– Basic COCOMO,
– Intermediate COCOMO,
– Complete COCOMO.

27
 Basic COCOMO Model (CONT.)

• Gives only an approximate estimation:

– Effort = a1 (KLOC)a2
– Tdev = b1 (Effort)b2
• KLOC is the estimated kilo lines
of source code,
• a1,a2,b1,b2 are constants for different categories
of software products,
• Tdev is the estimated time to develop the
software in months,
• Effort estimation is obtained in terms
of person months (PMs).
28
Development Effort Estimation

• Organic :
– Effort = 2.4 (KLOC)1.05 PM
• Semi-detached:
– Effort = 3.0(KLOC)1.12 PM
• Embedded:
– Effort = 3.6 (KLOC)1.20PM
29
Development Time Estimation

• Organic:
– Tdev = 2.5 (Effort)0.38 Months
• Semi-detached:
– Tdev = 2.5 (Effort)0.35 Months
• Embedded:
– Tdev = 2.5 (Effort)0.32 Months
30
 Basic COCOMO Model (CONT.)

• Effort is Effort

somewhat super-
linear in
problem size.
Size

31
 Basic COCOMO Model (CONT.)

• Development time
– sublinear
Dev. Time
• product
function of size.
• When product size
18 Months
increases two times,
– development time does
14 Months
not double.
• Time taken:
– almost same for all the 30K
Size
60K

three product categories.

32
 Basic COCOMO Model (CONT.)

• Development time does not

increase linearly with product size:
– For larger products more parallel
activities can be identified:
• can be carried out simultaneously by
a number of engineers.

33
 Basic COCOMO Model (CONT.)

• Development time is roughly the same for

all the three categories of products:
– For example, a 60 KLOC program can be
developed in approximately 18 months
• regardless of whether it is of organic, semi-
detached,
or embedded type.
– There is more scope for parallel activities for
system and application programs,
• than utility programs.
34
 Example
• The size of an organic software product has
been estimated to be 32,000 lines of source code.

• Effort = 2.4*(32)1.05 = 91 PM
• Nominal development time = 2.5*(91)0.38 = 14
months

35
 Intermediate COCOMO

• Basic COCOMO model assumes

– effort and development time depend on product
size alone.
• However, several parameters affect effort
and development time:
• Reliability requirements
• Availability of CASE tools and modern facilities to
the developers
• Size of data to be handled
36
 Intermediate COCOMO

• For accurate estimation,

– the effect of all relevant parameters
must be considered:
– Intermediate COCOMO model
recognizes this fact:
• refines the initial estimate obtained by the
basic COCOMO by using a set of
15 cost drivers (multipliers).
37
 Intermediate COCOMO (CONT.)

• Cost driver classes:

– Product: Inherent complexity of the product,
reliability requirements of the product, etc.
– Computer: Execution time, storage
requirements, etc.
– Personnel: Experience of
personnel, etc.
– Development Environment: Sophistication of the
tools used for software development.
38
 Shortcoming of basic and intermediate
COCOMO models

• Both models:
– consider a software product as a single
homogeneous entity:
– However, most large systems are made up of
several smaller sub-systems.
• Some sub-systems may be considered as organic
type, some may be considered embedded, etc.
• for some the reliability requirements may be
high,
and so on.
39
 Complete COCOMO

• Cost of each sub-system is

estimated separately.
• Costs of the sub-systems are added to
obtain total cost.
• Reduces the margin of error in the final
estimate.

40
 Complete COCOMO Example

• A Management Information System (MIS) for an

organization having offices at several places across
the country:
– Database part (semi-detached)
– Graphical User Interface (GUI) part (organic)
– Communication part (embedded)
• Costs of the components are estimated separately:
– summed up to give the overall cost of the system.

41
 Staffing Level Estimation

• Number of personnel required during

any development project:
– not constant.
• Norden in 1958 analyzed many R&D
projects, and observed:
– Rayleigh curve represents the number
of full-time personnel required at any
time.
42
 Rayleigh Curve
Biju
2017-08-07 20:50:22
--------------------------------------------
r & d projects

• Rayleigh curve is Rayleigh Curve

specified by two
parameters: Effort

– td the time at
which the curve
reaches its
maximum td
Time
– K the total area
under the curve.
• L=f(K, td)
43
 Putnam’s Work:

• In 1976, Putnam studied the problem

of staffing of software projects:
– observed that the level of effort required in
software development efforts has a similar
envelope.
– found that the Rayleigh-Norden curve
• relates the number of delivered lines of code to effort
and development time.

44
 Putnam’s Work (CONT.) :

• Putnam analyzed a large number of army

projects, and derived the expression:
L=CkK1/3td4/3
– K is the effort expended and L is the
size in KLOC.
– td is the time to develop the software.
– Ck is the state of technology constant
• reflects factors that affect programmer
productivity.
45
 Putnam’s Work (CONT.) :

• Ck=2 for poor development

environment
– no methodology, poor documentation, and
review, etc.
• Ck=8 for good software
development environment
– software engineering principles used
• Ck=11 for an excellent environment
46
 Rayleigh Curve

• Very small number of engineers are

needed at the beginning of a
project
– carry out planning and specification.
• As the project progresses:
– more detailed work is required,
– number of engineers slowly increases
and reaches a peak.
47
 Rayleigh Curve

• Putnam observed that:

– the time at which the Rayleigh
curve reaches its maximum value
• corresponds to system testing and product
release.
– After system testing,
• the number of project staff falls till product
installation and delivery.
48
 Rayleigh Curve

• From the Rayleigh curve

observe that:
– approximately 40% of the area under
the Rayleigh curve is to the left of
td
– and 60% to the right.

49
 Effect of Schedule Change on Cost

• Using the Putnam's expression for L,

K=L3/Ck3td4
Or, K=C1/td4
• For the same product size, C1=L3/Ck3
is a constant.
• Or, K1/K2 = td24/td14

50
Effect of Schedule Change on Cost (CONT.)

• Observe:
– a relatively small compression in
delivery schedule
• can result in substantial penalty on human
effort.
• Also, observe:
– benefits can be gained by using fewer
people over a somewhat longer time span.
51
 Example

• If the estimated development time is 1

year, then in order to develop the
product in 6 months,
– the total effort and hence the
cost increases 16 times.
– In other words,
• the relationship between effort and the
chronological delivery time is highly
nonlinear. 51
Effect of Schedule Change on Cost (CONT.)

• Putnam model indicates extreme penalty

for schedule compression
– and extreme reward for expanding the
schedule.
• Putnam estimation model works
reasonably well for very large systems,
– but seriously overestimates the effort for
medium and small systems.

53
Effect of Schedule Change on Cost (CONT.)

• Boehm observed:
– “There is a limit beyond which the
schedule of a software project cannot
be reduced
by buying any more personnel or
equipment.”
– This limit occurs roughly at 75% of
the nominal time estimate.
54
 Effect of Schedule Change on Cost (CONT.)

• If a project manager accepts a customer

demand to compress the development
time by more than 25%
– very unlikely to succeed.
• every project has only a limited amount of parallel
activities
• sequential activities cannot be speeded up by
hiring any number of additional engineers.
• many engineers have to sit idle.

55
 Jensen Model

• Jensen model is very similar to

Putnam model.
– attempts to soften the effect of
schedule compression on effort
– makes it applicable to smaller and
medium sized projects.

56
 Jensen Model

• Jensen proposed the equation:

– L=CtetdK1/2
– Where,
• Cte is the effective technology constant,
• td is the time to develop the software, and
• K is the effort needed to develop the software.

57