ISIS
Suche
Login
ISIS
Übersicht:
Die innere und die äußere Qualität eines Softwaresystems hängen unmittelbar von der Qualität des Entwicklungsprozesses ab. Agile Methoden bieten daher ideale Ansatzpunkte für ein prozessorientiertes Qualitätsmanagement: Iterationen beispielsweise, wie in der Managementmethode Scrum, setzen mit der regelmäßigen Rückschau ständige Inspektionspunkte für Qualität; TDD, testgetriebene Entwicklung, fordert mit „Test First“ die fortwährende Produktion von lauffähiger Software: „Quality First“.
Im Jahr 2006 hat andrena ISIS, das andrena Navigationssystem für das Qualitätsmanagement entwickelt und Anfang 2007 in einem Pilotprojekt eingesetzt, optimiert und evaluiert.
Kernbestandteil von ISIS ist das Projektlogbuch. Hier werden Kenngrößen zur Prozessqualität und zur Softwarequalität weitgehend automatisiert aufgezeichnet, verdichtet und in Zeitreihen dokumentiert.
Die Einzelmetriken sind: Kundenzufriedenheit, Anzahl Programmierfehler, Schätzabweichung, Mittlere Testabdeckung, Packages in Zyklen, Zyklomatische Komplexität, Durchschnittliche Komponenten-Abhängigkeit auf Klassenebene, Klassen mit mehr als 20 Methoden, Methoden mit mehr als 15 LOC, Compiler Warnungen.
Die Verdichtung zu zwei zentralen Steuergrößen „Prozessqualitätsindex“ und „Softwarequalitätsindex“ wendet heuristisches Know-how, gespeist aus langjährigen Erfahrungen der andrena an.
ISIS liefert so für die Entwickler einen ständigen Abgleich zu selbst vorgegebenen Qualitäts-Zielen. Abweichungen werden sichtbar. Aus Fehlern kann sofort gelernt werden, Fehlentwicklungen kann unmittelbar entgegen gesteuert werden. ISIS hilft dem Entwicklungsteam zu verhindern, dass Projekte in Schieflage kommen.
ISIS bietet dem Projektmanagement und dem IT Management Transparenz. Über die beiden Qualitätsindizes haben sie jederzeit objektivierte Kenngrößen für Prozessqualität, Äußere Qualität und Innere Qualität des in Entwicklung befindlichen Systems. ISIS schafft mehr Verständnis für den Entwicklungsprozess und den aktuellen Stand der Entwicklung.
Vorm richtigen und falschen Umgang mit Metriken:
Oft sehen wir eine Überbewertung oder eine Unterschätzung von Metriken. Aus dem akademischen Bereich liegt tonnenweise Literatur vor, in der Praxis werden Metriken dagegen weitgehend ignoriert. Diese Nichtbeachtung ist zumindest teilweise dem Umstand geschuldet, dass die Fülle der definierten Maße jeden Erkenntnisgewinn erschlägt und der benötigte Zeitaufwand für die Erhebung und Interpretation in Projekten nicht zur Verfügung steht. Die Umweltwissenschaften gehen einen anderen Weg. So gibt es für die Beurteilung der Gewässergüte zwar ebenfalls eine Unzahl an Metriken, die Analyse erfolgt aber nur mittels einer sehr stark eingeschränkten Anzahl an Indikatoren. Diesem Ansatz folgen auch wir mit ISIS.
Die Verwendung von wenigen Metriken als Indikatoren zur Beurteilung der Software- bzw. Prozessqualität setzt eine Annahme voraus: verschiedene Aspekte müssen eine Ganzheit bilden, d. h. aus wenigen Qualitätsaspekten muss auf die Qualität des Ganzen geschlossen werden können. Unsere Annahme harrt zwar des wissenschaftlichen Nachweises, erscheint uns aber vernünftig. Im Zuge vieler Code Reviews haben wir eine Korrelation zwischen der Qualität von Modularisierung, Design und Codierung beobachtet.
Ein generelles Problem in der Verwendung von Metriken besteht in der Gefahr, dass sie kontraproduktiv manipuliert, wenn nicht gar gefälscht werden. Sowohl die zielführende Auswahl der Metriken, als auch der konstruktive Umgang mit den Ergebnissen sind deshalb von entscheidender Bedeutung. Ein weiterer Aspekt beruht auf der Schwäche des Menschen: Das Wissen um die Erhebung bestimmter Metriken führt unweigerlich zur Optimierung derselben, gegebenenfalls auf Kosten nicht gemessener Qualitätsaspekte. Als Beispiel hierfür kann die häufig vorgenommene Messung der Produktivität anhand ΔLOC dienen. Die normale Reaktion der Entwickler ist, dass große Mengen LOC produziert werden, zur Not mit Copy/Paste. Diesem Problem begegnen wir mit
- einem ganzheitlichen Ansatz: die Indikatoren stehen für wesentliche Aspekte der Qualität
- einem Dualismus: mindestens 2 Metriken sind Gegenspieler dahingehend, dass die scheinbare Verbesserung eines Qualitätsaspekts durch „Optimierung“ einer Metrik durch eine andere Metrik aufgefangen wird.
Die ISIS-Metriken:
Wie aus obigen Ausführungen schon hervorgeht, muss die Auswahl der Indikatoren möglichst gut die Qualität als Ganzes abdecken. Manipulationen der Messwerte müssen im Sinne der Qualität erwünscht sein, gleichzeitig sollten Fälschungen schwierig sein. Weitere Kriterien für die Auswahl waren Einfachheit beim Erheben und Interpretieren.
Die Auswahl und Gewichtung der Indikatoren sowie die weitere Verdichtung zu den zwei zentralen Steuergrößen „Prozessqualitätsindex“ und „Softwarequalitätsindex“ wendet heuristisches Know-how aus langjährigen Erfahrungen der andrena an. Aktuell wird ein Forschungsprojekt zur Validierung dieser Daten angestrebt.
Die Metriken Kundenzufriedenheit, Anzahl Bugs und Schätzabweichung sind reine Prozessmetriken. Die weiteren Indikatoren sind Softwaremetriken. Sie liefern die Basis für die Ermittlung der Softwarequalität zu einem bestimmten Zeitpunkt. Ihre Veränderung zwischen zwei Messpunkten geht, neben den Prozessmetriken, maßgeblich in die Ermittlung der Prozessqualität ein.
Kundenzufriedenheit wird vom Kunden als subjektiver Wert auf einer Skala von 1 bis 10 angegeben. Als hochgradig integriertes Maß, das letztendlich entscheidend ist für kundenorientierte Dienstleistungen, hat es mit 17% die höchste Gewichtung.
Die Anzahl Bugs ist ein Indikator für die äußere Softwarequalität. Ein Bug ist definiert als von der Spezifikation abweichendes Verhalten in Code, der vom Entwicklungsteam als fertiggestellt und qualitätsgesichert freigegeben wurde. Verletzungen der guten fachlichen Praxis werden auch als Bug erfasst (z. B. ungenügende Performance). Hier liegt mit 15% das zweite „Schwergewicht“.
Mit der Schätzabweichung wird die Qualität der Planung abgebildet. Erfasst wird die prozentuale Abweichung der Soll- und Istwerte. Dies kann auf Basis von Zeitschätzungen für einzelne Tasks, auf Basis von Storypoints oder gar auf Basis des gesamten Sprints erfolgen.
Die Testabdeckung dient der äußeren Softwarequalität (Fehlerfreiheit) und verbessert die Wart- und Erweiterbarkeit des Codes.
Packages in Zyklen und Average Component Dependency (Class) sind beides Maße für die Qualität der Modularisierung. Während Packages in Zyklen die Qualität auf mittlerer Ebene abbilden, steht der ACD für die Modularisierung auf dem Niveau von Subsystemen. Beide Maße können ohne statische Codeanalyse kaum oder gar nicht erkannt, geschweige denn beeinflusst werden. Für die Betrachtung der Wartbarkeit und Erweiterbarkeit eines Systems sind sie aber essentiell.
Die Klassengröße ist ebenfalls ein Maß für die Qualität des Designs und die Wartbarkeit und Erweiterbarkeit einer Anwendung. Der Grenzwert liegt bei 20 Methoden pro Klasse.
Die Methodenlänge ist ein Maß für die Verständlichkeit und Lesbarkeit des Codes und damit für die Qualität der Codierung. Der Grenzwert liegt bei 15 LOC.
Die Cyclomatic Complexity ist ein Maß für die Verständlichkeit, Wartbarkeit und Änderungsfreundlichkeit des Codes, mithin für die Qualität der Codierung. Der Grenzwert liegt bei 5 pro Methode.
Die Compiler Warnings sind ein Maß für die Sauberkeit des Arbeitens. Sie werden in Relation zur Anzahl Klassen gesetzt.
Der Werkzeugzoo:
Für die Messung der Metriken, die Bewertung der Werte und die Historisierung und Visualisierung werden mehrere Werkzeuge zusammengeführt.
- Sotograph (Lizenz). Automatisierte statische Analyse, Historisierung, Deltafunktion, manuelle Identifizierung und Behebung von Schwachstellen
- EclEmma (Freeware). Messung der mittleren Testabdeckung. Identifizierung von lokalen Defiziten (Klassen- und Methodenebene)
- ProjektLogbuch (andrena Eigenentwicklung). Zentrales Instrument für Integration, Verdichtung, Visualisierung, Historisierung
- BugCollector (andrena Eigenentwicklung). Erfassung und Historisierung der Programmierfehler
Der BugCollector ist wie das ProjektLogbuch ein Bestandteil von ISIS. Er ist ein sehr einfaches Werkzeug mit großer Wirkung. Wenn vom Kunden ein Bug gemeldet wird, werden die Umstände des Entstehens analysiert und hier erfasst. Die Information, ob der Code mit UnitTests abgedeckt ist und ob der Bug beim PairProgramming oder alleine entstand, wird als Kennzeichen mitgeführt. Die Bugs werden im BugCollector vom jeweiligen Entwickler selbst dokumentiert und anschließend in (Scrum-) Retrospektiven gemeinsam analysiert und besprochen. Ein immenses Lern- und Vermeidungspotenzial wird mit dem Sammeln und Analysieren der Programmierfehler systematisch ausgeschöpft.
Die Anzahl der Programmierfehler pro Entwickler und Monat stellt eine wesentliche Steuergröße für die Balance von Qualität und Effizienz dar.
Lessons learned:
Die Entwicklung von ISIS erfolgte in einem Pilotprojekt, um sicher zu stellen, dass die Methode praxistauglich ist. Im Laufe des Einsatzes in Projekten wurde (und wird) das System weiterhin kontinuierlich geprüft und verbessert. Die Beschränkung auf wenige Indikatoren zur Alltagstauglichkeit hat sich bislang bewährt. „Gefühlte“ und gemessene Qualität korrespondieren in der Regel.
Wie oben bereits erwähnt, ist der Umgang mit Messungen und ihren Ergebnissen von entscheidender Bedeutung für ihren Erfolg. An den Einsatz von ISIS sind deshalb Voraussetzungen geknüpft. Unabdingbar ist die eigenverantwortliche Handhabung seitens des Entwicklerteams (Erfassung, Auswertung und Analyse der Daten), kombiniert mit einer lernorientierten Fehlerkultur und Teamverantwortlichkeit für die Resultate. Dies bedeutet auch, dass von Seiten des Managements keinerlei Verstärker (Belohnung/Bestrafung) eingesetzt werden. Der Scrum-Prozess bietet einen idealen Rahmen für die genannten Voraussetzungen.
Die Einführung von ISIS initiierte in den Entwicklungsteams intensive Diskussionen über Softwarequalität, Metriken und Produktionsprozesse. Als problematisch erwiesen sich insbesondere die Indikatoren Schätzabweichung und Testabdeckung.
Hinsichtlich Testabdeckung ist die Tendenz erkennbar, Tests mehr quantitativ als qualitativ auszurichten. Die Erfassung der Anzahl Bugs, die dem entgegen steuert, hat einen (oft hohen) zeitlichen Nachlauf. Die Korrektur setzt somit verspätet ein und das Gesamtbild kann zunächst verfälscht sein. Die adäquate Relativierung einzelner Messergebnisse im Bezug zum Ganzen und zum jeweiligen System und Zeitpunkt konnte aber bei der gemeinschaftlichen Betrachtung im Team erfolgreich geleistet werden. Teamzusammensetzungen mit erfahrenen Kollegen waren dabei natürlicherweise hilfreich.
Die Schätzabweichung kann bislang nur manuell ermittelt werden. Damit einher geht ein beträchtlicher zeitlicher Aufwand (ca. 60% der Gesamtzeit pro Messpunkt) und eine erhebliche Unschärfe bzw. Manipulierbarkeit. Die Qualität der Planung ist uns aber zu wichtig, um auf diese Metrik zu verzichten. Gegenwärtig diskutieren wir intensiv über andere Möglichkeiten zur Bewertung der Planungsqualität.
Die Analyse und Diskussion im Team ist ein wesentlicher Bestandteil der Prozess-Steuerung. ISIS ist als Navigationssystem konzipiert, nicht als Autopilot. Die weitgehende Automatisierung der Datenerfassung (heute nur noch etwa eine Stunde pro Messpunkt) und die Visualisierung der verdichteten Ergebnisse war wichtig, um eine einfache Handhabung und damit den regelmäßigen Einsatz zu gewährleisten. So konnten die Messergebnisse als Bestandteil der Scrum-Retrospektiven integriert werden.
Die Transparenz der Produktion schafft Vertrauen bei Auftraggeber und Management und führt zu einer Verstetigung der Produktion. Wir setzen ISIS inzwischen in allen unseren Inhouse-Projekten ein. Nach Einführung von ISIS haben sich Prozess- und Softwarequalität sichtbar verbessert.