1

UNIT – 5
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, Software reliability, The ISO
9000 quality standards.

RISK MANAGEMENT
Introduction:
Risk Management is the name given to a logical and systematic method of
identifying, analysing, treating and monitoring the risks involved in any activity or
process.
Risk Management is a methodology that helps managers make best use of their available
resources
* The risk analysis and management are a series of steps that help a software team to
understand and manage Uncertainty
* A risk is a potential problem – it might happen, it might not
* But it is really good idea to identify it, assess its probability of occurrence, estimate its
impact

Reactive VS Proactive Risk strategies:

(i) Reactive risk Strategies:
* The software team does nothing about risks until something goes wrong
* If problem occurs then the team files into action in an attempt to correct the problem
rapidly. This is often called Fire – Fighting Mode
* It is sometimes laughingly called “Indiana Jones School of risk management”
* i.e. Indian Jones faced with over whelming difficulty would invariably say “ Don’t
worry I’ll think of something !” never worry about problems until they happened

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 2

(ii) Proactive Risk Strategies:

* This strategy begins long before technical work initiated. Here
=> The potential risks are identified
=> Their probability and impact are assessed
=> and they are ranked by importance
* Then software team establishes a plan for managing risks
* The primary objective is to avoid risk, but because all risks are not avoided
* The team work to develop a contingency plan that will enable it to respond in a
controlled and effective manner

Software Risks: Risk Characteristics:

(1) Uncertainty: The risk may (Or) may not happen, that is there are no 100% probable
risks
(2) Loss: If a risk became a reality, unwanted consequences (Or) losses will occur
* When risks are analyzed it is important to quantify;
=> the level of uncertainty and
Risk Categories:
(i) Project Risk:
* It affects the project Plan
* If projects risks become real, it is likely that;
=> Project schedule will slip &
=> Cost will increase
* Project risks identify
=> Potential Budgetary
=> Schedule
=> Personnel [Staffing and organization]
=> Resource
=> Stakeholder
=> Requirement Problems..

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 3

(ii) Technical Risks:

* It threaten the quality and timeliness of the software to be produced
* If a technical risk become reality, implementation may become difficult
* Technical Risks identify
=> Potential Design
=> Implementation
=> Interface
=> Verification
=> Maintenance problems
* Technical risks occur because, the problem is harder to solve than what we thought it
would be
(iii) Business Risks:
* It affects the viability of the software to be built
* Top Five business risks are;
(i) Building an excellent product (Or) System that no one really wants
[Market Risks]
(ii) Building a product that no longer fits into the overall business strategy
for the company [Strategic risks]
(iii) Building a product that the sales force doesn’t understand how to sell
[Sales Risks]
(iv) Losing the support of the senior management due to change in focus
(Or) change in people [Management Risks]
(v) Losing Budgetary (Or) Personnel commitment [Budget Risks]

(iv) Known Risks:

* These risks can be uncovered after careful evolution of the project plan, the business
and technical environment in which project is being developed
* Other reliable information sources are;
=> Unrealistic delivery date
=> Lack of document requirements
=> Poor development environment

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 4

(v) Predictable Risks:

* These risks are extrapolated from past project experience
Example:
=> Staff turnover
=> Poor communication with the customer
=> Dilution of staff effort as ongoing maintenance requests are serviced
(vi) Unpredictable Risks:
* These risks are the joker in the deck, they can and do occur. But extremely difficult to
identify in advance

Risk Identification:
Risk identification is the process of understanding what potential unsatisfactory
outcomes are associated with a particular project.
Several risk identification tools include checklists, flowcharts, and interviews

* It is a systematic attempt to specify threats to the project plan [i.e. estimates, schedules,
resource loading]
* By identifying a known and predictable risk, project manager take a first step toward
avoiding them, when possible and controlling them when necessary
There are two distinct types of risks:
(i) Generic Risks – These are potential threat to every software project
(ii) Product – Specific Risks – These can be identified only by those, who with a clear
understanding of the technology, the people, and the environment that is specific to the
software that is to be built
* One method of risk identification is to create a risk item check list
* The checklist can be used for risk identification and focus on some subset of known and
predictable risks in the following generic subcategories:
Product Size => Risk associated with the overall size of the software to
be built (Or) modified
Business impact => Risk associated with the constraints imposed by
management (Or) the market place

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 5

