nach oben
Meine Merkliste
Ihre Merklisteneinträge speichern
Wenn Sie weitere Inhalte zu Ihrer Merkliste hinzufügen möchten, melden Sie sich bitte an. Wenn Sie noch kein Benutzerkonto haben, registrieren Sie sich bitte im Hanser Kundencenter.

» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.
Ihre Merklisten
Wenn Sie Ihre Merklisten bei Ihrem nächsten Besuch wieder verwenden möchten, melden Sie sich bitte an oder registrieren Sie sich im Hanser Kundencenter.
» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.

« Zurück

Ihre Vorteile im Überblick

  • Ein Login für alle Hanser Fachportale
  • Individuelle Startseite und damit schneller Zugriff auf bevorzugte Inhalte
  • Exklusiver Zugriff auf ausgewählte Inhalte
  • Persönliche Merklisten über alle Hanser Fachportale
  • Zentrale Verwaltung Ihrer persönlichen Daten und Newsletter-Abonnements

Jetzt registrieren
Merken Gemerkt
Software-Qualität - Software-Qualität

Qualität explizit beschreiben

Qualität, laut Duden definiert als „Beschaffenheit, Güte, Wert", bildet ein wichtiges Ziel für Software-Architekten. Bei Qualität handelt es sich allerdings um ein vielschichtiges Konzept, das mit einer Reihe gravierender Probleme behaftet ist:

  • Qualität ist nur indirekt messbar: Es gibt kein absolutes Maß für die Qualität eines Produktes, höchstens für einzelne Eigenschaften (etwa: Zeit- oder Ressourceneffizienz).
  • Qualität ist relativ: Verschiedene Stakeholder haben unterschiedliche Qualitätsbegriffe und -anforderungen:
    • Manager und Auftraggeber fordern Kosteneffizienz, Flexibilität und Wartbarkeit.
    • Endanwender fordern hohe Performance und einfache Benutzbarkeit.
    • Projektleiter fordern Parallelisierbarkeit der Implementierung und gute Testbarkeit.
    • Betreiber fordern Administrierbarkeit und Sicherheit.
  • Qualität der Architektur korreliert nicht notwendigerweise mit der Qualität des Endproduktes: Gute Architekturen können schlecht implementiert sein und dadurch die Qualität des Gesamtsystems mindern. Aus hervorragendem Quellcode kann jedoch nicht auf die Qualität der Architektur geschlossen werden. Insgesamt gilt daher: Architektur ist für Qualität eines Systems notwendig, aber nicht hinreichend.
  • Die Erfüllung sämtlicher funktionaler Anforderungen lässt keinerlei Aussage über die Erreichung der Qualitätsanforderungen zu: Betrachten Sie das Beispiel eines einfachen Sortierverfahrens: Die (triviale) Anforderung, eine Menge von Variablen gemäß eines vorgegebenen Sortierkriteriums aufsteigend zu ordnen, ist eine beliebte Programmieraufgabe für Einsteiger. Nun denken Sie an einige zusätzliche nichtfunktionale Anforderungen, etwa:
    • Sortierung großer Datenmengen (Terabyte), die nicht mehr zeitgleich im Hauptspeicher gehalten werden können.
    • Sortierung robust gegenüber unterschiedlichen Sortierkriterien (Umlaute, akzentuierte Zeichen, Phoneme, Ähnlichkeitsmaße und anderes).
    • Sortierung für viele parallele Benutzer.
    • Sortierung unterbrechbar für lang laufende Sortiervorgänge.
    • Erweiterbarkeit um weitere Algorithmen, beispielsweise für ressourcenintensive Vergleichsoperationen.
    • Entwickelbarkeit im räumlich verteilten Team.

Diese Qualitätsanforderungen können von naiven Implementierungen nicht erfüllt werden – dazu bedarf es grundlegender architektonischer Maßnahmen!

