Chapter 4

Software Project Estimation

and
Risk Management

1
 Software Project Estimation

• Contents to be covered:-
 Software Project Estimation
 Estimation Approaches
 Risk and Change Management
 Software Risks
 Risk Management
 Risk Monitoring and Control

2
 Software Project Estimation
• Software project management begins with a set of activities
that are collectively called project planning
• Software project planning encompasses five major
activities:-
o Project estimation
o Project scheduling
o Risk analysis
o Quality management planning
o Change management planning

3
 Cont..

• Before a project begins project manager must estimate:

o The work to be done
o The resources that will be required
o The time that will be elapsed from start to finish
• The software team must establish a project schedule that
defines:-
o Software engineering tasks
o Milestones
o Responsible for conducting each task
o Inter-task dependencies

4
 Cont’d
• Estimation lays a foundation for all other project planning activities
and that project planning provides the road-map for successful
software engineering.
• Estimation is as such “Art” as it is science. However this important
activity need not be conducted in a haphazard manager
• Software estimation begins with a description of the “scope of
software product” until the scope is “bounded "it is not possible to
develop a meaningful project estimate.
• The problem is then decomposed into a set of smaller problems
and each of these is estimated using historical data and/or pervious
experience as a guide.
5
 Cont’d

• The problem complexity and risk are then considered before final estimate is
made.
• Estimation of resources, Cost and Schedule for a Software Engineering Effort
requires: Experience, Access to good historical information (Project Metrics)
Courage to commit to Quantitative predictions (when Quantitative information
is all that exists).
• Estimation carries inherent “RISK”, and this Risk leads to uncertainty. The
availability of Historical Information (Project Metrics) has a strong influence on
estimation risk.
• Estimation Risk is measured by the degree of uncertainty
• In the Quantitative Estimates establish for resources, Cost and Project Schedule.
• Estimation Risk becomes dangerously high when Project Scope is poorly
understood or Project Requirements are subject to changes.
6
 Software Estimation: Software Scope and Feasibility
• Software Scope Describes:
 The function and features that are to be delivered to end-users.
 The data that are input and output.
 The “Content” that is presented to user as a consequence of using the
software.
 Performance, constraints, reliability and interfaces that bounds the
system.
 Software Scope is defined using one of the following techniques:
o A narrative description of software scope is developed after
communication with all stakeholders.
o A set of Use-Cases are developed by end-users.

7
 Scope Consideration
• Scope Consideration Functions described in the “Statement of Scope”
or within the Use-Cases are evaluated and in some cases refined to
provide more detail point to the beginning of Estimation.
• Because both Cost and Schedule Estimates are functionally oriented,
some degree of functional decomposition is useful.
• Performance considerations encompass Processing and Response
time requirements.
• Constraints identify limits placed on the software by hardware,
available memory size on other existing system.

8
 Cont’d
• Once the Project Scope has been identified it is reasonable to ask
yourself:-
o Can we build the Software to meet this scope?
o Is the Project feasible?
• Often Software Engineers rush past these questions only to become
mired (become stuck) in a Project that is doomed from the onset. Since
not everything in real life is feasible, the Software Feasibility is
emphasized in Estimation.
• Software Feasibility has four solid dimensions:
o Technology
o Finance
o Time
o Resources
9
 Software Scope and Feasibility
• Once the Software Scope and Feasibility have been identified the second task is
Estimation of the “RESOURCES” required to accomplish the Software Development
Effort.
• The three major categories of Software Engineering Resources:
o People
o Reusable software components.
o Development environment (H/W, S/W Tools)
• Each Resources is specified with four Characteristics:
o Description of the resource.
o A statement of availability.
o Time when resources will be required.
o Duration of the time that resource will be applied.
NOTE: The last two characteristics can be viewed as a “Time Window”.
• Availability of the Resource for a specified window must be established at the earliest
practical time.
10
 Software Estimation: Human Resources
• The Project Planner begins by evaluating Software Scope and
selecting the ‘’skills’’ required to complete development Both
organizational position
Example:
o Manager, Senior Software Engineer etc. and the specialty
o Database Telecommunication, client/server etc. and the Location of each
human resource is specified.
• The Number of People required for a Software Project can be
determined only after an Estimate of Development Effort
Example: Person-months is made.

