Unit 5

Software Risk and

Quality Management

By
Prof. Prerna Solanke
 Software Risk
• Risk is an “uncertain event or condition” that may or may not
occur in the future. It is generally caused due to lack of
information, control or time.
• A possibility of suffering from loss in software development
process is called a software risk.
• Risk Management is the system of identifying addressing and
eliminating these problems before they can damage the project.
"Tomorrow problems are today's risk."
 Risk management strategies
1. Reactive Risk Management:
Definition: Involves responding to risks after they have occurred. It
focuses on damage control and mitigating the impact of problems as they
arise.
Example: Fixing a critical bug after it has caused a system crash.
2. Proactive Risk Management:
Definition: Involves identifying and addressing risks before they
materialize. It focuses on planning, risk assessment, and taking preventive
measures to minimize risk impact.
Example: Conducting thorough testing early in development to
prevent bugs in production.
 Categories of the risk

1. Project risk
• Risks related to management, resources, and planning that can
impact the overall success of the project, such as unrealistic
deadlines, budget constraints, or lack of proper project
management.
• For example, unrealistic deadlines. If a software project is
scheduled with insufficient time for development and testing, it
can lead to rushed work, poor quality, and potential failure to
meet client expectations.
 Categories of the risk
2. Technical risk
• Risks arising from the technology itself, such as choosing
unsuitable technologies, system complexity, technical limitations,
or difficulty in integrating components.
• For example, The Space Shuttle Challenger exploded 73 seconds
into its flight on January 28, 1986. The shuttle broke apart and
disintegrated in the Atlantic Ocean, killing all seven crew
members.
 Categories of the risk
3. Business risk
• Business risks threaten the viability of the software to be
built and often jeopardize the project or the product.
• This type of risks contain risks of building an excellent
product that no one need, losing budgetary or personnel
commitments, etc.
• For example, Ford was read to Edsel, the market had already
moved on to compact cars and the Edsel was a flop.
 Categories of the risk
There are five subcategories of the Business risk:
1.Market risk - Creating an excellent system that no one really wants.
2.Strategic risk - Creating a product which no longer fit into the overall
business strategy for companies.
3.Sales risk - The sales force does not understand how to sell a creating
product.
4.Management risk - Loose a support of senior management because of a
change in focus.
5.Budget risk - losing a personal commitment.
 Other Categories Of The Risk

1. Known risks: Risks that can be uncovered after careful

assessment of the project program, business and technical
environment.

2. Predictable risks: Risks that are hypothesized from previous

project experience.

3. Unpredictable risks: Risks that can and do occur, but are

extremely tough to identify in advance.
Risk management plan
 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.
● The objective is the early and continuous identification of events that,
if they occur, will have negative impacts on the project's ability to
achieve performance or capability outcome goals.
 Risk Identification

Software risk identification

 Risk Identification

There are two distinct types of risks :

1. Generic risks: These are a potential threat that can affect a
project or the interests of those involved in it.
2. Product-specific risks: These 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.
 Risk Identification
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
• Business impact
• Customer characteristics
• Process definition
• Development environment
• Technology to be built
• Staff size and experience
 Risk Assessment
• Software risk assessment is a process of identifying, analyzing,
and prioritizing risks.
• There are five steps which organization follow for assessment of
risks:
1. Identify the hazards
2. Determine what or who could be harmed.
3. Evaluate the risks and develop control measures.
4. Record the findings.
5. Review and update the risk assessment regularly.
 Risk Projection

• Risk projection is also called risk estimation.

• It attempts to rate each risk in two ways:
1. The probability that the risk is real and will occur
2. The consequences of the problems associated with the risk,
should it occur.
 Risk Projection
The project planner along with other technical and managers staff,
performs 4 risk projection activities that are as follows:
1.Establish a scale which reflects the perceived likelihood of a
risk.
2.Depict or outline the consequences of the risk.
3.Estimate the impact of the risk on the project and the product.
4.Assess the overall accuracy of the risk projection so that there will
be no misunderstandings
 Risk Projection- Developing a Risk Table
A risk table provides a project manager with a simple technique
for risk projection.

Risk summary - Short description of risk

Probability - estimation of risk occurrence,
Impact values:1.catastrophic 2.critical 3.marginal 4.negligible
Risk Projection- Developing a Risk Table
RANK RANGE LOSS
1 Catastrophic • Irreversible environmental damage
• Closure to business
2 Critical • Reversible environmental damage
• Violation of regulation/law
3 Marginal Avoidable environmental damage where
restoration activities can be done
4 Negligible • Does not violate laws
• Little or minimal environmental
damage
 Risk Projection- Developing a Risk Table
Example:

PS - project size risk

BU - business risk
 Risk Projection- Assessing Risk Impact
