Die Organisation muss sicherstellen, dass die Entwicklungsergebnisse Anforderungen an die Überwachung und Messung, soweit zutreffend, sowie Annahmekriterien enthalten oder auf sie verweisen.
ISO 9001, Kapitel 8.3

Den Satz musste ich mehrmals lesen, um ihn zu verstehen. Bezogen auf agile Entwicklungsprozesse meint die Qualitätsmanagementnorm ISO 9001 (2015) nach meinem Verständnis eine objektive Messung der Qualität der Entwicklungsergebnisse. Neben der Bereitstellung von Software für den kundenwirksamen Betrieb ist die objektive Beurteilung ihrer Qualität eine der größten Herausforderungen in der IT-Branche. Software als Produkt lässt sich dabei nur eingeschränkt mit Produkten anderen Industrien vergleichen.

Nehmen wir als Beispiel einen Mixer. So ein Gerät besteht aus einer Vielzahl von einzelnen Komponenten, angefangen bei einfachen Schrauben bis hin zu komplexen Bauteilen wie Motor oder Netzteil. Jede Schraube, praktisch jedes Bauteil ist genormt. Die Herstellung basiert auf einer genau geplanten Abfolge von Arbeitsschritten, die tausendfach teil- oder vollautomatisch ausgeführt werden.

Moderne Software wird modularisiert. Ein Modul, z.B. eine Programmbibliothek, hat eine Spezifikation, ist also ebenfalls genormt. Damit enden aber schon die Parallelen. Bei Software gibt es keine Grenzen in der Verwendung. Ein Modul kann bei 1000 Aufrufen pro Tag noch fehlerfrei funktionieren, bei der 10-fachen Menge aber Fehler zeigen. Ein Modul kann also außerhalb seiner Spezifikation verwendet werden.

Die Herstellung von Software kann nicht automatisiert werden. Aber Test und Installation. Agile Entwicklungsprozesse erfordern sogar ein sehr hohes Maß an Automatisierung in diesen Bereichen. Werkzeuge wie JaCoCo oder SonarQube versetzen uns zusätzlich in die Lage, Software zu analysieren und Metriken daraus abzuleiten.

Ein bekanntes und sehr nützliches Werkzeug in der Java-Welt zur Messung der Testabdeckung ist JaCoCo. Es bietet dem Entwickler die Möglichkeit, die erreichte Abdeckung seiner Testfälle zu messen.

Entwicklungsergebnisse messen mit JaCoCo

Die Ergebnisse werden menschenlesbar als HTML-Seite (siehe Beispiel) und maschinenlesbar in den Datenformaten XML oder CSV erstellt.

Weiterlesen auf eclemma.org

SonarQube ist ein Werkzeug, das mittels statischer Code-Analyse technische Qualitätsmerkmale von Software erfasst und diese in einer übersichtlichen Oberfläche darstellt.

Entwicklungsergebnisse messen mit SonarQube

SonarQube analysiert den Code hinsichtlich der folgenden Qualitätsbereiche:

  • Anzahl der erkannten Fehler und Schwachstellen
  • Codequalität und ein Maß für technische Schulden
  • Duplizierter Code als prozentualer Anteil und als Anzahl der Code-Blöcke
  • Testabdeckung in Prozent und Anzahl der Testfälle

SonarQube ermittelt die zyklomatische Komplexität des untersuchten Projektes. Zur Bestimmung der Metrik wird die Anzahl bestimmter Schlüsselwörter je Methode bzw. je Klasse gezählt und bewertet.

Weiterlesen auf sonarqube.org

