Veröffentlicht von Jens
am 27. Juni 2008
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.
Veröffentlicht von Jens
am 25. Juni 2008
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.
Veröffentlicht von Jens
am 26. Mai 2008
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.
Veröffentlicht von Jens
am 08. Mai 2008
Eine Usability Driven Development Iteration besteht aus folgenden Phasen:
Veröffentlicht von Jens
am 05. Mai 2008
Die technische Grundvorraussetzung für UDD ist, dass es sich bei der zu entwickelnden Software um eine Anwendungssoftware, mit einer grafischen Oberfläche, handelt. Für eine Hardwaresteuerung, ein Framework oder eine Software für den Batchbetrieb ist das Vorgehensmodell ungeeignet.
UDD setzt ein hohes fachliches Verständnis der Entwickler voraus, welches durch intensive Kommunikation mit dem Anwender geschaffen werden muss. Damit Entwickler sich auf Probleme der Geschäftslogik konzentrieren können, sollte die Entwicklung mit möglichst problemnahen Werkzeugen geschehen. Das kann durch selbstentwickelte Fachsprachen geschehen oder durch Frameworks, die entsprechende Funktionalitäten bereitstellen.
Damit UDD funktionieren kann, muss ein möglichst hoher Grad an Automatisierung in einem Projekt erreicht werden. Entwicklerdokumentation sollte aus dem Quelltext generiert werden. Quellcode und Dokumentation sollte mit Hilfe von Versionsverwaltung verwaltet werden. Das Deployment sollte möglichst mit einem Kommando durchgeführt werden. Dabei müssen sämtlich automatisierten Vorgänge zuverlässig wiederholbar und umkehrbar sein. In Pragmatic Project Automation von Mike Clark
werden viele Aspekte der Automatisierung beschrieben.
Veröffentlicht von Jens
am 30. April 2008
Die organisatorischen Vorraussetzungen für UDD sind im wesentlichen die gleichen wie bei Extreme Programming und werden ausführlich in Extreme Programming. Das Manifest (Kapitel 26 Xp in der Praxis)
und Extreme Programming planen (Kapitel 25 Geschäftsbeziehungen)
beschrieben.
Besonders hervorzuheben ist dabei, dass Kunden gerne Verträge mit genau fest geschriebenem Umfang haben möchten. Andererseits wollen Kunden aber auch Ihre Meinung ändern können.
Es ist vermutlich noch nie ein Softwareprojekt abgeschlossen worden, in dem sich die Anforderungen nicht im Verlauf der Entwicklung geändert haben.
UDD löst diesen Widerspruch, indem der Kunde bei Projektstart einen groben Plan für die weitere Entwicklung bekommt, seine Meinung aber bei jedem Planungsspiel ändern kann.
Veröffentlicht von Jens
am 29. April 2008
Usability Driven Development (UDD) ist ein Vorgehensmodell der Softwaretechnik das Usability in einen agilen Prozess einbindet.
Es soll Entwicklern ein Werkzeug an die Hand geben um Anwendungen in einem iterativen Entwicklungsprozess, auf die Anforderungen von Kunden maßzuschneidern. Dabei soll das System so schnell wie möglich in Produktion gehen und in kurzen Releasezyklen weiterentwickelt werden.
Das Vorbild hierfür ist Extreme Programming das um Elemente des User Centered Design erweitert wurde. Die Grundprinzipien des Vorgehensmodel sind das DRY und das KISS-Prinzip, die in jeder Phase konsequent verfolgt werden.
UDD wendet diese Prinzipien auf alle Aspekte eines Softwarepro jektes an, von grafischen Oberflächen, über Quellcodes und Dokumentation bis zu Verträgen mit Kunden.
