• 

People

• Prof. Dr. Kurt Schneider
• Anna Averbakh
• Olesia Brill
• Eric Knauss
• Sebastian Meyer
• Leif Singer
• Kai Stapel
• Tristan Wehrmaker

Research

• Requirements Engineering
• Software Quality
• FLOW

Teaching

Research » Software Quality →

Controlling and Steering Software Quality

Issues concerning the quality of software products still pose a significant problem. IEEE Std 610.12-1990 (IEEE Standard Glossary of Software Engineering Terminology) defines software-related quality as:

1. The degree to which a system, component, or process meets specified requirements.
2. The degree to which a system, component, or process meets customer or user needs or expectations.

Especially the latter aspect poses a problem because of the well-documented symmetry of ignorance between customers and developers. Consequently, requirements most likely will not be captured completely or will be captured at a level which is too abstract. A systematic requirements engineering including the capturing of use cases, elicitation techniques and user interface mockups helps to complete the requirements. Refining techniques such as quality models help to transfer abstract quality requirements (e. g. flexibility and usability) to a measurable level.

Quality assurance includes three different areas:

• Analytical quality assurance: A software product's quality is checked against criteria. If the software product cannot reach certain desired values, appropriate actions will be taken (most likely rework).
• Constructive quality assurance: Constructive quality assurance includes all methods which provide assistance in constructing error-free software beforehand.
• Organizational quality assurance: Organizational quality assurance's task is to provide an environment in which quality assurance can be established. Organizational quality assurance includes e.g. a quality management organization, training courses and development processes.

A great number of software companies conduct Quality Gates to analyze the quality of their software products and to take actions in time. The following section explains the Quality Gate concept in more detail.

The Quality Gate Concept

Quality Gates are significant milestones and decision points within a project [1, 2]. At each Quality Gate products are evaluated against predefined and quality focused criteria. Based on the fulfillment of these criteria gatekeepers (which are usually part of the quality management) make a decision whether a project may proceed or not. Consequently, the quality situation of a project can be uncovered to the management and actions can be made in time. Quality Gates are often used in certain domains, e. g. in car development or in serial production of industrial goods. In the domain of software development Quality Gates are used cumulatively in the last years.

A software company can use Quality Gates in two ways (we will refer to them as strategies):

• Quality Gates as a quality guideline: The same set of Quality Gates (and criteria) is applied to all projects resulting in a comparable and at least an equal minimum quality level in all those projects.
• Quality Gates as a flexible quality strategy: A suitable Quality Gate process is applied to each project to exactly meet the project's needs.

Figure 1 depicts a typical waterfall process, while figure 2 shows a possible network of Quality Gates. Obviously not every activity must be completed with a Quality Gate. It is also possible to run a project without any Quality Gate. Especially for small projects Quality Gates pose an extreme overhead. On the other hand large and risky projects require the maximum set of Quality Gates in order to ensure product quality.

Assessing the Quality of Implementation

A Quality Gate reference process encapsulates special structures, activities, methods, roles and documents, which can be implemented by a software company individually in order to satisfy their quality and business goals. This Quality Gate reference process then can be tailored to meet the needs of a special project. The result is a Quality Gate process, containing a set of criteria and a set of Quality Gates.

The main idea of our assessment concept is very close to the idea of process maturity models such as SPICE and CMMI: it does not matter how a software company implemented a Quality Gate concept because the actual implementation depends on the company's size and its domain. Rather it is only relevant to rate the degree of implementation of a each concept. Nonetheless, a faulty implementation of a concept can cause problems even if the concept is fully implemented. Based on this idea all concepts can be assessed on a three-valued ordinal scale. The following listing explains the values of the scale.

A ● denotes a fully implemented concept. This means that it is clear, how the concept has to be mapped to a project in order to be applicable. A fully implemented concept must be fixed within a process description. For example a role with a clear and fixed ability profile is a fully implemented concept.

A ∗ denotes a partly implemented concept. A partly implemented concept must be interpreted in order to be applicable. Partly implemented concepts often are fixed as an abstract description or a written description is missing, but is intuitively clear how the concept has to be applied. Sometimes it is necessary to leave a concept abstract because it must be applied to different business units of the software company. For example the protocol concept is partly implemented if most people in a company know how to write a protocol but there is no fixed guideline.

A ο denotes an unimplemented concept. Reasons could be:

• The process management forgot to implement the concept.
• The concept was left unimplemented, because the Quality Gate reference process must be used in different business units in the company and each business unit has to interpret it individually.
• The concept was intentionally left unimplemented, because the process management regards it as unimportant.

Figure 3 shows an assessment of different Quality Gate reference processes.



Different consequences might arise from shortcoming in the implement Quality Gate reference process. For example an unimplemented gate network concept might result in a lower comparability and quality level, because different sets of Quality Gates might be applied.

References

1. Flohr, T. NetQGate - Tool Support for Quality Gate Processes, in 9th International Conference on Quality Engineering in Software Technology (CONQUEST). 2006. Berlin: dpunkt.verlag.
2. Knauss, E. and T. Flohr. Managing Requirement Engineering Processes by Adapted Quality Gateways and critique-based RE-Tools, in Workshop on Measuring Requirements for Project and Product Success at 19th International Conference on Advanced Information Systems Engineering. 2007. Palma de Mallorca, Spain.