COCOMO MODEL

COCOMO MODEL:The COCOMO (Constructive Cost Estimation Model) is proposed by DR. Berry Boehm in 1981 and that's why it is also known as COCOMO'81. It is a method for evaluating the cost of software package. According to him software cost estimation should be done through three stages: 

 

COCOMO models depend upon the two main equations:

1. Development Effort : MM = a * KDSI b
   
   Which is based on MM - man-month / person month / staff-month is one month of effort by one person.
   
   Note: In COCOMO'81, there are 152 hours per Person month. According to organization this values may differ from the standard by 10% to 20%.
    
2. Efforts and Development Time (TDEV) : TDEV = 2.5 * MM c
   
   Note: The coefficients a, b and c depend on the mode of the development.

DEVELOPMENT MODES:

There are three modes of development:

1. Organic Mode:
• Relatively Small, Simple Software projects.
• Small teams with good application experience work to a set of less than rigid requirements.
• Similar to previously developed projects.
• Relatively small and require little innovation.

2. Semidetached Mode:
• Intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.

 

3. Embedded Mode:
• Software projects that must be developed within set of tight hardware, software and operational Constraints.

Development Mode with Project Characteristics:

Development Mode                                          Project Characteristics

	Size	Innovation	Deadline	Dev. Environment
ORGANIC	Small	Little	Not Tight	Stable
SEMI-DITACHED	Medium	Medium	Medium	Medium
EMBEDDED	Large	Greater	Tight	Complex Hardware

The values of a1, a2, b1, b2 for different categories of products (i.e. organic, semidetached, and embedded) as given by Boehm [1981] are summarized below. He derived the above expressions by examining historical data collected from a large number of actual projects.


BASIC COCOMO MODEL: Basic COCMO Model is good for quick, early, rough order of magnitude estimate of software cost. It does not account for differences in hardware constraints, personal Quality and experience, use of modern tools and techniques, and other project attribute known to have a significant influence on software cost, which limits its accuracy. It gives an approximate estimate of the project parameters. The basic COCOMO estimation model is given by the following expressions:

Effort = a₁ x (KLOC)^a₂PM

Tdev = b₁ x (Effort)^b₂ Months      

Software Project	a1	a2	b1	b2
Organic	2.4	1.05	2.5	0.38
Semi-Detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

Where,

• KLOC is the estimated size of the software product expressed in Kilo Lines of Code,
   
• a₁, a₂, b₁, b₂ 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). 

Estimation of development effort:

For the three classes of software products, the formulas for estimating the effort based on the code size are shown below:

Organic: Effort = 2.4(KLOC)^1.05 PM

The effort estimation is expressed in units of person-months (PM). It is the area under the person-month plot as shown in figure below. 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.

From the following figure which shows a plot of estimated effort versus product size. We can observe that the effort is somewhat superlinear in the size of the software product. Thus, the effort required to develop a product increases very rapidly with project size. 

 

Now the following figure plots the development time versus the product size in KLOC can be observed that the development time is a sublinear function of the size of the product, i.e. when the size of the product increases by two times, the time to develop the product does not double but rises moderately.


Note: It is to be noted that the effort and the duration estimations obtained using the COCOMO model are called as nominal effort estimate and nominal duration estimate.

Let's see an Example:

Problem: 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 engineers be Rs. 15,000/- per month. Determine the effort required to develop the software product and the nominal development time.

Solution: As per the basic COCOMO estimation formula for organic software:

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

Cost required to develop the product = 14 * 15,000
                                                  = Rs. 210,000/-

INTERMEDIATE COCOMO MODEL: The intermediate COCOMO model takes the basic COCOMO model as its starting point which means that it is slightly different coefficients for the effort equation than the Basic model. After that it multiplies the basic estimate by an Effort Adjustment Factor which is calculated as the product of 15 multipliers (cost drivers) which take into account factors such as required product reliability, database size, execution and storage constraints, personnel aptitude, and the use of software tools. It produces better results than the Basic model because the user supplies settings for cost drivers that determine the effort and duration of the software projects. The Intermediate model also allows the system to be divided and estimated in components. DSI values and cost drivers can be chosen for individual components instead of for the system as a whole.

Effort Adjustment factor

The effort adjustment factor use 15 cost drivers that are grouped into four categories:

1. Product
2. Computer
3. Personnel
4. Project

Note: Each cost driver has been rated on a six-point ordinal scale ranging from low to high importance. Product of all effort multipliers leads to EAF.

Estimation of development effort:

For the three classes of software products, the formulas for estimating the effort based on the code size are shown below:

 Effort = a₁ x (KLOC)^a₂PM

 Tdev = b₁ x (Effort)^b₂ Months     
 PM: Person Months

Software Project	a1	a2	b1	b2
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

DETAILED/ADVANCED 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.
The Detailed COCOMO Model differs from the Intermediate COCOMO model in that it uses effort multipliers for each phase of the project. These phase dependent effort multipliers yield better estimates because the cost driver ratings may be different during each phase.
In Advanced COCOMO Model the cost of each subsystem is estimated separately. This approach reduces the margin of error in the final estimate.
Example: 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.

Advantages of COCOMO Model:

1. COCOMO is transparent, one can see how it works unlike other models such as SLIM
2. Drivers are particularly helpful to the estimator to understand the impact of different factors that affect project costs.

Limitations of COCOMO  Model:

1. It is hard to accurately estimate KDSI early on in the project, when most effort estimates are required.
2. KDSI, actually, is not a size measure it is a length measure.
3. Extremely vulnerable to mis-classification of the development mode.
4. Success depends largely on tuning the model to the needs of the organization, using historical data which is not always available.