User:Reginald Sachs/sandbox

Der System Meter ist eine Softwaremetrik bzw. präziser umschrieben eine Systembeschreibungsmetrik. Mit dem System Meter werden alle Arten von Systembeschreibungen insb. auch Modelle und Software-Quellcode bezüglich Grösse und Komplexität gemessen. Was genau unter 'Grösse und Komplexität' zu verstehen ist, wird aus der Definition des System Meter weiter unten ersichtlich.

Seine Hauptanwendung hat der System Meter bei der Messung von System Scope Modellen und Business Modellen bzw. Domänenmodellen. Der Zweck dieser Messungen besteht in der Aufwand- und Terminschätzung von Software-Projekten, deren Ziel die Implementierung, Änderung oder Wartung des im Scope oder Business Modell beschriebenen Systems ist. In diesen Ausprägungen (Scope-basiert: PRE System Meter, Business Modell - basiert: DOME System Meter, Detailspezifikation-basiert: SPEC System Meter) ist er ein sog. Functional Size Measurement. In anderen Ausprägungen (Messung von Software Source Code) wurde der System Meter für die Messung der Qualitätsmerkmale Coupling und Cohesion angewendet (^[1]APSEC'97).

Er kann als Alternative zum Function Point Bewertungsverfahren eingesetzt werden. Die bekannten Nachteile des Function Point Verfahrens behebt der System Meter weitgehend. Insbesondere ist der Messaufwand praktisch 0, weil die Messung voll-automatisch vorgenommen wird. Allerdings wird als Voraussetzung eine Systemspezifikation in der Form eines zumindest semi-formalen Modells vorausgesetzt. Diese Modelle werden jedoch mit zunehmender Verbreitung in der Praxis ohnehin als Standard-Artefakte in IT-Projekten erarbeitet (Stand: 2012, z.B. Domänen-getriebene und agile Software-Entwicklung und RUP, welche die modell- getriebene oder -basierte Software-Entwicklung propagieren).

Wie die Function-Points können die PRE, DOME und SPEC System Meter in der Softwareentwicklung neben der Anwendung in Aufwandsschätzungen auch für das Benchmarking und allgemein zur Ableitung von ökonomischen Kennzahlen zur Produktivität und Qualität von Software herangezogen werden. Unter anderem wurde zum Einfluss von wiederverwendbaren Komponenten auf die Produktivität eine Untersuchung mit System Meter im IEEE Computer Journal publiziert ^[2]. PRE und DOME System Meter sind unabhängig von der zu Grunde liegenden Technologie der Anwendung. Der SPEC System Meter bezieht sich auf eine Beschreibung der Benutzeroberfläche und unterliegt deshalb zumindest indirekt den Technologieeinflüssen (Programmiersprache, GUI-Framework).

Standards

Simon Moser entwickelte und publizierte den System Meter im Jahr 1995 ^[3]SCT'94 im Rahmen seiner Dissertation zu Mess- und Aufwandschätzverfahren in Software-Projekten. Da es sich beim System Meter -im Unterschied zu den Function Points- um eine mit einer einfachen Zählregel definierte Metrik handelt, gibt es keine Varianten oder Abweichungen. Dies ist einer der Vorteile der System Meter gegenüber den Function Points.

Methode

Voraussetzungen

(A) Es wird eine Systembeschreibung vorausgesetzt, welche in einer normierten Sprache vorliegt (z.B. UML, OML, BPMN, EPK, C++, Java, ...). Dabei kann sowohl die Granularität (Detailtiefe) der Beschreibung als auch der System-Perspektive,

von aussen (= "User View", black-box-view)

oder

von innen (= "Implementors View", white-box-view)

varieren. Für die Anwendung des System Meter müssen letztlich nur sog. 'Beschreibungsobjekte' (das sind --etwas vereinfacht ausgedrückt-- die verwendeten Wörter) und deren definitiorische Abhängigkeit zu anderen 'Beschreibungsobjekten' (d.h. die Information, mit welchen anderen Wörtern ein Wort definiert oder umschrieben wird) vorhanden sein.

(B) In sehr grossen bestehenden Beschreibungen von Systemen (Betrieb- und Wartung bzw. bei Erweiterungsvorhaben an Systemen) muss definiert sein, welche Menge an 'Beschreibungsobjekten' überhaupt relevant ist. Jedes in die Messung einbezogene 'Beschreibungsobjekt' muss für den Messzweck relevant sein. Oder noch anders ausgedrückt: Wenn in einem grossen Gebäude mit vielen Zimmern ein Zimmer neu gestrichen werden soll, dann müssen Sie (z.B. um abzuschätzen wieviel Malfarbe Sie kaufen müssen) sagen/wissen/definieren, welches der Zimmer das ist. Und: dann müssen Sie nur die Grösse dieses Zimmers messen. Das tönt banal, erfordert aber in der (abstrakten oder zumindest meist undokumentierten) Welt von geschäftlichen Systemen und Software bereits einiges an Analyse. D.h. es wird vorausgesetzt, dass das relevante System als Menge von 'Beschreibungsobjekten' definiert ist.

Zusatzbemerkung: Je nach gewählter Granularität und Perspektive der Beschreibungssprache kann das mehr oder weniger präzise sein und aber auch mehr oder weniger analytischen Aufwand erfordern. Hier gilt es, je nach Zweck der Messung (z.B. einerseits nur Grobschätzung oder andererseits Fixpreisofferte einer einzelnen (kleinen) Systemänderung) die geeignete Form zu bestimmen.

(C) Als zusätzliche Information muss jedes 'Beschreibungsobjekt' in eine der folgenden 3 Wiederverwendungs-Kategorien eingeteilt sein:

Teil einer Standard-Sprache
Teil einer spezifischen Bibliothek ("Komponente")
Neu

Messung

(1) Jedes Beschreibungsobjekt erhält die sog. Anzahl 'Token' in seinem Namen als sog. 'Externe Grösse' zugeordnet. Dabei werden Trennzeichen, der Wechsel von Gross- zu Kleinschreibung (und umgekehrt) und weitere Regeln berücksichtigt. Jedes Beschreibungsobjekt hat mindestens 1 als 'Externe Grösse' (Diese Regel ist wichtig für 'namenlose' Beschreibungsobjekte, welche es auch gibt).

(2) Sofern das Beschreibungsobjekt 'Neu' ist, wird seine Definition angeschaut (= Menge anderer 'Beschreibungsobjekte') und als sog. 'Interne Grösse' die Summe der 'Externen Grössen' aller dieser 'Beschreibungsobjekte' berechnet.

(3) Um die Gesamtgrösse des betrachteten Systems oder Systemteils zu berechnen, werden

für alle 'neuen' Beschreibungsobjekte die 'Externe Grösse' und 'Interne Grösse' summiert
für alle Bibliotheks-Objekte nur die 'Externe Grösse' summiert

Die Beschreibungsobjekte, welche bereits in einer Standard-Sprache vorhanden sind, werden nicht gezählt.

Beispiel

TODO

Voraussetzung: UML-Modell eines Change

Messung

Aufwandsschätzung

Der System Meter wird hauptsächlich für Aufwandschätzungen von Software-Projekten angewendet. Eine statistische Untersuchung ^[4]hat mit hoher Signifikanz gezeigt, dass die DOME System Meter die bessere Prognostik-Metrik ist als Function Points. Dazu wurden in mehr als 30 Projekten sowohl die System Meter als auch die Function Points gemessen.

Seit 1997 sammelt der Verein 'The SEE Group' (SEE = Software Engineering and Economics) empirische Daten aus abgeschlossenen Projekten. The SEE Group wurde 1997 in Melbourne, Australien, gegründet und ist mittlerweile eine Fachgruppe der Schweizer Informatik Gesellschaft [1]. The SEE Group ist offen für Mitglieder aus aller Welt. Die Anzahl Projekte in der Erfahrungsdatenbank ist >500 (Stand 2009). Die Projekte stammen aus 'aller Welt'. Neben den Daten zur Systemgrösse werden Aufwände, die Projektdauer und --was die Daten-Nutzbarkeit besonders fördert-- eine Beurteilung der bei Projektabschluss vorhandenen Artefakte (zusätzlich zum Source Code und Build) und ggf. die einzeln dafür aufgewendeten Personalleistungen erhoben.

Kritik und Diskussion

Aufwand

Wie bereits erwähnt erfordert die Messung der System Meter keinen Aufwand (voll-automatisierte Methode). Allerdings muss für die Erarbeitung der vorausgesetzten Modelle Personalaufwand eingesetzt werden. Die Erfahrung zeigt (siehe Erfahrungsdaten von The SEE Group), dass dies für die

PRE System Meter zwischen 2 - 7% des Gesamtprojektaufwands
DOME System Meter zwischen 12 - 25% des Gesamtprojektaufwands
SPEC System Meter (bei Projekten) zwischen 25 - 50% des Gesamtprojektaufwands
SPEC System Meter (bei Changes/Kleinaufträgen) zwischen 13 - 23% des Gesamt-Changeaufwands

benötigt.

Nachvollziehbarkeit und Eindeutigkeit

Bei gegebenem Modell ist der daraus gemessene System Meter - Wert immer nachvollziehbar und eindeutig.

Allerdings ist bei gegebener realer Situation die Umsetzung in ein Modell (durch verschiedene Modellierer) nicht eindeutig (und oft auch nicht nachvollziehbar). Die gemessenen System Meter - Werte varieren dabei in 95% aller Fälle zwischen +/-1.8% an unterschiedlichen Modellen der gleichen realen Situation.

Aktualität

Die System Meter - Metrik kann sich durch die generische Definition an moderne Modellierungs- und Software-Technik-Methoden anpassen. Sie ist insbesondere für die objekt-orientierte Modellierungssprache UML implementiert, welche Mehrfach-Vererbung und Polymorphismus unterstützt.

Siehe auch

Weblinks

Fachgruppe für Software Estimation und Economics der Schweizer Informatik Gesellschaft (www.s-i.ch)

Literatur

Saba Zamir (ed.): Handbook of Object Technology (chpt. 9, Object Oriented Metrics), CRC Press, December 1998 (1,168 Pages), ISBN 9780849331350

Einzelnachweise

^ Misic V. B., Moser S.: Measuring Class Coupling and Cohesion: A Formal Metamodel Approach, Proc. of APSEC'97 and ICSC'97 (December 1997), pp. 31-39 (ISSN 0-8186-8271-X/97 - IEEE)
^ Nierstrasz O, Moser S: The Effect of Object-Oriented Frameworks on Developer Productivity, IEEE Computer (vol. 29, no. 9, September 1996), pp. 45-51 (ISSN 0018-9162/96 - IEEE)
^ Moser S: Metamodels of Object-Oriented Systems, Software - Concepts and Tools (July 1995), pp. 63-80 (ISSN 0945-8115/95 - Springer Intl.)
^ Henderson-Sellers B., Moser S., Misic V. B.: Cost estimation based on business models. Journal of Systems and Software 49(1): pp. 33-42 (1999)

Kategorie:Software-Metrik Kategorie:Anforderungsmanagement Kategorie:Projektmanagement

en:System Meter

[Misic-1] Misic V. B., Moser S.: Measuring Class Coupling and Cohesion: A Formal Metamodel Approach, Proc. of APSEC'97 and ICSC'97 (December 1997), pp. 31-39 (ISSN 0-8186-8271-X/97 - IEEE)

[Nierstrasz-2] Nierstrasz O, Moser S: The Effect of Object-Oriented Frameworks on Developer Productivity, IEEE Computer (vol. 29, no. 9, September 1996), pp. 45-51 (ISSN 0018-9162/96 - IEEE)

[Moser-3] Moser S: Metamodels of Object-Oriented Systems, Software - Concepts and Tools (July 1995), pp. 63-80 (ISSN 0945-8115/95 - Springer Intl.)

[Henderson-Sellers-4] Henderson-Sellers B., Moser S., Misic V. B.: Cost estimation based on business models. Journal of Systems and Software 49(1): pp. 33-42 (1999)

[1]

[2]

[3]

[4]