Stellen Sie sich vor, Sie bauen ein Haus. Sie erwerben ein Grundstück, engagieren Arbeiter, heben Fundamente aus, verfüllen diese und mauern dann fröhlich drauf los. Zunächst die Außenmauern und anschließen - so wie es Ihnen und Ihrem Partner gerade einfällt - entsprechende Zwischenwände. Danach ziehen Sie eine Decke ein und bauen darauf das nächste Stockwerk. Wie viele Stockwerke das Ganze mal tragen muss? Welche Wände welche Last tragen müssen? Wohin welche Leitungen gelegt werden müssen? Das interessiert Sie erst einmal nicht. Im Vordergrund steht nur eins: der Wunsch nach mehr Wohnraum. Irgendwann bricht ein tragendes Element und das Haus stürzt ein, die investierten Ressourcen sind futsch und das Entsetzen ist groß.

"Das macht doch niemand" - werden Sie sich jetzt vielleicht denken und: Sie haben Recht. Aber erstaunlicherweise, laufen heutzutage sehr viele Softwareprojekte, auf genau diese Art und Weise. Hier finden natürlich nicht Kelle, Hammer und Mörtel Verwendung sondern Entwicklungsumgebungen, Frameworks und Programmiersprachen.

Auch wenn das Haus Ihren Ansprüchen entsprach, also die gewünschte Funktionalität nach Wohnraum umgesetzt wurde, war die Gesamtqualität des Produktes schlecht. Auch wenn der Vergleich, mit der Entwicklung von Software, etwas weit hergeholt zu seien scheint, ist auch hier das Problem auf eine Ursache zurückzuführen: mangelhafte Produktqualität. Um das Problem genauer zu untersuchen, muss zunächst der Begriff "Softwarequalität" etwas präziser formuliert werden.

Was ist Softwarequalität?

Unter Softwarequalität wird eine Sammlung von verschiedenen Merkmalen bzw. Aspekten verstanden, die zusammengefasst eine Aussage darüber erlauben, welche Qualität ein entwickeltes Softwareprodukt besitzt. Die Gruppierung solcher Merkmale, welche die Bewertung ermöglichen, werden auch Qualitätsmodelle genannt. Hier sei als Beispiel das ISO-9126 Modell genannt. In diesem Modell werden die verschiedenen Aspekte in die Gruppen

• Funktionalität

• Zuverlässigkeit

• Benutzbarkeit

• Effizienz

• Änderbarkeit

• Übertragbarkeit

unterteilt. Um nun einen einzelnen Aspekt bewerten zu können, muss eine geeignete Metrik gefunden werden, welche diesen Aspekt durch einen bewertbaren Zahlenwert ausdrückt.

Im Folgenden sei exemplarisch, der Aspekt Analysierbarkeit der Gruppe Änderbarkeit betrachtet. Dieser bewertet, wie gut ein Softwareprodukt durch einen Entwickler erlernt bzw. verstanden werden kann. Eine mögliche Metrik, um diesen Aspekt zu bemessen, wäre die Aussage, ob eine projektweite Codierrichtlinie von allen Entwicklern eingehalten wird. Ist diese Metrik erfüllt, wird von jedem Entwickler auf die gleiche Art und Weise Code geschrieben, somit ist Fremdcode einfacher zu erlernen. Wie in diesem Beispiel muss zu jedem zu berücksichtigenden Aspekt eine Metrik oder mehrere Metriken gefunden werden und diese durch entsprechende Maßnahmen gestärkt werden.

Alle Qualitätsaspekte im Blick behalten

Kehren wir zurück zu dem einleitenden Bauprojekt: Hier wurden lediglich einzelne Aspekte der Gruppe "Funktionalität" berücksichtigt, welche höchstens ein Sechstel der Gesamtqualität des Produktes ausmachen. Wie sieht es bei Softwareprojekte aus? Auch diese sind meist fast ausschließlich funktional getrieben. Zu Beginn ist das auch sehr erfolgreich, die benötigten Features werden schnell und kontinuierlich geliefert und alle, besonders natürlich die Kunden, sind sehr zufrieden mit dem Projekt. Aber nach einigen Releases wird dieser Strom immer langsamer und langsamer und die Zeiten zum Umsetzen der Features, werden immer länger und länger.

Zusätzlich erschweren vermehrt auftretende Fehler die Entwicklung. Irgendwann dann ist diese Zeitspanne so groß, dass die zur Verfügung stehenden Ressourcen, nicht mehr ausreichen. Meilensteine können nicht mehr eingehalten werden. Das Projekt droht zu scheitern.

Alle dem Autor im Beratungsalltag begegneten gescheiterte Projekte waren immer auf eine mangelhaft Erfüllung der Aspekte zurückzuführen. Das Prinzip ist also relativ einfach, alle Aspekte müssen mit Maßnahmen adressiert und durch entsprechende Metriken überwacht werden. Um eine geeignete Strategie dazu abzuleiten, werden die Aspektgruppen in verschiedene Kategorien unterteilt.

Unterteilung nach funktionalen und nicht-funktionalen Anforderungen

Zunächst die offensichtlichste: Während die Gruppe Funktionalität die funktionalen Aspekte behandelt, also WAS wird gemacht, behandeln die restlichen fünf (Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit) alle qualitative Aspekte, also WIE wird etwas gemacht. Diese Unterteilung entspricht den funktionalen und nicht-funktionalen Anforderungen.

Es seien nun die qualitativen Aspekte genauer betrachtet. Diese werden weiter unterteilt, in Aspekte die aus Anforderungen abgeleitet werden (Zuverlässigkeit, Benutzbarkeit, Effizienz), also durch den Kunden bestimmt sind und Aspekte, welche die innere Beschaffenheit der Software adressieren (Änderbarkeit und Übertragbarkeit), also durch die Entwicklungsabteilung bestimmt werden (siehe Abbildung 2). Während die Anforderungen durch den Kunden von Projekt zu Projekt variieren, sollten Ihre eigenen Ansprüche an ihre Softwareprojekte, immer gleich hoch sein.

Aber hier geht es doch um Architektur? Genau! Wird eine geeignete Standardarchitektur für Projekte in Ihrem Unternehmen etabliert, können alle qualitativen Aspekte, bezogen auf die innere Beschaffenheit des Produktes, automatisch bei allen Projekten adressiert werden. Das heißt, alle Projekte sind analysierbar, modifizierbar, stabil, prüfbar, anpassbar und austauschbar. Natürlich sind das nicht alle Aspekte, die es zu berücksichtigen gilt, jedoch die am schwersten erfüllbaren. Deshalb können Ihre Entwickler und Projektverantwortliche ihren Fokus auf die Kernaufgabe legen, die Erfüllung der gewünschten funktionalen und nicht-funktionalen Anforderungen des Kunden.