Qualitätsprobleme

Die November-Ausgabe diese Kolumne [1] hatte einige Mythen der Softwareentwicklung und die darauf aufbauend getroffenen Fehlentscheidung in Projekten zum Thema. Oft werden bestimmte Annahmen oder Aussagen in Projekten getroffen und daraufhin in gutem Glauben Maßnahmen veranlasst, die sich katastrophal auswirken können.Jeder von uns hat schon einmal bei der täglichen Arbeit eine Entscheidung getroffen, die mit nicht unerheblichem Aufwand korrigiert werden musste. Aus solchen Fehlern lernt der Mensch normalerweise, und solange ein solcher Fehler für alle Beteiligten lehrreich ist, lässt sich auch jedem groben Schnitzer etwas Positives abgewinnen. Nach dem Studium dieses Artikels werden Sie in der Lage sein, sich der Konsequenzen Ihrer Entscheidungen besser bewusst zu sein.Dazu ist vorab kurz zu überlegen, wie umfangreich das entstehende Problem wird, wenn zu folgenden Themen falsche Entscheidungen getroffen werden:

• Usability, zum Beispiel eine komplizierte Bedienung,
• eine Funktion, zum Beispiel neue Nutzer anlegen,
• Architektur,
• Ausnahmebehandlung.

Softwarequalität

Um zu einer einfacheren Einschätzung zu kommen, wie sich ein Fehler auswirkt, muss zunächst das Thema Softwarequalität beleuchtet werden. Das einfachste Verständnis des Themas Softwarequalität zeigt sich im sogenannten Softwarequalitätsmodell. Solche Modelle bündeln einzelne Aspekte zu Gruppen; so fasst das ISO-9126-Modell in Bild 1 die Aspekte Analysierbarkeit, Modifizierbarkeit, Stabilität und Prüfbarkeit zu der Gruppe Änderbarkeit zusammen. Wenn die Aspekte dieser Gruppe eingehalten werden, ist die Änderbarkeit des Softwareprojekts gut oder sogar sehr gut.

Quelle von Aspekten

Welche dieser Aspekte sind in einem Projekt wichtig? Das ist nicht so ohne Weiteres pauschal zu beantworten, denn keiner diese Aspekte wird explizit berücksichtigt, wenn nicht eine entsprechende Anforderung durch die Stakeholder (Kunde, Fachabteilung, Entwicklungsabteilung und so weiter) gestellt wird. Diese Anforderungen lassen sich immer in funktionale und nichtfunktionale Anforderungen aufteilen.Eine funktionale Anforderung beschreibt das Was in der Softwareentwicklung, also was die Software schließlich können soll. Eine mögliche, jedoch unzureichend formulierte Anforderung wäre, dass in einem Shop-System einzelne Artikel angelegt werden können. Die nichtfunktionalen Anforderungen beschreiben das Wie, also wie die entwickelte Software die geforderte Funktio­nalität anbieten muss. Ein Beispiel dazu wäre, dass ein entwickeltes Software­system bei einer Last von 1 000 gleichzeitig zugreifenden Anwendern auf einem Referenzsystem eine wohldefinierte Aufgabe in unter 500 Millisekunden bearbeiten muss.Bei Betrachtung der Aspektgruppen aus dem ISO-9126-Qualitätsmodell zeigt sich schnell, dass bis auf die Aspektgruppe „Funktionalität“ alle anderen Gruppen aus den nichtfunktionalen Anforderungen entstehen. Auch wenn es an dieser Stelle nicht das Thema des Artikels ist: Überlegen Sie kurz, wie qualitativ hochwertig ein Softwareprojekt sein kann, wenn zu Beginn fast keine nichtfunktionalen Anforderungen daran gestellt wurden. Ich hoffe, Sie sind sich der möglichen Konsequenzen bewusst.

Sichtweise von Aspekten