Viele Publikationen über Software-Architektur ignorieren das Thema der nichtfunktionalen Anforderungen völlig. Es scheint fast, als fielen Verständlichkeit, Wartbarkeit und Performance von Systemen als Nebenprodukte ab, wenn der eifrige Architekt nur in ausreichender Menge Design- und Architekturmuster anwendet. Das Gegenteil ist der Fall:

Qualitätsmerkmale müssen Entwurfsziele sein. Treffen Sie Entscheidungen zur Erreichung solcher Ziele bewusst und frühzeitig. Qualität entsteht nicht von selbst, sondern muss konstruiert werden!

Qualitätsmerkmale von Software-Systemen

Die Qualität von Software-Systemen wird immer bezogen auf einzelne Eigenschaften oder Merkmale. Beispiele für solche Merkmale sind Effizienz (Performance), Verfügbarkeit, Änderbarkeit und Verständlichkeit.

Es gibt eine ganze Reihe unterschiedlicher Definitionen von Qualitätsmodellen und Qualitätsmerkmalen. Die bekannten Qualitätsmodelle (siehe etwa [Wallmüller01]) definieren einige zentrale Qualitätseigenschaften (beispielsweise Zuverlässigkeit, Effizienz, Wartbarkeit, Portabilität etc.) und verfeinern diese Eigenschaften durch eine Hierarchie weiterer Merkmale.

Egal welches dieser Modelle Sie verwenden: Achten Sie darauf, innerhalb Ihrer Projekte, besser noch innerhalb ganzer Organisationen, eine einheitliche Terminologie einzuführen.

Die Tabelle zeigt Ihnen die Qualitätsmerkmale gemäß DIN/ISO 9126. Diese Norm enthält die wesentlichen Begriffe rund um Software-Qualität, zwei wichtige Qualitätsziele vieler Architekturen fehlen:

  • Verständlichkeit der Architektur selbst.
  • Testbarkeit der Architektur.

Falls Sie in dieser Tabelle (vergeblich) nach dem Stichwort "Performance" suchen – im DIN-normierten Sprachgebrauch heißt es Effizienz.

Tabelle 1. Qualitätsmerkmale nach DIN/ISO 9126

Tabelle 1. Qualitätsmerkmale nach DIN/ISO 9126

Szenarien konkretisieren Qualität

Jetzt kennen Sie zwar die wichtigsten Qualitätsmerkmale, benötigen aber noch ein Mittel, um diese Merkmale praxisgerecht für Ihre Projekte zu konkretisieren und definieren. Hierzu eignen sich Szenarien (nach [Bass+03]). Szenarien beschreiben, was beim Eintreffen eines Stimulus auf ein System in bestimmten Situationen geschieht. Sie charakterisieren damit das Zusammenspiel von Stakeholdern mit dem System. Szenarien operationalisieren Qualitätsmerkmale und machen sie messbar.

Typen von Szenarien

Es gibt einige unterschiedliche Typen von Szenarien:

  • Anwendungsszenarien beschreiben, wie das System zur Laufzeit auf einen bestimmten Auslöser reagieren soll. Hierunter fallen auch Szenarien zur Beschreibung von Effizienz oder Performance. Beispiel: Das System beantwortet eine Benutzeranfrage innerhalb einer Sekunde.
  • Änderungsszenarien beschreiben eine Modifikation des Systems oder seiner unmittelbarer Umgebung. Beispiel: Eine zusätzliche Funktionalität wird implementiert oder die Anforderung an ein Qualitätsmerkmal ändert sich.
  • Stress- oder Grenzszenarien beschreiben, wie das System auf Extremsituationen reagiert. Beispiele: Das System soll jetzt im Online- statt wie bisher im Batch-Betrieb laufen. Wie reagiert das System auf einen Stromausfall?

Beispiele für Szenarien

