Diskussion:Softwarequalität

Kriterienkatalog für hochqualitative Softwareentwicklung im Zeitalter von AI-Driven Development

Eine Erweiterung des klassischen Drei-Säulen-Modells (Produkt- / Struktur- / Prozessqualität) um eine vierte Säule für den KI-augmentierten Entwicklungsprozess.

---

Quellen- und Traditionslinie (Vorbemerkung)

Die hier verwendete Dreiteilung in Produktqualität, Strukturqualität (Architektur) und Prozessqualität ist kein originäres Modell eines einzelnen Autors, sondern fachwissenschaftlich etablierter Konsens, der sich aus drei parallelen Forschungslinien speist:

• Produktqualität geht zurück auf die FCM-Modelle (Factor-Criterion-Metric) von McCall et al. (1977) und Boehm et al. (1978), später kanonisiert in ISO/IEC 9126 (1991) und der heute gültigen ISO/IEC 25010 (2011, Revision 2023). FURPS (Grady/Caswell, HP, 1987) ist eine bekannte Parallel-Variante.
• Prozessqualität entstammt der Total-Quality-Tradition (Deming, Juran, Crosby) und wurde für Software durch Watts Humphrey am SEI mit dem Capability Maturity Model (CMM, 1991) und später CMMI sowie ISO/IEC 15504 / SPICE systematisiert. Die Kernannahme — "guter Prozess begünstigt gute Produkte" — formuliert Dunn (1990) in der bekannten Definition.
• Strukturqualität / Architektur als eigene Qualitätsdimension wurde durch Shaw & Garlan (1996) und vor allem Bass, Clements, Kazman in Software Architecture in Practice (1998 ff.) etabliert. Methoden wie ATAM und das Konzept der Quality Attributes stammen aus dieser Linie. Im deutschsprachigen Raum prägen Gernot Starke (Effektive Softwarearchitekturen) und der iSAQB-Lehrplan seit ca. 2008 die Architektenausbildung — und damit auch das Vokabular, das Trainer wie David Tielke in ihren Workshops verwenden.

Die explizite Verpackung als "Drei Säulen" ist ein didaktisches Framing, das in der deutschsprachigen Architektur-Community kursiert und u.a. von Tielke prominent vertreten wird; konzeptionell ist sie eine Synthese der genannten Traditionen, keine Neuschöpfung.

Das vollständige Literaturverzeichnis findet sich am Ende dieses Dokuments. Pro Säule sind die einschlägigen Primärquellen jeweils direkt benannt.

Hinweis zum Lesen: Fachbegriffe sind beim ersten Auftreten knapp im Text erklärt. Ein ausführliches Glossar im Concept-Card-Format mit ~45 zentralen Begriffen findet sich vor dem Literaturverzeichnis am Ende des Dokuments — dort jeweils mit Definition, Einsatzzweck, Abgrenzung zu Verwandtem und Quellverweis.

---

Säule 1 — Produktqualität (klassisch, aber neu gewichtet)

Fachwissenschaftliche Verankerung: McCall, Richards & Walters (1977) · Boehm, Brown & Lipow (1978) · ISO/IEC 9126 (1991) · ISO/IEC 25010 (2011, Rev. 2023) · FURPS (Grady & Caswell 1987). Die hier verwendeten Charakteristiken folgen ISO/IEC 25010.

Das ist die "Was ist am Ende rausgekommen?"-Sicht. Klassische Kriterien bleiben gültig, aber zwei verschieben sich in der Gewichtung: Sicherheit und Verifizierbarkeit.

Kernkriterien

• Funktionale Eignung — Korrektheit, Vollständigkeit, Angemessenheit gegenüber Spezifikation
• Zuverlässigkeit — Verfügbarkeit, Fehlertoleranz, Wiederherstellbarkeit
• Performance-Effizienz — Antwortzeit, Durchsatz, Ressourcenverbrauch (zunehmend auch: Energieverbrauch / Green Coding — energiebewusste Softwareentwicklung)
• Benutzbarkeit & Barrierefreiheit — WCAG 2.2 AA (Web Content Accessibility Guidelines, internationaler Standard für barrierefreie Webinhalte) als Mindeststandard, nicht als Bonus
• Sicherheit (Product Security) — OWASP Top 10 (Liste der häufigsten Web-Sicherheitslücken), Threat Modeling (systematische Bedrohungsanalyse vor der Implementierung), Defense in Depth (mehrschichtige Verteidigung)
• Wartbarkeit — siehe Säule 2 (gehört strukturell dorthin)
• Kompatibilität & Portabilität — Interoperabilität, plattformübergreifende Lauffähigkeit

Konkrete Prüfpunkte

• Existieren messbare Service Level Objectives (SLOs — interne Qualitätsziele wie "99,9% Verfügbarkeit") statt vager "muss schnell sein"?
• Sind die Top-10-Bedrohungen explizit modelliert (STRIDE — Microsoft-Klassifikation: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege; LINDDUN — Privacy-Pendant)?
• Existiert ein Accessibility-Audit pro Major-Release?
• Wird Energieverbrauch als nicht-funktionale Anforderung erfasst?

Antipattern

• "Performance optimieren wir später" ohne Baseline-Messung
• Sicherheit als Pen-Test am Ende statt als Shift-Left-Praxis (Qualitätsprüfungen früh im Entwicklungsprozess)
• Accessibility als nachträglicher Zusatz statt als Designprinzip

Tooling

• k6, Gatling, Locust (Performance) · OWASP ZAP, Burp, Semgrep (Security) · axe-core, Pa11y (a11y) · Scaphandre, CodeCarbon (Energie)

---

Säule 2 — Strukturqualität / Architektur

Fachwissenschaftliche Verankerung: Shaw & Garlan (1996) · Bass, Clements & Kazman (1998 ff., aktuell 4. Aufl. 2021) inkl. ATAM · Parnas (1972, Modularisierung) · Evans (2003, Domain-Driven Design) · Cockburn (2005, Hexagonal Architecture) · Ford, Parsons & Kua (2017, Building Evolutionary Architectures — Fitness Functions) · Skelton & Pais (2019, Team Topologies) · Starke (aktuell 9. Aufl., Effektive Softwarearchitekturen) · iSAQB-Lehrplan (Foundation/Advanced Level). David Tielkes "Composite Components" ist ein eigenes, im deutschsprachigen Raum verbreitetes Pattern in dieser Tradition.

Tielkes Kerngebiet. Modularisierung (Zerlegung in unabhängige Bausteine), Kohäsion (innerer Zusammenhalt eines Moduls — gehört zusammen, was zusammengehört) und Kopplung (Abhängigkeit zwischen Modulen — möglichst gering) bleiben die invarianten Begriffe. Ergänzt um zeitgemäße Pattern und — entscheidend — um executable constraints (automatisiert durchsetzbare Architekturregeln statt bloß dokumentierter).

Kernkriterien

• Modularität — klare Schnittstellen, niedrige Kopplung, hohe Kohäsion
• Wartbarkeit — Lesbarkeit, Änderbarkeit, Analysierbarkeit, Modifizierbarkeit, Testbarkeit
• Evolvierbarkeit — Erweiterbarkeit ohne Breaking Changes (Änderungen, die bestehende Schnittstellen brechen), Versionierungsstrategie
• Architektur-Fitness — automatisiert prüfbare Architekturregeln (Fitness Functions nach Neal Ford — Tests, die Architektur-Eigenschaften wie Schichtentrennung oder Performance-Budgets im CI durchsetzen)
• Soziotechnische Passung — Conway's Law bewusst nutzen (Beobachtung: Systeme spiegeln die Kommunikationsstruktur der bauenden Organisation; Team Topologies macht das gestaltbar)
• Strategischer Architekturstil — bewusst gewählt, nicht zufällig: Modular Monolith (in sich modulare Einzelapplikation), Hexagonal/Ports & Adapters (Domänenkern wird über klar definierte "Ports" von Infrastruktur isoliert), Event-Driven (Komponenten kommunizieren über Ereignisse), CQRS (Command Query Responsibility Segregation — getrennte Modelle für Schreiben und Lesen), Microservices — je nach Kontext

