Software Engineering and Project Management.

Unit-V: Software quality, risk and Plan.

Software Quality
For software products, the fitness of use is generally explained in terms of
satisfaction of the requirements laid down in the SRS document.
Example: Consider a functionally correct software product. That is, it
performs all tasks as specified in the SRS document. But, has an almost unusable
user interface. Even though it may be functionally right, we cannot consider it to
be a quality product.
The modern view of a quality associated with a software product
several quality methods such as the following:
1. Portability: This refers to the ease with which software can be adapted
to run in different environments. A portable software can function
seamlessly on various operating systems, hardware platforms, and with
different software configurations. This adaptability is crucial for
widespread deployment and user accessibility.
2. Usability: Usability focuses on how easy it is for users to interact with
and understand the software. A user-friendly interface, clear instructions,
and intuitive navigation contribute to high usability. This characteristic is
essential for user adoption and satisfaction.
3. Reusability: Reusability refers to the ability to reuse software
components or modules in other projects. This can significantly reduce
development time and effort by leveraging existing code and design
patterns. Well-designed software with high reusability promotes
modularity and efficiency.
4. Correctness: Correctness ensures that the software functions as
intended and meets all the specified requirements. It involves thorough
testing and validation to identify and rectify any errors or discrepancies.
A correct software provides reliable and accurate results, which is critical
for its credibility and user trust.
5. Maintainability: Maintainability refers to the ease with which software
can be modified, updated, or fixed. This includes the ability to add new
features, correct bugs, and adapt to changing requirements. A
maintainable software has a well-structured design, clear documentation,
 and modular architecture, making it easier to manage and evolve over
time.
6. Reliability: Reliability refers to the consistency and dependability of the
software. A reliable software performs its intended functions without
failures or unexpected errors. This is achieved through robust design,
rigorous testing, and effective error handling mechanisms.
7. Efficiency: Efficiency refers to the optimal use of system resources, such
as CPU, memory, and storage. An efficient software minimizes resource
consumption, leading to faster execution, improved performance, and
reduced costs.
8. Functionality: The capability to provide function which meet stated and
implied needs when the software is used.

Software Quality Management System

A quality management system is the principal methods used by organizations to
provide that the products they develop have the desired quality.
A quality system subsists of the following:
Managerial Structure and Individual Responsibilities: A quality system is
the responsibility of the organization as a whole. However, every organization
has a sever quality department to perform various quality system activities.
The quality system of an arrangement should have the support of the top
management. Without help for the quality system at a high level in a company,
some members of staff will take the quality system seriously.
Quality System Activities: The quality system activities encompass the
following:
• Auditing of projects
• Review of the quality system
• Development of standards, methods, and guidelines, etc.
• Production of documents for the top management summarizing the
effectiveness of the quality system in the organization.
Approach To Quality Management
To produce high quality software, the final software should have as few defects
as possible. The task of quality management is to plan suitable quality control
activities, and properly execute and control these activities such that most of
the defects are detected “in-process”, that is, before the software is delivered.
There are two approaches to quality management – the procedural approach
and the quantitative approach.

Procedural Approach to Quality Management:

• In the procedural approach for quality management, procedures and
guidelines for the review and testing activities are established.
• In a project, these activities are planned, and during execution, they are
executed following the defined procedures.
• The procedural approach to defect removal does not allow claims to be
made about what percentage of defects have been removed, or the quality
of the software after performing the procedure.
• It also does not provide quantitative means for a project manager to assess
and manage the quality of the software being produced – the only factor
visible to the manager is whether the quality control tasks are executed
or not.
• procedural approach to quality management is expected from a level 3
organization by the Capability Maturity.

Quantitative Approach to Quality Management:

• A quantitative approach goes beyond asking “has the method been
executed” and looks at defect data to evaluate the effectiveness of the
quality control activities and whether more testing or reviews need to be
done.
• There are two key aspects to quantitative quality management
– setting a quantitative quality goal, and then managing the software
development process quantitatively so that the quality goal is met.

• Managing the process quantitatively requires that intermediate goals are

