Architecting for Quality: Qualität methodisch herbeiführen (1/4)

„Wir können auch ohne Qualität“. Aus voller Überzeugung. Schon mal gelesen? Nein? Ich auch nicht. Auch wenn es manchmal ehrlicher wäre. Stattdessen: „Nur die beste Qualität“. „Das Jahr der Qualität“. „Qualität ist unser Markenzeichen“.

„We are quality“

Qualität ist ein Muss – das zeigen die unzähligen Initiativen und Werbeslogans der Firmen, die schon aus Prinzip nicht schlechter dastehen können als die Konkurrenz (zumindest dem Anschein nach). Und das sind so ziemlich alle. Die Softwareentwicklung macht da selbstverständlich keine Ausnahme. Doch was Softwarequalität nun wirklich genau heißt, wie man sie misst und wie man sie erreicht – da wird es meist dann schon ziemlich dünn. Und manchmal ist eine ernsthafte Auseinandersetzung mit dem Thema auch gar nicht erwünscht.

Architecting for Quality: Qualität methodisch herbeiführen

Architecting for Quality – das bedeutet Qualität explizit zu machen und als treibenden Faktor der Architekturarbeit zu begreifen.

Diese vierteilige Blogserie soll zeigen, wie Qualität – begonnen bei der Anforderungsanalyse, über den Entwurf bis hin zu Implementierung und Test – methodisch herbeigeführt werden kann. Zwar sind nicht alle diese Disziplinen in der Verantwortung der Architekt*innen, dennoch sollte Architektur und damit auch das Thema Qualität in allen Entwicklungsphasen mit bedacht werden.

In diesem ersten Teil der Serie widmen wir uns dem Qualitätsbegriff. Wir schauen uns an, was „Qualität“ bedeuten kann und welchen besonderen Blick die Architekturdisziplin darauf hat.

Der Qualitätsbegriff

Subjektiv bzw. eine Frage des Standpunktes?

Was ist nun „Qualität“? Gute Wartbarkeit? Eine hübsche UI? Oder doch lieber Performance?

Die Entwicklungsabteilung hat häufig eine ganz andere Vorstellung von Qualität als ein Produktmanager oder eine Usability Expertin. Dabei sind all diese Aspekte mögliche Qualitäten, wie sie beispielsweise die ISO 25010 beschreibt.

Die Frage ist nur, welche Qualitätsattribute für ein spezielles Softwaresystem wirklich relevant sind und wie wir sie methodisch herbeiführen können – so dass der Satz „unser System hat eine hohe Qualität“ keine Floskel bleibt sondern eine belegbare Aussage wird.

Halten wir also fest: Es ist logisch, dass Qualität nicht einfach eine Frage des Standpunktes sein kann. Denn die Konsequenz daraus wäre (unter der Annahme, dass wir Planlosigkeit, Willkür und Anarchie beim Systementwurf vermeiden wollen):

• Dass es entweder einen Standpunkt geben muss, der sich aufgrund politischer Macht durchsetzt und damit die Zielrichtung vorgibt.
• Oder dass das System eben alle Qualitäten erfüllen muss: Die berühmte eierlegende Wollmilchsau.

Auch wenn die erste Variante in der Praxis häufig vorkommt und die andere regelmäßig durchs Dorf getrieben wird – das kann nicht richtig sein.

 

Objektiv und maßgeschneidert!

Im Umkehrschluss heißt das: Ein System kann nicht gleichzeitig alle denkbaren Qualitätsattribute erfüllen. Wir müssen uns also auf die relevanten konzentrieren. Und das sind nicht notwendigerweise die, die sich alleine aufgrund des politischen Einflusses (beispielsweise der Unternehmensleitung) durchsetzen.

Jedes gut entworfene System ist maßgeschneidert. Das heißt nicht, dass für schon gelöste Probleme das Rad neu erfunden werden soll, ganz im Gegenteil. Aber jedes Produkt ist individuell: Es verfolgt individuelle Geschäftsziele und muss sich gegenüber Konkurrenzprodukten etablieren. Eine 0815-Lösung, die auf alles passen soll, wird nur auf die wenigsten Systeme perfekt passen.

Welche Qualitätsattribute sind nun für ein spezielles Softwaresystem wirklich relevant? Es ist die Aufgabe der Architekt*innen, auf diese Frage (durch methodisches Vorgehen!) eine objektive Antwort zu finden.

 

Qualität durch die Architektenbrille

Eine Softwarearchitektur wird durch verschiedene Einflüsse getrieben. Die folgende Abbildung zeigt eine mögliche Kategorisierung dieser Einflüsse:

 

 

In der Praxis liegt das Hauptaugenmerk vieler Beteiligter häufig auf den funktionalen Anforderungen (grüne Säule). Allerdings sind es die Qualitätsanforderungen (rot) und die Randbedingungen (gelb und blau), die die Architektur letztendlich häufig am stärksten prägen.

Es ist daher mehr als sinnvoll, Qualität explizit zu machen und als treibenden Faktor der Architekturarbeit in den Fokus zu rücken.

 

Mehr Informationen zum Thema Software Engineering findest du hier in unserem Kompetenzfeld.