Konkrete Prüfpunkte

• Gibt es Architecture Decision Records (ADRs — kurze, versionierte Markdown-Dokumente, die Architekturentscheidungen festhalten) mit Begründung und Verworfenen?
• Werden Architekturregeln automatisiert geprüft (ArchUnit — Java-Library für Architektur-Tests, dependency-cruiser, Sonargraph, NetArchTest)?
• Existiert eine dokumentierte Domänensprache (Ubiquitous Language nach DDD — gemeinsames Vokabular von Fachbereich und Entwicklung)?
• Sind Bounded Contexts (klar abgegrenzte Domänenbereiche mit eigenem Modell) und Team-Grenzen kongruent?
• Wird Komplexität gemessen (zyklomatisch, kognitiv, Kopplungsmetriken)?

Antipattern

• Architektur lebt nur in Diagrammen und Köpfen → wird in der Praxis erodiert
• "Microservices, weil das machen jetzt alle" ohne Domain-Decomposition (fachliche Zerlegung als Basis der Service-Schnitte)
• Verteilter Monolith — Microservices-Topologie mit monolithischer Kopplung (Dienste sind so eng verzahnt, dass sie nur gemeinsam deploybar sind — schlechtester Fall: Komplexität verteilter Systeme ohne deren Vorteile)
• Anämisches Domänenmodell (Datenklassen ohne Verhalten — verstößt gegen DDD-Idee, dass fachliches Verhalten ins Domänenmodell gehört) trotz DDD-Anspruch
• "Wir sind Hexagonal" ohne klare Ports & Adapter-Trennung

Tooling

• ArchUnit (Java), NetArchTest (.NET), dependency-cruiser (JS/TS) · Structure101, Sonargraph, NDepend · C4-Model + Structurizr für Visualisierung · Lizi/Backstage für Service-Katalog

---

Säule 3 — Prozessqualität

Fachwissenschaftliche Verankerung: Deming (1986), Juran, Crosby — allgemeine Qualitätstheorie · Humphrey (1989, Managing the Software Process) und das Capability Maturity Model (CMM, 1991) sowie CMMI am SEI · ISO/IEC 15504 (SPICE) und Branchenableger (Automotive SPICE) · Dunn (1990) zur Beziehung Produkt-/Prozessqualität · Forsgren, Humble & Kim (2018, Accelerate — DORA-Metriken) · Beyer et al. (2016, Site Reliability Engineering — Google) · Skelton & Pais (2019, Team Topologies).

Tielke widmet dem einen eigenen Webcast (Teil 2). Die klassischen Themen bleiben, aber DevOps/SRE/Platform Engineering haben den Bereich seit ~2018 erweitert.

Kernkriterien

• Engineering-Praktiken — Code Review, Pair/Mob Programming, Trunk-Based Development (alle Entwickler arbeiten auf einem Hauptzweig statt langlebiger Feature-Branches), TDD (Test-Driven Development — Tests vor Implementierung), BDD (Behavior-Driven Development — Verhalten in fachsprachlicher Form spezifizieren)
• CI/CD-Reife — DORA-Metriken (vier wissenschaftlich validierte Kennzahlen aus dem State of DevOps-Report: Deployment Frequency — wie oft wird produktiv deployed, Lead Time — von Commit zu Produktion, Change Failure Rate — Anteil defekter Releases, MTTR — Mean Time to Recovery)
• Automatisierung — Build, Test, Deploy, Infrastruktur (IaC — Infrastructure as Code: Server, Netzwerk, Cloud-Ressourcen werden als versionierter Code beschrieben statt manuell konfiguriert), Compliance
• Observability — Beobachtbarkeit produktiver Systeme über Logs, Metrics, Traces (verteilte Trace-Verfolgung über Service-Grenzen hinweg), plus Continuous Profiling und Business KPIs
• Incident Response — Runbooks (dokumentierte Reaktionsabläufe), Blameless Postmortems (Vorfall-Analysen ohne Schuldzuweisung, fokussiert auf systemische Ursachen), Error Budgets (akzeptierte Ausfallzeit als Steuerungsgröße zwischen Stabilität und Innovationstempo)
• Platform Engineering — Internal Developer Platform (IDP — interne Plattform, die Entwicklerteams Self-Service-Zugriff auf Infrastruktur, CI/CD und Standards bietet) als Produkt für Entwicklerteams
• Wissenstransfer & Onboarding — Dokumentation als Code, Architecture Haikus (sehr knappe Architektur-Beschreibungen), Lernpfade

Konkrete Prüfpunkte

• Wo steht das Team auf den DORA-Metriken (Elite / High / Medium / Low)?
• Wird Infrastruktur 100% als Code verwaltet (Terraform, Pulumi, Crossplane — verbreitete IaC-Werkzeuge)?
• Existieren Service Level Objectives mit Error Budgets — nicht nur SLAs (Service Level Agreements; SLOs sind die internen Ziele, die ein SLA absichern)?
• Wie lange braucht ein neuer Entwickler bis zum ersten produktiven Commit?
• Gibt es ein Internal Developer Portal (Backstage — von Spotify entwickelt, heute Standard, o.ä.) ab Team-Größe ≥ 30?

Antipattern

• "DevOps-Team" als Silo statt als Kultur
• Manuelle Release-Approvals als Sicherheitstheater
• Observability = "wir haben Logs in Splunk"
• Postmortems mit Schuldzuweisung
• Plattform-Team baut, was es selbst cool findet, nicht was Teams brauchen

Tooling

• GitHub Actions / GitLab CI / Buildkite · Terraform, Pulumi, Crossplane · OpenTelemetry, Grafana, Prometheus, Honeycomb · Backstage, Port, Cortex (IDP) · PagerDuty, Incident.io

---

Säule 4 — KI-augmentierter Entwicklungsprozess (NEU)

Quellen- und Diskursverankerung: Dieser Bereich hat noch keine kanonisierte Lehrbuchliteratur. Der Diskurs läuft über Industrie-Publikationen, Konferenzbeiträge und Praktiker-Quellen. Wichtige Bezüge: GitHub/Anthropic/OpenAI-Dokumentation zu Coding-Agenten · Karpathy (2025) zum Begriff "Vibe Coding" · Simon Willison (laufende Blog-Reihe zu LLM-gestützter Entwicklung, u.a. zu Slopsquatting) · Lazar Nikolov / Birgitta Böckeler / Martin Fowler (thoughtworks: Generative AI in software engineering) · NIST AI Risk Management Framework (AI RMF 1.0, 2023) · OWASP Top 10 for LLM Applications (2023/2024) · SLSA Framework (Supply-chain Levels for Software Artifacts) · Lazar (2024) und andere zu Slopsquatting / Package Hallucination · DORA-Reports 2024/2025 mit AI-Adoption-Daten · Ford et al. (2017) zu Fitness Functions als Brückenkonzept zur Architektur-Governance.

Das ist der Bereich, der in klassischen Qualitätsframeworks fehlt. Wenn 60–80% des Codes von KI-Assistenten generiert wird, verschiebt sich der Hebel von "guter Code schreiben" zu "guten Kontext geben, gut verifizieren, gut steuern". Vier Subbereiche:

4.1 Spezifikations- und Intent-Qualität

Die neue Engpassressource ist nicht Code, sondern präzise, kontextreiche Spezifikation.

