System Meter
Der System Meter (englischer Begriff, deshalb kein Bindestrich) ist eine Softwaremetrik, präziser umschrieben, eine Systembeschreibungsmetrik. Mit dem System Meter werden alle Arten von Systembeschreibungen, insb. auch Modelle und Software-Quellcodes, bezüglich ihrer Größe und Komplexität gemessen. Was genau unter „Größe“ und „Komplexität“ zu verstehen ist, wird aus der Definition des „System Meter“ weiter unten ersichtlich.
Seine Hauptanwendung findet 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 sogenanntes Functional Size Measurement. In anderen Ausprägungen (Messung von Software Source Code) wird der System Meter für die Messung der Qualitätsmerkmale Kopplung (Softwareentwicklung) und Kohäsion (Informatik) angewendet (APSEC’97[1]).
Der System Meter wird als Alternative zum Function Point Bewertungsverfahren eingesetzt werden. Er behebt die bekannten Nachteile des Function-Point-Verfahrens weitgehend. Insbesondere ist der Messaufwand praktisch null, weil die Messung vollautomatisch vorgenommen wird. Dazu 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, nebst deren 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 von der zugrunde liegenden Technik der Anwendung unabhängig. Der SPEC System Meter dagegen bezieht sich auf eine Beschreibung der Benutzeroberfläche. Er unterliegt deshalb, zumindest indirekt, dem Einfluss der angewandten Technik (Programmiersprache, GUI-Framework).
Standards[Bearbeiten]
Der Urheber, Simon Moser, entwickelte und publizierte den System Meter im Jahr 1995[3] 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[Bearbeiten]
Voraussetzungen[Bearbeiten]
(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 Systemperspektive,
- von außen (= „User View“, black box view)
oder
- von innen (= „Implementors View“, white box view)
variieren. 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 definitorische Abhängigkeit von anderen „Beschreibungsobjekten“ (d. h. die Information, mit welchen anderen Wörtern ein Wort definiert oder umschrieben wird) vorhanden sein.
(B) In sehr großen 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 anders, mit einer Analogie ausgedrückt: Wenn in einem großen Gebäude mit vielen Zimmern ein Zimmer neu gestrichen werden soll, dann muss man (z. B. um abzuschätzen, wie viel Farbe gekauft werden muss) sagen/wissen/definieren, welches der Zimmer das ist. Und: dann muss man nur die Größe dieses Zimmers messen. Das klingt 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 außerdem auch mehr oder weniger analytischen Aufwand erfordern. Hier gilt es, je nach Zweck der Messung (z. B. einerseits nur Grobschätzung oder andererseits Festpreisofferte einer einzelnen (kleinen) Systemänderung) die geeignete Form zu bestimmen.
(C) Als zusätzliche Information muss jedes „Beschreibungsobjekt“ in eine der folgenden drei Wiederverwendungskategorien eingeteilt sein:
- Teil einer Standardsprache
- Teil einer spezifischen Bibliothek („Komponente“)
- Neu.
Messung[Bearbeiten]
(1) Jedes Beschreibungsobjekt erhält die sog. Anzahl „Token“ in seinem Namen als sog. „Externe Größe“ zugeordnet. Dabei werden Trennzeichen, der Wechsel von Groß- zu Kleinschreibung (und umgekehrt) und weitere Regeln berücksichtigt. Jedes Beschreibungsobjekt hat mindestens ein Token als „Externe Größe“ (Diese Regel ist wichtig für „namenlose“ Beschreibungsobjekte, welche es ebenfalls gibt).
(2) Sofern das Beschreibungsobjekt „neu“ ist, wird seine Definition betrachtet (= Menge anderer „Beschreibungsobjekte“) und, als sog. „Interne Größe“, die Summe der „Externen Größen“ aller dieser „Beschreibungsobjekte“ berechnet.
(3) Um die Gesamtgröße des betrachteten Systems oder Systemteils zu berechnen, werden
- für alle „neuen“ Beschreibungsobjekte die „Externe Größe“ und „Interne Größe“ summiert
- für alle Bibliotheksobjekte nur die „Externe Größe“ summiert
Die Beschreibungsobjekte, welche bereits in einer Standardsprache vorhanden sind, werden nicht gezählt.
Aufwandschätzung[Bearbeiten]
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 in der Prognostik jener der Function Points Metrik überlegen ist. 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. The SEE Group ist offen für Mitglieder aus aller Welt. Die Anzahl Projekte in der Erfahrungsdatenbank ist >500 (Stand 2009). Sie stammen aus der Schweiz, Australien, den USA, Kanada, Indien und weiteren Ländern. Nebst den Daten zur Systemgröße werden Aufwände, die Projektdauer und – was die Daten-Nutzbarkeit besonders fördert – eine Beurteilung der bei Projektabschluss vorhandenen Artefakte (zusätzlich zum Quelltext und dem Produkt) und ggf. die einzeln dafür aufgewendeten Personalleistungen erhoben.
Hier ein allgemeiner Hinweis zu parametrischen Schätzverfahren: Es gibt keine 'magischen Schätzformeln', die den Personalaufwand genau berechnen können. Jedes Schätzmodell muss
- auf Erfahrungsdaten beruhen, d. h. mit statistischen Verfahren ermittelte Koeffizienten enthalten
- eine Angabe der Schätz-Ungenauigkeit machen („Vertrauensintervall“)
Nur solche Schätzmodelle sind lernfähig, d. h. mit Erfahrungsdaten aus dem eigenen Umfeld ergänzbar und in der Praxis von Nutzen. Misstrauen Sie allen Schätzformeln, die nicht durch Erfahrungsbasis und Vertrauensintervall gestützt sind.
Die typischerweise mit dem System Meter erreichbaren Genauigkeiten (95-%-Vertrauensintervall) sind:
- PRE System Meter: ±35 %
- DOME System Meter: ±12 %
- SPEC System Meter: ±7 %
(Quelle: The SEE Group)
Kritik und Diskussion[Bearbeiten]
Aufwand[Bearbeiten]
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 und 7 % des Gesamtprojektaufwands
- DOME System Meter zwischen 12 und 25 % des Gesamtprojektaufwands
- SPEC System Meter (bei Projekten) zwischen 25 und 50 % des Gesamtprojektaufwands
- SPEC System Meter (bei Modifikationen oder Kleinaufträgen) zwischen 13 und 23 % des Gesamtaufwands
benötigt.
Nachvollziehbarkeit und Eindeutigkeit[Bearbeiten]
Bei gegebenem Modell ist der daraus gemessene System-Meter-Wert immer nachvollziehbar und eindeutig. Allerdings ist in der Realität die Umsetzung in ein Modell (durch verschiedene Modellierer) nicht eindeutig (und oft auch nicht nachvollziehbar). Die gemessenen System Meter – Werte variieren dabei in 95 % aller Fälle zwischen ±1,8 % an unterschiedlichen Modellen der gleichen realen Situation.
Aktualität[Bearbeiten]
Die System Meter Metrik kann sich durch die generische Definition an moderne Modellierungs- und Softwaretechnik-Methoden anpassen. Sie ist insbesondere für die objektorientierte Modellierungssprache UML implementiert, welche Mehrfachvererbung und Polymorphismus unterstützt.
Siehe auch[Bearbeiten]
Literatur[Bearbeiten]
- Saba Zamir (Hrsg.): Handbook of object technology. CRC Press, Boca Raton 1999, ISBN 0-8493-3135-8, 9, Object Oriented Metrics.
- Simon Moser: Mit “Model-Driven-Architecture (MDA)” und der System Meter Methode zu verbessertem Management von IT-Projekten, in: Stephan Geberl, Siegfried Weinmann, Daniel F. Wiesner (Hrsg.): Impulse aus der Wirtschaftsinformatik. 5. Liechtensteinisches Wirtschaftsinformatik-Symposium an der Fachhochschule Liechtenstein, Springer, Berlin/Heidelberg 2004, ISBN 978-3-7908-0195-8, S. 183-197.
Weblinks[Bearbeiten]
- Fachgruppe für Software Estimation und Economics der Schweizer Informatik Gesellschaft (www.s-i.ch)
- Unternehmen von Simon Moser
- Webseite von Simon Moser
Einzelnachweise[Bearbeiten]
- ↑ 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, S. 31–39, doi:10.1109/APSEC.1997.640159.
- ↑ Simon Moser, Oscar Nierstrasz: The effect of object-oriented frameworks on developer productivity. In: Computer. Band 29, Nr. 9, September 1996, ISSN 0018-9162, S. 45–51, doi:10.1109/2.536783.
- ↑ Simon Moser: Metamodels of Object-Oriented Systems. In: Springer International (Hrsg.): Software – Concepts and Tools. Band 16, Nr. 2, Juli 1995, ISSN 0945-8115, S. 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. Band 49, Nr. 1, 15. Dezember 1999, S. 33–42, doi:10.1016/S0164-1212(99)00064-3.
Diese artikel "System Meter" ist von Wikipedia The list of its authors can be seen in its historical and/or the page Edithistory:System Meter.
