Constructive Cost Model - II (COCOMO-II)

CONSTRUCTIVE COST MODEL-II
(COCOMO-II)
Software Engineering
CS-16106
Group - 7
Course Coordinator:
Dr. Anoj Kumar
AssociateProfessor,
Department ofCSED, MNNIT,
Allahabad
• Aman Sharma (20178051)
• Harshit Agarwal (20178042)
• Prakhar Mishra (20178002)
• Shivam Shrivastava (20178025)

Introduction
COCOMO-II is the revised version of the Cocomo (Constructive Cost Model) and is developed at University of
Southern California. It is the model that allows one to estimate the cost, effort and schedule when planning a
new software development activity.
The four main elements of the COCOMO II strategy are:
• Preserve the openness of the original COCOMO
• Key the structure of COCOMO II to the future software marketplace sectors described earlier
• Key the inputs and outputs of the COCOMO II sub models to the level of information available
• Enable the COCOMO II sub models to be tailored to a project's particular process strategy.
All of its relationships and algorithms will be publicly available. To support the software marketplace sectors
above, COCOMO II provides a family of increasingly detailed software cost estimation models, each tuned to
the sectors' needs and type of information available to support software cost estimation.

Table of Content
1) Sub Models 4-5
2) Lines of Code 6
3) Function Points 7-8
4) Scaling Drivers 9-10
5) Cost Drivers 11-12
6) Effort Estimates and EAF 13-14
7) Schedule Equation, Breakage 15
8) Tool Analysis 16-19
Name Slide No(s)

• The sub-models in COCOMO-II are:
• APPLICATION COMPOSITION MODEL:
➢ Supports prototyping projects and projects where there is extensive reuse.
➢ Based on standard estimates of developer productivity in application (object) points/month.
➢ Takes CASE tool use into account.
➢ PM = (NAP * ( 1 - %reuse/100 ) ) / PROD . ( PM = effort in person-month , NAP = number of application
points, and PROD = productivity ).
• EARLY DESIGN MODEL :
• Estimates can be made after the requirements have been agreed.
• Based on a standard formula for algorithmic models
PM = A x (Size^b) x M where
M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED;
A = 2.94 in initial calibration, Size in KLOC, B varies from 1.1 t o1.24 depending on novelty of the project,
development flexibility, risk management
COCOMO II Sub Models
PRAKHAR MISHRA (20178002)

• REUSE MODEL:
➢ Takes into account black box code that is reused without change and code that has to be adapted to integrate
it with new code. There is two versions
➢ Black box reuse where code is not modified. An effort estimate (PM) is computed.
➢ White-box reuse where code is modified, A size estimate equivalent to the number of lines of new source
code is computed. This then adjusts the size estimate for new code.
➢ When code has to be understood and integrated:
▪ ESLOC = ASLOC * (1 – AT/100) *AAM.
▪ ASLOC and AT as before.
▪ AAM is the adaptation adjustment multiplier computed from the costs of changing the reused code,
the costs of understanding how to integrate the code and the costs of reuse decision making.
• POST-ARCHITECTURE MODEL: Used once the system architecture has been designed and more information about
the system is available. The code size is estimated as :
• Number of lines of new code to be developed.
• Estimates of equivalent number of lines of new code computed using the reuse model.
• An estimate of the number of lines of new code computed using the reuse model.
• An estimate of the number of lines of code that have to be modified according to requirements changes.

Source Lines of Code (SLOC/LOC)
The COCOMO calculations are based on your 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
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.

Function Points
The function point cost estimation approach is based on the amount of functionality in a software project and a
set of individual project factors. Function points are useful estimators since they are based on information that is
available early in the project life cycle. A brief summary of function points and their calculation in support of
COCOMO II is as follows. Function points measure a software project by quantifying the information processing
functionality associated with major external data or control input, output, or file types.
User Function
Types
SHIVAM SHRIVASTAVA (20178025)

Converting Function Points to Lines of Code
To determine the nominal person months for the Early Design model, the
unadjusted function points have to be converted to source lines of code in
the implementation language (assembly, higher order language, fourth-
generation language, etc.) in order to assess the relative conciseness of
implementation per function point. COCOMO II does this for both the
Early Design and Post-Architecture models by using tables such as those
found in [Jones 1991] to translate Unadjusted Function Points into
equivalent SLOC.

Scaling Drivers
In the COCOMO II model, some of the most important factors contributing to a project's duration and cost are the
Scale Drivers. You set each Scale Driver to describe your project; these Scale Drivers determine the exponent used in
the Effort Equation.
The 5 Scale Drivers are:
• Precedentedness (PREC) : how novel the project is for the organization
• Development Flexibility (FLEX) : development flexibility (e.g. rigidity of compliance to requirements)
• Architecture / Risk Resolution (RESL) : thoroughness of design and risk resolution
• Team Cohesion (TEAM)
• Process Maturity (PMAT) : maturity with respect to the CMMI questionnaire
Note that the Scale Drivers have replaced the Development Mode of COCOMO 81. The first two Scale Drivers,
Precedentedness and Development Flexibility actually describe much the same influences that the original
Development mode did.

Scale factors and
description
Constant values
of different scale
factors
according to
SLOC

Cost Drivers
COCOMO II has 17 cost drivers – you assess your project, development environment, and team to set each cost
driver. The cost drivers are multiplicative factors that determine the effort required to complete your software
project. For example, if your project will develop software that controls an airplane's flight, you would set the
Required Software Reliability (RELY) cost driver to Very High. That rating corresponds to an effort multiplier of
1.26, meaning that your project will require 26% more effort than a typical software project. COCOMO II
defines each of the cost drivers, and the Effort Multiplier associated with each rating.
AMAN SHARMA (20178051)

