Softwarequalität im Kontext von Wertschöpfung und Evolution

Markus Harrer

This blog post is also available in English

TLDR;

Die Wichtigkeit von Qualitäten kann sich mit der Evolution eines Softwaresystems ändern. Es wird zudem schwieriger, Nutzer:innen und Produktverantwortliche den Wert von später wichtiger werdende Qualitäten zu motivieren. In diesem Blog-Post erläutere ich meine Sicht darauf. Nach dem Lesen wirst du diese Visualisierung verstehen können:

Einleitung

Vor ein paar Jahren durfte ich mit einem Kollegen einem Unternehmen helfen, ihre Performance-Probleme für eine Smartphone-App (inkl. Backend) in den Griff zu bekommen. Wir klärten mit den Verantwortlichen vorher ab, was das System so macht, wie der derzeitige Technologie-Stack aussieht und wo der Schuh drückt. Mein Kollege und ich bereiteten uns darauf mit ein paar Fragen vor, um dem System später besser auf den Zahn fühlen zu können. Vor Ort bei der Firma begannen wir wie üblich mit einem kleinen Kick-Off. Eines der Ziele in diesen Kick-Offs ist es, herauszufinden, ob das Team oder die Teams wissen, wie das Geschäftsmodell tickt, für das sie das System entwickeln. Daher stelle ich gerne immer die Frage: „Wie verdient ihr Geld mit dem System?“. Nur dieses Mal kam die Antwort etwas überraschend für mich. Sie war: „gar nicht“. Das brachte mich in dem Meeting etwas aus dem Konzept. Im späteren Verlauf unserer Hilfeleistung behielten wir auch viele der von uns vorbereitete Fragen zur Produktionsreife (wie zu Skalierbarkeitseigenschaften, Monitoring oder Fehlerkompensation) zurück. Nach den ersten Workshops mit dem Entwicklungsteam sahen wir, dass solche Punkte noch nicht auf der Agenda des Teams waren. Es gab noch völlig andere Problembereiche, die letztendlich den Benutzenden des Systems (und damit dem Unternehmen) mehr interessierten wie zu langsame Abfragen, Benutzbarkeitsprobleme oder fehlerbehaftete Funktionen. Welchen fundamentalen Aspekt hatte ich hier übersehen?

Szenenwechsel: Vor ein paar Jahren gründete ich zusammen mit ein paar ehemaligen Kommilitonen aus meinem Informatikstudium ein kleines Start-Up. Wir entwickelten in unserer Freizeit eine Webapplikation zur Organisation und Durchführung von Kneipentouren. Wir hatten sehr hohe Ansprüche an die Entwicklung der Software. Eines unserer wichtigsten Ziele war es zu beweisen, dass ein Start-Up, welches von Anfang an auf die Clean-Code-Prinzipien setzt, auch erfolgreich sein konnte. Daher zogen wir unsere Anwendungsarchitektur nach der Onion Architecture auf. Wir konnten damit mühelos verschiedene Frontend-Technologien auf unsere Geschäftslogik setzen (was wir auch zweimal machten) und den Persistenzmechanismus ändern (den wir viermal änderten, weil es so einfach ging). Außerdem achteten wir von Stunde null an auf eine extreme Skalierbarkeit unseres Softwaresystems durch die Nutzung diverser Cloud-Dienste. Wir fantasierten auch über ein Ökosystem von Plugins, um unsere modular aufgebaute Software auch für Drittanbieter als Plattform attraktiv zu machen. Letztendlich waren das aber die völlig falschen Ziele für unsere Software. Unsere Webapplikation hatte nie die Features angeboten, die wir für einen Live-Gang benötigt hätten. Das was wir hatten, war auch schrecklich zu bedienen. Wir gaben unsere Idee auf (spätestens jetzt, während der Corona-Pandemie, wären wir sowieso pleite gewesen mit einer App, die Kneipentouren organisiert).

