Evolutionäre Qualitätsziele: Welche Qualität wann zählt

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.

Häufig gestellte Fragen

Warum stoßen Qualitätsinitiativen in Startups und bei Bestandssoftware auf so unterschiedliche Widerstände?

Startups sehen keinen Anlass, sich um Qualität zu kümmern, weil ein laufendes Produkt existiert und funktioniert. Bei Bestandssoftware ist das Gegenteil das Problem: Technische Schulden haben sich angehäuft, und niemand weiß, wo der Hebel ansetzen soll. Beide Fälle führen zu dem Fehler, zu viele Qualitätsthemen gleichzeitig anzugehen, statt sie nach Reifegrad zu ordnen.

Woher kommt der Gedanke, Softwarequalität an die Reifephase eines Systems zu koppeln?

Die Grundlage liefert Wardley Mapping, eine Technik des Beraters Simon Wardley für strategische, evolvierende Landkarten von Software-Systemen. Eine ihrer Achsen ist die Evolutionsachse mit den Phasen Genesis, Einzelanfertigung, Produkt und Commodity. Markus Harrer bildet Softwarequalitäten auf genau diese Achse ab und ergänzt sie um die zweite Achse, die Wertschöpfungskette.

Welche Qualitätsmerkmale zählen, solange ein Produkt am Markt noch nicht bewiesen ist?

Funktionale Eignung und Zuverlässigkeit. In der Genesis-Phase muss ein System zeigen, dass der Ansatz technisch überhaupt trägt, und es darf vor Geldgebern nicht beim nächsten Klick abstürzen. Erst mit dem ersten Prototyp oder Minimal Viable Product kommen Benutzbarkeit und Performance hinzu, weil dann Endnutzer mit unterschiedlichem Ausbildungsgrad bedient werden müssen.

Darf ein Team einzelne Qualitätsmerkmale bewusst liegen lassen?

Ja, und genau darin liegt der praktische Wert des Modells. Ein Startup ohne Zeit für Wartbarkeit liegt in der Genesis-Phase oft richtig. Umgekehrt kann man Qualität am falschen Ende übertreiben: In einem eigenen Startup tauschte Markus Harrers Team den Persistenzmechanismus fünfmal binnen ein bis zwei Tagen aus, während Funktion und Benutzbarkeit liegen blieben.

Warum verstehen Stakeholder manche Qualitätsforderungen aus der Entwicklung nicht?

Weil Qualitäten unterschiedlich weit vom Nutzer entfernt liegen. Funktionale Eignung und Benutzbarkeit sind sichtbar und für Product Owner und Geschäftsführung greifbar. Wartbarkeit, Sicherheit und Verschlüsselungsverfahren sitzen tief in der Technik, weit weg vom Tagesgeschäft. Ab der Wartbarkeit kippt die Argumentierbarkeit: Business und Entwicklung reden nicht mehr über dieselben sichtbaren Dinge.

Mit welchen Kennzahlen lässt sich Wartbarkeit gegenüber dem Business belegen?

DORA-Metriken eignen sich, etwa die Lead Time von der Idee bis zum Roll-out. Damit wird sichtbar, dass Feature-Entwicklung zu lange dauert, ohne dass über abstrakte Qualitätsbegriffe geredet werden muss. Für Sicherheit funktionieren Risiken und Angstszenarien besser, weil sie bei Produktmanagern andocken. Hilfreich ist auch ein konkreter Anlass wie das Onboarding von 50 neuen Leuten.

Muss man Qualitätsziele im Laufe eines Projekts neu priorisieren?

Ja. Der typische Fehler ist, die Top-5-Ziele vom Projektstart als erledigt abzuhaken. Wartbarkeit, Sicherheit und Übertragbarkeit werden mit der Zeit wichtiger, als sie am Anfang waren, weil neue Kundengruppen und steigende Nachfrage die Prioritäten verschieben. Verworfene Ideen gehören auf die Ersatzbank oder die Roadmap, statt endgültig gestrichen zu werden.