[VIVA COLLEGE]

CASE STUDY
ON

Risk Analysis and

Management

BY NISHANT NAIR

[2009]

[ SY.BSc IT ]
 VIVA
Vishnu Waman Thakur Charitable Trust’s
College Of Arts, Commerce and Science

CERTIFICATE
FOR CASE STUDY
This is to Certify That NISHANT NAIR OF
S.Y.Bsc. (IT) Class Has Satisfactory completed the
case study on Risk Analysis and Management for
the year 2008-09

Professor-in-Charge Head of the

Dept

Page 2 of 26
Date: College
Stamp

Page 3 of 26
 Overview

First, risk concerns future happenings. Today and yesterday

are beyond active concern, as we are already reaping what was
previously sowed by our past actions. The question is, can we,
therefore, by changing our actions today, create an opportunity for a
different and hopefully better situation for ourselves tomorrow. This
means, second, that risk involves change, such as in changes of
mind, opinion, actions, or places . . . [Third,] risk involves choice,
and the uncertainty that choice itself entails. Thus paradoxically,
risk, like death and taxes, is one of the few certainties of life.
When risk is considered in the context of software
engineering, Charette's three conceptual underpinnings are always in
evidence. The future is our concern— what risks might cause the
software project to go awry? Change is our concern how will
changes in customer requirements, development technologies, target
computers, and all other entities connected to the project affect
timeliness and overall success? Last, we must grapple with choices
—what methods and tools should we use, how many people should
be involved, how much emphasis on quality is "enough"?

Page 4 of 26
 Some general questions in our mind

What is it?
Risk analysis and management are a series of steps that help a
software team to understand and manage uncertainty. Many
problems can plague a software project. A risk is a potential
problem—it might happen, it might not. But, regardless of the
outcome, it’s a really good idea to identify it, assess its probability
of occurrence, estimate its impact, and establish a contingency plan
should the problem actually occur.

Who does it?

Everyone involved in the software process—managers, software
engineers, and customers participate in risk analysis and
management.

Why is it important?
Think about the Boy Scout motto: “Be prepared.” Software is a
difficult undertaking Lots of things can go wrong, and frankly, many
often do. It’s for this reason that being prepared understanding the
risks and taking proactive measures to avoid or manage them is a
key element of good software project management.

Page 5 of 26
 SOFTWARE RISKS

There is general agreement that risk always involves two

characteristics:

Uncertainty — the risk may or may not happen; that is, there are no
100% probable risks.
Loss — if the risk becomes a reality, unwanted consequences or
losses will occur.
When risks are analyzed, it is important to quantify the level of
uncertainty and the degree of loss associated with each risk. To
accomplish this, different categories of risks are considered.
Project risks threaten the project plan. That is, if project risks
become real, it is likely that project schedule will slip and that costs
will increase. Project risks identify potential budgetary, schedule,
personnel (staffing and organization), resource, customer, and
requirements problems and their impact on a software project.
Technical risks threaten the quality and timeliness of the software
to be produced. If a technical risk becomes a reality, implementation
may become difficult or impossible. Technical risks identify
potential design, implementation, interface, verification, and
maintenance problems. In addition, specification ambiguity,
technical uncertainty, technical obsolescence, and "leading-edge"
technology are also risk factors. Technical risks occur because the
problem is harder to solve than we thought it would be.

Page 6 of 26
 Business risks threaten the viability of the software to be built.
Business risks often jeopardize the project or the product.
Candidates for the top five business risks are:
 Building a excellent product or system that no one really
wants (market risk).
 Building a product that no longer fits into the overall
business strategy for the company (strategic risk).
 Building a product that the sales force doesn't
understand how to sell.
 Losing the support of senior management due to a
change in focus or change in people (management risk).
 Losing budgetary or personnel commitment (budget
risks).

Known risks are those that can be uncovered after careful

