Chapter 5:

Software Planning and Risk Management

Software Engineering
Dr. Yahya Esmail Al-Ashmori
PH.D. Information Technology (IT)
Email: [email protected]
 Topics covered

• Software project management

• Plan-driven development

• Risk management

• Managing people

• Teamwork
2
 Software project management
• Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.

• Project management is needed because software

development is always subject to budget and
schedule constraints that are set by the
organisation developing the software. 3
 Success standards
• Deliver the software to the customer at the agreed
time.

• Keep overall costs within budget.

• Deliver software that meets the customer’s

expectations.

• Maintain a coherent and well-functioning

development team.

4
 Software management distinctions
• The product is intangible.
– Software cannot be seen or touched. Software project
managers cannot see progress by simply looking at the
artefact that is being constructed.
• Many software projects are 'one-off' projects.
– Large software projects are usually different in some
ways from previous projects. Even managers who have
lots of previous experience may find it difficult to
anticipate problems.
• Software processes are variable and organization
specific.
– We still cannot reliably predict when a particular software
process is likely to lead to development problems.
5
 Factors influencing project management
• Company size

• Software customers

• Software size

• Software type

• Organizational culture

• Software development processes

• These factors mean that project managers in different

organizations may work in quite different ways.
6
 Universal management activities
• Project planning
– Project managers are responsible for planning.
estimating and scheduling project development and
assigning people to tasks.
• Risk management
– Project managers assess the risks that may affect a
project, monitor these risks and take action when
problems arise.
• People management
– Project managers have to choose people for their team
and establish ways of working that leads to effective
team performance.

7
 Management activities
• Reporting
– Project managers are usually responsible for reporting
on the progress of a project to customers and to the
managers of the company developing the software.

• Proposal writing
– The first stage in a software project may involve writing a
proposal to win a contract to carry out an item of work.
The proposal describes the objectives of the project and
how it will be carried out.
8
 Plan-driven development
• Plan-driven or plan-based development is an approach to
software engineering where the development process is
planned in detail.

– Plan-driven development is based on engineering project

management techniques and is the ‘traditional’ way of
managing large software development projects.

• A project plan is created that records the work to be done,

who will do it, the development schedule and the work
products.
• Managers use the plan to support project decision making
and as a way of measuring progress. 9
 Plan-driven development
• The arguments in favor of a plan-driven approach are that
early planning allows organizational issues (availability of
staff, other projects, etc.) to be closely taken into account,
and that potential problems and dependencies are
discovered before the project starts, rather than once the
project is underway.

• The principal argument against plan-driven development is

that many early decisions have to be revised because of
changes to the environment in which the software is to be

developed and used.

10
 Project plans
• In a plan-driven development project, a project plan
sets out the resources available to the project, the
work breakdown and a schedule for carrying out
the work.
• Plan sections
– Introduction
– Project organization
– Risk analysis
– Hardware and software resource requirements
– Work breakdown
– Project schedule
– Monitoring and reporting mechanisms

11
 Project plan supplements
Plan Description
Configuration Describes the configuration management
management plan procedures and structures to be used.
Deployment plan Describes how the software and associated
hardware (if required) will be deployed in
the customer’s environment. This should
include a plan for migrating data from
existing systems.
Maintenance plan Predicts the maintenance requirements,
costs, and effort.
Quality plan Describes the quality procedures and
standards that will be used in a project.
Validation plan Describes the approach, resources, and
schedule used for system validation.
12
 The planning process
• Project planning is an iterative process that starts when
you create an initial project plan during the project
startup phase.

• Plan changes are inevitable.

– As more information about the system and the project
team becomes available during the project, you should
regularly revise the plan to reflect requirements, schedule
and risk changes.
– Changing business goals also leads to changes in project
plans. As business goals change, this could affect all
projects, which may then have to be re-planned.

13
The project planning process

14
Risk management
15
 Risk management