Jahrelang konnte ich diese Situationen nicht wirklich einordnen. Heute sind mir diese Szenen viel klarer: Natürlich hatten wir in beiden Fällen auf die falschen Qualitätsziele geachtet. Aber wir wussten auch, dass die von uns ins Auge gefassten Qualitätsziele irgendwann wichtig werden, um die Softwaresysteme auch in Zukunft attraktiv für Kund:innen und Nutzer:innen zu gestalten. Warum war es dann nicht schlau, alle irgendwann notwendigen Qualitäten so früh wie möglich anzugehen? Ein wichtiges Modell, das mir hier mehr Einblick gegeben hat, wann welche Qualitäten denn wie wichtig werden, sind Wardley Maps. Mit Hilfe von Wardley Maps können wir viele neue Blickwinkel auf die Entwicklung von Softwaresystemen schaffen. In diesem Blog-Post verwenden wir Wardley Maps als Kommunikationsmittel, um Qualitäten besser einzuordnen. Ein Vorwissen über Wardley Maps ist nicht notwendig. Ich führe Wardley Maps im Folgenden Schritt für Schritt im Kontext von Qualitätsmerkmalen ein.

Qualität im Kontext

Um fundierter über Qualität im Softwarekontext zu reden, verwende ich ein weiteres Modell, welches uns einen gemeinsamen Wortschatz liefert, um besser über Qualität reden zu können: Die ISO-Norm ISO/IEC 25010:2011.

Wir fokussieren uns auch nur auf die Hauptqualitätsmerkmale der Norm inkl. einer schlanken Beschreibung meinerseits:

• Funktionale Eignung: Das System bietet Funktionen, die den angegebenen und impliziten Bedürfnissen entsprechen.
• Leistungseffizienz: Das System liefert eine angemessene Geschwindigkeit mit den bereitgestellten Ressourcen.
• Kompatibilität: Das System kann Informationen mit anderen austauschen
• Benutzbarkeit: Das System kann von bestimmten Nutzern verwendet werden können, um bestimmte Ziele effizient zu erreichen.
• Zuverlässigkeit: Das System führt bestimmte Funktionen unter gegebenen Bedingungen aus
• Sicherheit: Das System schützt Informationen und Daten.
• Wartbarkeit: Das System kann modifiziert werden, um es zu verbessern, zu korrigieren oder an Änderungen anzupassen.
• Übertragbarkeit: Das System kann auf verschiedenen Umgebungen betrieben werden Wir müssen auch klären, was wir überhaupt unter Qualität im Kontext von Softwaresystemen verstehen.

Eine inhaltlich treffende, aber für meine Begriffe etwas zu kompliziert ausgedrückte Definition findet sich bei Helmut Balzerts „Lehrbuch der Softwaretechnik“:

Unter Softwarequalität versteht man die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen.

Für mich ist Qualität in einer Software immer dann erreicht, wenn das, was an Qualität gefordert wird, auch im Softwaresystem erreicht ist. Im ersten Beispiel gab es einen Qualitätsmangel: Es wurde eine gute Performance gefordert, aber das System konnte diese Anforderungen nicht erfüllen. Daher mussten wir passende Maßnahmen finden, um das System performanter zu gestalten. Im zweiten Beispiel waren Qualitäten übererfüllt, da sie noch nicht relevant waren für die aktuelle Situation. Andere Qualitäten, die von potenziellen Nutzern und Kunden erwartet waren, wurden aber ignoriert. Beide Arten waren Qualitätsmängel, da das erwartete Soll an den notwendigen Stellen nicht erfüllt wurde und beim Ist zu viel gemacht wurde, was (noch) nicht gefordert wurde.

Qualität wertschöpfend einordnen

