Simple and Cheap aren't necessarily the same!

Simple and Cheap aren’t necessarily the same!

Attribute and usage models are fairly typical frameworks for translating a strategic definition of quality into tactical measurements of quality. The quality of the software or product is measured by observing the impact of what is delivered. The software or product quality can be influenced by the development process (process quality); however, process-like development, project management, and testing are not being directly measured. The attributes and usage components you select are a reflection of the organization’s goals and missions. For example, one would expect an airline’s definition and model of quality to prominently feature safety while a financial institution would tend to highlight data and physical security. Leveraging the ISO “quality in use” model as an example to develop a measurement pallet (a bunch of metrics that can be used based on specific needs) provides the following example: (more…)

Attributes are like buttons, lots of control and lots of complexity.

Attributes are like buttons, lots of control and lots of complexities.

At its heart, the defect management approach to defining software quality is focused on identifying, categorizing and counting defects.  Quality attribute models expand the definition of quality from the occurrence of defects to a framework of attributes.  For example, ISO/IEC 25010:2011 describes an attribute model comprised of eight quality characteristics. The characteristics are:

  1. Functional suitability
  2. Reliability
  3. Operability
  4. Performance efficiency
  5. Security
  6. Compatibility
  7. Maintainability
  8. Transferability

In the ISO model each of the characteristics can be further broken down into sub-characteristics to provide additional depth to the definition of quality.  All quality attribute models are based on a broader framework than the defect management approach. Using a broader framework provides teams and organizations with more information than simpler models due to the sheer number of attributes in the model. However, more information comes at a cost.  Quality attribute modes are less easy to implement, require more data collection, and often require more effort from the development team. (more…)



One of the most common measures of software quality is a count of defects. Conceptually it goes as follows: the more defects generated (and found), the lower the quality of the software. The process of finding, categorizing, counting and resolving defects not only improves the quality of the delivered software but is useful for improving the processes used to create the defects (and the software). The defect management approach is common because it can be simple or complex, require little or a lot of effort to execute, or predictive or reactive depending on an organization’s need.


Airplane propeller

Software quality is a simple phrase that is difficult to define. Three of the most important quality management thought leaders of the past century define quality in very different ways.

Philip B Crosby, author of Quality is Free, defines quality as conforming to requirements. Crosby views quality as nearly binary; quality either exists or it does not.  There are no different levels of quality.

Joseph Juran, who popularized the concept of the cost of poor quality, defines quality as fitness for use.  Juran’s writings describe quality as meeting customers’ expectations with a product that is free from deficiencies.

W. Edward Deming, the author of Out of the Crisis, stated that the customer’s definition of quality is the only one that matters, which means that there is no single definition. Each customer (or group of customers) will have their own definition of quality is based on their needs.

While none of these eminent thought leaders agreed on a precise definition of quality, at the core of all three definitions are the needs and requirements of users. This is critical, but software quality is more nuanced. Just meeting user requirements is only one part of the overall quality of a software deliverable. Technical debt, shortcuts taken while developing and maintaining software, can accumulate and make the software buggy and costly to maintain.  Quality will suffer if the process used to develop the software causes it to be late or if the software is not verified before it delivered.  Defining software quality requires a broader framework.