Page 151 -

8 - PROJECT QUALITY MANAGEMENT

ensure that the project team understands that the user is the person or persons who defines what “quality” and
“fit for use” mean in order to satisfy user needs. However, the project manager needs to recognize that the users
may not be able to indicate what they really want and need prior to using the software. For this reason, a project
manager should rely on the expertise of business analysts, requirements engineers, and others who can elicit
quality expectations.

Software quality has been a fundamental issue from the early days of developing algorithms to perform
mathematical calculations quickly and accurately, to the present day demands for safety-critical, enterprise-wide,
and commercial software. Beyond the basic pass/fail questions of whether the software runs and returns a usable
result (sometimes called a software smoke test), the quality attributes for a particular software product may include
elements from a very long list, which includes attributes that range from accessibility, adaptability, analyzability,
availability, compatibility, and complexity, to survivability, testability, understandability, and usability (the well-known
“ilities” of software).

The complexities of software quality have led to a number of quality models such as those in ISO/IEC 25000 and
the other standards referenced in this section of the Software Extension. Software quality models include process
quality, internal and external product quality, quality in use, data quality, and quality of the software code; the latter
is appraised by inspections or “static” testing, and by exercising the software in “dynamic” testing.

From the perspective of project quality, a project manager considers: Is the work organized to produce quality
software? Are the processes efficient and effective in achieving the project and product goals, and also in building
a strong, cohesive team for ongoing work? What methods and tools are used and are they used effectively?
The internal quality model looks at the software as an open “white box,” where software evaluators can directly
examine the code and the accompanying artifacts, such as design documents, even as they are being developed.
Automated software tools are available to perform many aspects of white-box examination. They include static and
dynamic testing tools that check for code coverage by the test cases, adherence to coding standards, uninitialized
variables, and many other types of coding errors.

The external quality model treats the software as a “black box” where software evaluators determine how the
software behaves by observing input-output behavior, measuring the software’s performance, examining how it
performs its functions and achieves its quality requirements, and observing the conditions under which it fails.
External quality assessment is typically accomplished by functional black box testing, which is usually performed
by external SQC and may be observed by a representative of the intended user community. Black box testing is
based on the requirements and not on the internal aspects of the software code.

Even when software passes predefined evaluations of internal and external quality, users may still think it lacks
quality. The quality in use perspective looks at the impact of the product on users and other stakeholders when it
is used for specified purposes in a specific environment and context. Usability is defined as the extent to which
a product or system can be used by specified users to achieve specified goals with efficiency, effectiveness, and
satisfaction in a specified context of use [26]. Characteristics of quality in use include (a) effectiveness (gets the
job done); (b) satisfaction (usefulness, trust, pleasure in use, comfort); and (c) freedom from risk (economic risk
mitigation, health and safety risk mitigation, and environmental risk mitigation).

142 ©2013 Project Management Institute. Software Extension to the PMBOK Guide Fifth Edition
®