set for different stages in the project, which if met during the actual
project execution, will ensure that the quality goal is met. These
 intermediate goals can then be used for quantitatively monitoring the
execution of the project.

• Proper quantitative quality management is what is expected at level 4 of

the CMM.

Quantitative Quality Management Planning

Quantitative Quality Management ensures the quality of a project by providing
early warning signs during execution, allowing timely intervention. Unlike
traditional methods, it focuses on predicting key parameters at different stages
of the project and controlling them to meet the desired quality standards.
By comparing predicted values with actual data during execution, this approach
ensures not only the completion of processes but also their effectiveness in
achieving the full potential of quality control activities.
A key element of this approach is defect prediction. The quality goal is set in
terms of delivered defect density, and intermediate goals are established by
estimating defect levels at various stages. These estimates guide the project
execution, ensuring that if the predicted defect levels are achieved, the target
quality is met.
Infosys implements this approach by leveraging historical data from its Process
Database (PDB) and Process Capability Baseline (PCB). The PDB provides
summary data for completed projects, while the PCB contains averages and
ranges for process characteristics such as defect injection rates and defect
removal efficiency. This data, collected over six years, enables accurate defect
prediction and better-quality control.
To enhance control, Statistical Process Control (SPC) is applied to defect
detection activities like reviews and unit testing, which identify most of the
defects. SPC establishes control limits for parameters such as defect density and
coverage rate, allowing for real-time corrective actions. While phase-wise
control provides a broader view of progress, SPC ensures micro-level control,
enabling issues to be addressed promptly.
Infosys also fosters a culture of rigorous data collection and reporting, involving
all team members, including senior executives. Tools are used for recording
efforts and defects, with over 250 data points gathered from completed projects.
These practices support consistent quality management by combining defect
prediction, process monitoring, and data-driven decision-making, ultimately
ensuring that the project achieves its quality objectives.

In this Approach:
• The quality goal is set in terms of delivered defect density.
• Intermediate goals are set by estimating the number of defects that may
be identified by various defect detection activities.
• Then the actual number of defects are compared to the estimated defect
levels.
The effectiveness of this approach depends on how well can we predict the
defect levels at different stages of the project. At Infosys, defect patterns
observed in past projects are used for predicting defect levels.

Setting a Quality Goal:

The quality goal for a project is the number of defects the project expects to
deliver. That is, the quality goal is the expected number of defects during
acceptance testing.
There are two primary sources of past data which may be used for setting the
quality goal –
• Past data on similar projects
• Data from the PCB.
If data of similar projects is used, then the number of defects found during
acceptance testing of this project can be estimated as the product of number of
defects found during acceptance testing of the similar projects and the ratio of
the estimated effort for this project and the total effort of the similar projects.
Concept of Risk and Risk Management

Risk:
• A risk is an uncertain event or condition that if it occurs has a positive or
negative effect on a project’s objective.
• A "risk" is a problem that could cause some loss or threaten the progress
of the project, but which has not happened yet.
• These potential issues might harm cost, schedule or technical success of
the project and the quality of our software device, or project team morale.
• A risk is a probable problem; it might happen, or it might not. There are
main two characteristics of risk.
o Uncertainty
o Loss
• A risk is a probabilistic event—it may or may not occur. In software
development process the risk items are:
o Personnel Shortfalls
o Unrealistic Schedules and Budgets
o Developing the Wrong Software Functions
o Developing the Wrong User Interface
o Continuing Stream of Requirement Changes
Risk Management:
Risk Management is the system of identifying addressing and eliminating these
problems before they can damage the project.
Risk management is an attempt to minimize the chances of failure caused by
unplanned events. The aim of risk management is not to avoid getting into
projects that have risks but to minimize the impact of risks in the projects that
are undertaken.
Risk Management is a systematic process of recognizing, evaluating, and handling
threats or risks that have an effect on the finances, capital, and overall operations
of an organization. These risks can come from different areas, such as financial
instability, legal issues, errors in strategic planning, accidents, and natural
disasters.
Risk Management Concepts
• Risk is defined as an exposure to the chance of injury or loss. That is, risk
implies that there is a possibility that something negative may happen.
• In the context of software projects, negative implies that there is an
adverse effect on cost, quality, or schedule.
• Risk management is the area that tries to ensure that the impact of risks
on cost, quality, and schedule is minimal.