Mit einer Wardley Map können wir beide Situationen (inperformante Smartphone-App und die Kneipentour-Software) veranschaulichen: In ihrer einfachsten Form besteht eine Wardley Map aus zwei Dimensionen: Eine Dimension zeigt die Sichtbarkeit von Komponenten (Systeme, Fähigkeiten, Wissen usw.) in einer Wertschöpfungskette von einem gewissen Standpunkt aus (wie z. B. von einem Kunden oder einer Benutzerin eines Softwaresystems). Dadurch können wir z. B. sehen, wie nah und dadurch sichtbar bestimmte Teile einer Smartphone-App für eine Nutzerin sind, die eine wertschöpfende Tätigkeit wie etwa „neue Grafikkarte bestellen“ über einen Online-Shop ausführen möchte. Wir können alle Komponenten etwa in einer Liste aufführen, um festzuhalten, was wir dazu brauchen, um diese Tätigkeit zu realisieren. „Brauchen“ ist hier auch ein wichtiges Stichwort, denn die Elemente in der folgenden Liste stehen in einer „braucht“-Beziehung zueinander, um die Bedürfnisse der Nutzerin letztendlich zu erfüllen:

Die Liste wird gelesen: „Eine Nutzerin braucht eine neue Grafikkarte und braucht dazu die Shopping-App, welche App-Services braucht, welche REST-Services brauchen“ und so weiter. Komponenten, die ganz oben in der Liste stehen, sind sichtbarer für die Nutzerin. Das App-Frontend verwendet die Nutzerin direkt selbst. Komponenten weiter unten sind ziemlich sicher unsichtbar für die Nutzerin, was dazu führt, dass sie sich nicht darum kümmern muss (und will). Aber weiter unten befindliche Komponenten sind trotzdem relevant, um die wertschöpfende Tätigkeit zu realisieren.

Wir möchten jedoch nun nicht einzelne Komponenten mappen, sondern die einzelnen Qualitäten. Wir können auch hier eine ähnliche Liste erstellen. Allerdings können wir nicht direkt eine Wertschöpfungskette abbilden, da Qualitäten etwas weniger Konkretes sind. Aber wir können die Wichtigkeit bestimmter Qualitäten wieder von einem bestimmten Standpunkt aus gesehen auflisten. Nehmen wir das Beispiel „Nutzerin will Grafikkarte kaufen“ wieder als Ausgangspunkt für unsere Liste. Dieses Mal listen wir aber die von der Nutzerin erwarteten Qualitäten nach ihrer Wichtigkeit auf:

Um diese Liste verständlicher zu machen, füge ich hinter jeder Qualität eine kleine Erklärung hinzu, die klarer macht, weshalb ich diese Qualität hier einordne.

1. Funktionale Eignung: Wenn die Shopping-App keine Bestellungen von Grafikkarten korrekt ausführen kann, dann verliere ich die Nutzerin als Kundin des Shops.
2. Benutzbarkeit: Die Nutzerin will sich zurechtfinden und nicht frustriert werden durch eine komplizierte Benutzerführung.
3. Zuverlässigkeit: Die App soll nutzbar sein, wenn die Nutzerin etwas bestellen möchte.
4. Leistungseffizienz: Die Nutzerin möchte nicht ewig warten müssen auf die Rückmeldung der Smartphone-App.
5. Sicherheit: Die Nutzerin will ihre hinterlegten persönlichen Daten geschützt wissen.
6. Wartbarkeit: Die Nutzerin erwartet auch ab und an neue Features, die das Verkaufserlebnis noch besser machen.
7. Übertragbarkeit: Die Nutzerin möchte auf verschiedenen Endgeräten die gleiche App verwenden können.
8. Kompatibilität: Die Nutzerin möchte das Zahlungsmittel verwenden können, das ihm am besten passt.

Diese Liste beansprucht keinen Anspruch auf 100%ige Korrektheit. Einige Qualitäten lassen sich hier zwar sehr eingängig aus der Sicht eines Benutzers oder Benutzerin auflisten. Diese Qualitäten bezeichne ich als „externe Softwarequalitäten“, da sie direkt für Außenstehende sichtbar sind. Aber für die Qualitäten, die sich weiter weg von Nutzer:innen befinden, ist eine exakte Reihenfolge schwieriger festzulegen. Ich spreche hier von „inneren Softwarequalitäten“, da sich diese tendenziell unter der Haube der Software wiederfinden. Ich habe trotzdem versucht, die obige Reihenfolge nachvollziehbar zu verargumentieren. In anderen Kontexten sind hier aber auch sicherlich Abweichungen möglich.