Zur weiteren Aufteilung der Aspekte müssen die verschiedenen Sichtweisen genauer untersucht werden, zunächst mit den Aspektgruppen, die sich aus den funktionalen Anforderungen ergeben. Wenn sich hier ein Fehler einschleicht, ist der Kunde natürlich nicht erfreut – die benötigte Funktion ist nicht oder nicht richtig umgesetzt und unter Umständen kann die Software nicht eingesetzt werden. Dem Entwicklungsteam ist das aber mehr oder weniger egal. Natürlich ist ein verärgerter Kunde nicht gut und die Zeit zum Nacharbeiten meist nicht eingeplant, aber die Folgearbeit wird nicht negativ beeinflusst.Bei den Gruppen, die aus den nichtfunktionalen Anforderungen kommen, ist die Frage nicht so einfach zu beantworten. Während beispielsweise der Kunde über eine schlechte Bedienbarkeit verärgert ist, betrachtet das Entwicklungsteam solche Probleme lange Zeit meist recht entspannt. Ist jedoch der Code schlecht lesbar oder erweiterbar, sind die schlechte Laune bei Entwicklern und natürlich auch höhere Projektfolgekosten im wahrsten Sinne des Wortes „vorprogrammiert“. Dem Kunden ist die Lesbarkeit des Codes aber vollkommen egal, diesen Fehler wird er selten direkt zu spüren bekommen.Die Gruppe der nichtfunktionalen Anforderungen wird also nochmals aufgeteilt in die Gruppen der Aspekte, die jeweils aus Kunden- und aus Entwicklungssicht relevant sind. Für den Kunden sind von Bedeutung:

• Zuverlässigkeit,
• Benutzbarkeit,
• Effizienz.

Aus Sicht des Entwicklers sind wichtig:

• Änderbarkeit,
• Übertragbarkeit.

Damit ergeben sich folgende Kategorien von Aspektgruppen, die Bild 1 noch einmal grafisch zusammenfasst:

• funktional aus Kundensicht (grün),
• nichtfunktional aus Kundensicht (gelb),
• nichtfunktional aus Entwicklungssicht (rot).

Sie werden sich bis hierher vielleicht gefragt haben, was das alles mit dem angesprochenen Thema des Artikels zu tun hat. Sie werden sehen, welche Tragweite eine Fehlentscheidung in der jeweiligen Kategorie hat.

Funktional aus Kundensicht (grün)

Die Fehlerart, die Ihnen oder dem Team bestimmt schon am häufigsten unterlaufen ist, gehört bestimmt zu dieser Kategorie (der grün gekennzeichnete Bereich in Bild 1). Eine vom Kunden gewünschte Funktionalität wurde nicht oder nicht richtig umgesetzt. Da zu jeder Anforderung ein Anwendungsfall zugeordnet werden kann, ist folglich die Arbeitsfähigkeit des Kunden mit der entwickelten Software herabgesetzt. Wie schwer dieser Fehler wiegt, lässt sich hier nicht pauschalisieren – das können kleine Fehler bei der Formatierung sein oder ein falsch ab­gebildeter Unternehmensprozess. Ohne Zweifel lässt sich jedoch feststellen, dass der Fehler kurzfristig durch den Kunden entdeckt wird und normalerweise vergleichsweise günstig zu beheben ist.Was bedeutet das? Wenn – bezogen auf die Aspektgruppe Funktionalität – eine falsche Entscheidung getroffen wird oder ein Fehler unterlaufen ist, ist dies zweifelsohne ärgerlich und unter Umständen etwas teurer in der Behebung; jedoch halten sich das Ausmaß und die damit verbundenen Konsequenzen in Grenzen.

Nichtfunktional aus Kundensicht (gelb)

Fehler, die in dieser Kategorie auftreten (in Bild 1 der gelb gekennzeichnete Bereich), fallen dem Kunden meist nicht sofort auf, und selbst wenn er den Fehler entdeckt hat, so wird er zunächst versuchen, sich mit dem Fehler zu arrangieren. Ist eine Software beispielsweise zu langsam (Aspektgruppe Effizienz), wird dies zwar irgendwann auffallen, aber zunächst toleriert. Erst wenn die Geschwindigkeit so langsam wird, dass die Bedienung nicht mehr ohne Weiteres möglich ist, wird dieses Problem gemeldet und muss entsprechend gelöst werden. Das heißt, Fehler in diesen Kategorien fallen später auf, und wenn sie dann behoben werden müssen, ist dies meist wesentlich aufwendiger und damit kostspieliger als in der Kategorie „Funktional aus Kundensicht“. Es ist also hier bereits Vorsicht geboten und Entscheidungen sollten nur mit entsprechendem Hintergrundwissen getroffen werden.