Ich möchte Ihnen die Anwendung von Szenarien zur Konkretisierung von Qualitätsanforderungen anhand einiger Beispiele verdeutlichen.

  • Anwendungsszenarien:
    • Die Antwort auf eine Angebotsanfrage muss Endbenutzern im Regelbetrieb in weniger als 5 Sekunden dargestellt werden. Im Betrieb unter Hochlast (Jahresendgeschäft) darf eine Antwort bis zu 15 Sekunden dauern, in diesem Fall ist vorher ein entsprechender Hinweis darzustellen.
    • Ein Benutzer ohne Vorkenntnisse muss bei der erstmaligen Verwendung des Systems innerhalb von 15 Minuten in der Lage sein, die gewünschte Funktionalität zu lokalisieren und zu verwenden.
    • Bei Eingabe illegaler oder fehlerhafter Daten in die Eingabefelder muss das System entsprechende spezifische Hinweistexte ausgeben und anschließend im Normalbetrieb weiterarbeiten.
  • Änderungsszenarien:
    • Die Programmierung neuer Versicherungstarife muss in weniger als 30 Personentagen möglich sein.
    • Die Unterstützung einer neuen Browser- oder Client-JDK-Version muss in weniger als 30 Personentagen programmiert und getestet werden können.
  • Stress- oder Grenzszenarien:
    • Bei Ausfall einer CPU muss das Ersatzsystem (Hot-Spare) im Normalbetrieb innerhalb von 15 Minuten online sein.
    • Die Anbindung eines neuen CRM1 -Systems muss innerhalb von 60 Tagen möglich sein.

Bestandteile von Szenarien

Nach diesen Beispielen können Sie sicherlich etwas Methodik vertragen: Szenarien bestehen aus folgenden wesentlichen Teilen (in Klammern die Terminologie aus [Bass+03]):

  • Auslöser (stimulus ): beschreibt eine spezifische Zusammenarbeit des (auslösenden) Stakeholders mit dem System. Beispiele: Ein Benutzer ruft eine Funktion auf, ein Entwickler programmiert eine Erweiterung, ein Administrator installiert oder konfiguriert das System.
  • Quelle des Auslösers (source ): beschreibt, woher der Auslöser kommt. Beispiele: intern oder extern, Benutzer, Betreiber, Angreifer, Manager.
  • Umgebung (environment ): beschreibt den Zustand des Systems zum Zeitpunkt des Auslösers. Befindet sich das System unter Normal- oder Höchstlast? Ist die Datenbank verfügbar oder nicht? Sind Benutzer online oder nicht? Hier sollten Sie alle Bedingungen beschreiben, die für das Verständnis des Szenarios wichtig sind.
  • Systembestandteil (artifact ): beschreibt, welcher Bestandteil des Systems vom Auslöser betroffen ist. Beispiele: Gesamtsystem, Datenbank, Webserver.
  • Antwort (response ): beschreibt wie das System durch seine Architektur auf den Auslöser reagiert. Wird die vom Benutzer aufgerufene Funktion ausgeführt? Wie lange benötigt der Entwickler zur Programmierung? Welche Systemteile sind von Installation/Konfiguration betroffen?
  • Antwortmetrik (response measure ): beschreibt, wie die Antwort gemessen oder bewertet werden kann. Beispiele: Ausfallzeit in Stunden, Korrektheit Ja/Nein, Änderungszeit in Personentagen, Reaktionszeit in Sekunden.
Bild 1. Schematische Darstellung von Szenarien (nach [Bass+03])

Bild 1. Schematische Darstellung von Szenarien (nach [Bass+03])

Szenarien und Qualitätsmerkmale

Ich möchte Ihnen nun etwas allgemeiner vorstellen, wie Sie Qualitätsmerkmale durch Szenarien beschreiben können. Dazu stelle ich zu ausgewählten Qualitätsmerkmalen mögliche Werte für die einzelnen Teile von Szenarien vor. Das Konzept dieser Darstellung stammt aus [Bass+03].
Bitte beachten Sie, dass es sich bei dieser Darstellung um allgemeine exemplarische Darstellungen handelt, die Sie für die Qualitätsanforderungen Ihrer Projekte spezifisch anpassen müssen. Einige Beispiele spezifischer Szenarien finden Sie im vorangehenden Abschnitt.
[...]

