UDD Phase 8 – Deployment

Der Begriff Deployment beschreibt die automatische Verteilung und Auslieferung der entwickelten Software. Im Optimalfall sollte die neu erstellte Funktion im Produktivsystem eingespielt werden. Dazu eignen sich beispielsweise Webanwendungen oder serverbasierte Systeme.

Das bringt den Vorteil, dass den Nutzern der Software Weiterentwicklungen sofort zur Verfügung stehen. Dies birgt jedoch trotz umfangreichen Test ein gewisses Risiko, dass Fehler in eine Produktivversion gelangen. Damit man dieses eingehen kann, muss die Möglichkeit bestehen, ein Deployment jederzeit einfach wieder rückgängig zu machen.

Bei Systemen die nicht serverbasiert arbeiten, oder Anwendungen bei denen ein sofortiges Einspielen der neu entwickelten Funktionen nicht erwünscht ist, sollte man das Deployment zumindest auf einem Testsystem vornehmen, um immer ein funktionierendes System mit der neuesten Softwareversion für Tests und Demonstrationen zur Verfügung zu haben.

UDD Phase 7 – Integration

Integration bedeutet das Zusammenführen des geänderten Quellcodes mit der Codebasis. Bevor dieser Schritt durchgeführt werden kann müssen alle Tests erfolgreich durchlaufen werden.

Als Werkzeug für die Integration sollte unbedingt eine Versionsverwaltung eingesetzt werden. Es ist ratsam zusätzlich zum Quellcode auch die in der Phase Modellierung eventuell erstellten Diagramme in die Versionsverwaltung eingecheckt werden.

Auch auf Werkzeuge die, automatisch bei jeder Softwareversion die in die Versionsverwaltung eingespielt wird alle Tests durchlaufen und einen Build anstoßen, sollte nicht verzichtet werden. Dadurch können Fehler wie, das vergessene Einchecken einer Datei in die Versionsverwaltung, leicht entdeckt werden.

UDD Phase 6 – Programmierung

In der Phase der Programmierung werden die Ergebnisse aus den vorherigen Phasen umgesetzt. Das zuvor gestaltete Userinterface wird implementiert, benötigte Klassen und Methoden geschrieben und Datenbankstrukturen entwickelt.

Es sollte hierbei immer die einfachste funktionierende Lösung implementiert werden (vgl. Das KISS-Prinzip). Die Programmierung ist abgeschlossen wenn alle Test fehlerfrei ausgeführt werden können. Nachdem alle Tests erfolgreich ausgeführt werden können, sollte der neu entwickelte Quellcode einem Refactoring unterzogen werden.

Bevor zur nächsten Phase übergegangen werden kann sollte überprüft werden, dass sowohl die in der vorherigen Phase entwickelten Tests, als auch die in dieser Phase entwickelten Klassen und Methoden ausreichend dokumentiert sind. 

UDD Phase 5 – Testdesign

Nachdem in der Phase der Modellierung die Einordnung der Funktionalität ins Gesamtsystem erfolgt ist, folgt die Entwicklung der Tests. Dabei werden alle auf der zu bearbeiteten Storycard beschriebenen Funktionalitäten in Form in Tests umgesetzt. So entsteht aus der Storycard, vom Kunden oder Geschäftsseite verfasst, eine ausführbare Spezifikation der Funktionalität (vgl. Test Driven Development). Ausnahmen bilden Storycards die sich ausschließlich mit Verbesserungen der Oberfläche beschäftigen und keine Funktionalität des Systems verändern. Diese können aus einem Usability Test hervorgegangen sein und sind eventuell nur schwer oder gar nicht maschinell testbar. Dann wird die Phase Testdesign übersprungen.

UDD Phase 4 – Modellierung

Nachdem die Oberfläche einer Funktion gestaltet ist, kann man sich den schwierigeren Dingen zuwenden. Die Phase Modellierung soll einen Überblick verschaffen, wie die neue Funktionalität in das Gesamtsystem integriert werden kann.

Welche Datenbankfelder werden benötigt, wo im Schichtenmodell soll die Funktion implementiert werden, welche Bibliotheksfunktionen können benutzt werden, welche Algorithmen sind am geeignetsten für das Problem? Diese Fragen sollten sich Entwickler stellen und beantworten.

Im Zweifelsfall sollte die Meinung von Kollegen eingeholt werden oder falls möglich ein Test entwickelt werden. Besonders bei Performancefragen kann ein Lasttest sehr aufschlussreich sein.

Es geht in dieser Phase nicht darum, die zu entwickelnde Funktionalität bis ins letzte Detail mit UML Diagrammen zu beschreiben. Diagramme sollten nur dort eingesetzt werden wo es Sinnvoll ist und dadurch Vorteile entstehen.