Die Organisation muss sicherstellen, dass die Entwicklungsergebnisse für die sich anschließenden Prozesse zur Bereitstellung von Produkten und Dienstleistungen geeignet sind.
ISO 9001, Kapitel 8.3

Die Bereitstellung von Entwicklungsergebnissen ist eine große Herausforderung. Erst mit der kundenwirksamen Einführung eines neuen Produktes oder Aktualisierung eines bereits von Kunden genutzten Produktes wird unser Entwicklungsprozess abgeschlossen. Diesen Punkt erreichen wir nur dann, wenn wir alle Schritte davor mit ausreichender Qualität abschließen können. Fehler in der Software, die bei der Einführung oder später im laufenden Betrieb auftreten, zwingen im besten Fall Nutzer dazu, einen Workaround zu finden und zu verwenden, bis der Fehler mit der nächsten Aktualisierung behoben wird. Im schlimmsten Fall jedoch führen Fehler zu Ausfällen in Produktionsprozessen des Kunden, mit damit verbundenen direkten oder indirekten finanziellen Verlusten.

Die Qualitätsmanagementnorm ISO 9001 (2015) fordert, dass jede Organisation sich kontinuierlich mit Fragen beschäftigt, wie sie die Kundenzufriedenheit auch in Zukunft steigern kann und was ihre Kunden sich in Zukunft von ihr erwarten. Die frühzeitige Erkennung von Fehlern ist notwendig, um ein hohes Maß an Kundenzufriedenheit zu erreichen und gleichzeitig die Kosten für die Entwicklung zu senken. Die Zehnerregel (englisch: rule of ten) sagt aus, dass sich die Fehlerkosten für einen nicht entdeckten Fehler von Stufe zu Stufe der Wertschöpfung um den Faktor 10 erhöhen. Je früher daher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies für die Organisation.

Software-Produktion lief viele Jahre lang in einem phasenorientierten Entwicklungsprozess ab. Ein Auftraggeber bestellt Software. Seinen Bedarf beschreibt er mit einem Lastenheft. Mit einem Pflichtenheft beschreibt ein Auftragnehmer seinen Lösungsvorschlag. Nach der Auftragserteilung erstellt der Auftragnehmer in einer Analysephase das Fachfeinkonzept, eine Konkretisierung des Pflichtenheftes. Jetzt arbeiten Auftraggeber und Auftragnehmer zusammen. Mit der Freigabe des Fachfeinkonzeptes startet die Entwicklungsphase, in welcher der Auftragnehmer die Software implementiert. Veränderungen in dieser Phase werden als “Change Requests” dokumentiert, vom Auftraggeber genehmigt, in das Fachfeinkonzept integriert und implementiert. Den Abschluss des Entwicklungsprozesses bildet die Abnahmephase. Hier überprüft der Auftraggeber das Entwicklungsergebnis, ob es mit dem Lösungsvorschlag aus den Eingabedokumenten, also dem Fachfeinkonzept inklusive aller genehmigten CR, übereinstimmt. Am Ende der Abnahmephase steht die kundenwirksame Einführung des Software-Produktes.

Mit dem Entstehen agiler Entwicklungsmethoden, allen voran Scrum, hat sich bei uns der Entwicklungsprozess radikal verändert. Mit dem Einsatz von Scrum akzeptiert ein Auftraggeber, dass der Entwicklungsprozess nicht vorhersehbar ist. Scrum ist disruptiv für jede Organisation. Neue Rollen wie Product-Owner oder Scrum-Master verdrängen bekannte Rollen, z.B. Project-Manager. Ein Scrum-Team ist in vielen Bereichen selbstbestimmt und interdisziplinär besetzt. Auch die Zusammenarbeit von Auftraggeber und Auftragnehmer muss anders gestaltet werden. Der Auftraggeber ist von Anfang bis Ende in die Gestaltung des Produktes involviert und besetzt als Product-Owner eine wichtige Rolle. Der Auftragnehmer darf sich konstruktiv einbringen und ist nicht festgezurrt in einem Korsett in Form eines frühzeitig erstellten Pflichtenheftes.

Ken Schwaber, Miterfinder von Scrum sagt:

« Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität. »

In diesem Satz steckt das Wort Qualität. Durch eine mit dem Scrum-Team abgestimmte Definition für ein “fertiges” Produkt (englisch: definition of done) wird sichergestellt, dass ein Entwicklungsergebnis nur dann akzeptiert wird, wenn das integrierte Produkt erfolgreich in einer genormten Testumgebung installiert und alle abnahmerelevanten Testfälle dort erfolgreich ausgeführt wurden. Genormt bedeutet in diesem Zusammenhang, dass eine erfolgreichen Ausführung in dieser Testumgebung den Schluß zulässt, dass damit auch eine Installation des bereitgestellten Produktes in der kundenwirksamen Zielumgebung möglich ist.

