SOFTWARE ENGINEERING

UNIT-5
RISK MANAGEMENT

1. a) Reactive Risk Strategies :

A ‘Reactive Risk Strategy’ is a response based approach, which is solely
dependent on past incident evaluation and audit based findings.

It begins once an ‘incident’ occurs, or once problems have been

detected following on from an audit.

Reactive Risk Management tries to reduce the damage of potential

threats and speedup an organization’s recovery from them.

b) Proactive Risk Strategy :

A ‘proactive Risk Strategy’ generally consists of focusing efforts on

mitigating the risk of pre-emptive threat occurrences.

This involves devising plans to protect critical assets via educating the
business about the who, what, where, why and how threats can be
potentially expose their valuable, sensitive assets.

Provide Risk Management identifies possible threats and aims to

prevent those events from ever happening in the first place.

“If you don’t attack the risks, they will attack you”

2. Software Risks :
A ‘Reactive Risk Strategy’ is a response based approach, which is solely

In general, the risk always involves two characteristics :

a) Uncertainty : the risk may or may not happen; that is there are no 100%
probable risks.

1
b) Loss : If the risk becomes a reality, unwanted consequences or losses
will occur.

a) Project Risks :

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,

resource, stakeholder and requirements problems and their impact
on a software project.

b) Technical Risks :
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.
c) Business Risks :
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 :
i) building an excellent product or system that no one really wants
ii) building a product that no longer fits into the overall business
strategy for the company.
iii) building a product that the sales force does not under stand
how to sell.
iv) losing the support of senior management due to a change in
focus or change in people.
v) losing budgetary or personnel commitment.
Predictable Risks : are extrapolated from past project experience.
Unpredictable Risks : risks are the joker in the deck. They can and
do occur, but they are extremely difficult to identify in advance.

2
3. a) Risk Identification :

Risk identification is a systematic attempt to specify threats to the

project plan.
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 different types of risks :
i) Generic Risks : are a potential threat to every software project.

ii) 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 software that is to be built.
Risk Item Checklist :
i) Product Size -
ii) Business Impact
iii) Customer Characteristics
iv) Process Definition
v) Development Environment
vi) Technology to be built
vii) Staff Size and Experience
b) Assessing Overall Project Risk
The following questions have been derived from risk data
obtained by surveying experienced software project managers.
i) Have top software and customer managers formally committed
to support the project.
ii) Are end-users enthusiastically committed to the project and the
system / product to be built.
iii) Are requirements fully understood by the software engineering
team and its customers.

3
 iv) Have customers been involved fully in the definition of
requirements.
v) Do end-users have realistic expectations.
vi) Is project scope stable.
vii) Does the software engineering tem have the right mix of skills.
viii) Are project requirements stable.
ix) Does the project team have experience with the technology to
be implemented.
x) Is the number of people on the project team adequate to do the
job.
xi) 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 the questions is answered negatively, mitigation,
monitoring, and management steps should be instituted without
fail.
c) Risk Components and Drivers :
The Risk components are :
i) Performance Risk : the degree of uncertainty that the product
will meet its requirements and be fit for its intended use.
ii) Cost Risk : the degree of uncertainty that the product budget
will be maintained.
iii) Support Risk : the degree of uncertainty that the resultant
software will be easy to correct, adapt and enhance.
iv) 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 Risk Driver on the risk component is divided into
one of four impact categories :
negligible marginal critical catastrophic

4
4. a) Risk Projection :

‘Risk Projection’ is also called ‘Risk Estimation’, attempts to rate each

risk in two ways :
a) The likelihood or probability that the risk is real

b) The consequences of the problems associated with the risk.

The Project planner, along with other managers and technical staff,
performs the following four risk projection steps :
a) Establish a scale that reflects the perceived likelihood of a risk.

b) Delineate the consequences of the risk.

c) Estimate the impact of the risk on the project and the product.

d) Note the overall accuracy of the risk projection so that there will be
no mis-understandings.
The intent of these steps is to consider risks in a manner that leads to
prioritization.
By prioritizing the risks, the team can allocate resources where they will
have the most impact.
b) Developing a Risk Table :
A risk table provides a project manager with a simple technique for ‘risk
projection’.
A project team begins by listing all risks in the first column of the table.
Each risk is categorized in the second column of the table.
The probability of occurrence of the risk is entered in the next column.
The probability value for each risk can be estimated by team members
individually.
Nest, the impact of each risk is assessed.
Each risk component is assessed using the characterization presented.
1. Catastrophic 2. Critical 3. Marginal 4. Negligible

