Below are few quality models from the so called Quality Management Gurus.
McCall’s Quality model (1977)
Also called as General Electrics Model. This model was mainly developed for US military to bridge the gap between users and developers. It mainly has 3 major representations for defining and identifying the quality of a software product, namely
Product Revision : This identifies quality factors that influence the ability to change the software product.
(1) Maintainability : Effort required to locate and fix a fault in the program within its operating environment.
(2) Flexibility : The ease of making changes required as dictated by business by changes in the operating environment.
(3) Testability : The ease of testing program to ensure that it is error-free and meets its specification, i.e, validating the software requirements.
Product Transition : This identifies quality factors that influence the ability to adapt the software to new environments.
(1) Portability : The effort required to transfer a program from one environment to another.
(2) Re-usability : The ease of reusing software in a different context.
(3) Interoperability: The effort required to couple the system to another system.
Product Operations : This identifies quality factors that influence the extent to which the software fulfills its specification.
(1) Correctness : The extent to which a functionality matches its specification.
(2) Reliability : The systems ability not to fail/ the extent to which the system fails.
(3) Efficiency : Further categorized into execution efficiency and storage efficiency and generally means the usage of system resources, example: processor time, memory.
(4) Integrity : The protection of program from unauthorized access.
(5) Usability : The ease of using software.
McCall’s Quality Model
Boehm’s Quality model (1978):
Boehm’s model is similar to the McCall Quality Model in that it also presents a hierarchical quality model structured around high-level characteristics, intermediate level characteristics, primitive characteristics – each of which contributes to the overall quality level.
The high-level characteristics represent basic high-level requirements of actual use to which evaluation of software quality could be put – the general utility of software. The high-level characteristics address three main questions that a buyer of software has:
• As-is utility : How well (easily, reliably, efficiently) can I use it as-is?
• Maintainability: How easy is it to understand, modify and retest?
• Portability : Can I still use it if I change my environment?
The intermediate level characteristic represents Boehm’s 7 quality factors that together represent the qualities expected from a software system:
• Portability (General utility characteristics): Code possesses the characteristic portability to the extent that it can be operated easily and well on computer configurations other than its current one.
• Reliability (As-is utility characteristics): Code possesses the characteristic reliability to the extent that it can be expected to perform its intended functions satisfactorily.
• Efficiency (As-is utility characteristics): Code possesses the characteristic efficiency to the extent that it fulfills its purpose without waste of resources.
• Usability (As-is utility characteristics, Human Engineering): Code possesses the characteristic usability to the extent that it is reliable, efficient and human-engineered.
• Testability (Maintainability characteristics): Code possesses the characteristic testability to the extent that it facilitates the establishment of verification criteria and supports evaluation of its performance.
• Understandability (Maintainability characteristics): Code possesses the characteristic understandability to the extent that its purpose is clear to the inspector.
• Flexibility (Maintainability characteristics, Modifiability): Code possesses the characteristic modifiability to the extent that it facilitates the incorporation of changes, once the nature of the desired change has been determined.
The lowest level structure of the characteristics hierarchy in Boehm’s model is the primitive characteristics metrics hierarchy. The primitive characteristics provide the foundation for defining qualities metrics – which was one of the goals when Boehm constructed his quality model. Consequently, the model presents one more metrics supposedly measuring a given primitive characteristic.
Though Boehm’s and McCall’s models might appear very similar, the difference is that McCall’s model primarily focuses on the precise measurement of the high-level characteristics “As-is utility”, whereas Boehm’s quality model is based on a wider range of characteristics with an extended and detailed focus on primarily maintainability.
Dromey’s Quality model(1995):
Dromey has built a quality evaluation framework that analyzes the quality of software components through the measurement of tangible quality properties. Each artifact produced in the software life-cycle can be associated with a quality evaluation model. Dromey gives the following examples of what he means by software components for each of the different models:
• Variables, functions, statements, etc. can be considered components of the Implementation model;
• A requirement can be considered a component of the requirements model;
• A module can be considered a component of the design model;
According to Dromey, all these components possess intrinsic properties that can be classified into four categories:
• Correctness : Evaluates if some basic principles are violated.
• Internal : Measure how well a component has been deployed according to its intended use.
• Contextual : Deals with the external influences by and on the use of a component.
• Descriptive : Measure the descriptiveness of a component (for example, does it have a meaningful name.) Dromey proposes a product based quality model that recognizes that quality evaluation differs for each product and that a more dynamic idea for modeling the process is needed to be wide enough to apply for different systems. Dromey is focusing on the relationship between the quality attributes and the sub-attributes, as well as attempting to connect software product properties with software quality attributes.
This quality model presented by R. Geoff Dromey is most recent model which is also similar to McCall’s and Boehm’s model. Dromey proposes a product based quality model that recognizes that quality evaluation differs for each product and that a more dynamic idea for modeling the process is needed to be wide enough to apply for different systems. Dromey focuses on the relationship between the quality attributes and the sub-attributes, as well as attempts to connect software product properties with software quality attributes.
1) Product properties that influence quality.
2) High level quality attributes.
3) Means of linking the product properties with the quality attributes.
Dromey’s Quality Model is further structured around a 5 step process:
1) Choose a set of high-level quality attributes necessary for the evaluation.
2) List components/modules in your system.
3) Identify quality-carrying properties for the components/modules (qualities of the component that have the most impact on the product properties from the list above).
4) Determine how each property effects the quality attributes.
5) Evaluate the model and identify weaknesses.