B.SC.

(COMPUTER SCIENCE)
SEM – V

UNIT III – CHAP 7

SOFTWARE QUALITY ASSURANCE

Trupti Wani Note: This PPT is used only for educational purpose
• Software Quality Management is a process that ensures the required level of
software quality is achieved when it reaches the users, so that they are satisfied
by its performance. The process involves quality assurance, quality planning,
and quality control.

• Quality software refers to a software which is reasonably bug or defect free, is

delivered in time and within the specified budget, meets the requirements
and/or expectations, and is maintainable. In the software engineering context,
software quality reflects both functional quality as well as structural quality.
•Software Functional Quality − It reflects how well it satisfies a given design, based on the functional
requirements or specifications.
•Software Structural Quality − It deals with the handling of non-functional requirements that support
the delivery of the functional requirements, such as robustness or maintainability, and the degree to
which the software was produced correctly.
•Software Quality Assurance − Software Quality Assurance (SQA) is a set of activities to ensure the
quality in software engineering processes that ultimately result in quality software products. The
activities establish and evaluate the processes that produce products. It involves process-focused
action.
•Software Quality Control − Software Quality Control (SQC) is a set of activities to ensure the quality
in software products. These activities focus on determining the defects in the actual products
produced. It involves product-focused action.
Importance of Quality

We would expect the quality to be a concern of all producers of goods and services. However,
the distinctive characteristics of software and in particular its intangibility and complexity,
make special demands.
Increasing criticality of software: The final customer or user is naturally concerned about
the general quality of software, especially its reliability. This is increasing in the case as
organizations become more dependent on their computer systems and software is used more
and more in safety-critical areas. For example, to control aircraft.
The intangibility of software: This makes it challenging to know that a particular task in a
project has been completed satisfactorily. The results of these tasks can be made tangible by
demanding that the developers produce 'deliverables' that can be examined for quality.
Accumulating errors during software development: As computer system development
is made up of several steps where the output from one level is input to the next, the errors
in the earlier ?deliverables? will be added to those in the later stages leading to accumulated
determinable effects. In general the later in a project that an error is found, the more
expensive it will be to fix. In addition, because the number of errors in the system is
unknown, the debugging phases of a project are particularly challenging to control.
 Characteristics of Quality

When we examine an item based on its measurable characteristics, two kinds of quality
may be encountered: quality of design and quality of conformance.
Quality of design refers to the characteristics that designers specify for an item. The grade
of materials, tolerances, and performance specifications all contribute to the quality of
design. As higher-grade materials are used, tighter tolerances and greater levels of
performance are specified, the design quality of a product increases, if the product is
manufactured according to specifications.

Quality of conformance is the degree to which the design specifications are followed
during manufacturing. Again, the greater the degree of conformance, the higher is the level
of quality of conformance. In software development, quality of design encompasses
requirements, specifications, and the design of the system. Quality of conformance is an
issue focused primarily on implementation. If the implementation follows the design and
the resulting system meets its requirements and performance goals, conformance quality is
high
In software development, quality of design encompasses requirements, specifications, and the design of the
system.

Quality of conformance is an issue focused primarily on implementation. If the implementation follows the
design and the resulting system meets its requirements and performance goals, conformance quality is high
Quality Control
Variation control may be equated to quality control. But how do we achieve quality control? Quality
control involves the series of inspections, reviews, and tests used throughout the software process to
ensure each work product meets the requirements placed upon it. Quality control includes a feedback loop
to the process that created the work product. The combination of measurement and feedback allows us to
tune the process when the work products created fail to meet their specifications. This approach views
quality control as part of the manufacturing process. Quality control activities may be fully automated,
entirely manual, or a combination of automated tools and human interaction. 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 feedback loop is essential to minimize the defects produced.
Quality Assurance
Quality assurance consists of the auditing and reporting functions of management. The goal of quality
assurance is to provide management with the data necessary to be informed about product quality, thereby
gaining insight and confidence that product quality is meeting its goals. Of course, if the data provided
through quality assurance identify problems, it is management’s responsibility to address the problems and
apply the necessary resources to resolve quality issues.
Cost of Quality

The cost of quality includes all costs incurred in the pursuit of quality or in performing
quality-related activities. Cost of quality studies are conducted to provide a base- line for the
current cost of quality, identify opportunities for reducing the cost of quality, and provide a
normalized basis of comparison. The basis of normalization is almost always dollars. Once we
have normalized quality costs on a dollar basis, we have the necessary data to evaluate where
the opportunities lie to improve our processes. Furthermore, we can evaluate the effect of
changes in dollar-based terms. Quality costs may be divided into
costs associated with prevention,
appraisal, and
failure.

Prevention costs include

