SOFTWARE QUALITY
MEANING OF SOFTWARE QUALITY
In the most general sense, software quality can be defi ned as: An effective software process applied
in a manner that creates a useful product that provides measurable value for those who produce it and
those who use it.
The above definition serves to emphasize three important points:
An effective software process establishes the infrastructure that supports any effort at building a high-
quality software product. The management aspects of process create the checks and balances that
help avoid project chaos—a key contributor to poor quality. Software engineering practices allow the
developer to analyse the problem and design a solid solution— both critical to building high-quality
software.
A useful product always satisfies those requirements that have been explicitly stated by stakeholders.
In addition, it satisfies a set of implicit requirements (e.g., ease of use) that are expected of all high-
quality software.
By adding value for both the producer and user of a software product, high-quality software provides
benefits for the software organization and the end-user community. The software organization gains
added value because high-quality software requires less maintenance effort, fewer bug fixes, and
reduced customer support. The user community gains added value because the application provides
a useful capability in a way that accelerates some business process.
MCCALL’S QUALITY FACTORS
McCall, Richards, and Walters propose a useful categorization of factors that affect software quality.
These software quality factors, shown in Figure - 1, focus on three important aspects of a software
product: its operational characteristics, its ability to undergo change, and its adaptability to new
environments.
Correctness. The extent to which a program satisfies its specification and fulfils the customer’s mission
objectives.
Reliability. The extent to which a program can be expected to perform its intended function with
required precision.
Efficiency. The amount of computing resources and code required by a program to perform its function.
Integrity. Extent to which access to software or data by unauthorized persons can be controlled.
Usability. Effort required to learn, operate, prepare input for, and interpret output of a program.
Maintainability. Effort required to locate and fi x an error in a program.
Flexibility. Effort required to modify an operational program.
Figure 1: McCall’s Quality Factors
Testability. Effort required to test a program to ensure that it performs its intended function.
Portability. Effort required to transfer the program from one hardware and/or software system
environment to another.
Reusability. Extent to which a program [or parts of a program] can be reused in other applications—
related to the packaging and scope of the functions that the program performs.
Interoperability. Effort required to couple one system to another.
ISO 9126 QUALITY FACTORS
The ISO 9126 standard was developed in an attempt to identify the key quality attributes for computer
software. The standard identifies six key quality attributes:
Functionality. The degree to which the software satisfies stated needs as indicated by the following
sub-attributes: suitability, accuracy, interoperability, compliance, and security.
Reliability. The amount of time that the software is available for use as indicated by the following
sub-attributes: maturity, fault tolerance, recoverability.
Usability. The degree to which the software is easy to use as indicated by the following sub-
attributes: understandability, learnability, operability.
Efficiency. The degree to which the software makes optimal use of system
resources as indicated by the following sub-attributes: time behaviour, resource behaviour.
Maintainability. The ease with which repair may be made to the software as indicated by the
following sub-attributes: analysability, changeability, stability, testability.
Portability. The ease with which the software can be transposed from one environment to another as
indicated by the following sub-attributes: adaptability, install ability, conformance, replaceability.
ACHIEVING SOFTWARE QUALITY
Software quality doesn’t just appear. It is the result of good project management and solid software
engineering practice. Management and practice are applied within the context of four broad activities
that help a software team achieve high software quality: software engineering methods, project
management techniques, quality control actions, and software quality assurance.
Software Engineering Methods
If you expect to build high-quality software, you must understand the problem to be solved and adopt
appropriate analysis and design methods the likelihood of creating high-quality software will increase
substantially. You must also be capable of creating a design that conforms to the problem while at the
same time exhibiting characteristics that lead to software that exhibits the quality dimensions and
factors.
Project Management Techniques
The implications of poor management decisions on software quality have been clear: if (1) a project
manager uses estimation to verify that delivery dates are achievable, (2) schedule dependencies are
understood and the team resists the temptation to use shortcuts, (3) risk planning is conducted so
problems do not breed chaos, software quality will be affected in a positive way.
Quality Control
Quality control encompasses a set of software engineering actions that help to ensure that each work
product meets its quality goals. Models are reviewed to ensure that they are complete and consistent.
Code may be inspected in order to uncover and correct errors before testing commences. A
combination of measurement and feedback allows a software team to tune the process when any of
these work products fail to meet quality goals.
Quality Assurance
Quality assurance establishes the infrastructure that supports solid software engineering methods,
rational project management, and quality control actions—all pivotal if you intend to build high-quality
software. In addition, quality assurance consists of a set of auditing and reporting functions that assess
the effectiveness and completeness of quality control actions.
The goal of quality assurance is to provide management and technical staff with the data necessary to
be informed about product quality, thereby gaining insight and confidence that actions to achieve
product quality are working.
ELEMENTS OF SOFTWARE QUALITY ASSURANCE
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:
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. Technical 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.
Testing. Software testing (Chapters 22 through 26) 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 analyses 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 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 cybercrime 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 human-rated 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.
SQA Tasks
The charter of the SQA group is to assist the software team in achieving a high-quality end product.
The Software Engineering Institute recommends a set of SQA activities that address quality assurance
planning, oversight, record keeping, analysis, and reporting. These activities are performed (or
facilitated) by an independent SQA group that:
Prepares an SQA plan for a project. The plan is developed as part of project planning and is reviewed
by all stakeholders. Quality assurance activities performed by the software engineering team and the
SQA group are governed by the plan. The plan identifies evaluations to be performed, audits and
reviews to be conducted, standards that are applicable to the project, procedures for error reporting
and tracking, work products that are produced by the SQA group, and feedback that will be provided
to the software team.
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.
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.
Audits designated software work products to verify compliance with those defined as part of the
software process. The SQA group reviews selected work products; identifies, documents, and tracks
deviations; verifies that corrections have been made; and periodically reports the results of its work
to the project manager.
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 plan, process description,
applicable standards, or software engineering work products.
Records any noncompliance and reports to senior management. Noncompliance items are tracked until
they are resolved.
GOALS, ATTRIBUTES, AND METRICS OF SQA
The SQA activities described in the preceding section are performed to achieve a set of pragmatic
goals:
Requirements quality. The correctness, completeness, and consistency of the requirements model will
have a strong influence on the quality of all work products that follow. SQA must ensure that the
software team has properly reviewed the requirements model to achieve a high level of quality.
Design quality. Every element of the design model should be assessed by the software team to ensure
that it exhibits high quality and that the design itself conforms to requirements. SQA looks for
attributes of the design that are indicators of quality.
Code quality. Source code and related work products (e.g., other descriptive information) must
conform to local coding standards and exhibit characteristics that will facilitate maintainability. SQA
should isolate those attributes that allow a reasonable analysis of the quality of code.
Quality control effectiveness. A software team should apply limited resources in a way that has the
highest likelihood of achieving a high-quality result. SQA analyses the allocation of resources for
reviews and testing to assess whether they are being allocated in the most effective manner.
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” .
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 well-defi ned methods
of customer communication.
➢ Measure the existing process and its output to determine current quality performance (collect
defect metrics).
➢ Analyse 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, analyse,
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, analyse, design, and verify) method.
