UNIT – V

Risk management: Reactive vs. Proactive Risk strategies, software risks, Risk
identification, Risk projection, Risk refinement, RMMM, RMMM Plan.
Quality Management: Quality concepts, Software quality assurance, Software Reviews,
Formal technical reviews, Statistical Software quality Assurance, The Capability Maturity
ModelIntegration (CMMI), Software reliability, The ISO 9000 quality standards.

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 effect
a project by identifying, analyzing and managing them

Reactive Vs Proactive risk

Reactive : It monitorsthe projects likely risk and resources are set aside.
Proactive: Risk are identified, their probability and impact is accessed

Software Risk
It involve 2 characteristics
Uncertainty : Risk may or may not happen
Loss : If risk is reality unwanted loss or consequences will occur
It includes
1)Project Risk
2)Technical Risk
3)Business Risk
4)Known Risk
5)Unpredictable Risk
6) Predictable risk
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 be difficult to identify

Department of CSE Page 1 of 8

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
Negligible-0
Marginal-1
Critical-2
Risk Identification
Risk Identification includes
Product size
Business impact
Development environment
Process definition
Customer characteristics
Technology to be built
Staffsize and experience

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
Risk Category Prob Imp RM
abilit act MM
y

Size PS 60% 2
estimate
may be
significantly

low

Larger no. PS 30% 3

of
users than
planned

Less reuse PS 70% 2

than planned

End user BU 40% 3

resist system

Likelihood or probability that the risk is real(Li)

Consequences(Xi)
Department of CSE Page 2 of 8
Risk Projection
Steps in Risk projection
1.
Estimate Li for each risk
2.
Estimate the consequence Xi
3.
Estimate the impact
4.
Draw the risk table
Ignore the risk where the management concern is low i.e., risk having impact high or
low with low probability of occurrence
Consider all risks where management concern is high i.e., high impact with high or
moderate probability of occurrence or low impact with high probability of
occurrence Risk Projection
Projection

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 a.Nature: Likely problems if risk occurs
b.Scope: Just how serious is it?
c.Timing: When and how long

It is based on Risk Elaboration

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 Monitoring And Management (RMMM)

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 Mitigation Monitoring And Management (RMMM)
Risk ManagementContingency planning
 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)

Department of CSE Page 3 of 8

RMMM plan
It documents all work performed as a part of risk analysis.
Each risk is documented individually by using a Risk Information
Sheet. RIS is maintained by using a database system Quality
Management

Quality Concepts
Variation control is the heart of quality control
Form 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
Quality of design
Refers to characteristics that designers specify for the end product
Quality Management
Quality of conformance
Degree to which design specifications are followed in manufacturing the
product 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
Prevention costs
Quality planning, formal technical reviews, test equipment, training
Appraisal costs
In-process and inter-process inspection, equipment calibration and maintenance,
testing Failure costs
rework, repair, failure mode analysis
External failure costs
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.
 Software Quality Assurance
Definition of Software Quality serves to emphasize:
Conformance to software requirements is the foundation from which software quality
is measured.

Department of CSE Page 4 of 8

Specified standards are used to define the development criteria that are used to guide
the manner in which software is engineered.
Software must conform to implicit requirements (ease of use, maintainability, reliability,
etc.) as well as its explicit requirements.

SQA Activities
Prepare SQA plan for the project.
Participate in the development of the project's software process description. Review
software engineering activities to verify compliance with the defined software process.
Audit designated software work products to verify compliance with those defined as part
of the software process.

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.

Software Reviews
Purpose is to find errors before they are passed on to another software
engineering activity or released to the customer.
Software engineers (and others) conduct formal technical reviews (FTRs) for
software quality assurance.
Using formal technical reviews (walkthroughs or inspections) is an effective means
for improving software quality.

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

The Review meeting in a FTR should abide to the following
constraints Review meeting members should be between three and
five.
Every person should prepare for the meeting and should not require more than two hours of
work for each person.
 The duration ofthe review meeting should be less than two hours.
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 .

Department of CSE Page 5 of 8

Each reviewer is expected to spend between one and two hoursreviewing the product,
making notes
The review leader also reviews the product and establish an agenda for the review
meeting The review meeting is attended by review leader, all reviewers and the producer.
One of the reviewer act as a recorder,who notes down all important points discussed in
the meeting.
The meeting(FTR) is started by introducing the agenda of meeting and then the
producer introduces his product. Then the producer “walkthrough” the product, the
reviewers raise issues which they have prepared in advance.
If errors are found the recorder notes down

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?
Review summary report is a single page form with possible attachments

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
Set an agenda and maintain it
Limit debate and rebuttal
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
Software Defects
Industry studies suggest that design activities
 introduce 50-65% of all defects or errors
during the software process
Review techniques have been shown to be up
to 75% effective in uncovering design flaws
which ultimately reduces the cost of
subsequent activities in the software process

Statistical Quality Assurance

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.

Department of CSE Page 6 of 8

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 assurance
Three 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 vital few causes.

For an existing process that needs improvement

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
1. Design each new process to avoid root causes of defects and to
meet customer requirements
2. Verify that the process model will avoid defects and meet customer
requirements
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%
 ISO 9000 Quality Standards
ISO (International Standards Organization) is a group or consortium of 63 countries
established to plan and fosters standardization. ISO declared its 9000 series of standards in
1987. It serves as a reference for the contract between independent parties. The ISO 9000
standard determines the guidelines for maintaining a quality system. The ISO standard
mainly addresses operational methods and organizational methods such as responsibilities,
reporting, etc. ISO 9000 defines a set of guidelines for the production process and is not
directly concerned about the product itself.

Types of ISO 9000 Quality Standards

The ISO 9000 series of standards is based on the assumption that if a proper stage is
followed for production, then good quality products are bound to follow automatically.
The types of industries to which the various ISO standards apply are as follows.

Department of CSE Page 7 of 8

1.ISO 9001: This standard applies to the organizations engaged in design,
development, production, and servicing of goods. This is the standard that applies to
most software development organizations.
2.ISO 9002: This standard applies to those organizations which do not design products but
are only involved in the production. Examples of these category industries contain steel
and car manufacturing industries that buy the product and plants designs from external
sources and are engaged in only manufacturing those products. Therefore, ISO 9002 does
not apply to software development organizations.
3.ISO 9003: This standard applies to organizations that are involved only in the installation
and testing of the products. For example, Gas companies.

An organization determines to obtain ISO 9000 certification applies to ISO registrar office for
registration. The process consists of the following stages:
 1.Application: Once an organization decided to go for ISO certification, it applies to the registrar
for registration.

2.Pre-Assessment: During this stage, the registrar makes a rough assessment of the organization.
3.Document review and Adequacy of Audit: During this stage, the registrar reviews the
document submitted by the organization and suggest an improvement.

4.Compliance Audit: During this stage, the registrar checks whether the organization has compiled
the suggestion made by it during the review or not.

5.Registration: The Registrar awards the ISO certification after the successful completion of all
the phases.

6.Continued Inspection: The registrar continued to monitor the organization time by time.

Department of CSE Page 8 of 8