Hoher Termin- und Budgetdruck, kürzere Entwicklungszeiten bei gleichzeitig komplexer werdenden Softwaresystemen, die zudem oft noch verteilt entwickelt werden: Die Anforderungen an die Entwicklung individueller Softwarelösungen steigen. Während auf die Optimierung von Prozessen in Entwicklungsprojekten bereits großer Wert gelegt wird, vernachlässigen viele Unternehmen die Produktqualität. Dabei macht sich schlechte Software schnell bemerkbar: 60 bis 70 Prozent der IT-Budgets werden derzeit in die Wartung und Weiterentwicklung investiert. Kosten und Risiken lassen sich aber reduzieren, wenn die Produktqualität bereits im Entwicklungsprozess gesteuert wird. Dafür liefert ein systematisches Software-Controlling Methodik und Werkzeuge: Qualitätseigenschaften von Software lassen sich eindeutig planen und Sollabweichungen früh erkennen. Software-Dienstleister können so ihre Projekte im vorgegebenen Budget- und Terminrahmen abwickeln und die Hauptanforderung der IT-Entscheider erfüllen: schnell stabile Systeme zu liefern.

Als standardisiertes Verfahren für ein aussagekräftiges Software-Controlling bietet sich eine dreistufige Methodik an. Ziel dabei ist es, die Qualität der Software während des gesamten Entwicklungsprozesses anhand definierter Kriterien zu steuern. Diese Vorgehensweise geht deutlich über die heute zumeist betriebene Prüfung von Codequalität (mittels Findbugs, Checkstyle, CPD, JavaNCSS etc.) hinaus. Die ganzheitliche Planung und Steuerung von Softwarequalität wird heute nur selten praktiziert - auch weil dafür geeignete Werkzeuge und Standardisierungen fehlen.

Sensoren liefern Werte für das Qualitätsmodell

Den Kern des dreistufigen Verfahrens bildet ein Qualitätsmodell, mit dem die Qualität der Software anhand von konkreten Eigenschaften und Kennzahlen bewertet wird. Hierzu werden Sensoren in die Entwicklungsumgebungen integriert, die permanent und bereits sehr früh im Entwicklungsprozess Werte für die definierten Kennzahlen auf der Ebene von Komponenten messen. Die Werte werden dann in ein Software-Cockpit eingespeist, über das der Softwarearchitekt jederzeit den aktuellen Qualitätsstand erfahren kann. Sollabweichungen sind somit schnell erkannt. Die Kennzahlen des Qualitätsmodells - das "Blutbild der Software" - sind also ein Frühwarnsystem für Qualitätsprobleme und ein aktives Steuerungsinstrument für anspruchsvolle Softwareprojekte.

Quality-Gates

Auf der Qualitätssteuerung über das Qualitätsmodell setzt die zweite Stufe auf: Quality-Gates werden in das Software-Controlling eingebunden. Dabei handelt es sich um definierte Prüfpunkte vor kritischen Projektphasen, anhand derer die inhaltliche Reife einer Phase überprüft wird. Das erste Quality-Gate findet bereits vor Abgabe des Angebots statt und leitet zur Spezifikation der Software über. Ein weiteres Gate wird im ersten Drittel der Spezifikationsphase installiert, um wesentliche fachliche Entwurfsentscheidungen zu überprüfen. Vor einer Realisierung in der Breite ist ein Gate platziert, das die Konstruktionsentscheidungen noch einmal im Abgleich mit den Anforderungen des Kunden spiegelt und die Einhaltung von standardisierten Entwurfsprinzipien prüft. Die Prüfungen werden von externen, nicht am Projekt beteiligten Experten vorgenommen, um eine größtmögliche Objektivität zu gewährleisten. Im Rahmen dieser Qualitätssicherung werden die im Qualitätsmodell gewonnenen Kennzahlen noch einmal explizit anhand vorgegebener Sollwerte beurteilt und durch weitere Messungen ergänzt.

Testläufe für funktionale und nichtfunktionale Aspekte

Die dritte Stufe besteht aus definierten Test- und Abnahmeverfahren auf Komponentenebene. Hierzu gehören während der gesamten Entwicklungsphase funktionale und nichtfunktionale Testläufe, die beispielsweise die fachliche Korrektheit sowie Performance und Stabilität des Systems prüfen. Eine kontinuierliche Integration untersucht die Zusammenarbeit der einzelnen Komponenten. Mit diesen drei Stufen leistet das Software-Controlling eine Qualitätssteuerung, die als Gesamtansatz eine Antwort auf die schärfer werdenden Rahmenbedingungen in der Softwareentwicklung gibt.

Das Ziel sind valide Qualitätsaussagen

