Evolutionäre Qualität

Evolutionäre Qualitätsziele beschreiben, welche Software-Qualitätsmerkmale in welcher Entwicklungsphase eines Produkts relevant sind. Ein System durchläuft Phasen von der Genesis über Einzelanfertigung und Produktreife bis zur Commodity. Früh zählen funktionale Eignung und Zuverlässigkeit, später Benutzbarkeit und Performance, zuletzt Wartbarkeit, Sicherheit, Kompatibilität und Übertragbarkeit.

Das Wichtigste in Kürze

• Softwarequalitätsziele sind nicht statisch: Welche ISO-25000-Qualitätsmerkmale relevant sind, hängt davon ab, in welcher Evolutionsphase sich ein Softwaresystem gerade befindet.
• In der frühen Experimentierphase sind funktionale Eignung und Zuverlässigkeit entscheidend, weil ein System beweisen muss, dass es funktioniert, bevor Investoren oder erste Kunden einsteigen.
• Wartbarkeit wird erst dann kritisch, wenn schnelles Wachstum das Onboarding neuer Entwicklerinnen und Entwickler erfordert und Feature-Requests in akzeptabler Zeit geliefert werden müssen.
• Geschäftsführer, Nutzende und Entwickler priorisieren Softwarequalitäten systematisch unterschiedlich: Benutzbarkeit steht bei Nutzenden ganz oben, Wartbarkeit bei Entwicklern ganz oben und bei Nutzenden ganz unten.
• Wer intern für technische Qualitätsthemen wie Wartbarkeit wirbt, braucht andere Argumente als für nutzerseitige Qualitäten: Metriken zu Entwicklungsgeschwindigkeit oder konkrete Onboarding-Kosten überzeugen dort, wo abstrakte Qualitätsbegriffe scheitern.

Was sind evolutionäre Qualitätsziele?

Evolutionäre Qualitätsziele bedeuten, dass sich die wichtigen Qualitätsmerkmale einer Software über ihren Reifegrad verschieben. Was am Anfang eines Systems zählt, ist nicht dasselbe wie das, was zählt, wenn das System am Markt erfolgreich ist.

Hinter dem Modell steht eine Beobachtung aus der Software-Architektur-Beratung: Firmen wollen oft zu viel auf einmal. Startups sehen nicht ein, warum sie sich plötzlich um Qualität kümmern sollen, schließlich gibt es ein laufendes Produkt. Bestandssoftware schleppt dagegen technische Schulden mit, und niemand weiß, wo der Hebel ansetzt.

Markus Harrer ordnet Softwarequalitäten den verschiedenen Phasen eines Systems zu. Die Grundlage liefert die Wardley-Mapping-Technik des Beraters Simon Wardley, eine Methode für strategische, evolvierende Landkarten von Software-Systemen. Eine ihrer Achsen ist die Evolutionsachse, und genau auf die lässt sich das Thema Qualität abbilden.

Die Evolutionsachse beschreibt vier Phasen eines Systems

Software wandert über ihre Lebensdauer durch vier Phasen, die mit dem Wechselspiel aus Angebot und Nachfrage zusammenhängen.

In der Genesis-Phase existiert nur eine Idee. Du weißt weder, ob jemand das Produkt nachfragt, noch ob es technisch machbar ist. Am Beispiel einer Reisekostenabrechnung: Du hast keine Ahnung, ob du Belege systematisch erfassen kannst und ob das überhaupt jemand braucht.

In der Einzelanfertigung baust du einen ersten Prototyp oder ein Minimal Viable Product. Du erfasst etwa Preise in einem Excel-Sheet und siehst, dass es für dich funktioniert. Ob der Markt es so will, ist noch offen.

In der Produktphase wird klar, dass ein breiter Bedarf besteht. Du baust eine echte Software mit Datenbank dahinter, weil sich der Aufwand jetzt rentiert. In der Commodity-Phase schließlich wird das System zum Gewohnheitsgut, etwa als Cloud-Service, der einen Massenmarkt versorgt.