Three factors affect the consequences that are likely if a risk
does occur:
1. Nature: It indicates the problems that are likely if it occurs.
2. Scope: It combines how serious the risk is and how much of
the project will be affected or how many customers are
harmed.
3. Timing: It considers when and for how long the impact will
be felt.
 Risk Projection- Assessing Risk Impact

Risk analysis approach:

The following steps determine the overall consequences of a
risk:
1. Find the average probability of occurrence of the risk for
each risk component.
2. Determine the impact for each component.
3. Complete the risk table and analyze the results.
 Risk Projection- Assessing Risk Impact
Risk exposure is a measure of possible future loss which may result
from an activity and to determine which losses are acceptable or
unacceptable.
The overall Risk Exposure, RE, is determined using the following
relationship: RE = P x C
where,
P is the probability of occurrence for a risk
C is the cost to the project should the risk occur.
Risk exposure can be computed for each risk in the risk table,
once an estimate of the cost of the risk is made.
 Risk Projection- Assessing Risk Impact

Example: Probability of occurrence of risk is 80% that 18 of 60

component will have to be developed. Total cost of developing the
component is $25,000. Compute the Risk exposure.
Solution:
 Risk Mitigation, Monitoring and Management
(RMMM) Plan
• It is a part of the software development plan.
• It documents all work as a part of risk analysis and used by the
project manager as a part of the overall project plan.
• The risk mitigation and monitoring starts after the project is
started and the documentation of RMMM is completed.
• In some software teams, risk is documented with the help of a
Risk Information Sheet(RIS).
 1. RISK MITIGATION

Risk mitigation means preventing the risk to occur.

Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are reason for risk creation.
3. Controlling corresponding documents time to time.
4. Conducting timely reviews to speed up the work.
 2. RISK MONITORING
It is an activity used for project tracking.
It has following primary objectives as the follows.
1. To check if predicted risks occurs or not.
2. To ensure proper application of risk aversion steps defined
for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks
throughout the project.
 3. RISK MANAGEMENT
● It assumes that the mitigation activity failed and the risk is a
reality.
● This task is done by Project manager when risk becomes reality
and causes severe problems.
● If the project manager effectively uses project mitigation to remove
risks successfully then it is easier to manage the risks.
● The main objective of the risk management plan is the risk register
which describes and focuses on the predicted threats to a software
project.
 The RMMM 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.
● Some software teams do not develop a formal RMMM document.
Rather, each risk is documented individually using a risk
information sheet (RIS).
● RIS is maintained using a database system, so that creation and
information entry, priority ordering, searches, and other analysis
may be accomplished easily.
 Software Configuration Management(SCM)
• SCM is also called as Change management.
• SCM is an umbrella activity that is applied throughout the software
process.
• SCM ensures that changes are tracked, conflicts are minimized, and the
product is always in a deployable state.
• Because change can occur at any time, SCM activities are developed to:
1. identify change
2. control change
3. ensure that change is being properly implemented
4. report changes to others who may have an interest.
Need of SCM
 Need of SCM
● Multiple people working on software which is continually updating
● In a case where multiple version, branches, authors are involved in
a software config project
● Changes in user requirement, policy, budget, schedule need to be
accommodated.
● Software should able to run on various machines and Operating
Systems
● Helps to develop coordination among stakeholders
● SCM process is also beneficial to control the costs involved in
making changes to a system
 SCM Repository
• The SCM repository is the set of mechanisms and data structures
that allow a software team to manage change in an effective
manner.
• SCM repository provides a hub for the integration of software
tools, is central to the flow of the software process, and can
enforce uniform structure and format for software engineering
work products.
 SCM Repository - Roles

Along with data management SCM repository performs

following operations:
• Data integrity
• Information sharing
• Tool integration
• Date integration
• Document standardization
 SCM Repository – Features & contents

The features and content of the repository are best

understood by looking at it from two perspectives:
1. what is to be stored in the repository
2. what specific services are provided by the repository.
SCM Repository – Contents
 SCM Repository – Features
• Versioning
• Dependency tracking and change management
• Requirement tracing
• Configuration management
• Audit trails
 SCM Process
SCM process defines a series of tasks that have four primary
objectives:
• to identify all items that collectively define the software
configuration,
• to manage changes to one or more of these items,
• to facilitate the construction of different versions of an
application, and
• to ensure that software quality is maintained as the
configuration evolves over time.
SCM Process - Participants
 SCM process - Tasks
SCM tasks can be viewed
as concentric layers.

The SCM process

involves managing code,
documents,
configurations, and other
important artifacts in a
systematic way.
 SCM process - Identification of objects
● control and manage software configuration items
● Two types of objects can be identified: Basic objects and
Aggregate objects.
1. Basic object: It is a unit of information that you create
during analysis, design, code, or test.
2. Aggregate object: It is a collection of basic objects and
other aggregate objects.
 SCM process - Identification of objects
