UNIT-5

RISK MANAGEMENT
Risk management: Reactive vs. Proactive
Risk strategies, software risks, Risk
identification,Risk projection, Risk
refinement.
Quality Management: Quality concepts,
Software qualityassurance, Software
Reviews, Formal Technical reviews,
Statistical Software quality Assurance,
Software Reliability.(Text Book1)
Risk management:
 Introduction to risk management
 Reactive vs. proactive risk strategies
 Software risk
 Risk identification
 Risk projection
 Risk refinement
 RMMM
 RMMM plan
Introduction to risk
management
 Risk is an undesired event or circumstance
that occur while a project is underway
 It is necessary for the project manager to
anticipate and identify different risks that a
project may be susceptible to.
 Risk Management : It aims at reducing
the impact of all kinds of risk that may
affect a project by identifying, analyzing
and managing them
 Reactive vs. Proactive Risk
Strategies
 Reactive risk strategies
 "Don't worry, I'll think of something"
 The majority of software teams and
managers rely on this approach
 Nothing is done about risks until something
goes wrong
The team then flies into action in an attempt
to correct the problem rapidly (fire fighting)
 Proactive risk strategies

 Steps for risk management are followed

 Primary objective is to avoid risk and to have
a contingency plan in place to handle
unavoidable risks in a controlled and
effective manner
SOFTWARE RISK
It involve 2 characteristics
 Uncertainty : Risk may or may
not happen
 Loss : If risk becomes a reality,

unwanted loss or
consequences will occur
 Categories of risks

 Project risk: Threaten the project plan and

affect schedule and resultant cost
 Technical risk: Threaten the quality and
timeliness of software to be produced
 Business risk: Threaten the viability of
software to be built
 Known risk: These risks can be recovered from
careful evaluation
 Predictable risk: Risks are identified by past
project experience
 Unpredictable risk: Risks that occur and may
RISK IDENTIFICATION
It concerned with identification of risk
 Step1: Identify all possible risks

 Step2: Create item check list

 Step3: Categorize into risk components-Performance

risk, cost risk, support risk and schedule risk

 Step4: Divide the risk into one of 4 categories

1.Negligible-0
2.Marginal-1
3.Critical-2
4.Catastrophic-3
Risk Identification includes
 Product size-risks associated with the overall size of the

software
 Business impact-constraints imposed by management

/market
 Development environment-availability and quality of tools

 Process definition-degree to which the process has been

defined and followed.

 Customer characteristics-customer awareness and smooth

communication
 Technology to be built-complexity of the system to be built

 Staff size and experience-technical and project experience

of the staff
RISK PROJECTION
 Also called risk estimation
 It estimates the impact of risk on the

project and the product

 Estimation is done by using Risk Table

 Risk projection addresses risk in 2 ways

 Likelihood or probability that the risk is

real
 Consequences of the problems

associated with the risk

Steps in risk projection are

 Estimate the scale that is likelihood of

risk
 Delineate the consequence of risk

 Estimate the impact on project and

product
 Note overall accuracy of the risk
projection
 Preparing a risk table
Risk Category Probability Impact RMMM
Size PS 60% 2
estimate
may be
significantly
low
Larger no. of PS 30% 3
users than
planned
Less reuse PS 70% 2
than
planned
End user BU 40% 3
resist
system

PS-PRODUCT SIZE,BU-BUSINESS RISK

The impact of each risk is assessed by Impact
values
 Catastrophic-1
 Critical-2
 Marginal-3
 Negligible-4
RISK REFINEMENT
 Also called Risk assessment
 Refines the risk table in reviewing the risk impact
based on the following three factors
 Nature: Likely problems if risk occurs
 Scope: Just how serious is it?
 Timing: When and how long
 Calculate Risk exposure RE=P*C
Where P is probability and C is cost of project if risk
occurs
Risk Mitigation Monitoring
And Management (RMMM)
 Its goal is to assist project team in developing a
strategy for dealing with risk
 There are three issues of RMMM
 1)Risk Avoidance
 2)Risk Monitoring and
 3)Risk Management
 Risk Mitigation
 Proactive planning for risk avoidance
 Risk Monitoring
 Assessing whether predicted risk occur or not
 Ensuring risk aversion steps are being properly
applied
 Collection of information for future risk analysis
 Determine which risks caused which problems

Risk Management
 Contingency planning(for future risks)

 Actions to be taken in the event that mitigation steps

have failed and the risk has become a live problem

 Devise RMMP(Risk Mitigation Monitoring And

Management Plan)
Quality Management:
 Quality concepts
 Software quality assurance
 Software Reviews
 Formal technical reviews
 Statistical Software quality Assurance
 Software reliability
 The ISO 9000quality standards
1. QUALITY CONCEPTS
 Variation control is the heart of quality control
 FROM one project to another, we want to minimize

the difference between the predicted resources

needed to complete a project and the actual
resources used, including staff, equipment, and
calendar time
When we examine an item based on its measurable
characteristics, two kinds of quality may be
encountered:
1.Quality of design –Requirements,specifiation,design
of system
2.Quality of conformance-implementation
User satisfaction = compliant
product + good quality +
delivery within budget and
schedule .
Quality control
 Series of inspections, reviews, and
