Once the quality agreements have been agreed to and documented, these provide the basis for the proven quality assurance techniques, such as technical reviews, inspections, and walkthroughs.
Given that the quality agreement defines the required quality attributes, it enables the project team to review all critical deliverables from the specific quality requirement for the system.
The quality agreement also provides a vehicle for the postimplementation evaluation of product quality and project change control. In particular, with a clear and negotiated definition of product data and function requirements and quality assurance, any change to agreed-on quality attributes or criteria should be treated as a request for change and processed using standard change control procedures (discussed later in this book).
The use of PQD as a vehicle for project quality planning provides a vital link between the software development process and the required product quality.
The quality assurance of the specific components of the service, product or system involves team-driven techniques. External support groups such as development support and data administration would act as facilitators for these techniques rather than being involved in the actual assessment of product quality. The majority of the product assurance techniques have developed from the work of Gerald Weinberg (1971) and others in the early 1970s. With the exception of the system testing techniques, all quality assurance techniques follow a common set of rules, as follows :
Within this framework of common rules, there are a number of different quality assurance review techniques that are appropriate for different products and different stages of the development cycle.
Technical reviews involve a small team representing stakeholders, dependent projects, support groups, and project team members examining the product without the producer present. Experience has shown that these reviews are the most rigorous , as they require the product to stand on its own and avoid the defensive and selling behaviors that often mar walkthroughs. Technical reviews are ideal for documentation, analysis, and design specifications.
These reviews, often called structured walkthroughs, are similar in structure to technical reviews but the producer steps, reads, or walks through the product with the review team. Walkthroughs are the most widely implemented of the quality assurance techniques, but they can be reduced in effectiveness by interpersonal behaviors such as selling, arguing, avoidance , and so on. As a result, this technique is most effective when a strong chairperson is conducting the review. Walkthroughs are most commonly used for detailed design, program, and testing documents.
Inspections are either walkthroughs or technical reviews that are driven using an inspection or checklist. These inspection lists highlight common errors and critical components that the quality assurance group should be evaluating in the product. Inspection lists are available for analysis, design, coding, and other system development deliverables (Freedman and Weinberg's 1977 book contains a number of excellent inspection lists). Inspections are ideal for all types of deliverables, provided the inspection lists are available for the specific deliverable .
This review technique can involve larger teams than the other product review techniques. Speed reviews are ideal for reviewing large deliverables that have not previously been subject to the other quality assurance techniques and that the review participants have not had an opportunity to preread or review. A typical speed review would require 10 or more people. A chairperson would partition the product into segments that could be read in a 10- to 20-minute session. As review members read the document, they mark errors or comments directly on the product. At the end of the session, a summary is made of the individual comments and the process is repeated until the entire product is reviewed. Speed reviews can take up to a day and are ideal for documentation and other textual material.
This review technique is a modified version of all the review techniques already discussed where the participants are selected to represent a specific area of expertise. For example, in a feature chief review, the data administration representative would be restricted to raising issues relevant to data administration.
All these review techniques can be conducted either formally or informally. Formal quality assurance reviews must produce a review summary including a decision to accept or reject the product, together with a list of errors and issues to be resolved by the producers. Informal reviews do not produce any management documentation.
The other forms of product quality assurance review techniques are generally included in the approaches of product or system testing. System testing techniques are not covered in this book.
Quality Assurance Drivers
Using your project's quality agreement provides you, your team, and stakeholders with a baseline for determining whether your project is delivering the agreed-on quality.
In effect, the quality agreement is used to determine which specific quality attributes should be reviewed in each deliverable. For example, if usability is required, then usability problems would be identified as serious defects. If usability is not required, these problems would simply be noted, not corrected.
Our experience has shown that this approach ensures that the quality assurance reviews do not get into wasteful arguments about whether a product is "correct" or not.
It all depends on the client's requirements.
Quality Assurance Principles
The techniques involved in quality management vary depending on whether the focus is on the process or the product. However, there is a common set of principles in all the techniques: