Beschreibung und Analyse von Usability Driven Development

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Düsseldorf
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Agile Softwareentwicklung
Autor(en):	Maik Saß
Studienzeitmodell:	Tagesstudium
Semesterbezeichnung:	SS11
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Einleitung 4 Usability 4.1 Was ist Usability ? 4.2 Usability Test 4.3 User Centered Design 5 Agile Entwicklung 5.1 Was bedeutet agil ? 5.2 Werte 5.3 Prinzipien 5.3.1 DRY-Prinzip 5.3.2 KISS-Prinzip 5.3.3 Refactoring 5.4 Methoden 5.4.1 Extreme Programming 6 Usability Driven Development 6.1 Was ist Usability Driven Development ? 6.2 Vorausetzungen 6.2.1 Organisatorische Vorausetzungen 6.2.2 Technische Voraussetzungen 6.3 Iteration 6.3.1 Das Planungspiel 6.3.2 Interface Design 6.3.3 Modellierung 6.3.4 Testdesign 6.3.5 Programmierung 6.3.6 Integration 6.3.7 Deployment 6.3.8 Usability Test 7 Analyse 7.1 Wirtschaftliche Betrachtung 7.2 Nicht Monetäre Nutzen 7.2.1 Kundensicht 7.2.2 Entwicklersicht 7.2.3 Projektsicht 7.3 Einsatzmöglichkeiten 8 Fazit 9 Fußpunkte 10 Literaturverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
DRY	Don't repeat yourself
KISS	Keep it simple, stupid
XP	eXtreme Programming
UDD	Usability Driven Development
Apps	applications

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	User Centered Design
2	Werte - Prinzipien - Methoden
3	UDD Iteration

3 Einleitung

In unser heutigen Zeit, geht es immer mehr darum wie eine Anwendung aussieht, welches Gefühl sie in uns hervorruft und das die Anwendung selbst ein Erlebnis ist. Um diese Anforderungen zu meistern wurde schon vor einiger Zeit das Usability Driven Development entwickelt. Dennoch gibt es viele Programmierer die sich gar nicht oder nur wenig mit der Usability eines Produktes beschäftigen. In erster Linie zählt eben die Funktion des Programms und keine hübsche Benutzeroberfläche. Und solange die Anwendung am ende das macht was sie soll, auch wenn dazu Funktionen in tausenden untermenüs versteckt sind mit kryptischen Bezeichnungen so sieht der Programmierer oft nicht die Notwendigkeit dies zu ändern. Die folgene Arbeit widmet sich der Beschreibung und der Analyse des Usability Driven Developments und soll aufzeigen wie dieser Ansatz in einer Firma funktionieren kann.

4 Usability

4.1 Was ist Usability ?

Das Wort Usability stammt aus dem Englischen und wird im Deutschen mit den Worten Benutzerfreundlichkeit und Gebrauchstauglichkeit übersetzt. Die Benutzerfreundlichkeit beschreibt dabei die Nutzungsqualität, die der Nutzer mit dem System hat, ist es besonders einfach und eine dem Aufgaben entsprechende Bedienung wird von einer guten Benutzerfreundlichkeit gesprochen. Die Gebrauchstauglichkeit beschreibt die Eignung des Produktes in einem bestimmtem Nutzungskontext. Als Beispiel sei hier erwähnt, dass gewisse Haarfrisuren gut aussehen, aber nicht Gebrauchstauglich sind, da sie im Nutzungskontext Alltag einfach nicht halten. Der englische Begriff ist dabei sehr viel präziser und deshalb wird im weiteren Verlauf der Fallstudie von Usability gesprochen. In der DIN EN ISO 9241 (Deutsches Institut für Normung e.V. 2006) ^[1] :

• Aufgabenangemessenheit: Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d. h., wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren, anstatt auf der zur Aufgabenerledigung eingesetzten Technologie.

• Selbstbeschreibungsfähigkeit: Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem Benutzer auf Anfrage erklärt wird.

• Steuerbarkeit: Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten, sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.

• Erwartungskonformität: Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.B. seinen Kenntnissen aus dem Arbeitsgebiet, seiner Ausbildung und seiner Erfahrung sowie den allgemein anerkannten Konventionen

• Fehlertoleranz: Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.

• Individualisierbarkeit: Ein Dialog ist individualsierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe, sowie an die individuellen Fähigkeiten und Vorlieben des Benutzers zulässt.

• Lernförderlichkeit: Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet.