Der Test der Software ist ein wichtiges Element der Software-Entwicklung. Von Edsger Dijkstra wissen wir aber, dass sich durch noch so viele Testfälle die Fehlerfreiheit einer Software nicht beweisen lässt. Aber wir können für jede geforderte Fähigkeit einer Software einen entsprechenden Testfall vorsehen. Die Methode CARDS+ hilft uns, dieses Ziel zu erreichen. Nutzen wir die Bausteine des Systembeschreibung konsequent für die Dokumentation der Ergebnisse der Anforderungsanalyse, haben wir mit dem Baustein Case jede Fähigkeit des Software-Produktes erfasst und kennen seinen Lösungsansatz. Wir wissen also, welche Dienste (Baustein Service) und welche Daten (Bausteine Event und/oder Entity) zur Lösung beitragen. Durch die Messung der Testabdeckung wissen wir, dass unsere “Bauteile” korrekt funktionieren. Durch den Systemtest überprüfen wir “end to end” die geforderte Fähigkeit in der Software. Damit stellen wir sicher, dass alle uns bekannten Funktionen in normalen Parametern fehlerfrei sind.

Natürlich basiert diese These auf der Annahme, dass wir alle Fähigkeiten kennen und mit dem Baustein Case erfasst haben. Anders als bei der Messung der Code-Qualität lässt sich die Qualität der Dokumentation nicht so leicht messen. Zumindest nicht automatisch. Aber mit Disziplin und Feedback lässt sich einiges erreichen. Die Bausteine Topic und Epic helfen dabei, den Überblick zu bewahren. Es versetzt Auftraggeber und Fachleute in die Lage, Feedback zur Dokumentation zu geben, weil diese Bausteine in ihrer Sprache geschrieben sind und eine passende Abstraktion darstellen.

Mit dem Baustein Topic dokumentieren das Verständnis des Auftraggebers über den Rahmen, in dem sich das Projekt bewegen soll. Alle Topics zusammen beschreiben den Projektauftrag. Ein Topic ist in der Sprache der Auftraggeber und Fachleute als Überblick (englisch; management summary) geschrieben, vom Product-Owner für Stakeholder.

Weiterlesen auf cardsplus.info

Nach der Lektüre eines Epics sollte jeder Leser in der Lage sein, die Anforderung fachlich einzuordnen. Die Zuordnung zum Topic hilft dabei. Ein Epic bündelt eine laufend wachsende Menge von Cases, die fachlich zusammen gehören.

Weiterlesen auf cardsplus.info

Diese Zerlegung eines Epic mit dem Baustein Case ist sehr wichtig, weil sie uns zeigt, wo wir aus der fachlichen Perspektive Unterschiede in den Anwendungsfällen vermuten. So eine Zerlegung ist nicht nur bei der Implementierung hilfreich, sondern mit Sicherheit auch später, wenn wir Fehler suchen oder die Funktionalität des Systems erweitern.

Weiterlesen auf cardsplus.info

Kommentare sind eine geeignete Metrik für die Qualität einer Produktdokumentation. Eine Moderation der Kommentare durch die Autoren ist dann jedoch zwingend notwendig. Nur eine Seite ohne Kommentare ist eine gute Seite. Andererseits ist jeder Kommentar ein für alle Leser sichtbarer Hinweis auf eine Lücke, eine Ungenauigkeit oder gar einen möglichen Fehler in der Dokumentation.

Kommentare unterstützen die Kommunikation im Team. Sie machen Feedback einzelner Personen für alle sichtbar. Sie lösen eine Diskussion aus, wenn es kontroverse Kommentare gibt. Sie sind die einzig verfügbare messbare Größe für die Qualität einer Seite in einem Wiki.

Weiterlesen auf cardsplus.info

In einfachen Worten fordert die ISO 9001 die Messung und Überwachung der Entwicklungsergebnisse. Mit geeigneten Werkzeugen messen wir kontinuierlich die Qualität unserer Software, die Einhaltung der Qualitätsmerkmale überwachen wir anhand von Metriken. Automatisierung von Test und Installation garantiert, dass Software nur in der definierten Qualität in die kundenwirksamen Umgebung gelangen. Flüchtigkeitsfehler durch manuelle Schritte werden ausgeschlossen.

Mit dem Einsatz von CARDS+ werden die notwendigen Testfälle identifiziert, die sicherstellen, dass alle angeforderten Fähigkeiten durch die Software im normalen Betrieb erfüllt werden. Die automatische und erfolgreiche Durchführung der Testfälle ist ein Annahmekriterium für den Auftraggeber.