5th Semester ECS Software Engineering

Module-5 Software Risk & Quality Management

 Software Risk- A possibility of suffering from loss in software development process is called a
software risk.
 Types of Risk- Schedule Risk, Budget Risk, Operational Risks, Technical Risks, Programmatic Risks
 Risk Identification- a set of activities that detect, describe all potential risks
 Risk Assessment- a process of identifying, analyzing, and prioritizing risks
 Risk Projection- also called risk estimation, attempts to rate each risk in two ways
 RMMM- Risk Mitigation, Monitoring, and Management Plan. A risk management technique used in
the software Project plan
 Software Quality Assurance Tasks (SQA Tasks) - Design test plans, procedures, Document
software defects, using a bug tracking system, and report defects to software developers. Identify,
analyze, and document problems with program function, output, online screen, or content.
 Software Quality Assurance Plan (SQA Plan) - it makes up the procedures, techniques, and
tools employed to ensure the product or service is in correspondence with the requirements outlined in
the software requirement specification.
 McCall’s Quality Factors- Correctness, Reliability, Usability, Integrity, Efficiency.
 Software Reliability- It is the probability of failure-free software operation for a specified period of
time in a specified environment.
 Formal Technical Review (FTR) - It is a software quality control activity performed by software
engineers.
 Walkthrough- Review meeting process (non formal meeting) where the code is read by the author and
others who are present in the meeting can note down the important points and can give suggestions
about them.
What is Software Risk and explain types of Software Risk in software project
development?
Software Risk:
 Risk is uncertain events associated with future events which have a probability of occurrence
but it may or may not occur and if occurs it brings loss to the project. Risk identification and
management are very important task during software project development because success
and failure of any software project depends on it.
 A possibility of suffering from loss in software development process is called a software risk.
Loss can be anything, increase in production cost, development of poor quality software, not
being able to complete the project on time.

Types of Software Risk in software project development:

Schedule Risk, Budget Risk, Operational Risks, Technical Risks, Programmatic Risks
1. ScheduleRisk:
Schedule related risks refers to time related risks or project delivery related planning
risks. The wrong schedule affects the project development and delivery. Finally if
schedule risks are not managed properly it gives rise to project failure and at last it affect
to organization/company economy very badly.

Some reasons for Schedule risks –

 Time is not estimated perfectly

 Improper resource allocation
 Tracking of resources like system, skill, staff etc
 Frequent project scope expansion
 Failure in function identification and its’ completion

2. Budget Risk:

Budget related risks refer to the monetary risks mainly it occurs due to budget overruns. Always
the financial aspect for the project should be managed as per decided but if financial aspect of
project mismanaged then there budget concerns will arise by giving rise to budget risks. So
proper finance distribution and management are required for the success of project otherwise it
may lead to project failure.

Some reasons for Budget risks –

 Wrong/Improper budget estimation

 Unexpected Project Scope expansion
 Mismanagement in budget handling
 Cost overruns
 Improper tracking of Budget
3. OperationalRisks:
Operational risk refers to the procedural risks means these are the risks which happen in
day-to-day operational activities during project development due to improper process
implementation or some external operational risks.

Some reasons for Operational risks –

 Insufficient resources
 Conflict between tasks and employees
 Improper management of tasks
 No proper planning about project
 Less number of skilled people
 Lack of communication and cooperation
 Lack of clarity in roles and responsibilities
 Insufficient training

4. TechnicalRisks:
Technical risks refers to the functional risk or performance risk which means this
technical risk mainly associated with functionality of product or performance part of the
software product.

Some reasons for Technical risks –

 Frequent changes in requirement

 Less use of future technologies
 Less number of skilled employee
 High complexity in implementation
 Improper integration of modules

5. ProgrammaticRisks:
Programmatic risks refer to the external risk or other unavoidable risks. These are the
external risks which are unavoidable in nature. These risks come from outside and it is
out of control of programs.

Some reasons for Programmatic risks –

 Rapid development of market

 Running out of fund / Limited fund for project development
 Changes in Government rules/policy
 Loss of contracts due to any reason
Risk identification

Risk identification (RI) is a set of activities that detect, describe all potential risks to assets and
processes that could have negatively impact business outcomes in terms of performance, quality,
damage, loss or reputation. In Software Testing, risk analysis is the process of identifying the
risks in software that you built and prioritizing them to test.

Risk assessment

