Software metrics
The Softwaremetrie engaged in as part of field of software engineering with the measurement of properties of software and the interpretation of these measurements.
The aim of software metrics is to be able to make various statements about a software unit and / or the process of its creation with the help of objective and ideally automatically generated measures.
The questions include a number of topics that come into play in different phases of software development and are intended to provide answers to questions from different people. The following are the most common questions asked with some typical questions.
- Manager
- are mostly interested in a measure of the progress of a development. How much longer do we need to finish the software? How much of the work have we already done?
- Software developer
- ask similar questions to software metrics on a smaller scale, mostly against the background of improving their own performance and / or being able to provide better values for future effort estimates. How long do I need for a function block (function point)? How many elements does the implementation of a functionality consist of? Are certain criteria (e.g. maximum length of methods) observed in the developed software? How strongly is an element dependent on other elements (couplings)?
- Quality assured
- focus on metrics that provide information about the properties of the software itself, but also about the course of software development in terms of quality. How is the number of errors found in the software developing? In which modules do a particularly large number of errors occur (because there are typically more errors hidden there)? Is the software design good?
In order to be able to answer these questions, so-called software metrics are first required as a data source . These metrics provide measures of the examined software element. These can then - supplemented by further figures from the development process (required working hours, error reports, error distribution, etc.) - be used to provide answers to the questions raised above.
Criticism of software metrics
The measurement of software properties such as quality (i. E. Software Quality ) or complexity is very difficult. Since each metric can only take into account a few properties of the software, there is a risk that the software will be developed to influence the values recorded by the metric in the desired direction, for example in order to improve the "quality" of the software.
The metric takes into account, for example, the number of lines of code ( lines of code , LOC), so could a software developer - consciously or unconsciously - write their code so that it consists of more lines of code. If the number of software bugs found has an influence on the metric, this can lead to either many smaller bug fixes being combined into a single large one (or worse: certain bugs not being fixed at all), which reduces the number of bug fixes, or but that unnecessarily many small changes are published to artificially increase the number of bugfixes. This effect is also referred to as a metric-induced change in behavior and generally does not lead to the actual intention of the respective software metrics being used - e.g. B. Increase in software quality - is achieved.
Critics of software metrics therefore believe that any attempts to define a metric for “software quality” or the like using a mathematical formula are doomed to failure, since most metrics fail as soon as the software to be evaluated is “optimized” for the metric used.
literature
- Harry Sneed , Richard Seidl , Manfred Baumgartner: Software in numbers - the measurement of applications . 1st edition. Carl Hanser Verlag , 2010, ISBN 978-3-446-42175-2 .