5
Sample Risk Table prior to Sorting :

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 above line will be given further attention.
Risks that fall below the line are reevaluated to accomplish second-order
prioritization.
In the following figure, risk impact and probability have a distinct
influence on management concern :
All risks that lie above the cutoff line must be managed.
The column labeled RMMM contains a pointer to
- Risk Mitigation
- Monitoring
- Management Plan

6
Risk and Management Concern :

Risk probability can be determined by making individual estimates and

then developing a single consensus value.
c) Assessing Risk Impact :
Three factors affect the consequences that are likely if a risk does occur :
Its nature scope timing
The nature of the risk indicates the problems that are likely.
The following steps are to determine the overall consequences of a risk
a) Determine the average probability of occurrence value for each risk
component.

b) Determine the impact for each component based on the criteria.

c) Complete the risk table and analyze the result as described.

7
The overall ‘risk exposure’, RE, is determined using the following :
RE = P X C
Here, P : the probability of occurrence for a risk
C : the cost to the project should the risk occur
Risk Identification :
Only 70 % of the software components scheduled for reuse well, be
integrated into the application.
The remaining functionality will have to be custom developed.
Risk Probability :
80 % likely.
Risk Impact :
60 reusable software components were planned.
If only 70 % can be used, 18 components would have to be developed
from scratch.
The average component is 100 LOC.
Local data indicate that the software engineering cost for each LOC
is Rs. 14.
The overall cost to develop the components would be :
Risk Exposure : RE = 0.80 X 25,200 = 20,200
Risk exposure can be computed for each risk in the risk table, once the
estimate of the cost of the risk is made.
The total risk exposure for all risks can provide a means for adjusting the
final cost estimate for a project.
This can also be used to predict the probable increase in staff resources
required at various points during the project schedule.
Note : Compare RE for all risks to the cost estimation for the project.
If RE is greater than 50 % of the project cost, the viability of the
project must be reevaluated.

8
5. Risk Refinement :

‘Risk Refinement’ is a process of restating the risks as a set of more

detailed risks that will be easier to mitigate, monitor and manage.
Risk table can be refined in reviewing the risk impact based on the
following three areas :
- Nature : Likely problems if risk occurs
- Scope : Just how serious is it
- Timing : When and how long.
To achieve this, represent the risk in :
Condition-Transition-Consequence (CTC).
i.e., the risk is stated in the following form :
“Given that <condition> then there is concern that
possibly <consequence>”
This format is good is a good representation for the detailed risk.

The general condition can be refined in the following manner :

a) Subcondition-1 : Certain reusable components were developed by a
third party with no knowledge of internal design standards.

b) Subcondition-2 :The design standard for component interfaces has

not been solidified and may not conform to certain existing reusable
components.

c) Subcondition-3 : Certain reusable components have been impleme-

nted in a language that is not supported on the target environment.
The consequences associated with these refined sub-conditions remain
the same, but the refinement helps to isolate the underlying risks and
might lead to easier analysis and response.
When one is applying ‘risk refinement process’, it may be possible to
refine the risk into a set of more detailed risks, each somewhat easier to
mitigate, monitor and manage.

9
6. Risk Mitigation, Monitoring and Management :
The goal of all of the risk analysis activities is ‘To assist the project team
in developing a strategy for dealing with risk’.
An effective strategy must consider the following three issues :
a) Risk Avoidance
b) Risk Monitoring
c) Risk Management and Contingency Planning
To mitigate the risk, project management must develop a strategy for
reducing turnover.
Among the possible steps to be taken are :
a) Meet with current staff to determine causes for turnover.

b) Mitigate those causes that are under control before the project
starts.

c) Once the project commences, assume turnover will occur and

develop techniques to ensure continuity when people leave.

d) Organize project teams so that information about each development

activity is widely dispersed.

e) Define documentation standards and establish mechanisms to ensure

that documents are developed in a timely manner.

f) Conduct peer reviews of all work.

g) Assign a backup staff member for every critical technologist.

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 addition to monitoring these factors, a project manager should
monitor the effectiveness of risk mitigation steps.
It is important to note that ‘Risk Mitigation, Monitoring and
Management’ (RMMM) steps incur additional cost.

