Die Sicht des Architekten auf Softwarequalität in Unternehmen
Wie lässt sich Softwarequalität erreichen? Sie entsteht mithilfe von Werkzeugen, Standards und Prozessen, vor allem aber Menschen sind für sie verantwortlich. Manche ignorieren diese Tatsache lieber, andere nehmen sie hingegen ernst. Dadurch bekommen diese die Gelegenheit, die Qualität überproportional zum Aufwand zu steigern.
- Robert Bräutigam
Theoretisch sollte es keinen Artikel über Softwarequalität geben, der nicht mit einer Definition anfängt. Entwickler würden unter dem Begriff meistens Codequalität verstehen und wahrscheinlich Metriken (und Werkzeuge) empfehlen. Zum Beispiel: Wie viel Code ist durch Unit-Tests abgedeckt? Wie steht es um die zyklomatische Komplexität der Methoden? Wie hoch ist der Zusammenhalt des Codes? Wie stabil sind die abstrakten Klassen? Solche Metriken lassen sich relativ leicht definieren, und in den richtigen Händen sind sie wichtige Werkzeuge.
Trotzdem sind deren Zahlen nichts weiter als Indikatoren, die auf ein Problem oder Defizit hinweisen können, aber selbst keine eindeutige Aussagekraft haben. Eine Testabdeckung von 100 Prozent sieht etwa in einem Managementbericht oder auf einer Power-Point-Folie überzeugend aus. Jedoch würde jeder Entwickler darauf hinweisen, dass so etwas selten praktisch ist und lediglich bedeutet, dass das Werkzeug keine weiteren Aussagen als die treffen kann, es sei alles während des Tests gelaufen.
Wenn Entwickler sich im Code umsehen, können sie recht einfach erkennen, ob er "gut" oder "schlecht" ist – auch ohne Metriken. Nicht nur wegen der tatsächlichen Fehler, die sie sehen, sondern anhand des Gefühls, das sich durch ihre Erfahrungen entwickelt hat. Nicht alles ist dabei objektiv. Was etwa für den einen Entwickler "lesbar" ist, kann für einen anderen durchaus "unlesbar" sein. Manche wollen unbedingt, dass "Interface"-Klassen mit "I" anfangen und manche eben nicht.
Endbenutzer bewerten bei der Qualität meistens die Benutzeroberfläche, also wie leicht es ist, bestimmte Abläufe und Aufgaben zu erledigen oder auch wie schnell man lernen kann, sie zu bedienen. Obwohl man oft versucht, Metriken aufzustellen, die diesen Aspekt spezifizieren sollen, ist das bisher niemandem gelungen. Es lässt sich aber die "Benutzbarkeit" messen, indem man etwa Oberflächen vom Benutzer bewerten lässt. Leider geht das aber erst nach Fertigstellung der Oberfläche.
Für Betreiber bedeutet Qualität nur, wie viel Aufwand benötigt wird, um das System am Laufen zu halten. Das ist messbar, etwa an der Anzahl der Supportanfragen oder der Updates, meistens sogar planbar. Andere Perspektiven haben Tester, Qualitätsmanager, Scrum Master, Projektmanager und auch Architekten. Letztere sind dafür verantwortlich, alle diese Perspektiven im Auge zu behalten, mit den entsprechenden Personen zu reden und alles in ein konsistentes Bild zu gießen. Bei der Kategorisierung hilft ISO 9126, und Risiken und Zielerreichung lassen sich mit Methoden wie ATAM (Architecture Tradeoff Analysis Method) einschätzen.
Für die meisten dieser Perspektiven kann man zumindest etwas messen, Metriken aufstellen und Ziele definieren. Leider garantiert das weder, dass die aufgestellten Metriken richtig angewendet und interpretiert, noch, dass die Ziele tatsächlich erreicht werden. Was bedeutet es, wenn man 80 Prozent Code Coverage fordert? Garantiert das wirklich, dass der Code getestet wird? Natürlich nicht, es hängt davon ab, wie die Tests geschrieben sind.
Qualität entsteht durch Menschen
Die einfache Beobachtung ist: Softwarequalität entsteht durch die Arbeit von Menschen. Entwickler, Architekten, Tester, Prozessmanager, Projektmanager, Scrum Master und so weiter sind dafür verantwortlich, Software gemeinsam zu entwickeln und dabei auf Qualität zu achten. Dazu brauchen sie Werkzeuge, die die Arbeit erleichtern oder sogar erst ermöglichen. Tester brauchen Bug-Tracking-Werkzeuge, Entwickler IDEs, Versionskontrolle, Bibliotheken, FindBugs, Sonar und Continuous Integration. Sogar Scrum Master brauchen zumindest eine Wand, auf die sie ihre Tasks aufkleben können. Wichtig zu erkennen ist jedoch, dass die richtigen Menschen ohne die meisten Werkzeuge (oder Prozesse) noch immer Software mit guter Qualität liefern können, aber die richtigen Werkzeuge ohne die richtigen Menschen können das nicht.
Das heißt allerdings nicht, dass alle Entwicklungsteams nur aus den "besten" Programmierern bestehen müssen, das wäre kaum realistisch und würde in den meisten Fällen auch nicht funktionieren. Auf die Teamzusammensetzung kommt es an. Dafür muss man nicht nur individuelles Fachwissen, Persönlichkeit und andere Charakteristika beachten, sondern auch, wie sich diese auf die anderen Teammitglieder auswirken.
Solche Beobachtungen klingen vielleicht trivial, aber es kommt trotzdem oft vor, dass gute Teams aufgebrochen und neue Teammitglieder ohne Absprache ins Team geworfen oder das "zentrale" Menschen, die das Team zusammenhalten, einfach versetzt werden. Die Gruppendynamik wird oft ignoriert, obwohl sie in der psychologischen Fachliteratur grĂĽndlich diskutiert wird. Bruce Tuckman [1] stuft das Verhalten und die Entwicklung eines Teams beispielsweise in die folgenden Kategorien ein:
- Forming: die ersten Schritte des Teams, die Menschen lernen einander kennen.
- Storming: Die Lösungsansätze werden diskutiert, es entsteht ein Wettbewerb nicht nur zwischen Ideen, sondern auch zwischen Teammitgliedern. Manche Teams können diesen Zustand nicht mehr verlassen.
- Norming: Die Ziele sind aufgestellt und die Hierarchie zwischen den Teamkollegen festgelegt. Es gibt ein Verständnis, wie sie miteinander kommunizieren können.
- Performing: Teams in diesem Stadium werden hochperformant und funktionieren selbstständig. Es reicht also nicht, die Menschen nur individuell zu selektieren, um ein Team zu bilden, die Teamdynamik ist immer im Auge zu behalten.