● Identify and define items that need to be managed, such as source
code files, libraries, documents, and dependencies.
● Changes may be made to any version, but not necessarily to all
versions.
Example:
For the frontend code, the home_page.html and checkout.js are
identified as configuration items. Each file is assigned a version
identifier (e.g., obj1.0).
SCM process - Identification of objects
 SCM process - Version Control
● Manage changes to items over time, maintaining a history of
revisions.
● Enables the team to track modifications, roll back to previous
versions, and prevent conflicts when multiple developers work
on the same file.
● Tools like Git, Subversion (SVN), or Mercurial are used to keep
track of the changes made to the software code and
configurations.
 SCM process - Version Control
Each time a developer makes a change to the source code, they commit
the changes to the Git repository with a message explaining the
modification.
Example:
● Developer A is working on the feature/add-to-cart branch, adding new
functionality to allow users to add products to their cart.
● Developer B is fixing a bug in the checkout.js file on a separate
branch.
● Each developer pushes their code changes to Git, creating a new
version for each update.
 SCM process - Change Control
● Process of handling changes in the software project, from initiation
to implementation.
● A change request is submitted and evaluated to assess technical
merit, potential side effects, overall impact on other configuration
objects and system functions.
● The results of the evaluation are presented as a change report, which
is used by a change control authority (CCA).
 SCM process - Change Control

The team uses JIRA to manage and track all change requests (e.g.,
adding a new payment method).
Example:
A change request for adding a "Buy Now" button is raised. The CCA
checks how it would affect the checkout process, user experience,
and the existing cart functionality before approving the change.
 SCM process - Configuration Control
● Controlling changes in the configuration items by ensuring only
approved changes are implemented.
● Prevents unauthorized or unnecessary changes from affecting
the software.
● The project manager and team lead review all code changes
before merging them into the main branch
Example:
Developer A's change to the cart system is reviewed by the team
lead to ensure it doesn’t break any existing functionality. Only after
approval, the change is merged into the main codebase.
 SCM process - Status Reporting
● Keeping stakeholders informed about the current configuration,
changes, and progress of the software.
● Provides visibility into the development process, helping in
decision-making and risk management.
● The project manager regularly generates reports from Git,
Jenkins, and JIRA to keep the stakeholders informed of the
progress.
● The reports highlight the status of feature development, the
success of builds, and the list of resolved/active issues.
 SCM process
Tools:

● Git: Distributed version control system to track code changes.

● Subversion (SVN): Centralized version control system.
● Jenkins: Continuous integration tool to automate builds and
tests.
● JIRA: Project management and defect tracking tool.
 Software Quality Assurance

● SQA is simply a way to assure quality in the software.

● It ensures that developed software meets and complies with the
defined or standardized quality specifications.
● SQA incorporates all software development processes starting
from defining requirements to coding until release.
● Its prime goal is to ensure quality.
Software Quality Assurance Tasks
 Software Quality Assurance Activities

• SQA Management Plan

• Set The Check Points
• Multi testing Strategy
• Measure Change Impact
• Manage Good Relations
 Software Quality Assurance Metrics

• Correctness
• Maintainability
• Integrity
• Usability
 Formal technical reviews - Objectives
1. to uncover errors in function, logic, or implementation for any
representation of the software;
2. to verify that the software under review meets its
requirements;
3. to ensure that the software has been represented according to
predefined standards;
4. to achieve software that is developed in a uniform manner;
and
5. to make projects more manageable.
 Formal technical reviews

• FTR is a software quality control activity performed by

software engineers.
• The focus of the FTR is on a work product
• Each FTR is conducted as a meeting and will be successful
only if it is properly planned, controlled, and attended.
• Steps in FTR: (1) The review meeting and (2) Review
Reporting and Record Keeping
 Walkthroughs

• Walkthrough is used to review documents with peers,

managers, and fellow team members who are guided by the
author of the document to gather feedback and reach a
consensus.
• A walkthrough can be pre-planned or organized based on the
needs. Generally people working on the same work product are
involved in the walkthrough process.
 Walkthroughs - Goals

1. To present the documents both within and outside the software

discipline in order to gather the information regarding the topic
under documentation.
2. To explain or do the knowledge transfer and evaluate the
contents of the document
3. To achieve a common understanding and to gather feedback.
4. To examine and discuss the validity of the proposed solutions
 Formal technical reviews Walkthroughs

It is a formal meeting conducted by It is an informal meeting led by author who

technical staff or software engineer guide the participants through the document
thought process to achieve a common
understanding and to gather feedback for
evaluation

Purpose is to detect quality problems and Purpose is to ensure that code fits the purpose
suggest improvements

It is a planned activity. It require lot of It is an unplanned activity which does not

preparation. require any planning

The FTR is actually a class of reviews that Walkthrough is a type of Formal Technical
includes walkthroughs, inspections, round- Review
robin reviews and other small group
technical assessments of software