• Risk management is concerned with identifying risks
and drawing up plans to minimise their effect on a
project.
• Software risk management is important because of
the inherent uncertainties in software development.
– These uncertainties stem from loosely defined
requirements, requirements changes due to changes in
customer needs, difficulties in estimating the time and
resources required for software development, and
differences in individual skills.
• You have to anticipate(expect) risks, understand the
impact of these risks on the project, the product and
the business, and take steps to avoid these risks.
16
 Risk classification
• There are two dimensions of risk classification
– The type of risk (technical, organizational, ..)

– what is affected by the risk:

• 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.
17
 Examples of project, product, and business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project
before it is finished.
Management Project There will be a change of organizational
change management with different priorities.
Hardware Project Hardware that is essential for the project
unavailability will not be delivered on schedule.
Requirements Project and product There will be a larger number of changes to
change the requirements than anticipated.
Specification delays Project and product Specifications of essential interfaces are not
available on schedule.
Size underestimate Project and product The size of the system has been
underestimated.
CASE tool Product CASE tools, which support the project, do
underperformance not perform as anticipated.
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
– Identify project, product and business risks;

• Risk analysis
– Assess the likelihood and consequences of these risks;

• Risk planning
– Draw up plans to avoid or minimise the effects of the risk;

• Risk monitoring
– Monitor the risks throughout the project;

19
The risk management process

20
 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.
21
 Examples of different risk types
Risk type Possible risks
Estimation The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)
Organizational The organization is restructured so that different management are
responsible for the project. (6)
Organizational financial problems force reductions in the project
budget. (7)
People It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Requirements Changes to requirements that require major design rework are
proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Technology The database used in the system cannot process as many transactions
per second as expected. (1)
Reusable software components contain defects that mean they cannot
be reused as planned. (2)
Tools The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)
 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.

23
Figure 11-5. Sample Probability/Impact
Matrix

24
25
 Risk types and examples
Risk Probability Effects

Organizational financial problems force Low Catastrophic

reductions in the project budget (7).
It is impossible to recruit staff with the skills High Catastrophic
required for the project (3).
Key staff are ill at critical times in the project (4). Moderate Serious
Faults in reusable software components have to Moderate Serious
be repaired before these components are
reused. (2).
Changes to requirements that require major Moderate Serious
design rework are proposed (10).
The organization is restructured so that different High Serious
management are responsible for the project (6).
The database used in the system cannot Moderate Serious
process as many transactions per second as
expected (1).
 Risk types and examples
Risk Probability Effects

The time required to develop the High Serious

software is underestimated (12).
Software tools cannot be integrated (9). High Tolerable
Customers fail to understand the impact Moderate Tolerable
of requirements changes (11).
Required training for staff is not Moderate Tolerable
available (5).
The rate of defect repair is Moderate Tolerable
underestimated (13).
The size of the software is High Tolerable
underestimated (14).
Code generated by code generation Moderate Insignificant
tools is inefficient (8). 27
 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; 28
 What-if questions
• What if several engineers are ill at the same time?

• What if an economic downturn leads to budget cuts of

20% for the project?

• What if the performance of open-source software is

inadequate and the only expert on that open source
software leaves?

• What if the company that supplies and maintains

software components goes out of business?

• What if the customer fails to deliver the revised

requirements as predicted? 29
 Strategies to help manage risk
Risk Strategy
Organizational Prepare a briefing document for senior management
financial showing how the project is making a very important
problems contribution to the goals of the business and
presenting reasons why cuts to the project budget
would not be cost-effective.
Recruitment Alert customer to potential difficulties and the
problems possibility of delays; investigate buying-in
components.
Staff illness Reorganize team so that there is more overlap of work
and people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-
components in components of known reliability.
Requirements Derive traceability information to assess requirements
changes change impact; maximize information hiding in the
design.
30
 Strategies to help manage risk
Risk Strategy

Organizational Prepare a briefing document for senior

restructuring management showing how the project is
making a very important contribution to
the goals of the business.
Database Investigate the possibility of buying a
performance higher-performance database.

Underestimated Investigate buying-in components;

development time investigate use of a program generator.

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

32