Oft sprechen wir über die Qualität von Software, fluchen, wenn sich sie nicht so funktioniert, wie wir das wollen, loben intuitive Bedienkonzepte und fordern im Rahmen des Projektmanagements immer „gute Qualität“. Aber was genau ist „gute Software“? Sind es fehlerfreie Funktionen? Geht es um den Funktionsumfang, je mehr desto besser? Oder dürfen wir Softwareentwickler auch die Qualität des Codes mit einbeziehen? Und wenn ja, was betrachten wir da? Die Formatierung des Quellcodes? Finden wir besonders einfallsreiche Designkonstruktionen gut? Oder ist guter Code der, den wir auf Anhieb verstehen?
Vor Jahren hat ein mir damals vorgesetzter Bereichsleiter eine flammende Rede gehalten, in der er eine unglaubliche Qualitätssteigerung prophezeite, die durch die Einführung von automatisierten Tests erreicht werden sollte. Ich habe mich damals unheimlich aufgeregt, weil ich mich dagegen gewehrt habe, dass Funktionalität das einzig maßgebliche Qualitätskriterium sein soll. Heute weiß ich, dass es nur eine Frage der Perspektive ist. Ein Anwender kann nur beurteilen, was er sieht. Man beachte dabei auch die Wortwahl: „Gute Software“ in der Empfindung des Benutzers ist „gut designt“, „schlechte Software“ ist „schlecht programmiert“. Für uns Maintainer zählt vor allem, ob wir den Code verstehen und ihn danach ändern können.
Der User sieht also die Oberfläche und kann z.B. Bedienbarkeit und Korrektheit beurteilen. Für Entwickler ist Analysierbarkeit und Modifizierbarkeit wichtig. Die Begriffe habe ich nicht zufällig gewählt. Sie sind Teil der Definitionen in ISO 9126, in der Kriterien für Softwarequalität definiert sind. Zugegeben, die Norm ist nicht mehr ganz aktuell, denn sie ist angeblich in ISO 25000 aufgegangen. Ich konnte jedoch bisher keinen Blick in ISO 25000 werfen, also halte ich mich an den alten Standard, solange der noch nicht zurückgezogen ist. Die wesentlichen Qualitätsmerkmale für Software sind in der Norm folgendermaßen aufgeführt:
- Funktionalität
- Zuverlässigkeit
- Benutzbarkeit
- Effizienz
- Wartbarkeit/Änderbarkeit
- Übertragbarkeit
Dann ist ja alles gut, jetzt wissen wir ja, was Qualität bedeutet. Dummerweise haben wir aber kaum Metriken zur Verfügung, um das Wissen in Zahlen zu fassen. Wirklich messbar ohne subjektive Wertung sind eigentlich nur Funktionalität (geht/geht nicht) und Effizienz (z.B. durch Reaktionszeiten). Die Wartbarkeit/Änderbarkeit kann man versuchen durch Codekomplexität auszudrücken, hat damit aber nur einen indirekten Wert in der Hand. Und bei der Benutzbarkeit wird’s düster: „Anzahl Klicks um eine Funktion zu nutzen“ fällt mir spontan ein, aber wie kann ich übertragbar ausdrücken, wie leicht oder schwer die Benutzung der Software zu erlernen ist?
Vor dem Hintergrund der fehlenden Metriken laufen wir Gefahr, mit Softwarequalität nur die messbaren Anteile der Software zu meinen, oder es werden nur diese Aspekte verstanden, obwohl wir eigentlich die umfassende Qualität mit all ihren Kriterien ausdrücken wollten. Sprechen wir über Softwarequalität, bleibt uns also nichts anderes übrig, als die gemeinten Aspekte aufzuzählen, um nicht mißverstanden zu werden. Vielleicht wird damit auch die nächste Diskussion über Qualität mit unserem Projektleiter einfacher.