Dennoch hilft uns diese Liste bereits, um eines unserer vorher genannten Beispiele besser einordnen zu können. Die Webanwendung zur Organisation und Durchführung von Kneipentouren setzte völlig auf andere Prioritäten als diejenigen, die etwa einem Nutzer wichtig gewesen wären:

1. Wartbarkeit
2. Leistungseffizienz
3. Übertragbarkeit

Dadurch ist es auch gut nachvollziehbar, weshalb diese Anwendung kein durchschlagender Erfolg gewesen ist: Sie ging völlig an den Qualitätsbedürfnissen potenzieller Endnutzer:innen vorbei.

Dazu passt ein Zitat von Peter Drucker:

„Es gibt nichts Sinnloseres, als etwas effizient zu tun, was gar nicht getan werden müsste.“

Das erste Beispiel (System mit den Performance-Problemen) hingegen hatte die sinnvollere Reihenfolge: Die Basisfunktionen der Anwendung waren bereits vorhanden und das Team hatte eine Usability-Expertin an Board. Bessere Skalierbarkeit („Kapazität“ nach ISO 25010 und damit ein Untermerkmal von „Leistungseffizienz“) stand nun als Nächstes auf der Agenda.

Spätestens jetzt sollte die Vermutung aufgekommen sein, dass das Modell hier vielleicht zu vereinfachend ist. Es könnte der Eindruck entstanden sein, dass immer die gleichen Qualitätsziele pauschal für alle Softwaresysteme erreicht werden müssen. Dabei wissen wir doch, dass Qualitätsziele stark abhängig vom Kontext (Geschäftsmodelle, Randbedingungen, Fähigkeiten usw.) sind und daher fast jedes Softwaresystem eine unterschiedliche Auswahl von Qualitäten zu erreichen hat. Und nicht jedes Softwaresystem hat den Luxus als Ziel, eine 100% korrekt funktionierende Anwendung zu bauen, die sich auch noch extrem gut zu bedienen ist. Das ist alles richtig. Wir betrachten aber Qualität von einem ganz speziellen Blickwinkel aus: Von den Nutzer:innen der Software. Zudem haben wir offengelassen, wie weit wir die Regler für eine bestimmte Qualität aufdrehen. Auch mit einem minimalen Set von Funktionalität und nicht allzu verwirrender Benutzerführung könnten wir die Bedürfnisse der Softwarenutzenden bereits erfüllen.

Ich möchte aber mit der Dimension „Wertschöpfungskette“ noch auf einen ganz anderen Punkt hinaus: Betrachten wir dazu die Liste der sichtbaren Qualitäten aus der Nutzer:innenperspektive. Damit können wir besser nachvollziehen, weshalb wir in der Softwareentwicklung gut dastehen, und ein lockeres Leben haben, wenn wir genau auf diese Qualitäten achtende Erweiterungen ausliefern. Die Dimension der Wertschöpfung zeigt uns auch, weshalb Softwareentwickelnde bei den unteren Qualitäten manchmal Nutzer:innen (oder dessen Stellvertreterinnen und Stellvertretern wie Product Owner) noch erst überzeugen müssen, dass Arbeiten in diesen Bereichen notwendig sind. Sie sind von diesen Standpunkten aus gesehen zu weit entfernt, nicht sichtbar und schwer greifbar für Endnutzer-nahe Rollen. Daher ist etwas Fingerspitzengefühl gefragt, um im richtigen Moment die richtigen Fragen für die Weiterentwicklung des Softwaresystems zu stellen. Ein anderer wesentlicher Punkt ist, dass wir auch andere Standpunkte im Blick haben müssen. Softwareentwickelnde werden mit einer ganz anderen Reihenfolge von Qualitäten konfrontiert (siehe Webapplikation für Kneipentouren). Auch das Operations-Team hat wiederum andere Qualitätsansprüche. Zu wissen, dass es diese Unterschiede zwischen den erwarteten und sichtbaren Qualitäten gibt, hilft uns hier auch, evtl. auftretende Konflikte transparenter und kommunizierbar zu machen.

Qualität und Evolution

