SEN-22413-Unit 4-Software Project Estimation

Unit No IV
Software Project Estimation [16 Marks]
Q1. Define management spectrum and enlist characteristics of software. OR Explain 4 P‘s
software project management spectrum OR Define management spectrum & explain people,
product, process & project in detail.
Ans:
Management Spectrum: The management spectrum describes the management/hierarchy of
people associated with a software project or how to make a software project successful. It
focuses on the four P‘s; People, Product, Process and Project.
The People
 The people factor is so important that the Software Engineering Institute has
developed a people management capability maturity model (PM-CMM), to
enhance the readiness of software organizations to undertake increasingly complex
applications by helping to attract, grow, motivate, deploy, and retain the talent
needed to improve their software development capability.
 The people management maturity model defines the following key practice
areas for software people: recruiting, selection, performance management,
training, compensation, career development, organization and work design, and
team/culture development. Organizations that achieve high levels of maturity in
the people management area have a higher likelihood of implementing
effective software engineering practices. The PM-CMM is a companion to the
software capability maturity model that guides organizations in the creation of a
mature software process.
 Following are the various categories of people associated with the project.
 The Stakeholders: - This include Senior managers, Project (technical) managers,
Practitioners, Customers, End user
 Team Leaders: - Leaders of various teams associated with the project
 The Software Team:- Entire software team
 Agile Teams: - Temporary teams associated with software
 Coordination and Communication Issues

The Product
 Before a project can be planned, product objectives and scope should be established,
alternative solutions should be considered and technical and management constraints
should be identified.
 Without this information, it is impossible to define reasonable estimates of the cost, an
effective assessment of risk, a realistic breakdown of project tasks, or a manageable
project schedule.
 Objectives identify the overall goals for the product without considering how these goals
will be achieved. Scope identifies the primary data, functions and behaviors that
characterize the product.
 Once the product objectives and scope are understood, alternative solutions are
considered. From the available various alternatives, managers and practitioners select a
"best" approach.

Mrs. M. P. Patil (DYP POLY, KOP) Page 1

 SEN-22413-Unit 4-Software Project Estimation

The Process
 A software process provides the framework from which a comprehensive plan for
software development can be established.
 A small number of frame-work activities are applicable to all software projects,
regardless of their size or complexity.
 A number of different tasks, milestones, work products and quality assurance points
enable the framework activities to be adapted to the characteristics of the software
project and the requirements of the project team.
Finally, umbrella activities such as software quality assurance, software configuration
management, and measurement overlay the process model.

The Project
 We conduct planned and controlled software projects for one primary reason it is the
only known way to manage complexity.
 A software project manager and the software engineers who build the product must avoid
asset of common warning signs, understand the critical success factors that lead to good
project management, and develop a common sense approach for planning, monitoring and
controlling the project.

OR
The management Spectrum: 4p’s
Effective software project management focuses on the four P‘s: people, product,
process, and project.
The People:
1. The ―people factor‖ is so important that the Software Engineering Institute has developed a
People Capability Maturity Model (People- CMM) to continually improve its ability to
attract, develop, motivate, organize, and retain the workforce needed to accomplish its
strategic business objectives.
2. The people capability maturity model defines the following key practice areas for
software people:
a. Staffing
b. communication and coordination
c. work environment
d. performance management
e. Training, compensation, competency analysis and development, career development,
workgroup development, team/culture development and others.
3. Organizations that achieve high levels of People-CMM maturity have higher likelihood of
implementing effective software project management practices.

The Product:
1. Before a project can be planned, product objectives and scope should be established,
alternative solutions should be considered and technical and management constraints
should be identified.
2. Without this information, it is impossible to define reasonable (and accurate) estimates of
the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a

Mrs. M. P. Patil (DYP POLY, KOP) Page 2

 SEN-22413-Unit 4-Software Project Estimation

manageable project schedule that provides a meaningful indication of progress.

3. Objectives identify the overall goals for the product (from the stakeholders‘ points of
view) without considering how these goals will be achieved.
4. Scope identifies the primary data, functions, and behaviors that characterize the
product
5. The alternatives enable managers and practitioners to select a ―best‖ approach, given the
constraints imposed by delivery deadlines, budgetary restrictions, personnel availability,
technical interfaces, and other factors.

The Process:
1. A software process provides the framework from which a comprehensive plan for
software development can be established.
2. A small number of framework activities are applicable to all software projects, regardless
of their size or complexity.
3. A number of different task sets—tasks, milestones, work products, and quality
assurance points enable the framework activities to be adapted to the characteristics of
the software project and the requirements of the project team.
4. Finally, umbrella activities—such as software quality assurance, software
configuration management, and measurement occur throughout the process.

The Project:
1. To manage complexity, we conduct planned and controlled software projects.
2. The success rate for present-day software projects may have improved but our project
failure rate remains much higher than it should be.
To avoid project failure, a software project manager and the software engineers who build the
product must avoid a set of common warning signs, understand the critical success factors that
lead to good project management, and develop a common-sense approach for planning,
monitoring, and controlling the project.

Q2: What are the metrics for size estimation types? Explain. OR Explain types of metrics used
for size estimation of the project with advantages &disadvantages
Ans: There are two types of the metrics used for size estimation of the project:-
 LOC based size estimation
 Function Point based size estimation
LOC based size estimation:
LOC is the simplest among all metrics available to estimate project size. This metric is very
popular because it is the simplest to use.
Using this metric, the project size is estimated by counting the number of source instructions in
the developed program. i. e. LOC consists of declarations, actual code including logic &
computations. Obviously, while counting the number of source instructions, lines used for
commenting the code and the header lines and blank lines should be ignored.
This is because blank lines are included in the code to improve readability of code & comments
are included to help in code understanding as well as maintenance. Actually blank lines &
comments do not contribute to any kind of functionality & it may be misused by developers to
give false notion about productivity.

Mrs. M. P. Patil (DYP POLY, KOP) Page 3

 SEN-22413-Unit 4-Software Project Estimation

Determining the LOC count at the end of a project is a very simple job. However, accurate
estimation of the LOC count at the beginning of the project is very difficult.
In order to estimate the LOC count at the beginning of a project, project managers usually divide
the problem into modules and each module into sub-modules and so on, until the sizes of the
different leaf-level modules can be approximately predicted.
To be able to do this, past experience in developing similar products is helpful. By using the
estimation of the lowest level modules, project managers arrive at the total size estimation.
Advantage of LOC:
 It is very easy to count & calculate from the developed code.
Disadvantage of LOC:
 It is Language & technology dependent
 Constitute (representation) an LOC varies from organization to organization

Function Point based size estimation:

The conceptual idea behind the function point metric is that the size of a software product is
directly dependent on the number of different Functions or features it supports. A software
product supporting many features would certainly be of larger size than a product with less
number of features. Each function when invoked reads some input data and transforms it to the
corresponding output data. For example, the issue book feature of a Library Automation
Software takes the name of the book as input and displays its location and the number of copies
available. Thus, a computation of the number of input and the output data values to a system
gives some indication of the number of functions supported by the system. Albrecht postulated
that in addition to the number of basic functions that software performs, the size is also
dependent on the number of files and the number of interfaces.
Function points are derived using an empirical relationship based on countable (direct) measures
of software‘s information domain and qualitative assessments of software complexity.
Information domain values are defined in the following manner:
Number of external inputs (EIs): Each external input originates from a user or is transmitted
from another application and provides distinct application-oriented data or control information.
Inputs are often used to update internal logical files (ILFs). Inputs should be distinguished from
inquiries, which are counted separately.
Number of external outputs (EOs): Each external output is derived data within the application
that provides information to the user. In this context external output refers to reports, screens,
error messages, etc. Individual data items within a report are not counted separately.
Number of external inquiries (EQs): An external inquiry is defined as an online input that
results in the generation of some immediate software response in the form of an online output
(often retrieved from an ILF).
Number of internal logical files (ILFs): Each internal logical file is a logical grouping of data
that resides within the application‘s boundary and is maintained via external inputs.
Number of external interface files (EIFs): Each external interface file is a logical grouping of
data that resides external to the application but provides information that may be of use to the
application.
Once these data have been collected, the table 1 is completed and a complexity value is
associated with each count. Organizations that use function point methods develop criteria for
determining whether a particular entry is simple, average, or complex. Nonetheless, the

Mrs. M. P. Patil (DYP POLY, KOP) Page 4

 SEN-22413-Unit 4-Software Project Estimation

determination of complexity is somewhat subjective. To compute function points (FP), the