• quality planning
• formal technical reviews
• test equipment
•training
Appraisal costs include activities to gain insight into product condition the “first time
through” each process.
Examples of appraisal costs include
• in-process and interprocess inspection
• equipment calibration and maintenance
• testing

Failure costs are those that would disappear if no defects appeared before shipping a
product to customers. Failure costs may be subdivided into internal failure costs and
external failure costs.
Internal failure costs are incurred when we detect a defect in our product prior to
shipment. Internal failure costs include
• rework
• repair
• failure mode analysis

External failure costs are associated with defects found after the product has been
shipped to the customer. Examples of external failure costs are
• complaint resolution
• product return and replacement
• help line support
• warranty work
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.

SQA Encompasses
•A quality management approach
•Effective Software engineering technology (methods and tools)
•Formal technical reviews that are tested throughout the software process
•A multitier testing strategy
•Control of software documentation and the changes made to it.
•A procedure to ensure compliances with software development standards
•Measuring and reporting mechanisms.
SQA Activities

Software quality assurance is composed of a variety of functions associated with two different
constituencies ? the software engineers who do technical work and an SQA group that has
responsibility for quality assurance planning, record keeping, analysis, and reporting.

Following activities are performed by an independent SQA group:

1.Prepares an SQA plan for a project: The program is developed during project planning and
is reviewed by all stakeholders. The plan governs quality assurance activities performed by the
software engineering team and the SQA group. The plan identifies calculation to be performed,
audits and reviews to be performed, standards that apply to the project, techniques for error
reporting and tracking, documents to be produced by the SQA team, and amount of feedback
provided to the software project team.
2.Participates in the development of the project's software process description: The
software team selects a process for the work to be performed. The SQA group reviews the
process description for compliance with organizational policy, internal software standards,
externally imposed standards (e.g. ISO-9001), and other parts of the software project plan.
3. Reviews software engineering activities to verify compliance with the
defined software process: The SQA group identifies, reports, and tracks deviations
from the process and verifies that corrections have been made.

4. Audits designated software work products to verify compliance with those

defined as a part of the software process: The SQA group reviews selected work
products, identifies, documents and tracks deviations, verify that corrections have been
made, and periodically reports the results of its work to the project manager.

5. Ensures that deviations in software work and work products are

documented and handled according to a documented procedure: Deviations may
be encountered in the project method, process description, applicable standards, or
technical work products.

6. Records any noncompliance and reports to senior management: Non-

compliance items are tracked until they are resolved.
Benefits of Software Quality Assurance (SQA):
1.SQA produce 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 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.

Disadvantage of SQA:
There are a number of disadvantages of quality assurance. Some of them include adding more
resources, employing more workers to help maintain quality and so much more.
SQA plan :

Software quality assurance encompasses a broad range of concerns and activities that focus on the
management of software quality. These can be summarized in the following manner [Hor03]:

Standards
The IEEE, ISO, and other standards organizations have produced a broad array of software engineering
standards and related documents. Standards may be adopted voluntarily by a software engineering
organization or imposed by the customer or other stakeholders. The job of SQA is to ensure that standards
that have been adopted are followed and that all work products conform to them.

Reviews and audits

reviews are a quality control activity performed by software engineers for software engineers. Their intent is
to uncover errors. Audits are a type of review performed by SQA personnel with the intent of ensuring that
quality guidelines are being followed for software engineering work. For example, an audit of the review
process might be conducted to ensure that reviews are being performed in a manner that will lead to the
highest likelihood of uncovering errors.
Testing
Software testing is a quality control function that has one primary goal—to find errors. The job of SQA is to ensure
that testing is properly planned and efficiently conducted so that it has the highest likelihood of achieving its primary
goal.

Error/defect collection and analysis

The only way to improve is to measure how you’re doing. SQA collects and analyzes error and defect data to better
understand how errors are introduced and what software engineering activities are best suited to eliminating them.

Change management
Change is one of the most disruptive aspects of any software project. If it is not properly managed, change can lead
to confusion, and confusion almost always leads to poor quality. SQA ensures that adequate change management
practices have been instituted.
Education
Every software organization wants to improve its software engineering practices. A key contributor to
improvement is education of software engineers, their managers, and other stakeholders. The SQA organization
takes the lead in software process improvement and is a key proponent and sponsor of educational programs.
Vendor management
Three categories of software are acquired from external software vendors—shrink-wrapped packages (e.g.,
Microsoft Office), a tailored shell [Hor03] that provides a basic skeletal structure that is custom tailored to the
needs of a purchaser, and contracted software that is custom designed and constructed from specifications provided
by the customer organization. The job of the SQA organization is to ensure that high-quality software results by
suggesting specific quality practices that the vendor should follow (when possible), and incorporating quality
mandates as part of any contract with an external vendor.