10
 ‘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.

7. The RMMM Plan :

A ‘risk management strategy’ can be included in the software project
plan and the risk management steps can be organized into a separate
‘Risk Mitigation, Monitoring and Management Plan’.
The RMMM Plan documents all work performed as part of risk analysis
and is used by the project manager as part of the overall project plan.
Each risk is documented individually using a ‘Risk Information Sheet’.
Risk Information Sheet :

11
In most cases, RIS is maintained using DBMS system, so that creation
and information entry, priority ordering, searches and other analysis
may be accomplished easily.
Once the RMMM has been documented and the project has begun, then
the risk mitigation and monitoring steps commence.
‘Risk Mitigation’ is a problem avoidance activity.
‘Risk Monitoring’ is a project tracking activity with three primary
objectives :
a) To assess whether predicted risks do, in fact, occur.

b) To ensure that aversion steps defined for the risk are being
properly applied.

c) To collect information that can be used for future risk analysis.

8. Risk Management Tool (software) :

Objective : The objective of risk management tools is
“to assist a project team in defining risks, assessing their impact and
probability, and tracking risks throughout a software project”.
Mechanics : In general, risk management tools assist in
generic risk identification by providing a list of typical project and
business risks
providing checklists or other ‘interview’ techniques that assist in
identifying project specific risks,
assigning probability and impact to each risk,
supporting risk mitigation strategies, and
generating many different risk-related reports.
Risk Representative Tool :
‘Riskman’ developed at Arizona State University.
[www.eas.asu.edu/~sdm/Merrill/riskman.html]
Is a risk evaluation expert system that identifies project-related risks.

12
9. Quality Management :
The problem of quality management is not what people do not know
about it. The problem is what they think they do know.
Quality Management encompasses :
a) Software Quality Assurance process. (SQA)
b) Specific Quality Assurance and quality control tasks.
c) Effective software engineering practice. (methods and tools)
d) Control of all software work products and the changes made to them.
e) A procedure to ensure compliance with software development
standards.
f) Measurement and reporting mechanisms.

10. Quality Concepts :

A manufacturer wants to minimize the variation among the products
that are produced, even when doing something relatively simple. This is
called ‘Variation Control’.
“Controlling variation is the key to a high quality product.”
Quality : “A characteristic or attribute of something”.
As an attribute of an item, quality refers to measurable characteristics.
Ex : length, color, temperature,…
‘Quality of Design’ refers to the characteristics that designers specify for
an item.
‘Quality of Conformance’ is the degree to which the design
specifications are followed during manufacturing.
“People forget how fast you did a job –
but they always remember how well you did it”
User satisfaction = compliant product
+ good quality
+ delivery within budget and schedule

13
Quality Control :
‘Variation Control’ is may be equated with quality control.
A key concept of ‘quality control’ is that
- all work products have defined

- measurable specifications to which one may compare

the output of each process.
Quality Assurance :
consists of a set of auditing and reporting functions that assess the
effectiveness and completeness of quality control activities.
The goal of ‘quality assurance’ is
to provide management with the data necessary to be informed
about product quality, - thereby gaining insight and confidence
that product quality is meeting its goals.

Cost of Quality :
The ‘cost of quality’ includes all costs incurred in the pursuit of quality or
in performing quality-related activities.
Cost of quality studies are conducted
- provide a base line for the current cost of quality
- identify opportunities for reducing the cost of quality
- provide a normalized basis of comparison.

Quality costs may be divide as follows :

a) Prevention Costs : include quality planning formal technical reviews,
test equipment and training.
b) Appraisal Costs : include activities to gain insight into product condi-
tion the ‘first time through’ each process.
c) Failure Costs : are those that would disappear if no defects appeared
before shipping a product to customers.

14
 Failure costs are subdivided into the following :
i) Internal Failure Costs : are incurred when we detect a defect in
our product prior to shipment.
Internal Failure costs include rework, repair, and failures.
ii) External Failure Costs : are associated with defects found after
the product has been shipped to the customer.
External Failure costs include complaint resolution, product
return, replacement and warranty work.
“It takes less time to do a thing right than to explain why you did
It wrong”
11. Software Quality Assurance (SQA) :
Software Quality : is defined as
“Conformance to
- explicitly stated functional and performance requirements
- explicitly documented development
- implicit characteristics that are expected of all professionally
developed software.”
Software Quality Assurance :
“Planned and systematic pattern of actions”
that are required to ensure high quality in software.
‘Software Quality Assurance is composed of a variety of tasks
associated with two different constituencies :
- The software engineers who do technical work
- SQA group that has responsibility for quality assurance planning,
oversight, record keeping, analysis and reporting.
SQA group includes software engineers, project managers, customers,
sales people, and the individuals, if any.
The goal of SQA is to remove quality problems in the software.

