Usability Driven Development

Usability Driven Development (UDD) ist ein iterativer Entwicklungsprozess, der die Benutzbarkeit (Usability) eines Systems in den Mittelpunkt stellt. Das Vorbild für UDD, auch User Interface Driven Develpoment oder UI-First Software Development genannt, ist Extreme Programming, das um Elemente des User Centered Design erweitert wurde. Jede Iteration besteht beim UDD aus neuen Phasen:

  • Planungsspiel
  • Aufwandsabschätzung
  • Interface Design
  • Modellierung
  • Testdesign
  • Programmierung
  • Integration
  • Deployment
  • Usability Test 

Ablauf einer Iteration in UDD (jensjaeger.com)

Phase 1 - Planungsspiel: Die Entwicklung einer Software nach UDD beginnt mit einem Planungsspiel. Der Kunde oder ein Teammitglied der Geschäftsseite notiert alle Aufgaben die das System erfüllen soll in Form von Storycards. Diese Storycards werden nach Priorität sortiert und entsprechend dieser Reihenfolge entwickelt. Das Planungsspiel wird bei jeder Iteration wiederholt. Dadurch hat der Kunde in jeder Iteration die Möglichkeit, die Priorisierung zu ändern und völlig neue Storycards hinzuzufügen. Weitere Storycards kommen durch, im Verlauf der Entwicklung durchgeführte, Usability Tests hinzu. Diese müssen ebenfalls vom Kunden priorisiert werden.

Phase 2 - Aufwandsabschätzung: Jeder Entwickler übernimmt Storycards, die Arbeit bis zum nächsten Planungsspiel enthalten. Dabei wird die Aufwandsschätzung durch die Entwickler selbst vorgenommen. Nach jeder Iteration werden die Ist-Zeiten mit den geschätzten Soll-Zeiten verglichen. So entsteht im Verlauf des Projekts eine bessere Basis für weitere Schätzungen.

Phase 3 - Interface Design: Programmierung ist im Vergleich zum Oberflächendesign sehr aufwendig und nur schwer zu verändern. Daher wird im UDD zuerst die GUI einer Anwendung betrachtet. Die Oberfläche einer Software zu gestalten ist verhältnismäßig leicht. Eine Skizze auf einem Blatt Papier ist schnell angefertigt und einfach zu ändern. Ein anderer wichtiger Grund das Interface zuerst zu gestalten ist, dass die Oberfläche das ist, was die Anwender zu Gesicht bekommen. Mit einer Anwendungssoftware, die zwar über großartige Funktionen verfügt, aber eine unattraktive Oberfläche besitzt, wird man nur schwer Kunden gewinnen können.
Bei umfangreichen Oberflächenänderungen oder Erweiterungen sollte von der Möglichkeit Gebrauch gemacht werden, in die Phase Usability Test zu springen. So kann das entworfene Design geprüft und eventuell verbessert werden, bevor zu viel Arbeit investiert wurde.

Phase 4 - Modellierung: Nachdem die Oberfläche einer Funktion gestaltet ist, beginnt die Phase Modellierung. In ihr soll ein Überblick entstehen, 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 die Lösung des Problems? 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.

Phase 5 - Testdesign: Als nächste Phase folgt das Testdesign. Dabei werden alle auf der zu bearbeiteten Storycard beschriebenen Funktionalitäten in Form von Tests umgesetzt. So entsteht aus der Storycard eine ausführbare Spezifikation der Funktionalität. Ausnahmen bilden Storycards, die sichausschließ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.

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. Die Programmierung ist abgeschlossen, wenn alle Tests fehlerfrei ausgeführt werden können. Nach erfolgreichem Test sollte der neu entwickelte Quellcode einem Refactoring unterzogen werden.

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, dass 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.

Phase 8 - Deployment: Der Begriff Deployment beschreibt die automatische Verteilung und Auslieferung der entwickelten Software. Im Idealfall wird die neu erstellte Funktion im Produktivsystem eingespielt.
Das bringt den Vorteil, dass den Anwendern die Weiterentwicklungen sofort zur Verfügung stehen. Dies birgt jedoch trotz umfangreicher Tests das 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.
Ist eine sofortige Produktivschaltung eines neuen Releases nicht möglich oder nicht erwünscht, 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.

Phase 9 - Usability Test: Der Usability Test ist die letzte Phase einer UDD-Iteration. Dabei testet der Entwickler die neu implementierte Funktion gegen die Beschreibung derFunktionalität auf der Storycard.
Sollten hierbei trotz der ausgiebigen Tests Fehler gefunden werden, ist umgehend das vorhergegangene Deployment rückgängig zu machen und die Iteration mit dem Ziel der Fehlerbehebung neu zu durchlaufen. Im Normalfall sollte die Funktionalität gewährleistet sein.
Es wird jedoch oft der Fall eintreten, dass Ideen für die Verbesserung der gerade entwickelten Funktionalität oder einer anderen Funktion des Systems entstehen. Diese werden in Form von Storycards notiert und müssen vom Kunden beim nächsten Planungsspiel priorisiert werden.

Bewertung BQI Research

Usability Driven Development besitzt seine Stärken in den Bereichen Test (T) und Integration/Einführung (INT). Gut bis befriedigend ist die Methode auch beim Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), bei der Implementierung (IMP) und beim Projekt-Management (PM). Schwächen gibt es bei der Wartung (W), der Betrieb (B) wird nicht unterstützt.

  • Bekanntheitsgrad und Verbreitung sind gering
  • Keine spezielle Tool-Unterstützung vorhanden
  • Die Methode ist nicht normiert/standardisiert oder zertifiziert
  • Keine Lizenzierung erforderlich
  • Support ist vorhanden

zurück zur Studie