11
 Software Estimation : Reusable Software Resources
• The Reusable Software Resource categories: Off-the-shelf Components
• Full-experience Components, Partial experience Components, New
Components:
• Guidelines for Planning Reusable Resource Components :-
o If Off-the-Shelf Components meet Project requirement acquire them. The cost of
the off-the-shelf components will almost always be less than the cost to develop
equivalent software. Also risk is low.
o If full-experience components are available, the risk associated with modification
and integration are generally acceptable.
o If Partial-Experience Components are available, the use of them for current Project
must be carefully analyzed If extensive modification is required proceed carefully
since the cost to modification can sometimes be greater than the cost to develop
new components also Risk is high.

12
 Software Estimation: Environnemental Resource
• The Software Engineering Environment (SEE) corporate Hardware and
Software / NetWare.
• H/W provides a platform that support the tools required to produce
Work Products that are outcome of good Software Engineering
practice.
• When a System is to be engineered the Software team may require
access to H/W elements being developed by other Engineering teams.
• Software Project Planner must specify each Hardware element and
the Time window for HW / SW and verify that these resources will be
available.

13
 Software Project Estimation
• Software is the most expensive element of virtually all Computer-Based
System. For complex, custom System, a large Cost Estimation error can
make the difference between profit and loss. Cost overrun can be
disastrous.
• Software Cost and Effort Estimation will never be an exact science.
Because too many Variable Factors can affect the ultimate Cost of
Software and Effort applied to develop it.
• Variable Project Factors:
o Human Factor
o Technical Variable Factors
o Environmental Factors
o Political Factors

14
 Options for Reliable Estimates

1) Delay Estimation until late in the Project (obviously we can achieve

accurate Estimates after the Project is complete)
2) Base Estimates on similar Projects that have already been
completed.
3) Use one or more Empirical Models for Software cost and Effort
Estimation.
4) Use relatively simple Decomposition Techniques to generate
Project Cost and Effort Estimates. Each of the viable Software Cost
Estimation options are only as good as the Historical data used to
seed the estimation.
• If no Historical data (metrics) exist, costing rest on a very shaky foundations.
15
 Software Estimation: Décomposition Techniques

• Software Project Estimation is a form of Problem solving, and in

most cases, the Problem to be solved is too complex in one
piece. For this reason, we decompose the problem, re-
characterizing it as a set of smaller problems. Estimation uses
one or both form of the two different partitioning point of
views:-
• Decomposition of the Problem
• Decomposition of the Process
• Before an Estimate can be made , the Project Planner must
understand the Scope of the Software to be built and generate
an Estimate according to the ‘’Size of Software’’.
16
 Software Estimation: Software Project Sizing
• Accuracy of a Software Project Estimate is predicted on a number of things:
• The degree to which the Planner has properly Estimated the Size of the Product to be
built.
• The ability to translate the Size Estimate into Human-effort (Calendar Time and Money)
• The degree to which the Project Plan reflects the abilities of Software team.
• The stability of Product requirements and the environment that supports the Software
Engineering effort.
• Sizing represents the Project Planner’s first major challenge since a Project
Estimate is only as good as the Estimate of the Size of the work to be
accomplished
• Size refers to a Quantifiable outcome of the Software Project.
• If a direct approach to Sizing is taken size can be measured in LOC(Line of codes)
• If an Indirect approach is taken that the sizing approach is represented as FP(Function
Points)
17
 Cont’d
• There are Four Different Sizing Approaches:
1. Fuzzy Logic Sizing - gather size data on previously developed programs
2. Function Point Sizing - measure of functionality derived by applications
3. Standard Component Sizing -individual component is built within same specification
4. Change Sizing
• The result of each Sizing approaches must be combined statistically to
create “Expected-Value Estimate.” This is accomplished by determining the
following values for:-
• Optimistic - Lowest estimation value
• Most Likely - Moderate estimation value
• Pessimistic - High estimation value

18
 Risk Vs. Problem