Unser Mapping der Qualitäten ist jedoch noch nicht zu Ende. Mit Wardley Maps haben wir eine noch eine zweite Dimension zur Verfügung, mit Hilfe derer wir uns Qualitäten im Kontext der Softwareevolution näher ansehen können. Dazu müssen wir einen kleinen Ausflug in diesen „Mechanismus“ unternehmen. Komponenten im Kontext von Wardley Maps können sich weiterentwickeln. Wie stark und wie weit sie das tun, hängt im Wesentlichen von zwei Faktoren ab: Dem Nachfragewettbewerb (also wie stark etwas gefragt ist) und dem Angebotswettbewerb (wie gut etwas bereitgestellt werden kann). Eine Wardley Map bildet diese Aspekte mit vier Evolutionsphasen auf einer Dimension ab. Für das Mapping von Qualitäten reicht uns hier ein rudimentäres Verständnis dieser Phasen, die ich im Folgenden grob charakterisiere:

1. Entstehung: Es ist völlig unklar, wie man die Komponente herstellt oder ob sie überhaupt jemand braucht.
2. Einzelanfertigung: Herstellungsprozesse sind noch sehr wackelig und wenig wiederholbar, es gibt aber schon einen ersten Bedarf.
3. Produkt: Das Hergestellte wird mit beherrschbaren Prozessen zuverlässig erzeugt und der Markt nimmt es in großer Stückzahl ab.
4. Gebrauchsgut: Der sichere Massenmarkt bezieht das Angebotene quasi direkt aus der Steckdose.

In Wardley Maps durchwandern Komponenten diese verschiedenen Phasen, wenn ein entsprechender Angebots- bzw. Nachfragewettbewerb vorhanden ist. Ein kleines Beispiel, wie sich die Evolution von Rechenkapazität dadurch veranschaulichen lässt:

1. Entstehung: Es ist überhaupt nicht klar, ob überhaupt automatisiert gerechnet werden kann und wer automatisierte Berechnungen gebrauchen könnte. Dennoch gibt es erste Ideen und Prototypen von Rechenmaschinen bis hin zum ersten Digitalrechner (z. B. Zuse Z3).
2. Einzelanfertigung: Automatisierte Berechnungen haben sich als ganz nützlich dargestellt. Es entstehen erste Digitalrechner für kommerzielle Einsatzbereiche wie etwa Lohnabrechnung. Diese werden nur auf speziellen Kundenwunsch angefertigt, da die noch schwer herzustellen und wenig nachgefragt werden (z. B. LEO I).
3. Produkt: Es gibt erste Computer, die die kundenindividuellen Rechenabläufe (= Software) von den ausführenden Recheneinheiten (= Hardware) trennen. Somit kann der hohen Nachfrage an Rechenkapazität entgegengekommen werden und Rechnerhardware kann in großen Stückzahlen hergestellt werden (z. B. IBM System/360).
4. Gebrauchsgut: Rechenkapazität ist nun selbstverständlich verfügbar und der Bedarf ist in fast jedem Anwendungsbereich vorhanden. Es gibt nun die Möglichkeit, Rechenkapazität ohne großen Aufwand direkt in bester Qualität jederzeit sofort zu beziehen (z. B. AWS Lambda).

Anhand dieses und der anderen Beispiele lässt sich erahnen, wo unsere Reise mit der Evolutionsachse hingeht. Auch hier können wir die Qualitäten entsprechend ihrer Relevanz nacheinander auflisten. Dieses Mal jedoch im Kontext der Evolution. Hier benötigen wir jedoch keinen speziellen Standpunkt, sondern können rein an den Charakteristika der Evolutionsphasen die Qualitäten in etwa zuordnen, welche hier wohl am höchsten je Phase relevant sind, um Komponenten weiterzuevolvieren:

1. Entstehung
   • Funktionale Eignung: Ohne Funktion gibt es keinen Nutzen für niemanden.
   • Benutzbarkeit: Ohne Zugänglichkeit für Nutzer*innen gibt es kein Wert.