4.2 Usability Test

Bei einem Usabilty Test wird die Usability einer Software oder Hardware evaluiert. Es werden dafür den Versuchspersonen typische Aufgaben an dem zu testenden Produkt gestellt und beobachtet welche Schwierigkeiten auftreten. Die Testpersonen werden dabei zum lautem Mitsprechen aufgefordert, damit die Beobachter wissen was die Person denkt. Zur Aufzeichnung der Tests kommen dabei eine ganze Reihe verschiedener Methoden zum Einsatz. Diese sind Ton sowie Videoaufzeichnung und die Aufzeichnung der Tastatureingaben sowie der Mausklicks. Es kommt auch immer mehr das sogenannte Eye-Tracking-System zum Einsatz, um genau zu sehen, wo die Testperson hinschaut. Usability Tests sind notwendig, da die Entwickler des Produktes häufig dazu neigen, Schwachstellen zu übersehen und dazu neigt es zu verteidigen, gerade deshalb ist unabhängiges Testen wichtig. Neben den Usability Tests mit Anwendern besteht außerdem die Möglichkeit einer expertenbasierten Usability-Evaluation. Hauptunterschied zwischen den Testmethoden sind die beteiligten Akteuere. Bei einer expertenbasieren Usability-Evaluation werden speziell geschulte Tester hinzugezogen die dann folgende Methoden durchführen: Styleguidereviews, heuristische Evaluation, Konsistenzinspektion, kognitiven Durchgangs und die formale Usability Inspektion. Die genannten Begriffe werden im folgenden nicht weiter erläutert. Ein elementarer Vorteil einer solchen Evaluation ist die Tatsache, dass erfahrene Tester häufig nicht offensichtliche Einschränkungen erkennen können. Im Anschluss eines jeden Usability Test kommen halbstrukturierte Interviews. Im Rahmen der Befragung werden dann häufig Vergleiche mit anderen Produkten angestellt. Ziel ist es mögliche Schwachstellen eines Produktes zu analysieren und diese dann für die Weiterentwicklung zu nutzen.

4.3 User Centered Design

Beim User Centered Design (UCD) handelt es sich um einen internationalen Standard für die benutzerorientierte Gestaltung interaktiver Systeme. Der Standard ist in der DIN EN ISO 13407 festgehalten. Die Norm beschreibt dabei einen fachübergreifenden, iterativen Entwicklungsprozess bei dem Nutzer- und Aufgabeneigenschaften die Entwicklung der Software bestimmen. Weiterhin befinden sich in der Norm Richtlinien für das Berichten über benutzerorientierte Aktivitäten. Elementare Kriterien hierbei sind (Deutsches Institut für Normung e.V. 1999) ^[2] :

1. Nutzungskontext verstehen: Das Ergebnis dieser Aktivität ist eine dokumentierte Beschreibung der relevanten Benutzer, ihrer Arbeitsaufgaben und ihrer Umgebung.
2. Anforderungen spezifizieren: Während dieser Phase werden die Zielgrößen aus der bereits vorhandenen Dokumentation auf einer Kompromissebene abgeleitet. Dabei wird die Teilung der Systemaufgaben in solche, die von Menschen und in solche, die von der Technik durchgeführt werden sollen bestimmt.
3. Lösungen produzieren: Dies kann im Sinne eines Prototypings oder eines anderen iterativen Prozesses erfolgen. Diese Prototypen können noch reine Papierentwürfe (Mock-ups) oder aber schon lauffähige Programmversionen sein. Falls es unternehmensinterne Gestaltungsregeln für Benutzerschnittstellen gibt, sollten diese genutzt werden.
4. Lösungen bewerten: Die Lösungen werden auf die Erfüllung der festgelegten Anforderungen geprüft. Dazu können Experten-Reviews, Usability-Tests, Befragungen oder auch eine Mischung daraus dienen. Die dabei entdeckten Abweichungen werden dann auf ihre Relevanz hin bewertet und sind Ausgangspunkt der nächsten Iteration des Entwicklungsprozesses.

5 Agile Entwicklung

5.1 Was bedeutet agil ?