Kernkriterien

• Spec-Driven Development — Spezifikation ist primärer Artefakt, Code ist Ableitung (in Abgrenzung zu Vibe Coding, dem flow-haften, intuitiven Generieren mit KI ohne klare Spec)
• Maschinenlesbare Akzeptanzkriterien — Gherkin/BDD (Given-When-Then-Syntax, die Fachsprache und ausführbare Tests verbindet), ausführbare Specs, Property-based Tests (Tests, die nicht Beispiel-Inputs prüfen, sondern Eigenschaften über Tausende generierter Inputs hinweg) als Spec
• Kontext-Engineering — projektspezifische Konventionen explizit in Konfigurationsdateien, die Coding-Agenten beim Generieren lesen (AGENTS.md — herstellerübergreifender Quasi-Standard, CLAUDE.md für Anthropic Claude Code, .cursorrules für Cursor, copilot-instructions.md für GitHub Copilot)
• Domain-Glossar als Code — Ubiquitous Language ist im Repo, nicht im Confluence

Konkrete Prüfpunkte

• Existiert eine zentrale AGENTS.md / CLAUDE.md mit Architekturprinzipien, Stilregeln, verbotenen Pattern?
• Sind Akzeptanzkriterien so formuliert, dass eine KI sie ohne Rückfrage umsetzen könnte?
• Wird die Domain-Sprache automatisiert auf Konsistenz geprüft?
• Werden Prompts und Generierungs-Konventionen versioniert wie Code?

Antipattern

• Tickets im Stil "Bitte XYZ implementieren" → KI rät, Mensch korrigiert in Endlosschleife
• Konventionen leben in Slack-Threads statt im Repo
• Jeder Entwickler hat eigene Prompts, kein Team-Kontext

4.2 Verifikations- und Review-Qualität

Wenn KI generiert, wird die Kernkompetenz des Entwicklers das kritische Lesen, Hinterfragen, Verifizieren.

Kernkriterien

• Mehrschichtige Test-Strategie — Unit + Integration + Contract Tests (prüfen Schnittstellen-Verträge zwischen Diensten) + Property-based + Mutation Testing (qualitätssichert die Tests selbst, indem Code-Mutationen eingeschleust werden — überleben sie, sind die Tests zu schwach)
• Adversarial Review — Code-Review mit Angreifer-Mindset: bewusst nach Halluzinationen, erfundenen APIs, Sicherheitslücken suchen
• Reviewer-Ratio anpassen — KI-generierter Code braucht mehr Review, nicht weniger
• Test-Pyramide neu denken — die klassische Pyramide (viele Unit-, weniger Integrations-, wenige End-to-End-Tests) verschiebt sich Richtung Integration, weil KI lokal plausiblen, im Zusammenspiel falschen Code erzeugt

Konkrete Prüfpunkte

• Gibt es Mutation Testing (Stryker, PIT, mutmut) in der Pipeline?
• Werden Property-based Tests (Hypothesis, fast-check, jqwik) für kritische Domänen-Logik genutzt?
• Existiert eine Checkliste für KI-generierten Code im Review (siehe Antipattern)?
• Werden Halluzinations-Indikatoren automatisiert geprüft (nicht-existente Imports, erfundene API-Calls)?

Antipattern

• "Die Tests sind grün, also ist es richtig" — die Tests wurden auch von der KI geschrieben
• Reviewer überfliegt 800 Zeilen KI-Code in 5 Minuten
• Keine Unterscheidung zwischen handgeschrieben und generiert in PR-Metadaten (Pull-Request-Metadata)
• Plausibilitäts-Bias: Code sieht sauber aus, also ist er es

Tooling

• Stryker, PIT, mutmut (Mutation Testing) · Hypothesis, fast-check (Property-based) · Semgrep, CodeQL für statische Analyse · Snyk, Socket.dev gegen Dependency-Halluzinationen

4.3 Architektur-Governance für autonome Agenten

Architektur muss durchsetzbar sein, nicht nur dokumentiert. Sonst erodieren Agenten sie zuverlässig.

Kernkriterien

• Executable Architecture — Fitness Functions, Linting-as-Architecture (Architekturregeln werden als Linter-Regeln formuliert, die im Editor und CI sofort feuern), ArchUnit-Regeln im CI
• Constraint-First-Prompting — Agenten kennen die Regeln, bevor sie generieren (statt erst im Review zu erfahren, dass etwas nicht erlaubt war)
• Automatisierte ADRs — Entscheidungen werden bei Generierung referenziert und aktualisiert
• Reversibilität — KI-Änderungen sind atomar, nachvollziehbar, rückrollbar (kleine, isolierte Commits statt 800-Zeilen-Mega-PRs)

Konkrete Prüfpunkte

• Werden Architekturregeln so formuliert, dass sie sowohl im CI als auch im Agenten-Kontext greifen?
• Gibt es einen Pre-Generation-Check, der Agenten auf relevante Constraints hinweist?
• Sind alle KI-Commits separat markiert (Co-authored-by, Trailer im Commit)?
• Existiert eine Quarantäne-Branch-Strategie für autonome Agenten?

Antipattern

• Architektur-Diagramm in Confluence, das nichts erzwingt
• Agent darf direkt auf main committen
• Keine Unterscheidung zwischen "Mensch dachte nach" und "Agent generierte"

4.4 KI-Supply-Chain & Sicherheit

KI-generierter Code bringt eigene Klassen von Sicherheitsrisiken mit, die klassische Qualitätsmodelle nicht kennen.

Kernkriterien

• Dependency-Halluzination prüfen — Schutz gegen Slopsquatting (eine 2024 dokumentierte Angriffsklasse, bei der Angreifer gezielt Pakete unter Namen registrieren, die LLMs erfinden — naive Installation der KI-Vorschläge führt dann zu Schadcode-Import): existiert das Paket wirklich, ist es legitim?
• SBOM für jede Generierung — Software Bill of Materials (maschinenlesbares Inhaltsverzeichnis aller Software-Bestandteile inkl. Versionen und Lizenzen), SLSA-Level (Supply-chain Levels for Software Artifacts — Reifegradmodell für vertrauenswürdige Lieferketten) dokumentiert
• Prompt-Injection-Resilienz — Schutz gegen Prompt Injection: Angriffsklasse, bei der Eingaben aus externen Quellen (z.B. Web-Inhalte, die ein Agent verarbeitet) versteckte Anweisungen enthalten, die das Modell umsteuern
• Secret-Hygiene — KI darf keine Credentials in Prompts oder generiertem Code sehen/erzeugen
• Lizenz-Compliance — generierter Code kann fremde Lizenzen mitschleppen

Konkrete Prüfpunkte

• Ist der Dependency-Resolver gegen erfundene Paketnamen abgesichert?
• Wird jede neue Dependency auf Alter, Maintainer, Reputation geprüft (Socket, Snyk)?
• Werden Prompts auf Injection-Pattern gefiltert?
• Existiert ein Air-Gap zwischen Produktions-Secrets und KI-Tooling?
• Gibt es eine Lizenz-Policy für KI-Output (besonders bei strict copyleft)?

Antipattern

• npm install direkt aus KI-Vorschlag ohne Verifikation
• Agent hat Zugriff auf .env oder Secret-Manager
• Keine Prüfung, ob generierter Code Trainingsdaten-Snippets reproduziert

4.5 Soziotechnische Qualität & Skill-Erhalt

Der vielleicht wichtigste blinde Fleck: Was passiert mit Teams, wenn Junioren nie mehr "die schweren Stellen selbst durchdenken"?

Kernkriterien