following relationship is used:
FP =count total * [0.65+ (0.01*(∑Fi)] ……..( Equation 1)
where count total is the sum of all FP entries obtained from Table 1.

Table 1: Computing function points

The Fi (i=1 to 14) are Value Adjustment Factors (VAF) or Unadjusted Function Points (UFP)
based on responses to the following questions:
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required to transfer information to or from the
application?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to be built over multiple screens or
operations?
8. Are the ILFs updated online?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Each of these questions is answered using a scale that ranges from 0 (not important or
applicable) to 5 (absolutely essential). The constant values in Equation 1 and the weighting
factors that are applied to information domain counts are determined empirically.

Advantages of FP:
 Size of software delivered is measured independent of language or technology & tools.
 FP‘s are directly estimated from requirement before design & coding.
 Any change in requirements can be easily reflected in FP count.
 Useful even for those users without technical expertise because FP is based on external
structure of the software to developed

Mrs. M. P. Patil (DYP POLY, KOP) Page 5

 SEN-22413-Unit 4-Software Project Estimation

Disadvantages of FP:
 It is not good for real time systems and embedded systems.
 Many cost estimation models like COCOMO uses LOC and hence FP must be converted
to LOC.

Q3: State importance of ―Function point ―and ―lines of code‖ in concerned with project
estimation.
Ans: Currently two metrics are popularly being used widely to estimate size: lines of code
(LOC) and function point (FP).
Lines of Code (LOC)
LOC is the simplest among all metrics available to estimate project size. This metric is very
popular because it is the simplest to use.
Using this metric, the project size is estimated by counting the number of source instructions in
the developed program. Obviously, while counting the number of source instructions, lines
used for commenting the code and the header lines should be ignored.

Function Point (FP):

The conceptual idea behind the function point metric is that the size of a software product is
directly dependent on the number of different Functions or features it supports. A software
product supporting many features would certainly be of larger size than a product with less
number of features. Each function when invoked reads some input data and transforms it to the
corresponding output data. For example, the issue book feature (as shown in figure) of a Library
Automation Software takes the name of the book as input and displays its location and the
number of copies available. Thus, a computation of the number of input and the output data
values to a system gives some indication of the number of functions supported by the system.
Albrecht postulated that in addition to the number of basic functions that software performs,
the size is also dependent on the number of files and the number of interfaces.

Q4. With an example, explain Line of Code (LOC) based estimation.

Ans: LOC-Based Estimation: As an example of LOC and FP problem-based estimation
techniques, let us consider a software package to be developed for a computer-aided design
application for mechanical components.
A review of the System Specification indicates that the software is to execute on an
engineering workstation and must interface with various computer graphics peripherals
including a mouse, digitizer, high resolution color display and laser printer.
Using the System Specification as a guide, a preliminary statement of software scope can be
developed:
Example:
Function Estimated LOC
User interface and control facilities (UICF) 2,300
Two-dimensional geometric analysis (2DGA) 5,300
Three-dimensional geometric analysis (3DGA) 6,800
Database management (DBM) 3,350

Mrs. M. P. Patil (DYP POLY, KOP) Page 6

 SEN-22413-Unit 4-Software Project Estimation

Computer graphics display facilities (CGDF) 4,950

Peripheral control function (PCF) 2,100
Design analysis modules (DAM) 8,400
Estimated lines of code 33,200

Q5: How to calculate the function point?

Ans: In this method, the number and type of functions supported by the software are utilized to
find FPC(function point count). The steps in function point analysis are:
 Count the number of functions of each proposed type.
 Compute the Unadjusted Function Points(UFP).
 Find Total Degree of Influence (TDI).
 Compute Adjustment Factor(VAF).
 Find the Function Point Count(FP).
The explanation of above points given below:
 Count the number of functions of each proposed type: Find the number of functions
belonging to the following types:
o External Inputs: Functions related to data entering the system.
o External Outputs: Functions related to data exiting the system.
o External Inquiries: They lead to data retrieval from system but don‘t change the
system.
o Internal Logical Files: Logical files maintained within the system. Log files are
not included here.
o External interface Files: These are logical files for other applications which are
used by our system.
 Compute the Unadjusted Function Points(UFP):Categorize each of the five function
types as low/simple, average or high/complex based on their complexity. Multiply count
of each function type with its weighting factor and find the weighted sum.

Where Zij=count of the number of functional units of category I classified as complexity j

Wij=weight from given table
 The weighting factors for each type based on their complexity are as follows:
Function type Low/Simple Average High/Complex
External Inputs 3 4 6
External Output 4 5 7
External Inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10

Mrs. M. P. Patil (DYP POLY, KOP) Page 7

 SEN-22413-Unit 4-Software Project Estimation

Find Total Degree of Influence (∑Fi): Use the ‘14 general characteristics‘ of a system to find
the degree of influence of each of them. The sum of all 14 degrees of influences will give the
TDI(∑Fi). The range of TDI is 0 to 70. The 14 general aspects or characteristics are:
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required to transfer information to or from the
application?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to be built over multiple screens or
operations?
8. Are the ILFs updated online?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Each of above aspects or characteristics is evaluated on a scale of 0-5.
0-No influences
1-Incidental
2-Moderate
3-Avarage
4-Significant
5-Essential
Compute Complexity Adjustment Factor (CAF): Use the following formula to calculate CAF

CAF = [0.65+ (0.01*(∑Fi)] -------eq(1)

Find the Function Point Count: Use the following formula to calculate FP

FP = UFP * CAF -------- eq(2)

Example:
Given the following values, compute function point when all complexity adjustment factor
(CAF) and weighting factors are average.
User Input = 50
User Output = 40
User Inquiries = 35
Internal Logical Files= 6
External Interface Files= 4

Solution:
 Step-1: As complexity adjustment factor is average (given in question),
hence, scale = 3.
Fi = 14 * 3 = 42

Mrs. M. P. Patil (DYP POLY, KOP) Page 8

 SEN-22413-Unit 4-Software Project Estimation

 Step-2:
CAF = [ 0.65 + (0.01*( ∑Fi ) )
CAF = 0.65 + ( 0.01 * 42 ) = 1.07

 Step-3: As weighting factors are also average (given in question)

hence we will multiply each individual function point to corresponding values in
TABLE.

UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7)

=200+200+140+60+28= 628

 Step-4:
Function Point (FP) = UFP * CAF
Function Point (FP) = 628 * 1.07 = 671.96
This is the required answer.

Q6. Explain any one project cost estimation approach. OR What are 3 commonly used cost
estimation approaches used in software project. Explain in details. OR Describe Heuristic
technique, Empirical technique & Analytical technique of cost estimation of the project.

Ans: Estimation of several project parameters is considered as initial project planning activity.
The significant project parameters which are mostly estimated include: size of the project, effort
necessary to build the software, project duration and costing. These estimates help to quote the
project cost to the customer and also beneficial in resource planning as well as scheduling.
Three broad categories are generally used in cost estimation techniques are:
 Heuristic estimation technique
 Analytical estimation technique
 Empirical estimation technique

Heuristic estimation technique

Heuristic techniques assume that the relationships among the different project parameters can
be modeled using suitable mathematical expressions. Once the basic (independent) parameters
are known, the other (dependent) parameters can be easily determined by substituting the value
of the basic parameters in the mathematical expression.
Different heuristic estimation models can be divided into the following two classes:
single variable model and the multivariable model.
Single variable estimation models provide a means to estimate the desired characteristics of
a problem, using some previously estimated basic (independent) characteristic of the software
product such as its size. A single variable estimation model takes the following form:
Estimated Parameter = c1 * e1d1

Mrs. M. P. Patil (DYP POLY, KOP) Page 9

 SEN-22413-Unit 4-Software Project Estimation

In the above expression, e is the characteristic of the software which has already been estimated
(independent variable).
Estimated Parameter is the dependent parameter to be estimated. The dependent parameter to
be estimated could be effort, project duration, staff size, etc. c1 and d1 are constants. The
values of the constants c1 and d1 are usually determined using data collected from past
projects (historical data). The basic COCOMO model is an example of single variable cost
estimation model.
A multivariable cost estimation model takes the following form:
Estimated Resource = c1 * e1d1+ c 2 * e2 d2+ ...
Where e1, e2, … are the basic (independent) characteristics of the software already estimated,
and c1, c2, d1, d2, … are constants.

Analytical estimation technique:

Analytical estimation techniques determine the necessary results beginning from basic
assumptions related to the project. In this way, unlike to remaining empirical & heuristic
techniques, there is scientific basis in analytical techniques. In analytical technique, Halstead‘s
software science is a prominent example.

Halstead’s Software Science – An Analytical Technique Halstead‘s software science is an

analytical technique to measure size, development effort, and development cost of software
products. Halstead used a few primitive program parameters to develop the expressions for
overall program length, potential minimum value, actual volume, effort, and development time.
Example:
Let us consider the following C program:
main( )
{
int a, b, c, avg;
scanf(―%d %d %d‖, &a, &b, &c);
avg = (a+b+c)/3;
printf(―avg = %d‖, avg);
}
The unique operators are:
main,(),{},int,scanf,&,―,‖,―;‖,=,+,/, printf
The unique operands are:
a, b, c, &a, &b, &c, a+b+c, avg, 3, ―%d %d %d‖, ―avg = %d‖
Therefore,
n1 = 12, n2 = 11
Estimated Length= (12*log12 +11*log11)
= (12*3.58 + 11*3.45)
= (43+38) = 81
Volume= Length*log(23)
= 81*4.52
= 366

Mrs. M. P. Patil (DYP POLY, KOP) Page 10

 SEN-22413-Unit 4-Software Project Estimation

Empirical estimation technique:

The empirical estimation techniques are usually founded on making an educated guess regarding
the project parameters. If similar products are developed previously, then that experience is
always helpful. Even though the base of empirical estimation techniques is common sense,
several activities involved in estimation have been formalized over the years.

There are two frequently used empirical estimation techniques namely: Expert judgment
technique & Delphi cost estimation technique.

Expert Judgment Technique:

 In expert judgment technique, an expert analyses the problem in detail and makes an
educated guess regarding the problem size.
 Usually, the expert makes an estimation of the cost regarding the different components
(such as modules or subsystems) of the respective system and then integrates them to find
the overall estimate.
 Yet, this technique is exposed to human errors. Additionally, it is likely that the expert
may miss few factors accidentally.
 Supplementary, an expert who is making the estimate may lack of experience as well as
knowledge of all aspects of a project.
 For example, he or she may be familiar with the database and user interface components
but may not be aware regarding the computer communication part.
 Estimation made by group of experts can be considered as a more refined form of expert
judgment.
 It minimizes factors like individual oversight, lack of familiarity with a specific aspect
regarding the project, etc.

Delphi Cost Estimation Technique:

 In this approach some of the shortcomings of the expert judgment approach are tried to
resolve.
 In this approach a team which involves a group of experts and a coordinator takes part.
 The coordinator gives a copy of the Software Requirements Specification (SRS)
document to all of the estimators and a particular form for the purpose of recording their
cost estimates.
 Individual estimates are completed by all of the estimators and submitted to the
coordinator.
 In individual estimates, the estimators point out any unusual characteristic regarding the
product which has great impact on the estimation.

Mrs. M. P. Patil (DYP POLY, KOP) Page 11

 SEN-22413-Unit 4-Software Project Estimation

 The coordinator then makes and handouts the summary of the responses by considering
all the estimators and incorporates any unusual justification that may be noted by any of
the estimators.
 By considering this summery, all of the estimators re-estimate. This method is repeated
for several rounds.
 However, estimators cannot communicate with each other regarding the estimates. The
reason is that the estimate of more experienced or senior estimator may influence other
estimators.
 After several iterations of estimations are done, the coordinator compiles the results and
prepares the final estimate.

Q7: Describe the Analytical method of project cost estimation with example. OR Write a short
note on Halstead‘s software science.
Ans:
Analytical estimation techniques derive the required results starting with basic assumptions
regarding the project. Thus, unlike empirical and heuristic techniques, analytical techniques do
have scientific basis.
Halstead’s software science is an example of an analytical technique. Halstead‘s software
science can be used to derive some interesting results starting with a few simple assumptions.
Halstead‘s software science is especially useful for estimating software maintenance efforts. In
fact, it outperforms both empirical and heuristic techniques when used for predicting software
maintenance efforts.
Halstead‘s Software Science – An Analytical Technique Halstead‘s software science is an
analytical technique to measure size, development effort, and development cost of software
products. Halstead used a few primitive program parameters to develop the expressions for
overall program length, potential minimum value, actual volume, effort, and development time.
For a given program, let:
 η1 be the number of unique operators used in the program,
 η2 be the number of unique operands used in the program,
 N1 be the total number of operators used in the program,
 N2 be the total number of operands used in the program. Example: Let us
consider the following C program:
main( )
{ int a, b, c, avg;
scanf(―%d %d %d‖, &a, &b, &c); avg = (a+b+c)/3;
printf(―avg = %d‖, avg);
} The unique operators are: main, (), {}, int, scanf, &, ―, ‖, =, +, /, printf
The unique operands are: a, b, c, &a, &b, &c, a+b+c, avg, 3, ―%d %d
%d‖, ―avg = %d‖ Therefore, η1 = 12, η2 = 11
Estimated Length = (12*log12 + 11*log11)
= (12*3.58 + 11*3.45)
= (43+38) = 81
Volume = Length*log(23)
= 81*4.52
= 366
Mrs. M. P. Patil (DYP POLY, KOP) Page 12
 SEN-22413-Unit 4-Software Project Estimation

Q8: Specify following cost directives of cocomo:

 Product attributes (any two)
 Hardware attributes (any two).
Ans: Product attributes –
 Required software reliability extent
 Size of the application database
 The complexity of the product

Hardware attributes –
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turn about time

Q9: Describe COCOMO model in detail. OR What are the different models of COCOMO
model? Explain. OR Describe basic model, intermediate model & detailed model of COCOMO
model.

Ans: Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is

one of the most generally used software estimation models in the world. COCOMO predicts the
efforts and schedule of a software product based on the size of the software.

The necessary steps in this model are:

1. Get an initial estimate of the development effort from evaluation of thousands of

delivered lines of source code (KLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying
factors i.e., multiply the values in step1 and step2.

The initial estimate (also called nominal estimate) is determined by an equation of the form used
in the static single variable models, using KLOC as the measure of the size. To determine the
initial effort Ei in person-months the equation used is of the type is shown below

Ei=a*(KLOC)b

The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

Mrs. M. P. Patil (DYP POLY, KOP) Page 13

 SEN-22413-Unit 4-Software Project Estimation

1. Organic: 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.

2. Semidetached: 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.

3. Embedded: 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.

For three product categories, Boehm provides a different set of expression to predict effort (in a
unit of person month)and development time from the size of estimation in KLOC(Kilo Line of
code) efforts estimation takes into account the productivity loss due to holidays, weekly off,
coffee breaks, etc.
According to Boehm, software cost estimation should be done through three stages:
1. Basic Model
2. Intermediate Model
3. Detailed Model
1. Basic COCOMO Model: The basic COCOMO model provides an accurate size of the
project parameters. The following expressions give the basic COCOMO estimation
model:
E = ab*(KLOC)bb PM
D = cb *(E)db Months
P = E/D
Where
E is the total effort required to develop the software product, expressed in person months
(PMs)
D is the estimated time to develop the software, expressed in months,
KLOC is the estimated size of the software product indicated in Kilo Lines of Code,
P is total number of persons required to accomplish the project
ab, bb, cb, db are coefficients for three modes/types are given below:,

Software Projects ab bb cb db
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

Mrs. M. P. Patil (DYP POLY, KOP) Page 14

 SEN-22413-Unit 4-Software Project Estimation

Merits of basic COCOMO model:

 Basic COCOMO model is good for quick, early, rough order of magnitude estimates of
software project.

Limitations of basic model

 The accuracy of this model is limited because it does not consider certain factors for cost
estimation of software. These factors are hardware constraints, personal quality,
experience and modern techniques and tools.
 The estimates of COCOMO model are within a factor of 1.3 only 29% of the time and
within factor of 2 only 60% of time.
2. 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 system. 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, etc are considered.
These factors are known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for
cost estimation.
Now these 15 attributes get a 6-point scale ranging from very low to extra high. These ratings
can be viewed as below:
Very Very Extra
Cost Drivers Low Nominal High
Low High High
Product Attributes
Required Software Reliability 0.75 0.88 1.00 1.15 1.40
Size of Application Database 0.94 1.00 1.08 1.16
Complexity of The Product 0.70 0.85 1.00 1.15 1.30 1.65
Hardware Attributes

Runtime Performance Constraints 1.00 1.11 1.30

1.66
Memory Constraints 1.00 1.06 1.21 1.56
Volatility of the virtual machine
0.87 1.00 1.15 1.30
environment
Computer turnabout time 0.94 1.00 1.07 1.15
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Software engineer capability 1.42 1.17 1.00 0.86 0.70
Applications experience 1.29 1.13 1.00 0.91 0.82
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language
1.14 1.07 1.00 0.95
experience

Mrs. M. P. Patil (DYP POLY, KOP) Page 15

 SEN-22413-Unit 4-Software Project Estimation

Very Very Extra

Cost Drivers Low Nominal High
Low High High
Project Attributes
Use of software tools 1.24 1.10 1.00 0.91 0.83
Application of software
1.24 1.10 1.00 0.91 0.82
engineering methods
Required development schedule 1.23 1.08 1.00 1.04 1.10

The effort multiplier for each cost driver attribute is as given in the above table. The products of
effort multipliers result in ―Effort Adjustment Factor (EAF).

The Intermediate COCOMO formula now takes the form:

E = ai * (KLOC)bi * EAF
The values of ai and bi in case of the intermediate model are as follows:

Software Projects ai bi

Organic 3.2 1.05

Semi Detached 3.0 1.12
Embedded 2.8 1.20

D = cb *(E)db Months
P = E/D
Where the duration (D) and person (P) estimate is same as in basic COCOMO model. Use
values of cb and db coefficients from basic COCOMO model.

Merits Intermediate COCOMO Model:

 This model can be applied to almost entire software product for easy and rough cost
estimation during early stage.
 It can also be applied at the software product component level for obtaining more
accurate cost estimation.
Limitations of Intermediate COCOMO Model:

 The estimation is within 20% of actual 68% of the time.

 The effort multipliers are not dependent on phases.
 A product with many components is difficult to estimate.

Mrs. M. P. Patil (DYP POLY, KOP) Page 16

 SEN-22413-Unit 4-Software Project Estimation

3. Detailed COCOMO Model

Detailed COCOMO includes 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 four phases of detailed COCOMO are:

1. Requirements Planning and Product Design(RPD)

2. Detailed design (DD)
3. Code and Unit Test (CUT)
4. Integration and Test (IT)

The effort is calculated as a function of program size and a set of cost drivers are given according
to each phase of the software lifecycle.

Very Very
Phases Low Nominal High
Low High
Requirements Planning and
1.80 0.85 1.00 0.75 0.55
Product Design(RPD)
Detailed design (DD) 1.35 0.85 1.00 0.90 0.75
1.00
Code and Unit Test (CUT) 1.35 0.85 0.90 0.75
1.00
Integration and Test (IT) 1.50 1.20 0.85 0.70

Q10: Describe COCOMO II model for evaluating size of software project with any three
parameters in detail OR Describe COCOMO-II model in detail.
Ans: COCOMO-II is the revised version of the original 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. COCOMO II
provides the following three-stage series of models for estimation of Application Generator,
System Integration, and Infrastructure software projects:

Mrs. M. P. Patil (DYP POLY, KOP) Page 17

 SEN-22413-Unit 4-Software Project Estimation

 The Application Composition Model

This model involves prototyping efforts to resolve potential high- risk issues such as
user interfaces, software/system interaction, performance, or technology maturity. The
costs of this type of effort are best estimated by the Applications Composition model. It
is suitable for projects built with modern GUI-builder tools. It is based on new Object
Points.

 The Early Design Model

The Early Design model involves exploration of alternative software/system
architectures and concepts of operation. It uses a small set of new Cost Drivers, and
new estimating equations. Based on Unadjusted Function Points or KLOC.

 The Post-Architecture Model

The Post-Architecture model involves the actual development and maintenance of a
software product.

 The Reuse Model

Reuse model used to calculate the efforts needed to integrate reusable software or
program code that are automatically created by design or program translation tools.

Q11: What is software risk? Explain types of software risks.

Ans: Software Risk: - A software risk is anything which can cause a delay in software or
stops the progress of a system or even terminates the software project.

There are two basic types of risks:

(a) Generic Risk Generic Risk is the general purpose possible threat to every software
product.
(b) Product Specific Risk Product Specific risk can be find out only by those with a clear
understanding of the technology going to be used for that project, the people and the
environment that is particular to the software that is to be built.
Different Categories of Risks: -
(a) Project Risk: - Threaten the project plan. That is if project risk become real it is likely
that project schedule will slip and that costs will increase. Project risks identity potential
budgetary, schedule, personnel, resource, customer and requirement problem.
(b) Technical Risk: - Threaten the quality and timeliness of the software to be produced. If
technical risk becomes real, implementation may become difficult or impossible.
(c) Business Risk: - Threaten the viability of the software to be built. Business risk often
jeopardizes the product or the project.
i. Market Risk:- Building product that no one wants
ii. Strategic Risk: - Building a product that no longer fits into the business strategy
iii. Management Risk: - Building a product that the sale force doesn‗t understand.
iv. Budget Risk: - Losing budgetary or personnel commitment

Mrs. M. P. Patil (DYP POLY, KOP) Page 18

 SEN-22413-Unit 4-Software Project Estimation

OR
a) Performance risk - the degree of uncertainty that the product will meet its
requirements and be fit for its intended use.
b) Cost risk - the degree of uncertainty that the project budget will be maintained.
c) Support risk - the degree of uncertainty that the resultant software will be easy to
correct, adapt, and enhance.
d) Schedule risk - the degree of uncertainty that the project schedule will be maintained
and that the product will be delivered on time.
OR
1. Generic risks are a potential threat to every software project.
2. Product-specific risks can be identified only by those with a clear understanding of the
technology, the people, and the environment.
3. Product size—risks associated with the overall size of the software to be built or modified
that is specific to the software that is to be built.
4. Business impact—risks associated with constraints imposed by management or the
marketplace.
5. Project risks threaten the project plan. That is, if project risks become real, it is likely that
the project schedule will slip and that costs will increase.
6. Technical risks threaten the quality and timeliness of the software to be produced.
7. Business risks threaten the viability of the software to be built and often jeopardize the
project or the product.
8. Known risks are those that can be uncovered after careful evaluation of the project plan,
the business and technical environment in which the project is being developed, and other
reliable information sources.
9. Predictable risks are extrapolated from past project experience of user.
10. Unpredictable risks are one that they can and do occur, but they are extremely difficult to
identify in advance.

