Risks and Estimations in Software Project

BSIT-6
University Institute of Information Technology (UIIT),
PMAS-Arid Agriculture University (AAUR), Rawalpindi
Lecture Agenda
▪ Part I
▪ Types of Risks and Management in SPM
▪ Part II
▪ Software Pricing
▪ Part III
▪ Project Scheduling

▪ Part IV
▪ Project Estimations
 Part I

Types of Risks and Risk Management in SPM

Types of Risks and Risk Management

▪ Risk management is concerned with identifying

risks and drawing up plans to minimise their
effect on a project.

▪ You have to anticipate risks, understand the

impact of these risks on the project, the product
and the business, and take steps to avoid these
risks.
Types of Risks in Software Project

▪ Project risks affect schedule or resources;

▪ Product risks affect the quality or

performance of the software being developed;

▪ Business risks affect the organisation

developing or procuring the software.
Examples of Project, Product, and Business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.

Hardware unavailability Project Hardware that is essential for the project will not be delivered on
schedule.
Requirements change Project and product There will be a larger number of changes to the requirements than
anticipated.
Specification delays Project and product Specifications of essential interfaces are not available on
schedule.

Technology change Business The underlying technology on which the system is built is
superseded by new technology.
Product competition Business A competitive product is marketed before the system is completed.
The Risk Management Process
Risk Identification
▪ May be a team activities or based on the individual project
manager’s experience.
▪ A checklist of common risks may be used to identify risks in a
project
▪ Technology risks.
▪ Organizational risks.
▪ People risks.
▪ Requirements risks.
▪ Estimation risks.
 Risk Analysis
▪ Assess probability and seriousness of each risk.

▪ Probability may be very low, low, moderate, high or very

high.

▪ Risk consequences might be catastrophic, serious,

tolerable or insignificant.
Risk Planning
▪ Consider each risk and develop a strategy to manage that risk.
▪ Avoidance strategies
▪ The probability that the risk will arise is reduced;

▪ Minimization strategies
▪ The impact of the risk on the project or product will be reduced;

▪ Contingency plans
▪ If the risk arises, contingency plans are plans to deal with that risk;
Risk Monitoring
▪ Assess each identified risks regularly to decide whether or
not it is becoming less or more probable.

▪ Also assess whether the effects of the risk have changed.

▪ Each key risk should be discussed at management progress

meetings.
Risk Types and Examples
Risk Probability Effects

Organizational financial problems force reductions in the project budget (7). Low Catastrophic

It is impossible to recruit staff with the skills required for the project (3). High Catastrophic

Key staff are ill at critical times in the project (4). Moderate Serious

Faults in reusable software components have to be repaired before these Moderate Serious
components are reused. (2).

Changes to requirements that require major design rework are proposed (10). Moderate Serious

The organization is restructured so that different management are responsible for High Serious
the project (6).

The database used in the system cannot process as many transactions per second Moderate Serious
as expected (1).
 Part II
Software Pricing
Software Pricing
▪ Estimates are made to discover the cost, to the developer, of
producing a software system.
▪ You take into account, hardware, software, travel, training and
effort costs.
▪ There is not a simple relationship between the development cost
and the price charged to the customer.

▪ Broader organisational, economic, political and business

considerations influence the price charged.
Factors Affecting Software Pricing
Factor Description

Contractual terms A customer may be willing to allow the developer to retain ownership of
the source code and reuse it in other projects. The price charged may
then be less than if the software source code is handed over to the
customer.

Cost estimate If an organization is unsure of its cost estimate, it may increase its price
uncertainty by a contingency over and above its normal profit.

Financial health Developers in financial difficulty may lower their price to gain a contract.
It is better to make a smaller than normal profit or break even than to go
out of business. Cash flow is more important than profit in difficult
economic times.
Factors Affecting Software Pricing
Factor Description

Market A development organization may quote a low price because

opportunity it wishes to move into a new segment of the software
market. Accepting a low profit on one project may give the
organization the opportunity to make a greater profit later.
The experience gained may also help it develop new
products.
Requirements If the requirements are likely to change, an organization may
volatility lower its price to win a contract. After the contract is
awarded, high prices can be charged for changes to the
requirements.
 Pricing Strategies