Grundsätzlich geht es bei der agilen Softwareentwicklung darum, den Entwicklungsprozess flexibler und schlanker zu gestalten. Der Hauptfokus liegt dabei mehr auf die zu erreichenden Ziele und die technischen sowie sozialen Probleme die bei der Softwareentwicklung entstehen. Es ist als Gegenbewebung zu sehen zu den traditionellen Softwareentwicklungsprozessen, die als schwerfällig, unflexbil und bürokratisch gelten. Vertreter dieser klassischen Prozessen sind dabei das V-Modell und der Rational Unified Process. Allerdings sei zu beachten nicht überall wo Agilität draufsteht steckt auch Agilität drin. Viele Pläne agil vorzugehen scheitern und dies liegt oft daran das die Grundidee nicht übernommen wurde, sondern man nur einfach auf einen der neuen Prozesse wie Crystal oder Scrum eingesetzt hat.

5.2 Werte

Die Grundlage für die agile Softwareentwicklung bildet das sogenannte Agile Manifest.^[3] Deshalb kommt man nicht drum herum sich dieses zu Gemüte zu führen, was damals im Februar 2001 von einer Gruppe von 17 Softwareentwicklern in einem Skiressort in Utah, ausgearbeitet wurde. Das Manifest lautet:

Wir decken bessere Wege auf, Software zu entwickeln, indem wir es vorleben und
anderen helfen, dies ebenso zu tun. Durch diese Arbeit haben wir schätzen gelernt:

• Menschen und Interaktion mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Eingehen auf Veränderung mehr als das Befolgen eines Planes

Das heißt, obwohl die Dinge auf der rechten Seite für uns einen gewissen Wert besitzen,
schätzen wir die Dinge auf der linken Seite als wichtiger ein.

In dem agilen Manifest und vielen anderen Dokumenten, die agile Entwicklungsmethoden beschreiben, sind Praktiken aufgeführt die man unbedingt durchführen muss. Als Teammitglied will man als "agil" gelten. Viele dieser Praktiken gab es bereits schon lange vor der "agilen Bewegung". Dazu zählen das iterative Vorgehen und crossfunktionale Teams, eine ganze Reihe anderer sind erst mit den agilen Methoden entstanden wie z.B. testgetriebene Entwicklung oder Paar-Programmierung. Was viele jedoch vergessen dabei ist, dass diese Praktiken nur versuchen, den agilen Prinzipien gerecht zu werden. Diese basieren wiederum auf den agilen Werten und beeinflussen unser Handeln von Grund auf. Oft scheint es so als würden einzelne Praktiken dem tradiotionellen Verständniss von Effizenz und Wirtschaftlichkeit im Widerspruch stehen. Diese werden dann häufig kritisiert, allerdings wird dabei oft die zugrunde liegenden Prinzipien vergessen. Die Prinzipien und Normen sind nichts weiter als hohle Regeln ohne ein Fundament aus Werten. Man kann jemand vielleicht eine Zeit lang dazu bringen einen agilen Prozess wie Crystal zu nutzen, allerdings werden die wenigsten diesen freiwillig auf Dauer einhalten, wenn sie die Werte und Prinzipien dahinter nicht verinnerlicht haben. Deshalb ohne die richtigen Werte, die mit den Prozessen eng verknüpft sind, kann kein agiler Prozess auf Dauer gelebt werden.

5.3 Prinzipien

Die oben genannten Werte beeinflussen Prinzipien, welche wiederum formuliert in Projekt- und Teamnormen eine Manifestation der Werte, die einem wichtig sind. Es ist wichtig das es sich nicht um Scheinprinzipien handelt, das wäre z.B. der Fall, wenn die oberste Firmenleitung diese einfach festlegen würde. Sie sollte deshalb gemeinsam erarbeitet werden.

5.3.1 DRY-Prinzip

Das Akronym DRY steht für "Don't repeat yourself" (dt. etwa: Wiederhole dich nicht). Das DRY-Prinzip besagt im Kern, Redundanz zu vermeiden oder zumindest wenn möglich zu reduzieren. Sie verlangt, dass jede Information nur einmal in einem Projekt vorkommt. Das bedeutet im Idealfall, dass in Quellcodes, Datenbankschemata, Tests und Dokumentation keinerlei Redundanzen vorhanden sind. Vorteil dabei ist, dass bei Änderungen nur jeweils eine Information geändert werden muss und nicht an mehreren Stellen. Die Gefahr das Inkonsistenten auftreten kann somit vermieden werden und auch die Fehleranfälligkeit ist geringer. Es kann durch konsequente Anwendung von Kapselung und Automatisierungen erreicht werden. Es ist einer der 12 Kernprinzipien des agilen Manifests und damit eine Voraussetzung für die agile Softwareentwicklung.

