Metriken sind Qualitätsmaße
Die Qualitäts-Metrik wird vom "Lexikon der Datenverarbeitung' als ein möglichst quantitativ ausdrückbares Kriterium definiert, anhand dessen sich die relative Qualität eines Produkts ausdrücken läßt. Typische Qualitätsmaße sind: Anzahl der Fehler pro Tausend Programmzeilen oder Anzahl der Probleme pro Monat und Kunde.
Unter einem Metrikprogramm ist der systematische Einsatz von Metrikdaten für Qualität, Produktivität und ähnlichem zur Prozeßsteuerung innerhalb einer Organisationseinheit oder eines Prozesses zu verstehen.
Metriken gewinnen als Hilfsmittel bei der Software-Entwicklung nach Ansicht von Harald Schumacher und Wolfgang Ey* an Bedeutung. An praktisch verwertbarer Literatur und entsprechender Tool-Unterstützung besteht ein unübersehbarer Mangel. Viele Projekte, denen die Erstellung von Metriken als Teil des Auftrags abverlangt wird, müssen zunächst Grundlagenarbeit zu diesem Thema leisten.
Da eine Fülle unterschiedlicher Werte als Grunddaten (Primärdaten) für die Ableitung voll Metriken herangezogen werden können, wurde bei Siemens zur Erleichterung der Auswahl und für ein unternehmensweit einheitliches Verständnis ein interner Normentwurf für das Teilgebiet der Qualitätsmetriken geschaffen. Der vorliegende Bericht soll Erfahrungen aus der praktischen Umsetzung im Bereich der Produktsoftware-Entwicklung vermitteln und potentiellen Metrikanwendern als Einstiegshilfe dienen.
Auch wenn das Schlagwort "Softwarekrise" nicht mehr die einschlägigen Fachzeitschriften füllt, läßt dies nicht auf die Beseitigung der Probleme schließen. Noch hat die Entwicklungsmethodik in der Software nicht den Stand erreicht, der in der Hardware üblich ist. Kosten und Terminüberschreitungen, mangelnde Qualität und übermäßige Personalbindung wegen notwendiger Produktpflege sind weiterhin üblich.
Immer öfter setzen sich Softwarehersteller deshalb höchst ehrgeizige Ziele, über eine dramatische Steigerung von qualitätsorientierten Leistungsdaten zu einer Verbesserung der Wettbewerbsfähigkeit zu gelangen. Als Beispiele seien "10x Goal" (HP, 1986), "Six Sigma" (IBM und Motorola, 1989) oder "Durchlaufzeit/2" (Siemens Automatisierungstechnik, 1990) genannt. Das Setzen und Messen der Einhaltung solcher Ziele erfordert jedoch de" Einsatz von Qualitätssystemen und Systematiken, mit denen die Ergebnisse einzelner Entwicklungsschritte nachweisbar sind. Solche Systeme werden in verschiedenen Normen definiert, doch werden diese gerade voll Softwareherstellern häufig ignoriert. Qualitätssysteme sind eine Voraussetzung, damit Entwicklungsergebnisse objektiv quantifizierbar werden.
Das systematische Sammeln und Auswerten von Entwicklungsdaten gehört in vielen japanischen Firmen seit mehr als zehn Jahren zum Stand der Technik. Langsam scheint sich dies nur, auch bei uns durchzusetzen, was sich an der immer häufigeren Forderung nach Metriken als Teil von Software-Aufträgen ablesen läßt.
Ursprünglich wurde der Begriff Metriken in Zusammenhang mit Komplexitätsmaßen für Sourcecode verwendet Am bekanntesten sind Halsteads "Software Science" und McCabes "Cyclomatic Complexity". Solche Komplexitätsmetriken werden heute als wertvolle Hilfe bei lokalen Analysen gesehen. Sie geben Zusatzinformationen bei Code-Inspektionen oder helfen bei der Auffindung möglicher kritischer Komponenten in existierenden Produkten. Da die Ermittlung der Werte automatisierbar und relativ einfach ist, ist dafür auch eine Vielzahl von Programmen erhältlich.
Für eine globale Betrachtung von Produkt- und Prozeßeigenschaften sind diese Methoden allerdings weniger geeignet. Deswegen werden "Metriken" auch immer häufiger als Übergriff von prozeßorientierten Kennzahlen wie Qualität, Produktivität und Planungstreue verwendet. Die Anzahl gefundener oder erwarteter Fehler definierter Programmgröße (Fehler pro 1000 Sourcestatements), oder die in einem Projekt entwickelte Zeilenzahl je Zeiteinheit sind zwei der bekanntesten prozeßorientierten Metriken, im folgenden kurz Metriken genannt.
Die Schwierigkeit ihrer Anwendung besteht jedoch in fehlender Standardisierung der meisten zugrundeliegenden Begriffe und Verfahren. Natürlich haben unterschiedliche Organisationen auch unterschiedliche Verfahren, um mit Software-Konfigurations-Management, Fehlerverfolgung oder Kostenzuordnung grundlegende Metrikdaten zu erfassen, die Folge ist das Fehlen verbreiteter Tools für (prozeßorientierte) Metriken. Auch gibt es wenige Veröffentlichungen mit spezifischen Vergleichszahlen, so daß häufig Unsicherheit über die Qualität der eigenen Werte vorliegt.
Sucht man konkrete Vorlagen zur Einführung eines Metrikprogramms, so findet man wohl bei Grady und Caswell die beste und umfassendste Beschreibung auf diesem Gebiet. Ein einfaches "Kochrezept" hat man damit allerdings nicht zur Hand, da in diesem Buch viele Details und Firmenspezifikationen geschildert sind, die entsprechend dem eigenen Umfeld und der verwendeten Entwicklungsplattform entweder geändert oder ganz weggelassen werden müssen.
Auch in vielen Bereichen unseres Unternehmens haben sich seit längerem Metriksysteme entwickelt. Diese waren jedoch meist unterschiedlich ausgeprägt, so daß es nicht immer möglich war, Erfahrungen aus einem Gebiet auf ein anderes zu übertragen. Deshalb wurde eine bereichsübergreifende Vereinbarung für den Einsatz von Qualitätsmetriken getroffen, deren Ziel es ist, Hilfestellung bei der Einführung von Metriken zu geben, einheitliche Tools und Verfahren zu ermöglichen und schließlich ein gemeinsames Verständnis zwischen den Bereichen auf dem Gebiet der SW-Qualitätsdaten zu unterstützen. Diese Vereinbarung soll zu einem späteren Zeitpunkt in eine interne Norm überführt werden.
Verbesserung des Entwicklungsprozesses
Das Prinzip des gewählten Ansatzes ist in zwei 'Tabellen dargestellt (siehe Abbildung 1 und 2). Die erste Tabelle legt Primärdaten fest, einfache Meßgrößen, welche durch Zählen, Messen oder ähnliches bestimmt werden. Beispiele dafür sind Fehler, Codezeilen oder Kosten. Darauf aufbauend sind in der zweiten Tabelle Kennzahlen definiert, verschiedene Quotienten der zuvor beschriebenen Primärdaten, zum Beispiel Kosten je Fehler.
Mit der Unterscheidung zwischen Mindestumfang und erweitertem Umfang wird zudem die Anfangsschwelle für geplante Metrikprogramme niedriger.
Die ausgewählten Daten stellen die im gesamten Unternehmen einheitlich verstandenen Meßwerte dar. Darüber hinaus werden in den einzelnen Bereichen weitere Metriken spezifisch vereinbart. Der vorliegende Bericht beschreibt die praktische Umsetzung dieser Metrikdefinition bei, der Entwicklung von Systemsoftware, unter anderem von einem realzeitfähigen Unix-Betriebssystem.
Das Primärziel eines Metrikprogramms ist die Verbesserung des Entwicklungsprozesses, das heißt der Summe aller während einer Entwicklung gültigen und angewandten Verfahren. Es hat sich jedoch gezeigt daß der Einsatz von Metriken erst dann sinnvoll ist, wenn der beobachtete Entwicklungsprozeß bereits von einer gewissen Qualität ist. Im folgenden werden einige Verfahren angerissen, die wichtige Voraussetzung für ein Metrikprogramm sind (siehe Abbildung 3).
- Verfahrensmodell (Leitprozeß, Life-cycle-model): Um einen Entwicklungsprozeß zu verbessern, müssen Aussagen über definierte Teilschritte abgeleitet werden. Dazu ist der Einsatz eines (phasenorientierten) Verfahrensmodells notwendig, dessen konsequente Anwendung Beobachtungs- und Meßpunkte innerhalb einer Gesamtentwicklung definiert.
- Formale Inspektionen haben sich nicht nur als besonders wirkungsvolle Maßnahme für Qualitäts- und Produktivitätssteigerung erwiesen, sondern auch als geeignete Systematik für die Gewinnung von Metrikdaten in frühen Entwicklungsphasen.
- Unter formalem Test (Abnahme) wird die abschließende, entwicklungsunabhängige Produkttest-Phase verstanden, in der Fehler, Testkosten, Testfortschritt und andere Daten erfaßt und ausgewertet werden. Dieser Test ist bei hohen Qualitätsanforderungen an ein Produkt unerläßlich und liefert zudem die einzig zuverlässige Basis für eine Vorhersage auf Fehler während des Einsatzes.
- Zentrales Konfigurations-Management (KM): Durch ein zentrales KM wird die gleichartige Behandlung verschiedener Produkteigenschaften erreicht, unter anderen in solch trivialen Dingen wie Versionsnummern-Vergabe oder Dateistrukturen. Solche (meist stillschweigend) vorausgesetzten Gleichartigkeiten sind entscheidend für eine Vergleichbarkeit von Zahlen, können bei größeren Entwicklungen jedoch nur durch eine unabhängige zentrale Stelle mit verbindlichen Vorgaben er. reicht werden. Es hat sich als vorteilhaft erwiesen, Produkte spätestens ab dem formalen Test dem zentralen KM zu übertragen.
- Kostenerfassung nach Phasen und Aufgaben: Hauptziel eines Metrikprogramms ist die Einsparung von Kosten über den gesamten Life-Cycle hinweg. Zur Analyse des Ist-Zustands und zur Verfolgung der Kostenauswirkungen zukünftiger Prozeßkorrekturen ist die Kenntnis des Kostenanfalls für unterschiedliche Aufgaben innerhalb eines Projekts notwendig. Ein geeignetes Vorgehen ist neben der Erfassung nach Einzelprodukten die Trennung nach Prozeßphasen sowie nach Entwicklungs- und Qualitätskosten (Fehlerverhütungs-, Prüf- und Folgekosten entsprechend DIN ISO 55 350).
Ähnlich wie CASE-Werkzeuge sind auch Metrik-Programme nicht unbedingt mit ihren Tools gleichzusetzen. Entscheidend ist jeweils das zugrundeliegende Vorgehen. Ohne ein funktionierendes Verfahren sind selbst gute Tools wirkungslos. Theoretisch kann bei Metriken auf spezielle Werkzeuge verzichtet und der Aufwand für Tool-Entwicklung zur periodischen Auszählung und Darstellung von Daten verwendet werden.
Dies hat sich jedoch als wenig praktikabel erwiesen, da solche Aktionen weder regelmäßig durchgeführt werden können, noch die gleichmäßige Interpretation der zugrundeliegenden Daten gewährleistet ist. Für die Durchführung von Metriken ist die Verwendung folgender Tools wichtig (siehe Abbildung 3):
- Häufig erweist sich das Fehlen einer einfachen Funktion wie der Produktgrößen-Ermittlung schon als Hindernis für die Einführung von Metriken. Wichtig ist, daß zumindest das Zählen von NLOC (Netto lines of code, also nicht Zeilen, die leer sind oder nur Kommentar enthalten) für Einzeldateien sowie für die Unterschiede zwischen zwei Ausgabeständen DNLOC (Delta netto lines of Code) möglich ist.
NCSS (Quellsprach-Anweisungen) oder Funktion Points sind sicher besser geeignet als das sprachen- und programmstilabhängige NLOC. Da jedoch Standardisierung und Tools nur bei NLOC für ein breites Sprachspektrum existieren, wurde diese Maßeinheit bevorzugt ausgewählt. In vielen Siemens-Bereichen wird ein eigenes Tool (Proloc) eingesetzt, das für eine Vielzahl von Sprachen und auf verschiedenen Systemen ablauffähig ist.
- Tools für das Konfigurationsmanagement sind im Hinblick auf Metriken notwendig, um eine automatisierbare Versionsverwaltung sicherzustellen, das heißt den eigentlichen Metrik-Tools eindeutige Informationen zu geben über Produktversionen und deren Zuordnung zu bestimmten Life-cycle-Phasen. Automatische Zeilenzählung muß unterstützt werden durch den Zugriff auf beliebige Produktversionen.
- Tools für Fehlererfassung und -verfolgung sind nicht nur für den Einsatz eines SW-Produkts unverzichtbar. Jedes Metrikprogramm lebt vom Umfang der damit erfaßbaren Daten wie Fehlerzahl und -art, Fehler- und Korrekturversion, Prioritäten und ähnlichem. Obwohl Bedarf besteht, scheinen geeignete Fehler-Tools am Markt praktisch nicht zu existieren.
Wegen des fehlenden Angebots mußten die Tools für KM und Fehlerverfolgung im Haus entwickelt werden. Da diese bei der Metrikeinführung aber schon seit mehreren Jahren im Einsatz waren, gab es auch den Vorteil einer umfassenden Produkt- und Fehlerdatenbank zu Beginn des Metrikprogramms.
So wenig, wie professionelles und qualitätsorientiertes Entwicklungsverhalten verordnet werden kann, so wenig ist es sinnvoll, Metrikprogramme einzuleiten, wenn nicht bestimmte ideelle Voraussetzungen gegeben sind. Dazu zählt vor allem die Unterstützung seitens des Managements: Alle bekannten und erfolgreichen Metrikprogramme haben mit konkreten Richtlinien durch die Firmen, Leitung begonnen. Auch im kleineren Bereichen ist die überzeugte und sichtbare Unterstützung durch das Management wichtigste Voraussetzung für den Erfolg eines Metrikprogramms.
Dies bezieht sich nicht nur auf die Übernahme direkter Kosten für Einführung und Entwicklung notwendiger Tools. Die Unterstützung ist besonders notwendig, wenn es darum geht, nette Verfahren und Tools für den Entwicklungsprozeß verbindlich einzuführen.
Neben einem qualitativ fortgeschrittenen Entwicklungsprozeß ist auch eine erfahrene und aufgeschlossene Projektmannschaft notwendig, wenn sinnvolle Ergebnisse erzielt werden sollen. Die Mitarbeiter müssen selbstbewußt sein, sich den Ergebnissen und Schwächen der eigenen Arbeit stellen. Nur so ist gewährleistet, daß sie nicht in einer defensiven Haltung Fehler wegdiskutieren und damit ungenügende Daten liefern. Auch hier muß das Management klarstellen, daß die Metriken Verbesserungen des Entwicklungsprozesses und nicht die Überwachung der Mitarbeiter zum Ziel haben.
Auch wenn zu Beginn eines Metrikprogramms das zu lösende Problem klar vor Augen liegt und entsprechende Metrikdaten vorliegen oder ermittelbar sind, wird man doch seht schnell auf eine ganze Reihe von Schwierigkeiten bei der Einführung stoßen. Diese können dazu führen, daß die Inhalte und Darstellungen der Metriken mehrfach modifiziert werden müssen, wodurch zusätzlich zu den Startproblemen beigetragen wird. Schwierigkeiten liegen sowohl in der Akzeptanz als auch in der Realisierung.
Das größte Problem resultiert fast immer aus dem Mißtrauen der Beteiligten. Viele werden befürchten, im Vergleich zu anderen Bereichen ungünstig dazustehen. Hier helfen: Klare Aussagen vom hochrangigen Management sind nötig, aus denen hervorgeht, daß das Ziel der Metriken n i c h t das Aufzeigen von Fehlern der Vergangenheit ist, sondern deren Vermeidung in der Zukunft.
Der Ist-Zustand muß als gegeben angenommen werden und dient als Ausgangspunkt für Verbesserungen. Zweitens sind vertrauliche Vorabinformation der Beteiligten erforderlich, denen damit die Möglichkeit gegeben wird, sich mit den Zahlen vertraut zu machen und Probleme möglicherweise vorab ausräumen zu können.
Es muß allen, insbesondere dem Management, klar sein, daß Kennzahlen nur in sehr seltenen Fällen unmittelbar miteinander vergleichbar sind, daß Voraussetzungen wie Infrastruktur oder Entwicklungsprozeß ebenfalls vergleichbar sind. Dies ist meist nur innerhalb derselben Organisationseinheit gegeben. Metriken sollen Steuerungs-, nicht Überwachungsinstrument sein. Primäres Ziel für Metrikprogramme ist die Optimierung des Entwicklungsprozesses im eigenen Bereich.
Besonders in der Anfangsphase bewirken gewünschte Aktualität und kurze Veröffentlichungsrhythmen oft sich kurzfristig verändernde Metriken. Dies liegt meist in der geringen Datenbasis und den damit verbundenen starken Auswirkungen, wie zum Beispiel eine verzögerte Kostenerfassung oder besonders intensive Fehlerbearbeitungs-Phasen. Dem scheinbaren Vorteil einer Online-Erfassung mit stets aktuellen Daten sollte widerstanden werden. Metriken sollten auch am Anfang nicht zu häufig und nur zu Zeitpunkten veröffentlicht werden, zu denen Datenkonsistenz gewährleistet ist.
Entscheidend für die konsequente Durchführung ist die Person eines Verantwortlichen, der innerhalb einer Organisation auch mit einer entsprechenden Position betraut ist. Maßnahmen aufgrund des Metrikprogramms sind häufig unpopulär, so daß eine einflußreiche Person ihre Einführung deutlich beschleunigen, wenn nicht gar erst ermöglichen kann. Außerdem haben Metriken Schnittstellen mit vielen Bereichen einer Organisation, zum Beispiel der oft sensitiven Kostenerfassung, zu welchen der Verantwortliche Zugang benötigt.
Technisch gesehen tauchen unerwartete Probleme bei der Umsetzung einer Norm in die reale Praxis auf. Begriffe, die zunächst intuitiv klar zu sein scheinen, sind dann nicht immer eindeutig. Es kann sich zum Beispiel herausstellen, daß Q-Kosten (Qualitätskosten) nicht nach Phasen getrennt werden können, da dies zu Mengenproblemen bei der Kostenerfassung führen würde. Es ist ein grundlegendes Problem, daß eingeführte Kostenerfassungs-Werkzeuge sehr lange Innovationszeiten haben und "moderne" Forderungen nur sehr schwer unterstützen.
Auch die Klassifizierung von Problemen und Fehlern ist nicht immer trivial. Besonders wenn Fehlererfassungs-Tools insofern komfortabel sind, als sie viele Klassifizierungen unterstützen, wird es hinterher wie der schwierig, eindeutig zwischen Fehler oder Problem zu trennen. Auch die Frage nach der Versionszuordnung eines Fehlers ist häufig nur schwer entscheidbar.
Eine für Metrikprogramme populäre Faustregel sagt aus, daß es drei Jahre dauert, bis "genügend" Daten gesammelt sind, um meßbare Trends in einer Organisation erkennen zu können. Allerdings setzt der Nutzen bei konsequent geführten Programmen auch sehr schnell ein. Manche Qualitätserrungenschaften werden dabei nicht eindeutig den Metriken zuzuordnen sein, während andere wiederum nur aufgrund des Metrikprogramms schnell und konsequent eingeführt werden können.
Insgesamt aber bewirkt ein engagiertes Programm die grundsätzliche Auseinandersetzung aller an einem Projekt Beteiligten mit einer Vielzahl von Qualitätszielen und erleichtert damit die Bereitschaft zur Einführung von Q -Maßnahmen. Der Nährboden für Qualitätsbewußtsein wird gelegt.
Konkrete Verfahrensverbesserungen im Rahmen der Entwicklung des Echtzeit-Betriebssystems Sorix waren zum Beispiel:
- die Verbesserung der Kontierungsweise zusammen mit dem zugrundeliegenden Kostenkontierungs-Schema. . Weil die Projektleiter selbst an den Entwicklungskosten interessiert waren, ließen sich klare Kostenzuordnungen treffen, "hidden projects" mußten nicht gefahren werden;
- das frühere Offenlegen von Fehlern, da es vorteilhafter ist, wenn ein Entwickler einen Fehler vor dem Tester, und der wiederum vor dem Kunden entdeckt,
- Standards und Kriterienlisten wurden von Entwicklern aus Eigeninitiative, entwickelt. Diese wollen sich Kriterien, nach denen Ergebnisse bewertet werden, selbst setzen.
Insgesamt gesehen darf man als Erfolg der Ergebnisse eines Metrikprogramms jedoch weniger das plötzliche Eintreffen grundlegender Erkenntnisse erwarten. Es ist das ständige Auseinandersetzen mit den Kleinigkeiten, die zu vielen, oft sekundären Verbesserungen führen.
Beispiele: Bei der Darstellung von Metrikdaten müssen zwei konkurrierende Anforderungen erfüllt werden: erstens die Vermittlung einer großen Menge von Daten und zweitens die Anschaulichkeit der wichtigen Daten und Ergebnisse. Aus diesem Grund werden üblicherweise zwei Darstellungsformen gleichzeitig verwendet:
- In tabellarischer Form wird die Vielzahl der Daten dargestellt, geordnet nach Systemen, Produkten, Versionen und Entwicklungsphasen (Abbildung 4). Diese Form ermöglicht Projektleitern und Q-Verantwortlichen, auf punktuelle Probleme einzugehen.
- Die grafische Form wird zur Darstellung der großen," Ergebnisse, Trends und Gesamtübersichten verwendet, insbesondere auf der - Stufe der Management-Präsentationen (Abbildung 5).
Literatur:
1. DIN ISO 9000 bis 9004, Qualitätsmanagement- und Qualitätssicherungs-Normen.
2. IEEE 730-1989, IEEE Standard for Software Quality Assurance Plans
3. DIN ISO 55 350, Teil 11, Begriffe der Qualitätssicherung und Statistik
4. B. W. Böhm, Software Engineering Economics, Prentice Hall, 1981
5. C.Jones, Effektive Programmentwicklung - Grundlagen der Produktivitätsanalyse, McGraw-Hill, 1987
6. C. Jones, Software Measurement and Estimation, GMO Konferenzband, 1990
7. R. B. Grady, D. L. Caswell, Software Metrics: Establishing a Company-wide Programm, Prentice Hall, 1987 .
8. Qualitätsmetriken Software, Entwurf, Version 1.2, Siemens intern, 1991
9. M. E. Fagan, Design and Code Inspections to Reduce Errors in Program Development IBM Systems Journal, Vol. 15, Nr.3 (1976), Seite 182-210.
* Dr. Wolfgang Ey und Dipl.-Informatiker Harald Schumacher, Siemens AG, Bereich Automatisierungstechnik, Gemeinsame Technische Aufgaben, Betriebssysteme und Softwaretechnologie in Nürnberg.