• Bewusste Schwierigkeit — Junioren bekommen Aufgaben ohne KI-Assistenz, um Grundlagen zu lernen (Begriff aus der Lernforschung: desirable difficulty nach Bjork — produktive Anstrengung als Lernverstärker)
• Wissens-Resilienz — Team kann ohne KI-Tools mindestens eingeschränkt weiterarbeiten
• Mentoring trotz KI — Code-Verständnis bleibt Lernziel, nicht nur Code-Produktion
• Lern-Telemetrie — Tracking, was Entwickler durch KI-Nutzung nicht mehr lernen (Schutz vor Skill-Atrophie: schleichender Verlust grundlegender Fähigkeiten durch dauerhafte Auslagerung an Werkzeuge)

Konkrete Prüfpunkte

• Gibt es regelmäßige "KI-freie" Sessions (Coding Dojos — gemeinsame Übungssessions an Coding-Aufgaben, Architecture Katas — kurze Architektur-Übungen an fiktiven Szenarien)?
• Wird Code-Review als Lehrmoment genutzt, nicht als Rubber-Stamp (durchgewinkte Genehmigung ohne echte Prüfung)?
• Gibt es Mentoring-Strukturen, die explizit gegen Skill-Atrophie arbeiten?
• Wie würde das Team auf einen 48h-Ausfall aller KI-Tools reagieren?

Antipattern

• Junior committet Code, den niemand im Team erklären kann
• KI als "schneller Fertig"-Druckmittel statt als Hebel
• Wegfall von Pair Programming, weil "geht ja schneller mit Copilot"

---

Reifegradmodell (optional als Workshop-Raster)

Pro Kriterium 0–4 Punkte:

Stufe	Bezeichnung	Charakteristik
0	Unbewusst	Thema ist nicht im Bewusstsein des Teams
1	Ad hoc	Einzelne kümmern sich, kein Standard
2	Definiert	Standard existiert, wird aber nicht durchgesetzt
3	Gemessen	Standard wird automatisiert geprüft, Metriken existieren
4	Optimiert	Kontinuierliche Verbesserung auf Basis der Metriken

Faustregel: Säule 4 (KI) ist 2026 bei den meisten Teams auf Stufe 0–1. Genau dort liegt der größte Hebel.

---

Wie der Katalog gegen Tielkes Material zu halten ist

Hinweis: Die folgende Tabelle vergleicht den Katalog mit den Themen, die Tielke in seinen öffentlich zugänglichen Workshops, Webcasts und Publikationen behandelt. "Deckt ab" bedeutet didaktische Vermittlung, nicht konzeptionelle Urheberschaft — die fachliche Herkunft der Konzepte ist in den jeweiligen Säulen-Quellen oben benannt.

Tielke vermittelt	Im Katalog	Lücke / Ergänzung
Softwarequalität (allgemein, ISO-25010-nah)	Säule 1	Energie/Green Coding, Accessibility als Pflicht
Composite Components, Modularisierung, Kohäsion/Kopplung	Säule 2	DDD in Tiefe, Hexagonal, Event-Driven, Fitness Functions, Team Topologies
Prozessqualität, ALM	Säule 3	DORA-Metriken, Platform Engineering, Observability als Disziplin
Anforderungen / Product Owner	4.1 (teilweise)	Spec-Driven Dev, Kontext-Engineering, AGENTS.md
—	4.2	Verifikations-Kompetenz, Mutation Testing, Adversarial Review
—	4.3	Executable Architecture für Agenten
—	4.4	KI-Supply-Chain-Sicherheit
—	4.5	Skill-Erhalt, soziotechnische Wirkung

---

Nutzungsempfehlung

1. Als Self-Assessment — Team bewertet jedes Kriterium auf der 0–4-Skala, identifiziert Top-3-Lücken pro Säule.
2. Als Workshop-Raster — eine Säule pro Halbtag, Antipattern als Diskussionseinstieg.
3. Als Audit-Checkliste — Prüfpunkte als Ja/Nein-Liste, pro Nein einen Maßnahmen-Eintrag.
4. Als Onboarding-Dokument — neue Teammitglieder lernen, was bei euch unter "Qualität" verstanden wird — inklusive der KI-Dimension.

---

Dieser Katalog ist bewusst opinionated. Säule 1–3 sind in der Community Konsens, Säule 4 ist 2026 noch in Bewegung — die hier genannten Praktiken sind die, die sich bisher durchsetzen, aber das Feld wird sich in 12–24 Monaten nochmal verschieben.

---

Glossar (Concept Cards)

Format pro Begriff: Was es ist · Wozu · Nicht zu verwechseln mit (sofern relevant) · Mehr dazu. Die Reihenfolge folgt der Säulen-Struktur, innerhalb thematisch gruppiert.

Allgemeine Qualitätsmodelle

ISO/IEC 25010

Was es ist: Internationaler Standard, der Software-Produktqualität in acht Charakteristiken unterteilt (Functional Suitability, Performance Efficiency, Compatibility, Usability, Reliability, Security, Maintainability, Portability), jeweils mit Subcharakteristiken.

Wozu: Gemeinsames Vokabular für Anforderungen, Reviews, Audits. Ablösung des älteren ISO 9126.

Nicht zu verwechseln mit: ISO 9001 (allgemeines Qualitätsmanagement, prozess-fokussiert).

Wichtig zur Namensherkunft: ISO = International Organization for Standardization (kein Akronym, sondern abgeleitet vom griechischen isos — "gleich", damit in allen Sprachen gleich abgekürzt). IEC = International Electrotechnical Commission. Die 25000er-Reihe heißt SQuaRE — Software product Quality Requirements and Evaluation; 25010 ist darin das Qualitätsmodell-Dokument.

Mehr dazu: ISO/IEC 25010:2011, Revision 2023.

FCM-Modell (Factor-Criterion-Metric)

Was es ist: Strukturierungsschema, das Qualitätsmerkmale (Factors) in messbare Kriterien (Criteria) und konkrete Metriken zerlegt.

Wozu: Operationalisierung des unscharfen Begriffs "Softwarequalität".

Wichtig zur Namensherkunft: Die drei Buchstaben spiegeln drei Abstraktionsebenen: Factor — abstraktes Qualitätsmerkmal (z.B. "Wartbarkeit"); Criterion — operationale Eigenschaft (z.B. "Modularität"); Metric — konkrete Messzahl (z.B. "Fan-out pro Modul"). Der McCall-Report wurde im Auftrag des US Air Force Rome Air Development Center erstellt — daher der starke Fokus auf militärisch-formale Operationalisierbarkeit.

Mehr dazu: McCall et al. (1977), Boehm et al. (1978).

FURPS / FURPS+

Was es ist: Klassifikation für Anforderungen — Functionality, Usability, Reliability, Performance, Supportability (das "+" steht für Constraints wie Design, Implementation, Interface, Physical).

Wozu: Strukturhilfe bei der Anforderungserhebung.

Wichtig zur Namensherkunft: Die fünf Buchstaben einzeln: Functionality (Funktionalität, Sicherheit) · Usability (Bedienbarkeit, Konsistenz, Dokumentation) · Reliability (Verfügbarkeit, Fehlertoleranz, Wiederherstellbarkeit) · Performance (Geschwindigkeit, Durchsatz, Ressourcen) · Supportability (Wartbarkeit, Erweiterbarkeit, Lokalisierbarkeit). Entwickelt bei Hewlett-Packard; das "+" wurde später bei Rational Software (heute IBM) ergänzt, um nicht-funktionale Constraints sichtbar zu machen, die kein "Quality Attribute" sind, aber die Lösung einschränken.

Mehr dazu: Grady & Caswell (HP, 1987).

CMM / CMMI

Was es ist: Reifegradmodell für Software-Entwicklungsprozesse mit fünf Stufen (Initial → Managed → Defined → Quantitatively Managed → Optimizing).