Im Gegensatz zur Qualitätsnorm ISO 9126, deren Eigenschaften nur schwer messbar sind, hat das Qualitätsmodell den Anspruch, valide Aussagen zur Produktqualität von Softwarelösungen zu machen. Auf Grundlage von Erfahrungswerten wurden acht relevante Eigenschaften definiert, von denen sich sechs (Größenverhältnisse, Codeanomalien, Zuverlässigkeit, Kritikalität, Qualitätssicherung und Performance) direkt auf das Produkt beziehen. Zwei zusätzliche Eigenschaften - Fortschritt und Umfragewert - geben Aufschluss über Prozesse, die sich auf die Qualität der zu entwickelnden Software auswirken können.

Den Eigenschaften werden definierte Kennzahlen zugeordnet. Sensoren, teilweise aber auch Projektmitarbeiter, liefern Werte, die in das Software-Cockpit einfließen. Die Kennzahlen werden für jede Komponente der Software, die der Architekt anlegt, einzeln gemessen. Für eine Auftragsverwaltung eines Automobilherstellers hat der Softwarearchitekt beispielsweise ständigen Zugriff auf Messwerte zu den Komponenten Kunde, Preis, Fahrzeugkonfiguration, Auftrag, Distribution und Baubarkeitsprüfung. Er kann so die Qualität jedes einzelnen Bausteins sowie der Gesamtsoftware anhand der Kennzahlen bewerten. Wie beim Blutbild des Menschen steht jede Kennzahl erst einmal für sich. Ob die Software tatsächlich "gesund" ist, muss der Architekt anhand des Gesamtbildes beurteilen.

Größenverhältnisse im Rahmen halten

Die Anzahl der Codeeinheiten sowie die Anzahl der Abhängigkeiten geben als Kennzahlen der Eigenschaft "Größenverhältnisse" Auskunft über die Struktur der Software. Diese Größenverhältnisse wirken sich später direkt auf die Wartbarkeit der Software aus. Wichtig ist daher, dass die Komponenten im Verhältnis zur Projektgröße ein angemessenes Größenverhältnis aufweisen. Kritisch kann beispielsweise sein, wenn eine einzige Komponente mehr als 20 Entitäten verwaltet oder ihre Dienstimplementierung viele Methoden mit mehr als 200 Lines of Code besitzt. Darüber hinaus geben die Kennzahlen Aufschluss über unerwünschte Abhängigkeiten oder Zyklen. Architekturverletzungen sind so bereits zum Zeitpunkt ihrer Entstehung sichtbar und einfacher zu beheben als in einem fortgeschrittenen Stadium der Softwareentwicklung.

Gegen Codeanomalien und schlechte Dokumentation

Die Qualität des Codes wird durch die Anzahl der Codeanomalien sowie auf Basis der Warnungsdichte bewertet. Codeanomalien sind inakzeptable Problemstellen wie zum Beispiel eine ungenügende Fehlerbehandlung oder Verstöße gegen das Prinzip der defensiven Programmierung. Die Kennzahl Warnungsdichte zeigt darüber hinaus die Anzahl akzeptierter Problemstellen, die für das Funktionieren der Software unkritisch sind. Das sind zum Beispiel fehlende Kommentare im Code oder zu große Parameterleisten, mit denen zwar die Software reibungslos funktionieren kann, ihre Verständlichkeit auf Codeebene aber leidet. Eine zu hohe Warnungsdichte dient ebenfalls als Indikator für Qualitätsprobleme in der Software.

Fehlerprognosen zeigen Zuverlässigkeit auf

Um die Zuverlässigkeit einer Software zu bewerten, werden die offenen und geschlossenen Fehler auf Komponentenebene angezeigt. So ist ein schnelles Reagieren möglich, um die angestrebte Fehlerzahl von null zu erreichen. Die Fehlerdichte ist die Anzahl der Fehler pro Codeumfang. Sie ist das am besten vergleichbare und belastbare Qualitätsmaß und zeigt Qualitätsbrennpunkte. Erfahrungsgemäß wird eine Komponente, die in allen Projektphasen durchgängig viele Fehler aufwies, auch im späteren Einsatz Probleme haben - auch wenn es zum Zeitpunkt der Produktion keine offenen Fehler gab und alle zuvor aufgetretenen Fehler behoben wurden. Mit der Kennzahl Fehlerdichte kann so bereits eine Fehlerprognose berechnet werden, bevor die Software in Produktion geht. Ist die Prognose schlecht, sollten zusätzliche Tests oder eine vorgeschaltete Pilotphase die Funktionalität der Software nochmals prüfen.

Kritische Komponenten definieren