evaluation of the project plan, the business and technical
environment in which the project is being developed, and other
reliable information sources (e.g., unrealistic delivery date, lack of
documented requirements or software scope, poor development
environment).
Predictable risks are extrapolated from past project experience
(e.g., staff turnover, poor communication with the customer, dilution
of staff effort as ongoing maintenance requests are serviced).
Unpredictable risks are the joker in the deck. They can and do
occur, but they are extremely difficult to identify in advance.

Page 7 of 26
 RISK IDENTIFICATION
Risk identification is a systematic attempt to specify threats to
the project plan (estimates, schedule, resource loading, etc.). By
identifying known and predictable risks, the project manager takes a
first step toward avoiding them when possible and controlling them
when necessary.
There are two distinct types of risks for each of the categories
that are generic risks and product-specific risks. Generic risks are a
potential threat to every software project. Product-specific risks can
be identified only by those with a clear understanding of the
technology, the people, and the environment that is specific to the
project at hand. To identify product-specific risks, the project plan
and the software statement of scope are examined and an answer to
the following question is developed: "What special characteristics of
this product may threaten our project plan?"
One method for identifying risks is to create a risk item
checklist. The checklist can be used for risk identification and
focuses on some subset of known and predictable risks in the
following generic subcategories:

 Product size—risks associated with the overall size of the

software to be built or modified.

Page 8 of 26
  Business impact—risks associated with constraints imposed by
management or the marketplace.

 Customer characteristics—risks associated with the

sophistication of the customer and the developer's ability to
communicate with the customer in a timely manner.

 Process definition—risks associated with the degree to which

the software process has been defined and is followed by the
development organization.

 Development environment—risks associated with the

availability and quality of the tools to be used to build the
product.

 Technology to be built—risks associated with the complexity

of the system to be built and the "newness" of the technology
that is packaged by the system.

 Staff size and experience—risks associated with the overall

technical and project experience of the software engineers who
will do the work.

A relatively short list of questions [KEI98] can be used to provide

a preliminary indication of whether a project is “at risk.”

 Assessing Overall Project Risk

Page 9 of 26
 The following questions have derived from risk data obtained by
surveying experienced software project managers in different part of
the world. The questions are ordered by their relative importance to
the success of a project.
 Have top software and customer managers formally
committed to support the project?

 Are end-users enthusiastically committed to the project and the

system/product to be built?

 Are requirements fully understood by the software engineering

team and their customers?

 Have customers been involved fully in the definition of

requirements?

 Do end-users have realistic expectations?

 Is project scope stable?

 Does the software engineering team have the right mix of

skills?

 Are project requirements stable?

 Does the project team have experience with the technology to

be implemented?
Page 10 of 26
  Is the number of people on the project team adequate to do the
job?

 Do all customer/user constituencies agree on the importance of

the project and on the requirements for the system/product to
be built?

If any one of these questions is answered negatively, mitigation,

monitoring, and management steps should be instituted without fail.
The degree to which the project is at risk is directly proportional to
the number of negative responses to these questions.

 Risk Components and Drivers

The U.S. Air Force has written a pamphlet that contains excellent
guidelines for software risk identification and abatement. The Air
Force approach requires that the project manager identify the risk
drivers that affect software risk components performance, cost,
support, and schedule. In the context of this discussion, the risk
components are defined in the following manner:

 Performance risk—the degree of uncertainty that the product

will meet its requirements and be fit for its intended use.

Page 11 of 26
  Cost risk—the degree of uncertainty that the project budget
will be maintained.

 Support risk—the degree of uncertainty that the resultant

software will be easy to correct, adapt, and enhance.

 Schedule risk—the degree of uncertainty that the project

schedule will be maintained and that the product will be
delivered on time.

The impact of each risk driver on the risk component is divided

into one of four impact categories—negligible, marginal, critical, or
catastrophic. Referring to Figure
Note:
 The potential consequence of undetected software errors
or faults.
 The potential consequence if the desired outcome is not
achieved.

Fig: Impact assessment

Page 12 of 26
Page 13 of 26
 RISK PROJECTION