Wozu: Bewertung und schrittweise Verbesserung organisationaler Prozessreife.

Nicht zu verwechseln mit: SPICE/ISO 15504 (kontinuierliches statt stufiges Modell, gleiche Idee).

Wichtig zur Namensherkunft: Capability Maturity Model; CMMI = "Integration", weil ab 2002 mehrere getrennte CMMs (Software, Systems Engineering, Acquisition) zu einem integrierten Modell zusammengeführt wurden. Entwickelt am SEI (Software Engineering Institute) der Carnegie Mellon University, ursprünglich im Auftrag des US-Verteidigungsministeriums — daher die in europäischen Augen oft als formalistisch empfundene Schwere.

Mehr dazu: Humphrey (1989), Paulk et al. (1993).

Architektur — Grundbegriffe

Modularisierung

Was es ist: Zerlegung eines Systems in unabhängige, klar abgegrenzte Bausteine mit definierten Schnittstellen.

Wozu: Macht Systeme verstehbar, parallel entwickelbar, testbar, austauschbar.

Mehr dazu: Parnas (1972) — die Urquelle "On the Criteria to Be Used in Decomposing Systems into Modules".

Kohäsion

Was es ist: Maß für den inneren Zusammenhalt eines Moduls — wie eng die Elemente innerhalb eines Moduls zusammengehören.

Wozu: Hohe Kohäsion ist gewünscht (ein Modul = ein Zweck).

Nicht zu verwechseln mit: Kopplung (Beziehungen zwischen Modulen).

Kopplung

Was es ist: Maß für die Abhängigkeit zwischen Modulen.

Wozu: Niedrige Kopplung ist gewünscht (Module unabhängig änderbar).

Faustregel: "Hohe Kohäsion, niedrige Kopplung" ist eines der ältesten und stabilsten Architekturprinzipien.

Conway's Law

Was es ist: Beobachtung von Melvin Conway (1968): "Organisationen entwerfen Systeme, die ihre Kommunikationsstrukturen abbilden."

Wozu: Erklärt, warum technische Architektur und Team-Struktur untrennbar sind.

Wichtig zur Namensherkunft: Stammt aus dem Aufsatz "How Do Committees Invent?" — der ursprünglich von der renommierten Harvard Business Review abgelehnt wurde mit der Begründung, Conways These sei "nicht hinreichend belegt". Erschien stattdessen 1968 in Datamation und wurde durch Fred Brooks' The Mythical Man-Month (1975) als "Conway's Law" zum geflügelten Wort.

Mehr dazu: Inverse Conway Maneuver — Teams bewusst so strukturieren, dass die gewünschte Architektur entsteht.

Team Topologies

Was es ist: Methodik zur Gestaltung von Software-Teams in vier Typen (Stream-aligned, Enabling, Complicated-Subsystem, Platform) mit drei Interaktionsmodi.

Wozu: Macht Conway's Law gestaltbar statt nur diagnostisch.

Mehr dazu: Skelton & Pais (2019).

Architektur — Pattern und Stile

Hexagonal Architecture (Ports & Adapters)

Was es ist: Architekturstil, bei dem die Kerndomäne von allen technischen Details (Datenbank, UI, externe Dienste) durch klar definierte "Ports" (Schnittstellen) und "Adapter" (Implementierungen) isoliert ist.

Wozu: Domänenlogik bleibt testbar und unabhängig von Frameworks.

Nicht zu verwechseln mit: Clean Architecture (Robert C. Martin, gleiche Grundidee, andere Akzente) und Onion Architecture (Jeffrey Palermo, ebenfalls verwandt).

Mehr dazu: Cockburn (2005).

CQRS (Command Query Responsibility Segregation)

Was es ist: Trennung von Schreiboperationen (Commands) und Leseoperationen (Queries) in separate Modelle.

Wozu: Lesen und Schreiben haben oft sehr unterschiedliche Anforderungen (Skalierung, Modellierung) — getrennt lassen sie sich getrennt optimieren.

Nicht zu verwechseln mit: Event Sourcing (Speichern als Event-Strom, oft kombiniert mit CQRS, aber unabhängig).

Wichtig zur Namensherkunft: Erweiterung von Bertrand Meyers älterem CQS-Prinzip (Command-Query Separation, in Object-Oriented Software Construction, 1988): Eine Methode soll entweder den Zustand ändern oder einen Wert zurückgeben, nie beides. CQRS hebt dieses Prinzip von der Methoden- auf die Architekturebene und wurde ab ~2010 von Greg Young geprägt.

Event-Driven Architecture

Was es ist: Architekturstil, bei dem Komponenten asynchron über Ereignisse kommunizieren statt synchroner direkter Aufrufe.

Wozu: Lose Kopplung, bessere Skalierbarkeit, natürliche Auditierbarkeit.

Modular Monolith

Was es ist: Einzelne deploybare Anwendung, intern aber strikt nach Domänen modularisiert mit klaren Schnittstellen.

Wozu: Vorteile der Modularisierung ohne Komplexität verteilter Systeme — oft die richtige Antwort statt "gleich Microservices".

Microservices

Was es ist: Architekturstil, der eine Anwendung als Sammlung kleiner, unabhängig deploybarer Dienste umsetzt.

Wozu: Unabhängige Skalierung und Entwicklung, technologische Heterogenität.

Faustregel: Sinnvoll erst ab erheblicher Team- und Domänen-Komplexität — sonst überwiegen die Kosten verteilter Systeme.

Verteilter Monolith

Was es ist: Antipattern — Microservices-Topologie, deren Dienste so eng gekoppelt sind, dass sie nur gemeinsam änder- und deploybar sind.

Wozu: Negativ-Beispiel: Komplexität verteilter Systeme ohne deren Vorteile.

Domain-Driven Design (DDD)

Was es ist: Methodik, bei der die fachliche Domäne das primäre Designartefakt ist; entwickelt eine gemeinsame Sprache (Ubiquitous Language) und schneidet das System entlang fachlicher Grenzen (Bounded Contexts).

Wozu: Macht komplexe Geschäftslogik beherrschbar, gibt klare Service-Schnittgrenzen.

Wichtig zur Namensherkunft: Eric Evans prägte den Begriff in seinem Buch Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) — in der Community schlicht "das Blue Book" wegen des Coverdesigns. Vaughn Vernons spätere Vertiefung Implementing Domain-Driven Design (2013) heißt analog "das Red Book".

Mehr dazu: Evans (2003); Vernon (2013) für die strategische Vertiefung.

Bounded Context

Was es ist: Klar abgegrenzter fachlicher Bereich mit eigenem konsistenten Modell und eigener Sprache.

Wozu: Vermeidet, dass ein "Kunde" für Vertrieb dasselbe meint wie für Buchhaltung — was er fast nie tut.

Mehr dazu: Kernkonzept des strategischen DDD.

Anämisches Domänenmodell

Was es ist: Antipattern — Domänenobjekte enthalten nur Daten (Getter/Setter), Verhalten liegt in separaten Service-Klassen.

Wozu: Negativ-Beispiel — verstößt gegen die DDD-Idee, dass fachliches Verhalten zur Domäne gehört.

Mehr dazu: Martin Fowler, "AnemicDomainModel" (2003).

Architektur — Methoden und Werkzeuge

ATAM (Architecture Tradeoff Analysis Method)

Was es ist: Strukturierte Methode zur Architekturbewertung anhand priorisierter Qualitätsattribute und ihrer Wechselwirkungen.

Wozu: Macht Architektur-Trade-offs (z.B. Performance vs. Sicherheit) explizit verhandelbar.