Risk assessment simply means to describe the overall process or method to identify risk and
problem factors that might cause harm. It is actually a systematic examination of a task or project
that you perform to simply identify significant risks, problems, hazards, and then to find out
control measures that you will take to reduce risk. The best approach is to prepare a set of
questions that can be answered by project managers in order to assess overall project risks.

These questions are shown below:

 Will the project get proper support from the customer manager?
 Are end-users committed to software that has been produced?
 Is there a clear understanding of the requirements?
 Is there an active involvement of customers in the requirement definition?
 Are the expectations set for the products are realistic?
 Is project scope stable?
 Are there team members with the required skills?
 Are project requirements stable?
 Does technology used for software is known to developers?
 Is the size of the team sufficient to develop the required product?
 Is that all customers know the importance of the product/requirements of the system to
be built?

Thus, the number of negative answers to these questions represents the severity of the impact of
risk on the overall project. It is not about creating or making a large number of work papers, but
rather simply identifies and find out measures to control risks in workplace.

Risk Projection:
Risk projection is a process of identifying, analyzing, and predicting potential risks that can
affect a project or an organization.

The primary objective of risk projection is to assess the potential impact of risks on the project
and develop strategies to mitigate or avoid those risks. Risk projection involves identifying
potential risks, evaluating the likelihood and impact of those risks, and developing a plan to
address them.
  RMMM- Risk Mitigation, Monitoring, and Management Plan
A risk management technique used in the software Project plan

A risk management technique is usually seen in the software Project plan. This can be divided
into Risk Mitigation, Monitoring, and Management Plan (RMMM). In this plan, all works are
done as part of risk analysis. As part of the overall project plan project manager generally uses
this RMMM plan.

In some software teams, risk is documented with the help of a Risk Information Sheet (RIS).
This RIS is controlled by using a database system for easier management of information i.e
creation, priority ordering, searching, and other analysis. After documentation of RMMM and
start of a project, risk mitigation and monitoring steps will start.

 Risk Mitigation:
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.

1. Finding out the risk.

2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.

 Risk Monitoring:
It is an activity used for project tracking.
It has the following primary objectives as follows.

1. To check if predicted risks occur 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.

 RiskManagementandplanning :
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. This shows that the response that will be
taken for each risk by a manager.

The main objective of the risk management plan is the risk register.

This risk register describes and focuses on the predicted threats to a software project.

Risk Management:

A risk is a probable problem- it might happen or it might not. There are main two characteristics
of risk
Uncertainty- the risk may or may not happen that means there are no 100% risks.
Loss – If the risk occurs in reality, undesirable result or losses will occur.
Risk management is a sequence of steps that help a software team to understand, analyze and
manage uncertainty. Risk management consists of
 Risk Identification
 Risk analysis
 Risk Planning
 Risk Monitoring

Drawbacks of RMMM:

 It incurs additional project costs.

 It takes additional time.
 For larger projects, implementing an RMMM may itself turn out to be another tedious
project.
 RMMM does not guarantee a risk-free project, infact, risks may also come up after the
project is delivered.

Software Quality Assurance (SQA)

 Software Quality Assurance (SQA) consists of a set of activities that monitor the
software engineering processes and methods used to ensure quality.
 Software Quality Assurance is simply a way to assure quality in the software. It is the set
of activities which ensure processes, procedures as well as standards are suitable for the
project and implemented correctly.
 Software Quality Assurance is a process which works parallel to development of
software. It focuses on improving the process of development of software so that
 problems can be prevented before they become a major issue. Software Quality
Assurance is a kind of Umbrella activity that is applied throughout the software process.

Software Quality Assurance (SQA) encompasses:

1. A quality management approach.

2. Effective software engineering technology (methods and tools).
3. Some formal technical reviews are applied throughout the software process.
4. A multitiered testing strategy.
5. Controlling software documentation and the changes made to it.
6. Procedure to ensure compliance with software development standards
7. Measurement and reporting mechanisms.

Software Quality Assurance Tasks (SQA Tasks)

What is Quality?

Quality defines to any measurable characteristics such as correctness, maintainability,

portability, testability, usability, reliability, efficiency, integrity, reusability, and interoperability.

There are two kinds of Quality:

Quality of Design: Quality of Design refers to the characteristics that designers specify for an
item. The grade of materials, tolerances, and performance specifications that all contribute to the
quality of design.

Quality of conformance: Quality of conformance is the degree to which the design

specifications are followed during manufacturing. Greater the degree of conformance, the higher
is the level of quality of conformance.