Risk projection, also called risk estimation, attempts to rate each

risk in two ways—the likelihood or probability that the risk is real
and the consequences of the problems associated with the risk,
should it occur. The project planner, along with other managers and
technical staff, performs four risk projection activities:

 establish a scale that reflects the perceived likelihood of a risk,

 delineate the consequences of the risk

 estimate the impact of the risk on the project and the product,
and

 note the overall accuracy of the risk projection so that there

will be no misunderstandings

Page 14 of 26
 Developing a Risk Table

A risk table provides a project manager with a simple technique for

risk projection. A sample risk table is illustrated in Figure

Sample risk table prior to sorting

Page 15 of 26
 A project team begins by listing all risks (no matter how
remote) in the first column of the table. This can be accomplished
with the help of the risk item checklists referenced in Section Risk
identification. Each risk is categorized in the second column
(e.g., PS implies a project size risk, BU implies a business risk). The
probability of occurrence of each risk is entered in the next column
of the table. The probability value for each risk can be estimated by
team members individually. Individual team members are polled in
round-robin fashion until their assessment of risk probability begins
to converge.
Page 16 of 26
 Next, the impact of each risk is assessed. Each risk component
is assessed using the characterization presented in Figure Impact
assessment, and an impact category is determined. The
categories for each of the four risk components performance,
support, cost, and schedule are averaged3 to determine an overall
impact value.
Once the first four columns of the risk table have been
completed, the table is sorted by probability and by impact. High-
probability, high-impact risks percolate to the top of the table, and
low-probability risks drop to the bottom. This accomplishes first-
order risk prioritization.
The project manager studies the resultant sorted table and
defines a cutoff line. The cutoff line (drawn horizontally at some
point in the table) implies that only risks that lie above the line will
be given further attention. Risks that fall below the line are re-
evaluated to accomplish second-order prioritization. Referring to
Figure above, risk impact and probability have a distinct influence
on management concern. A risk fac tor that has a high impact but a
very low probability of occurrence should not absorb a significant
amount of management time. However, high-impact risks with
moderate to high probability and low-impact risks with high
probability should be carried forward into the risk analysis steps that
follow.
All risks that lie above the cutoff line must be managed. The
column labeled RMMM contains a pointer into a Risk Mitigation,
Monitoring and Management Plan or alternatively, a collection of
risk information sheets developed for all risks that lie above the
cutoff. The RMMM plan and risk information sheets are discussed
in Risk Refinement and Risk Mitigation.
Risk probability can be determined by making individual
estimates and then developing a single consensus value. Although
that approach is workable, more sophisticated techniques for
determining risk probability have been developed. Risk drivers can
Page 17 of 26
be assessed on a qualitative probability scale that has the following
values: impossible, improbable, probable, and frequent.
Mathematical probability can then be associated with each
qualitative value (e.g., a probability of 0.7 to 1.0 implies a highly
probable risk).

RISK REFINEMENT

During early stages of project planning, a risk may be stated

quite generally. As time passes and more is learned about the project
and the risk, it may be possible to refine the risk into a set of more
detailed risks, each somewhat easier to mitigate, monitor, and
manage.
One way to do this is to represent the risk in condition-
transition-consequence (CTC) format. That is, the risk is stated in
the following form:
Given that <condition> then there is concern that (possibly)
<consequence>.

Using the CTC format for the reuse risk noted in Section 6.4.2, we
can write:

Page 18 of 26
 Given that all reusable software components must conform to
specific design standards and that some do not conform, then there
is concern that (possibly) only 70 percent of the planned reusable
modules may actually be integrated into the as-built system,
resulting in the need to custom engineer the remaining 30 percent of
components.

This general condition can be refined in the following manner:

Subcondition 1. Certain reusable components were developed by a

third party with no knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces has
not been solidified and may not conform to certain existing reusable
components.
Subcondition 3. Certain reusable components have been
implemented in a language that is not supported on the target
environment.
The consequences associated with these refined subconditions
remains the same (i.e., 30 percent of software components must be
customer engineered), but the refinement helps to isolate the
underlying risks and might lead to easier analysis and response.