Customer Characteristic => Risk associated with the sophistication of

the customer and developers’ 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 quant ability
and quality of the tools to be used to built
the product
Technology to built => Risk associated with the complexity of the system
to be built and the “Newness” of the technology
that is packaged by the System
Staff Size & experience => Risks associated with the overall technical
and project experience of the software
engineers who will do the work
Assessing Overall Project Risks:
* The following questions have been derived from risk data, obtained from experienced
software project managers
* The questions are ordered by relative importance to the success of as project
Questions:
(1) Have top software and customer managers formally committed to support the project?
(2) Are end users enthusiastically committed to the project and the system / product to be
built?
(3) Are requirements fully understood by the software engineering team and its
customers?
(4) Have customers been involved fully in the definition of requirements?
(5) Do end-Users have realistic expectations?
(6) Is project scope Stable?
(7) Does the software engineering team have the right mix of skills?
(8) Are project requirements are stable?

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 6

(9) Does the project team have experience with the technology to be implemented?
(10) Is the number of people on the project team adequate to do the job?
(11) Do all customer / User constituencies agree on the importance of the project and on
the requirements for the system / product to be built?
* 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 risk components are defined in the following manner:
(1) Performance Risks => The degree of uncertainty that the product will meet its
requirements and be fit for its intended use
(2) Cost Risks => The degree of uncertainty that the project budget will be maintained
(3) Support Risks => The degree of uncertainty that the resultant software will be easy
to correct, adapt and enhance
(4) Schedule Risks => 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 risk component is divided into four categories:
=> Negligible
=> Marginal
=> Critical
=> Catastrophic
Risk Projection:
* It is also referred as Risk Estimation
* It attempts to rate each risk in two ways:
(i) the likelihood (Or) probability that the risk is real
(ii) the consequences of the problem associated with the risk should it
occur
* The project planner and technical staff perform four risk projection steps:

(1) Establish a scale, which reflects the perceived likelihood of a risk

(2) Delineate the consequence of the risk
(3) Estimate the impact of the risk on the project and product

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 7

(4) Note the over all accuracy of the risk projection, so that there will be no
misunderstanding
Risk Table:
*A risk table provides a project manager with a simple technique for risk projection
Risks Category Probability Impact RMMM
Size estimate PS 60% 2
may be
significantly
low
Large number PS 30% 3
of users than
planned
Less reuse than PS 70% 2
planned
Delivery BU 50% 2
deadline will
be tightened
Customer will PS 80% 2
change
requirements
Staff ST 30% 2
Inexperienced

* Impact values
1 – Catastrophic
2 – Critical
3 – Marginal
4 – Negligible
* The project team list all risks in the first column of the table
* Each risk is categorized in second column
e.g. PS => Project Size risk

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 8

BU => Business risk

* Third column contains the probability of occurrence of each risk
* Fourth column contains impact of each risk
* After first four column, the risk table has been completed; the table is sorted by
probability and by impact
* High probability and high impact risks moves to top of table
* Low probability risk moves to bottom of table
* The project manager studies he resultant sorted table and defines a “Cut Off Line”
* The Cut Off line drawn horizontally at some point of table implies that, only risks that
lie above the line will be given further attention
* All risks lie above the Cut Off Line must be managed
* Fifth Column, RMMM contains a pointer into a risk mitigation, monitoring and
management plan
Example:

High

Very Management
High Concern

Impact Disregard
risk factor

Very Low
0
Probability of
occurrence 1.0

* In the above figure a risk factor that has a high impact, but a low probability of
occurrence, should not absorb a significant amount of management time

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 9

* High impact risks with moderate to high probability and low impact risks with high
probability should be carried out forward into risk analysis steps that follow