Security management
With the increase in cyber crime and new government regulations regarding privacy, every software organization
should institute policies that protect data at all levels, establish firewall protection for WebApps, and ensure that
software has not been tampered with internally. SQA ensures that appropriate process and technology are used to
achieve software security.
Safety
Because software is almost always a pivotal component of humanrated systems (e.g., automotive or aircraft
applications), the impact of hidden defects can be catastrophic. SQA may be responsible for assessing the
impact of software failure and for initiating those steps required to reduce risk.

Risk management
Although the analysis and mitigation of risk is the concern of software engineers, the SQA organization
ensures that risk management activities are properly conducted and that risk-related contingency plans have
been established.
SOFTWARE REVIEWS

Software reviews are a "filter" for the software engineering process. That is, reviews are applied at various
points during software development and serve to uncover errors and defects that can then be removed. Software
reviews "purify" the software engineering activities that we have called analysis, design, and coding. A review—
any review—is a way of using the diversity of a group of people to: 1. Point out needed improvements in the
product of a single person or team; 2. Confirm those parts of a product in which improvement is either not
desired or not needed; 3. Achieve technical work of more uniform, or at least more predictable, quality than can
be achieved without reviews, in order to make technical work more manageable. Many different types of
reviews can be conducted as part of software engineering. Each has its place. An informal meeting around the
coffee machine is a form of review, if technical problems are discussed. A formal presentation of software design
to an audience of customers, management, and technical staff is also a form of review. In this book, however, we
focus on the formal technical review, sometimes called a walkthrough or an inspection. A formal technical
review is the most effective filter from a quality assurance standpoint. Conducted by software engineers (and
others) for software engineers, the FTR is an effective means for improving software quality.
Review Guidelines

Guidelines for the conduct of formal technical reviews must be established in advance, distributed to all
reviewers, agreed upon, and then followed. A review that is uncontrolled can often be worse that no
review at all. The following represents a minimum set of guidelines for formal technical reviews:
1. Review the product, not the producer. An FTR involves people and egos. Conducted properly, the
FTR should leave all participants with a warm feeling of accomplishment. Conducted improperly,
the FTR can take on the aura of an inquisition. Errors should be pointed out gently; the tone of the
meeting should be loose and constructive; the intent should not be to embarrass or belittle. The
review leader should conduct the review meeting to ensure that the proper tone and attitude are
maintained and should immediately halt a review that has gotten out of control.
2. Set an agenda and maintain it. One of the key maladies of meetings of all types is drift. An FTR must
be kept on track and on schedule. The review leader is chartered with the responsibility for
maintaining the meeting schedule and should not be afraid to nudge people when drift sets in.
3. Limit debate and rebuttal. When an issue is raised by a reviewer, there may not be universal
agreement on its impact. Rather than spending time debating the question, the issue should be
recorded for further discussion off-line
4. Enunciate problem areas, but don't attempt to solve every problem noted. A review is not a problem-
solving session. The solution of a problem can often be accomplished by the producer alone or with the
help of only one other individual. Problem solving should be postponed until after the review meeting.
5. Take written notes. It is sometimes a good idea for the recorder to make notes on a wall board, so that
wording and priorities can be assessed by other reviewers as information is recorded.
6. Limit the number of participants and insist upon advance preparation. Two heads are better than one,
but 14 are not necessarily better than 4. Keep the number of people involved to the necessary minimum.
However, all review team members must prepare in advance. Written comments should be solicited by the
review leader (providing an indication that the reviewer has reviewed the material).
7. Develop a checklist for each product that is likely to be reviewed. A checklist helps the review leader to
structure the FTR meeting and helps each reviewer to focus on important issues. Checklists should be
developed for analysis, design, code, and even test documents.
8. Allocate resources and schedule time for FTRs. For reviews to be effective, they should be scheduled as
a task during the software engineering process. In addition, time should be scheduled for the inevitable
modifications that will occur as the result of an FTR.
9. Conduct meaningful training for all reviewers. To be effective all review participants
should receive some formal training. The training should stress both process-related issues
and the human psychological side of reviews. Freedman and Weinberg [FRE90] estimate
a one-month learning curve for every 20 people who are to participate effectively in
reviews.

10. Review your early reviews. Debriefing can be beneficial in uncovering problems with
the review process itself. The very first product to be reviewed should be the review
guidelines themselves.
STATISTICAL SOFTWARE QUALITY ASSURANCE

Statistical quality assurance reflects a growing trend throughout industry to become more quantitative about
quality. For software, statistical quality assurance implies the following steps:

1. Information about software defects is collected and categorized.