• A problem is a condition that exists and is undesirable. Thus it is
a value judgment made upon the merits of the current
condition.
• A risk suggests a possible, future undesirable condition (or
consequence). Thus it is a value judgment made upon the
potential implications of the current conditions.
• Risks that are not identified (or identified but not prevented)
will later become problems
Note: Risks are not always problems; they can be beneficial

19
 Software Risks
• Risk analysis and management are a set of activities that
help a software team to understand and manage uncertainty
about a project.
• Definition: Risk is the uncertainty associated with the outcome of a future event and
has a number of attributes:
• Uncertainty (probability)
• Time (future event)
• Potential for loss or gain
• Multiple perspectives
e.g.
• Process perspective -development process breaks
• Project perspective - critical objectives are missed
• Product perspective - loss of code integrity
• User perspective -loss of functionality
20
 Risk classification
• Pressman classified project risks into three types:
1) Project Risks: threaten the project plan e.g. cost overrun
2) Technical Risks: threaten the quality and timeliness of the product
e.g. specification ambiguity
3) Business Risks: threaten the viability of the product
e.g. product not aligned with business strategy or losing upper
management support, or losing budget

21
 Risk Management
• Traditionally:
o Risk is the possibility of suffering loss
• In project management:
o Project Risk is an event or condition that, if it occurs has
positive or negative influence on an objective
• Negative outcome: menace/threat
• Positive outcome: opportunity

22
 Risk Management
• Risk management is the process by which a course of action is selected
that balances the potential impact of a risk weighted by its probability
of occurrence and the benefits of avoiding (or controlling) the risk
• Risk management life cycle:
• Identify (risk identification)
• Analyze (risk analysis)
• Plan (contingency planning)
• Track (risk monitoring)
• Control (recovery management)
• Two types of risk management:
i. Reactive risk management
ii. Proactive risk management

23
 Cont’d
• Reactive Risk Management
• Project team reacts to risk when they occur
• Fix on failure: resources are found and applied when the risks strike
• Crisis management: failure does not respond to applied resources and the
project is in danger.
• Proactive Risk Management
• Formal risk analysis is performed
• An attempt is made to correct the root causes
o Statistical SQA
o Developing skills to manage changes
o Examining risks sources beyond the bounds of the software

24
 Risk Management..
•Risk management collects techniques, know-how and processes to help
identify, assess, manage, and monitor risks
•The objectives of Project Risk Management is to increase the probability and
the impact of positive events and decrease the probability and impact of
events adverse to the project.
•Goals :
• Understanding whether a project is worth taking
• Help refining the budget for the project
• Increase chances of ending the project successfully
• Increase chances of terminating the project as planned:
• Within scope
• Within quality
• Within budget
• On time

25
 Cont’d…
• Used in several fields, such as:
– Finance
– Insurance
– Engineering (safety critical, security, …)
• Various standards recognize the importance of risk in software
development:
– ISO/IEC 12207 (Information Technology - Software life cycle processes)
– UNI EN 29000-3 (Guidelines for the application of ISO 9001 to software
development and maintenance)
– UNI ISO 10006 (Guidelines for managing projects)
• Various techniques (FMEA, FTA, simulation, …) have been defined and
adopted to assess it.

26
Software Life Cycle Processes

27
The Risk Management Process

28
 The Risk Management Standards
•Goals :
• Describing how risk management will be structured and performed on the project.
o Output: a document (or set of documents and templates)
o Part of the project management plan
o Helps define project standards and best practices
• The document includes, at a minimum:
o The procedures to monitor and update risks
o The procedures to apply contingency plans
o Who is in charge of what
• Added value:
o Definition of risk probabilities and impacts
o Risk Categories or other sources to identify risks
o Reporting formats
• A risk management plan could be standardized and adopted organization-wide.
•Different projects require different levels of formality in risk management

29
 Risk Identification
• Goal: understanding what are the risk that could potentially
influence the project and document their characteristics
• Risk identification is an iterative process (new risks may be
identified as the project progresses; old risks may become
“obsolete”)
• Output: Risk Register, basis for qualitative/quantitative risk
analysis

