UDD Phase 3 – Interface Design

Programmierung ist im Vergleich zum Oberflächendesign sehr aufwendig und nur schwer zu verändern.

Deshalb sollte man sich zuerst dem Interface einer Anwendung zuwenden. 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 Produkt ist.

Die Oberfläche ist das, was die Anwender sehen und schlussendlich bezahlen sollen. 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 der Gestaltung von Oberflächen sollte man sich immer das Zitat von Antoine de Saint-Exupéry vor Augen führen: „Perfektion ist erreicht, nicht, wenn sich nichts mehr hinzufügen lässt, sondern, wenn man nichts mehr wegnehmen kann“  ( Wind, Sand und Sterne von Saint-Exupéry und Becker 1941, S.48). Angewandt auf die Oberflächengestaltung bedeutet Saint-Expuérys Zitat nichts anders als die Anwendung des DRY und des KISS-Prinzips

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. 

IT-Team der Hochschule Esslingen gewinnt Microsoft Imagine Cup 08

Mein Kommilitonen Daniel Franke, Jörn Schindler, Axel Ernst und Vasilios Filippidis arbeiten im Rahmen Ihrer Diplomarbeit an einem Projekt namens PoinT (Power in Time). 

Der Zweck von PoinT (Power in Time) besteht darin, elektronische Geräte mit Netzwerkanschluss komplett abzuschalten, wenn sie nicht benutzt werden. Die Grundidee: Geräte werden mittels der Power-over-Ethernet-Spannung definiert und gesteuert ein- und ausgeschaltet. Da der Power-over-Ethernet-Standard keine Netzspannung zulässt, wird für den Schaltvorgang ein Relais in einer entwickelten Power-Control-Unit (PCU) eingesetzt. Das Relais schaltet über die PoE-Spannung die benötigte Netzspannung. Im Vergleich zu anderen Technologien erreicht PoinT eine tatsächliche Standby-Leistungsaufnahme von 0 Watt am Endgerät, da die angeschlossenen Geräte physikalisch komplett von der Stromversorgung getrennt werden. Dies reduziert den Energieverbrauch und führt so zu einer Kostensenkung. Die Funktion erfolgt für den Benutzer transparent. Für ihn sind die Endgeräte nach wie vor verfügbar. 

Damit haben die vier erfolgreich am Microsoft Imagine Cup 08 teilgenommen. Und konnten das nationale Finale das im Rahmen der Student Technologie Conference in Berlin stattfand für sich entscheiden.

Herzlichen Glückwunsch! Und weiterhin viel Erfolg für das internationale Finale in Paris.

Mehr Infos gibt es in der Pressmitteilung unserer Hochschule oder in diesem Video:

UDD Phase 2 – Aufwandsabschätzung

Jeder Entwickler übernimmt Storycards, die Arbeit bis zum nächsten Planungsspiel enthalten. Dabei wird die Zeiteinschätzung durch die Entwickler selbst vorgenommen. Das Einfachste dieses zu tun ist die “Wetter von gestern Methode”, die besagt, dass das Wetter heute mit hoher Wahrscheinlichkeit das Gleiche wie gestern ist. Das bedeutet das sich Entwickler mit ihren Schätzungen an vorhergehenden Aufgaben orientieren sollen. Nach jeder Iteration werden die Istzeiten mit den geschätzten Sollzeiten verglichen. So entsteht im Verlauf des Projekts eine bessere Basis für weitere Schätzungen.

UDD Phase 1 – Das 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 in bei jeder Iteration wiederholt. Dadurch hat die Geschäftsseite bei jedem Planungsspiel 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 von der Geschäftsseite priorisiert werden.

Technische Vorraussetzungen für UDD

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.