Software problems are 100 to 1000 times more costly to find and repair after deployment. Verifying and managing quality
throughout the project's lifecycle is essential to achieving the right objectives at the right time.
It's important that the quality of all artifacts are assessed at several points in the project's lifecycle as they
mature. Artifacts should be evaluated as the activities that produce them complete and at the conclusion of each
iteration. In particular, as executable software is produced, it should be subjected to demonstration and test of
important scenarios in each iteration, which provides a more tangible understanding of design trade-offs and earlier
elimination of architectural defects. This is in contrast to a more traditional approach that leaves the testing of
integrated software until late in the project's lifecycle.
Quality is something we all strive for in our products, processes, and services. Yet when asked, "What is Quality?",
everyone has a different opinion. Common responses include one or the other of these:
-
"Quality ... I'm not sure how to describe it, but I'll know it when I see it."
-
"... meeting requirements."
Perhaps the most frequent reference to quality, specifically related to software, is this remark regarding its absence:
"How could they release something like this with such low quality!?"
These commonplace responses are telling, but they offer little room to rigorously examine quality and improve upon its
execution. These comments all illustrate the need to define quality in a manner in which it can be measured and
achieved.
Quality, however, is not a singular characteristic or attribute. It's multi-dimensional and can be possessed by a
product or a process. Product quality is concentrated on building the right product, whereas process quality is focused
on building the product correctly. See Concept: Product Quality and Concept: Process Quality for additional information.
The definition of quality, taken from The American Heritage Dictionary of the English Language, 3rd Edition, Houghton
Mifflin Co.,© 1992, 1996, is:
Quality (kwol'i-te) n., pl. -ties. 1.a. An inherent or distinguishing characteristic; a
property. b. A personal trait, especially a character trait. 2. Essential character; nature.
3.a. Superiority of kind. b. Degree or grade of excellence.
As demonstrated by this definition, quality is not a single dimension, but many. To use the definition and apply it to
software development, the definition must be refined. Therefore, for the purposes of the Rational Unified Process
(RUP), quality is defined as:
"...the characteristic of having demonstrated the achievement of producing a product that meets or exceeds
agreed-on requirements-as measured by agreed-on measures and criteria-and that is produced by an agreed-on
process."
Achieving quality is not simply "meeting requirements", or producing a product that meets user needs and expectations.
Rather, quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the
implementation of a process to ensure that the product created by the process has achieved the desired degree of
quality, and can be repeated and managed.
See also the following pages for additional information on how the RUP defines the idea of quality:
A common misconception is that quality is owned by, or is the responsibility of, one group. This myth is often
perpetuated by creating a group, sometimes called Quality Assurance-other names include Test, Quality Control, and
Quality Engineering-and giving them the charter and the responsibility for quality.
Quality is, and should be, the responsibility of everyone. Achieving quality must be integral to almost all process
activities, instead of a separate discipline, thereby making everyone responsible for the quality of the products (or
artifacts) they produce and for the implementation of the process in which they are involved.
Each role contributes to the achievement of quality in the following ways:
-
Product quality-the contribution to the overall achievement of quality in each artifact being produced.
-
Process quality-the achievement of quality in the process activities for which they are involved.
Everyone shares in the responsibility and glory for achieving a high-quality product, or in the shame of a low-quality
product. But only those directly involved in a specific process component are responsible for the glory, or shame, for
the quality of those process components (and the artifacts). Someone, however, must take the responsibility for
managing quality; that is, providing the supervision to ensure that quality is being managed, measured, and achieved.
The role responsible for managing quality is the Project Manager.
There are many misconceptions regarding quality and the most common include:
Just as a product cannot be produced if there is no description of what it is, what it needs to do, who uses it and how
it's used, and so on, quality and its achievement cannot be attained if it's not described, measured, and part of the
process of creating the product.
See Concept: Measuring Quality and the section of this document titled Quality happens on its own.
Quality is not a single dimension, attribute, or characteristic. Quality is measured in many ways-quality metrics and
criteria are established to meet the needs of project, organization, and customer.
Quality can be measured along several dimensions-some apply to process quality; some to product quality; some to both.
Quality can be measured for:
-
Progress-such as use cases demonstrated or milestones completed
-
Variance-differences between planned and actual schedules, budgets, staffing requirements, and so forth
-
Reliability-resistance to failure (crashing, hanging, memory leaks, and so on) during execution
-
Function-the artifact implements and executes the required use cases as intended
-
Performance-the artifact executes and responds in a timely and acceptable manner, and continues to perform
acceptably when subjected to real-world operational characteristics such as load, stress, and lengthy periods of
operation
See Concept: Quality Dimensions, Concept: Product Quality, and Concept: Process Quality for additional information.
Quality cannot happen by itself. For quality to be achieved, a process is must be implemented, adhered to, and
measured. The purpose of the RUP is to provide a disciplined approach to assigning tasks and responsibilities within a
development organization. Our goal is to ensure the production of high-quality software that meets the needs of our
users, within a predictable schedule and budget. The RUP captures many of the best practices in modern software
development in a form that can be tailored for a wide range of projects and organizations. The Environment discipline gives you guidance about how to best configure
the process to your needs.
Processes can be configured and quality-criteria for acceptability-can be negotiated, based upon several factors. The
most common factors are:
-
Risk (including liability)
-
Market opportunities
-
Revenue requirements
-
Staffing or scheduling issues
-
Budgets
Changes in the process and criteria for acceptability should be identified and agreed upon at the outset of the
project.
Managing quality is done for these purposes:
-
To identify appropriate indicators (metrics) of acceptable quality
-
To identify appropriate measures to be used in evaluating and assessing quality
-
To identify and appropriately address issues affecting quality as early and effectively as possible
Managing quality is implemented throughout all disciplines, workflows, phases, and iterations in the RUP. In general,
managing quality throughout the lifecycle means you implement, measure, and assess both process quality and product
quality. Some of the efforts expended to manage quality in each discipline are highlighted in the following list:
-
Managing quality in the Requirements discipline includes analyzing the requirements
artifact set for consistency (between artifact standards and other artifacts), clarity (clearly communicates
information to all shareholders, stakeholders, and other roles), and precision (the appropriate level of detail and
accuracy).
-
In the Analysis & Design discipline, managing quality
includes assessing the design artifact set, including the consistency of the design model, its translation from the
requirements artifacts, and its translation into the implementation artifacts.
-
In the Implementation discipline, managing quality includes assessing
the implementation artifacts and evaluating the source code or executable artifacts against the appropriate
requirements, design, and test artifacts.
-
The Test discipline is highly focused toward managing quality, as
most of the efforts expended in this discipline address the three purposes of managing quality, identified
previously.
-
The Environment discipline, like the Test discipline, includes many
efforts addressing the purposes of managing quality. Here you can find guidance on how to best configure your
process to meet your needs.
-
Managing quality in the Deployment discipline of your product deliverables includes
assessing the implementation and deployment artifacts, and evaluating the executable and deployment artifacts
against the appropriate requirements, design, and test artifacts needed to deliver the product to your customer.
-
The Project Management discipline includes an overview of many
efforts for managing quality, including the reviews and audits required to assess the implementation, adherence,
and progress of the development process.
|