Wichtig zur Namensherkunft: Architecture Tradeoff Analysis Method, entwickelt am SEI (Carnegie Mellon) als Nachfolger von SAAM (Software Architecture Analysis Method, 1994). Das Tradeoff im Namen ist programmatisch: Die Methode geht davon aus, dass Architektur immer aus Kompromissen zwischen konkurrierenden Qualitätszielen besteht.

Mehr dazu: Kazman, Klein & Clements (SEI, 2000).

Architecture Decision Record (ADR)

Was es ist: Kurzes, versioniertes Markdown-Dokument im Repo, das eine einzelne Architekturentscheidung mit Kontext, Optionen, gewählter Lösung und Konsequenzen festhält.

Wozu: Macht das Warum von Architektur nachvollziehbar — das wertvollste Wissen, das sonst beim Personalwechsel verloren geht.

Mehr dazu: Michael Nygard, "Documenting Architecture Decisions" (2011).

Fitness Function

Was es ist: Automatisierter Test, der eine Architektur-Eigenschaft prüft (Schichtentrennung, Performance-Budget, Komplexitätsgrenzen, Abhängigkeitsregeln).

Wozu: Macht Architektur durchsetzbar statt nur dokumentiert. Im CI integriert wird sie zum Sicherheitsnetz gegen architekturelle Erosion.

Mehr dazu: Ford, Parsons & Kua (2017), Building Evolutionary Architectures.

ArchUnit

Was es ist: Java-Library, mit der man Architekturregeln als Unit-Tests formuliert (z.B. "Klassen in domain dürfen nicht von infrastructure abhängen").

Wozu: Konkrete Implementierung von Fitness Functions auf Code-Ebene.

Verwandt: NetArchTest (.NET), dependency-cruiser (JS/TS), Sonargraph, NDepend.

C4-Modell

Was es ist: Notations-Framework von Simon Brown für Architekturdiagramme auf vier Detailstufen: Context, Containers, Components, Code.

Wozu: Bringt Konsistenz in Architekturdokumentation; vermeidet die übliche Mischung aus inkohärenten "Boxen-und-Pfeile"-Diagrammen.

Mehr dazu: c4model.com; Structurizr als zugehöriges Werkzeug.

Prozess und DevOps

DORA-Metriken

Was es ist: Vier wissenschaftlich validierte Kennzahlen für Software-Lieferleistung — Deployment Frequency (wie oft wird produktiv deployed), Lead Time for Changes (Zeit von Commit bis Produktion), Change Failure Rate (Anteil defekter Releases), Mean Time to Recovery / MTTR (Zeit bis zur Wiederherstellung nach Ausfall). Seit 2021 wird in den Reports zusätzlich Reliability als fünfte Metrik geführt; durchgesetzt haben sich aber die ursprünglichen vier.

Wozu: Empirisch belegt: bessere Werte korrelieren mit besserer Geschäftsleistung. Standard-Benchmark zur Einordnung von Teams (Elite / High / Medium / Low).

Wichtig zur Namensherkunft: DORA steht für DevOps Research and Assessment — den Namen der Forschungsgruppe um Nicole Forsgren, Jez Humble und Gene Kim, die ab 2014 jährlich den State of DevOps Report herausgab und 2018 von Google übernommen wurde. Das Akronym bezeichnet nicht die Metriken selbst — ein häufiges Missverständnis, das auch in der Literatur regelmäßig auftaucht.

Mehr dazu: Forsgren, Humble & Kim (2018), Accelerate; jährlicher State of DevOps Report.

Trunk-Based Development

Was es ist: Branching-Modell, bei dem alle Entwickler in kurzen Zyklen direkt auf einen Hauptzweig (Trunk) committen.

Wozu: Vermeidet Merge-Hölle langlebiger Feature-Branches; Voraussetzung für hohe DORA-Werte.

Nicht zu verwechseln mit: GitFlow (langlebige Feature-Branches, heute meist überholt).

TDD (Test-Driven Development)

Was es ist: Praxis, bei der Tests vor der Implementierung geschrieben werden (Red-Green-Refactor-Zyklus).

Wozu: Erzwingt testbares Design, gibt unmittelbares Feedback.

Wichtig zur Namensherkunft: Kent Beck beschreibt den Begriff selbst nicht als Erfindung, sondern als Wiederentdeckung einer Praxis aus den frühen NASA-Projekten der 1960er. Populär geworden ist TDD durch Becks Buch Test-Driven Development by Example (2002) im Kontext von Extreme Programming (XP).

Mehr dazu: Kent Beck, Test-Driven Development by Example (2002).

BDD (Behavior-Driven Development)

Was es ist: Erweiterung von TDD, bei der Tests in fachsprachlicher Form (Given-When-Then, oft mit Gherkin-Syntax) formuliert werden.

Wozu: Brücke zwischen Fachseite und Entwicklung; Tests sind gleichzeitig Spezifikation.

Wichtig zur Namensherkunft: Geprägt 2003 von Dan North als Reaktion auf eine wiederkehrende Beobachtung beim TDD-Coaching: Entwickler verstanden das Wort "Test" zu eng (technische Prüfung) und übersahen die Designwirkung. Norths Lösung: Statt "Test" das Wort Behavior — und plötzlich ergab sich der ganze TDD-Workflow für die Lernenden von selbst. BDD ist also weniger eine neue Methode als eine Umformulierung mit anderem mentalen Modell.

Werkzeuge: Cucumber, SpecFlow, behave.

Mutation Testing

Was es ist: Verfahren zur Qualitätssicherung der Tests selbst: Es werden gezielt kleine Code-Mutationen eingeschleust ("Bugs"); überleben sie die Test-Suite, sind die Tests zu schwach.

Wozu: Deckt schwache Tests auf, die zwar grün sind, aber nichts wirklich prüfen — besonders wichtig bei KI-generiertem Code, wo Tests oft koexistieren mit dem geprüften Code.

Werkzeuge: Stryker (JS/.NET), PIT (Java), mutmut (Python).

Property-based Testing

Was es ist: Test-Verfahren, bei dem nicht konkrete Beispiele, sondern Eigenschaften definiert werden, die für alle gültigen Eingaben gelten müssen — das Framework generiert dann hunderte/tausende Testfälle.

Wozu: Findet Edge Cases, an die niemand gedacht hätte.

Werkzeuge: Hypothesis (Python), fast-check (JS/TS), jqwik/Junit-Quickcheck (Java), QuickCheck (Haskell — die Urquelle).

Contract Testing

Was es ist: Test-Strategie für verteilte Systeme: Konsumenten und Anbieter eines API einigen sich auf einen Vertrag und testen unabhängig dagegen.

Wozu: Macht Integrationsprobleme früh sichtbar, ohne bei jedem Test alle Dienste hochfahren zu müssen.

Werkzeuge: Pact, Spring Cloud Contract.

Observability

Was es ist: Eigenschaft eines Systems, aus seinen Außen-Signalen (Logs, Metrics, Traces) auf den inneren Zustand schließen zu können.

Wozu: Voraussetzung für effektive Fehlersuche in verteilten Systemen.

Nicht zu verwechseln mit: Monitoring (kontinuierliche Überwachung bekannter Größen — Observability ermöglicht das Aufdecken unbekannter Probleme).

Werkzeuge: OpenTelemetry (Standard), Grafana, Prometheus, Honeycomb, Datadog.

Service Level Objective (SLO) / Error Budget

Was es ist: SLO ist ein internes Verfügbarkeits-/Latenzziel (z.B. "99,9% Verfügbarkeit über 30 Tage"). Das Error Budget ist der erlaubte Rest (0,1%).

Wozu: Macht den Trade-off zwischen Stabilität und Innovationstempo verhandelbar — solange Budget übrig ist, dürfen Risiken eingegangen werden.

Nicht zu verwechseln mit: SLA (Service Level Agreement — vertragliche Zusicherung gegenüber Kunden, üblicherweise schwächer als das interne SLO).