The risk management activities:

Risk Assessment
• Risk assessment is an activity that must be undertaken during project
planning. This involves identifying the risks, analyzing them, and prioritizing
them on the basis of the analysis.
• The goal of risk assessment is to prioritize the risks so that attention and
resources can be focused on the riskier items.

Following important point have been observed about the risk assessment:
1. Risk identification
• Risk identification is the first step in risk assessment, which identifies
all the different risks for a particular project.
• These risks are project-dependent and identifying them is an
exercise in envisioning what can go wrong.
• Methods that can aid risk identification include checklists of possible
risks, surveys, meetings and brainstorming, and reviews of plans,
processes, and work products.
 • Based on surveys of experienced project managers, Boehm has
produced a list of the top 5 risk items likely to compromise the
success of a software project are :
1. Personnel Shortfalls
2. Unrealistic Schedules and Budgets
3. Developing the Wrong Software Functions
4. Developing the Wrong User Interface
5. Continuing Stream of Requirement Changes

2. Risk Analysis
Risk identification merely identifies the undesirable events that might take
place during the project, i.e., detail the "unforeseen" events that might
occur. It does not specify the probabilities of these risks appearance nor
the impact on the project if the risks really appear. Hence the next tasks
are risk analysis and prioritization.

In risk analysis, the probability of occurrence of a risk has to be estimated,

along with the loss that will occur if the risk does appear. This is often
done through discussion, using experience and understanding of the
situation. but, if cost models are used for cost and schedule estimation,
then the same models can be used to assess the cost and schedule risk.

3. Risk Prioritization
Once the probabilities of risks appear and losses due to appearance of
different risks have been analyzed, they can be prioritized. One approach
for prioritization is through the concept of risk exposure (RE), which is
sometimes called risk impact. RE is defined by the relationship

RE = Prob{UO) * Loss{UO)

Risk Control
Risk control activity consists of risk resolution (management plan) and
monitoring management as discussed as follows:
1. Risk Resolution (Risk Management Plan):
The main objective of risk management is to identify the top few risk items
and then focus on them. Once a project manager has identified and
prioritized the risks, the top risks can be easily identified and may
determine (resolute) which risk event has high risk and have to control
first.

Risk Mitigation Steps: For most risks, the strategy is to perform the
actions that will either reduce the probability of the risk appearing or
reduce the loss due to the risk appearing. These are called risk mitigation
steps.

With these ratings, the following simple method for risk prioritization can
be specified:

o For each risk, rate the probability of its happening as low, medium,
or high.
o For each risk, assess its impact on the project as low, medium, or
high.
o Rank the risks based on the probability and effects on the project;
for example, a high-probability, high-impact item will have higher
rank than a risk item with a medium probability and high impact. In
case of conflict, use judgment.
o Select the top few risk items for mitigation and tracking.

2. Risk Monitoring
Risk monitoring involves continuously tracking and overseeing identified
risks to assess their status, changes, and effectiveness of mitigation
strategies. It ensures that risks are regularly reviewed and managed to
maintain alignment with organizational objectives and adapt to new
developments or challenges.
TYPES OF RISK
There are mainly 3 classes of risks that may affect a computer code project:

1. Project Risks:
• Project risks concern various sorts of monetary funds, schedules,
personnel, resources, and customer-related issues.
• A vital project risk is schedule slippage. Since computer code is
intangible, it’s tough to observe and manage a computer code
project.
• It’s tough to manage one thing that cannot be seen.

2. Technical Risks:
• Technical risks concern potential style, implementation, interfacing,
testing, and maintenance issues.
• Technical risks conjointly embody ambiguous specifications,
incomplete specifications, dynamic specifications, technical
uncertainty, and technical degeneration.
• Most technical risks occur thanks to the event team’s lean
information concerning the project.

3. Business Risks:
• This type of risk embodies the risks of building a superb product
that nobody needs, losing monetary funds or personal
commitments, etc.