THE COCOMO MODEL
COCOMO IS FOR CONSTRUCTIVE COST MODEL
It is a regression model based on LOC i.e number of Line of
Code
It is a procedural cost estimate model for software projects and
often used as a process of reliably predicting the various
parameters associated with making a project such as size,
effort, cost, time and quality.
It was proposed by Barry Boehm in 1970.
The key parameters which define the quality of any software
products, which are also an outcome of the COCOMO are
effort and schedule.
THE KEY PARAMETERS
Effort - Amount of labor that will be required to complete a task. It is
measured in person-months unit(PMs).
Schedule - Amount of time required for the completion of the job .It is
proportional to the effort put and is measured in the units of time such
as weeks, months.
To determine the initial effort E in person-months the equation used is of
the type is shown below.
E =a*(KLOC)b;
The value of the constant a and b are depends on the project type.
COCOMO PROJECTS
In COCOMO, projects are categorized into three types
1. Organic
2. Semidetached
3. Embedded
ORGANIC PROJECTS
A development project can be treated of the 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 experienced in
developing similar methods of projects.
Examples of this type of projects are simple business systems,
simple inventory management systems, and data processing
systems.
SEMIDETACHED PROJECTS
A development project can be treated with semidetached type if the
development consists of a mixture of experienced and inexperienced
staff.
Team members may have finite experience in related systems but
may be unfamiliar with some aspects of the order being developed.
Example of Semidetached system includes developing a new
operating system (OS), a Database Management System (DBMS), and
complex inventory management system.
EMBEDDED PROJECTS
A development project is treated to be of an embedded type, if the software
being developed is strongly coupled to complex hardware, or if the stringent
regulations on the operational method exist.
For Example: ATM, Air Traffic control.
BASIC COCOMO MODEL
According to Boehm, software cost estimation should be done
through three stages.
The basic COCOMO model provide an accurate size of the
project parameters.
The following expressions give the basic COCOMO estimation
model:
Where KLOC is the estimated size of the software product
indicated in Kilo Lines of Code,
a,b,c,d are constants for each group of software products,
Tdev (Development Time) is the estimated time to develop the
software, expressed in months
𝐸𝑓𝑓𝑜𝑟𝑡 = 𝑎(𝐾𝐿𝑂𝐶)𝑏
-> PMs
𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑇𝑖𝑚𝑒 = 𝑐(𝐸𝑓𝑓𝑜𝑟𝑡)𝑑
𝐴𝑣𝑒𝑟𝑎𝑔𝑒 𝑆𝑡𝑎𝑓𝑓 =
𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦 =
𝐸𝑓𝑓𝑜𝑟𝑡
(
)
𝑑𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑡𝑖𝑚𝑒
𝐾𝐿𝑂𝐶
(
)
𝐸𝑓𝑓𝑜𝑟𝑡
->months/weeks
-> no of people
-> KLOC per Month
BASIC COCOMO MODEL
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
Semi-detached: Effort = 3.0(KLOC) 1.12 -> PM
Embedded: Effort = 3.6(KLOC) 1.20
-> PM
For the three classes of software products, the formulas for estimating the
development time based on the effort are given below:
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
QUESTION ?
Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached &
embedded.
Solution: The basic COCOMO equation takes the form:
Effort = a*(KLOC)b PM
Development Time = c*(efforts)d Months
Estimated Size of project = 400 KLOC
(i)Organic Mode
Effort = 2.4 * (400)1.05 = 1295.31 PM
Development Time = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode
Effort = 3.0 * (400)1.12=2462.79 PM
Development time = 2.5 * (2462.79)0.35=38.45 PM
QUESTION CONTINUED
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM
INTERMEDIATE COCOMO MODEL
The basic Cocomo model assumes that the effort is only a function of the
number of lines of code and some constants evaluated according to the
different software systems.
However, in reality, no system’s effort and schedule can be solely
calculated on the basis of Lines of Code. For that, various other factors
such as reliability, experience, Capability.
These factors are known as Cost Drivers and the Intermediate Model
utilizes 15 such drivers for cost estimation. Classification of Cost Drivers
and their attributes.
Cost Drivers
Required software reliability extent
Size of the application database
The complexity of the product
Run-time performance constraints
Memory constraints
The volatility of the virtual machine environment
Required turnabout time
Analyst capability
Software engineering capability
Applications experience
Virtual machine experience
Programming language experience
Use of software tools
Application of software engineering methods
Required development schedule
INTERMEDIATE COCOMO EQUATION:
𝑬𝒇𝒇𝒐𝒓𝒕 = 𝒂(𝑲𝑳𝑶𝑪)𝒃 × 𝑬𝑨𝑭 → (𝑬𝒇𝒇𝒐𝒓𝒕 𝑨𝒅𝒋𝒖𝒔𝒕𝒎𝒆𝒏𝒕 𝑭𝒂𝒄𝒕𝒐𝒓)
𝑫𝒆𝒗𝒆𝒍𝒐𝒑𝒎𝒆𝒏𝒕 𝑻𝒊𝒎𝒆 = 𝒄(𝑬𝒇𝒇𝒐𝒓𝒕)𝒅
->months/weeks
ADVANCED/ DETAILED COCOMO
Detailed COCOMO incorporates all characteristics of the intermediate version
with an assessment of the cost driver’s impact on each step of the software
engineering process.
The detailed model uses different effort multipliers for each cost driver
attribute. In detailed COCOMO, the whole software is divided into different
modules and then we apply COCOMO in different modules to estimate effort
and then sum the effort.
The Six phases of detailed COCOMO are:
Planning and requirements
System design
Detailed design
Module code and test
Integration and test
Cost Constructive model
FUNCTIONAL POINT (FP) ANALYSIS
Function Point Analysis was initially developed by Allan J. Albercht in
1979 at IBM and it has been further modified by the International
Function Point Users Group (IFPUG).
The initial Definition is given by Allan J. Albrecht:
FPA gives a dimensionless number defined in function points which we
have found to be an effective relative measure of function value
delivered to our customer.
Function Point Analysis (FPA) is a method or set of rules of Functional
Size Measurement.
It assesses the functionality delivered to its users, based on the user’s
external view of the functional requirements. It measures the logical
view of an application, not the physically implemented view or the
internal technical view.
TYPES OF FP ATTRIBUTES
Measurements Parameters
Examples
1.Number of External Inputs(EI)
Input screen and tables
2. Number of External Output (EO)
Output screens and reports
3. Number of external inquiries (EQ)
Prompts and interrupts.
4. Number of internal files (ILF)
Databases and directories
5. Number of external interfaces (EIF)
Shared databases and shared routines.
TYPES OF FP ATTRIBUTES
FPA CHARACTERISTICS
1. FP characterizes the complexity of the software system and hence
can be used to depict the project time and the manpower
requirement.
2.
The effort required to develop the project depends on what the
software does.
3.
FP is programming language independent.
4. FP method is used for data processing systems, business systems like
information systems.
5. The five parameters mentioned above are also known as information
domain characteristics.
6.
All the parameters mentioned above are assigned some weights that
have been experimentally determined and are shown in Table.
FPA PARAMETERS
FUNCTIONAL POINT CALCULATION
𝑭𝑷 = 𝑼𝑭𝑷 × 𝑪𝑨𝑭
where, 𝑪𝑨𝑭 ≡ 𝑪𝒐𝒎𝒑𝒍𝒆𝒙𝒊𝒕𝒚 𝑨𝒅𝒋𝒖𝒔𝒕𝒎𝒆𝒏𝒕 𝑭𝒂𝒄𝒕𝒐𝒓
𝑼𝑭𝑷 ≡ 𝑼𝒏𝒂𝒅𝒋𝒖𝒔𝒕𝒆𝒅 𝑭𝒖𝒏𝒄𝒕𝒊𝒐𝒏𝒂𝒍 𝑷𝒐𝒊𝒏𝒕
𝑪𝑨𝑭 = 𝟎. 𝟔𝟓 + (𝟎. 𝟎𝟏 ×
𝑭𝒊 )
∑(fi) is the sum of all 14 questionnaires and show the complexity
adjustment value/ factor-CAF (where i ranges from 1 to 14). Usually, a
student is provided with the value of ∑(fi)
14 QUESTIONNAIRES
CALCULATING UFP
FP EXAMPLE
Example: Compute the function point, productivity, documentation, cost per
function for the following data:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Number of user inputs = 24
Number of user outputs = 46
Number of inquiries = 8
Number of files = 4
Number of external interfaces = 2
Effort = 36.9 p-m
Technical documents = 265 pages
User documents = 122 pages
Cost = $7744/ month
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.
SOLUTION
Measurement Parameter
Count
Weighing factor
1. Number of external inputs (EI)
24
*
4 = 96
2. Number of external outputs (EO)
46
*
4 = 184
3. Number of external inquiries (EQ)
8
*
6 = 48
4. Number of internal files (ILF)
4
*
10 = 40
5. Number of external interfaces (EIF) Count-total →
2
*
5
378
=
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.
So fi = fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43
FP =UFP * [0.65 + 0.01 *∑(fi)]
= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408
SOLUTION CONTINUED
Total pages of documentation = technical document + user document
= 265 + 122 = 387 pages
Documentation = Pages of documentation/FP
= 387/408 = 0.94
BENEFITS OF FPA




FPA is a tool to determine the size of a purchased application
package by counting all the functions included in the package.
It is a tool to help users discover the benefit of an application
package to their organization by counting functions that
specifically match their requirements.
It is a tool to measure the units of a software product to support
quality and productivity analysis.
It s a vehicle to estimate the cost and resources required for
software development and maintenance.
It is a normalization factor for software comparison.
THE DRAWBACK OF FPA
It requires a subjective evaluation and involves many judgments.
Many cost and effort models are based on LOC, so it is necessary to
change the function points.
Compared to LOC, there are less research data on function points.
Run after creating the design specification.
With subjective judgment, the accuracy rate of the assessment is low.
Due to the long learning curve, it is not easy to gain proficiency.
This is a very time-consuming method
THE END