Nichtfunktional aus Entwicklungssicht (rot)

Die letzte Kategorie zieht die weitreichendsten Konsequenzen nach sich. Wird beispielsweise ein großes Softwareprojekt ohne Codierrichtlinien und ohne statische Codeanalyse durchgeführt, wirkt sich dies sehr negativ auf die Aspektgruppe Änderbarkeit auf. Der geschriebene Code ist schwer zu lesen und die entstehende Codestruktur – zum Beispiel das Klassendesign – kann sehr schlecht sein. Wem fällt dieses Versäumnis nun auf?Dem Kunden nicht. Er bekommt den Code und die Klassen­diagramme nie zu sehen und würde sie ohnehin nicht verstehen. Erst wenn die Menge der Fehler groß wird, Korrekturen sehr lange dauern oder einfache neue Funktionen aufgrund des Problems sehr teuer werden, wird er Alarm schlagen.Und die Entwickler? Natürlich sprechen diese die Probleme oft an, aber ganz ehrlich: Wie oft schon wurden diese Bedenken unter den Teppich gekehrt, weil der Lieblingskunde schnell das nächste tolle Feature haben wollte? Oft werden die Bedenken sogar so lange missachtet, bis das entstandene Problem derart groß ist, dass deren Behebung mehrere Jahre und teils gigantische Summen erfordern würde.Um das Ganze exemplarisch zu demonstrieren, kehren wir nun zurück zu den eingangs erwähnten falsch getroffenen Entscheidungen.

Schlechte Usability

Eine Software wurde so entworfen, dass die Anwendbarkeit im Hinblick auf die Zielgruppe nicht angemessen ist. So könnte beispielsweise der Bestellprozess in einem Shop zu kompliziert oder ein System zur Dokumentenverwaltung nur schlecht zu durchsuchen sein. Mit diesen Fehlern können manche Nutzer besser umgehen und manche schlechter; jedoch werden alle zunächst versuchen, dieses Problem irgendwie zu umgehen, um trotzdem das Ziel zu erreichen. Wenn die Analyse dann irgendwann feststellt, warum der Shop so wenig Umsatz macht oder die Verwendung des Dokumentensystems so ineffizient ist, versucht das verantwortliche Entwicklungsteam, das Problem spät, aber noch mit vertretbarem Aufwand zu lösen. In Bild 1 also ein gelbes Problem aus der Kategorie „nichtfunktional aus Kundensicht“.

Eine fehlerhafte Funktion

Ein Nutzer soll in der Lage sein, ein Produkt in einem Web­shop anzulegen oder verschiedene Versionen eines Dokuments einzusehen. Da dies meist Teil des Anwendungsfalls des Kunden ist, zeigt sich der Fehler relativ schnell und ist mit vertretbarem Aufwand durch die Entwicklungsabteilung zu beheben. In Bild 1 ist das somit ein grüner Fehler aus der Kategorie „funktional aus Kundensicht“.

Falsche Architektur

Anstatt für den besagten Webshop eine saubere Architektur mit mehreren Schichten zugrunde zu legen, wurde ein großer Monolith entwickelt. Die anfangs schnelle Entwicklungsgeschwindigkeit sinkt zunehmend, die Zahl der Fehler steigt und ein neues Merkmal wird immer teurer.Wenn die Entwickler nicht Alarm schlagen, wird der Kunde erst nachfragen, wenn zu wenig neue Funktionen kommen, zu viele Fehler auftauchen und eine einfache Funktion plötzlich ein Vielfaches wie zu Beginn des Projekts kostet. Wird der Fehler in der Architektur nun entdeckt, muss die Software meist sehr umfangreich refaktorisiert werden, was sehr teuer sein kann und nicht selten die Kosten einer Neuentwicklung übersteigt. Damit ist dies ein roter Fehler aus der Kategorie „nichtfunktional aus Entwicklungssicht“.