▪ Under pricing
▪ A company may underprice a system in order to gain a contract that
allows them to retain staff for future opportunities
▪ A company may underprice a system to gain access to a new market
area
▪ Increased pricing
▪ The price may be increased when a buyer wishes a fixed-price
contract and so the seller increases the price to allow for
unexpected risks
Pricing to Win
▪ The software is priced according to what the software developer
believes the buyer is willing to pay

▪ If this is less that the development costs, the software functionality

may be reduced accordingly with a view to extra functionality being
added in a later release

▪ Additional costs may be added as the requirements change and these

may be priced at a higher level to make up the shortfall in the original
price
 Part III
Project Scheduling
 Project Scheduling
▪ Project scheduling is the process of deciding how the work in a
project will be organized as separate tasks, and when and how these
tasks will be executed.
▪ You estimate the calendar time needed to complete each task, the
effort required and who will work on the tasks that have been
identified.
▪ You also have to estimate the resources needed to complete each
task, such as the disk space required on a server, the time required
on specialized hardware, such as a simulator, and what the travel
budget will be.
Project Scheduling Activities
▪ Split project into tasks and estimate time and resources required to
complete each task.
▪ Organize tasks concurrently to make optimal use of workforce.
▪ Minimize task dependencies to avoid delays caused by one task waiting
for another to complete.
▪ Dependent on project managers intuition and experience.
The Project Scheduling Process
 Scheduling Problems
▪ Estimating the difficulty of problems and hence the cost of
developing a solution is hard.
▪ Productivity is not proportional to the number of people working on a
task.
▪ Adding people to a late project makes it later because of
communication overheads.
▪ The unexpected always happens. Always allow contingency in
planning.
 Milestones and Deliverables
▪ Milestones are points in the schedule against which you can assess
progress, for example, the handover of the system for testing.

▪ Deliverables are work products that are delivered to the customer,

e.g. a requirements document for the system.
Tasks, Durations, and Dependencies
Activity Bar Chart
Staff Allocation Chart
 Part IV
Estimation Techniques
 Estimation Techniques
▪ Organizations need to make software effort and cost estimates. There
are two types of technique that can be used to do this:
▪ Experience-based techniques The estimate of future effort requirements is
based on the manager’s experience of past projects and the application domain.
Essentially, the manager makes an informed judgment of what the effort
requirements are likely to be.
▪ Algorithmic cost modeling In this approach, a formulaic approach is used to
compute the project effort based on estimates of product attributes, such as size,
and process characteristics, such as experience of staff involved.
 Experience-based Approaches
▪ Experience-based techniques rely on judgments based on
experience of past projects and the effort expended in these projects
on software development activities.
▪ Typically, you identify the deliverables to be produced in a project and
the different software components or systems that are to be
developed.
▪ You document these in a spreadsheet, estimate them individually and
compute the total effort required.
▪ It usually helps to get a group of people involved in the effort
estimation and to ask each member of the group to explain their
estimate.
 Problem with Experience-based Approaches
▪ The difficulty with experience-based techniques is that a new software
project may not have much in common with previous projects.
▪ Software development changes very quickly and a project will often
use unfamiliar techniques such as web services, application system
configuration or HTML5.
▪ If you have not worked with these techniques, your previous
experience may not help you to estimate the effort required, making it
more difficult to produce accurate costs and schedule estimates.
 Algorithmic Cost Modelling
▪ Cost is estimated as a mathematical function of product, project and
process attributes whose
values are estimated by project managers:
▪ Effort = A ´ SizeB ´ M
▪ A is an organisation-dependent constant, B reflects the
disproportionate effort for large projects and M is a multiplier
reflecting product, process and people attributes.
▪ The most commonly used product attribute for cost estimation is code
size.
▪ Most models are similar but they use different values for A, B and M.
 Estimation Accuracy