Der Treiber dahinter dreht sich: Anfangs ist die Angebotsseite unklar, du musst beweisen, dass die Sache überhaupt herstellbar ist. Später zieht die Nachfrage an, neue Kunden kommen mit neuen Ansprüchen.

Welche Qualitäten in welcher Phase zählen

Pro Phase rücken andere Merkmale der ISO 25010 in den Fokus. Die Norm liefert dafür einen geklärten Wortschatz, mit dem über Qualität fundierter geredet werden kann, statt jeder eigene Begriffe erfindet.

Die folgende Zuordnung fasst zusammen, welche der acht Qualitäts-Obermerkmale in welcher Phase neu hinzukommen:

In der Genesis-Phase zählt vor allem die funktionale Eignung. Du musst beweisen, dass dein Ansatz funktioniert. Dazu kommt Zuverlässigkeit, denn vor Geldgebern darf die Software nicht beim nächsten Klick die Grätsche machen.

In der Einzelanfertigung schwappt Benutzbarkeit herein, weil plötzlich unterschiedliche Endnutzer mit verschiedenem Ausbildungsgrad bedient werden müssen. Mit den neuen Nutzern wird auch Performance zum Thema, denn eine responsive Anwendung wird nachgefragt.

In der Produktphase kommt Wartbarkeit ins Spiel. Wenn das System erfolgreich ist, brauchst du mehr Entwickler, um Feature-Requests in akzeptabler Zeit abzuarbeiten. Modularität und Analysierbarkeit entscheiden darüber, wie schnell du neue Leute onboarden und Teams unabhängig arbeiten lassen kannst. Anspruchsvollere Kunden verlangen außerdem Löschkonzepte, Auftragsdatenverarbeitung und Single Sign-On, womit Sicherheit hinzukommt.

In der Commodity-Phase bleiben Kompatibilität und Übertragbarkeit. Du willst dein System auf austauschbarer Cloud-Infrastruktur betreiben und Schnittstellen für andere Dienste anbieten, etwa damit Analyse-Tools auf deine Reisekostendaten zugreifen können.

Das Modell entlastet, statt nur zu fordern

Der praktische Wert liegt darin, dass du Qualitäten bewusst aussetzen darfst. Nicht jedes Thema muss von Anfang an perfekt sein.

Ein Startup, das keine Zeit für Wartbarkeit hat, liegt in der Genesis-Phase oft richtig. Markus berichtet von einem eigenen Startup mit dem Anspruch, Clean Code von Anfang an umzusetzen. Das Team konnte den Persistenzmechanismus binnen ein, zwei Tagen austauschen und tat das fünfmal. Sinnvoll war es nicht, es zeigt aber, wie leicht man Übertragbarkeit übertreibt, während Funktion und Benutzbarkeit liegen bleiben.

Das Modell hilft also bei zwei Fragen: Fokussiert ihr euch auf die richtigen Dinge? Und welche Entscheidung lässt sich noch vertagen, ohne ein Risiko einzugehen?

Warum Wartbarkeit dem Business so schwer zu vermitteln ist

Qualität wird schwerer verkaufbar, je tiefer sie in der Technik sitzt. Das erklärt eine zweite Achse des Modells, die Wertschöpfungskette.

Sie ordnet Komponenten danach, wie nah sie am Nutzer liegen. Oben steht, womit der Nutzer direkt in Kontakt kommt, etwa die Website. Darunter liegen Kundeninformationssystem, Betriebsplattform und Infrastruktur. Ein Nutzer merkt, wenn das Fotodrucken klemmt. Ob das System auf einem Kubernetes-Cluster läuft, bemerkt er nie.

Dasselbe gilt für Qualitäten. Funktionale Eignung und Benutzbarkeit liegen oben, nah am Nutzer, gut greifbar für Product Owner und Geschäftsführung. Wartbarkeit, Sicherheit und Verschlüsselungsverfahren liegen unten, weit weg vom Tagesgeschäft der Stakeholder.