tests used to ensure conformance of a
work product to its specifications
Quality assurance
 Consists of a set of auditing and reporting
functions that assess the effectiveness and
completeness of quality control activities
 Cost of Quality-all costs incurred in performing
quality related activities.
 Quality costs may be
 1.prevention-cost -for FTRs,quality
planning,test eqipment etc
 2.appraisal(assessment costs)

 3.Failure costs-(reworks,repair costs)

Appraisal costs(assessing something)
 In-process and inter-process inspection, equipment
calibration and maintenance, testing

Failure costs
 rework, repair, failure mode analysis
External failure costs-defects found after the product is
delivered
 Complaint resolution, product return and
replacement, help line support, warranty work
 
SOFTWARE QUALITY
ASSURANCE
 Software quality assurance (SQA) is the concern of
every software engineer to reduce cost and
improve Product time-to-market.
 A Software Quality Assurance Plan is not merely
another name for a test plan, though test plans are
Included in an SQA plan.
 SQA activities are performed on every software
Project.
 Use of metrics is an important part of developing a
strategy to improve the quality of both software
Processes and work products.
Definition of Software Quality
serves to emphasize:

1. Conformance to software
requirements is the foundation from
which software quality is measured.
 2. Specified standards are used to
define the development criteria that are
used to guide the manner in which software
is engineered.
 3. Software must conform to implicit
requirements (ease of use,
maintainability, reliability, etc.) as well as
its explicit requirements.
SQA team Activities
 Prepare SQA plan for the project.
 Participate in the development of the

project's software process description

to verify compliance with standards,
organization policies ,external
standatds(ISO) etc.
 Review software engineering activities

to verify compliance with the defined

software process.
 Audit designated software work
 Ensure that any deviations in
software or work products are
documented and handled
according to a documented
procedure.
 Record any evidence of
noncompliance and reports
them to management.
FORMAL TECHNICAL REVIEW
 A FTR is a software quality control
activity performed by software engineers
and others. The objectives are:
 To uncover errors in function, logic or
implementation for any representation
of the software.
 To verify that the software under review
meets its requirements.
 To ensure that the software has been
represented according to predefined
standards.
 To achieve software that is developed
in a uniform manner and
 To make projects more manageable.
Review meeting in FTR(rules)
 The Review meeting in a FTR should
abide to the following constraints
1.Review meeting members
should be between three and five.
2.Every person should prepare for
the meeting and should not
require more than two hours of
work for each person.
3.The duration of the review
meeting should be less than two
 The focus of FTR is on a work product
that is requirement specification, a
detailed component design, a source
code listing for a component.
 The individual who has developed the
work product i.e, 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 copy
of product material and distributes them to two or
three review members for advance preparation .
 Each reviewer is expected to spend between one and
two hours reviewing the product, making notes
 The review leader also reviews the product and
establish an agenda for the review meeting
Review reporting and Record
keeping
 During the FTR, a
reviewer( recorder) records all
issues that have been raised
 A review summary report answers

three questions
 What was reviewed?

 Who reviewed it?

 What were the findings and

conclusions?
 The review issues list serves
two purposes
 To identify problem areas in the

product
 To serve as an action item
checklist that guides the producer
as corrections are made
Review Guidelines
 Review the product, not the producer :errors
should be pointed out gently.
 Set an agenda and maintain it.
 Limit debate and rebuttal(argument)
 Enunciate problem areas, but don’t attempt to
solve every problem noted
 Take return notes
 Limit the number of participants and insist
upon advance preparation.
 Develop a checklist for each product i.e likely
to be reviewed
 Allocate resources and schedule time for FTRS
 Conduct meaningful training for all reviewer
 Review your early reviews –review the review
guidelines them selves
STATISTICAL SOFTWARE
QUALITY
ASSURANCE(quantitative
about
 quality)
Information about software defects is collected and
categorized.
 Each defect is traced back to its cause using the Pareto
principle (80% of the defects can be traced to 20% of
the causes) isolate the "vital few" defect causes
 Move to correct the problems that caused the defects
in the "vital few”
 Six Sigma for Software Engineering
 The most widely used strategy for statistical
quality assuranceIn the industry today.
It defines 3 core steps :
1. Define customer requirements,
deliverables, and project goals via
well-defined methods of customer
communication.
2. Measure each existing process and its
output to determine current quality
performance (e.g., compute defect
metrics)
3. Analyze defect metrics and determine
For an existing process that needs
improvement,then 2 additional steps
are suggested
 1. Improve process by eliminating the

root causes for defects.

 2. Control future work to ensure that

future work does not reintroduce

causes of defects.
If new processes are being developed,
core steps are augmented as follows
 1. Design each new process to avoid

root causes of defects and to meet

customer requirements.
 2. Verify that the process model will
Software Reliability
 Defined as the probability of failure free operation
of a computer program in a specified environment
for a specified time period Can be measured
directly and estimated using historical and
developmental data.
 Software reliability problems can usually be traced
back to errors in design or implementation.
 Measures of Reliability
 Mean time between failure (MTBF) = MTTF + MTTR
 MTTF = mean time to failure
 MTTR = mean time to repair
 Availability = [MTTF / (MTTF + MTTR)] x 100%