Quality Assurance: Quality Assurance is the preventive set of activities that provide greater
confidence that the project will be completed successfully.
Software Quality Assurance

Software quality assurance is a planned and systematic plan of all actions necessary to provide
adequate confidence that an item or product conforms to establish technical requirements.

A set of activities designed to calculate the process by which the products are developed or
manufactured.

Benefits of Software Quality Assurance (SQA):

1. SQA produces high quality software.

2. High quality application saves time and cost.
3. SQA is beneficial for better reliability.
4. SQA is beneficial in the condition of no maintenance for a long time.
5. High quality commercial software increase market share of company.
6. Improving the process of creating software.
7. Improves the quality of the software.
8. It cuts maintenance costs. Get the release right the first time, and your company can
forget about it and move on to the next big thing. Release a product with chronic issues,
and your business bogs down in a costly, time-consuming, never-ending cycle of repairs.

Major Software Quality Assurance Tasks:

1. SQA Management Plan:

Make a plan for how you will carry out the SQA throughout the project.
2. Set The Check Points:
SQA team should set checkpoints. Evaluate the performance of the project on the basis of
collected data on different check points.

3. Multi testing Strategy:

Do not depend on a single testing approach. When you have a lot of testing approaches
available use them.
4. Measure Change Impact:
The changes for making the correction of an error sometimes re introduces more errors
keep the measure of impact of change on project.
5. Manage Good Relations:
In the working environment managing good relations with other teams involved in the
project development is mandatory. Bad relation of SQA team with programmers team
will impact directly and badly on project.
Differences between Quality Assurance and Quality control

Quality Assurance Quality Control

Quality Assurance (QA) is the Quality Control (QC) is
set of actions including described as the processes and
facilitation, training, methods used to compare
measurement, and analysis product quality to
needed to provide adequate requirements and applicable
confidence that processes are standards, and the actions are
established and continuously taken when a nonconformance
improved to produce products is detected.
or services that conform to
specifications and are fit for
use.
QA is an activity that
QC is an activity that
establishes and calculates the
demonstrates whether or not
processes that produce the
the product produced met
product. If there is no process,
standards.
there is no role for QA.
QC relates to a particular
QA helps establish process
product or service

QC verified whether particular

QA sets up a measurement attributes exist, or do not exist,
program to evaluate processes in a explicit product or
service.
QC identifies defects for the
QA identifies weakness in
primary goals of correcting
processes and improves them
errors.
Quality Assurance is a Quality Control is a corrective
managerial tool. tool.
Verification is an example of Validation is an example of
QA. QC.
Software Quality Assurance Plan
It is a managerial tool and a proactive measure to prevent defects and consumes less time. It is
usually associated with two teams. It has auditing and reporting functions. It ensures that the
software being developed meets the standard demand and works parallel to its development.

A Software Quality Assurance Plan revolves around making sure that the product or service
teaches the market trouble and bug-free. It should also meet the requirements defined in the SRS
(software requirement specification).

Why Is a Quality Assurance Plan Important for Software Companies?

A quality assurance plan is crucial for software companies due to the following reasons:

1. Assures product dependability through extensive testing and validation.

2. Keeps customers satisfied by providing high-quality items.

3. Reduces risks and expenses by detecting problems early on.

4. Ensures industry standards and laws are followed.

5. Encourages ongoing improvement and efficiency in development practices.

Overall, a quality assurance plan is vital for software companies to deliver reliable, high-quality
products, maintain customer satisfaction, reduce risks and costs, comply with industry standards,
and drive continuous improvement.

Creating a Quality Assurance Plan (Best Practices)

 Setting Procedures and Policies for All:

Establishing clear processes and regulations ensures everyone is aware of expectations and
upholds quality standards, ensuring everyone follows the appropriate standards.

 Schedule Roles and Responsibilities:

During the quality assurance process, team members will be aware of their roles and duties, akin
to actors knowing their lines and cues.

 Documentation in Different Phases:

Documenting our quality journey through project phases, similar to taking pictures, will help us
develop, learn, and make adjustments, providing valuable resources for future initiatives.
  Review and Audit:

Routine quality inspections assess and audit quality assurance initiatives to ensure they align
with goals and are worthwhile. This process is similar to a strategy checkup to ensure soundness
and functionality.

 Testing Phase:

The action takes place here! To find any bugs or problems, we’ll put our goods and services
through a thorough testing process. To make sure they are top-notch, it’s like taking our
inventions for a test drive and pushing them to their limits.

 Troubleshooting Problems:

