Difference between revisions of "Category:Quality"

From Pearl Language
Jump to navigation Jump to search
m (Empty space deleted.)
(→‎Sources: += InfoQ » Shane Hastie » Elisabeth Hendrickson on Building Quality In)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
:'''Focus on quality, speed will follow.'''
:'''Focus on quality, speed will follow.'''
::—W. Edwards Deming
::—{{author|W. Edwards Deming}}


==Pearls and other pages==
Quality can be quantified, for example, by using {{p|planguage}}. Keep in mind, though, that {{p|metric drives behavior}}.
*[[Mission Critical Agile]]
*{{p|babushka of value}}
*{{p|refactor code}}
 
==See also==
*[[Planguage]]
 
==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:
Quality requirements should be specified in terms of:
Line 47: Line 13:


==Sources==
==Sources==
*SunTone Architecture Methodology
{{WebSourceListItem
|url=http://www.infoq.com/articles/create-culture-quality
|site=InfoQ
|person=Jonathan Levene
|title=Creating a Culture of Quality
}}
{{WebSourceListItem
|url=http://www.mountaingoatsoftware.com/blog/what-is-quality
|site=Mountain Goat Software
|person=Mike Cohn
|title=What Is Quality?
}}
{{WebSourceListItem
|url=http://www.infoq.com/interviews/agile2014-hendrickson-quality
|site=InfoQ
|person=Shane Hastie
|title=Elisabeth Hendrickson on Building Quality In
}}

Latest revision as of 09:26, 9 October 2014

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.

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

Pages in category "Quality"

The following 8 pages are in this category, out of 8 total.

 

M

N

P

S

Retrieved from "http://pearllanguage.org/index.php?title=Category:Quality&oldid=2240"