Difference between revisions of "Category:Quality"

Focus on quality, speed will follow.

—W. Edwards Deming

Quality can be quantified, for example, by using planguage. Keep in mind, though, that metric drives behavior.

Pearls and other pages

• Mission Critical Agile
• babushka of value
• refactor code

Systemic Quality

Systemic Quality is also known as Service Level Requirements or ‘ilities” for short.

Systemic qualities (the “-ilities”) reflect current and evolving goals for the system as it fits into an operational and business environment. The following list, while not exhaustive, identifies the major systemic qualities. It is useful to classify them into three categories based on who is affected, and how and when they are measured.

• Manifest qualities reflect what individual end users see. Their effect is immediate and (for the most part) measurable. Their effect is only relevant at release points. Their growth may be carefully plotted to increase over several release points.
  • Usability reflects the ease which users can accomplish their goals.
  • Performance reflects how little users must wait for things to complete.
  • Reliability measures how often the system fails, or the mean or other time between failures.
  • Availability measures uptime vs. downtime. This may include the capability and measurement of continued partial operation in partial failure situations, with a preference toward gracefully degraded operation in place of total failure.
  • Accessibility incorporates usability paradigms for those with physical limitations.
• Operational qualities concern those who run or monitor the system as it operates, who view the system as a job to manage rather than as a tool by which they benefit from. Only when degraded are operational qualities visible to end-users and then only indirectly. For example, what end-users may see as poor performance may be the result of throughput thresholds having been exceeded. Unlike manifest qualities, the insufficiency of operational qualities may be supplemented by manual or alternative processes as workarounds.
  • Throughput measures how many users can be supported at particular performance thresholds.
  • Manageability is the ability to easily start, restart, and stop the system or its sub processes (if required), to monitor it for behavior relative to desired quality thresholds, and to take corrective action accordingly. The latter actions overlap aspects of field maintainability, with the difference that operations staff are generally not as deeply trained in systems internals as those responsible for field maintenance.
  • Security is the prevention of undesired use of or access to a system and the data to which it has access. This typically centers around the ability to control access to specific data items and/or operations based on the identity of the accessing entity.
  • Serviceability is the degree to which a system can be repaired or updated as reflected by the granularity of its replaceable components, the ease and speed that they can be swapped, and the downtime effect on the overall system while this is taking place.
  • Field Maintainability is the degree to which faults can be detected ('routine maintenance'), diagnosed, and serviced. Insofar as some faults are evidenced through visible system failure, maintainability reduces to fault diagnosis and serviceability.
• Developmental qualities describe advantageous aspects of the system of interest to its builders. Developmental qualities are transitory insofar as the system is continuously evolving; they become irrelevant once the system is built. Their definition is a primary concern of the initial project leadership.
  • Buildability is the amount of confidence that a system can be built within a given time frame.
  • Budgetability is the amount of confidence that a system can be built within a given resource budget within a given time frame.
  • Planability reflects the degree to which a predictable plan and cost estimation can be created.
• Evolutionary qualities anticipate future system demands beyond the current release. Unlike runtime qualities, these are in general much more difficult to measure since their effect will not be apparent until some date following the upcoming release date. From a business perspective, they are therefore hard to hold anyone accountable.
  • Scalability is a ratio between the ability to support more users vs. the amount of required effort.
  • Maintainability eases the work of minor modifications and fixes (the equivalent of field maintainability and serviceability on a design and its implementation.
  • Extensibility makes significant enhancements or changes easier.
  • Reusability or flexibility allows portions of the current system to be incorporated into other systems.
  • Portability enables the system to be moved to other platforms.

Quality requirements should be specified in terms of:

• Quantifiable, preferably testable, value ranges
• Which context and inputs produce distinct outputs
• Consideration for typical vs. atypical circumstances
• Which particular functional aspects of the system (possibly which user stories), if any, are specifically relevant to that quality
• Possible scenarios under which conditions should hold
• Priority among them

Sources

• SunTone Architecture Methodology