Q12: What are the characteristics involved in software risk?

Ans: Software risk always involves two characteristics:
1. Uncertainty—the risk may or may not happen; that is, there are no 100 percent probable
risks.
2. Loss—if the risk becomes a reality, unwanted consequences or losses will occur.
When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss
associated with each risk.

Q13: Define proactive and reactive risk strategy.

Ans: Reactive risk strategies
• Reactive risk strategy follows that the risks have to be tackled at the time of their
occurrence.
• No precautions are to be taken as per this strategy.
• They are meant for risks with relatively smaller impact.
• More commonly, the software team does nothing about risks until something goes
wrong.
• Then, the team flies into action in an attempt to correct the problem rapidly. This is

Mrs. M. P. Patil (DYP POLY, KOP) Page 19

 SEN-22413-Unit 4-Software Project Estimation

often called a fire-fighting mode.

Proactive risk strategies
• It follows that the risks have to be identified before start of the project.
• They have to be analysed by assessing their probability of occurrence, their impact after
occurrence, and steps to be followed for its precaution.

Q14: Define Reactive Risk strategies.

Ans: A reactive risk strategy monitors the project for likely risks. Resources are set aside to
deal with them, should they become actual problems. More commonly, the software team does
nothing about risks until something goes wrong. Then, the team flies into action in an attempt to
correct the problem rapidly. This is often called a fire-fighting mode. When this fails, ―crisis
management‖ takes over and the project is in real jeopardy.

