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 RequirementsThis 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 AttributesThis 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' RankingPreferably 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.
Step 2.2: Derive Final RankingEvaluate 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 SponsorThe 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 UntilAs 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 IndexIf 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
|