Software quality
" Software quality is understood to mean the entirety of the features and characteristic values of a software product that relate to its suitability to meet specified or assumed requirements" (actual / target).
Quality models
concept
The notion of software quality itself is inoperable; H. not directly applicable in practice. That is why there are quality models that concretize the term and operationalize it through further detailing. This creates a tree (or network ) of terms and sub-terms.
The quality characteristics are called factor in English , a quality part characteristic is called criterion and the quality indicators are metrics . This is why such quality models appear in the literature as "FCM models" (e.g. FURPS , Boehm et al. 1978, DGQ -modell 1986, McCall et al. 1977). The leaf nodes in the tree of the quality model, the quality indicators, should be act observable or measurable facts. For example, software metrics can be used here.
Example ISO / IEC 9126
Quality models exist, for example, in the form of the ISO standard ISO / IEC 9126 . This standard defines the quality criteria for software shown in the adjacent graphic in a two-tier structure. Then it becomes clear that software quality is understood to mean more than just freedom from defects (which can essentially be assigned to the criterion of functionality).
The quality features name different properties that the software should have. These are at the top level:
- functional properties, "the basic properties for the functions of the software" (what it should functionally perform and how),
- non-functional properties that characterize "the operational behavior of the software product in daily use."
While the requirements that the software product should meet during its operation must be classified in the non-functional properties for reliability, usability and efficiency, the quality criteria for changeability ( maintainability ) and transferability to the internal nature of the software (mainly . of the source text ), which should enable / simplify any necessary adaptation measures.
These criteria represent a framework that can be concretized for individual software products in individual specifications in order to be taken into account in software development.
Ensuring the software quality
Various process models and methods exist to ensure that the software meets the requirements with regard to the various quality features (= quality assurance , QA for short) .
Some models can be assigned to the concept of process quality . This assumes that a high quality process of product creation favors the creation of high quality products. Therefore, the following models place quality requirements on the process in which the software is developed.
However, there are also procedural models , such as the goal-question-metric approach, which lead to individual quality models.
Models and methods
Some models:
- Organizational quality models , for example the Capability Maturity Model (CMM) or Automotive SPICE
- Process models, such as
- Capability Maturity Model Integration
- the Rational Unified Process (RUP)
- the V model
- the V² model, also known as the W model
- Hardware in the Loop (HIL)
Some methods:
- iterative software development
- Spiral model
- Refactoring
- Test-driven development
- different test types and methods for software tests
Some of the models and the methods can be combined with one another. The models of agile processes such as extreme programming are particularly interesting because they use synergy effects from the simultaneous use of different methods.
QA focus on software testing
Testing is an important part of software development for software quality. The quality of the software created or modified / further developed is checked with different methods (e.g. keyword-driven testing , risk-based testing, data-driven testing, ...), process models , test types , test levels , etc. prior to handover for actual use . The literature (here) calls this “creating trust in the quality of the software” and explains: “Tests are not the only measure in quality management in software development, but they are often the last possible; Quality cannot be 'tested'. " .
Accordingly, a distinction is made between constructive and analytical measures with regard to quality assurance measures (see graphic).
- The constructive measures include, for example, disciplines such as a systematic project definition and project goal definition as well as a detailed (and bindingly approved by the project clients) requirements analysis , the use of established or defined programming standards , etc.
- The analytical measures can be divided into
- static measures (see static code analysis such as code reviews ), in which only the code of the application created is checked without the application actually being executed. Depending on the type of measure, the review takes place at different times, e.g. B. immediately during code development (see pair programming ) or only before release for user tests.
- dynamic tests in which the generated application is actually executed under a wide variety of constellations (see also test case ) and the generated results are checked.
The quality of the software is thus in different states at different times during its development and should meet all defined requirements / criteria when it is actually used productively.
Software type-specific quality features
The quality criteria for software can differ in their meaning depending on the software type, they cannot always be assessed / weighted uniformly, and additional detailed requirements can also arise. As a result, a different procedure is sometimes necessary or possible during production and also during quality assurance.
For example, while criteria such as correctness and correctness (partial criteria for functionality ) generally have the same or similar importance / weighting for all software types , this can be different for other criteria depending on the type. Such deviations / special features in the quality criteria are described below by way of example and with reference to the quality criteria for software in accordance with ISO / IEC 9126 :
Standard software
For software of this type, so that it can be used by different users , the criterion of portability (adaptability) is particularly important. The functional scope of the standard software can thus be adapted (through parameterization ) to the functional scope required by the company.
System software
Criteria for efficiency (consumption behavior, time behavior) can be particularly important for this type of software; likewise the reusability and the compatibility (= executability in different system environments ).
Game software
Here comes efficiency of particular importance, for example, make the best use of graphics cards ( "smooth" image movements). There are also special requirements with regard to usability (such as uniformity, simplicity).
Mobile device software
- Functionality
Regarding the security sub-criterion : Compared to applications on stationary computers, the user's movement profiles are also generated as sensitive data.
- Efficiency
In the individual criterion of consumption behavior , the use of processor performance , main memory and online data volume is of particular importance. Low battery consumption can ensure the longest possible runtime.
- Changeability
The main difference to workstation computers is the variety of platforms and their faster further development, which requires simple / quick changes to the software.
This flexibility can be achieved by using frameworks (such as PhoneGap and Xamarin ) on different operating systems and environments and can be easily installed ( installability ). Another option to achieve platform independence are so-called web apps , i.e. applications that are displayed and operated in a web browser.
- Transferability
Mobile devices are characterized by display areas of different sizes (from 1 to 10 inches ). Applications must be operable on small displays and be able to use larger displays meaningfully. Switching between portrait and landscape format is common on mobile platforms, but the exception on workstations.
Most of the time, no real keyboard is available, keyboard input is slower, there are fewer keys and key combinations are unusual. On the other hand, there are often alternative input options that need to be stored with functions.
- conformity
For this quality criterion - that in all of the above Criteria groups applies - for the example of usability / usability, the design guidelines / specifications provided by manufacturers of mobile systems for a large number of applications represent a good basis for the design. For examples see Google, Apple and Microsoft
literature
- Ralf Kneuper, Ernest Wallmüller (ed.): CMMI in practice. Case studies to improve development processes with CMMI . dpunkt, Heidelberg 2009, ISBN 978-3-89864-571-3 .
- Ernest Wallmüller: Software quality management in practice. Software quality through the management and improvement of software processes . 2nd Edition. Hanser, Munich et al. 2001, ISBN 3-446-21367-8 .
Web links
- International Software Testing Qualifications Board
- German Testing Board
- Global Association for Software Quality
- Working group for software quality and advanced training
- International Software Quality Institute
Individual evidence
- ↑ a b Helmut Balzert: Textbook of software technology . tape 2 : software management, software quality assurance, business modeling . Spektrum Akademischer Verlag, Heidelberg 1998, ISBN 3-8274-0065-1 , p. 257 .
- ↑ Jim A. McCall, Paul K. Richards, Gene F. Walters: Factors in software quality . Vols I-III. Rome Air Development Center, Griffiss Air Force Base New York 1977 ( Volume I, PDF ).
- ↑ Torsten Cleff: Basic knowledge of testing software. Herdecke, Witten 2010, ISBN 978-3-86834-012-9 , [1] p. 68.
- ↑ Martin Pol, Tim Koomen, Andreas Spillner: Management and optimization of the test process. A practical guide to successfully testing software with TPI and TMap . dpunkt, Heidelberg 2002, ISBN 3-89864-156-2 .
- ↑ New test techniques for the next-generation apps. In : entwickler.de. August 2, 2013, accessed August 11, 2015 .
- ↑ a b Boles, 2.1 Basics of Software Development [2]
- ↑ Encyclopedia of Business Information Systems [3] Parameterization of standard software
- ↑ Mobile apps collect more data than the police. Retrieved July 31, 2015 .
- ↑ https://www.pagerduty.com/blog/mobile-monitoring-reliability/
- ↑ http://www.imn.htwk-leipzig.de/~weicker/pmwiki/pmwiki.php/Main/%DCbertragbarkeit ( page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.
- ↑ - ( Memento of the original from April 21, 2017 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ Google material design [4]
- ↑ Apple Mobile HIG [5]
- ↑ Microsoft design [6]