Kritikalität kann im Gegensatz zu den anderen Eigenschaften des Modells nicht über integrierte Sensoren gemessen werden, sondern bedarf einer Einschätzung des verantwortlichen Softwarearchitekten. Dennoch ist sie eine zentrale Größe, um die Produktqualität einer gesamten Softwarelösung bewerten und andere Eigenschaften einordnen zu können. Der Softwarearchitekt identifiziert diejenigen Komponenten, die nach fachlichen Gesichtspunkten für das Gesamtsystem besonders relevant oder technisch neu sind, und kategorisiert sie nach ihrer kritischen Bedeutung. Bei einer Auftragsverwaltung in der Automobilindustrie wären kritische Komponenten beispielsweise die Preisberechnung mit ihren komplizierten Währungsumrechnungen, die Baubarkeitsprüfung oder die Fahrzeugkonfiguration. Im Bereich Logistik sind Routenoptimierungen schwierig, während die Kundenverwaltung eher zum Standard gehört. Kritikalität gestattet eine Fokussierung und eine gezielte Steuerung von Qualität.

Die Eigenschaft Qualitätssicherung zeigt, inwieweit die Software bereits mit Testverfahren überprüft wurde. Bei der Kennzahl "Testüberdeckung" misst ein Sensor im Hintergrund, wie viel Code tatsächlich in Tests durchlaufen wurde. Eine Testüberdeckung von 50 Prozent sagt aus, dass die Hälfte des geschriebenen Codes nie in einem Test zum Einsatz kam, die Wahrscheinlichkeit für spätere Fehler ist demnach hoch. Beim Qualitätssicherungsaufwand ist zusätzlich nachvollziehbar, wie viele Bearbeitertage in Code-Reviews investiert wurden.

Performance gibt Aufschluss über die Benutzbarkeit

Die Kennzahlen "Antwortzeit", "Durchsatz" und "Aufrufhäufigkeit" stellen zentrale nichtfunktionale Anforderungen an die Software dar und liefern Ergebnisse für die Benutzbarkeit durch den Anwender: Wie lange braucht die Komponente "Fahrzeugkonfiguration", bis sie antwortet, wie viele Daten kann sie in einem bestimmten Zeitrahmen verarbeiten, und wie häufig wird sie innerhalb der Gesamtlösung aufgerufen?

"Fortschritt" und "Umfragewert" ergänzen die reinen Produkteigenschaften um Angaben zu Prozessfortschritt und Einschätzungen des Projektteams. So wird der Status jeder Komponente aus dem Planungswerkzeug eingespeist, genauso wie alle offenen Punkte im Software-Cockpit einzusehen sind. Hier kann der Softwarearchitekt mögliche Konflikte frühzeitig voraussehen, zum Beispiel, wenn der zu enge Zeitplan nicht zum aktuellen Qualitätsstand der Software passt.

Die Kennzahl "Änderungshäufigkeit" weist darauf hin, wie viele Anpassungen an einer Komponente insgesamt vorgenommen werden mussten. Eine hohe Änderungshäufigkeit kurz vor den Integrationstests ist sehr kritisch für den Projekterfolg. Schließlich bleibt die Einschätzung durch das Team auch in einem Software-Controlling-Prozess, der Wert auf valide Messgrößen aus der Entwicklungsumgebung legt, eine zu beachtende Kennziffer. Wichtig ist, dass sie als Zusatzindikator für reale Messwerte hinzugezogen wird. So können die Messwerte der Produktkennzahlen bestätigt oder bei Widersprüchen zu der Teameinschätzung genauer untersucht werden.

Das Gesamtbild ist entscheidend

Für eine valide Bewertung der Qualität einzelner Komponenten sowie des Gesamtsystems muss der Softwarearchitekt die Kennzahlen gemeinsam interpretieren, nur dann sind sie als Frühwarnsystem für die Produktqualität aussagekräftig. Zwei Beispiele zur Veranschaulichung: Hat eine unkritische Komponente eine höhere Warnungsdichte, ist dies für die Softwarelösung weniger problematisch. Wird bei einer kleinen, aber wichtigen Komponente allerdings eine geringe Testüberdeckung angezeigt, scheint diese im Verhältnis fehleranfällig und für das System risikoreich zu sein.

Für alle Kennzahlen sollten Schwellenwerte oder Toleranzkorridore festgelegt werden, die nicht überschritten werden dürfen. Um das Qualitätsmodell als Steuerungsinstrument zu standardisieren, muss man dafür in den nächsten Jahren noch Daten aus einer Vielzahl von Softwareprojekten sammeln. Erste Werte für kritische Schwellwerte liegen heute bereits vor, jedoch lebt das Software-Controlling von der zukünftigen permanenten Justierung der Zahlenwerte auch in Abhängigkeit von bestimmten Projekttypen. (ue)