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.

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.