COCOMO MODEL
TABLE OF CONTENTS
1. What is COCOMO Model?
2. Objective of COCOMO Model
3. Types of COCOMO Model
3.1 Basic COCOMO Model
3.2 Intermediate COCOMO Model
3.3 Complete COCOMO Model
EFFORT ESTIMATE:
Effort estimation is essential in different departments in an organization various
points of a project lifecycle. Presales teams need effort estimation in order to cost
price custom software.
Project managers need it in order to allocate resources and time plans a
project.
Usually, software development is priced based on the person days, it requires
in order to be built, multiplied by a daily person day rate. Without effort
estimation pricing is impossible. Also, in order to plan a project and inform
the project owners about deadlines and milestones you have to know how
much effort the job requires. Finally, initial effort estimation shows if you
have the resources to finish the project within customer or project owner
predefined time limits, based on your available man power.
The accuracy of effort estimation depends on available information at various stages
of the software development life cycle. Usually, less information is available before
you the project is started and more information is available while working in the
project.
Most of the times, you can have more accurate effort estimation after requirement
analysis. However, initial effort estimation at early project stages is sometimes more
important. Example, a financial offer is given based on early stage effort estimation.
The price given give will probably bind you for the whole project, so it is important to
have a good estimation from the beginning.
Although it is obvious that accurate effort estimation is crucial, most of the times
people fail to predict well. Actually it is amazing how often and how much effort
estimation goes wrong. Approximately 40% of industry software projects that get
cancelled are cancelled due to, partly or completely, failures in effort time, it is more
difficult to have one a good estimate for a large project.
TYPES OF SOFTWARE PROJECTS - ORGANIC,
SEMIDETACHED AND EMBEDDED SOFTWARE PROJECTS:
Software Development Projects can be classified based on the development
complexity: organic, semidetached, and embedded. In order to classify a product into
the identified categories ,Roughly speaking, these three product classes correspond to
programs, utility and system programs Normally, data processing gras are considered
to be application programs. Compilers, linkers, etc., are utility programs. Operating
systems and real-time system program etc. are system programs. System programs
interact directly with the hardware and typically involve meeting timing constraints
and concurrent processing.
ORGANIC:
A development project can be considered of organic type, if the project deals with
developing a well understood application program, the size of the development team
is reasonably small, and the team members are developing similar types of projects.
SEMI DETACHED:
A development project can be considered of semidetached type, if the development
consists of a mixture of experienced and inexperienced staff. Team members may
have limited experience on related systems but may be unfamiliar with some aspects
of the system being developed.
EMBEDDED:
A development project is considered to be of embedded type, if the software being
developed is strongly coupled to complex hardware, or if the stringent regulations on
the operational procedures exist.
BASIC COCOMO MODEL:
The basic COCOMO model is a single-valued, static model that computes software
development effort as a function of program size expressed in estimated lines of code
(LOC). The basic COCOMO model gives an approximate estimate of the project
parameters. The basic COCOMO estimation model is given by expressions:
Effort = a1 (KLOC)a2 PM
Tdev = b1 x (Effort)b2 Months
KLOC is the estimated size of the software product expressed in Kilo Lines of Code,
a1, a2, b1, b2 are constants for each category of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in
person months (PMs).
The effort estimation is expressed in units of person-months (PM). It is the area under
the person-month plot. It should be carefully noted that an effort of 100 PM does not
imply that 100 persons should work for 1 month nor does it imply that 1 person
should be employed for 100 months, but it denotes the area under the person-month
curve.
Every line of source text should be calculated as one LOC irrespective of the actual
number of instructions on that line. Thus, if a single instruction spans several lines, it
is considered to be nLOC. The values of a1, a2, b1, b2 for different categories of
products as given by Boehm are summarized below. He derived the above
expressions by examining historical data collected from a large number of actual
projects.
Development
Project Characteristics
Mode
Size Innovation Deadline/constraints Dev. Environment
Organic Small Little Not tight Stable
Semi-detached Medium Medium Medium Medium
Complex
Embedded Large Greater Tight hardware/customer
interfaces
Development
a1 a2 b1 b2
Mode
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.0 2.5 0.32
INTERMEDIATE COCOMO MODEL:
The intermediate COCOMO model computes software development effort as a
function of program size and a set of "cost drivers" that include subjective
assessments of product, hardware, personnel, and project attributes.In intermediate
mode development effort equation becomes :
Effort = a(KLOC)bC
C (effort adjustment factor) is calculated simply multiplying the values of cost
drivers. So the intermediate model is more accurate than the basic model.
Product attributes
1. required software reliability
2. size of application data base
3. complexity of the product
Hardware attributes
4. Run-time performance constraints
5. Memory constraints
6. Volatility of the virtual machine environment
7. Required turnaround time
Personnel attributes
8. Analyst capability
9. Software engineer capability
10. Applications experience
11. Virtual machine experience
12. Programming language experience
Project attributes
13. Use of software tool
14. Application of software engineering methods
15. Required development schedule
The steps in producing an estimate using the intermediate COCOMO model are:
Cost Extra
Very Low Low Nominal High Very High
Driver High
ACAP Analyst Capability 1.46 1.19 1.00 0.86 0.71 -
AEXP Applications Experience 1.29 1.13 1.00 0.91 0.82 -
CPLX Product Complexity 0.70 0.85 1.00 1.15 1.30 1.65
DATA Database Size - 0.94 1.00 1.08 1.16 -
LEXP Language Experience 1.14 1.07 1.00 0.95 - -
MODP Modern Programming Practices 1.24 1.10 1.00 0.91 0.82 -
PCAP Programmer Capability 1.42 1.17 1.00 0.86 0.70 -
RELY Required Software Reliability 0.75 0.88 1.00 1.15 1.40 -
SCED Required Development Schedule 1.23 1.08 1.00 1.04 1.10 -
STOR Main Storage Constraint - - 1.00 1.06 1.21 1.56
TIME Execution Time Constraint - - 1.00 1.11 1.30 1.66
TOOL Use of Software Tools 1.24 1.10 1.00 0.91 0.83 -
TURN Computer Turnaround Time - 0.87 1.00 1.07 1.15 -
VEXP Virtual Machine Experience 1.21 1.10 1.00 0.90 - -
VIRT Virtual Machine Volatility - 0.87 1.00 1.15 1.30 -
Development
A B C D
Mode
Organic 3.2 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
COMPLETE COCOMO MODEL:
A major shortcoming of both the basic and intermediate COCOMO models is that
they consider a software product as a single homogeneous entity. However, most
large systems are made up several smaller sub-systems. These sub-systems may have
widely different characteristics.not only that the inherent development complexity of
the subsystems may be different, but also for some subsystems the reliability
requirements may be high, for some the development team might have no previous
experience of similar development, and so on. 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.
The following development project can be considered as an example application of
the complete COCOMO model. A distributed Management Information System
(MIS) product for an organization having offices at several places across the country
can have the following sub-components:
Database part
Graphical User Interface (GUI) part
Communication part
Of these, the communication part can be considered as embedded software. The
database part could be semi-detached software, and the GUI part organic software.
The costs for these three components can be estimated separately, and summed up to
give the overall cost of the system.
COCOMO MODEL
FOR
COURSE RECOMMENDATION SYSTEM
COCOMO MODEL:
COCOMO (Constructive Cost Estimation Model) was proposed by Boehm.
According to Boehm, software cost estimation should be done through three stages:
Basic COCOMO, Intermediate COCOMO, and Complete COCOMO.
OBJECTIVE:
This Course recommendation system is to make user familiar with the variety
of courses of his/her interests in the field of IT.
This consists of mainly three modules. They are:
Admin
User
ADMIN:
This module is the main module which coordinates the total system. The
options given to admin are:
Login
Change Password
Maintain home page
Validations
Logout
USER:
Options given to a user are:
Login
Edit user Information
Change password
Browse Information
Submit queries
Logout
BASIC COCOMO MODEL:
Mode: Semi-detached
As the Course Recommendation system is an organic software project the
estimation factor in the basic model is KLOC. The KLOC for different modules in
our project is:
NAME OF THE MODULE LOC FILES REQUIRED
Registration form 800 1PHP
Login 800 1HTML,1JS
Details of donation 1000 2HTML,2JS
Website 1000 2HTML,1CSS
ADMINISTRATION KLOC FILES REQUIRED
Blood bank Manager 1500 1PHP
Database related to blood donor 500 2HTML,1JS
details
Effort =
1.0
3.6*(7.5) PM
Request management 1000 2HTML,3JS
Notficaton of blood bank camps 900 1HTML,1CSS
The total Kilo Lines of Code (KLOC) for the project is 7.5
We assume that the average salary =20,000/- For the basic model
Effort = a1 * (KLOC)a2 PM Tdev = b1 * (Effort)b2 Months KLOC = 7.5
a1 = 3.6 a2 = 1.0 b1 = 2.5 b2 = 0.32
= 27 PM
Tdev = 2.5* (27)0.32 Months
= 7.3 Months
~ 7 Months
Cost = Average Salary * No. of Months
= 20,000 *7
= 1,40,000/-
Therefore cost required to develop the product is 1,40,000/-
INTERMEDIATE COCOMO MODEL:
In the intermediate COCOMO model in addition to the KLOC, the additional
estimation factor is cost driver. As Course Recommendation system is an organic
software project the estimation factors in the intermediate model are KLOC and cost
drivers.
COST DRIVERS VALUES
Low application experience 1.13
Low product complexity 0.85
High Database size 1.08
Very low modern programming practices 1.24
Low Required Development Schedule 1.08
Other cost drivers assumed to be nominal 1.00
Mode: semi-detached
Cost driver( C )=1.13*0.85*1.08*1.24*1.08*0.87*1.21*0.87*1
=1.2723
Effort=a*( KLOC )b *C PM
T dev=c*(Effort)D Months
KLOC=5.08
a=3.0
b=1.12
C=1.21
c=2.5
D=0.35
Effort =3.0*(5.08)1.12 *1.2723 PM
=23.5655 PM
~24PM
T dev=2.5*(24)0.35
=7.6035Months
~8 Months
Cost=Average salary*no. of months
=20,000*8
=1,60,000/-
Therefore cost required to develop the product is 1,73,400/-
COMPLETE COCOMO MODEL:
In complete COCOMO model the whole project is divided into two similar
subsystems. They are:
1. Database part
2. Graphical user interface part
3. Communication part
MODULES ESTIMATED(LOC)
Database part 4000
Graphical user interface part 5000
Communication part 3000
The effort of these subsystems is calculated using intermediate COCOMO model.
DATABASE PART:
Mode is organic
The total kilo lines of code are 4
Effort=a1*(KLOC)^a2 PM
=2.4*(4)1.05
=10.28
~10 PM
T dev=2.5*(10)0.38
= 5.9 Months =~6 Months
Cost=6*20,000=1,20,000/-
GRAPHICAL USER INTERFACE:
The GUI part which is considered as embedded software consists of following
module
The total kilo lines of code are 5
Effort= a1*(KLOC)a2 PM
T dev=b1*(Effort)b2Months
KLOC=5
a1=3.6
a2=1.20
b1=2.5
b2=0.35
Effort=3.6*(5)1.20
=24.8 PM
=~25 PM
T dev=2.5*(25)0.35
=7.7
~8 Months
Cost=Average salary*no. of months
=20,000*8
=1, 60,000/-
COMMUNICATION PART
The communication part which is considered as software consists of the following
modules.
The total kilo lines of code(KLOC) are 3
A1=3.0
KLOC=3
A2=1.12
B2=0.32
B1=2.5
Effort=3.0*(3)1.12
=10.26
~10 PM
Tdev=2.5*(10)0.32
=5.22
~5 Months
Cost =average salary*no. of months
=20,000*5
=1,00,000 /-
AFTER INTEGRATION:
MODULES EFFORT TIME BUDGET
Data base part 10 6 1,20,000
GUI part 25 8 1,60,000
Communication part 10 5 1,00,000
Total 45 PM 19 Months 3,80,000/-
