Quality in Action

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.

If you haven't defined quality, you can't measure it.

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 :

• The producers determine when the product is ready for review.

• Everything new should be reviewed.

• Quality assurance starts when the project starts.

• Reviews should be short (one or two hours), sharp (small deliverables), and regular (daily).

• Reviews raise problems but don't resolve them.

• The product is commented on, not the producers.

• Reviews should involve people external to the team (i.e., stakeholders, operations, etc.).

• Formal reviews should produce reports and be conducted by a designated chairperson.

• Quality assurance reviews should focus on major issues.

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

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.

Walkthroughs

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

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 .

Speed Reviews

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.

Feature Chiefs

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.

Good Enough

There is an on-going debate between software people, in particular, about the issue of quality. One school is the CMM and ISO group, who believe that quality is perfection . The other school is the "good enough" school, who believe that quality is whatever the client perceives as good enough for their need. The quality agreement tool clearly belongs to the "good enough" school.

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:

• The people producing the product, service, or system are responsible for the quality.

• The techniques of quality management and assurance are participative and team driven.

• Quality cannot be inspected in ”it has to be built in.

• Quality starts with senior management.

• Quality is in the details.

• Quality improvement is achieved incrementally through small changes.

• Quality improvement requires resources and expenses that are paid back in the long term .

• Quality improves productivity and morale .