Chapter- 4

Software Project Estimation

 Software Project Management
• Software Project Management is to be done in
scientific way.
• It involves the knowledge, techniques and tools
necessary to manage the software development.
• It starts before any activity starts.
• The Software Project Management includes
basic function such as scoping, planning,
estimating, scheduling, organizing, directing,
coordinating, controlling and closing.
 Management Spectrum
• The management spectrum describes the
management/hierarchy of people associated with
a software project.
• How to make a software project successful.
• Effective Software Project Management focuses
on the four P’s:
– People
– Product
– Process
– Project
• The order is not arbitrary.
 The People
• People factor is very much important in the
process of software development.
• There are following areas for software people like,
recruiting, performance management,
training, compensation, career development,
workgroup development, and team/culture
development.
 Stakeholders
• Senior managers who define the business issues that often have
significant influence on the project.
• Project (technical) managers who must plan, motivate, organize,
and control the practitioners who do software work.
• Practitioners/Software Engineer: who deliver the technical skills
that are necessary to engineer a product or application.
• Customers who specify the requirements for the software to be
engineered
• End-users who interact with the software once it is released for
production use.
 Product
1. Before a project can be planned, the product
objectives and scope should be identified.
2. Objectives identify the overall goals for the
product without considering how these goals will be
achieved.
3. Scope identifies the primary data, functions and
behaviors that categorize the product.
4.It identifies cost, risk and realistic break downs of
project task.
 Process
• The process model is the plan to be selected
depending on following factors
– a) Customers and developers.
– b) Characteristics of product itself.
– c) Project environment of software team.
• Regardless of the size and type of project, there
are small number of framework activities that
are applicable to all of them.
• There are also umbrella activities like SQA, that
occur throughout the system.
 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, 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.
 Metric for 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.
• Obviously, while counting the number of source instructions, lines used
for commenting the code and the header lines should be ignored.
• 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 a
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.
2)Function Point:
•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.
•Each function when invoked reads some input data and
transforms it to the corresponding output data.
•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.
 Cost estimation models
• Cost estimation models are some mathematical algorithms or parametric
equations that are used to estimate the cost of a product or a project.
• Various techniques or models are available for cost estimation, also known
as Cost Estimation Models as shown below :
 Empirical estimation

• Empirical estimation is a technique or model in which empirically derived

formulas are used for predicting the data that are a required and
essential part of the software project planning step.
• These techniques are usually based on the data that is collected
previously from a project and also based on some guesses, prior
experience with the development of similar types of projects, and
assumptions.
• It uses the size of the software to estimate the effort. In this technique,
an educated guess of project parameters is made. Hence, these models
are based on common sense.
• However, as there are many activities involved in empirical estimation
techniques, this technique is formalized. For example Delphi technique
and Expert Judgement technique.
 Heuristic Technique
• Heuristic word is derived from a Greek word that means “to discover”.
• The heuristic technique is a technique or model that is used for solving
problems, learning, or discovery in the practical methods which are used
for achieving immediate goals.
• These techniques are flexible and simple for taking quick decisions
through shortcuts and good enough calculations, most probably when
working with complex data. But the decisions that are made using this
technique are necessary to be optimal.
• In this technique, the relationship among different project parameters is
expressed using mathematical equations. The popular heuristic
technique is given by Constructive Cost Model (COCOMO). This
technique is also used to increase or speed up the analysis and
investment decisions.
 Analytical Estimation Technique

• Analytical estimation is a type of technique that is used to measure

work. In this technique, firstly the task is divided or broken down into
its basic component operations or elements for analyzing.
• if the standard time is available from some other source, then these
sources are applied to each element or component of work.
• if there is no such time available, then the work is estimated based
on the experience of the work. In this technique, results are derived
by making certain basic assumptions about the project. Hence, the
analytical estimation technique has some scientific basis. Halstead’s
software science is based on an analytical estimation model.
 Project Risks
What can go wrong?
What is the likelihood?
What will the damage be?
d o a b o u t i t ?
c a n we
W h at
 Risk Management