Tabelle 2. Allgemeine Szenarien für Zuverlässigkeit

Tabelle 2. Allgemeine Szenarien für Zuverlässigkeit

Tabelle 3. Allgemeine Szenarien zur Änderbarkeit

Tabelle 3. Allgemeine Szenarien zur Änderbarkeit

Tabelle 4. Allgemeine Szenarien zu Effizienz (landläufig: Performance)

Tabelle 4. Allgemeine Szenarien zu Effizienz (landläufig: Performance)

Hierzu gehören die üblicherweise als Mengengerüste bezeichneten Informationen: Wie viele Benutzer bearbeiten wann wie viele Daten in welcher Zeit? Welche Reaktionszeiten oder Durchsätze soll das System erbringen, welche Prozessor- oder Datenbanklast darf dabei entstehen?

Mengen- und Zeitangaben solcher Art bilden eine gute Grundlage für Effizienz- oder Performanceszenarien.

Tabelle 5. Allgemeine Szenarien zu Benutzbarkeit und Verständlichkeit

Tabelle 5. Allgemeine Szenarien zu Benutzbarkeit und Verständlichkeit

In den Szenarien bezüglich Benutzbarkeit und Verständlichkeit weiche ich von der DIN/ISO 9126 ab, weil insbesondere die Verständlichkeit der Software-Architektur für mich zu den wichtigen Architekturzielen und damit nichtfunktionalen Anforderungen gehört.

Eine leicht verständliche Architektur ohne (unliebsame) Überraschungen gehört zu den wesentlichen Voraussetzungen für Wartbarkeit und Änderbarkeit.

Verständlichkeit von Architekturen entziehen sich der sinnvollen Quantifizierbarkeit. Ich habe positive Erfahrung mit der Vergabe von Schulnoten gemacht: Lassen Sie die Leser und Reviewer von Architekturen die Verständlichkeit der Architektur und ihrer Dokumentation (kapitel-/dokumentenweise) bewerten. Zwar ist diese Metrik subjektiv, allerdings gibt sie Ihnen wertvolle Hinweise, wo und bei wem Sie die Verständlichkeit erreicht haben und wo nicht.

Tabelle 6. Allgemeine Szenarien zur Sicherheit

Tabelle 6. Allgemeine Szenarien zur Sicherheit

Hier kann ich bei weitem nicht alle Aspekte von Sicherheit in der IT abdecken. In [Möricke04] finden Sie weiterführende Hinweise.


Szenarien unterstützen bei Architekturbewertung

Sie können Szenarien auch nutzen, um Ihre Architekturen hinsichtlich spezifischer Qualitätsmerkmale zu bewerten. [...]

1 CRM: Customer-Relationship-Management, deutsch Verwaltung von Kundenbeziehungen) hat das Ziel, Kundenbeziehungen in einem Unternehmen zu organisieren und somit die Kundenzufriedenheit und -bindung, sowie die Profitabilität zu erhöhen (nach: [Wikipedia]).

zusätzliche Links

Weitere Informationen zum Thema Softwareentwicklung finden Sie auch im IT-Blog Hanser Update .

Gernot Starke, Effektive Softwarearchitekturen, 07/2015, 458 Seiten, € 44,99, ISBN: 978-3-446-44361-7

DIN EN ISO 9001:2015

Zum ISO 9001:2015 Special

Prozesswelt

Serie zum Thema Prozesse, veröffentlicht von QM-Experten deutscher Unternehmen gemeinsam mit der N5 GmbH und der Fachzeitschrift QZ

Zur Prozesswelt