2. An attempt is made to trace each defect to its underlying cause (e.g., nonconformance to specifications, design
error, violation of standards, poor communication with the customer).
3. Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all possible causes), isolate
the 20 percent (the "vital few").
4. Once the vital few causes have been identified, move to correct the problems that have caused the defects.
This relatively simple concept represents an important step towards the creation of an adaptive software
engineering process in which changes are made to improve those elements of the process that introduce error.
To illustrate this, assume that a software engineering organization collects information on defects for
a period of one year. Some of the defects are uncovered as software is being developed. Others are
encountered after the software has been released to its end-users. Although hundreds of different
errors are uncovered, all can be tracked to one (or more) of the following causes:
• incomplete or erroneous specifications (IES)
• misinterpretation of customer communication (MCC)
• intentional deviation from specifications (IDS)
• violation of programming standards (VPS)
• error in data representation (EDR)
• inconsistent component interface (ICI)
• error in design logic (EDL)
• incomplete or erroneous testing (IET)
• inaccurate or incomplete documentation (IID)
• error in programming language translation of design (PLT)
• ambiguous or inconsistent human/computer interface (HCI)
• miscellaneous (MIS)
SOFTWARE RELIABILITY

There is no doubt that the reliability of a computer program is an important element of its
overall quality. If a program repeatedly and frequently fails to perform, it matters little whether
other software quality factors are acceptable. Software reliability, unlike many other quality
factors, can be measured directed and estimated using historical and developmental data.
Software reliability is defined in statistical terms as "the probability of failure-free operation of
a computer program in a specified environment for a specified time" [MUS87]. To illustrate,
program X is estimated to have a reliability of 0.96 over eight elapsed processing hours. In
other words, if program X were to be executed 100 times and require eight hours of elapsed
processing time (execution time), it is likely to operate correctly (without failure) 96 times out
of 100.
If we consider a computer-based system, a simple measure of reliability is meantime
between-failure (MTBF),
where MTBF = MTTF + MTTR

The acronyms MTTF and MTTR are mean-time-to-failure and mean-time-to-repair,

Respectively In addition to a reliability measure, we must develop a measure of availability.
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%

The MTBF reliability measure is equally sensitive to MTTF and MTTR. The availability
measure is somewhat more sensitive to MTTR, an indirect measure of the maintainability of
software.
Six Sigma for Software Engineering

Six Sigma is the most widely used strategy for statistical quality assurance in industry today.
Originally popularized by Motorola in the 1980s, the Six Sigma strategy “is a rigorous and
disciplined methodology that uses data and statistical analysis to measure and improve a company’s
operational performance by identifying and eliminating defects’ in manufacturing and service-related
processes” [ISI08]. The term Six Sigma is derived from six standard deviations—3.4 instances
(defects) per million occurrences—implying an extremely high quality standard.
The Six Sigma methodology defines three core steps:
• Define customer requirements and deliverables and project goals via welldefined methods of
customer communication.
• Measure the existing process and its output to determine current quality performance (collect defect
metrics).
• 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: • Improve the process by eliminating the root causes of
defects.
• Control the process to ensure that future work does not reintroduce the causes of defects.
These core and additional steps are sometimes referred to as the DMAIC (define, measure,
analyze, improve, and control) method. If an organization is developing a software process
(rather than improving an existing process), the core steps are augmented as follows:
• Design the process to (1) avoid the root causes of defects and (2) to meet customer
requirements.
• Verify that the process model will, in fact, avoid defects and meet customer requirements.
This variation is sometimes called the DMADV (define, measure, analyze, design, and verify)
method.
THE ISO 9000 QUALITY STANDARDS

A quality assurance system may be defined as the organizational structure, responsibilities, procedures, processes,
and resources for implementing quality management [ANS87]. Quality assurance systems are created to help
organizations ensure their products and services satisfy customer expectations by meeting their specifications.
These systems cover a wide variety of activities encompassing a product’s entire life cycle including planning,
controlling, measuring, testing and reporting, and improving quality levels throughout the development and
manufacturing process. ISO 9000 describes quality assurance elements in generic terms that can be applied to any
business regardless of the products or services offered. To become registered to one of the quality assurance system
models contained in ISO 9000, a company’s quality system and operations are scrutinized by third-party auditors
for compliance to the standard and for effective operation. Upon successful registration, a company is issued a
certificate from a registration body represented by the auditors. Semiannual surveillance audits ensure continued
compliance to the standard. The requirements delineated by ISO 9001:2000 address topics such as management
responsibility, quality system, contract review, design control, document and data control, product identification and
traceability, process control, inspection and testing, corrective and preventive action, control of quality records,
internal quality audits, training, servicing, and statistical techniques.
In order for a software organization to become registered to ISO 9001:2000, it must establish policies and
procedures to address each of the requirements just noted (and others) and then be able to demonstrate that these
policies and procedures are being followed.
 a nk yo u
T h