Risk Refinement:
* 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
* One way to do refine is represent the risk in Condition – Transition – Consequence
[CTC] format
* The risk is stated in the following form
Given that <condition> then there is concern
That (possibly) <Consequence>
Risk Mitigation, Monitoring and management [RMMM]:
* If a software team adopts a proactive approach, to risk avoidance is always the best
* The possible steps taken to avoid the risks are

Mitigation Strategy:
=> meet with current staff to determine causes for turnover
Example:
* Poor working condition, Low pay, Competitive job market
=> Avoid 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 team so that information about each development activity is widely
dispersed
=> Define documentation standards and establish mechanism to ensure 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
=> As projects precede risk monitoring activities commence
=> The factors that can be monitored are:

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 10

Monitoring Strategy:
=> General attitudes of team members based on the project pressures
=> The degree to which the team has jelled
=> Interpersonal relationship among the team members
=> Potential problems with compensation and benefits
=> The qualitative of jobs with in the company and outside it

Risk Management and Contingency Planning:

* The project is well underway and number of people announce that they will leaving
* Suppose if the mitigation strategy has been followed then
=> Back up is available
=> Information is documented
=> Knowledge has been dispersed across team
=> In addition the manager may temporarily read just the project schedule
* It is noted that, RMMM steps leads to additional project cost
RMMM – Plan:
* The RMMM plan, documents all work performed as part of risk analysis
* It is used by project manager as part of the overall project plan
* Some Software teams do not develop a formal RMMM document; rather each risk is
documented individually using Risk Information Sheet [RIS]

RISK INFORMATION SHEET

Risk Id: CSE -06 Date: 11/02/2018 Probability: 80% Impact: High
Description: Only 70% of the software components scheduled for reuse will in fact
be integrated into the application
Refinement / Context:
Sub Condition 1: Certain reusable components were developed by a third party with
no knowledge of internal design standards
Sub Condition 2: The design components for component interfaces have not been
solidified
Sub Condition 3: Certain reusable components have been implemented in a language

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 11

that is not supported on the target environment

Mitigation / Monitoring:
(1) Contact third party to determine conformance with design issues
(2) Press for interface standard completion
Management / Contingency Plan / Trigger:
Recomputed to be 30, 300. Allocate his amount within project contingency cost.
Develop revised schedule, allocate staff accordingly
Trigger: Mitigation steps unproductive as of 10 / 3 / 06
Current Status: 15/3/6018 : Mitigation steps Initiated
Originator: Arivu Assigned: Selvan

QUALITY MANAGEMENT
Quality Concepts:
* Variation control is the heart of the quality concepts
* A manufacturer wants to minimize the variation among the products that are produced
* The variation can be minimized by reducing number of defects that are released to the
field and the number of bugs is also minimized from one release to another
* Minimize the difference in speed and accuracy from one release to another

Quality:
* It is defined as “a characteristic (Or) attribute of something”
* As an attribute of an item quality refers to measurable characteristics such as
=> Length
=> Color
=> Electrical properties and malleability
* As a characteristic of an item, it includes;
=> Cyclomatic Complexity
=> Cohesion
=> Number of function point
=> Lines of code

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 12

* Based on measurable characteristics two kinds of quality may be encountered:

Quality, simplistically, means that a product should meet its specification
 This is problematical for software systems
 Tension between customer quality requirements (efficiency, reliability, etc.) and
developer quality requirements (maintainability, reusability, etc.)
 Some quality requirements are difficult to specify in an unambiguous way
Software specifications are usually incomplete and often inconsistent
(i) Quality of Design – It refers to the characteristics that designers specify for an item
(ii) Quality of Conformance – It is the degree to which the design specification are
followed during manufacturing

User Satisfaction = Compliant Product

+
Good Delivery
+
Delivery with in budget and Schedule

Quality Control:
 Checking the software development process (within a particular project) to ensure
that procedures and standards, as defined in the quality plan, are being followed.
 Quality control aims at correcting the causes of errors.