Fehlerhafte Ausnahmebehandlung

Fehler treten in der Anwendung auf, wichtig ist es jedoch, mit diesen Fehlern entsprechend umzugehen [2]. Werden Ausnahmen nicht richtig eingesetzt, behandelt und protokolliert, kann die Anwendung abstürzen und die Fehlersuche zur Mammutaufgabe werden. Während die Anwendung zunächst Aufgaben erneut ausführt oder neu gestartet wird, wird dieses Verhalten später gemeldet und behoben. Auch wenn der Fehler damit zu der Kategorie „nichtfunktional aus Kundensicht“ gehört (also gelb, Aspektgruppe Zuverlässigkeit), muss ein solches Versäumnis ähnlich dem Beispiel zur schlechten Architektur meist durch eine teure Refaktorisierung behoben werden.

Was Sie mit diesem Wissen anfangen können

Wie schon erwähnt, lassen sich die hier getroffenen Aussagen und die Beispiele nicht pauschalisieren. Natürlich kann auch ein funktionaler Fehler sehr zeitaufwendig sein oder ein Fehler bei der Nutzbarkeit sehr schnell auffallen, das steht außer Frage. Es geht hier viel mehr darum, für die drei verschiedenen Kategorien von Fehlern (grün, gelb, rot) und die damit verbundenen Fragen zu sensibilisieren:

• Wie teuer wird eine Fehlentscheidung?
• Wann fällt eine Fehlentscheidung auf?
• Wem fällt die Fehlentscheidung auf?

Wenn Sie beispielsweise die Architekturentscheidungen einem Entwickler überlassen, der in diesem Bereich nicht geschult ist, kann diese Entscheidung unter Umständen erst sehr spät auffallen und dann sehr teuer in der Behebung sein. Oder wenn Sie die Anforderung von jemandem aufnehmen lassen, der das Problem nicht beherrscht, werden meist nur funktionale und kaum nichtfunktionale Anforderungen aufgenommen. Wie hier gezeigt wurde, werden also die Kategorien „nichtfunktional aus Kundensicht“ und „nichtfunktional aus Entwicklungssicht“ kaum bis gar nicht mit entsprechenden Aspekten adressiert; beide Versäumnisse haben jedoch meist erst im späteren Projektverlauf eine ernsthafte Auswirkung.

Fazit

Diese Liste an Versäumnissen ließe sich ewig weiterführen, und sicher sind Ihnen auch schon einige Beispiele eingefallen. Denken Sie einen Moment über die im letzten Projekt getroffenen Fehlentscheidungen nach und überlegen Sie, wem und wann die Fehler aufgefallen sind und welche Kosten mit der Behebung verbunden waren. Das alles wird nicht dabei helfen, keine Fehlentscheidungen mehr zu treffen, jedoch können Sie mit diesem Wissen besser einschätzen, ob eine Entscheidung noch einmal überdacht werden oder gar externe Hilfe dazugeholt werden sollte.Wenn Sie dann eine Entscheidung treffen, die erst mittel- oder langfristige Konsequenzen bei einem Fehler haben sollte, sorgen sie dafür, dass sich die Richtigkeit der Entscheidung mit entsprechenden Metriken überprüfen lässt. So kann beispielsweise die Teamgeschwindigkeit auf eine zu kom­plexe Architektur hinweisen, oder eine zu komplexe Codestruktur lässt sich mit Tools zur statischen Codeanalyse wie NDepend [3] erkennen. Was auch immer Sie tun: Wichtige Entscheidungen sollten immer wohlüberlegt sein.

Fussnoten

1. David Tielke, Mythen der Softwareentwicklung, Falsche Annahmen und ihre Folgen, dotnetpro 11/2017, Seite 68 ff., http://www.dotnetpro.de/A1711DDD
2. David Tielke, Keine Ausnahme ohne Exception, Ausnahmen und Entwicklungsrichtlinien, dotnetpro 6/2016, Seite 80 ff., http://www.dotnetpro.de/A1606DDD
3. NDepend, http://www.ndepend.com