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

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)

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.

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.

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.

Total quality management Main elements

Total quality management Another view to TQM

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

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

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.

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.

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.

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.

McCall's quality model

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.

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

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?

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

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

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

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

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Software quality models

Thanks…