2. Einzelanfertigung
   • Zuverlässigkeit: Ohne ein verfügbares System bekomme ich keine gesteigerte Nachfrage nach meinen Angeboten.
   • Leistungseffizienz: Ohne schnelle Reaktion und Skalierung erfolgt kein Ausbau der Nutzerbasis.
3. Produkt
   • Sicherheit: Ohne Schutz von Daten keine Akzeptanz durch die Mehrheit der Nutzer:innen.
   • Wartbarkeit: Ohne kontinuierliche Weiterentwicklung erfolgt keine Befriedigung der gestiegenen Ansprüche.
4. Gebrauchsgut
   • Übertragbarkeit: Ohne Abdeckung von verschiedenen Betriebsplattformen keine Unabhängigkeit.
   • Kompatibilität: Ohne einer guten Zugänglichkeit zu den Leistungsangeboten über Schnittstellen und Standards erfolgt keine Massennachfrage.

Auch diese Abfolge ist teils subjektiv und aus Erfahrungen gewonnen, aber es hilft uns ebenfalls, einige neue Erkenntnisse zu gewinnen. Insbesondere müssen wir als Softwareentwickelnde wissen, in welcher der Phasen wir gerade unterwegs sind. Es ergibt, in den allermeisten Fällen, überhaupt keinen Sinn, über Wartbarkeit zu reden, wenn wir erst in einer explorativen Phase wie der Entstehung unterwegs sind. Hier müssen wir zuerst einmal ein passendes Geschäftsmodell finden und in Software gießen, welche potenzielle Nutzer anzieht. Womöglich ist auch die Fachlichkeit, die wir umsetzen, noch derart stark im Fluss und Neuland für uns, dass z. B. eine Maßnahme für mehr Wartbarkeit wie eine fachlich getriebene Modularisierung hier noch viel zu früh angesetzt ist. Die Wahrscheinlichkeit ist hier viel zu hoch, dass wir falsch liegen und dann Dank der Sunk Cost Fallacy unnötig an einer falsch modularisierten Struktur festhalten und uns damit noch mehr blockieren in der täglichen Arbeit. Die Dimension der Evolution hilft daher, unnötige Arbeiten und verfrühte Entscheidungen zu erkennen. Wir sehen aber auch, dass wir immer wieder neue Qualitäten bei der Evolution unseres Softwaresystems adressieren müssen.

Besonders wenn wir in eine andere Phase übergehen, kann es durchaus sein, dass sich die Sichtweisen auf die Qualitäten fundamental ändern. Plötzlich wird Dokumentation als Maßnahme für mehr Wartbarkeit immer wichtiger für den Erfolg unserer Software, wenn wir uns aus der Phase von Einzelanfertigung nach Produkt bewegen. Irgendwann wird API-Design notwendig werden, um Kompatibilitätsaspekte bei einer von uns bereitgestellten Plattform zu erfüllen, wenn unsere Software zum Gebrauchsgut werden soll. Die grobe Einordnung der Qualitäten entlang der Evolutionsachse bereitet uns auf die, hier immer wieder neu hinzukommenden, Herausforderungen frühzeitig vor. Diese versetzt uns in die Lage, vorherzusehen, welche Arbeiten bald noch zusätzlich auf uns zukommen, wenn wir ein Softwaresystem stark evolvieren möchten. Die Zuordnung von Qualitäten auf die Evolution hilft uns auch, wenn wir nicht von Null an ein neues Softwaresystem schrittweise evolvieren. Oft wissen wir bereits, dass es einen Markt für unser System gibt (Nachfragewettbewerb). Wir kennen auch die Rahmenbedingungen, die erfüllt sein müssen, damit unser System erfolgreich ist und sich gegenüber evtl. Konkurrenten durchgesetzt (Angebotswettbewerb). Dadurch wissen wir, dass wir in eine fortgeschrittenere Evolution einsteigen müssen und eine Reihe voller notwendigen Qualitäten in unserem Softwaresystem von Anfang an beachten müssen. Ansonsten sind wir chancenlos gegenüber unseren Konkurrenten oder erfüllen nicht die Bedürfnisse unserer Kund:innen und letztendlich Nutzer:innen.

Qualität bei Wertschöpfung und Evolution

