Nachvollziehbare Arbeitsaufteilung
Jede Implementierungsaufgabe ist mit einer konkreten Anforderung oder einem Akzeptanzkriterium verknüpft — nicht mit einer lose verwandten Funktionsbeschreibung.
Entwicklung & Integration · Schritt 04 · Wie wir arbeiten
Eine Spezifikation wird zu Software.
Das Solution Design liefert eine getestete Spezifikation und festgelegte Akzeptanzkriterien. In dieser Phase wird diese Spezifikation in funktionierende, verifizierte Software überführt — integriert mit den Systemen, neben denen sie betrieben werden muss, und gegenüber den vor der Entwicklung definierten Kriterien nachgewiesen.
Entwicklung ist hier keine Interpretation. Jede Implementierungsentscheidung lässt sich auf eine während des Designs erstellte Spezifikation zurückführen — nicht auf das, was ein Entwickler vermutlich als Absicht angenommen hat.
Nicht diese Frage
"Läuft der Code?"
Stattdessen diese Frage
"Erfüllt das erstellte System die vor Beginn definierten Akzeptanzkriterien — unter realen Integrationsbedingungen und nicht nur isoliert?"
Implementierung · Verifikation · Integration · Rückverfolgbarkeit · Lieferdisziplin
Warum Entwicklung dem Design folgt
Hier ist nichts dem Zufall überlassen.
Jeder Input für diese Phase wurde während des Solution Designs erstellt: das Lösungs-Spezifikationsdokument, der Prototyp-Evaluationsbericht und die Akzeptanzkriterien & der Testplan. Entwicklung anhand einer ungetesteten Spezifikation würde das Risiko, das durch das Prototyping abgebaut werden sollte, einfach zurück in den Produktionscode verlagern.
Lösungsspezifikation + Akzeptanzkriterien → Verifizierte Implementierung
Warum Lieferdisziplin wichtig ist
Geschwindigkeit und Stabilität werden gemeinsam gemessen, nicht gegeneinander ausgespielt.
Die Leistungsfähigkeit bei der Softwareauslieferung bemisst sich nicht allein daran, wie schnell ein Team Code schreibt. Forschung von Forsgren, Humble und Kim — veröffentlicht in Accelerate: The Science of Lean Software and DevOps (2018), basierend auf dem mehrjährigen Forschungsprogramm DevOps Research and Assessment (DORA) über tausende Organisationen — identifizierte zwei Kategorien technischer Leistungskennzahlen, die gemeinsam gemessen werden müssen: Durchsatz und Stabilität.
Durchlaufzeit
Wie lange es dauert, bis eine validierte Änderung vom Commit in einen bereitstellbaren Zustand gelangt.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps-Forschung.
Fehlerquote bei Änderungen
Der Prozentsatz der Änderungen, die einen Defekt einführen, der eine Behebung erfordert.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps-Forschung.
Ein Team, das schnell ausliefert, aber häufig Dinge kaputt macht, erzielt laut dieser Forschung keine gute Leistung — ebenso wenig wie ein Team, das sicher ausliefert, aber zu langsam ist, um relevant zu sein. OpenQCore berücksichtigt in dieser Phase beide Dimensionen, statt nur die Geschwindigkeit zu optimieren.
Von der Spezifikation zur Implementierung
Jeder Arbeitsschritt lässt sich auf eine Anforderung zurückführen.
Implementierungsarbeit wird direkt aus der Lösungsspezifikation und den Akzeptanzkriterien abgeleitet — nicht aus einem allgemeinen Verständnis dessen, "worauf das Design hinauswollte."
Definition von 'Done'
Eine Aufgabe ist nicht dann abgeschlossen, wenn der Code geschrieben ist. Sie ist abgeschlossen, wenn sie das verknüpfte Akzeptanzkriterium unter Testbedingungen erfüllt.
Kontrolle der Spezifikationsdrift
Wenn die Implementierung eine Lücke oder Unklarheit in der Spezifikation aufdeckt, wird die Spezifikation aktualisiert und überprüft — nicht stillschweigend von der Person neu interpretiert, die an jenem Tag den Code schreibt.
Testgetriebene Verifizierung
Verifikation erfolgt auf jeder Ebene, nicht nur am Ende.
OpenQCore strukturiert die Verifikation gemäß der Testpyramide — ein weithin verwendetes Konzept, popularisiert von Mike Cohn, das darauf abzielt, die Testabdeckung über die Schichten eines Systems zu verteilen, anstatt sie in langsamen, teuren End-to-End-Tests zu konzentrieren.
Unit-Tests
Schnelle, isolierte Überprüfung einzelner Komponenten gegenüber ihrem spezifizierten Verhalten — einschließlich ihres Verhaltens bei ungültigen Eingaben.
Integrationstests
Überprüfung, dass Komponenten gemäß den während des Lösungsdesigns definierten Datenverträgen korrekt interagieren.
End-to-End-Tests
Überprüfung kompletter Arbeitsabläufe anhand der vor Entwicklungsbeginn definierten Akzeptanzkriterien — die kleinste, teuerste Ebene, reserviert für das, was dies wirklich erfordert.
Das Ziel ist nicht eine maximale Anzahl von Tests. Es ist das Vertrauen darin, dass die Akzeptanzkriterien tatsächlich erfüllt sind — auf der kostengünstigsten Ebene, die dies beweisen kann.
Integrations- und Vertragstests
Ein API-Vertrag ist nur dann real, wenn er getestet wird, nicht nur dokumentiert.
Die während des Lösungsdesigns festgelegten Daten- und API-Verträge werden nicht als informell zu befolgende Dokumentation behandelt. OpenQCore wendet consumer-driven contract testing an — einen Ansatz, der in Werkzeugen wie Pact formalisiert ist — bei dem jeder Integrationspunkt gegen einen ausführbaren Vertrag verifiziert wird, den beide Seiten der Integration erfüllen müssen.
Das ist besonders wichtig für Systeme, die sich an bestehende Infrastruktur anschließen müssen: Ein Vertrag, der nur durch manuelle Überprüfung geprüft wird, kann stillschweigend abdriften, wenn sich eine der Seiten ändert. Ein automatisch getesteter Vertrag kann das nicht.
Code-Review & statische Verifikation
Ein zweiter Prüfer entdeckt, was der Autor nicht entdeckt.
Weit zitierte Forschung zur Peer-Code-Review — einschließlich der bei Cisco Systems durchgeführten Studie und popularisiert durch Cohen et al. in 'Best Kept Secrets of Peer Code Review' — fand heraus, dass die Effektivität von Reviews stark von Tempo und Umfang abhängt: Kleinere, häufigere Reviews ohne Zeitdruck entdecken deutlich mehr Fehler als große, schnell durchgeführte Reviews.
OpenQCore wendet strukturierte Code-Reviews neben automatisierter statischer Analyse an — Stil-, Komplexitäts- und bekannte-Schwachstellen-Scans — als dauerhafte Verifikationsschicht, nicht als optionale Höflichkeitsprüfung vor dem Merge.
Continuous-Integration-Pipeline
Jede Änderung wird automatisch auf die gleiche Weise verifiziert.
Commit → automatisierter Build → Unit- & Integrationstests → statische & Sicherheitsanalyse → Vertragsverifikation → bereit für die Bereitstellung.
Manuelle, inkonsistente Verifikation skaliert nicht und liefert kein verlässliches Signal dafür, ob eine Änderung tatsächlich sicher freigegeben werden kann — eine Entscheidung, die in der nächsten Phase, Deployment & Enablement, getroffen wird. Was diese Phase garantiert, ist, dass eine Änderung, die dieses Tor erreicht, bereits gegen denselben automatisierten Standard verifiziert wurde wie jede vorherige Änderung.
Sichere Entwicklungspraktiken
Sicherheit wird während der Entwicklung verifiziert, nicht nachträglich auditiert.
Die Entwicklungspraktiken von OpenQCore stimmen mit der Struktur überein, die im Secure Software Development Framework (SP 800-218) des NIST beschrieben ist — sie organisieren Sicherheitsaktivitäten rund um die Vorbereitung der Organisation, den Schutz der Software, die Produktion gut gesicherter Software und die Reaktion auf Schwachstellen.
Abhängigkeits- und Schwachstellenscanning
Automatisiertes Scannen von Drittanbieterabhängigkeiten auf bekannte Schwachstellen als Teil der Standard-Pipeline, nicht eine periodische manuelle Prüfung.
Bedrohungsmodellierung
Strukturierte Betrachtung, wie eine Komponente missbraucht werden könnte, basierend auf den während des Lösungsdesigns definierten Ausfallmodi.
Implementierung des Prinzips der geringsten Privilegien
Zugriffs- und Berechtigungsbereiche werden auf dem kleinstmöglichen Niveau implementiert, das die Spezifikation erfüllt — nicht auf dem breitesten, weil es bequemer wäre.
Das Verifizierungs-Gate für Integration
Ein Build ist nicht bereit, nur weil er kompiliert.
Jede Änderung muss ein definiertes Verifizierungs-Gate erreichen, bevor sie für die Bereitstellung in Betracht gezogen werden kann.
Bereit für die Bereitstellung
Alle Abnahmekriterien sind erfüllt und wurden durch automatisierte Tests, Vertragsprüfungen und Sicherheitsscans verifiziert.
Zurück zur Fehlerbehebung
Konkrete, identifizierte Fehler müssen behoben werden, bevor diese Änderung weitergeführt werden kann.
Zurück zum Entwurf
Die Implementierung hat gezeigt, dass die Spezifikation selbst unter realen Bedingungen nicht standhält — die richtige Reaktion ist, die Spezifikation zu überarbeiten, nicht sie durch Programmierarbeit zu umgehen.
Risiko eskalieren
Ein Sicherheits-, Compliance- oder Architektur-Risiko wurde identifiziert, das eine Entscheidung über die Zuständigkeit des Entwicklungsteams hinaus erfordert.
Eine Pipeline, die immer "Bereit für die Bereitstellung" erreicht, verifiziert nichts.
Was diese Phase produziert
Software, bereit für die Entscheidung zur Bereitstellung — noch nicht bereitgestellt.
Je nach Umfang des Engagements erzeugt diese Phase:
Verifizierte Codebasis
Implementierung, die zur Spezifikation rückverfolgbar ist und alle definierten Verifizierungsebenen besteht.
Bericht zur Testabdeckung
Ergebnisse von Unit-, Integrations- und End-to-End-Tests, die den Abnahmekriterien zugeordnet sind.
Vertragstest-Suite
Ausführbare Verifikation jedes während des Lösungsdesigns definierten Integrationspunkts.
Code-Review-Aufzeichnungen
Dokumentierte Überprüfungshistorie und Behebung aufgeworfener Probleme.
Ergebnisse des Sicherheitsscans
Befunde aus Abhängigkeits-, Schwachstellen- und statischer Analyse sowie deren Behebung.
CI-Pipeline-Dokumentation
Die automatisierte Verifizierungspipeline, die auf diese Änderung und jede folgende Änderung angewendet wird.
Von Entwicklung bis Bereitstellung & Aktivierung
Verifizierte Software ist noch keine Live-Software.
Entwicklung & Integration erzeugt Software, die gegen ihre Spezifikation verifiziert wurde — nicht jedoch Software, die bereits freigegeben, überwacht oder unter realer Produktionslast als stabil erwiesen ist. Die nächste Phase regelt, wie, wann und wie sicher diese Software tatsächlich in die Produktion gelangt.
Lösungsspezifikation → Verifizierte Implementierung → Bereitstellung & Aktivierung
Schritt 05
Bereitstellung & Aktivierung
Verifizierte Software sicher, bewusst und mit einem definierten Rückrollpfad in die Produktion freigeben.
Forschungs- und methodische Referenzen
Forsgren, N., Humble, J. & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, DORA-Studie zum Stand von DevOps
Quelle der oben genannten Metriken zur Lieferleistung.
Cohn, M. — Succeeding with Agile (2009)
Quelle des in der testgetriebenen Verifizierung oben erwähnten Konzepts der Testpyramide.
Cohen, J. et al. — Best Kept Secrets of Peer Code Review (SmartBear, basierend auf Forschung bei Cisco Systems)
Quelle der oben genannten Erkenntnisse zur Wirksamkeit von Code-Reviews.
Pact / Consumer-Driven Contracts
Ein etabliertes Vorgehen für ausführbare, automatisch verifizierte Integrationsverträge, das im Abschnitt zu Integrationstests oben erwähnt wird.
NIST — Secure Software Development Framework, SP 800-218
Quelle der im Abschnitt zu sicheren Entwicklungspraktiken oben erwähnten Struktur.