Q15: Explain in detail RMMM strategy OR Describe RMMM strategy in detail OR Explain
RMMM plan with example.
Ans: Risk mitigation, monitoring, and management (RMMM) plan. A risk management
strategy can be included in the software project plan or the risk management steps can be
organized into a separate Risk Mitigation, Monitoring and Management Plan. The RMMM
plan documents all work performed as part of risk analysis and is used by the project
manager as part of the overall project plan. Once RMMM has been documented and the
project has begun, risk mitigation and monitoring steps commence. Risk mitigation is a
problem avoidance activity.
Risk monitoring is a project tracking activity with three primary objectives:
1) To assess whether predicted risks do, in fact, occur;
2) To ensure that risk aversion steps defined for the risk are being properly applied; and
3) To collect information that can be used for future risk analysis.
In many cases, the problems that occur during a project can be traced to more than one risk.
Another job of risk monitoring is to attempt to allocate origin (what risk(s) caused
which problems throughout the project).
An effective strategy must consider three issues:
• Risk avoidance
• Risk monitoring
• Risk management and contingency planning
If a software team adopts a proactive approach to risk, avoidance is always the best
strategy. This is achieved by developing a plan for risk mitigation. To mitigate this risk,
project management must develop a strategy for reducing turnover.
Among the possible steps to be taken are
 Meet with current staff to determine causes for turnover (e.g., poor working
conditions, low pay, and competitive job market).
 Mitigate those causes that are under our control before the project starts.
 Once the project commences, assume turnover will occur and develop techniques to