• 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.
• Risk is an expectation of loss, a potential
problem that may or may not occur in the future.
• It is generally caused due to lack of information,
control or time.
• A possibility of suffering from loss.
• Loss can be anything, increase in production
cost, development of poor quality software,
not being able to complete the project on time.
 Concept of Proactive and Reactive
risk strategies
Reactive Risk:
• 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:
• 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
 Types of Software Risks
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.
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.
 Continue
(d) Market Risk:- Building product that no one wants
(e) Strategic Risk: - Building a product that no
longer fits into the business strategy
(f) Management Risk: - Building a product that the
sale force doesn‘t understand.
(g) Budget Risk: - Losing budgetary or personnel
commitment
 Risk Assessment

• In initial stages of project planning a risk is stated

generally. As the time passes, it is important to
divide that risks into sub types and try to refine it.
Risk Management Paradigm

control

track

RI S identify

plan
K analyze
 Risk identification

• Risk identification can be defined as systematic

attempt to specify or find out threats to the
project plan. Project plan includes estimation,
resource distribution etc.
• With the help of finding well known and predictable
risks, the project manager or leader can take first
step to deal with or avoid them.
• These risks need to be controlled or avoided as per
its form.
 Risk Analysis

• After identification of the risk, risk analysis has to

be done.
• The process of risk analysis is analyzing the
potential risks with its types and details.
• The time and efforts needed for risks analysis
are huge.
• Analysis starts with what risks are there, their
probability and consequences with their impact
on the project.
Risk refinement : In initial stages of project
planning a risk is stated generally. As the time
passes it is important to divide that risks into its
sub types and try to refine it.
The way to refine risk is to represent the risk in
condition – transition – consequence i.e. CTC
format. The risk can be stated as follows.
<Condition>(Possibly)<Consequence>
 Risk Prioritization
• For the purpose of deciding the priority of the
risk, process called as risk prioritization is used.
• When first four columns of the risk table are filled
with the risk related data, the table needs to be
sorted by probability and by impact.
• The risk with high probability and high impact
risks are located at the top of the table.
• The risks with low probability go to the bottom of
the table after sorting.
• This is called as first order prioritization of the
risks.
• The project manager analyses the sorted risk
table and defines the cutoff line.
• It is a horizontal line at some point in the table.
The risk above this line will be given more
attention. The risks below the line will be again
reviewed and evaluated.
• After this, again second order prioritization of the
risk below cut off line is done.
 RMMM strategy

• An effective strategy must consider three issues:

risk avoidance, risk monitoring, and risk
management and contingency planning.
• A risk management technique is usually seen in
software project plan
• Risk is documented with the help of Risk
Information sheet.
 Risk Mitigation(Avoid Risk)
• It is Proactive approach. Apply before risk have generate.
• Step to mitigate the risk as follow:
 Communicate with current staff to find probable risk: Meet with
current staff to determine causes for turnover (e.g., poor working
conditions, low pay, competitive job market).
 Mitigate those causes that are under your control before the
project starts.:
– Removing all causes that the reason for risk creation.
 Develop a policy in an organization which will help to continue the
Project
 Controlling the corresponding document from time to time.
 Conducting timely review to speed up the work.
 Risk Monitoring
 Risk monitoring is an activity used to track a project
progress.
 Performed by project Manager.
 Objective of risk monitoring process:
 -To check if predicted risk occure or not.
 -To ensure proper application of risk avoidance are
apply or not
 -To gather information for future risk assessments
 -To determine which risk generate which problem
throughout the project.
 Risk Management

 It is reactive approach. apply after risk have generate.

 It assumes that the mitigation activity failed and risk
occure in reality.
 This task is done by project manager .they will solve
generated risk.
 If project manager effectively uses project mitigation to
remove risk successfully then it is easier to manage the
risk.
 RMMM Plan Example
• Risk Generated: Late Delivery of project
1. Mitigation:
• Before development apply some precautionary Measure
• Developer already knew project will be complete in 20 days. but he
told customer project will complete in 30 days.
2.Monitoring:
• To develop project schedule Mentioned start and end date of project
.with in 20 to 30 days.
3.Management:
• Project not complete with in deadline then negotiate with customer.
• Ask some extra time or give some additional feature etc.