Address obstacles head-on, examining underlying reasons, devising cures, and implementing
them like sleuths to maintain proper functioning and address issues effectively.

 Project Control:

Imagine yourself as the leader of our quality project, monitoring key performance indicators and
making wise decisions to ensure we’re heading in the right direction.

 Training:

Fund training initiatives to enhance team members’ abilities and expertise, fostering a high-
quality culture and thriving in their professions. Provide necessary tools for success.

 Risk Management:

Proactively identifying potential dangers and developing plans to reduce them serves as a safety
net, ensuring quality issues are mitigated and preparing for outstanding achievements by
controlling risks.

Proactively identifying potential dangers and developing plans to reduce them serves as a safety
net, ensuring quality issues are mitigated and preparing for outstanding achievements by
controlling risks.

McCall’s Quality Model

McCall’s Software Quality Model was introduced in 1977. This model is incorporated with
many attributes, termed as software factors, which influence software. The model distinguishes
between two levels of quality attributes:

 Quality Factors
 Quality Criteria
  Quality Factors: The higher-level quality attributes which can be accessed directly are
called quality factors. These attributes are external attributes. The attributes at this level
are given more importance by the users and managers.
 Quality Criteria: The lower or second-level quality attributes that can be accessed either
subjectively or objectively are called Quality Criteria. These attributes are internal
attributes. Each quality factor has many second-level of quality attributes or quality
criteria.
 McCall distinguishes two levels of quality attributes McCall.
Quality criteria: It can be measured directly, either objectively or subjectively.
Quality Factors: The higher-level quality attributes which can be assessed directly are
called quality factors.

The 11 software quality factors are organized into three product quality factors: Product
Operation, Product Revision, and Product Transition.

 Product Operation: The software can run successfully in the market if it is according to
the specifications of the user and also it should run smoothly without any defects. The
product operation perspective influences the extent to which the software fulfills its
specifications
 Product Revision: It encompasses the revision perspective identifying quality factors
that change or enhance the ability to change the software product in the future according
to the needs and requirements of the user.
 Product Transition: It enables the software to adapt itself to new environments. The
identification of the quality factor which enables the ability to the adaption of the
software in the new environment is known as product transition.

Product Operation

It includes five software quality factors, which are related to the requirements that directly affect
the operation of the software such as operational performance, convenience, ease of usage, and
correctness. These factors help in providing a better user experience.

 Correctness: The extent to which software meets its requirements specification.

 Efficiency: The number of hardware resources and code the software needs to perform a
function.

 Integrity: The extent to which the software can control an unauthorized person from
accessing the data or software.

 Reliability: The extent to which software performs its intended functions without failure.

 Usability: The extent of effort required to learn, operate and understand the functions of
the software.
Product Revision

It includes three software quality factors, which are required for testing and maintenance of the
software. They provide ease of maintenance, flexibility, and testing effort to support the software
to be functional according to the needs and requirements of the user in the future.

 Maintainability: The effort required to detect and correct an error during the
maintenance phase.

 Flexibility: The effort needed to improve an operational software program.

 Testability: The effort required to verify software to ensure that it meets the specified
requirements.

Product Transition

It includes three software quality factors that allow the software to adapt to the change of
environments in the new platform or technology from the previous.

 Portability: The effort required to transfer a program from one platform to another.

 Re-usability: The extent to which the program’s code can be reused in other
applications.

 Interoperability: The effort required to integrate two systems with one another.

Formal Technical Review (FTR)

Formal Technical Review (FTR) - It is a software quality control activity performed by
software engineers.

Objectives of formal technical review (FTR): Some of these are:

 Useful to uncover error in logic, function and implementation for any

representation of the software.
 The purpose of FTR is to verify that the software meets specified requirements.
 To ensure that software is represented according to predefined standards.
 It helps to review the uniformity in software that is development in a uniform
manner.
 To makes the project more manageable.
 In addition, the purpose of FTR is to enable junior engineer to observe the
analysis, design, coding and testing approach more closely.
 FTR also works to promote back up and continuity become familiar with parts of
software they might not have seen otherwise.
  Actually, FTR is a class of reviews that include walkthroughs, inspections, round
robin reviews and other small group technical assessments of software. Each FTR
is conducted as meeting and is considered successful only if it is properly
planned, controlled and attended.