Wichtig zur Namensherkunft: Die Akronymfamilie kommt aus der SRE-Tradition bei Google: SLI (Service Level Indicator — die Messgröße, z.B. Latenz), SLO (Service Level Objective — das interne Ziel auf der Messgröße), SLA (Service Level Agreement — die externe vertragliche Zusicherung). Faustregel von Google SRE: SLA ist immer schwächer als SLO, weil ein verfehltes SLO intern alarmiert, bevor das SLA gerissen wird.

Mehr dazu: Beyer et al. (2016), Site Reliability Engineering.

Infrastructure as Code (IaC)

Was es ist: Beschreibung von Servern, Netzwerken, Cloud-Ressourcen als versionierter Code statt manueller Konfiguration.

Wozu: Reproduzierbarkeit, Audit-Trail, automatisiertes Deployment.

Werkzeuge: Terraform, Pulumi, Crossplane, AWS CDK.

Platform Engineering / Internal Developer Platform (IDP)

Was es ist: Disziplin, die Entwicklerteams eine interne Plattform mit Self-Service-Zugriff auf Infrastruktur, CI/CD und Standards bereitstellt.

Wozu: Reduziert kognitive Last bei Entwicklerteams, standardisiert ohne zu zentralisieren.

Werkzeuge: Backstage (Spotify, jetzt CNCF), Port, Cortex.

Blameless Postmortem

Was es ist: Vorfall-Analyse, die systemische Ursachen sucht statt individuelle Schuld zuzuweisen.

Wozu: Voraussetzung dafür, dass Menschen ehrlich über Fehler sprechen — sonst werden sie versteckt.

Mehr dazu: John Allspaw, "Blameless PostMortems and a Just Culture" (2012).

Sicherheit

OWASP Top 10

Was es ist: Regelmäßig aktualisierte Liste der zehn häufigsten Web-Sicherheitslücken (Injection, Broken Access Control, etc.) der Open Worldwide Application Security Project Foundation.

Wozu: Mindeststandard für Security-Awareness von Entwicklerteams.

Verwandt: OWASP Top 10 for LLM Applications (seit 2023, deckt KI-spezifische Risiken ab).

Wichtig zur Namensherkunft: Open Worldwide (früher: Web) Application Security Project — gemeinnützige Stiftung, gegründet 2001. Die Umbenennung von "Web" zu "Worldwide" 2023 reflektiert die Ausweitung über klassische Web-Sicherheit hinaus (Mobile, IoT, LLMs). OWASP-Materialien sind grundsätzlich unter freien Lizenzen verfügbar — daher der De-facto-Standard-Status.

Threat Modeling

Was es ist: Strukturierte Bedrohungsanalyse vor oder während der Implementierung — welche Angreifer, welche Angriffsvektoren, welche Gegenmaßnahmen?

Wozu: Verhindert, dass Sicherheit erst beim Pen-Test "gefunden" wird.

Methoden: STRIDE (Microsoft, 6 Bedrohungskategorien), LINDDUN (Privacy-Pendant), PASTA.

Wichtig zur Namensherkunft: STRIDE ist ein echtes Akronym mit jeweils einer Kategorie pro Buchstabe — Spoofing (Identitätsfälschung) · Tampering (Manipulation) · Repudiation (Abstreitbarkeit) · Information Disclosure (Informationsleck) · Denial of Service · Elevation of Privilege (Rechte-Eskalation). Entwickelt 1999 bei Microsoft. LINDDUN überträgt das Schema auf Privacy: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance.

Shift-Left

Was es ist: Prinzip, Qualitäts- und Sicherheitsprüfungen so früh wie möglich im Entwicklungsprozess durchzuführen statt am Ende.

Wozu: Spätere Defekte sind exponentiell teurer zu beheben.

SBOM (Software Bill of Materials)

Was es ist: Maschinenlesbares Inhaltsverzeichnis aller Software-Bestandteile inklusive Versionen, Lizenzen und Abhängigkeiten.

Wozu: Voraussetzung für Schwachstellen-Management und Lizenz-Compliance.

Standards: SPDX, CycloneDX.

SLSA (Supply-chain Levels for Software Artifacts)

Was es ist: Reifegradmodell der Linux Foundation für die Vertrauenswürdigkeit der Software-Lieferkette (Stufen 1–4).

Wozu: Standardisiert "wie sicher ist eigentlich der Bauprozess unserer Software?".

Wichtig zur Namensherkunft: Wird "salsa" ausgesprochen — bewusst gewählt, weil das Akronym sich ansonsten kaum aussprechen lässt. Initiiert 2021 von Google nach den großen Supply-Chain-Angriffen (SolarWinds 2020, Log4j 2021), inzwischen unter Schirmherrschaft der OpenSSF (Open Source Security Foundation) bei der Linux Foundation.

Mehr dazu: slsa.dev.

KI-spezifische Begriffe

AI-Driven Development / KI-augmentierte Entwicklung

Was es ist: Sammelbegriff für Entwicklungsworkflows, bei denen LLM-basierte Werkzeuge (Copilot, Cursor, Claude Code, Aider) substantielle Anteile am Codieren, Refactoring oder Reviewen übernehmen.

Wozu: Beschreibt den Paradigmenwechsel, ohne festzulegen, wie die Aufteilung Mensch/KI aussieht.

Verwandt: Vibe Coding (siehe unten) als ein Modus davon.

Vibe Coding

Was es ist: Begriff von Andrej Karpathy (2025) für intuitives, flow-haftes Generieren mit KI ohne strenge Spec — der Entwickler beschreibt informell, was er möchte, und prüft das Ergebnis pragmatisch.

Wozu: Beschreibt einen real existierenden Modus (Prototyping, Exploration); didaktisch nützlich als Negativ-Folie für Spec-Driven Development.

Nicht zu verwechseln mit: Spec-Driven Development (das gegenteilige Pol auf der Spektrum).

Wichtig zur Namensherkunft: Karpathy (Mitgründer von OpenAI, ehemals Tesla AI) prägte den Begriff in einem viralen Tweet im Februar 2025: er beschrieb darin sein eigenes Coden mit Cursor/Claude als "I just see things, say things, run things, and copy-paste things, and it mostly works" — explizit als nicht-rigorose Praxis für Wegwerf-Code, die dann unerwartet schnell als Sammelbegriff für ein ganzes Phänomen breitenwirksam wurde.

Spec-Driven Development

Was es ist: Ansatz, bei dem die Spezifikation (Anforderungen, Akzeptanzkriterien, Constraints) das primäre Artefakt ist, aus dem Code abgeleitet wird — auch und gerade von KI-Werkzeugen.

Wozu: In der KI-Ära ist die Spec der eigentliche Engpass; präzise Spec → präziser generierter Code.

Kontext-Engineering

Was es ist: Disziplin, Coding-Agenten den richtigen projektspezifischen Kontext (Konventionen, verbotene Patterns, Architekturprinzipien) bereitzustellen — typischerweise über Dateien wie AGENTS.md, CLAUDE.md, .cursorrules.

Wozu: Ohne Kontext erfindet jedes Modell jedes Mal neu; mit Kontext bleibt Code konsistent.

Hinweis: Eng verwandt mit Prompt Engineering, aber bezogen auf langlebige Projekt-Kontexte statt Einzel-Prompts.

Halluzination (im KI-Kontext)

Was es ist: Plausibel klingender, aber faktisch falscher Output eines LLM — z.B. erfundene Funktionen, nicht existierende Pakete, ausgedachte API-Signaturen.

Wozu (zu wissen): Halluzinationen sind kein Bug, sondern ein strukturelles Merkmal von Sprachmodellen — der ganze Verifikations-Stack der Säule 4 baut darauf auf, dass sie auftreten.