▪ The size of a software system can only be known accurately when it
is finished.
▪ Several factors influence the final size
▪ Use of reused systems and components;
▪ Programming language;
▪ Distribution of system.
▪ As the development process progresses then the size estimate
becomes more accurate.
▪ The estimates of the factors contributing to B and M are subjective and
vary according to the judgment of the estimator.
Effectiveness of Algorithmic Models
▪ Algorithmic cost models are a systematic way to estimate the
effort required to develop a system. However, these models are
complex and difficult to use.
▪ There are many attributes and considerable scope for uncertainty in
estimating their values.
▪ This complexity means that the practical application of algorithmic
cost modeling has been limited to a relatively small number of large
companies, mostly working in defense and aerospace systems
engineering.
Project Estimations
Planning - Estimating
Source Information
Statement of Work
Requirements WBS Size Estimate
Estimate
Constraints Effort and
Standards Size
Processes
Cost
History
etc. Effort
Revise & &
Negotiate Cost
Not OK
Estimated
OK Schedule Estimate
Cost Evaluate
Schedule
& Schedule
Estimation
▪ The process of forecasting/predicting, or approximating the amount of
▪ Effort
▪ Cost
▪ Duration
▪ required for completing project and/or project deliverables.
Duration vs. Effort vs. Productive Time
▪ Duration is the elapsed time in business working days
▪ Work effort is the labor required to complete an activity.
▪ Work effort is typically the amount of focused and uninterrupted labor time
required to complete an activity.
▪ Productive time considers the percentage of the work day that can
be devoted to project activity work.
▪ Estimates in software range from 66-75%, recent estimates of about 50-65%
(same client base). This doesn’t include unexpected interruptions!
Elapsed time vs. work time
 Why Estimation?
▪ The most common problem in building the software systems is not
the construction of them itself, but rather the estimation of the
cost of that construction [Robert L Glass (Software Runaways)]
▪ According to the Standish Group CHAOS report of 2003:
▪ 15% of software projects are terminated before they produce anything
▪ 66% are considered to have failed
▪ Of those that do complete the average cost blowout is 43%
▪ “On average, Government projects are being delivered 37% later than
their estimate and 22% over their cost estimate.”
ISBS Group report of January 2004 on Government projects in Australia.
Why Estimate ?
▪ To determine if planned features are realistic in terms of
▪ Resources (effort)
▪ Schedule, and
▪ Cost
▪ To determine staff loading during phases
▪ To be competitive
▪ To allow project monitoring and controlling
When to Estimate?
▪ Throughout the software lifecycle
▪ Initial estimates
▪ Detailed estimates
▪ Re estimates
▪ Software cost estimation is a process of gradual refinement
 Types of Estimates
• Top-down (macro) estimates
– E.g., Analogy, Group Consensus
• Bottom-up (micro) estimates
– E.g., Estimates of elements of the work breakdown structure
Conditions for Preferring Top-Down or Bottom-up Time and Cost
Estimates
Condition Macro Estimates Micro Estimates
Strategic decision making X
Cost and time important X
High uncertainty X
Internal, small project X
Fixed-price contract X
Customer wants details X
Unstable scope X
Problems in Estimation
▪ Complexity and Uniqueness of Software Development Project
▪ Imprecise estimation models and methods
▪ Ineffective management of requirements
▪ In-experienced project management
▪ Lack of application domain expertise
▪ Software processes and process maturity
▪ Lack of historical data
Size Estimation
▪ Metric used in estimating the size of software product are
▪ LOC, function points, …
▪ Notion of size changes in project from requirement analysis to
implementation and test
▪ at requirements time
▪ at design time
▪ at implementation/test time
▪ Size can be estimated
▪ Using an algorithmic approach
▪ Using old similar project’s size as a basis
▪ Using expert judgment
COCOMO Cost Modeling
COCOMO Cost Modeling
▪ An empirical model based on project experience.
▪ Well-documented, ‘independent’ model which is not tied to a
specific software vendor.
▪ Long history from initial version published in 1981 (COCOMO-
81) through various instantiations to COCOMO 2.
▪ COCOMO 2 takes into account different approaches to
software development, reuse, etc.
 COCOMO 2 Models
▪ COCOMO 2 incorporates a range of sub-models that produce
increasingly detailed software estimates.
▪ The sub-models in COCOMO 2 are:
▪ Application composition model. Used when software is composed from existing
parts.
▪ Early design model. Used when requirements are available but design has not
yet started.
▪ Reuse model. Used to compute the effort of integrating reusable components.
▪ Post-architecture model. Used once the system architecture has been designed
and more information about the system is available.
COCOMO Estimation Models
Questions/Discussion/Feedback