* The quality control involves,

=> Series of inspections
=> Reviews and Tests are used throughout the software process to ensure
each work product meets the requirements placed on it
* A key concept of quality control is that all work products have defined, measurable
specifications to which we may compare the output of each process
* The feed back loop is essential to minimize the defects produced

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 13

Quality Assurance:
* It consists of a set of auditing and reporting functions that checks 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 there by gaining insight and confidence
Cost of Quality:
* Quality costs may be divided into costs associated with,
=> Prevention
=> Appraisal and
=> Failure
(i) Prevention Costs:
It includes
=> Quality planning
=> Formal Technical reviews
=> Test Equipment and training
(ii) Appraisal Costs:
* It includes activities to gain insight into product condition the “First time through” each
process
* Example of appraisal costs include,
=> in-process and in-process inspection
=> Equipment calibration and maintains
=> Testing
(iii) Failure Costs:
* These costs would disappear, if no defects appeared before shipping a product to
customers
* Failure cost may be sub divided into:

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 14

(1) Internal Failure cost: These are incurred, when we detect a defect in our product
prior to shipment
This cost includes,
=> Rework
=> Repair
=> Failure mode analysis
(2) External Failure Cost: These are associated with defects found after the product has
been shipped to the customer
Examples:
=> Complaint resolution
=> Product Return and replacement
=> Help line support
=> Warranty work

Software Quality Assurance:

* The software quality is defined as “conformance to explicitly stated functional and
performance requirements, explicitly documented development standards and implicit
characteristics that are expected of all professionally developed software”

SQA Activities:
* SQA quality assurance is composed of a variety of tasks associated with two different
group of peoples:
(i) Software Engineers => Do technical work
(ii) SQA group => It has responsibility for quality assurance, planning, oversight, record
keeping, analysis and reporting

* The independent SQA group conduct the following activities:

(1) Prepare an SQL plan for a project
(2) Participates in the development of the project’s software process description
(3) Reviews software engineering activities to verify compliance with the defined
software process

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 15

(4) Audits designated software work products to verify compliance with those defined as
part of software process
(5) Ensures that deviations in software work and work products are documented handled
according to a documented procedure
(6) Records any non-compliance and reports to senior management
Software reviews:

* Software reviews are a “filter” for the software process

* Reviews are applied at various points during software engineering and serve to uncover
errors and defects that can be removed
* Many different types of reviews can be conducted as part of software engineering
* We focus only on “Formal Technical Review” also called as “Walk through” (Or) an
“Inspection”

Defect Amplification and Removal:

* A defect amplification can be used to illustrate the generation and detection of error
during the preliminary design, detail design and coding steps of a software engineering
process

Development Step

Defects Detection
Errors Passed through

Errors from Amplified Errors 1: X Percent efficiency

previous step for error detection Errors passed to next
step
Newly generated errors

Defect Amplification Model

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 16

* The box represents a software development steps

* During the step, errors may be generated
* Review may fail to uncover newly generated errors and errors from previous steps
* Resulting from some number of errors that are passed through
* In some cases errors passed through previous steps are amplified [amplification factor,
X] by current work
Example 1: Defect amplification – No reviews:

Preliminary
Design
0 Detail
Design
0 0% 10 6
6
Code / Unit test
10 37 10
4 4*1.5
X = 1.5 0% 10
27 94
25 27 * 3 20 %
X=3
To
25 Integrate
Integration Test

94 Validation Test
47
0 50 %
System Test
0 24
0
50 %
12
0 0 50 %
Latent
Errors
0

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 17

Defect amplification – Reviews Conducted:

Preliminary
Design
0 Detail
Design
0 70 % 3 2
6
Code / Unit test
10 1
4*1.5 15 5
X = 1.5 0% 10

25 27 * 3 20 % 24
X=3
To
25 Integrate
Integration Test

24 Validation Test
0 50 % 12
System Test
0
0
6
50 %

0 0 3
50 %
Latent
0 Errors

Formal Technical Reviews [FTR]:

