What Is a Quality?


The IEEE and ISO 9000 define quality as "fitness for purpose," which mirrors Philip Crosby's (1979) widely accepted definition of quality as "conformance to requirements." However, for a project manager planning a new project, the ISO 9000 [3] definition does not provide a detailed basis for software quality planning.

[3] Recently, ISO has released a new standard, ISO 9126, for software. This refines the definition of quality into attributes similar to those used by McCall and our group for the past 14 years .

Although many people seem comfortable accepting these definitions, they miss an important related question: Whose requirements and whose purpose?

Based on Jim McCall and Mike Matsumoto's (1980) work, our group has been using the following definition of business product and software quality. Quality is an agreed combination of the following quality attributes:

  • Conformity: Does the product or software have all the data, process, or functionality specified?

  • Usability: Is the product or software easy to use and understand from the client's perspective?

  • Efficiency: Does the product or software use the people, business process, hardware, database or other support software efficiently ?

  • Maintainability: Is the product or software easy to maintain and support?

  • Flexibility: Is the product or software easy to modify to include or add new functions and data?

  • Reliability: Does the product or software perform reliably and is it free from errors?

  • Portability: Can the product or software easily operate in different physical, business, software, or hardware environments?

  • Reusability: Does the product or software require reuse for a different purpose or application?

  • Security/ auditability : Is the product or software secure from unauthorized access and modification and can the software be easily audited and does it include adequate controls?

  • Job impact: Does the product or software affect the existing workflows, control, and autonomy of the business area?

As in many other quality models, the various attributes can be positively or negatively related. For example, although improving maintainability does improve flexibility, the improvement of efficiency can lead to a lowering of usability, maintainability, flexibility, security, and auditability. The positive “negative relationship is identified by the fact that many of the quality attributes share common criteria. For example, flexibility and maintainability share four common criteria. As discussed later in this chapter, you and your team must identify potential conflicts in the product's quality requirements and resolve them before the project begins.

Some pragmatists also add deadlines and cost as a measure of software quality. However, these are constraints, not quality requirements. Many business people faced with cost-reduction pressures and increasing competition based on market windows have been prepared to sacrifice the software quality attributes just listed to simply get a low-quality software solution on time and in budget. Cost and deadlines clearly have a negative relationship with all other software quality attributes.

Although Crosby's admonition that "quality is free" is true in respect to the costs of rework , many computer people have learned that certain software quality attributes are very expensive. The development of a GUI system with full online help and extensive manuals for users, administrators, and power users could incur 50% to 100% additional effort when compared to a similar data and function requirement with a minimum requirement for usability.

In other words, the formalization of software quality attributes reveals the fact that software quality has inherent conflicts. These are exacerbated by the existence of many external people or groups (stakeholders) that have differing views on the required quality for a particular software system. As shown in Figure 10.2, these groups have specialized and often narrow views of the required software quality.

Figure 10.2. Product quality: A conflicting client community

graphics/10fig02.gif

For one particular system, the internal audit department may be concerned about controls and audit trails, whereas the data center may be concerned with reliability, efficiency, and maintainability. Communications may be concerned only with network efficiency and standards may be interested in the following of development standards during the system life cycle. Senior management is focused on deadlines and the business people want usability and reliability. Faced with conflicting quality requirements, it is understandable for project managers and the teams to simply ignore the conflict and impose their own quality requirements on the project!

The process of product quality planning must recognize these conflicts and provide two structured and negotiated outcomes : What is the required quality and what processes are to be in place during the development process to ensure the negotiated quality is delivered. This is the essence of project quality deployment (PQD).



Radical Project Management
Radical Project Management
ISBN: 0130094862
EAN: 2147483647
Year: 2002
Pages: 136
Authors: Rob Thomsett

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net