Cloudogu Logo

Hallo, wir sind Cloudogu!

Experten für Software-Lifecycle-Management und Prozess­auto­mati­sierung, Förderer von Open-Source-Soft­ware und Entwickler des Cloudogu EcoSystem.

featured image Softwarequalität verstehen
24.02.2016 in Quality

Softwarequalität verstehen


Daniel Huchthausen
Daniel Huchthausen

IT Consultant


Man spricht oft von qualitativ hochwertigen Softwareprodukten, aber was ist das eigentlich? Wie kann man die Qualität einer Anwendung messen oder vergleichen? Schauen wir uns dieses Thema genauer an und erörtern wir, was Qualität bedeutet und wie sie verbessert werden kann.

Was ist Qualität?

Wie kann man behaupten, dass ein Softwareprodukt eine hohe Qualität hat? Weil die Anwendung eine hohe Verfügbarkeit hat? Oder weil die Benutzer sehr zufrieden damit sind? Ist es wegen des Preises? Oder ist eine fehlerfreie Anwendung der Schlüssel zu hoher Qualität? Die Antwort ist: ja. Alle diese Aspekte spielen eine Rolle und je nachdem mit wem man spricht, Endanwender:in, Administrator:in, Teamleiter:in können die Aspekte unterschiedlich gewichtet sein. Deswegeb müssen wir uns darauf einigen, dass Qualität irgendwie immateriell ist. Da wir jedoch qualitativ hochwertige Produkte liefern wollen, reicht dies nicht aus, wir brauchen eine klare Definition von Qualität.

Versuchen wir, einen Schritt zurückzutreten und die ISO-Definition von Qualität zu betrachten, denn das könnte ein guter Ausgangspunkt für unsere Betrachtung sein. „(Software-)Qualität ist der Grad der Übereinstimmung mit expliziten oder impliziten Anforderungen und Erwartungen“ Das bedeutet, dass man das Endprodukt mit den zugrunde liegenden Anforderungen vergleichen muss, um seine Qualität zu bestimmen.

Elemente von Qualität

Anforderungen und Erwartungen können von allen Personen vorgebracht werden, die an dem Projekt oder Produkt interessiert sind (d. h. von allen Beteiligten). Durch Gespräche mit diesen Personen können Sie herausfinden, was sie von dem Produkt erwarten. Die Herausforderung besteht darin, alle Anforderungen und Erwartungen so früh wie möglich herauszufinden und ihre konkreten Merkmale aufzuschreiben. Nur wenn sie aufgeschrieben sind, ist es möglich, die Konformität, die Qualität, im Nachhinein zu bestimmen. Es ist nicht möglich, Qualität im Voraus zu bestimmen, man kann nur Ziele setzen, die man erreichen will. Um die Definition besser zu verstehen, werden wir uns die verschiedenen Aspekte genauer ansehen.

Anforderungen vs. Erwartungen

Je nach Quelle kann eine Forderung entweder eine Anforderung oder eine Erwartung sein. In der Regel werden Anforderungen durch äußere Einflüsse wie Regeln einer Organisation oder technische Voraussetzungen bestimmt, während Erwartungen persönlich motiviert sind. Eine Anforderung könnte sein, dass die Anwendung der Corporate Identity des Unternehmens entspricht. Darüber hinaus kann es Erwartungen an das Aussehen und die Handhabung des Produkts geben. Daher sind Anforderungen oft objektiver, während Erwartungen von Person zu Person leicht variieren können, was es schwieriger macht, sie zu bestimmen. Das Wichtigste bei Anforderungen und Erwartungen ist, dass sie messbar sein müssen. Es reicht nicht aus, eine hohe Verfügbarkeit zu fordern. Es ist notwendig, einen Wert für die Verfügbarkeit des Systems (z.B. 99% pro Jahr) anzugeben. Andernfalls ist nicht klar, ob die Forderung erfüllt wird, wenn eine Analyse ergibt, dass die Verfügbarkeit bei 98 % liegt.

Anforderungen und Erwartungen können auch als funktional (z.B. eine spezielle Funktionalität wie Login/Logout) oder nicht-funktional (z.B. die Reaktionszeit der Anwendung) unterschieden werden. Unabhängig von der Art der Anforderung ist es wichtig, Akzeptanzkriterien festzulegen, um sie messbar zu machen.

Explizit vs. Implizit