* It is performed by software engineers
Objectives:
(i) To uncover errors in function, logic (Or) implementation for any representation of the
software
(ii) To verify that the software under review meets its requirements
(iii) To ensure that the software has been represented according to predefined statements
(iv) To achieve software that is developed in a uniform manner
(v) To make projects more manageable
* Each FTR is conducted as a meeting and will be successful only if it is properly
planned, controlled and attended

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 18

The Review Meeting:

* The review meeting should abide by the following constraints
=> Between three and five people should be involved in the review
=> Advance preparation should occur but should require no more
than two hours of work for each person
=> The duration of the review meeting should be less than two
hours
* The review meeting is attended by the review leader, all reviews and the producer
* One of the reviewers should take on the role of the Recorder [i.e. Individual who
records (in writing) all important issues raised during the review
* The FTR begins with an introduction of the agenda, and a brief introduction by the
producer
* When valid problems (Or) errors are discovered, the recorder notes each
* At the end of the review all attendees of the FTR must decide whether to
(i) Accept the product without further modification
(ii) Reject the product due to severe errors
(iii) Accept the product provisionally [minor errors have been
encountered and must be corrected but no additional reviews will be required]
* The decision made all FTR attendees complete a sign Off, indicating their participation
in the review

Review Report:
* A review summary form is a Single page form
* It becomes part of the project historical record and may be distributed to the project
leader and other interested parties
* The review issue list serves two purposes:
(i) To identify problem areas with in the product
(ii) To serve as an action item check list that guides the producer as
corrections made
* An issues list normally attached to the summary report

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 19

Review Guidelines:
* The following represents a minimum set of guidelines for formal technical reviews
(i) Review the product, not the producer
(ii) Set an agenda and maintain it
(iii) Limit debate and rebuttal
(iv) Enunciate problem areas but don’t attempt to solve every
problem noted
(v) Take written notes
(vi) Limit the number of participants and insist upon advance
preparation
(vii) Develop a check list for each product and that is likely to be
reviewed
(viii) Allocate resources and schedule items for FTRs
(ix) Conduct meaningful training for all reviewers
(x) Reviews your early reviews
Statistical Software Quality Assurance:
(i) Information about the software defect is collected and
categorized
(ii) An attempt is made to trace each defect to its underlying cause
(iii) Using the Pareto principle [80 percent of the defect can be
traced to 20 percent of all possible causes], isolate the 20
percent
(iv) Once the vital few causes have been identified move to correct
the problems that have caused the defects

Six Sigma for Software Engineering:

The six sigma methodology defines three core steps:
(1) Define customer requirements, deliverables and project goals via well defined
methods of customer communication
(2) Measure the existing process and its output to determine current quality performance

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 20

(3) Analyze defect metrics and determine the vital few causes
* If an existing software process is in place, but improvement is required six sigma
suggests two additional steps
(i) Improve the process by eliminating the root causes of the
defects
(ii) Control the process to ensure that future work does not
reintroduce the causes of defects

Measures of Reliability and Availability:

* If we consider a computer – based system a simple measure of reliability is Mean –
Time – Between – Failure [MTBF]

MTBF = MTTF + MTTR

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)] * 100%

ISO 9000 Quality Standards:

* ISO 9000 describes a quality assurance system in generic terms that can be applied to
any business regardless of the product (Or) services offered
* To become registered to one of the quality assurance system models contained in ISO
9000, a company quality system and operations and operations are scrutinized by third
party auditors
* Upon successful registration a company is issued a certificate

Dr.K.Bhargavi /KMIT/SE/UNIT-5
 21

ISO 9001:2000
* It is the quality assurance standard that applies to software engineering
* The standard contains 20 requirements
* The requirement delineated by ISO 9001:2000 address topics such as
=> Management responsibility
=> Quality Systems
=> Contract reviews
=> Design Control
=> Document and Data control
=> Product Identification
=> Corrective and Preventive action
=> Control of quality records etc..

Dr.K.Bhargavi /KMIT/SE/UNIT-5