SOFTWARE QUALITY CONCEPTS - Software Design for Six-Sigma: A Roadmap for Excellence - page 9

nonfunctional requirements, reviewing for conformance to organizational policy, re-
views for configuration management plans, standards, and so on. QA in the design
phase may include reviews, inspections, and tests. QA would be able to answer ques-
tions like, “Does the software design adequately meet the quality required by the
management?” QA in the implementation phase may include a review provision for
QA activities, inspections, and testing. QA would be able to answer questions like,
“Have technical disciplines properly performed their roles as part of the QA activ-
ity?” QA in the testing phase would include reviews, and several testing activities.
QA in the maintenance phase could include reviews, inspections, and tests as well.
The QA engineer serves as the customer's in-house representative (Pressman, 1997).
The QA engineer usually is involved with the inspection process. Ideally, QA should
(Braude, 2001) be performed by a separate organization (independent) or engineers
can perform QA functions on each other's work.
The ANSI/IEEE Std 730-1984 and 983-1986 software quality assurance plans 5
provide a road map for instituting software quality assurance. Table 1.3 shows the
ANSI/IEEE Std 730-1984 and 983-1986 software quality assurance plans. The plans
serve as a template for the QA activates that are instituted for each software project.
The QA activities performed by software engineering team and the QA group are
controlled by the plans. The plans identify the following (Pressman, 1997):
Evaluations to be performed
Audits and reviews to be performed
Standards that are applicable to the project
Procedures for error reporting and tracking
Documents to be produced by the QA group
Amount of feedback provided to the software project team

To be more precise in measuring the quality of a software product, statistical quality
assurance methods have been used. The statistical quality assurance for software
products implies the following steps (Pressman, 1997):

1. Information about software defects is collected and categorized.
2. An attempt is made to trace each defect to its cause.
3. Using the Pareto principle, the 20% of the vital causes of errors that produce
80% of the defects should be isolated.
4. Once the vital causes have been identified, the problems that have caused the
defects should be corrected.

1.6 SOFTWARE QUALITY COST

Quality is always deemed to have a direct relationship to cost—the higher the quality
standards, the higher the cost. Or so it seems. Quality may in fact have an inverse

5 Software Engineering Standards (1994 edition), IEEE Computer Society.