ensure continuity when people leave.
 Organize project teams so that information about each development activity is widely
dispersed.

Mrs. M. P. Patil (DYP POLY, KOP) Page 20

 SEN-22413-Unit 4-Software Project Estimation

 Define documentation standards and establish mechanisms to be sure that documents

are developed in a timely manner.
 Conduct peer reviews of all work (so that more than one person is "up to speed).
 Assign a backup staff member for every critical technologist. As the project
proceeds, risk monitoring activities commence. The project manager monitors factors
that may provide an indication of whether the risk is becoming more or less likely. In
the case of high staff turnover, the following factors can be monitored:
 General attitude of team members based on project pressures.
 The degree to which the team has jelled.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.
In addition to monitoring these factors, the project manager should monitor the
effectiveness of risk mitigation steps. RMMM steps incur additional project cost. Part of
risk management, therefore, is to evaluate when the benefits accrued by the RMMM
steps are outweighed by the costs associated with implementing them. In essence, the
project planner performs a classic cost/benefit analysis.

OR
To assist the project team in developing a strategy for dealing with risk. An effective strategy
must consider three issues: risk avoidance, risk monitoring, and risk management and
contingency planning. If a software team adopts a proactive approach to risk, avoidance is always
the best strategy. This is achieved by developing a plan for risk mitigation.
Risk Mitigation: -
To mitigate this risk, you would develop a strategy for reducing turnover. Among the possible
steps to be taken are:
 Meet with current staff to determine causes for turnover (e.g., poor working conditions,
low pay, and competitive job market).
 Mitigate those causes that are under your control before the project starts.
 Once the project commences, assume turnover will occur and develop techniques to
ensure continuity when people leave.
 Organize project teams so that information about each development activity is widely
dispersed.
 Define work product standards and establish mechanisms to be sure that all models and
documents are developed in a timely manner.
 Conduct peer reviews of all work (so that more than one person is―up to speed‖).
 Assign a backup staff member for every critical technologist.

Mrs. M. P. Patil (DYP POLY, KOP) Page 21

 SEN-22413-Unit 4-Software Project Estimation

Risk Monitoring: -
As the project proceeds, risk-monitoring activities commence. The project manager monitors
factors that may provide an indication of whether the risk is becoming more or less likely. In
the case of high staff turnover, the general attitude of team members based on project
pressures, the degree to which the team has jelled, interpersonal relationships among team
members, potential problems with compensation and benefits, and the availability of jobs
within the company and outside it are all monitored.
Risk Management: -
In addition to monitoring these factors, a project manager should monitor the effectiveness of
risk mitigation steps. Risk management and contingency planning assumes that mitigation
efforts have failed and that the risk has become a reality.
Risk management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality.
It is important to note that risk mitigation, monitoring, and management (RMMM) steps incur
additional project cost. For example, spending the time to back-up every critical technologist
costs money. Part of risk management, therefore, is to evaluate when the benefits accrued by
the RMMM steps are outweighed by the costs associated with implementing them.

OR
A risk management plan or plan risk management is a document that a prepares to foresee
risks, estimate impacts, and define responses to risks. It also contains a risk matrix.
A risk is "an uncertain event or condition that, if it occurs, has a positive or negative effect on a
project's objectives." Risk is inherent with any and project manager should assess risks
continually and develop plans to address them. The risk management plan contains an analysis
of likely risks with both high and low impact, as well as mitigation strategies to help the project
avoid being derailed should common problems arise. Risk management plans should be
periodically reviewed by the project team to avoid having the analysis become stale and not
reflective of actual potential project risks. Most critically, risk management plans include a risk
strategy. There are two characteristics of risk i.e. uncertainty and loss.
Risk Mitigation, Monitoring and Management (RMMM)
Risk analysis support the project team in constructing a strategy to deal with risks.
There are three important issues considered in developing an effective strategy:
Risk avoidance or mitigation - It is the primary strategy which is fulfilled through a plan.
Risk monitoring - The project manager monitors the factors and gives an indication whether
the risk is becoming more or less.
Risk management and planning - It assumes that the mitigation effort failed and the risk is a
reality.
RMMM Plan- It is a part of the software development plan or a separate document.
The RMMM plan documents all work executed as a part of risk analysis and used by the
project manager as a part of the overall project plan.
The risk mitigation and monitoring starts after the project is started and the documentation of
RMMM is completed.
Risk: Computer Crash Mitigation :
The cost associated with a computer crash resulting in a loss of data is crucial. A computer
crash itself is not crucial, but rather the loss of data. A loss of data will result in not being able
to deliver the product to the customer. This will result in a not receiving a letter of acceptance

Mrs. M. P. Patil (DYP POLY, KOP) Page 22

 SEN-22413-Unit 4-Software Project Estimation

from the customer. Without the letter of acceptance, the group will receive a failing grade for
the course. As a result the organization is taking steps to make multiple backup copies of the
software in development and all documentation associated with it, in multiple locations. ·
Monitoring :
When working on the product or documentation, the staff member should always be aware
of the stability of the computing environment they‘re working in. Any changes in the
stability of the environment should be recognized and taken seriously. ·
Management :
The lack of a stable-computing environment is extremely hazardous to a software development
team. In the event that the computing environment is found unstable, the development team
should cease work on that system until the environment is made stable again, or should move
to a system that is stable and continue working there.

Q16: Explain following terms w.r.t. risk management:

(i) Risk identification
(ii) Risk analysis
Ans:
(i) Risk identification:
During the first step in the software risk management process, risks are identified and added to
the list of known risks. The output of this step is a list of project-specific risks that have the
potential of compromising the project's success. There are many techniques for identifying
risks, including interviewing, reporting, decomposition, assumption analysis, critical path
analysis, and utilization of risk taxonomies. Interviewing/Brainstorming:
One technique for identifying risks is interviewing or brainstorming with project personnel,
customers, and vendors.
Open-ended questions such as the following can help identify potential areas of risk.
What new or improved technologies does this project implement? What interfaces issues
still need to be defined?
What requirements exist that we aren‘t sure how to implement?
What concerns do we have about our ability to meet the required quality and performance
levels?

Mrs. M. P. Patil (DYP POLY, KOP) Page 23

 SEN-22413-Unit 4-Software Project Estimation

Voluntary Reporting:
Decomposition: As the product is being decomposed during the requirements and design
phases, another opportunity exists for risk identifications. Every TBD ("To Be
Done/Determined") is a potential risk. ―The most important thing about planning is writing
down what you don‘t know, because what you don‘t know is what you must find out.
Decomposition in the form of work breakdown structures during project planning can also
help identify areas of uncertainty that may need to be recorded as risks. Assumption Analysis:
Process and product assumptions must be analyzed. Risk Taxonomies: Risk taxonomies are
lists of problems that have occurred on other projects and can be used as checklists to help
ensure all potential risks have been considered.

(ii) Risk analysis

During the risk analysis step, each risk is assessed to determine: Likelihood: the probability that
the risk will result in a loss
Impact: the size or cost of that loss if the risk turns into a problem
Timeframe: when the risk needs to be addressed (i.e., risk associated with activities in the near
future would have a higher priority similar risks in later activities), the interrelationships
between risks are assessed to determine if compounding risk conditions magnify losses.
Comparing the Risk Exposure measurement for various risks can help identify those risks with
the greatest probable negative impact to the project or product and thus help establish which
risks are candidates for further action. The list of risks is then prioritized based on the results
of our risk analysis. Since resource limitations rarely allow the consideration of all risks, the
prioritized list of risks is used to identify risks requiring additional planning and action. Other
risks are documented and tracked for possible future consideration. Risk analysis is based on
changing conditions, additional information, the identification of new risks, or the closure of
existing risks, the list of risks requiring additional overheads.

Q17: Describe the following with respect to Risk assessment:

(i) Risk identification
(ii) Risk analysis
(iii) Risk prioritization
Ans:
Risk identification: Is the first step in risk assessment, which identifies all the different risks for
a particular project. These risks are project-dependent and identifying them is an exercise in
envisioning what can go wrong. Methods that can aid risk identification include checklists of
possible risks, surveys, meetings and brainstorming, and reviews of plans, processes, and work
products. Checklists of frequently occurring risks are probably the most common tool for risk
identification—most organizations prepare a list of commonly occurring risks for projects,
prepared from a survey of previous projects. Such a list can form the starting point for
identifying risks for the current project. Risk identification merely identifies the undesirable
events that might take place during the project, i.e., enumerates the ―unforeseen‖ events
that might occur. It does not specify the probabilities of these risks materializing nor the
impact on the project if the risks indeed materialize. Hence, the next tasks are risk analysis and
prioritization.

Mrs. M. P. Patil (DYP POLY, KOP) Page 24

 SEN-22413-Unit 4-Software Project Estimation

Risk analysis: In risk analysis, the probability of occurrence of a risk has to be estimated, along
with the loss that will occur if the risk does materialize. This is often done through discussion,
using experience and understanding of the situation, though structured approaches also exist.
Once the probabilities of risks materializing and losses due to materialization of different risks
have been analyzed, they can be prioritized.
Risk prioritization: One approach for prioritization is through the concept of risk exposure,
which is sometimes called risk impact. RE is defined by the relationship
RE = Prob(UO) * Loss(UO),
Where Prob(UO) is the probability of the risk materializing (i.e., undesirable outcome) and
Loss(UO) is the total loss incurred due to the unsatisfactory outcome. The loss is not only the
direct financial loss that might be incurred but also any loss in terms of credibility, future
business, and loss of property or life. The RE is the expected value of the loss due to a particular
risk. For risk prioritization using RE is, the higher the RE, the higher the priority of the risk item.

Q18. Explain risk refinement.

Ans: During early stages of project planning, a risk may be stated quite generally. As time
passes and more is learned about the project and the risk, it may be possible to refine
the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor,
and manage. One way to do this is to represent the risk in condition-transition-
consequence
(CTC) format. That is, the risk is stated in the following form:
Given that <condition> then there is concern that (possibly) <consequence>.
Using the CTC format for the reuse risk one could write:
Given that all reusable software components must conform to specific design standards
and that some do not conform, then there is concern that (possibly) only 70 percent of
the planned reusable modules may actually be integrated into the as-built system,
resulting in the need to custom engineer the remaining 30 percent of components.
This general condition can be refined in the following manner:
Sub-condition 1: Certain reusable components were developed by a third party with no
knowledge of internal design standards.
Sub-condition 2: The design standard for component interfaces has not been solidified
and may not conform to certain existing reusable components.
Sub-condition 3: Certain reusable components have been implemented in a language that is not
supported on the target environment.
The consequences associated with these refined sub-conditions remain the same
(i.e., 30 percent of software components must be custom engineered), but the refinement
helps to isolate the underlying risks and might lead to easier analysis and response.

Q19: What is risk projection? Enlist steps of risk projection.

Ans:
1. Risk projection is called as risk estimation. Risk can be related in two ways as follows:
1) The possibility or probability that the risk is practical or real.
2) The results of the problems linked with the risk.
2. The project planners, other managers and technical staff follow four risk projection
steps or activities:

Mrs. M. P. Patil (DYP POLY, KOP) Page 25

 SEN-22413-Unit 4-Software Project Estimation

1) Establishment of a scale that follows the supposed possibility of a risk.

2) Define the results of the risk.
3) Find out or estimate the impact of the risk on the software project and the software
product.
4) Record the overall correctness of the risk projection so that there will be no
confusions or misunderstandings.
3. The objectives of these four steps are to understand risks in manner that show the way
to prioritization.
4. No software team has all the resources to address every possible risks with the same
degree of severity.
5. After prioritizing risks, the team can allocate resources where they will be having more
importance.
6. The impact of the risk refers to the consequence that takes place if the risk occurs.
7. Following are few important points that assess the risk impacts:
1) Find out the average probability of occurrence value for every component of risk.
2) Find out impact of every component of the risk on the basis of its criteria.
3) Enter full data in risk table and carry out the analysis for the results.

Q20: Study of requirement specification for ABC project has produced following results: Need
for 7 inputs, 10 outputs, 6 inquires, 17 files & 4 external interfaces. Inputs & external interface
function point attributes are of average complexity & all other function points attributes are of
low complexity. Determine adjusted function points assuming complexity adjustment value is
32.
Ans:
Number of external inputs (EIs): 7
Number of external outputs (EOs): 10
Number of external inquiries (EQs): 6
Number of internal logical files (ILFs): 17
Number of external interface files (ELFs): 4
Complexity Adjustment Value (∑Fi)=32
Since Inputs & external interface function point attributes are of average complexity & all
other function points attributes are of low complexity.

Function type X Simple Average Complex Count Total

External Inputs= 7 X 4 28
External Output= 10 X 4 40
External Inquiries= 6 X 3 18
Internal Logical Files= 17 X 7 119
External Interface Files= 4 X 7 28
Count Total 233

Mrs. M. P. Patil (DYP POLY, KOP) Page 26

 SEN-22413-Unit 4-Software Project Estimation

 Step-1:
∑Fi =32

 Step-2:
CAF = [ 0.65 + (0.01*( ∑Fi ) )
CAF = 0.65 + ( 0.01 * 32 ) = 0.97

 Step-3: As weighting factors are also average (given in question)

hence we will multiply each individual function point to corresponding values in
TABLE.

UFP = (7*4) + (10*4) + (6*3) + (17*7) + (4*7)

=28+40+18+119+28=233

 Step-4:
Function Point (FP) = UFP * CAF
Function Point (FP) =233 * 0.97 = 226.01
This is the required answer.

Q21: Calculate using COCOMO model

i) Effort
ii) Project duration
iii) Average staff size
If estimated size of project is 200 KLOC using organic mode.
Ans:
Given data: size=200 KLOC mode= organic
1. Effort:
E = a (KLOC) b
For organic a=2.4 and b= 1.05 E= 2.4 (200) 1.05
= 626 staff members
2. Project duration: TDEV= c (E) d
Where TDEV= time for development
c and d are constant to be determined E = effort
For organic mode, c= 2.5 and d= 0.38
TDEV= 2.5 (626) 0.38
=29 months
3. Average staff size: SS = E/TDEV
SS = 626/29 = 22 staffs

Mrs. M. P. Patil (DYP POLY, KOP) Page 27

 SEN-22413-Unit 4-Software Project Estimation

Q22: Using COCOMO, Calculate effort, duration & person estimation for the following:

i. A semi detached model of software project of 2000 lines

ii. An embedded model of software of 30000 lines
iii. An organic model of software of one lakh lines
iv. An organic model of software of ten lakh lines
Ans:
To estimate time using basic model of COCOMO following formula is used
E = ab*(KLOC)bb PM
D = cb *(E)db Months
P = E/D
Where
E is the total effort required to develop the software product, expressed in person months
(PMs)
D is the estimated time to develop the software, expressed in months,
KLOC is the estimated size of the software product indicated in Kilo Lines of Code,
P is total number of persons required to accomplish the project
ab, bb, cb, db are coefficients for three modes/types are given below:,

Software Projects ab bb cb db
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

i. A semi-detached model of software project of 2000 lines

Given that, project type: - semi-detached
Lines Of Code(LOC)=2000 lines=2KLOC
E = ab*(KLOC)bb
E= 3.0(2)1.15
E=6.65 Person-Month

D = cb *(E)db
D=2.5(6.65)0.35
D=4.8 Months

P = E/D
P=6.65/4.8
P=1.3 ≈ 1 Person

Thus, this project can be completed within 4.8 months by 1 person approximately

ii. An embedded model of software of 30000 lines

Given that, project type: - embedded
Lines Of Code(LOC)=30000 lines=30KLOC
E = ab*(KLOC)bb

Mrs. M. P. Patil (DYP POLY, KOP) Page 28

 SEN-22413-Unit 4-Software Project Estimation

E= 3.6(30)1.20
E=213 Person-Month

D = cb *(E)db
D=2.5(213)0.32
D=14 Months

P = E/D
P=213/14
P=15.2 ≈ 15 Persons

Thus, this project can be completed within 14 months by 15 persons approximately

iii. An organic model of software of one lakh lines

Given that, project type: - organic
Lines Of Code(LOC)=1 lakh =100KLOC
E = ab*(KLOC)bb
E= 2.4(100)1.05
E=302 Person-Month

D = cb *(E)db
D=2.5(302)0.38
D=21 Months

P = E/D
P=302/21
P=14.3 ≈ 14 Persons

Thus, this project can be completed within 21 months by 14 persons approximately

iv. An organic model of software of ten lakh lines

Given that, project type: - organic
Lines Of Code(LOC)= 10 lakh =1000KLOC
E = ab*(KLOC)bb
E= 204(1000)1.05
E=3390 Person-Month

D = cb *(E)db
D=2.5(3390)0.38
D=55 Months

P = E/D
P=3390/55
P=61.6 ≈ 61 Persons

Thus, this project can be completed within 55 months by 61 persons approximately

Mrs. M. P. Patil (DYP POLY, KOP) Page 29

 SEN-22413-Unit 4-Software Project Estimation

Review Questions
Software Project Estimation
1. Define management spectrum and enlist characteristics of software. OR Explain 4 P‘s
software project management spectrum OR Define management spectrum & explain
people, product, process & project in detail.
2. What are the metrics for size estimation types? Explain. OR Explain types of metrics
used for size estimation of the project with advantages & disadvantages
3. State importance of ―Function point ―and ―lines of code‖ in concerned with project
estimation.
4. With an example, explain Line of Code (LOC) based estimation.
5. How to calculate the function point?
6. Explain any one project cost estimation approach. OR What are 3 commonly used cost
estimation approaches used in software project. Explain in details. OR Describe
Heuristic technique, Empirical technique & Analytical technique of cost estimation of
the project.
7. Describe the Analytical method of project cost estimation with example. OR Write a
short note on Halstead‘s software science.
8. Specify following cost directives of cocomo:
 Product attributes (any two)
 Hardware attributes (any two).
9. Describe COCOMO model in detail. OR What are the different models of COCOMO
model? Explain. OR Describe basic model, intermediate model & detailed model of
COCOMO model.
10. Describe COCOMO II model for evaluating size of software project with any three
parameters in detail OR Describe COCOMO-II model in detail.
11. What is software risk? Explain types of software risks.
12. What are the characteristics involved in software risk?
13. Define proactive and reactive risk strategy.
14. Explain in detail RMMM strategy OR Describe RMMM strategy in detail OR Explain
RMMM plan with example.
15. Explain following terms w.r.t. risk management:
(i) Risk identification
(ii) Risk analysis
16. Describe the following with respect to Risk assessment:
(i) Risk identification
(ii) Risk analysis
(iii) Risk prioritization
17. Explain risk refinement
18. What is risk projection? Enlist steps of risk projection.
19. Study of requirement specification for ABC project has produced following results:
Need for 7 inputs, 10 outputs, 6 inquires, 17 files & 4 external interfaces. Inputs &
external interface function point attributes are of average complexity & all other
function points attributes are of low complexity. Determine adjusted function points
assuming complexity adjustment value is 32.

Mrs. M. P. Patil (DYP POLY, KOP) Page 30

 SEN-22413-Unit 4-Software Project Estimation

20. Calculate using COCOMO model

i) Effort
ii) Project duration
iii) Average staff size
If estimated size of project is 200 KLOC using organic mode.
21. Using COCOMO, Calculate effort, duration & person estimation for the following:
i. A semi-detached model of software project of 2000 lines
ii. An embedded model of software of 30000 lines
iii. An organic model of software of one lakh lines
iv. An organic model of software of ten lakh lines

Mrs. M. P. Patil (DYP POLY, KOP) Page 31