Model Of Quality
Model Of QualityI've been working with software quality for a long time. Quality is a multi-faceted concept that only can be understood from a defined perspective. To define quality of an object, being it a service or product, you must also define what is the perspective to be analyzed.
From an article I wrote: (http://www.cos.ufrj.br/~xexeo/artigos/isas96/isas96.htm)
'' Quality is an elusive concept, included in the relation among observer and observed object. It is of general acceptance that quality should be evaluated as a composite notion, and the ISO 9000 series of international standard for quality control support this approach. Recently, the ISSO-9126 Software Product Evaluation Characteristics has established itself as a high-level framework for assessing software product quality.
We have been working since 1983 with a hierarchical quality model based in four main concepts: objectives or goals, factors, criteria and evaluation processes.
A Software Quality Evaluation Model aims to describe how to understand quality. Rocha introduced a model where quality objectives or goals represent the general properties that a product should possess. Each goal is decomposed in factors, which can be or not further decomposed in subfactors. Factors and subfactors define different users' perspectives about the quality of a software product. Moreover, factors should be divided in primitive quality attributes, able to be measured, called criteria. For each criterion, we must establish one or more alternative evaluation processes, describing a measurement methodology. When we speak about objectives, factors, subfactors and criteria indifferently we use the terms attribute or requirement .
Measures realized in an automatic way, or by a manual but well-defined process, are called objective measures. When they are difficult to precisely define, we call them subjective measures. Most of the time we search for objective measures, but the special characteristic of software development sometimes forces us to appeal to subjective analysis, like using expert consultation. These relations among evaluation processes, criteria, subfactors, factors and goals compose the logic relations of our model.
After the evaluation we remain with the numerical or qualitative measures that quantify the criteria. These measures must be aggregated to quantify the factors. The relations among measures and aggregate measures are known as quantitative relations. Finally, we now extend this model appending a set of fuzzy functions, that support the interpretation of the obtained measures.
An actual instance
It is important to show one example of quality attributes, taken directly from an instance of our model designed for financial applications. Our experiment used the data derived from a field investigation with 46 expert professionals in fourteen Brazilian financial institutions, where one hundred quality attributes were identified in the literature, classified using our Software Quality Model, and adjusted to the financial area. The experts advised the desirable quality attribute value for each quality criterion.
Software products should attend specific user needs, and are expected to have a long operational life. Three quality goals must achieve to realize these hopes: usability, conceptual reliability and representational reliability.
Usability is the quality goal composed by the quality factors related to the actual use of the program in diverse ways. Although important, it is also necessary that the program complies with the requirements that motivated it construction.
The quality objective Conceptual Reliability refers to the quality factors that express the understanding and correction, related to the contents of the internal documentation and source code.
Finally, the quality factors related to understanding and manipulation of the description, organization and representation of the documentation and source code compose the quality goal Representational Reliability.
The data used in this work describe the quality factor user friendliness, component of the quality objective usability. The user friendliness characterizes if a program presents the its results in the expected format, offering a feeling of satisfaction and confidence to the user. It has four components:
Quality is something we often want to talk about when we are discussing software. For example we want to talk about whether QualityIsFree or the effect of ExtremeProgramming on quality. The problem is quality is a pretty slippery subject. Maybe we need a ModelOfQuality to help us talk about it.
I recall reading a book once which distinguished between Quality of design and Quality of conformance. Quality of design was about functionality, features, appearance etc. Quality of conformance was about reliability, maintainability, etc. Following this model one might think of MicrosoftSoftware? as being strong on quality of design and weak on quality of conformance.
Has anyone else come across this distinction or have any references?
I've heard of external versus internal quality, which sounds similar. External is stuff visible to users, like functionality, features etc. Internal is stuff visible to programmers, like clarity, maintainability. -- DaveHarris
Yet another axis is VerificationVsValidation'. Verification checks that the program does what the specification says; validation checks that the specification is useful to the audience.
I was also told recently about a new ISO standard for software in the 9000 series that contains a model of quality. Apparently it defines a small number of quality attributes. For example: reliability, portability, usability, maintainability, etc. I'm not clear exactly how the attributes were to be used but presumably as some sort of quality target for a project.
Has anyone else come across this or have any references?
I guess you are thinking about ISO 9126, but it isn't that new. One of the many pages on the internet that describes this standard is: http://www.isaca.org.za/Iso9126.htm.
Quality, said RobertPirsig, is what you like. --RonJeffries
We held a workshop on OO design quality at OOPSLA a few years ago. One table of people constructed 27 different plausible measures of quality, such as performance, simplicity and all those ilities you mentioned above. At my table, I presented two very small OO designs and asked, "Which is better?" The seven people were split in their opinions. One pointed to design A and that "That one is; it's simpler." Another said, "No, the other one is simpler." So we went around the table and collected about 5 different understandings of what we meant or looked for when saying one design was "Simpler" than the other. Imagine how hard it would be to have tried for consensus among all 18 people for the other 26 plausible measures of quality. --AlistairCockburn
Maybe it is hard to come up with consensus on the different measures of quality, but surely its easy than reaching consensus on what we mean by quality itself. If we can draw out different measures then the client can tell us: "Sure quality is important but what I really care about is conformance to requirements and reliability and I don?t care much about usability, portability or flexibility". As developers we can then target those specific measures confident that we are addressing the quality requirements of the client, or following Ron's definition that we are implementing what the client likes. -- FabianLeGayBrereton
Agreed, getting alignment on development priorities is a very good thing.
At the same time, that doesn't help two developers arguing over the design ("this is better", "no, this is better", etc.).
Applied to software, QualityIsFree would state that improvements in the process of developing software will result in higher quality software at lower development costs. The focus is on the method of doing things not the end result. -- WayneMack
GeraldWeinberg has defined Quality as value to some person. The tricky bit is working out who that person should be. This is how a User's high quality system can be a low quality maintenance nightmare to the software engineers. So any ModelOfQuality must first decide who is measuring it and then decide how they assess quality. Many of the who axes will be orthogonal. Some of the whos are:
The important thing to remember is that all of these groups have a lesser or greater influence on the success of a software project and they all have different quality expectations. The C3 project is an example where the developers concentrated on, and met, one group's quality expectations to the exclusion of another's, and were shut down as a consequence.
Don't forget, "Its always a people problem". And, "Beware the axes with axes to grind." --TomAyerst & WaldenMathews
I find the concept of business value to be a useful guiding concept when evaluating quality. The more business value the system delivers the higher the quality. This takes into account factors such as requirements. If a developer perfectly implements an incorrect requirement, what business value is deliver to the customer? And obviously, if a feature doesn't work, and the feature is to satisfy a valid requirement, business value isn't being delivered. --DavidBeardsley
How is "Business Value" any less elusive a concept than "Quality?" The terms may actually be synonyms.
I think the two are different. The customer can explain what value the software will provide. That is the business value. Your ability to elicit that information from them and incorporate it into the implementation is part of the quality of your process.
Referring back to what was said above, I guess my basic point was that too much focus is placed on verification over validation and I think that the common definition of quality as conformance to requirements and absence of defects is part of the cause of that problem.
WaldenMathews makes my point pretty well above, so I won't further restate his words.
See: QualityElbow, QualityIsFree, QualitySoftwareManagement, WhatIsQuality
EditText of this page
(last edited December 30, 2009)
or FindPage with title or text search