Page 19 of 26
RISK MITIGATION, MONITORING
AND MANAGEMENT

All of the risk analysis activities presented to this point have a single
goal—to assist the project team in developing a strategy for dealing
with risk. 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. For example, assume that high
staff turnover is noted as a project risk, r1. Based on past history and
Page 20 of 26
management intuition, the likelihood, l1, of high turnover is
estimated to be 0.70 (70 percent, rather high) and the impact, x1, is
projected at level 2. That is, high turnover will have a critical impact
on project cost and schedule.
To mitigate this risk, project 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, 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.

Page 21 of 26
As the project proceeds, risk monitoring activities commence. The
project manager monitors factors that may provide an indication of
whether the risk is becoming more or less likely. In the case of high
staff turnover, the following factors can be monitored:

 General attitude of team members based on project pressures.

 The degree to which the team has jelled.

 Interpersonal relationships among team members.

 Potential problems with compensation and benefits.

 The availability of jobs within the company and outside it.

In addition to monitoring these factors, the project manager should
monitor the effectiveness of risk mitigation steps. For example, a
risk mitigation step noted here called for the definition of
documentation standards and mechanisms to be sure that documents
are developed in a timely manner. This is one mechanism for
ensuring continuity, should a critical individual leave the project.
The project manager should monitor documents carefully to ensure
that each can stand on its own and that each imparts information that
would be necessary if a newcomer were forced to join the software
team somewhere in the middle of the project.

Risk management and contingency planning assumes that

mitigation efforts have failed and that the risk has become a reality.
Continuing the example, the project is well underway and a number
of people announce that they will be leaving. If the mitigation
strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team. In
Page 22 of 26
addition, the project manager may temporarily refocus resources
(and readjust the project schedule) to those functions that are fully
staffed, enabling newcomers who must be added to the team to “get
up to speed.” Those individuals who are leaving are asked to stop all
work and spend their last weeks in “knowledge transfer mode.” This
might include video-based knowledge capture, the development of
“commentary documents,” and/or meeting with other team members
who will remain on the project.

SAFETY RISKS AND HAZARDS

Risk is not limited to the software project itself. Risks can

occur after the software has been successfully developed and
delivered to the customer. These risks are typically associated with
the consequences of software failure in the field.
In the early days of computing, there was reluctance to use
computers (and software) to control safety critical processes such as
nuclear reactors, aircraft flight control, weapons systems, and large-
scale industrial processes. Although the probability of failure of a
well-engineered system was small, an undetected fault in a computer
based control or monitoring system could result in enormous
Page 23 of 26
economic amage or, worse, significant human injury or loss of life.
But the cost and functional benefits of computer-based control and
monitoring far outweigh the risk. Today, computer hardware and
software are used regularly to control safety critical systems.
When software is used as part of a control system, complexity
can increase by an order of magnitude or more. Subtle design faults
induced by human error something that can be uncovered and
eliminated in hardware-based conventional control becomes much
more difficult to uncover when software is used.
Software safety and hazard analysis are software quality
assurance activities that focus on the identification and assessment
of potential hazards that may affect software negatively and cause
an entire system to fail. If hazards can be identified early in the
software engineering process, software design features can be
specified that will either eliminate or control potential hazards.

SUMMARY

Whenever a lot is riding on a software project, common sense

dictates risk analysis. And yet, most software project managers do it
informally and superficially, if they do it at all. The time spent
identifying, analyzing, and managing risk pays itself back in many
ways: less upheaval during the project, a greater ability to track and
control a project, and the confidence that comes with planning for
problems before they occur.

Page 24 of 26
Risk Information sheet

Page 25 of 26
REFERENCES:-

1. Software Engineering
-by R. Pressman

2.http://www.mhhe.com/engcs/compsci/pressman/resources/ris
k.mhtml

Page 26 of 26