Software metric

A software metric, metric or short, is a (usually mathematical ) function into a numerical value, also called the measure that maps a property of software. This formal comparison and assessment opportunities will be created.

Background

Formally speaking we not apply the metric to a software unit. The result is the measure. With software unit is meant in the majority of cases, the underlying source code. Since the source code is typically divided into one or a plurality of individual files, the metric can be used depending on the type of the whole or parts of the source code. There is also metrics, such as the function point analysis can be applied to the specification of this software to determine the costs for developing the software in advance.

In the form of the numerical value, the measured value, the metric is a measure of a characteristic, a quality characteristic of the software. You can have a functional relationship represent or be derived from a checklist. Simple metrics point to the size of the source code in lines or characters, more complex metrics try to assess the comprehensibility of source code. With a suitable number of different metrics can be assessed as consuming ( ie labor and cost- intensive ) the maintenance, development and subsequent testing of the software.

From a newly developed program not only certain functions are often required, but also quality characteristics such as maintainability, extensibility and understandability. Software metrics can not establish a correct implementation of the functions evaluate, they can predetermine if need be, how much effort will prepare about the creation of the software and how many errors occur.

If, during the long-term development of software metrics used regularly, negative trends, ie deviations from the quality target are detected and corrected early.

The interpretation of the data of a software metric is an object of the discipline of Softwaremetrie, there are the software metrics part of the base data for the interpretation dar.

Definition according to IEEE Standard 1061

"Software quality metric: A function Whose inputs are software data and Whose output is a single numerical value can be interpreted as did the degree to Which software poss esses a givenName attribute did Affects its quality. "

" A software quality metric is a function that maps a software unit in a numerical value. This calculated value is interpreted as the degree to which a quality characteristic of software unit. "

With " software unit " is usually the underlying source code meant. Since the source code is usually distributed to a odere multiple individual files, the metric can be applied to all or parts of source code ( depending on species). There is also metrics, such as the function point analysis can be applied to the specification of the software already.

Order of software metrics

Metrics use different aspects of the software being developed, the applied process model and the assessment of compliance.

Use

The use of metrics extends from the assessment of the development phases of the assessment phase of the results up to the assessment of the technologies used. The objective of using a metric in software development is the failure prediction and cost estimation, with a distinction between pretravel, propagate and retrospective use.

Restriction

Basically metrics remain manageable, one-dimensional. To force them to simplify. Usually this is achieved by dividing each metric is concentrated on a point of view. This means then imperative that other views are not served at the same time in the same quality.

  • Cost of software development (supply, cost minimization)
  • Increase in productivity (processes, experience curve )
  • Risks ( market position, time-to -market)
  • Certification ( Marketing)
  • Readability (maintenance, reuse)
  • Efficiency and effectiveness
  • Confidence ( residual error, MTBF, tests )
  • Estimates ( budget loyalty, punctuality )
  • Quality (reliability, accuracy )
  • Return on Investment ( maintainability, extensibility )

Classification

For the various aspects of the assessment, there are design metrics, economic metrics, communication, etc. metrics metrics can be assigned to different classes, which specify the subject of the measurement or assessment:

  • Of resources ( staff, time, cost )
  • Error
  • Communication effort
  • Size ( lines of code, reuse, procedures, ... )
  • Complexity
  • Readability ( style)
  • Design quality ( modularity, cohesion, coupling, ...)
  • Product quality ( test results, test coverage, ...)
  • Cost stability
  • Expense allocation
  • Productivity
  • Cost-to- date - fidelity
  • Development time
  • Average development time
  • Milestone Trend Analysis
  • Punctuality
  • Software Size
  • POC
  • Training effort
  • Customer satisfaction

Quality criteria

A metric from the production phase of the software alone is not a criterion. In the control quality characteristics are measured at the fulfillment of the requirements of the customer and its application. Here, the applicability of the results and the representation of the measured values ​​for the customer benefit of importance:

  • Objectivity: no subjective influences the measurement ends
  • Reliability: when repeating the same results
  • Scaling: Measurement result scale and Vergleichbarkeitsskala
  • Comparability: measure with other measures in relation settable
  • Economy: minimum cost
  • Usefulness: measurable fulfillment of practical needs
  • Validity: from measurable quantities close to other parameters ( difficult )

Metrics

Some of the more well-known metrics are:

  • Number of lines of code, Eng. Lines Of Code, short LOC.
  • The function point method for effort estimation in the analysis phase
  • COCOMO to calculate project costs from other measures
  • The cyclomatic complexity ( McCabe ) complexity for determining a program module
  • The Halstead metric to implement assessment in the design phase
  • Control flow -oriented metrics such as statement coverage, branch coverage, path coverage or condition coverage

By combining existing metrics new metrics are being developed constantly, partly reflecting new developments in software engineering. An example of this is the 2007 presented CRAP (Change Risk Analysis and Predictions ) metric to evaluate the maintainability of code.

Selection of appropriate metrics

In order to identify suitable metrics the Goal Question Metric ( GQM ) method can be used.

Procedure

75677
de