Softwareentwicklung muss, um mit den Anforderungen des Marktes Schritt zu halten, mit zunehmender Geschwindigkeit erfolgen. Der Funktionsumfang selbst einfacher Anwendungen wird immer größer, die Anwendungsentwicklung somit komplexer. Zusätzlich ändern sich auch Kundenanforderungen schneller. Methoden der agilen Softwareentwicklung sind ein viel versprechender Ansatz diesen Herausforderungen zu begegnen.
Bedienbarkeit und Benutzerfreundlichkeit ist ein Qualitätsmerkmal guter Software. In Zeiten des Internets, in der die Konkurrenz nur einen Klick entfernt ist, wird Usability immer mehr zu einem entscheidenden Faktor für den Markterfolg. Agile Methoden betrachten Usability nicht in dem Maße, wie es klassische Usability zentrierte Verfahren tun.
Inhalt dieser Studienarbeit ist das Skizzieren eines Vorgehensmodells das anwenderzentrierte Softwareentwicklung mit Methoden der agilen Softwareentwicklung verknüpft. Als Vorbilder für die anwenderzentrierten Methoden sollen unter anderem IBMs Easy und das User Centered Design der Usability Professionals Association (UPA) dienen, welche mit agilen Methoden wie Behaviour Driven Development und Extreme Programming sinnvoll verknüpft werden sollen.
Die Arbeit teilt sich in zwei Teile. Im ersten Teil soll das Vorgehensmodell Usability Driven Development entwickelt und beschrieben werden. Im zweiten Teil wird dieses in der Praxis erprobt. Als Beispielanwendung dient dazu die Webanwendung Journizer.com. Journizer.com ist eine Webapplikation, die Dienstleistungen für Reisende bietet. Dazu gehören Blogs, Fotoalben und virtuelle Landkarten.
Inhaltsverzeichnis
Verzeichnis der verwendeten Abkürzungen v
1 Motivation
2 Begriffserklärungen
2.1 Usability
2.2 Usability Test
2.3 Anwenderzentrierte Methoden
2.3.1 User Centered Design
2.3.2 Easy of Use
2.3.3 Human-Centered Software Engineering
2.4 Agile Methoden
2.4.1 Agile Werte
2.4.2 Das DRY-Prinzip
2.4.3 Das KISS-Prinzip
2.4.4 Refactoring
2.4.5 Extreme Programming
2.4.6 Test Driven Development
2.4.7 Behaviour Driven Development
3 Usability Driven Development
3.1 Was ist Usability Driven Development?
3.2 Usability als Entwicklungsziel
3.3 Vorraussetzungen für UDD
3.3.1 Organisatorische Vorraussetzungen
3.3.2 Technische Vorraussetzungen
3.4 Eine UDD Iteration
3.4.1 Das Planungsspiel
3.4.2 Interface Design
3.4.3 Modellierung
3.4.4 Testdesign
3.4.5 Programmierung
3.4.6 Integration
3.4.7 Deployment
3.4.8 Usability Test
3.5 Bei jeder Iteration
3.5.1 Messen
3.5.2 Dokumentation
3.6 Bei jedem Planungsspiel
3.6.1 Usability Tests
3.6.2 Der große Plan
4 UDD in der Praxis
4.1 Journizer - Organize your journey!
4.2 Usability Test auf dem World Usability Day
4.3 Kleinigkeiten mit großer Wirkung
4.3.1 Aufwandsabschätzung
4.3.2 Programmierung
4.3.3 Integration und Deployment
4.3.4 Usability Test
4.4 Schlagworte
4.4.1 Aufwandsabschätzung
4.4.2 Interface Design
4.4.3 Modellierung
4.4.4 Testdesign
4.4.5 Programmierung
4.4.6 Integration und Deployment
4.4.7 Usability Test
5 Zusammenfassung und Ausblick
Literaturverzeichnis
A World Usability Day
A.1 Aufgaben des Usability Tests
A.2 Auswertung
B Quellcodes
B.1 Kleinigkeiten mit großer Wirkung
B.2 Performance Test
Abbildungsverzeichnis
2.1 User Centered Design
3.1 Eine UDD Iteration
4.1 Impressionen World Usability Day
4.2 Storycard - Validierung
4.3 Kleinigkeiten mit großer Wirkung - vorher
4.4 Kleinigkeiten mit großer Wirkung - nachher
4.5 Storycard - Schlagworte
4.6 Papierprototyp - Schlagworte
4.7 Datenbankmodell
4.8 Alle Schlagwörter
4.9 Schlagwörter eines Reisenden
4.10 Ansicht der verschlagworteten Inhalte
4.11 Eingabe der Schlagwörter
A.1 Wie gefällt dir das Design von Journizer?
A.2 Wie schnell hast du den Aufbau einer Reise in Journizer erfasst?
A.3 Wie plausibel findest du die Menüführung auf den externen Seiten?
A.4 Wie plausibel findest du die Menüführung im internen Bereich?
A.5 Gesamtbeurteilung
Verzeichnis der verwendeten Abkürzungen
Folgende Abkürzungen werden im Verlauf der Studienarbeit verwendet. Falls der Begriff im Verlauf der Studienarbeit ausführlich erklärt wird ist das entsprechende Kapitel in Klammern angegeben.
Abbildung in dieser Leseprobe nicht enthalten
Kapitel 1 Motivation
Softwareentwicklung muss, um mit den Anforderungen des Marktes Schritt zu halten, mit zunehmender Geschwindigkeit erfolgen. Der Funktionsumfang selbst einfacher Anwendungen wird immer größer, die Anwendungsentwicklung somit komplexer. Zusätzlich ändern sich auch Kundenanforderungen schneller. Methoden der agilen Softwareentwicklung sind ein viel versprechender Ansatz diesen Herausforderungen zu begegnen.
Bedienbarkeit und Benutzerfreundlichkeit ist ein Qualitätsmerkmal guter Software. In Zei- ten des Internets, in der die Konkurrenz nur einen Klick entfernt ist, wird Usability immer mehr zu einem entscheidenden Faktor für den Markterfolg. Agile Methoden betrachten Usability nicht in dem Maße, wie es klassische Usability zentrierte Verfahren tun.
Inhalt dieser Studienarbeit ist das Skizzieren eines Vorgehensmodells das anwenderzen- trierte Softwareentwicklung mit Methoden der agilen Softwareentwicklung verknüpft. Als Vorbilder für die anwenderzentrierten Methoden sollen unter anderem IBMs Easy und das User Centered Design der Usability Professionals Association (UPA) dienen, welche mit agilen Methoden wie Behaviour Driven Development und Extreme Programming sinnvoll verknüpft werden sollen.
Die Studienarbeit teilt sich in zwei Teile. Im ersten Teil soll das Vorgehensmodell Usability Driven Development entwickelt und beschrieben werden. Im zweiten Teil wird dieses in der Praxis erprobt. Als Beispielanwendung dient dazu die Webanwendung Journizer.com. Journizer.com ist eine Webapplikation, die Dienstleistungen für Reisende bietet. Dazu gehören Blogs, Fotoalben und virtuelle Landkarten.
Kapitel 2 Begriffserklärungen
2.1 Usability
Der englische Begriff Usability hat im Deutschen zwei Übersetzungen. Zum einen Ge- brauchstauglichkeit, die die Eignung eine Produktes in einem bestimmten Nutzungskon- text bezeichnet. Und zum anderen Benutzerfreundlichkeit, welche die von einem Nutzer erlebte Nutzungsqualität eines Systems aufzeigt. Die Benutzerfreundlichkeit ist eng mit der Ergonomie verwandt. Da der englische Begriff prägnanter ist wird im weiteren Verlauf dieser Studienarbeit immer Usability anstelle von Gebrauchstauglichkeit oder Benutzer- freundlichkeit verwendet.
In DIN EN ISO 9241 (Deutsches Institut für Normung e.V. 2006) werden folgende Kriterien für die Usability eines Dialogsystems zusammengefasst:
- Aufgabenangemessenheit: Ein Dialog ist Aufgaben angemessen, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen.
- 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 individualisierbar, 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.
2.2 Usability Test
Ein Usability Test soll die Usability einer Software oder Hardware evaluieren. Dabei wer- den Versuchspersonen typische Aufgaben an dem zu testenden Produkt gestellt und be- obachtet welche Schwierigkeiten auftreten. Die Testperson wird angehalten die Methode des “lauten Denkens” anzuwenden. Zur Auswertung der Daten können in einem Usability Labor Tastatur und Maus Aktionen aufgezeichnet, sowie der Bildschirminhalt aufgenom- men werden. Weitere Hilfen bei der Auswertung bieten Filmaufnahmen der Testperson und physiologische Werte, die Aussagen über den Streßlevel geben (Puls, Blutdruck oder Herzrhythmus). Um die genaue Orientierung innerhalb einer Bildschirmanwendung auf- zuzeichnen, können Eye-Tracking-Systeme eingesetzt werden. Usability Tests können in jeder Phase der Entwicklung durchgeführt werden. Papierprototypen, Modelle (bei Hard- ware) und Prototypen eignen sich dazu, bereits in der Anfangsphase der Entwicklung mögliche Fehler zu erkennen und zu beseitigen. In (Nielsen 1993, Kapitel 6: Usability Testing) werden alle Aspekte eines Usability Tests beschrieben.
Neben Usability Tests mit Benutzern besteht die Möglichkeit von Experten Reviews. Der Hauptunterschied zwischen diesen Verfahren liegt in den beteiligten Akteuren. Für die Durchführung von Experten-Reviews gibt es nach (Shneiderman 1998) folgende Me- thoden: heuristischen Evaluation, Styleguidereviews, Konsistenzinspektion, kognitiven Durchgangs und der formalen Usability Inspektion. Auf die genannten Begriffe soll im Verlauf der Studienarbeit nicht im Detail eingegangen werden. Der Hauptvorteil eines Experten Reviews ist, dass erfahrene Tester viele nicht offensichtliche Einschränkungen erkennen können.
2.3 Anwenderzentrierte Methoden
Im diesen Abschnitt sollen, die in dieser Studienarbeit betrachteten Methoden beschrieben werden, welche, die Interaktion mit dem Anwender in den Mittelpunkt stellen.
2.3.1 User Centered Design
User Centered Design (UCD) ist ein internationaler Standard für die benutzerorientierte Gestaltung interaktiver Systeme. Der Standard ist in der DIN EN ISO 13407 festgehalten. Darin wird ein fachübergreifender, iterativer Entwicklungsprozess beschrieben. Allerdings sind die Methoden nicht genau spezifiziert. Der Iterationszyklus endet, wenn die entwickelten Lösungen den Anforderungen entsprechen.
Hier sind die vier wesentlichen Teilaufgaben des Isoprozesses beschrieben:
Abbildung in dieser Leseprobe nicht enthalten
Bild 2.1: User Centered Design
1. Nutzungskontext verstehen
Bei dieser Aktivität wird eine Dokumentation erstellt, die beschreibt welche Benutzer, welche Use Cases in welcher Umgebung durchführen sollen.
2. Spezifikation der Anforderungen
In dieser Phase werden die Anwendungsfälle und Benutzerziele, die erreicht werden müssen damit das System erfolgreich in den Produktivbetrieb gehen kann, identifiziert und beschrieben.
3. Erstellen von Lösungen
In der Phase “Erstellen von Lösungen” werden die zuvor spezifizierten Anforderungen implementiert.
4. Evaluierung der Lösungen
Der wichtigste Schritt des User Centered Design ist die Evaluation der Lösungen, im Idealfall durch einen Usability Test mit zukünftigen Benutzern der Anwendung. Dabei wird die Erfüllung der festgelegten Anforderungen bewertet. Festgestellte Abweichungen sind Basis für die nächste Iteration des Entwicklungsprozesses.
Der genaue Wortlaut der Norm kann bei (Deutsches Institut für Normung e.V. 1999) nachgeschlagen werden. Eine ausführliche Beschreibung von User Centered Design bietet (Vredenburg u. a. 2002). Bei (Torres 2002) werden zahlreiche praktische Beispiele für User Centered Design beschrieben.
2.3.2 Easy of Use
Easy of Use ist ein von IBM entwickeltes Vorgehensmodel das auf UCD basiert. IBM be- schreibt auf der Easy of Use Webseite (IBM - Usability Engineering Team) welchen Mehr- wert gute Usability für Produkte und Dienstleistungen bietet und mit welchen Methoden und Werkzeugen diese erreicht werden kann. Es werden umfangreiche Designkonzepte, Styleguides und Projektpläne mit Phasen, Rollen und Aktivitäten vorgestellt.
2.3.3 Human-Centered Software Engineering
Das Human-Centered Software Engineering beschreibt wie Forschungsergebnisse, aus dem Bereich Human-Machine Interface1 (HMI), in Methoden der klassischen Softwaretechnik integriert werden können. In (Seffah u. a. 2005) wird beschrieben wie Usabilityanforderun- gen mit UML notiert werden können und welche Usability-Techniken und Aktivitäten, wie integriert werden sollten. Es wird verglichen wie mit Komplexität aus Designersicht und aus Ingenieursicht umgegangen wird. Außerdem werden Vorgehensweisen aufgezeigt wie Human-Centered Software Engineering umgesetzt werden kann. Diese sind:
- Fuß in der Tür (für interne Usability Gruppen): Um Usability Verfahren in einer Organisation, die bis dahin keine einsetzt, einzuführen eignen sich besonders die frühen Phasen eines Projektes. In Phasen wie Analyse oder High-Level Design ist eine Umsetzung von Usabilitygesichtspunkten einfacher durchzuführen, da für Än- derungen nur wenig Arbeit des Teams weggeworfen werden muss. Die Veränderung einer bestehenden Organisation ist grundsätzlich schwierig. Deshalb muss in kleinen Schritten vorgegangen werden. Es ist wichtig Entwicklern Vorteile klar aufzuzeigen.
- Fuß in der Tür (für externe Berater): Externe Usability Berater werden üblicher- weise in den späten Phasen eines Projektes hinzugezogen. Für sie ist es wichtig, die Geschäftsziele einer Organisation zu evaluieren. Diese Geschäftsziele können bei- spielsweise Kundenloyalität oder Konkurrenzfähigkeit sein. Es ist wichtig so schnell wie möglich einen Usability Test (siehe Kapitel 2.2 auf Seite 3) mit echten Anwen- dern durchzuführen. Die Stimme des Kunden sollte genutzt werden, um aufzuzeigen wie Usability helfen kann die Geschäftsziele der Organisation zu erreichen.
- Usability in frühen Projektphasen: Wenn in einer Organisation grundsätzlich akzep- tiert ist anwenderzentrierten Aspekten mehr Beachtung zu schenken (Beispielsweise durch eine der beiden “Fuß in der Tür” Vorgehensweise), eignen sich frühe bis mitt- lere Phasen eines Projektes, um Usabilitymaßnahmen einzuführen. Der wichtigste Schritt hierbei ist die Erarbeitung eines Styleguides und die Kommunikation an alle Entwickler.
- Usability in jeder Projektphase: Diese Vorgehensweise eignet sich für Organisatio- nen die bereits Usability in frühen Projektphasen einsetzen und eine mehr anwen- derzentrierte Organisation werden wollen. Der Schlüssel dazu ist die Einrichtung eines kontinuierliche Workflows der Kommunikation und des Feedbacks über den Lebenszyklus eines Produktes. Dazu muss eine Infrastruktur für Human-Centered Software Engineering geschaffen werden, um Usabilityaktivitäten möglichst effizient durchzuführen.
2.4 Agile Methoden
In diesem Abschnitt sollen Methoden und Stichworte erklärt werden, die unter dem Oberbegriff Agile Softwareentwicklung zusammengefasst werden können.
2.4.1 Agile Werte
Im Februar 2001 wurde von einer Gruppe von 17 Softwareentwicklern in einem Skiressort in Utah das agile Manifest ausgearbeitet (Beck u. a.). Darin sind die Prinzipien der agilen Softwareentwicklung festgehalten:
1. Individuen und Interaktionen gelten mehr als Prozesse und Tools.
2. Funktionierende Programme gelten mehr als ausführliche Dokumentation.
3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.
4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festge- legten Plans.
2.4.2 Das DRY-Prinzip
Das Akronym DRY steht für Don’t repeat yourself2. Das DRY-Prinzip ist eine Philoso- phie in der Informationstechnik, die verlangt, dass jede Information nur einmal in einem Projekt vorkommt. Das schliesst im Idealfall Quelltexte, Datenbankschemata, Tests und Dokumentationen ein. Durch die Vorhaltung von Informationen an nur einer Stelle, wird die Gefahr vermieden, dass redundante Informationen bei Änderungen vergessen werden. Das vermeidet Fehler so wie Inkonsistenzen und erhöht die Übersicht. Das DRY-Prinzip kann durch Automatisierung und Kapselung erreicht werden. Es ist eines der Kernprinzi- pien auf denen das bekannte Buch „Der pragmatische Programmierer“(Hunt und Thomas 2003) basiert. Es hält Anwendungen für Änderungen offen und ist damit Vorraussetzung für agile Softwareentwicklung.
2.4.3 Das KISS-Prinzip
Das Akronym KISS steht für Keep it simple, stupid3. Es besagt, dass stets die einfachste Lösung für ein Problem gewählt werden sollte. Bereits 1654 wurde vom deutschen Philo- sophen Johannes Clauberg die bekannte Formulierung aufgestellt, dass „Entitäten nicht über das Notwendige hinaus vermehrt werden dürfen“.4 (Clauberg 1968) Johannes Clau- berg bezog sich in seinem Buch auf wissenschaftliche Theorien. Vereinfacht ausgedrückt bedeutet die Aussage: Eine Theorie sollte möglichst einfach gestaltet sein und trotzdem alle wesentlichen Zusammenhänge erklären. Das KISS-Prinzip verallgemeinert Claubergs Aussage und kann auf Softwaretechnik angewandt, als eine der Vorraussetzungen für agile Softwarentwicklung angesehen werden.
2.4.4 Refactoring
Der Begriff Refactoring5 wurde von William Opdyke geprägt der, 1992, zu diesem The- ma promovierte (Opdyke 1992). Refactoring bedeutet: „Verbesserung des Designs von Quellcode nachdem er geschrieben wurde, ohne die Funktion zu verändern“. Dabei soll insbesondere die Lesbarkeit, Verständlichkeit, Testbarkeit und Erweiterbarkeit verbessert werden. Martin Fowler hat in (Fowler und Beck 1999) Refactoring in aller Ausführlichkeit beschrieben. Fowler listet “Bad Code Smells” auf, die Hinweise geben an welchen Stel- len des Quellcodes möglicherweise ein Refactoring notwendig sein könnte und behandelt Methoden, wie verschiedenen Arten von Refactorings durchgeführt werden können. Refac- toring ist heute ein allgemein anerkanntes Werkzeug der Softwareentwicklung. Zahlreiche freie und kommerzielle, meist in IDEs integrierte, Refactoring Browser belegen dies. Für agile Softwareentwicklung ist ständiges Refactoring des Quellcodes eine Grundvorrausset- zung.
2.4.5 Extreme Programming
Extreme Programming (XP) ist ein iteratives Vorgehensmodell der Softwaretechnik, wel- ches eine sehr flexible Arbeitsweise erlaubt. Es wurde von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt. XP basiert auf fünf zentralen Werten: Respekt, Kommunika- tion, Einfachheit, Feedback und Mut. Auf diesen Werten basierende Praktiken bilden das Vorgehensmodell Extreme Programming. Kent Beck hat diese in (Beck 2000) zusammen- gefasst:
- Das Planungsspiel - Der Umfang einer Version wird festgelegt, indem Geschäftsprioritäten mit technischen Aufwandsschätzungen kombiniert werden. Der Plan muss ständig an die Realität angepasst werden.
- Kurze Releasezyklen - Ein einfaches System soll so schnell wie möglich in Produktion gehen. Darauf folgend sollen in möglichst kurzen Iterationsschritten neue Versionen eingeführt werden.
- Metapher - Sämtliche Entwicklungen werden an einer gemeinsamen, einfachen Metapher ausgerichtet. Diese Metapher soll für Geschäftsseite und Entwicklerseite gleichermassen verständlich sein. Dadurch soll die einfache Kommunikation zwischen Kunden und Entwicklern sichergestellt werden.
- Einfaches Design - Das System soll zu jedem Zeitpunkt so einfach wie möglich strukturiert sein. (vgl. Das KISS-Prinzip Kapitel 2.4.3 auf Seite 7)
- Testen - Es werden für jeden Teil des System fortwähren Komponententests ge- schrieben, die fehlerfrei ausgeführt werden müssen. (vgl. Test Driven Development Kapitel 2.4.6)
- Refactoring - Das System unterliegt einem ständigen Refactoring, um Redundanzen zu verhindern, den Programmcode zu vereinfachen oder flexibler zu gestalten. (vgl. Refactoring Kapitel 2.4.4 auf der vorherigen Seite)
- Programmieren in Paaren - Der gesamte Produktionscode wird von zwei Programmieren geschrieben, die gemeinsam an einem Rechner sitzen.
- Gemeinsame Verantwortlichkeit - Jeder kann jederzeit beliebigen Code im System ändern.
- Fortlaufende Integration - Das System wird ständig integriert. Immer dann, wenn eine Aufgabe erledigt worden ist.
- 40 - Stunden Woche - Man arbeitet prinzipiell nicht mehr als 40 Stunden in der Woche. Überstunden werden nie länger als eine Woche geleistet.
- Kunde vor Ort - Dem Team soll ein echter, lebender Benutzer angehören, der wäh- rend der gesamten Arbeitszeit zur Beantwortung von Fragen zur Verfügung steht.
- Programmierstandards - Programmierer schreiben sämtlichen Code entsprechend Regeln, die die Kommunikation mithilfe des Codes erleichtern.
Diese Best Practices waren schon vorher bekannt und werden teilweise bereits lange genutzt. XP fasst diese Praktiken zu einem funktionierenden Gesamtkonzept zusammen, definiert diese jedoch nicht als Allheilmittel. Wo sie nicht den individuellen Anforderungen eines Projektes genügen sollen sie angepasst werden.
2.4.6 Test Driven Development
Test Driven Development6 (TDD) bezeichnet eine Methode zur Entwicklung von Software bei der Tests vor der eigentlichen Softwarekomponente entwickelt werden. Test Driven Development folgt dabei einem iterativen Prozess aus drei Schritten:
1. Rot - Schreibe einen Test für die nächste Funktion, der fehlschlagen muss.
2. Grün - Sorge mit möglichst wenig Quellcode dafür, dass wieder alle Tests laufen (grüner Balken für alle Tests).
3. Refaktorisiere - Eliminiere alle Duplikationen und führe notwendige Abstraktionen ein.
Das Verlagern der Tests vor das Entwickeln von Softwarekomponenten bietet einige Vorteile. So wird die Spezifikation nach und nach in die Testsuite überführt. Daraus ergibt sich eine ausführbare Spezifikation, die in maschinell prüfbarer Form vorliegt. Es besteht weiterhin nicht die Gefahr das Tests, die beim klassischen Wasserfallmodel am Ende des Entwicklungsprozesses stehen, aus Zeitmangel nicht durchgeführt werden. Zusätzlich erleichtert eine Testsuite Refaktorisierungen massgeblich.
Kent Beck hat in Test-Driven Development by Example (Beck 2003) das Vorgehen anhand von Beispielen beschrieben und nennt ausführliche Test Patterns.
2.4.7 Behaviour Driven Development
Behaviour-Driven Development7 (BDD) ist eine Evolution des Denkens hinter Test Dri- ven Development. Dabei wird die Sapir-Whorf Hypothese auf das Schreiben von Tests angewandt. Diese besagt: „zwischen den grammatikalischen Kategorien der Sprache, die eine Person spricht und wie diese Person die Welt versteht und sich in ihr bewegt, be- steht eine systematische Beziehung“(Whorf 1956). Die Sapir-Worf Hypothese ist in der Linguistik umstritten. Unstrittig ist jedoch das Sprache unser Denken beeinflusst. Diese Aussage kann bis auf Wilhelm von Humboldts Essay „Über das vergleichende Sprachstu- dium“(Humboldt und Leitzmann 1903) zurückgeführt werden. Bei BDD wird im Vergleich zu TDD nicht ein Testfall definiert, sondern ein Erwartung. Das Ziel ist nicht eine An- sammlung von Tests sondern eine ausführbare Spezifikation der zu entwickelnden Softwa- re. Nach (Astels) „arbeitet man bereits mit BDD wenn man TDD richtig anwendet“. Es existieren spezielle BDD Frameworks die Softwareunterstützung für BDD bieten. BDD kann aber auch mit den bekannten xUnit Frameworks umgesetzt werden.
Kapitel 3 Usability Driven Development
3.1 Was ist Usability Driven Development?
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 Produk- tion gehen und in kurzen Releasezyklen weiterentwickelt werden. Das Vorbild hierfür ist Extreme Programming (vgl. Extreme Programming Kapitel 2.4.5 auf Seite 8) das um Elemente des User Centered Design (vgl. User Centered Design Kapitel 2.3.1 auf Seite 4) 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 Softwareprojektes an, von grafischen Oberflächen, über Quellcodes und Dokumentation bis zu Verträgen mit Kunden.
3.2 Usability als Entwicklungsziel
UDD integriert Usability in agile Methoden. Der Gedanke dahinter ist, dass die Usability vor allem durch die Funktionalität eines Systems erreicht wird. Nur wenn ein System genau die Funktionen, die man von ihm erwartet, in einfach zu bedienender Weise erfüllt, entspricht es den Kriterien der Usability (vgl. Usability Kapitel 2.1 auf Seite 2). Das kann nur in einem iterativen Prozess durch ständiger Kommunikation mit den Nutzern erreicht werden.
3.3 Vorraussetzungen für UDD
3.3.1 Organisatorische Vorraussetzungen
Auf die organisatorischen Vorraussetzungen für UDD soll in dieser Studienarbeit nicht im Detail eingegangen werden. Sie sind im wesentlichen die gleichen wie bei Extreme Pro- gramming und werden ausführlich in (Beck 2000, Kapitel 26 Xp in der Praxis) und (Beck und Fowler 2001, Kapitel 25 Geschäftsbeziehungen) beschrieben. Besonders hervorzuhe- ben 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 ver- mutlich 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, sei- ne Meinung aber bei jedem Planungsspiel (siehe: Das Planungsspiel Kapitel 3.4.1 auf der nächsten Seite) ändern kann.
3.3.2 Technische Vorraussetzungen
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 Vor- gehensmodell ungeeignet. UDD setzt ein hohes fachliches Verständnis der Entwickler vor- aus, 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 selbst- entwickelte Fachsprachen geschehen oder durch Frameworks, die entsprechende Funktio- nalitäten bereitstellen. Damit eine 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 zu- verlässig wiederholbar und umkehrbar sein. In (Clark 2005) werden viele Aspekte der Automatisierung beschrieben.
[...]
1 dt. Mensch-Maschine-Schnittstelle
2 dt. Wiederhole dich nicht.
3 dt. Halt es einfach, Dummkopf!
4 Original lat. Entia non sunt multiplicanda praeter necessitatem oder sine necessitate.
5 dt. Refaktorisierung oder Refaktorierung
6 dt. testgetriebene Entwicklung
7 dt. erwartungsgetriebene Entwicklung
- Arbeit zitieren
- Jens Jäger (Autor:in), 2008, Usabilty Driven Development, München, GRIN Verlag, https://www.grin.com/document/91199
-
-
-
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.