Genau bei der Wartbarkeit kippt die Argumentierbarkeit. Bis dahin reden Business und Entwicklung über dieselben, sichtbaren Dinge. Ab Wartbarkeit wird die Qualität für das Business ominös, und der bekannte Konflikt bricht auf.

Wir müssen es mehr wartbar machen. Ja, was bedeutet das? Keine Ahnung, warum sollte ich mir das antun? Können wir es nicht schneller machen? Das kann ich besser zuordnen.

Markus Harrer

Unterschiedliche Rollen verfolgen unterschiedliche Qualitätsziele

In Software-Audit-Trainings argumentieren Teilnehmer aus drei Rollen heraus, welche Qualitäten am wichtigsten sind. Die Auswertung der Bewertungen zeigt klare Muster.

• Nutzer priorisieren Benutzbarkeit.
• Geschäftsführung priorisiert funktionale Eignung, also dass das Zugesagte eingehalten wird. Sicherheit rückt nach oben, seit Haftungsfragen sichtbarer werden.
• Entwickler priorisieren Wartbarkeit, die bei den anderen Rollen ganz unten landet.

Legt man die Sicht von Geschäftsführung und Nutzern zusammen, steht Benutzbarkeit oben, Wartbarkeit unten. Daraus folgt das Aneinander-vorbei-Reden im Team. Wer das Bewusstsein für diese Verteilung schafft, kann den Konflikt früher lösen, indem die Ziele aufgeschrieben und validierbar gemacht werden. Auch Nicht-Ziele helfen, den Fokus zu schärfen.

So bringst du als Entwicklungsteam interne Qualitäten voran

Wenn das Business interne Qualitäten nicht greift, brauchst du andere Methoden als bei nutzernahen Merkmalen. Ein direkter Appell an die Wartbarkeit verfängt selten.

Gründe eine Community of Practice im eigenen Unternehmen, etwa eine Software-Craft-Community, die sich um Wartbarkeit in eurem konkreten Kontext kümmert. So hältst du das Thema sichtbar und schaffst Werbung für seine Wichtigkeit, gekoppelt an einen echten Anlass wie “Wir wollen 50 neue Leute onboarden”.

Mach interne Qualität an Business-Bedürfnissen fest, statt an Technik. “Wir setzen Kubernetes ein” ist zu weit weg. “Wir wollen dynamische Lasten am Black Friday abfangen” ist zuordbar. Der Zwischenpunkt zwischen tiefer Technik und Geschäftsnutzen ist das Sprungbrett, über das das Business mitgeht.

Nutze passende Werkzeuge je nach Qualität. Für Wartbarkeit eignen sich DORA-Metriken, etwa die Lead Time von der Idee bis zum Roll-out, um sichtbar zu machen, dass die Feature-Entwicklung zu lange dauert. Für Sicherheit arbeitest du mit Risiken und Angstszenarien, die bei den Produktmanagern andocken.

Best Practices anderer Firmen liefern Abkürzungen, taugen aber nur, wenn sie zu deinem Kontext passen. Die Architektenrolle heißt hier, kreativer zu werden und mehr Verbindungen zum Business zu ziehen.

Qualitätsziele sind nie fertig

Qualitätsziele bleiben in Bewegung, weil das System in Bewegung bleibt. Neue Kundengruppen, steigende Nachfrage und ein aktives System sind gute Zeichen, sie verschieben aber laufend die Prioritäten.

Der Fehler liegt darin, die Top-5-Ziele vom Anfang als erledigt abzuhaken. Wartbarkeit, Sicherheit und Übertragbarkeit werden mit der Zeit wichtiger, als sie es am Start waren. Du musst die Liste also immer wieder neu ranken, je nachdem, wo das System auf der Evolutions- und der Wertschöpfungsachse gerade steht.

Eingefangene Ideen müssen nicht verloren gehen. Setz sie auf die Ersatzbank oder die Roadmap und greif darauf zurück, wenn der Zeitpunkt da ist. So nimmst du Teams mit, ohne dich zu verzetteln.