—How do you manage cost in McCall's quality model?
I’ve written about McCall’s Software Quality Model and applying it to software quality assurance to create measures throughout the lifecycle. The team and I are trying to employ this model and have some challenges.
Should time-to-release (e.g., something measured using time and cost) be a quality factor?
A quality factor is (FACTORS IN SOFTWARE QUALITY):
A condition or characteristic which actively contributes to the quality of the software.
Quality factors affect cost, whether measured in terms of time, dollars or people.
… all factors are related to a normalized cost to either perform the activity characterized by the factor or to operate with that degree of quality. For example, maintainability is the effort required to locate and fix an error in an operational program. This effort required may be expressed in units such as time, dollars, or manpower.
So every factor has a cost and the units of cost need to be normalized so they are easy to compare.
The rules for quality factors.
The following rules were used to determine the prime set of quality factors:
- a condition or characteristic which contributes to software quality,
- a user-related characteristic,
- related to cost either to perform the activity characterized by the function or to operate with that degree of quality,
- relative characteristic between software products.
Bullet four implies that cost and time are quality factors. It connects managing quality to managing time or cost. Table 2.4-1 in FACTORS IN SOFTWARE QUALITY, titled “Grouping of Software Quality Factors to Achieve Unambiguous Set” includes cost and time.
Elsewhere, FACTORS IN SOFTWARE QUALITY explains that cost and time are not quality factors. They form the basis for correlating metrics with various levels of quality.
The quality triangle is another way to view this relationship. Since the quality model focuses on managing software quality. You can choose only one of cost or time as the second focus of management.
McCall’s model ignores quality factors based upon cost and time because it includes provision for normalizing all quality factors using time or cost. You can’t use both. Including time-to-release as a quality factor isn’t supported by the model.
In all, strictly applying McCall’s quality model means that cost or time is normalized across all quality factors. Not doing so means your model is less coherent (quality factors are not comparable). If your quality factors are not comparable you will have more difficulty determining how to allocate resources.
As to the second question, “Should time-to-release include notions of quality factors that come before and after it?” the answer is no. If you insist, take a look at Time-to-Release – the missing System Quality Attribute.
You can view this as a simplification of McCall’s model: spend more resources on those attributes above time-to-release and less resources on those below. (Note this article points out that related ISO standards ignore time-to-release, so what’s proposed in this article isn’t recommended.)
The lesson here is that time-to-release is a useful approach for managing McCall’s quality factors. It’s not best practice and that means it introduces other challenges. The main disadvantage introduced by time-to-release is the inability to normalize the costs of quality factors. That’s a bad thing if you define quality as something that controls cost. (You should.)