UNIT 4

SOFTWARE QUALITY

Software Quality

Software quality product is defined in term of its fitness of purpose. That is, a quality product
does precisely what the users want it to do. For software products, the fitness of use is
generally explained in terms of satisfaction of the requirements laid down in the SRS
document. Although "fitness of purpose" is a satisfactory interpretation of quality for many
devices such as a car, a table fan, a grinding machine, etc.for software products, "fitness of
purpose" is not a wholly satisfactory definition of quality.

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:

Portability: A software device is said to be portable, if it can be freely made to work in

various operating system environments, in multiple machines, with other software products,
etc.

Usability: A software product has better usability if various categories of users can easily
invoke the functions of the product.

Reusability: A software product has excellent reusability if different modules of the product
can quickly be reused to develop new products.

Correctness: A software product is correct if various requirements as specified in the SRS

document have been correctly implemented.

Maintainability: A software product is maintainable if bugs can be easily corrected as and

when they show up, new tasks can be easily added to the product, and the functionalities of
the product can be easily modified, etc.

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.

Evolution of Quality Management System

Quality systems have increasingly evolved over the last five decades. Before World War II,
the usual function to produce quality products was to inspect the finished products to remove
defective devices. Since that time, quality systems of organizations have undergone through
four steps of evolution, as shown in the fig. The first product inspection task gave method to
quality control (QC).

Quality control target not only on detecting the defective devices and removes them but also
on determining the causes behind the defects. Thus, quality control aims at correcting the
reasons for bugs and not just rejecting the products. The next breakthrough in quality
methods was the development of quality assurance methods.

The primary premise of modern quality assurance is that if an organization's processes are
proper and are followed rigorously, then the products are obligated to be of good quality. The
new quality functions include guidance for recognizing, defining, analyzing, and improving
the production process.

Total quality management (TQM) advocates that the procedure followed by an organization
must be continuously improved through process measurements. TQM goes stages further
than quality assurance and aims at frequently process improvement. TQM goes beyond
documenting steps to optimizing them through a redesign. A term linked to TQM is Business
Process Reengineering (BPR).

BPR aims at reengineering the method business is carried out in an organization. From the
above conversation, it can be stated that over the years, the quality paradigm has changed from
product assurance to process assurance, as shown in fig.
REVIEWS: A RECOMMENDED APPROACH
Criteria for types of Reviews
Software Review is systematic inspection of a software by one or more individuals who
work together to find and resolve errors and defects in the software during the early stages
of Software Development Life Cycle (SDLC). Software review is an essential part of
Software Development Life Cycle (SDLC) that helps software engineers in validating the
quality, functionality and other vital features and components of the software. It is a whole
process that includes testing the software product and it makes sure that it meets the
requirements stated by the client.
Usually performed manually, software review is used to verify various documents like
requirements, system designs, codes, test plans and test cases.
Objectives of Software Review:
The objective of software review is:
1. To improve the productivity of the development team.
2. To make the testing process time and cost effective.
3. To make the final software with fewer defects.
4. To eliminate the inadequacies.
Process of Software Review:

Types of Software Reviews:

There are mainly 3 types of software reviews:
1. Software Peer Review:
Peer review is the process of assessing the technical content and quality of the
product and it is usually conducted by the author of the work product along with
 some other developers.
Peer review is performed in order to examine or resolve the defects in the
software, whose quality is also checked by other members of the team.
Peer Review has following types:
 (i) Code Review:
Computer source code is examined in a systematic way.
 (ii) Pair Programming:
It is a code review where two developers develop code together at the
same platform.
 (iii) Walkthrough:
Members of the development team is guided bu author and other
interested parties and the participants ask questions and make
comments about defects.
 (iv) Technical Review:
A team of highly qualified individuals examines the software product
for its client’s use and identifies technical defects from specifications
and standards.
 (v) Inspection:
In inspection the reviewers follow a well-defined process to find
defects.

2. Software Management Review:

Software Management Review evaluates the work status. In this section
decisions regarding downstream activities are taken.

3. Software Audit Review:

Software Audit Review is a type of external review in which one or more critics,
who are not a part of the development team, organize an independent inspection
of the software product and its processes to assess their compliance with stated
specifications and standards. This is done by managerial level people.
Advantages of Software Review:
 Defects can be identified earlier stage of development (especially in formal
review).
 Earlier inspection also reduces the maintenance cost of software.
 It can be used to train technical authors.
 It can be used to remove process inadequacies that encourage defects.

Formal Technical Review (FTR) in Software Engineering

