Toward an Effective Quality Plan: PQD in Action

Using the modified McCall product quality definition, you can use a three-step process to plan the deployment of the required quality through the development process.

Once the PQD process has been applied to the overall product requirements, the product is partitioned into subcomponents and the process is repeated for each subcomponent. For a software system, the components would usually be subsystems such as front-end and back-end processing.

Step 1: Define the Product Requirements

This step would usually be undertaken during the project feasibility study and, in more detail, in the requirements analysis phase. Typically, the RAP process would provide enough information for the stakeholders to reach an initial agreement.

Step 2: Negotiate Product Quality Attributes

This step is the most crucial in the quality planning cycle. Given the potential for conflict in quality expectations between your various stakeholders in the project and the conflict between the various quality attributes, you must identify the quality requirements of your critical stakeholders, identify any conflicts, and negotiate an agreed quality requirement, the quality agreement (see Figure 10.3).

Figure 10.3. Quality agreement

Step 2.1: Determine and Review Stakeholders' Ranking

Preferably in a group session, interview each critical stakeholder and review and determine their quality requirements using the form in Figure 10.2. It is important that you are patient here, as some stakeholders will simply say, "They're all on." Remember, they will generally be stating their MPP.

Don't Get Too Complex

You may be tempted to use more sophisticated scoring mechanisms than the simple on/off ones that we propose (e.g., mandatory or not applicable). You may feel that using scales such as mandatory, desirable, and not applicable could be more useful, but our experience is that the simpler scales always work better. By getting too into the ranking process, people get focused on what the ranking means (i.e., what is the difference between a 6 and a 7?). Remember, simple is sexy. Complex sucks.

Step 2.2: Derive Final Ranking

Evaluate all mandatory quality attributes, looking for a majority agreement between the team and stakeholders (say, where 50% or more of the stakeholders agree, the attribute is mandatory for the project). Also, evaluate the rankings for any potentially conflicting mandatory quality attributes. For example, efficiency has a negative relationship with maintainability, flexibility, and portability.

Step 3: Review Quality Attributes with Your Sponsor

The final rankings should be reviewed with senior management, including your project sponsor, and any unresolved conflicts in the stakeholders' rankings should be resolved by senior management.

Your own project's quality agreement can then be used to develop broad quality baseline drivers and review points across the system development process. This development and use of quality baseline drivers is the key to quality planning and deployment.

Repeat Until

As described earlier, for larger projects, the PQD process would be repeated for individual subprojects broken into major modules. As the project progresses through the system development life cycle, the quality agreements would become more detailed. For example, by the design phase of a software project, the quality agreement would be platform-specific.

Quality Index

If the relevant software attributes and criteria have been scored, then they can simply be added together to provide a simple, yet powerful numeric indicator of the relative quality of the product or system.

The simple approach is to use Table 10.1, which is based on just scoring the quality attributes.

Table 10.1. Quality Index

Conformity and/or maintainability and/or flexibility and/or auditability /security	1
Conformity and/or maintainability and/or flexibility and/or auditability/security and any one of portability, efficiency, usability, reliability, reusability, and job impact	2
Conformity and/or maintainability and/or flexibility and/or auditability/security and any two of portability, efficiency, usability, reliability, reusability, and job impact	3
Conformity and/or maintainability and/or flexibility and/or auditability/security and any three of portability, efficiency, usability, reliability, reusability, and job impact	4
Conformity and/or maintainability and/or flexibility and/or auditability/security and any four or more of portability, efficiency, usability, reliability,reusability, and job impact	5

The quality index provides a reasonable baseline to adjust project productivity measures or metrics and also to measure the quality of production systems. For example, two teams may have reported the same delivery productivity rates, but one team has delivered a system with a quality index score of 5 (very high quality requirements) and the other has delivered a system with a quality index score of 2 (low). Clearly, the first team has been more productive.