Der Unterschied zwischen expliziten und impliziten Anforderungen an eine Anwendung besteht darin, dass explizite Anforderungen von übergeordneten Stellen wie z.B. organisatorischen Regeln kommen. Zum Beispiel: „Die Anwendung muss die Authentifizierung über SSL 3.0 beherrschen!“. Implizite Anforderungen hingegen werden in Aussagen wie „Die Anwendung sollte nicht zu langsam sein!“ ausgedrückt. Mehrere Beteiligte könnten einen ähnlichen Satz sagen, aber „langsam“ könnte für jeden von ihnen eine andere Bedeutung haben. Daher ist es notwendig, diese Aussagen/Anforderungen aufzuschreiben und sie mit Werten (Akzeptanzkriterien) zu versehen. Dadurch werden sie messbar (z. B. „Die Anwendung muss innerhalb von 0,5 Sekunden auf neue Eingaben reagieren.“). Dieser messbare Wert wird zu einer Diskussion zwischen den Beteiligten führen und am Ende werden sich alle auf einen bestimmten Wert einigen und es wird möglich sein, die Konformität der Anwendung mit der Anforderung zu überprüfen. Oft kann eine implizite Anforderung zu mehreren Akzeptanzkriterien führen. Manchmal sind sich die Beteiligten zu einem bestimmten Zeitpunkt nicht einmal über alle ihre Anforderungen im Klaren, weil sie der Meinung sind, dass die Anforderung offensichtlich ist und es sich daher nicht lohnt, sie zu erwähnen. Es ist eine große Herausforderung, diese Anforderungen herauszufinden, da sie unweigerlich am Ende des Projekts auftauchen und dann zu einer Änderung in letzter Minute führen (oder zu einer schlechten Qualität). Im Allgemeinen ist es sehr wahrscheinlich, dass die Anforderungen explizit und die Erwartungen implizit sind.

Konformität

Dies ist das Kernstück der Qualität: die Übereinstimmung des entstehenden Produkts mit den ursprünglich festgelegten Anforderungen und Erwartungen. Daher ist es wichtig, messbare Akzeptanzkriterien zu haben, anhand derer die Anwendung getestet werden kann. Ohne messbare Kriterien ist es äußerst schwierig, die Qualität zu bestimmen. Die Kriterien können konkrete Zahlen sein (z.B. 99% Verfügbarkeit) oder ja/nein (z.B. Login ist möglich). Wenn es nicht möglich ist, ein konkretes Kriterium zu definieren, ist es wichtig, die Anforderungen so detailliert wie möglich zu beschreiben und den Kunden so weit wie möglich einzubeziehen (z.B. die Anwendung muss auf neue Eingaben innerhalb von 0,5 Sekunden reagieren und die Änderungen werden innerhalb von 1 Sekunde auf dem Bildschirm des Benutzers angezeigt. Es wird davon ausgegangen, dass der Benutzer eine durchschnittliche Internetverbindung (16.000 Mbit/s) hat). Mit Beschreibungen wie diesen für die Akzeptanzkriterien ist es möglich zu beweisen, dass die Spezifikation erfüllt ist.

Qualität in der Softwareentwicklung

Was sind nun die Merkmale von Qualität? Ist es die Verfügbarkeit, die Anzahl der Bugs, der Preis oder die Leistung des Produkts? Auch nach der Prüfung der Definition von Qualität ist es immer noch ein Begriff, der sehr schwer zu bestimmen ist, da jeder ein etwas anderes Verständnis davon hat. Um die Qualität eines Produkts vergleichen zu können, sind messbare Anforderungen erforderlich. Ansonsten fehlt eine klare Grundlage für die Bestimmung der Qualität eines Produkts. Daher gibt es drei Dinge, die Sie beachten müssen:

  • Sprechen Sie so früh wie möglich mit den Beteiligten, um ihre Anforderungen und Erwartungen an das Produkt zu erfahren.
  • Schreiben Sie die Anforderungen auf.
  • Finden Sie messbare Akzeptanzkriterien für die Anforderungen.

Wenn Sie dies tun, können Sie jederzeit nachweisen, dass Ihr Produkt den Spezifikationen entspricht und die Qualität bestimmt werden kann. Auf dieser Grundlage werden wir im nächsten Beitrag einige Beispiele für Maßnahmen zur Verbesserung der Qualität in Softwareentwicklungsprojekten geben.