System meter

The system meter (English term, therefore no hyphen) is a software metric , more precisely described, a system description metric. The System Meter measures all types of system descriptions, especially models and software source codes, with regard to their size and complexity. What exactly is meant by “size” and “complexity” can be seen from the definition of the “system meter” below.

The system meter is mainly used for measuring system scope models and business models or domain models . The purpose of these measurements is to estimate the effort and deadline for software projects, the aim of which is to implement, change or maintain the system described in the scope or business model. In these versions (scope-based: PRE System Meter, business model-based: DOME System Meter, detailed specification-based: SPEC System Meter) it is a so-called functional size measurement . In other forms (measurement of software source code) the system meter is used to measure the quality characteristics coupling (software development) and cohesion (computer science) (APSEC'97).

The System Meter will be used as an alternative to the Function Point evaluation method. It largely eliminates the known disadvantages of the function point method. In particular, the measurement effort is practically zero because the measurement is carried out fully automatically. A system specification in the form of an, at least semi-formal, model is a prerequisite for this. However, as they become more widespread in practice, these models are developed as standard artifacts in IT projects (status: 2012, e.g. domain-driven and agile software development and RUP , which use model-driven or model-based software Propagate development).

Like the function points, the PRE, DOME and SPEC system meters can be used in software development , in addition to their use in cost estimates, for benchmarking and generally to derive economic key figures for the productivity and quality of software. Among other things, a study with System Meter was published in the IEEE Computer Journal on the influence of reusable components on productivity. PRE and DOME System Meter are independent of the underlying technology of the application. The SPEC System Meter, on the other hand, refers to a description of the user interface. It is therefore subject, at least indirectly, to the influence of the technology used (programming language, GUI framework).

Standards

The author, Simon Moser, developed and published the System Meter in 1995 as part of his dissertation on measurement and cost estimation methods in software projects. Since the Meter system - in contrast to the Function Points - is a metric defined with a simple counting rule, there are no variants or deviations. This is one of the advantages of the System Meter over the Function Points.

method

requirements

(A) A system description is required, which is available in a standardized language (e.g. UML, OML, BPMN, EPK, C ++, Java, ...). Both the granularity (depth of detail) of the description and the system perspective,

from outside (= "User View", black box view)

or

from inside (= "Implementors View", white box view)

vary. For the use of the System Meter, only so-called “description objects” (that is, to put it somewhat more simply, the words used) and their definitional dependence on other “description objects” (ie the information with which other words a word is defined or paraphrased) need ultimately ) to be available.

(B) In very large existing descriptions of systems (operation and maintenance, or in the case of expansion projects on systems) it must be defined which number of "description objects" is relevant at all. Every "description object" included in the measurement must be relevant for the measurement purpose. Or to put it another way, using an analogy: If a room is to be repainted in a large building with many rooms, then you have to say / know / define which of the rooms (e.g. to estimate how much paint has to be bought) This is. And: then you just have to measure the size of this room. That sounds banal, but in the (abstract or at least mostly undocumented) world of business systems and software, it requires quite a bit of analysis. I.e. it is assumed that the relevant system is defined as a set of “description objects”.

Additional remark: Depending on the selected granularity and perspective of the description language, this can be more or less precise and also require more or less analytical effort. The aim here is to determine the appropriate form depending on the purpose of the measurement (e.g. on the one hand only a rough estimate or on the other hand a fixed price offer for a single (small) system change).

(C) As additional information, each "description object" must be divided into one of the following three reuse categories:

Part of a standard language
Part of a specific library ("component")
New.

Measurement

(1) Each description object receives the so-called number of “tokens” in its name as a so-called “external size”. Separators, the change from upper to lower case (and vice versa) and other rules are taken into account. Each description object has at least one token as an "external size" (this rule is important for "nameless" description objects, which also exist).

(2) If the description object is “new”, its definition is considered (= set of other “description objects”) and the sum of the “external variables” of all these “description objects” is calculated as a so-called “internal variable”.

(3) In order to calculate the total size of the system or part of the system under consideration

for all "new" description objects the "external size" and "internal size" are added up
for all library objects only the "external size" is added

The description objects that are already available in a standard language are not counted.

Estimate of effort

The system meter is mainly used for cost estimates of software projects. A statistical investigation has shown with high significance that the DOME System Meter is superior to that of the Function Points metric in terms of prognosis. For this purpose, both the system meters and the function points were measured in more than 30 projects.