Moderne Software-Entwicklung erfährt gerade noch weitere disruptive Veränderungen. Mit dem Konzept eines “Microservice” wird eine große Aufgabe in kleine Teile zerlegt. Die Einführung eines IT-Systems wird mit Sicherheit nicht einfacher, wenn anstelle eines zentralen Applikationsservers viele verteilt laufende Prozesse installiert werden. Auch der Einsatz von “Cloud Computing” anstelle dedizierter Rechner im eigenen Rechenzentrum macht die Aufgabe eher komplizierter. Eine Abnahme eines Produktes durch den Auftraggeber als Grundvoraussetzung für die Bereitstellung der Software in der kundenwirksamen Zielumgebung erfordert daher neue Strategien.

Ein “Release Candidate” ist eine Zusammenstellung von Software-Komponenten, die  als Produkt durch einen Systemtest vollumfänglich und positiv geprüft wurden. Der Systemtest enthält Testfälle für alle angeforderten Funktionen des Systems und überprüft die Korrektheit der Ausführung “end to end”, d.h. Daten werden in den Eingangsschnittstellen eingespielt und die Datenverarbeitung an den Ausgangsschnittstellen anhand der Kriterien Vollständigkeit, Korrektheit und Rechtzeitigkeit überprüft.

Für die erfolgreiche Umsetzung der Strategie “Release Candidate” ist eine vollautomatische Installation der Software-Komponenten erforderlich. Die Grundlage dafür ist ein vollständiges Komponentenverzeichnis, also eine Liste der Komponenten mit ihrer exakten Version im Git-Repository. Die Liste wird automatisch in jener Testumgebung ermittelt, in welcher der Systemtest erfolgreich durchgeführt wurde.

Das bereitgestellte Produkt ist ein valider Kandidat für die Installation in der Zielumgebung des Auftraggebers. Die Installation basiert auf dem Komponentenverzeichnis und wird vollautomatisch durchgeführt. Die vollautomatisch Installation ist ein wichtiges Werkzeug, mit dem menschliches Versagen bei der Einführung des Produktes ausgeschlossen werden kann, wenn zuvor in der Testumgebung die korrekte Installierbarkeit überprüft wurde. Tritt trotz aller qualitätssichernden Maßnahmen ein schwerwiegender Fehler auf, kann der zuvor eingesetzte Kandidat wiederhergestellt werden.

Die Strategie “Canary Release” hat das Ziel, die Wirksamkeit einer neuen Software-Komponente auf eine zuvor informierte Nutzergruppe einzuschränken. Diese Nutzergruppe hat die Aufgabe, die alten und neuen Funktionen auf Herz und Nieren zu prüfen. Erst wenn diese Nutzergruppe grünes Licht gibt, kann die neue Software-Komponente für alle Nutzer eingeführt werden. Geht jedoch etwas schief, kann die bisher erfolgreich eingesetzte Software-Komponente wiederhergestellt werden. Der Schaden ist begrenzt, weil nur die bereits informierte Nutzergruppe vom Fehler betroffen war.

Jede Strategie muss durch die Software-Architektur ermöglicht werden, d.h. sie ist eine wichtige nicht funktionale Anforderung, die im Entwicklungsprozess zu berücksichtigen ist. Ein hoher Prozentsatz bei der Testabdeckung ist ebenfalls sehr wichtig, damit unerwünschte Seiteneffekte nach der Installation einer neuen Software-Komponente ausgeschlossen werden können. Eine umfangreiche Testpyramide ist trotzdem keine Garantie, dass Software fehlerfrei ist. Das ist nach Einschätzung der IT-Branche unmöglich. Es ist aber die Absicherung, die einem Auftraggeber die notwendige Sicherheit vermittelt, damit er sein Okay für die Einführung geben kann. Und eine Testabdeckung kann gemessen werden und bildet so eine objektive Metrik für die Qualität von Software.

In agilen Entwicklungsprozessen gibt es keinen linearen Ablauf von Phasen, sondern ein stetes Reagieren auf Erkenntnisse oder Probleme in einem festen Takt (z.B. Sprint in Scrum) und die kontinuierliche Verbesserung der Qualität des Produktes. Durch dokumentierte Information im Backlog, durch eine inkrementell erstellte Produktdokumentation und das Messen von Metriken der Software kann die Qualität der bereitgestellten Entwicklungsergebnisse vom Auftraggeber selbst beurteilt werden. Die letzte Hürde, die Freigabe der Software für die kundenwirksame Einführung, treffen wir immer zusammen mit unserem Auftraggeber.