Slopsquatting

Was es ist: Angriffsklasse, bei der Angreifer Pakete unter Namen registrieren, die LLMs häufig erfinden — wer den KI-Vorschlag naiv installiert, bekommt Schadcode.

Wozu (zu wissen): Zentrales Beispiel, warum KI-generierter Code gegen halluzinierte Dependencies geprüft werden muss.

Wichtig zur Namensherkunft: Kofferwort aus AI slop (abwertend für minderwertigen KI-Output) und typosquatting (klassischer Angriff: Pakete unter ähnlich klingenden Namen wie populäre registrieren). Geprägt 2024 von Seth Larson (Python Software Foundation), populär gemacht durch Simon Willisons Blog. Die Wortbildung ist programmatisch — typosquatting nutzt menschliche Tippfehler, slopsquatting nutzt KI-Halluzinationen als systematische Angriffsfläche.

Mehr dazu: ab 2024 dokumentiert, u.a. Simon Willison, Lazar et al.

Prompt Injection

Was es ist: Angriffsklasse, bei der externe Eingaben (Web-Inhalte, Dokumente, E-Mails), die ein KI-Agent verarbeitet, versteckte Anweisungen enthalten, die das Modell umsteuern.

Wozu (zu wissen): Sobald Agenten autonom externe Inhalte konsumieren, ist Prompt Injection das Pendant zu klassischem Code Injection.

Mehr dazu: OWASP Top 10 for LLM Applications, LLM01.

AGENTS.md / CLAUDE.md

Was es ist: Konvention für Markdown-Dateien im Projekt-Root, in denen Architekturprinzipien, Codestil, verbotene Pattern und projektspezifische Hinweise für Coding-Agenten festgehalten werden. AGENTS.md als herstellerübergreifender Quasi-Standard, CLAUDE.md für Anthropic Claude Code, .cursorrules für Cursor, copilot-instructions.md für GitHub Copilot.

Wozu: Verhindert, dass jeder Entwickler im Team ein anderes Verständnis "von der KI bekommt".

Skill-Atrophie

Was es ist: Schleichender Verlust grundlegender Fähigkeiten durch dauerhafte Auslagerung an Werkzeuge — in der KI-Debatte besonders relevant für Junior-Entwickler, die "die schweren Stellen" nie selbst durchdenken.

Wozu (zu wissen): Der vielleicht wichtigste blinde Fleck moderner Qualitätsmodelle.

Verwandt: Desirable Difficulty (Bjork) — produktive Anstrengung als Lernverstärker.

NIST AI Risk Management Framework (AI RMF)

Was es ist: Rahmenwerk des US-amerikanischen NIST (2023), das Risiken beim Einsatz von KI-Systemen systematisch erfasst (Govern, Map, Measure, Manage).

Wozu: De-facto-Referenz für KI-Risikomanagement; Grundlage vieler Compliance-Frameworks.

Mehr dazu: NIST AI 100-1.

---

Literaturverzeichnis

Säule 1 — Produktqualität

• McCall, J. A., Richards, P. K., & Walters, G. F. (1977). Factors in Software Quality (Vols. 1–3). Rome Air Development Center / General Electric.
• Boehm, B. W., Brown, J. R., & Lipow, M. (1978). Quantitative evaluation of software quality. In Proceedings of the 2nd International Conference on Software Engineering (S. 592–605).
• Grady, R. B., & Caswell, D. L. (1987). Software Metrics: Establishing a Company-Wide Program. Prentice Hall. (Ursprung von FURPS)
• ISO/IEC 9126 (1991/2001). Software engineering — Product quality. (Vorgänger von 25010, abgelöst.)
• ISO/IEC 25010 (2011, Revision 2023). Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models.

Säule 2 — Strukturqualität / Architektur

• Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058.
• Shaw, M., & Garlan, D. (1996). Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall.
• Bass, L., Clements, P., & Kazman, R. (2021). Software Architecture in Practice (4. Aufl.). Addison-Wesley. (Erstauflage 1998)
• Kazman, R., Klein, M., & Clements, P. (2000). ATAM: Method for Architecture Evaluation (CMU/SEI-2000-TR-004). Software Engineering Institute.
• Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
• Cockburn, A. (2005). Hexagonal Architecture (Ports and Adapters). Online-Publikation.
• Ford, N., Parsons, R., & Kua, P. (2017). Building Evolutionary Architectures. O'Reilly. (Fitness Functions)
• Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution.
• Starke, G. (2024, 9. Aufl.). Effektive Softwarearchitekturen: Ein praktischer Leitfaden. Hanser.
• iSAQB (laufend). Lehrplan Foundation Level / Advanced Level. International Software Architecture Qualification Board.

Säule 3 — Prozessqualität

• Deming, W. E. (1986). Out of the Crisis. MIT Press.
• Humphrey, W. S. (1989). Managing the Software Process. Addison-Wesley.
• Dunn, R. H. (1990). Software Quality: Concepts and Plans. Prentice Hall.
• Paulk, M. C., Curtis, B., Chrissis, M. B., & Weber, C. V. (1993). Capability Maturity Model for Software, Version 1.1 (CMU/SEI-93-TR-024). SEI. (Begründung CMM/CMMI-Linie)
• ISO/IEC 15504 (2003 ff., später ersetzt durch ISO/IEC 33000-Reihe). Process assessment (SPICE).
• VDA QMC (laufend). Automotive SPICE Process Assessment / Reference Model.
• Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Hrsg.) (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution. (DORA-Metriken)
• DORA / Google Cloud (jährlich). State of DevOps Report.

Säule 4 — KI-augmentierter Entwicklungsprozess

Diese Säule stützt sich überwiegend auf Praktiker- und Industriepublikationen, da kanonische Lehrbuchliteratur erst im Entstehen ist.

• NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.
• OWASP (2023, laufend aktualisiert). Top 10 for Large Language Model Applications.
• SLSA (laufend). Supply-chain Levels for Software Artifacts. https://slsa.dev
• Karpathy, A. (2025). Public statements zum Konzept "Vibe Coding". (Twitter/X, Februar 2025)
• Willison, S. (laufend). Blog-Reihe zu LLM-gestützter Entwicklung, u.a. zum Begriff Slopsquatting. https://simonwillison.net
• Lazar, S. et al. (2024). Untersuchungen zu Package-Halluzination und Slopsquatting in LLM-generierten Code-Vorschlägen. (Industrie- und Konferenzpublikationen)
• Böckeler, B., & Fowler, M. et al. (laufend). thoughtworks-Publikationen zu Generative AI in Software Engineering. https://martinfowler.com/articles/
• GitHub (laufend). Dokumentation zu Copilot Workspace, Custom Instructions, copilot-instructions.md.
• Anthropic (laufend). Dokumentation zu Claude Code, CLAUDE.md, MCP. https://docs.claude.com
• Spec-Driven Development: aktuelle Diskurslage in den Communities um Cursor, Aider, Claude Code; noch keine kanonische Primärquelle.
• Ford, N. et al. (2017) — siehe Säule 2; relevant als Brücke zur architekturellen Governance autonomer Agenten.

Sekundärquelle / didaktische Aufbereitung im deutschsprachigen Raum

• Tielke, D. (laufend). Workshops, Webcasts, dotnetpro-Beiträge zu Softwarequalität, Architektur und Composite Components. https://www.david-tielke.de — vermittelt die Drei-Säulen-Sicht in der iSAQB-/Starke-Tradition für ein deutschsprachiges Praktiker-Publikum.

---

Stand: Mai 2026. Bei den Standards (ISO/IEC, NIST, OWASP) und den Industrie-Reports (DORA) jeweils die aktuelle Fassung konsultieren.