1. Source & Courtesy: Doc. S. Dapkūnas
Software Quality
Source & Courtesy: Doc. S. Dapkūnas

2. Total quality management
Concept TQM originated in 1985.
Main focus on: to create such work culture when all organization members participate in improving processes, products and services.
Main authors:
Crosby (1979), Deming (1986), Feigenbaum (1961, 1991), Ishikawa (1985), Juran and Gryna (1970)

3. Total quality management
has many meanings,
it means the style with the goal: the success joining quality with customer satisfaction,
the base – to create the quality culture.

4. Total quality management
The examples of successful use in computer industry:
Hewlett-Packard’s Total Quality Control (TQC),
Motorola’s Six Sigma Strategy,
IBM’s Market Driven Quality.

5. Total quality management
Summary:
Customer focus: the objective is to achieve total customer satisfaction.
Process: the objective is to reduce process variations and to achieve continuous process improvement. Through process improvement, product quality will be enhanced.
Human side of quality: the objective is to create a companywide quality culture.
Measurement and analysis: the objective is to drive continuous improvement in all quality parameters by the goal-oriented measurement system.

6. Total quality management
Main elements

7. Total quality management
Another view to TQM

8. Software quality models
McCall's quality model,
Boehm model,
FURPS/FURPS+,
Dromey quality model,
ISO quality model.

9. McCall's quality model
One of the first software quality models (1977)

10. McCall's quality model
Based on three type characteristics with hierarchic dependency:
factors – external software view for users,
criteria – internal software view for developers,
Measures (metrics) - are used for software measurement.

11. McCall's quality model (factors - 1)
Product operations:
correctness – the functionality matches the specification;
reliability – the extent to which the system fails;
efficiency – system resource (including CPU, disk, memory, network) usage;
integrity – protection from unauthorized access;
usability – ease of use.

12. McCall's quality model (factors - 2)
Product revision:
maintainability – the ability to find and fix a defect,
flexibility – the ability to make changes required as dictated by the business,
testability – the ability to validate the software requirements.

13. McCall's quality model (factors - 3)
Product transition:
portability – the ability to transfer the software from one environment to another,
reusability – the ease of using existing software components in a different context,
interoperability – the extent, or ease, to which software components work together.

14. McCall's quality model

15. McCall's quality model
The quality measure aims to capture some of the aspects of a quality criterion.
The quality factors synthesized should provide a complete software quality picture.
The quality is evaluated by answering “yes” and “no” questions and summarizing the answers.

16. Boehm's quality model
Defined in A hierarchical model of software quality characteristics.
There are characteristics of three levels:
highest level,
intermediate level,
primitive.

17. Boehm's quality model
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?

18. Boehm's quality model
The intermediate level characteristic represents 7 quality factors:
portability,
reliability,
efficiency,
usability,
testability,
understandability,
flexibility (modifiability).

19. Boehm's quality model
The lowest level structure of the characteristics hierarchy is the primitive characteristics metrics hierarchy.

20. Comparison of two models
Criteria/goals
McCall,
1977
Boehm,
1978
Correctness *
Reliability
Integrity
Usability
Effiency
Maintainability
Testability
Interoperability
Flexibility
Reusability
Portability
Clarity
Modifiability
Documentation
Resilience
Understandability
Validity
Functionality
Generality
Economy

21. FURPS/FURPS+ quality model
FURPS - Functionality, Usability, Reliability, Performance, Supportability.
FURPS model originally presented by Robert Grady in eighties and presented in It was extended by Rational Software (IBM Rational Software) into FURPS+.

22. FURPS/FURPS+ quality model
FURPS stands for:
Functionality – feature sets, capabilities and security;
Usability – human factors, aesthetics, consistency in the user interface, online and context sensitive help, wizards and agents, user documentation, and training materials;
Reliability – frequency and severity of failure, recoverability, predictability, accuracy, and mean time between failure;
Performance – conditions on functional requirements such as speed, efficiency, availability, accuracy, throughput, response time, recovery time, and resource usage;
Supportability – testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, localizability (internationalization).

23. FURPS/FURPS+ quality model
The FURPS-categories are of two different types:
Functional (F)
Non-functional (URPS).
These categories can be used as both product requirements as well as in the assessment of product quality.

24. Dromey's quality model Proposed in 1995. Main presumptions:
quality evaluation differs for each product,
a more dynamic idea for modelling the process is needed to be wide enough to apply for different systems,
model is focusing on the relationship between the quality attributes and the sub-attributes,
attempting to connect software product properties with software quality attributes.

25. Dromey's quality model Main elements:
Product properties that influence quality.
High level quality attributes.
Means of linking the product properties with the quality attributes.

26. Dromey's quality model
The Model is structured around a 5 step process:
Chose a set of high-level quality attributes necessary for the evaluation.
List components / modules in your system.
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).
Determine how each property effects the quality attributes.
Evaluate the model and identify weaknesses.

27. Software quality according to IEEE
The degree to which a system, component, or process meets specified requirements.
The degree to which a system, component, or process meets customer or user needs or expectations.

28. Software quality according to Pressman
Software quality is conformance to:
explicitly stated functional and performance requirements,
explicitly documented development standards,
implicit characteristics that are expected of all professionally developed software.

29. Software quality according to Pressman
The foundation for quality assessment is the software requirements specification.
Lack of conformance to requirements is lack of quality.
Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result.
The software has to meet implicit requirements too.

30. Difference between IEEE and Pressman views
According to IEEE definition the main thing in the quality assurance is to satisfy the user.
Pressman emphasizes the software development process.
The both definitions agree that a high quality is impossible without the conformance to specification requirements.

31. Summary for the models
There exist many different quality models for software product.
The factors used in the models overlap and more complete definitions are needed for their use.
The models do not agree on terminology or even on what factors should be included, scopes of definitions vary.
It is developed ISO quality model. It tries to summarize the experience from different models.

32. The comparison of the models
Mac Call (1977)
Boehm (1978)
Evans & Marciniak (1987)
Deutsch & Willis (1988)
ISO 9126 (1991)
FURPS+ (1992)
Dromey (1992)
SEI (1995)
SQuaRE (2011)
Maintainability x
Flexibility
Testability
Correctness
Efficiency
Reliability
Integrity
Usability
Portability
Reusability
Interoperability
Human Engineering
Understandability
Modifiability
Functionality x1
Performance
Supportability
Design Requirements
Implementation Requirements
Interface Requirements
Physical Requirements
Verifiability
Expandability
Survivability
Safety
Manageability
Dependability
Security  x 28 11 7 12 15 6 9 4 8

33. Software quality models

34. Thanks…