SEN (AY 2023-24) Software Project Estimation

UNIT 4: SOFTWARE PROJECT ESTIMATION

4.1 The management Spectrum: 4p’s
Effective software project management focuses on the four P’s: People, Product, Process, and
Project.
The People:
Consists of the stakeholders, the team leaders, and the software team.
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.

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

ZEBA SYED Page 1

SEN (AY 2023-24) Software Project Estimation

4.2 Metrics for Size Estimation

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):

This method is developed by Albercht in 1979 for IBM. 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. Albrecht suggested that in addition to the number of basic functions that a software
performs, the size is also dependent on the number of files and the number of interfaces.
The data for the following information domain characteristics are collected:
Number of user inputs
Number of user outputs
Number of user inquiries
Number of internal files
Number of external files

4.3 Project Cost Estimation Approaches:

(i) Heuristic
This method makes use of previous project’s estimated cost.
Heuristic techniques assume that the relationships among the different project parameters can
be modeled using suitable mathematical expressions. Once the basic parameters are known,
the other 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 multi variable 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 * e1 d1

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 * e1 d1 + c 2 * e2 d2 + ...

Where e1, e2, … are the basic (independent) characteristics of the software already estimated,
and c1, c2, d1, d2, … are constants.

ZEBA SYED Page 2

SEN (AY 2023-24) Software Project Estimation

(ii) Analytical
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

iii. Empirical Estimation Technique

In this technique, an educated guess of project parameters is made. Hence, the empirical
model is based on common sense. Delphi technique is used for empirical estimation
techniques. This method involves more interactions and communications between those who
are participating. The procedure is as follows:
The co-ordinator presents a specification and estimation form to each expert.
Co-ordinator calls a group meeting in which the experts discuss estimation issues with the co-
ordinator and each other.
Experts fill out forms anonymously
Co-ordinator prepares and distributes a summary of the estimates.
The co-ordinator then calls a group meeting. In this meeting the experts mainly discuss the
points where their estimates vary widely.
The experts again fill out the forms anonymously.
Again co-ordinator edits and summarizes the forms, until the co-ordinator is satisfied with
overall predictions from experts.

4.5 RISK MANAGEMENT

Definition of Risk: Risk denotes the uncertainty. Risk is an undesirable outcome that poses a
threat to the achievement.

ZEBA SYED Page 3

SEN (AY 2023-24) Software Project Estimation

(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?

(ii)Risk Assessment
Risk Assessment is done during the project planning. In this phase, the risks are identified,
analyzed and then prioritized on the basis of analysis.
This risk assessment is done throughout the project. It is most needed at the starting phases of
project. The goal of risk assessment is to prioritize the risks that require attention.

(iii)Risk Containment
After all the identified risks of a project are assessed, plans must be made to contain the most
damaging and most likely risks. There are three main strategies to plan for risk containment:
Avoid the risk: This may take several forms such as discussing with the customer to change
the requirements to reduce the scope of the work, giving incentives to the engineers to avoid
the risk of manpower turnover, etc.
Transfer the risk: This strategy involves getting the risky component developed by a third
party.
Risk reduction: This involves planning ways to contain the damage due to risk.

RMMM Strategy
Risk mitigation, monitoring, and management (RMMM) 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.

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

ZEBA SYED Page 4

SEN (AY 2023-24) Software Project Estimation

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.
• 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.

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.

Define proactive and reactive risk strategy.

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 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.

4.4 COCOMO (Cost Constructive Model)

COCOMO is one of the most widely used estimation models in the world. This model is
developed in 1981 by Barry Boehm to give an estimate of the number of man-months it will
take to develop a software product.
COCOMO has three different models that reflect the complexity
Basic model
Intermediate model
Detailed model

Similarly there are three classes of software products:

Organic mode: in this mode, small simple software projects with a small team are handled.
Semi-detached: In this, intermediate projects with teams of mixed experience level are
handled.

ZEBA SYED Page 5

SEN (AY 2023-24) Software Project Estimation

Embedded: In this, projects with tight hardware, software and operational constraints are
handled.

Basic model

Intermediate model

ZEBA SYED Page 6

SEN (AY 2023-24) Software Project Estimation

COCOMO II

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
:

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 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 KSLOC.

-Architecture Model

ZEBA SYED Page 7

SEN (AY 2023-24) Software Project Estimation

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

In COCOMO II effort is expressed as Person Months (PM). The inputs are the Size of
software development, a constant, A, and a scale factor, B. The size is in units of thousands
of source lines of code (KSLOC). The constant, A, is used to capture the multiplicative
effects on effort with projects of increasing size.
The parameters used in COCOMO II are described below:-

a. Person month- A person month is the amount of time one person spends working on the
software development project for one month. The nominal effort for a given size project and
expressed as person months (PM) is given by Equation 1.
PMnominal =A* (Size)B
Where
A- constant
B = 0.91 + 0.01 Σ(exponent driver ratings)
- B ranges from 0.91 to 1.23
- 5 drivers; 6 rating levels each

b. Maintenance size is the amount of project code that is change. It

is calculated as below:-
Size=[(BaseCodeSize) *MCF] *MAF
COCOMO II uses the reuse model for maintenance when the amount of added or changed
base source code is less than or equal to 20% or the new code being developed. Base code is
source code that already exists and is being changed for use in the current project. For
maintenance projects that involve more than 20% change in the existing base code (relative to
new code being developed) COCOMO II uses maintenance size.

c. Maintenance Change Factor MCF

The percentage of change to the base code is called the Maintenance Change Factor (MCF).
MCF= (SizeAdded +SizeModified)/BaseCodeSize

d. Maintenance effort (MAF)

COCOMO II instead used the Software Understanding (SU) and Programmer Unfamiliarity
(UNFM) factors from its reuse model to model the effects of well or poorly
structured/understandable software on maintenance effort.
MAF=1+ (SU.01*UNFM)

ZEBA SYED Page 8