15
 SQA Activities :
a) Prepares an SQA plan for a project.

b) Participates in the development of the project’s software process

description.

c) Reviews software engineering activities to verify compliance with the

defined software process.

d) Audits designated software work products to verify compliance with

those defined as part of the software process.

e) Ensures that deviations in software work and work products are

documented and handled.

f) Records any noncompliance and reports to senior management.

12. Software Reviews :

Technical work needs reviewing for the same reason that pencils needs
erasers.
Formal Technical Review (walkthrough / inspection) :
“A FTR is the most effective filter from a quality assurance standpoint. “
The FTR is an effective means for uncovering errors and improving
software quality.
The primary objective of FTR is to find errors during the process so that
they do not become defects after release of the software.
Cost Impact of Software Defects :
The cost impact of early detection requires a series of relative costs that
are based on actual cost data collected for large software projects.
Assume that an error uncovered during design will cost 1 rupee to
correct.
Relative to this cost, the same error uncovered just before testing
commences will cost 6.5 rupees.
And after release, between 60 and 100 rupees.

16
13. Defect Amplification and Removal :
This model can be used to illustrate the generation and detection of
errors during the preliminary design, detail design and coding steps of a
software engineering process.
Defect Amplification Model :

Here, the box represents a software development step.

During the step, errors may be inadvertently generated.
Review may fail to uncover newly generated errors and errors from
previous steps, resulting in some number of errors that are passed
through.
In some cases, errors passed through from previous steps are amplified.
The box subdivisions represent each of these characteristics and the
percent of efficiency for detecting errors, a function of the thoroughness
of the review.
Defect Amplification with / without reviews :
The following figure illustrates a hypothetical example of defect
amplification for a software process in which no reviews are conducted.
Referring to the figure, each test step is assumed to uncover and correct
50 % of all incoming errors without introducing any new errors.
10 preliminary design defects are amplified to 94 errors before testing.
Twelve (12) latent defects are released to the field.

17
Defect Amplification – No Reviews :

In the following figure, the same conditions except that design and code
reviews are conducted as part of the each development step.
In this case, 10 initial preliminary design errors are amplified to 24 errors
before testing. And only three latest defects exist.
Defect Amplification – Reviews Conducted :

18
14. Formal Technical Reviews :
A ‘formal technical review’ is a software quality control activity
performed by software engineers.
The objectives of FTR are :
a) To uncover errors in function, logic, or implementation for any
representation of the software.

b) To verify that the software under review meets its requirements.

c) To ensure that the software has been represented according to

predefined standards.

d) To achieve software that is developed in a uniform manner.

e) To make projects more manageable.

The Review Meeting :

Every review meeting should abide by following constraints :
a) Between three and five people should be involved in the review.

b) Advance perception should occur but should require no more than

two hours of work for each person.

c) The duration of review meeting should be less than two hours

The focus of the FTR is on a work product.

The individual who has developed the work product – the producer –
informs the project leader that the work product is complete and that a
review is required.
The project leader contacts a review leader, who evaluates the product
for readiness, generates copies of product materials and distributes
them to two or three reviewers for advance preparation.
The review meeting is attended by the review leader, all reviewers and
the producer. One of the reviewers takes on the role of the ‘recorder’,
that is the individual who records all important issues during review.

19
Review Reporting and Record Keeping :
During the FTR, a reviewer (the recorder) actively records all issues that
have been raised.
These are summarized at the end of the review.
The summary report of FTR answers the following three questions :
a) What was reviewed.

b) Who reviewed it.

c) What were the findings and conclusions.

The review issues list serves two purposes :

a) To identify problem areas within the product.

b) To serve as an action item checklist that guides the producer as

corrections are made.
Review Guidelines :
Minimum set of guidelines for FTR :
a) Review the product, not the producer.

b) Set an agenda and maintain it.

c) Limit debate and the rebuttal.

d) Enunciate problem areas.

e) Take written notes.

f) Limit the number of participants and insist upon advance