Zum Schluss können wir auch noch einen Schritt weitergehen und beide Dimensionen zusammenbringen. Hierzu verwenden wir die Wertschöpfung aus Nutzersicht zusammen mit der obigen Einordnung der Qualitäten nach ihrer Relevanz je Evolutionsphase. Die Reihenfolge der Qualitäten ist in beiden Fällen die gleiche. Das ist deshalb so, da die Abfolge der Qualitäten in der Evolutionsachse ja auch die Nachfrage potenzieller Nutzer:innen abbildet. Beide Dimensionen zusammengebracht, ergeben die Darstellung einer Wardley Map: Die Dimension für die Evolution auf der x-Achse sowie die Dimension für die Wertschöpfungskette auf der y-Achse.

Die beiden eingangs erwähnten Beispiele sind hier ebenfalls mit eingezeichnet. „A“ ist das System mit den Performanzproblemen und „B“ ist die Kneipentour-Webanwendung. System A war ein System, welches es bereits als Produkt in einen App-Store geschafft hatte. Das komplette System musste jetzt aber etwas tun für mehr Performanz. Ansonsten lief das System in das Problem, dass die Nachfrage von den Nutzern zurückging, da das System zu langsam zu benutzen war. Auch Themen wie Wartbarkeit und Sicherheit standen langsam an und wollten angegangen werden. Das System B hatte sich hingegen um Dinge gekümmert, die völlig fehl am Platz waren. Wir erinnern uns: Ohne Nutzer:innen zu haben, wurde beispielsweise an hoher Leistungseffizienz gearbeitet (die Grenze war nur das Kreditkartenlimit). Das Auswechseln diverser Frontend- und Persistenztechnologien wurde implementiert, um auf mehrere Umgebungen übertragbar zu sein. Die Darstellung auf der Wardley Map zeigt sofort, dass wir hier völlig am Ziel vorbeigeschossen sind. Wir führten spekulatives Design in Reinform aus! Zum Glück lernten wir vieles dazu in dieser Zeit und können heute noch von diesen Erfahrungen zehren und mit einem lachenden und weinenden Auge davon erzählen.

Zusammenfassung

Mit der Darstellung von Softwarequalität auf einer Wardley Map erhalten wir neue Einsichten in unsere Entwicklungsaktivitäten. Wir haben gesehen, dass es im Lebenszyklus einer Software vorkommen kann, dass sich die Ansprüche an die Softwarequalitäten ändern kann. Softwareentwickelnde dürfen die Punkte nicht verpassen, da ansonsten die Evolution der Softwaresysteme stagniert. Es droht, mit der Zeit von anderen, gleichartigen Systemen überholt zu werden, die diese Qualitäten entsprechend adressieren. Entwicklungsteams dürfen aber auch nicht zu viel an Qualität wollen, wenn das Softwaresystem noch nicht so weit ist. Sonst droht zu viel Mehraufwand, der sich wirtschaftlich nicht mehr rechtfertigen lässt. Am Ende gilt es auch für dieses Modell um eine Vereinfachung einer ansonsten sehr komplexen Angelegenheit. Das Abbilden von Qualitätsmerkmalen auf einer Wardley Map kann uns jedoch helfen, Qualität besser in einer gegebenen Situation zu verstehen. Es lässt uns auch darüber nachdenken, wann wir denn welche Qualitäten in welcher Evolutionsstufe als nächstes angehen müssen, um weiterhin erfolgreich zu sein.

Insgesamt befindet sich das vorgestellte Modell jedoch selbst auch noch in der Entstehungsphase. Daher freue ich mich besonders über Fragen, Feedback, Diskussionen mittels Zuschriften per Kommentar, E-Mail, Brief oder Fax!

Header-Bild von Johannes Plenio von Unsplash

Vielen Dank an Anja Kammer für ihr Feedback zu einer früheren Version dieses Artikels!

Update 18.05.2022: Reihenfolge der Qualitäten an zwischenzeitliche gesammeltes Feedback und neuen Erfahrungen angepasst sowie zusammenfassende Visualisierung an den Anfang gestellt.