Example: suppose during the development of the software without FTR design cost 10
units, coding cost 15 units and testing cost 10 units then the total cost till now is 35 units
without maintenance but there was a quality issue because of bad design so to fix it we
have to re-design the software and final cost will become 70 units. That is why FTR is so
helpful while developing the software.

 The review meeting: Each review meeting should be held considering the following
constraints- Involvement of people:

1. Between 3, 4 and 5 people should be involved in the review.

2. Advance preparation should occur but it should be very short that is at the most 2
hours of work for every person.
3. The short duration of the review meeting should be less than two hour. Gives these
constraints, it should be clear that an FTR focuses on specific (and small) part of the
overall software.

At the end of the review, all attendees of FTR must decide what to do.

 Accept the product without any modification.

 Reject the project due to serious error (Once corrected, another app need to be
reviewed), or
 Accept the product provisional (minor errors are encountered and should be
corrected, but no additional review will be required).

The decision was made, with all FTR attendees completing a sign-of indicating
their participation in the review and their agreement with the findings of the
review team.

 Review reporting and record keeping:-

1. During the FTR, the reviewer actively records all issues that have been raised.
2. At the end of the meeting all these issues raised are consolidated and a review list is
prepared.
3. Finally, a formal technical review summary report is prepared.
 Review guidelines: - Guidelines for the conducting of formal technical reviews should be
established in advance. These guidelines must be distributed to all reviewers, agreed
upon, and then followed. A review that is unregistered can often be worse than a review
that does not minimum set of guidelines for FTR.

 Review the product, not the manufacture (producer).

 Take written notes (record purpose)
 Limit the number of participants and insists upon advance preparation.
 Develop a checklist for each product that is likely to be reviewed.
 Allocate resources and time schedule for FTRs in order to maintain time schedule.
 Conduct meaningful training for all reviewers in order to make reviews effective.
 Reviews earlier reviews which serve as the base for the current review being
conducted.
 Set an agenda and maintain it.
 Separate the problem areas, but do not attempt to solve every problem notes.
 Limit debate and rebuttal.

Walkthrough-
 It is the review meeting process (non formal meeting) where the code is read by the
author and others who are present in the meeting can note down the important points and
can give suggestions about them. The walkthrough is an informal way of testing, no
formal authority is been involved in this testing.
 The walkthrough is a review meeting process but it is different from the Inspection, as it
does not involve any formal process i.e. it is a nonformal process. Basically, the
walkthrough [review meeting process] is started by the Author of the code.
 It is an informal way of testing involved so there is no need for a moderator while
performing a walkthrough. We can call a walkthrough an open-ended discussion; it does
not focus on the documentation. Defect tracking is one of the challenging tasks in the
walkthrough.
 Advantages and Objectives of Walkthrough:
Following are some of the objectives of the walkthrough.
 To detect defects in developed software products.
 To fully understand and learn the development of software products.
 To properly explain and discuss the information present in the document.
 To verify the validity of the proposed system.
 To give suggestions and report them appropriately with new solutions and ideas.
 To provide an early “proof of concept”.

Types of Review:
 Walkthrough
 Technical review
 Inspection
Technical Review:

The technical review is a less formal way of reviewing a meeting process. It is process which is
performed to give assurance about software quality. In Technical review process, the testing
activity is performed by software engineers and other persons.

Here a work product is been inspected and reviewed for defects and other errors by individuals
rather than the person who have produced it. The technical review is performed as a peer review
without any management involved. So in context, the technical review varies from informal to
quite formal.

Objectives of Technical Review:

Following are some of the objectives of Technical Review.

 To create more reliable and manageable project.
 To find technical error and defects.
 To inform participants who have participated in technical review, about the technical
content of document.
 To maintain consistency of technical concepts.
 To ensure that the software fulfils the requirements for which it is built.

Inspection:

Inspection is a more formal way of reviewing a meeting process. In inspection the documents are
checked thoroughly and reviewed by reviewers before the meeting. it basically involves peers to
examine the product or software.

A preparation is been carried out separately in which the product is been examined properly and
scanned for any defects or errors. The process of inspection is led and done by trained
moderators. A formal follow up is carried out by these trained moderators. Inspection is been
done to improve the product quality more efficiently.

Objectives of Inspection:

Following are some of the objectives of Inspection.

 To efficiently improve the quality of a software or product.
 To create common understanding between individuals who are been involved in the inspection.
 To remove defects and errors as early as possible.
 To learn and improve from defects which are been found during inspection.
 Helping author to improve and increase the quality of product which is been developed.