The SEE Group (SEE = Software Engineering and Economics) has been collecting empirical data from completed projects since 1997. The SEE Group was founded in Melbourne, Australia in 1997 and is now a specialist group of the Swiss Informatics Society . The SEE Group is open to members from all over the world. The number of projects in the experience database is> 500 (as of 2009). They come from Switzerland, Australia, the USA, Canada, India and other countries. In addition to the data on the system size, the effort, the duration of the project and - which particularly promotes the usability of the data - an assessment of the artifacts present at the end of the project (in addition to the source text and the product) and, if necessary, the individual personnel expenses.

Here is a general note on parametric estimation methods: There are no 'magic estimation formulas' that can accurately calculate the personnel costs. Every estimation model must

based on empirical data, d. H. contain coefficients determined by statistical methods
make an indication of the estimation inaccuracy ("confidence interval")

Only such estimation models are capable of learning, i.e. H. Can be supplemented with experience data from one's own environment and is useful in practice. Do not trust any estimation formulas that are not supported by experience and confidence intervals.

The accuracies that can typically be achieved with the Meter system (95% confidence interval) are:

PRE System Meter: ± 35%
DOME System Meter: ± 12%
SPEC System Meter: ± 7%

(Source: The SEE Group)

Criticism and discussion

effort

As already mentioned, the measurement of the system meter does not require any effort (fully automated method). However, personnel costs must be used to develop the required models. Experience shows (see experience data from The SEE Group) that this is for the

PRE System Meter between 2 and 7% of the total project effort
DOME System Meter between 12 and 25% of the total project effort
SPEC System Meter (for projects) between 25 and 50% of the total project effort
SPEC System Meter (for modifications or small orders) between 13 and 23% of the total effort

needed.

Traceability and clarity

With a given model, the system meter value measured from it is always traceable and clear. However, in reality the implementation in a model (by different modelers) is not clear (and often not understandable). The measured system meter values vary in 95% of all cases between ± 1.8% on different models of the same real situation.

Topicality

The system meter metric can be adapted to modern modeling and software technology methods thanks to the generic definition. It is implemented especially for the object-oriented modeling language UML , which supports multiple inheritance and polymorphism.

literature

Saba Zamir (Ed.): Handbook of object technology . CRC Press, Boca Raton 1999, ISBN 0-8493-3135-8 , 9, Object Oriented Metrics.

Web links

Section for Software Estimation and Economics of the Swiss Informatics Society (www.si.ch)

Individual evidence

↑ Simon Moser, Vojislav B. Misic: Measuring Class Coupling and Cohesion: A Formal Metamodel Approach . In: Proceedings: Asia Pacific Software Engineering Conference and International Computer Science Conference: December 2-5, 1997, Hong Kong . IEEE Computer Society, Los Alamitos, CA, USA 1997, ISBN 0-8186-8271-X , pp. 31-39 , doi : 10.1109 / APSEC.1997.640159 .
^ Simon Moser, Oscar Nierstrasz: The effect of object-oriented frameworks on developer productivity . In: Computer . tape 29 , no. 9 , September 1996, ISSN 0018-9162 , p. 45-51 , doi : 10.1109 / 2.536783 .
^ Simon Moser: Metamodels of Object-Oriented Systems . In: Springer International (Ed.): Software - Concepts and Tools . tape 16 , no. 2 , July 1995, ISSN 0945-8115 , p. 63-80 ( theseegroup.org [PDF]).
^ Simon Moser, Brian Henderson-Sellers, Vojislav B. Mišić: Cost estimation based on business models . In: Journal of Systems and Software . tape 49 , no. 1 , December 15, 1999, p. 33-42 , doi : 10.1016 / S0164-1212 (99) 00064-3 .

[Misic-1] Simon Moser, Vojislav B. Misic: Measuring Class Coupling and Cohesion: A Formal Metamodel Approach . In: Proceedings: Asia Pacific Software Engineering Conference and International Computer Science Conference: December 2-5, 1997, Hong Kong . IEEE Computer Society, Los Alamitos, CA, USA 1997, ISBN 0-8186-8271-X , pp. 31-39 , doi : 10.1109 / APSEC.1997.640159 .

[Nierstrasz-2] Simon Moser, Oscar Nierstrasz: The effect of object-oriented frameworks on developer productivity . In: Computer . tape 29 , no. 9 , September 1996, ISSN 0018-9162 , p. 45-51 , doi : 10.1109 / 2.536783 .

[Moser-3] Simon Moser: Metamodels of Object-Oriented Systems . In: Springer International (Ed.): Software - Concepts and Tools . tape 16 , no. 2 , July 1995, ISSN 0945-8115 , p. 63-80 ( theseegroup.org [PDF]).

[4] Simon Moser, Brian Henderson-Sellers, Vojislav B. Mišić: Cost estimation based on business models . In: Journal of Systems and Software . tape 49 , no. 1 , December 15, 1999, p. 33-42 , doi : 10.1016 / S0164-1212 (99) 00064-3 .