preparation.

g) Develop a check list for each product that is likely to be reviewed.

h) Allocate resources and schedule time for FTRs.

i) Conduct meaningful training for all reviewers.

j) Review your early reviews.

20
Sample-Driven Reviews :
In an ideal setting, every software engineering work product would
undergo a FTR.
In the real world of software projects, resources are limited and time is
short.
As a consequence, reviews are often skipped, even though their value as
a quality control mechanism is recognized.
Inspections (FTRs) are only viewed efficient, if many faults are found
during the fault searching part.
To be effective, the ‘sample driven review’ process must attempt to
quantify those work products that are primary targets for FTR.
To accomplish this, the following steps are suggested :
a) Inspect a fraction Pi of each software work product, i.
Record the number of faults, Fi found within Pi.

b) Develop a gross estimate of number of faults within work product i,

by multiplying Fi by 1/Pi.

c) Sort the work products in descending order according to the gross

estimate of the number of faults in each.

d) Focus available review resources on those work products that have

the highest estimated number of faults.

The fraction of the work product that is sampled must :

a) Be representative of the work product as a whole

b) Large enough to be meaningful to the reviewers who does the

sampling.
A software engineering team must establish the best value for Pi for the
types of work products produced.
“It is one of the most beautiful compensations of life, that no man can
sincerely try to help another without helping himself”.

21
15. Software Reliability :
‘Software Reliability’ is “the probability of failure-free operation of a
computer program in a specified environment for a specified time”.
“The unavoidable price of reliability is simplicity”
Failure : ‘Failure’ is nonconformance to software requirements.

Measures of Reliability and Availability :

A simple measure of reliability is ‘Mean-Time-Between-Failure” (MTTF).
Here,
MTBF = MTTF + MTTR ……………(1)
MTTF : Mean-Time-To-Failure
MTTR : Mean-Time-To-Repair
Software Availability : is the probability that a program is operating
according to requirements at a given point in time and is defined as :
Availability = [ MTTF / (MTTF + MTTR) ] X 100 % ………(2)

Software Safety : is a software quality assurance activity that focuses 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 process, ‘software
design’ features can be specified that will either eliminate or control
potential hazards.
A modeling and analysis process is conducted as part of software safety.
Some of the hazards associated with a computer-based cruise control for
an automobile might be :
a) Causes uncontrolled acceleration that cannot be stopped.

b) Does not respond to depression of brake pedal.

c) Doe not engage when switch is activated.

d) Slowly loses or gains speed.

22
16. The ISO 9000 Quality Standards :

A Quality Assurance System may be defined as the organizational

structure, responsibilities, processes, and resource for implementing
quality management.

To become registered to one of the quality assurance system models

contained in ‘ISO 9000’, a company’s quality system and operations
are scrutinized by third-party auditors for compliance to the standard
and for effective operation.

ISO 9001:2000 is the quality assurance standard that applies to

software engineering.

The standard contains 20 requirements that must be present for an

effective quality assurance System.

The requirements delineated by ISO 9001:2000 address topics :

- management responsibility
- quality system
- contract review
- design control
- document and data control
- product identification and traceability
- process control
- inspection and testing
- corrective and preventive action
- control of quality records
- internal quality audits
- training
- servicing
- statistical techniques

For a software organization to become registered to ISO 9001:2000,

it must establish policies and procedures to address each of the
requirements just noted and then be able to demonstrate that these
policies and procedures are being followed.

23
The ISO 9001:2000 Standard :
Establish the elements of a quality management system.
Develop, implement, and improve the system.
Define a policy that emphasizes the importance of the system.
Document the Quality System
Describe the process
Produce an operational manual
Develop methods for controlling (updating) documents
Establish methods for record keeping
Support Quality Control and Assurance
Promote the importance of quality among all stakeholders
Focus on customer satisfaction
Define a quality plan that addresses objectives, responsibilities,
and authority
Define communication mechanisms among stakeholders
Establish Review Mechanisms for the Quality Management System
Identify review methods and feedback mechanisms
Define follow-up procedures
Identify Quality Resources including Personal, Training, Infrastructure
Elements
Establish Control Mechanisms
For planning
For customer requirements
For technical activities (eg. analysis, design, testing)
For project monitoring and management
Define Methods for Remediation
Access quality data and metrics
Define approach for continuous process and quality improvement

* * * * *

24