Constant values of
different cost
drivers according
to SLOC

Developing Effort Estimates
The COCOMO II model makes its estimates of required effort (measured in Person-Months -- PM) based
primarily on your estimate of the software project's size (as measured in thousands of SLOC, KSLOC)):
Effort = 2.94 * EAF * (KSLOC)E
Where
EAF is the Effort Adjustment Factor derived from the Cost Drivers
E is an exponent derived from the five Scale Drivers
As an example, a project with all Nominal Cost Drivers and Scale Drivers would have an EAF of 1.00 and
exponent, E, of 1.0997. Assuming that the project is projected to consist of 8,000 source lines of code,
COCOMO II estimates that 28.9 Person-Months of effort is required to complete it:
Effort = 2.94 * (1.0) * (8)1.0997 = 28.9 Person-Months
E＜1.0：the project exhibits economies of scale.
E＝1.0：the economies and diseconomies of scale are in balance.
E＞1.0：the project exhibits diseconomies of scale.

Effort Adjustment Factor
The Effort Adjustment Factor in the effort equation is simply the product of the effort multipliers corresponding to
each of the cost drivers for your project.
For example, if your project is rated Very High for Complexity (effort multiplier of 1.34), and Low for Language
& Tools Experience (effort multiplier of 1.09), and all of the other cost drivers are rated to be Nominal (effort
multiplier of 1.00), the EAF is the product of 1.34 and 1.09.
Effort Adjustment Factor = EAF = 1.34 * 1.09 = 1.46
Effort = 2.94 * (1.46) * (8)1.0997 = 42.3 Person-Months

Schedule Equation
The COCOMO II schedule equation predicts the number of months required to complete your software project. The
duration of a project is based on the effort predicted by the effort equation:
Duration = 3.67 * (Effort) SE
Where:
• Effort Is the effort from the COCOMO II effort equation
• SE Is the schedule equation exponent derived from the five Scale Drivers
Continuing the example, and substituting the exponent of 0.3179 that is calculated from the scale drivers, yields an
estimate of just over a year, and an average staffing of between 3 and 4 people:
Duration = 3.67 * (42.3) 0.3179 = 12.1 months
Average staffing = (42.3 Person-Months) / (12.1 Months) = 3.5 people
Breakage
COCOMO II uses a breakage percentage, BRAK, to adjust the effective size of the product. Breakage reflects the
requirements volatility in a project. It is the percentage of code thrown away due to requirements volatility. For
example, a project which delivers 100,000 instructions but discards the equivalent of an additional 20,000
instructions has a BRAK value of 20. This would be used to adjust the project’s effective size to 120,000 instructions
for a COCOMO II estimation. The BRAK factor is not used in the Applications Composition model, where a certain
degree of product iteration is expected, and included in the data calibration.

TOOL ANALYSIS
➢ SLOC (size in single line of code) calculation measure: The line of code generated by software activities and the source
program code which is used to measuring of linage (most commonly), also instruction number of object code. delivered system
documentation phases. The calculation of single line of code includes design and analysis, written program, instruments tests
and documentation of system in person-month.
➢ Measures in Object Oriented concepts: Focus on C&K[5] and MOOD[6] Measures to identity weather a design is reasonable
or not reasonable. C&K gives six class level Metrics: Each class weighted method, inheritance tree depth, total children; object
classes coupling, responses for a class, methods having lack of cohesion.
➢ Software project Cost Estimation: Divide the software into components. This is called splitting or grouping of software which
not require unnecessary internal knowledge and his helps to configured to complete word as required, hence by this way, it is
easy and convenient for developer and it provides great convenient for estimation.
1) After grouping, application having two relationships:
1) Integer relationship b/w classes with in an individual group.
2) The relationship b/w various groups are previously created
2) Now, for individual group, often details design completion each group will have.
1) Complete class diagram.
2) Complete sequence diagram.
3) Now, use both of above complete class and sequence diagram, i.e. as follow
1) Use number of class in class diagram.
2) The number of methods in all class.
HARSHIT AGARWAL (20178042)

➢ For Sequence Diagram: First, you have to enter number of methods, that are with your corresponding group which is
currently used process, whose sequence diagram are analyzed for calculating single line of code. And then our software
window repeats that number of time for the analysis of all sequence diagrams. NOTE: The methods analyzed, needed
to input there name or record their name to database.
➢ Coding File Analysis: Browse Coding files to software for calculating total single line of code in file, this software
automatically remove single line comments, multiline comments and white/ blank lines, It imports all files to their database
and auto record all the results to database, including those SLOC which are already calculated.
➢ Total SLOC Calculation: Now, have all method names that are analyze in class diagrams analysis & sequence diagram
analysis and also total SLOC calculation in coding file analysis. This data is used to calculate Significant number of
accurate SLOC, Software auto recognize all the methods by name and as it have all coding files loaded in it.

Demo of
Tool Usage
(Input)

Demo of
Tool Usage
(Results)

References
● http://info.usherbrooke.ca/llavoie/enseignement/References/C
ocomoII_Reference_Manual.pdf
● https://en.wikipedia.org/wiki/COCOMO
● https://www.geeksforgeeks.org/software-engineering-cocomo-ii-
model/
● https://sunset.usc.edu/research/COCOMOII/beta_software/mod
el_manual_000614.pdf
● http://www.dmi.usherb.ca/~frappier/IFT721/COCO
MOII.PDF

Constructive Cost Model - II (COCOMO-II)

More Related Content

What's hot

Similar to Constructive Cost Model - II (COCOMO-II)

Recently uploaded

Constructive Cost Model - II (COCOMO-II)