30
 Risk Identification and Classification
• Process (iterative):
• Collect:
* identify specific project risks
* describe the risk
• Analyze:
* Identify the root causes (do not misinterpret effects as causes)
* Define the risk category (impact) and probability
* Identify other useful characteristics:
o When it can occur or frequency of occurrence
o How it manifests
• Output:
o Risk Register

31
 Risk Identification Techniques

• Meetings
• Document analysis
• Risk breakdown structures, checklists and templates
• Analogy/correlation

32
 Causes for Project Failures
• Boehm developed a list of the ten most common causes for
projects to fail
• Some of the causes mentioned in the list can be used as starting point to identify the
risks applicable to a project at hand
• Risks include:
 Poor Preparation
 Inadequate Documentation and Tracking
 Bad Leadership
 Failure to Define Parameters and Enforce Them
 Inexperienced Project Managers
 Inaccurate Cost Estimations
 Little Communication at Every Level of Management
 Culture or Ethical Misalignment
 Competing Priorities
 Disregarding Project Warning Signs

33
 Documenting Risks
• Use a “risk Identification Form”
• Fields may include:
o ID
o Description
o Category
o Probability
o Potential consequences
o Indicator
o Avoidance approach
o Related risks
o Action items

34
Fishbone Diagrams: Some starting points
• The 6 M's:
o Machine, Method, Materials, Measurement, Man and Mother
Nature/Environment (recommended for manufacturing industry).
• The 8 P's:
o Price, Promotion, People, Processes, Place / Plant, Policies, Procedures
& Product/Service (recommended for administration and service
industry).
• The 4 S's:
o Surroundings, Suppliers, Systems, Skills (recommended for service
industry).

35
Risk Assessment and Risk Management Strategies
Risk Assessment
• Goal: prioritize risks according to their impact and likeness on the project
– Output: a prioritized list of risks (priority defined according to probability and
impact)
– Information on whether a project is worth taking
– Information about what risks must be monitored

36
 Techniques
• Qualitative Risk Analysis
o Simpler
o Can be used when no precise information about probabilities
of risk is available
• Quantitative Risk Analysis
o More systematic
o Suitable for mathematical analysis
o Provide figures on the (economical) impact of risks

37
 Risk Projection

• Estimate the probability of occurrence

• Estimate the impact on the project on a particular scale
e.g.
o Low impact (negligible)
o Medium impact (marginal)
o High impact (critical)
o Very high impact (catastrophic)
• Build a risk table and sort by probability and impact

38
 RMMM: Risk Mitigation, Monitoring, and Management

 Mitigation: how can we avoid the risk?

 Monitoring: what factors can we track that will enable us to
determine if the risk is becoming more or less likely?
 Management: what contingency plans do we have if the risk
becomes a reality?

39
 Risk Monitoring and Control
• Risk Monitoring and Control is the process of identifying, analyzing, and planning
for newly identified risks, monitoring previously identified risks, and reevaluating
existing risks to verify the planned risks response strategies for their effectiveness.
• Activities involved in Risk Monitoring include:
o Establish periodic reviews and schedule them in the project plan.
o Ensure that all requirements of the Risk Management Plan are being implemented.
o Assess currently defined risks as defined in the Risk Register.
o Evaluate effectiveness of actions taken.
o Identify status of actions to be taken.
o Validate previous risk assessments (likelihood and impact).
o Validate previous assumptions and state any new assumptions.
o Identify new risks.
o Track risk response.
o Communicate risk management status and risk response follow-through as appropriate.
40
 Cont’d
• Activities involved in Risk Control include:
• Validate risk mitigation strategies and alternatives.
• Take corrective action when actual events occur.
• Assess impact on the project of actions taken (cost, time, resources).
• Identify new risks resulting from risk mitigation actions.
• Ensure the Project Plan (including Risk Management Plan) is maintained.
• Ensure change control addresses risks associated with the proposed change.
• Revise risk management documents to capture results of mitigation actions.
• Update Risk Register.
• Communicate risk management status and risk response follow-through as
appropriate.
• Establish communications as appropriate.
41
Q? 42