Formal Technical Review (FTR) 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 observer 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 successfully only if it is properly planned, controlled and
attended.
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 involve 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.
1. Accept the product without any modification.
2. Reject the project due to serious error (Once corrected, another app need to be
reviewed), or
3. Accept the product provisional (minor errors are encountered and are 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.
It answers three questions :-
1. What was reviewed ?
2. Who reviewed it ?
3. What were the findings and conclusions ?
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.
1. Review the product, not the manufacture (producer).
2. Take written notes (record purpose)
3. Limit the number of participants and insists upon advance preparation.
4. Develop a checklist for each product that is likely to be reviewed.
 5. Allocate resources and time schedule for FTRs in order to maintain time
schedule.
6. Conduct meaningful training for all reviewers in order to make reviews
effective.
7. Reviews earlier reviews which serve as the base for the current review being
conducted.
8. Set an agenda and maintain it.
9. Separate the problem areas, but do not attempt to solve every problem notes.
10. Limit debate and rebuttal.
Agile Review

Some Agile practitioners consider peer code review an unwelcome legacy that persists from
the dark ages of waterfall development. As a result, they vehemently reject its inclusion in
Agile projects. This paper demonstrates both how code reviews reinforce the key tenets that
underlie Agile development philosophies, and also how code reviews can be conducted in a
manner that aligns perfectly with Agile processes. The fundamental principles of Agile
development are discussed at length on the Agile Manifesto web site. The essential Agile
Manifesto tenets value:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

Although Agile followers acknowledge that the concepts on the right have value, they value
the concepts on the left more. The premise is to adapt to changes in requirements, respond to
user needs faster, streamline processes, decrease development iterations, and enable higher
productivity. All this enhances business value by making development more transparent and
getting software to the market faster.

Consistently, research shows that code review produces software with fewer defects, which
aligns with the emphasis on working software. What could be more interactive than software
developers collaborating about the code and making real-time improvements? As you’ll learn
in this paper, code review fully supports Agile tenets by promoting the development of
working software, collaboration and interaction among teams, continuous attention to
technical excellence and the ability to respond to change – all while maintaining a high level
of quality.
Consider three, well-known Agile shops: Apple, Google, and Microsoft. Like most successful
companies that attest to being Agile, they enjoy high product adoption and loyal customers.
Unlike Microsoft, Apple and Google are sticklers for code review, and their product quality
reflects this added effort. Apple in particular delivers major upgrades and fixes to the market
at an impressive pace. Both companies closely tie code review to their development culture;
they “bake” code reviews into Agile sprints and iterations to identify potential defects earlier
in their cycles. At these companies, code is never “checked-in” before it is reviewed. So why
do so many software development teams resist adopting code review when industry titans
attest to its success?

For developers to be open to the notion of adopting code review in Agile environments, they
must first accept the premise that code review can be agile. Delving into principles that
underlie the Agile Manifesto provides specific evidence that code review is Agile.

Working software is the primary measure of progress. Software developers make mistakes.
Some mistakes are detected automatically by unit tests, static analysis tools, etc. Just as
professional writers rely on human editors and spell-check software to identify mistakes,
developers benefit from having other developers examine their code.

During iterations, developers devote a lot of time discussing requirements with stakeholders
and talk about the emerging design and architecture with other software developers. That’s
true even when they tend to work in isolation to actually write the code (giving developers a
reputation as introverts, at the very least). We know and accept that flaws are uncovered
during discussions of requirements, architecture, and design. The same principle applies to
the writing of the code. Code reviews not only uncover flaws, but they also offer another key
benefit prized by Agilists – the feedback is kept close to the point of creation and happens
sooner – before the code gets into the hands of either QA or customers.

Agile processes promote sustainable development. Project sponsors, developers, and users
should be able to maintain a constant pace indefinitely. That’s a tall order. To meet this
objective, Agile teams frequently practice collective code ownership. The goal here is to
invite team members to get familiar with and understand the code base.

Collective code ownership fuels sustainable development in many ways, because it:
  Transforms team member focus from “specialist” to “generalist” in certain
domains.
 Helps to eliminate delays that result when team members are out sick or on
vacation.
 Helps to establish common coding standards.
 Fosters a common “look and feel” to the code base.
 Ensures that everyone is generating detailed documentation.

Continuous attention to technical excellence and good design enhances agility. All software
developers have egos, and most are naturally curious people who enjoy learning new things.
In anticipation of code reviews, developers tend to write better code, because they know that
their reputation is on the line. No one wants to be thought of as the weak link in the chain.

An Agile Corollary: A developer who reviews another’s code can learn new tricks and
techniques; a key step in mastering any craft is to benefit from the experience of others.

The Agile Case for Code Review: Find Bugs Early and Often
The Agile methodology is grounded in a desire to deliver working software in the most
efficient manner possible. As Agilists work to achieve this goal, they generally accept that
recognizing and eradicating bugs closer to the point of inception promotes software quality.
But have these developers considered the economic impact of doing so?

A SmartBear customer set out to test exactly how much money they would have saved if the
company had peer review in a certain three-month, 10,000-line project with 10 developers.
The business tracked how many bugs were found by QA and customers in the subsequent six
months. Then they went back and had another group of developer’s peer-review the code in
question. Using metrics from previous releases of the development project, the company
knew the average cost of fixing a defect at each phase of development, so they could measure
directly how much money they would have saved if code review was used from the start.

The result: Code review would have saved more than half the cost of fixing bugs. Plus they
would have found 162 additional bugs.

Why is the effect of code review so dramatic? A lack of collaboration in the development
phase may be the culprit. With requirements and design, you always have meetings and invite
input from customers, managers, developers, and QA to synthesize a result. You do this
because mistakes in requirements or architecture are expensive and can lead to lost sales. You
then debate the relative priorities, difficulty, and long-term merits of your choices and
techniques.

Saving more than $200k: A real-world case study

Actually writing the source code, however, is a solitary activity. Since developers tend to
create code in quiet places, collaboration is limited to occasional whiteboard drawings and a
few shared interfaces. No one catches the obvious bugs; no one is making sure the
documentation matches the code. Peer code review puts the collaborative element back into
this phase of the software development process.
Software Quality Assurance

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.

Software Quality: Software Quality is defined as the conformance to explicitly state

functional and performance requirements, explicitly documented development standards, and
inherent characteristics that are expected of all professionally developed software.

Quality Control: Quality Control involves a series of inspections, reviews, and tests used
throughout the software process to ensure each work product meets the requirements place
upon it. Quality control includes a feedback loop to the process that created the work product.

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

Quality Assurance focuses on how the engineering and management activity will be done?

As anyone is interested in the quality of the final product, it should be assured that we are
building the right product.

It can be assured only when we do inspection & review of intermediate products, if there are
any bugs, then it is debugged. This quality can be enhanced.
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.

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
o A quality management approach
o Effective Software engineering technology (methods and tools)
o Formal technical reviews that are tested throughout the software process
o A multitier testing strategy
o Control of software documentation and the changes made to it.
o A procedure to ensure compliances with software development standards
o 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.

Quality Assurance v/s Quality control

Quality Assurance Quality Control

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

QA helps establish process QC relates to a particular product or service

QA sets up a measurement program to evaluate QC verified whether particular attributes

processes exist, or do not exist, in a explicit product or
service.

QA identifies weakness in processes and improves QC identifies defects for the primary goals
them of correcting errors.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Verification is an example of QA. Validation is an example of QC.

Components of SQA System

An SQA system always combines a wide range of SQA components. These components can
be classified into the following six classes −
Pre-project components
This assures that the project commitments have been clearly defined considering the resources
required, the schedule and budget; and the development and quality plans have been correctly
determined.
Components of project life cycle activities assessment
The project life cycle is composed of two stages: the development life cycle stage and the
operation–maintenance stage.
The development life cycle stage components detect design and programming errors. Its
components are divided into the following sub-classes: Reviews, Expert opinions, and
Software testing.
The SQA components used during the operation–maintenance phase include specialized
maintenance components as well as development life cycle components, which are applied
mainly for functionality to improve the maintenance tasks.
Components of infrastructure error prevention and improvement
The main objective of these components, which is applied throughout the entire organization,
is to eliminate or at least reduce the rate of errors, based on the organization’s accumulated
SQA experience.
Components of software quality management
This class of components deal with several goals, such as the control of development and
maintenance activities, and the introduction of early managerial support actions that mainly
prevent or minimize schedule and budget failures and their outcomes.
Components of standardization, certification, and SQA system assessment
These components implement international professional and managerial standards within the
organization. The main objectives of this class are utilization of international professional
knowledge, improvement of coordination of the organizational quality systems with other
organizations, and assessment of the achievements of quality systems according to a common
scale. The various standards may be classified into two main groups: quality management
standards and project process standards.
Organizing for SQA – the human components
The SQA organizational base includes managers, testing personnel, the SQA unit and the
persons interested in software quality such as SQA trustees, SQA committee members, and
SQA forum members. Their main objectives are to initiate and support the implementation of
SQA components, detect deviations from SQA procedures and methodology, and suggest
improvements.
Pre-project Software Quality Components
These components help to improve the preliminary steps taken before starting a project. It
includes −

 Contract Review
 Development and Quality Plans
Contract Review
Normally, a software is developed for a contract negotiated with a customer or for an internal
order to develop a firmware to be embedded within a hardware product. In all these cases, the
development unit is committed to an agreed-upon functional specification, budget and
schedule. Hence, contract review activities must include a detailed examination of the project
proposal draft and the contract drafts.
Specifically, contract review activities include −
 Clarification of the customer’s requirements
 Review of the project’s schedule and resource requirement estimates
 Evaluation of the professional staff’s capacity to carry out the proposed project
 Evaluation of the customer’s capacity to fulfil his obligations
 Evaluation of development risks
Development and Quality Plans
After signing the software development contract with an organization or an internal
department of the same organization, a development plan of the project and its integrated
quality assurance activities are prepared. These plans include additional details and needed
revisions based on prior plans that provided the basis for the current proposal and contract.
Most of the time, it takes several months between the tender submission and the signing of
the contract. During these period, resources such as staff availability, professional capabilities
may get changed. The plans are then revised to reflect the changes that occurred in the interim.
The main issues treated in the project development plan are −
  Schedules
 Required manpower and hardware resources
 Risk evaluations
 Organizational issues: team members, subcontractors and partnerships
 Project methodology, development tools, etc.
 Software reuse plans
The main issues treated in the project’s quality plan are −
 Quality goals, expressed in the appropriate measurable terms
 Criteria for starting and ending each project stage
 Lists of reviews, tests, and other scheduled verification and validation activities

ISO 9000 Certification

ISO (International Standards Organization) is a group or consortium of 63 countries established
to plan and fosters standardization. ISO declared its 9000 series of standards in 1987. It serves
as a reference for the contract between independent parties. The ISO 9000 standard determines
the guidelines for maintaining a quality system. The ISO standard mainly addresses operational
methods and organizational methods such as responsibilities, reporting, etc. ISO 9000 defines
a set of guidelines for the production process and is not directly concerned about the product
itself.

Types of ISO 9000 Quality Standards

The ISO 9000 series of standards is based on the assumption that if a proper stage is followed
for production, then good quality products are bound to follow automatically. The types of
industries to which the various ISO standards apply are as follows.

1. ISO 9001: This standard applies to the organizations engaged in design, development,
production, and servicing of goods. This is the standard that applies to most software
development organizations.
 2. ISO 9002: This standard applies to those organizations which do not design products
but are only involved in the production. Examples of these category industries contain
steel and car manufacturing industries that buy the product and plants designs from
external sources and are engaged in only manufacturing those products. Therefore, ISO
9002 does not apply to software development organizations.
3. ISO 9003: This standard applies to organizations that are involved only in the
installation and testing of the products. For example, Gas companies.

How to get ISO 9000 Certification?

An organization determines to obtain ISO 9000 certification applies to ISO registrar office for
registration. The process consists of the following stages:

1. Application: Once an organization decided to go for ISO certification, it applies to the

registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the
organization.
3. Document review and Adequacy of Audit: During this stage, the registrar reviews
the document submitted by the organization and suggest an improvement.
4. Compliance Audit: During this stage, the registrar checks whether the organization
has compiled the suggestion made by it during the review or not.
 5. Registration: The Registrar awards the ISO certification after the successful
completion of all the phases.
6. Continued Inspection: The registrar continued to monitor the organization time by
time.

Software Reliability

Software Reliability means Operational reliability. It is described as the ability of a system

or component to perform its required functions under static conditions for a specific period.

Software reliability is also defined as the probability that a software system fulfills its assigned
task in a given environment for a predefined number of input cases, assuming that the hardware
and the input are free of error.

Software Reliability is an essential connect of software quality, composed with functionality,

usability, performance, serviceability, capability, installability, maintainability, and
documentation. Software Reliability is hard to achieve because the complexity of software turn
to be high. While any system with a high degree of complexity, containing software, will be
hard to reach a certain level of reliability, system developers tend to push complexity into the
software layer, with the speedy growth of system size and ease of doing so by upgrading the
software.

For example, large next-generation aircraft will have over 1 million source lines of software
on-board; next-generation air traffic control systems will contain between one and two million
lines; the upcoming International Space Station will have over two million lines on-board and
over 10 million lines of ground support software; several significant life-critical defense
systems will have over 5 million source lines of software. While the complexity of software is
inversely associated with software reliability, it is directly related to other vital factors in
software quality, especially functionality, capability, etc.