5.3.2 KISS-Prinzip

Das Akronym KISS steht für "Keep it simple, stupid" (zu dt. „Halte es einfach, Dummkopf!“; sinngemäß: Mach's so einfach wie möglich) Es besagt, dass stets die möglichst einfache, minimalistische und leicht verständliche Lösung eines Problems gewählt werden sollte. Im Jahre 1654 stellte der deutsche Philosoph und Theologe die bekannte Formulierung auf, dass "Entitäten nicht über das Notwendige hinaus vermehrt werden dürfen". ^[4] Er bezog sich in seinem Buch, welches nach sein Tod gedruckt wurde, auf Wissenschaftliche Theorien. Es bedeutet im Grunde eine Theorie muss möglichst einfach sein aber trotzdem alle elementaren Zusammenhänge erklären können. Das KISS-Prinzip befolgt damit Claubergs Aussage und hat seine Theorie simplifiziert. Es gilt zudem als eine Voraussetzung für die agile Softwareentwicklung.

5.3.3 Refactoring

Der Begriff Refactoring wurde erstmal im Jahr 1990 verwendet in einer Arbeit von Ralph Johnson und William Opdyke, Opdyke promovierte 2 Jahre später zu dem Thema. Sie entwickelten erste Ansätze um Quellcode über eine Software-Refactory, diese sollte es ermöglichen Quellcode einfacher umzugestalten ohne dabei seine eigentliche Funktion zu ändern. Der Begriff wurde dann später vor allem durch Martin Fowler ^[5] geprägt als dieser in aller Ausführlichkeit das Refactoring beschrieb und auch eine Liste "Bad Code Smells" auflisteten. In dieser Liste finden sich viele Hinweise, an welchen Stellen im Quellcode ein Refactoring notwendig ist. Einige davon im Bereich der objektorientierten Programmierung sind:

• Faule Klassen: Eine einzelne Klasse hat zu wenig Methode, um ihre Existenz zu rechtfertigen
• Toter Code: Codeteile die überhaupt nicht mehr im Programm verwendet werden
• Middle Man: Eine Klasse die sämtliche Methodenaufrufe nur an eine andere Klasse weiterleitet

In der heutigen Zeit ist Refactoring ein allgemein bekanntes Werkzeug der Sofwareentwicklung. So gut wie alle aktuelle IDEs unterstützen Refactoring und es ist somit einfacher sauberen funktionalen Code zu schreiben.

5.4 Methoden

Es scheinen immer mehr sogenannte agile Methoden aus dem Boden zu sprießen. Dazu zählen unter anderem: Extreme Programming, Scrum, DSDM (Atern), die Familie der Crystal-Prozesse, Feature-driven Development (FDD), Lean Software Development und viele andere. Im Gegenzug dazu werden mittlerweile auch die traditionellen Entwicklungsprozesse agil gemacht. Unter ihnen unter anderem RUP und das V-Modell XT welches in Deutschland entwickelt wurde. Im folgenden wird dabei nur auf einer der bekanntesten Vertreter eingegangen.

5.4.1 Extreme Programming

Das Extreme Programming (XP) ist eine Methode und beschreibt ein iteratives Vorgehensmodell der Softwaretechnik. Es ermöglicht eine schrittweise Näherung an die Anforderungen des Kunden. Diese Methode wurde von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt. XP basiert dabei auf den fünf zentralen Werten: Einfachheit, Kommunikation, Rückmeldung, Mut und Respekt, wobei Respekt erst später hinzugefügt wurde. Aus diesen Werten sind die folgenden Praktiken des Extreme Programmings entstanden^[6]

• Kommunikation: Es wird ein stetiger Austausch gefördert, somit ist niemand auf sich alleine gestellt.
• Mut: Es herrscht allgemein eine sehr offene Atmosphäre unter den Entwicklern und es gibt keine Angst vor versäumten Terminen.
• Kollektives Eigentum: Der Code gehört dem Team, somit gibt es nicht die Mentalität, dass jeder nur seine Codeartefakte pflegt.
• Paar-Programming: Der Programmcode wird von zwei Leuten entwickelt, die gemeinsam an einem Rechner sitzen, frei nach dem Motto vier Augen sehen besser als zwei.
• Fortlaufende Integration: Es werden fertige Programmfunktionen sofort mit dem Gesamtsystem integriert, dies erlaubt Feedback und erhöht die Qualität
• Testen: Das Testen hat hat im Gegensatz zu den traditionellen Softwareentwicklungsprozessen einen sehr hohen Stellenwert.
• Kundeneinbeziehung: Jedem Team soll ein echter Benutzer angehören, dieser ist während der gesamten Entwicklung vor Ort.
• Refactoring: Das System unterliegt einem ständigen Refactoring und es werden suboptimale Designs und Fehler akzeptiert.
• 40 - Stunden Woche: Die reguläre Arbeitszeit wird eingehalten.
• Iteration: Das Gesamtsystem wird ständig iteriert, somit wird ein Release in einzel Iterationen unterteilt.
• Stand-up-Meeting: Es gibt eine tägliche Besprechung unter allen Beteiligten um frühzeitig Probleme zu erkennen oder mögliche Idee einzubringen.
• Dokumentation: Es soll dort Dokumentiert werden wo es sinnvoll ist und nicht überall wo es möglich ist.
• Metapher: Es soll ein gemeinsames Vokabular zwischen Entwickler und Kunden vorhanden sein.
• Team: Das Team steht im Mittelpunkt, im Team selbst existieren keine Rollen und Feedback wird von jedem gewünscht und auch erwartet.
• Standards: Es wird sich an Code-Konventionen gehalten, so dass der Code auch untereinander lesbar bleibt.
• Planspiel: Neue Software wird mit Hilfe eines Planspiel erstellt. Dabei werden Aufgaben definiert, die dann von der Geschäftsseite priorisiert werden und den Teams zugeteilt.

Diese Liste an sogenannten Best Practice waren schon lange vor dem Extreme Programming bekannt, jedoch wurde diese in der Methode XP zu einem funktionierenden Gesamtmodell zusammengefasst. Es sei aber gesagt, sie sind nicht als Wunderwaffe zu verstehen, es kann durchaus vorkommen, dass einige dieser Werte nicht vereinbar sind mit den eignen Projekten z.B. ist es oft nicht Möglich einen Kunden während des gesamten Projektes vor Ort zu haben, hier sollte man dann gegebenfalls Anpassungen durchführen.

6 Usability Driven Development

6.1 Was ist Usability Driven Development ?

Unter Usability Driven Development versteht man ein Vorgehensmodell der Softwaretechnik bei dem das Thema Usability in einem agilen Prozess eingebettet wird. Der gesamte Entwicklungsprozess ist dabei iterativ und ermöglicht damit eine Anwendung auf den Kunden exakt anzupassen. Ziel ist es, dabei das Produkt schnellst möglich in einen Produktivzustand zu bringen um es dann mit vielen kurzen Releasezyklen weiter zu entwickeln. Als Vorlage dient dabei, eine von Jens Jäger entwickelte Methode, bei dem das Extreme Programming um die Elemente des User Centered Design erweitert wurde. Als Grundlage für das Vorgehensmodell dient das DRY und das KISS-Prinzip, diese werden in jeder Phase konsequent durchgeführt und ermöglichen eine agile Entwicklung. Beim UDD werden diese Prinzipien auf sämtliche Aspekte eines Softwareproduktes angewendet, von der GUI, über den Quellcode bis hin zur Dokumentation und den Verträgen mit dem Kunden.

6.2 Vorausetzungen

6.2.1 Organisatorische Vorausetzungen

Die organisatorischen Voraussetzungen sind die gleichen wie beim Extremeprogramming und sollen hier nur kurz erläutert werden. Im wesentlichen geht das darum, dass Kunden gerne Verträge haben, in denen genau beschrieben steht, welchen Umfang und welche Funktionen die Software haben soll. Allerdings möchten Kunden auch die Option ihre Meinung zu ändern. Bei fast allen Softwareprojekten haben sich die Anforderungen während der Entwicklung geändert. Dies können technische Gründe sein aber auch marktrelevante, die Liste hier für ist lang. Um dem entgegen zu wirken und dieses Paradoxon zu lösen, bekommt der Kunde zum Projektstart einen groben Plan der die ungefähre Richtung des Projektes definiert. Der Kunde kann aber bei jedem Planungsspiel seine Meinung ändern.

6.2.2 Technische Voraussetzungen

Das entscheidende Kriterium bei den technischen Voraussetzungen ist, dass die zu entwickelnde Software eine GUI besitzt. Sämtliche Anwendungen die diese Eigenschaft nicht haben, sei es eine Kommandozeilen-Anwendung, ein Treiber oder eine API sind nicht geeignet für das UDD. Für den Entwickler ist es außerdem entscheidend, dass dieser über ein hohes fachliches Wissen verfügt, um mit dem Anwender auf einer Ebene zu kommunizieren und dass er entsprechende Werkzeuge verwendet, wie spezielle Frameworks oder sonstiges um den Fokus beim Entwickeln auf die Geschäftslogik legen zu können. Da es bei einem Projekt zu vielen Iterationen kommt ist ein hohes Maß an Automatisierung erforderlich. Die Dokumentation selbst sollte über den Quellcode erfolgen. Es sei hierbei noch zu empfehlen eine Versionsverwaltung zu verwenden (z.B. Subversion). Ein Deployment der Software muss schnell und einfach möglich sein. Es sollte auch möglichen sein zwischen verschiedenen Versionen der Software hin und her zu springen, um einzelne Änderungen besser sichtbar zu machen.

6.3 Iteration

6.3.1 Das Planungspiel

Beim UDD beginnt die Entwicklung der Software mit einem sogenannten Planungsspiel. Bei einem Planungsspiel werden die Rollen fest verteilt, zum Einen die Rolle des Kunden und zum Anderen die Geschäftsseite. Ein Mitglied der Geschäftsseite notiert zu Anfang alle Anforderungen der Software in Form von Storycards, diese werden der Priorität nach geordnet und dann entsprechend dieser Reihenfolge erfolgt eine Entwicklung. So ist schon zu Beginn klar welche Funktionen elementar sind und welche eher sekundär. Das Planungsspiel wird bei jeder Iteration wiederholt, so hat zu einem der Kunde die Möglichkeit neue Anforderungen zu definieren aber auch die Geschäftsseite hat die Chance eine neue Priorisierung vorzunehmen. Während der Entwicklung kommen, durch Usability Tests, neue Story Cards hinzu, diese müssen ebenfalls von der Geschäftsseite priorisiert werden. Danach übernimmt jeder Entwickler die ihm zugeteilten Storycards. Diese wird er mindestens bis zum nächsten Planungsspiel behalten. Die Zeiteinschätzung erfolgt durch den Entwickler selbst und nicht durch den Projektleiter oder der Geschäftsführung wie es in klassischen Projekten der Fall ist. Zur Aufwandsschätzung wird dabei die einfache Vergleichsmethode heran gezogen, diese stützt sich im wesentlichen auf Erfahrung. Es wird dabei nach vergleichbaren Projekten oder Projektteilen aus der Vergangenheit gesucht um so Rückschlüsse auf die laufenden bzw. die zukünftigen Projekte zu schließen. Zu dem werden nach jeder Iteration die Istzeiten mit den Sollzeiten verglichen um so eine bessere Basis für zukünftige Schätzungen zu ermöglichen. Diese Aufwandsschätzmethode ist zwar einer der simpelsten aber wegen des geringen Aufwandes eher Vorzuziehen als die algorithmische- oder Kennzahlenmethode.^[7]

6.3.2 Interface Design

Die grafische Benutzeroberfläche oder auch GUI ist einer der zentralen Punkte im UDD. Im Vergleich zum Programmcode ist die Oberfläche relativ leicht zu ändern und hat zudem den größten Eindruck auf den Kunden. Es ist schließlich das was er am Ende sieht und mit dem er arbeiten wird. Ein Interface sollte dabei möglichst zuerst auf Papier erfolgen, um nicht an mögliche Restriktionen durch bestimmte Werkzeuge gebunden zu sein. Häufig kommt es sonst zu einseitigem Denken, wenn das verwendete Tool ein bestimmtes Designelement nicht unterstützt. Ein Programm welches zwar über einen großen Funktionsumfang verfügt jedoch über eine sehr unattraktive Oberfläche verfügt wird einen Kunden nicht begeistern. Wahrscheinlich würde selbiger ein Programm mit der Hälfte der Funktionen, aber einen guten Oberfläche sogar vorziehen. ^[7] Deshalb sollte man sich an den Grundsatz halten „weniger ist mehr“ und diesen konsequent anwenden. Es ist einfach gesagt die Anwendung des DRY und des KISS-Prinzips. Sollte es sich um bei den Oberflächenänderungen um sehr Umfangreiche handeln, ist zu bedenken möglicherweise kurz in die Phase „Usability Test“ zu springen. Somit ist es möglich, das Design zu prüfen, bevor zu viele Ressourcen darauf verwendet werden.

6.3.3 Modellierung

Ist die Konzeption der Oberfläche einer Funktion abgeschlossen, geht es an die Modellierung. Diese Phase dient dazu, sich einen Überblick zu verschaffen, wie man eine neue Funktionalität in der Software integriert. Es geht nicht darum aufwändige UML Diagramme zu zeichnen oder Ähnliches, vielmehr soll entschieden werden, wo im Schichtenmodell die Funktion implementiert wird, welche möglichen Algorithmen genutzt werden können und ob vielleicht bereits vorhandene Programmbibliotheken genutzt werden können. Diese Dinge sollten die Entwickler klären und falls nötig sollte man auch einen Test entwickeln. Es ist wichtig bereits in der Modellierungsphase auf Performance zu achten. Gerade in der heutigen Zeit in der immer mehr auf skalierbare Systeme wert gelegt wird, sind Lasttests bereits in dieser Phase aufschlussreich.^[7]

6.3.4 Testdesign

Nach der Phase der Modellierung kommt das Testdesign. Es werden dabei die vorhandenen Storycards in denen Funktionalitäten beschrieben sind in Tests umgesetzt. Somit bildet sich aus den Storycards, die in dem Planungsspiel verfasst wurde, eine erste ausführbare Version. Dabei werden natürlich Storycards ausgeschlossen, die sich nur auf das Interface beziehen und keinerlei Funktionen in der Software selbst. Diese entstehen normalerweise nur während Usability Tests und sind maschinell schwer bis überhaupt nicht zu testen. In solchen Fällen wird die Phase Testdesign übersprungen.^[7]

6.3.5 Programmierung

In der Phase Programmierung geht es darum die Ergebnisse aus den Phasen Inteface Design, Modellierung und Testdesign umzusetzen. Es erfolgt die Implementiertierung des Userinterfaces, die nötigen Klassen mit ihren Methoden werden geschrieben und die Datenbank wird entwickelt. Es gilt dabei das DRY und KISS-Prinzip einzuhalten und jede Lösung möglichst simpel zu halten. Sollten alle Tests erfolgreich bestanden sein beginnt das Refactoring, dies ist trotz hohem Zeitdruck immer zu empfehlen. Bevor man schlussendlich die Phase beendet, sollte geprüft werden ob sämtliche Tests erfolgreich waren und die Dokumentation für die Klassen und Methoden ausreicht. Denn diese werden schon bei der nächsten Iteration wieder nötig sein wodurch man sehr schnell merkt, dass eine gute Dokumentation sich auszahlt und Zeit spart.^[7]

6.3.6 Integration

Bei der Integration handelt es sich um die Zusammenführung des geänderten Quellcodes mit der Codebasis. Dieser Schritt erfolgt sobald alle Tests erfolgreich sind. Um dies zu bewerkstelligen ist die Nutzung einer Versionsverwaltung zu empfehlen, andernfalls kann es schnell zu Problemen kommen. Zum Einen ist ein vereinfachtes und schnelleres Zusammenführen möglich, es gibt eine einheitliche Codebasis für alle Entwickler, das Zurückspringen zu vorherigen Versionen ist schnell und einfach und der Projektleiter hat einen besseren Überblick über das Gesamtprojekt. Es sollten auch erstellte Diagramme, die während der Modellierung entstanden sind eingecheckt werden. Weiterhin sollte ein Integrationstest durchgeführt werden, bei dem die Software vor dem eigentlich Deployment getestet wird, um so mögliche fehlende Dateien auszumachen oder Komplikationen mit anderer vorhandener Software auszumachen.^[7]

6.3.7 Deployment

Das Deployment zu deutsch Softwareverteilung beschreibt den Prozess bei dem eine Software auf den Anwender-PCs oder Servern in Betrieben verteilt und ausgeliefert wird. Es ist dabei zu empfehlen, ein System mit 3 Umgebungen zu nutzen, eine Entwickler-,eine Test- und eine Produktivumgebung. Dies hat den Vorteil, dass Entwickler ihre Lösungen in einem Gesamtsystem testen können. Der Kunde dann in einem Testsystem bevor am Ende diese im Produktivumfeld eingespielt werden. So kann das Risiko einen Fehler im Produktivbetrieb zu haben deutlich reduziert werden. Dennoch sollte man Backupsysteme nutzen, um gegeben falls Änderungen in den Umgebungen rückgängig zu machen. Es sei hier noch anzumerken, dass umfangreiches Testen dafür notwendig ist und gerade dem Kunden sollte verdeutlicht werden, dass er nur so am Ende eine hohe Qualität der Software möglich ist.^[7]

6.3.8 Usability Test

Am Ende einer jeden Iteration erfolgt der Usability Test. Hierbei werden alle implementierten Funktionen mit Hilfe der Storycards getestet. Die Storycards sind so zu sagen als Aufgabe zu betrachten, die die jeweiligen Entwickler lösen mussten. Stellt sich heraus, es ist eine Funktion ungenügend oder gar nicht implementiert worden, wird das Deployment rückgängig gemacht. In diesem Fall wird die Iteration erneut durchgeführt, um die Fehler zu beseitigen. Dies ist allerdings eher selten der Fall, was häufig eintreten wird und durchaus auch gewünscht ist, sind Verbesserungsvorschläge, zum einen vom Kunden und zum andern auch von anderen Entwicklern, die Ihre Funkionen jetzt unter anderen Bedingungen sehen. Ist dies der Fall beginnt die Iteration ebenfalls erneut und die Verbesserungen werden in Form von Storycars aufgeschrieben und von der Geschäftsseite erneut priorisiert werden.^[7]

7 Analyse

7.1 Wirtschaftliche Betrachtung

7.2 Nicht Monetäre Nutzen

7.2.1 Kundensicht

7.2.2 Entwicklersicht

7.2.3 Projektsicht

7.3 Einsatzmöglichkeiten

8 Fazit

Leider es ist aufgrund der fehlenden Analyse nicht möglich ein eindeutiges Fazit zu ziehen. Es sei hier jedoch gesagt das Usability Driven Development mit dem wachsenden Bedarf an Benutzerfreundlicher Software immer mehr an Bedeutung gewinnt. Gerade im Bereich der mobilen Geräte wie Smartphones mit ihren Apps entscheidet oft nicht die Funktion sondern das Aussehen und die Handhabung der Software über einen Erfolg.

9 Fußpunkte

1. ↑ Ergonomie der Mensch-Maschine-Interaktion - Teil 110: Grundsätze der Dialoggestaltung (ISO 9241-110:2006)
2. ↑ Benutzer-orientierte Gestaltung interaktiver Systeme (ISO 13407:1999)
3. ↑ Vgl. Manifest für Agile Softwareentwicklung, http://agilemanifesto.org/iso/de/ , 11.06.2011 22:41
4. ↑ Opera omnia philosophica. Hildesheim : G. Olms, 1968
5. ↑ Vgl. Seite xvii Refactoring . Wie Sie das Design vorhandener Software verbessern
6. ↑ Vgl. Extreme Programming – Back to Basics? Bernhard Rumpe http://www4.in.tum.de/publ/papers/Rum01.pdf 11.06.2011 23:14
7. ↑ ^{7,0 7,1 7,2 7,3 7,4 7,5 7,6 7,7} Vgl. Jäger (2008) Seite 13-17

10 Literaturverzeichnis

Sarodnick, F., & Brau, H. (2011).	Methoden der Usability-Evaluation. Bern: Hans Huber.
Alistair Cockburn (2003)	Agile Software Entwicklung
Jens Jäger (2008)	Usability Driven Development Studienarbeit (in Absprache mit dem Autor)
Clauberg (1968)	Opera omnia philosophica. Hildesheim : G. Olms, 1968
Kent Beck (2004)	Extreme Programming. Das Manifest : Addison-Wesley, München (2004)
Martin Fowler (2001)	Refactoring . Wie Sie das Design vorhandener Software verbessern  : Addison-Wesley; Auflage: 1. Aufl. (15. März 2000)
Deutsches Institut für Normung e.V 1999	Benutzer-orientierte Gestaltung interaktiver Systeme (ISO 13407:1999) ; Deutsche Fassung EN ISO 13407:1999 : Deutsches Institut für Normung e.V 1999
Deutsches Institut für Normung e.V 2006	Ergonomie der Mensch-Maschine-Interaktion - Teil 110: Grundsätze der Dialoggestaltung (ISO 9241-110:2006) ; Deutsche Fassung EN ISO 9241-110:2006 : Deutsches Institut für Normung e.V 2006
Manhartsberger, Martina (2001)	Web Usability – Das Prinzip des Vertrauens. Galileo Design 2001