Softwarequalität – Vom vielbeschworenen Mythos zur messbaren Größe
Häufig wird von qualitativ hochwertiger Software gesprochen, aber was ist das? Wie kann man Qualität messen oder vergleichen? Wir wollen uns das genauer anschauen und herausfinden, was Qualität eigentlich ist und wie man sie verbessern kann.
Was ist Qualität?
Wann kann man behaupten hoch qualitative Software zu entwickeln? Vielleicht weil eine Applikation hochverfügbar ist? Oder weil die Nutzer sehr zufrieden mit ihr sind? Ist der Preis ein Kriterium, oder die Anzahl bekannter Bugs?
Wenn es um die Qualität eines Produktes geht, scheint es als ob jeder eine eigene Meinung hätte, denn jeder hat individuelle Vorlieben und Dinge die ihm wichtig sind. Das macht Qualität sehr schwer greifbar. Da wir aber Software ausliefern wollen, die für jeden eine hohe Qualität aufweist, reicht uns das nicht. Wir müssen wissen wie wir Qualität objektiv messen können.
Vielleicht hilft es einen Schritt zurück zu treten und etwas abstrakter auf das Thema zu schauen. Dabei kann die ISO Definition von Qualität helfen: „(Software) Qualität ist der Grad in dem ein Satz inhärenter Merkmale eines Objekts Anforderungen erfüllt.“ Qualität gibt daher an, in welchem Maße ein Produkt den bekannten Anforderungen entspricht. Das Endprodukt muss also mit den zugrundeliegenden Anforderungen verglichen werden, um die Qualität zu bestimmen.
Damit ein Produkt für möglichst viele seiner Nutzer eine hohe Qualität hat, müssen die Anforderungen und Erwartungen aller Personen, die an dem Produkt interessiert sind (das sind Stakeholder), erfasst werden. Die Herausforderung ist es Anforderungen und Erwartungen so früh wie möglich herauszufinden und deren wesentlichen Merkmale zu dokumentieren. Denn nur wenn etwas dokumentiert ist, ist es im Nachhinein möglich zu bestimmen in wie weit das Produkt den Anforderungen entspricht. Daher ist es auch nicht möglich im Voraus die Qualität eines Produkts zu bestimmen. Man kann sich nur Ziele setzen, die man erreichen möchte.
Anforderungen vs. Erwartungen
Eine Forderung gegenüber einem Produkt kann entweder aus einer Anforderung oder einer Erwartung hervor gehen. Anforderungen basieren meistens auf externen Einflüssen, wie z.B. technischen Voraussetzungen oder Verfahrensregeln. Erwartungen hingegen sind von persönlicher Natur. Eine Anforderung kann z.B. sein, dass eine Applikation der Corporate Identity (CI) des Unternehmens entspricht. Jeder zukünftige Nutzer hat zusätzlich zur formalen Einhaltung der CI-Richtlinien Erwartungen an das Look and Feel des Produkts. Daher kann man sagen, dass Anforderungen eher objektiv sind und Erwartungen von Person zu Person leicht unterschiedlich sein können. Dadurch ist es schwieriger Erwartungen genau zu bestimmen.
Unabhängig davon ob es sich um Anforderungen oder Erwartungen handelt, ist es das wichtigste, dass sie messbar sind! Es reicht nicht aus hohe Verfügbarkeit zu verlangen. Anforderungen müssen mit einem messbaren Wert verknüpft werden (z.B. eine Verfügbarkeit von 99% im Jahr), ansonsten ist es im Nachhinein nicht möglich zu bestimmen, ob die Anforderung erfüllt wurde (z.B. wenn die Verfügbarkeit im Vergangenen Jahr bei 98% lag). Diese messbaren Werte werden als Akzeptanzkriterien bezeichnet, da sie beschreiben was erfüllt sein muss, damit das Produkt von Stakeholdern akzeptiert wird.
Anforderungen und Erwartungen können außerdem als funktional (z.B. die Möglichkeit Rechte innerhalb einer Applikation an User zu vergeben) oder nicht-funktional (z.B. Anforderungen an die Reaktionszeit einer Anwendung) unterschieden werden. Für beide Arten wiederum gilt, dass messbare Akzeptanzkriterien definiert werden müssen, um die Qualität des Produkts bestimmen zu können.
Explizit vs. Implizit
Der Unterschied zwischen ex- und impliziten Forderungen ist, dass explizite oftmals übergeordnete Themen betreffen, beispielsweise „Die Applikation muss SSL 3.0 verwenden!“. Implizite Forderungen hingegen sind indirekt in Aussagen wie „Die Anwendung sollte nicht zu langsam sein!“ enthalten. Mehrere Stakeholder sagen wahrscheinlich diesen Satz, aber für jeden von ihnen hat „langsam“ eine etwas andere Bedeutung. Es handelt sich also um eine implizite Erwartung. Die SSL 3.0 Verschlüsselung hingegen ist eine explizite Anforderung.
So wie für explizite Forderungen gilt auch für implizite, das Aussagen, bzw. Forderungen aufgeschrieben und mit messbaren Werten versehen werden müssen (z.B. „Die Applikation muss innerhalb von 0,5 Sek. auf Input reagieren.“). Durch das Aufschreiben der Forderung mit konkreten Akzeptanzkriterien werden ggf. Diskussionen zwischen den Stakeholdern ausbrechen, in denen sie sich auf einen Wert einigen werden. Mit diesem Wert kann dann später die Qualität bestimmt werden.
Oft sind sich Stakeholder ihrer Forderungen gar nicht bewusst oder sie sprechen sie nicht aus, weil sie denken, dass diese selbstverständlich und daher nicht der Rede wert sind. Die Herausforderung ist es also auch diese Forderungen so früh wie möglich zu erfassen, denn sie werden spätestens dann auf den Tisch kommen, wenn sie nicht erfüllt werden. Das fällt meistens am Ende des Projekts auf und das bedeutet, dass noch kurzfristig Änderungen vorgenommen werden müssen, oder dass die Qualität entsprechend geringer ist.
Normalerweise sind Anforderungen eher explizit und Erwartungen implizit, aber es gibt auch Ausnahmen.
Übereinstimmung
Dies ist der wichtigste Teil von Qualität: wir haben die Anforderungen und Erwartungen an unser Produkt erfasst und mit Akzeptanzkriterien versehen. Nun müssen wir das Ergebnis mit den Anforderungen vergleichen. Das zeigt wie wichtig messbare Kriterien sind, denn es ist schwierig die Qualität für schwammig formulierte Anforderungen zu bestimmen. Kriterien sollten konkrete Zahlen (z.B. 99% Verfügbarkeit), oder Ja/Nein Aussagen (z.B. Login möglich) sein. Falls es einmal nicht möglich sein sollte ein messbares Kriterium zu finden, muss die Forderung so detailiert wie möglich beschrieben werden und die betroffenen Personen müssen so intensiv wie möglich in die Umsetzung der Forderung involviert werden. Eine detailierte Beschreibung könnte dies sein: „Die Applikation muss innerhalb von 0,5 Sek. auf Input reagieren und Änderungen müssen innerhalb von 1 Sek. auf dem Bildschirm des Users angezeigt werden. Die 1 Sek. gilt für eine durchschittliche Internetverbindung mit 16 Mbit/s.“
Fazit
Was ist also Qualität? Ist es die Verfügbarkeit, die Zahl von Bugs, der Preis oder die Performance des Produkts? Die Antwort ist: Ja!
Auch jetzt noch ist Qualität ein schwer greifbarer Begriff, denn es ist nicht möglich ein Produkt ausschlißlich mit messbaren Kriterien zu beschreiben und genau bei schwammigen Definitionen kommen die individuellen Erwartungen von Stakeholdern zum Tragen. Um eine hohe Qualität für ein Produkt zu erreichen, solltet ihr diese Tipps befolgen:
> Sprecht so früh wie möglich mit den Stakeholdern um alles über deren Anforderungen und Erwartungen zu erfahren.
> Schreibt alle Forderungen auf.
> Versucht für möglichst viele der Forderungen messbare Akzeptanzkriterien festzulegen.
Dieser Beitrag wurde ursprünglich in unserem Partnerblog vom SCM-Manager Universe Team veröffentlicht.
Kommentare
Keine Kommentare