Bachelor-Thesis. Storyboard-getriebene Frontend-Entwicklung auf Basis des Microsoft.NET-Framework

Transkript

1 Bachelor-Thesis Storyboard-getriebene Frontend-Entwicklung auf Basis des Microsoft.NET-Framework Arbeit zur Erlangung des akademischen Grades Bachelor of Science Fakultät Elektro- und Informationstechnik Studiengang Angewandte Informatik Vorgelegt von: Johannes Stoll Schauinslandstr Eschbach Beginn: 9. Dezember 2010 Ende: 9. Juni 2011 Betreuer: Prof. Dr.-Ing. Daniel Fischer Dr. Eva Decker Eingereicht am 30. Mai 2011

2 Abstrakt (Deutsch) Heutzutage spielt es keine Rolle mehr, ob man Software für eingebettete Unterhaltungselektronik, Software für medizinische Geräte, Web- oder klassische Desktop-Anwendungen entwickelt. Graphische Benutzeroberflächen machen im Allgemeinen Softwaresysteme erst für jeden einsetzbar und schaffen, wenn sie richtig umgesetzt sind, erstmals die Grundlage von jedem ohne technischem Hintergrundwissen und ohne zusätzliche Peripherie z. B. nur durch eine Touch-Oberfläche (im Bereich der Automation häufig anzutreffen) mit Leichtigkeit bedient zu werden. Die heutigen zunehmend vernetzten Anwendungen, Dienste und Betriebssysteme sind durch ihre Komplexität ohne graphische Benutzeroberfläche nicht mehr bedienbar. Eine ausgereifte und intuitiv-bedienbare graphische Benutzeroberfläche trägt entscheidend zur Akzeptanz beim Endanwender, zur Attraktivität einer Software und zur Kaufentscheidung der Software bei. Gerade im Bereich der mobilen Endgeräte, wie z. B. den Smartphones, die anfänglich noch schlecht strukturierte und einfache LCDs besaßen und heutzutage dem Konzept des Personal Computer immer ähnlicher werden, kann dieser Trend besonders gut beobachten werden, da er sich rapide abzeichnet. Der Erfolg der graphischen Benutzeroberflächen ist darauf begründet, dass sie weitestgehend selbsterklärend sind und der Endanwender sie dadurch ohne weiteres Wissen leicht versteht und bedienen kann. Die Anwendungsmöglichkeiten der graphischen Benutzerführung sind aber noch lange nicht erschöpft. So erkennt man gerade erst die verborgenen Potentiale der kognitiven Wahrnehmung in Verbindung mit der Technik und versucht sie in neue Forschungsfelder und Industriezweige für die Erledigung neuer Aufgaben einzuführen und zu etablieren. Eines dieser neuesten Interessensfelder in der Anwendungsentwicklung ist das anspruchsvolle Aufgabenfeld der Anforderungsanalyse. Dieser Bereich könnte sich in Zukunft, durch den Einsatz von Prototypen graphischer Benutzeroberflächen zur Ableitung fachlicher und technischer Anforderungen, effizienter und verlässlicher gestalten lassen. Die neu erlangten Vorteile einer graphischen Anforderungsanalyse könnten somit zu einer besseren äußeren wie auch inneren Produktqualität beitragen. 1

3 Abstract (English) Nowadays, it makes no difference whether embedded consumer electronics, software for medical devices, web applications or traditional desktop applications are developed anymore. In General, when having a graphical user interface for the first time software becomes usable and adequately designed enables people without technical background and without additional peripheral devices to use applications with ease e.g. simply by a touch panel (often found in the field of automation). By its complexity, today s interconnected applications, services and operating systems cannot be operated without graphical user interfaces anymore. A robust and intuitively usable graphical user interface adds decisively to acceptance with end users, to the attractiveness of a software and to its buying decision. Especially in the field of mobile devices e.g. with smart phones which started with badly organized and simple LCDs and nowadays are almost like Personal Computers this trend can be studied extremely well because it is progressing so fast. The success of graphical user interfaces is based on their widely self declarative nature which enables their users to learn them without additional knowledge and operate them with ease. However, the potential of graphical user guidance has not yet been maxed out. We only are just about to fully grasp all hidden aspects of cognitive perception in conjunction with technology and try to introduce them into and establish them in the latest fields of research or industry branches to solve new tasks. One of those latest fields of interest in application development is the ambitious field of Requirements Engineering. In the future, this field could be made more efficient and reliable by the use of prototypes of graphical user interfaces to derive technical specifications from. Therefore, lately archived advantages could lead to an increase of inner and outer product quality. 2

4 Vorwort Diese Bachelor-Thesis wurde im Zeitraum vom 9. Dezember 2010 bis zum 30. Mai 2011 verfasst und baut im Implementierungsteil thematisch auf die im Studiengang Angewandte Informatik im 6. Semester angebotene Pflicht-Lehrveranstaltung Projekt 2 auf. Alle notwendigen Informationen über die thematische Verzahnung der Thematik dieser Thesis mit der Thematik aus Projekt 2 werden an den geeigneten Stellen gegeben. Das für diese Thesis entwickelte Frontend implementiert eine voll funktionsfähige graphische Benutzeroberfläche, die einerseits die Neuauflage des Frontend des in Projekt 2 entwickelten Tool Inspector C 1.0 darstellt und andererseits als GUI-Prototyp zu Erklärungszwecken für den neu entwickelten Softwareentwicklungsprozess Scrum SD herangezogen wird. Fachbegriffe bzw. gängige Ausdrücke aus der Software-Branche sind jeweils mit einer hochgestellten Nummer versehen. Sie finden die Definitionen dieser Begriffe in den Begriffsdefinitionen nach dem Inhaltsverzeichnis. 3

5 Danksagungen Ich widme diese Abschlussarbeit meinen Eltern und Großeltern und danke ihnen damit für ihre langjährige Unterstützung während meiner Schulzeit und während meines Studiums. Desweiteren möchte ich mich bei meinem Erstbetreuer Professor Dr.-Ing. Daniel Fischer und bei meiner Zweitbetreuerin Dr. Eva Decker für ihre unterstützenden Kommentare und die reibungslose Kommunikation mit beiden bedanken. Offenburg, Mai

6 Inhaltsverzeichnis Abstrakt (Deutsch)... 1 Abstract (English)... 2 Vorwort... 3 Danksagungen... 4 Inhaltsverzeichnis... 5 Begriffsdefinitionen Einführung Problemstellung Motivation Zielsetzung Der heutige Stand der Technologien Heutige Entwicklungsumgebungen und GUI-Designers Microsoft.NET-Framework User Experiences mit Infragistics Microsofts IDE und Presentation Foundation Heutige Shape-Tools und Mockup-Designers Grundlagen des GUI-Prototyping Vorteile des GUI-Prototyping Arten von Prototypen Low-Fidelity-Prototyping High-Fidelity-Prototyping Graphische Anforderungsanalyse Storyboard-Entwicklung mit dem Kunden Fachliche Analyse

7 4.2.1 Eigenschaften einer Anforderung FURPS+ und IEC SOPHIST-Schablone Zusammenfassung Technische Analyse Schnittstellenanalyse Komponentenanalyse Items-Analyse Zusammenfassung Storyboard-getriebene Frontend-Entwicklung Scrum im Überblick Artefakte in Scrum Rollen in Scrum Ablauf von Scrum Vor- und Nachteile von Scrum Agile Softwareentwicklung mit Scrum SD Rollen in Scrum SD Artefakte in Scrum SD Ablauf von Scrum SD Zusammenfassung Konzeption des Frontend Single View Konzept Eigenschaften-Dialoge Implementierung des Frontend Thematik aus Projekt Validierung des Frontend

8 7.2.1 Moderne Wizards Anwender-orientiertes Design Manipulation von Items Zusammenfassung und Ausblick Rechtliche Übertragungen Eidesstattliche Erklärung Tabellenverzeichnis Abbildungsverzeichnis Listenverzeichnis Abkürzungsverzeichnis Literaturverzeichnis Internet Links Anhang A FURPS+ Kategorien von Hewlett Packard ISO 9126/IEC Kategorien Anhang B Features des Frontend von Inspector C Installationsvoraussetzungen Anhang C Programmcode einer abgeleiteten Schnittstelle (C#) Anhang D Die drei Wizard-Typen in Inspector C Anhang E CD mit C#-Programmcodes des Frontend und Screenshots

9 Begriffsdefinitionen Kunde 1 In dieser Thesis wird generell nicht zwischen den Begriffen Kunde, Stakeholder und Anwender in Bezug auf Projektbeteiligte unterschieden. Der Begriff Kunde steht meist stellvertretend für alle drei Begriffe, um Missverständnisse zu vermeiden. Proof-of-Concept 2 Ein Proof-of-Concept ist ein Machbarkeitsnachweis, der die Durchführbarkeit eines Vorhabens meist anhand von Kernfunktionalitäten eines Prototyps belegt. Control 3 Controls sind Steuerelemente auf einer graphischen Benutzeroberfläche wie z. B. ein Button, eine Drop Down Box oder ein Schieberegler. Deployment 4 Das Deployment beschreibt in der Informatik den kompletten Einrichtungsvorgang einer Software. Dieser Vorgang kann verschiedene Teilvorgänge beinhalten z. B. das Verteilen von Software-Komponenten auf verschiedene Rechner (Distribution), den Installationsvorgang (Installation), das Anstoßen von Dritt-Komponenten (z. B. Application Server) uvm. zur Inbetriebnahme der Software. Frontend 5, Backend 8 Das Frontend ist der Teil der Software, der Software-architektonisch näher am Endanwender liegt. Meist ist dies die graphische Benutzeroberfläche. Das Backend hingegen ist der eher entferntere Teil, auf den der Endanwender keinen direkten Zugriff hat (z. B. Business Logik, Business Domain Model, Datenbank-Backend, Web-Server). Legacy 6 Alt-, Altlast-, älter oder schon bestehend, Legacy-Anwendung = Altanwendung 8

10 Annotation 7 Annotations sind Anmerkungen zu einem Kontext. Hier sind ergänzende Beschreibungen zu Benutzeraktionen und zur Benutzerführung (uvm.) eines Storyboard gemeint. Solution 9 Mit Solution ist hier eine Tool-Suite gemeint, die essentielle Entwicklerwerkzeuge für Anwendungsentwickler enthält (u. a. die Tool Chain). All-in-One 10, Out-of-the-Box 12 All-in-One bedeutet hier, dass eine komplette Solution bzw. Tool-Chain von genau einem Software-Hersteller bezogen wird. Out-of-the-Box ist eine Betonung dafür, dass eine Software bestimmte Funktionalitäten im Lieferumfang bereits enthält. Die Funktionalitäten müssen daher nicht erst noch durch Zukauf erworben oder heruntergeladen werden. Webinar 11 Ein Webinar ist ein Seminar, das über das Internet (Web) gehalten wird. State-of-the-Art 13 Der Begriff State-of-the-Art ist ein Ausdruck für den neusten Stand einer Entwicklung. In der Informatik ist dies die neuste Version einer Technologie oder einer Anwendung. Item 14 Items sind im GUI sichtbare und meist interaktive (manipulierbare) Objekte aus der Kunden-Domäne. Sie dienen dem Anwender zur Erledigung von Arbeitsaufgaben. Code Behind 15, Code Base 16 Der Begriff Code Behind wird nur in der Frontend-Entwicklung verwendet. Er beschreibt den Programmcode, der für die GUI-Komponenten (im Hintergrund) von einem GUI- Designer generiert wird. Der Begriff der Code Base dagegen ist allgemein gebräuchlich und betont eine bestimmte Programmcode-Basis (Bestand). Dabei kann Code Base auch eine Revision eines Programmcode beschreiben. 9

11 Wiring 17 Unter dem Begriff des Wiring versteht man das Anbinden von Controls einer graphischen Benutzeroberfläche durch Programmcode (Event-Handler-Methoden). Der Begriff wird verwendet bei GUI-Editoren, die diese flexible Anbindung bieten (z. B. MS Visual Studio). Wizard-of-Oz-Prototyp 18 Bei Wizard-of-Oz-Prototypen hat der Anwender den Eindruck, er würde mit einem System interagieren z. B. bei einem Usability-Test. In Wirklichkeit aber interagiert er mit einem Entwickler, der das System glaubhaft bedient (z. B. für Server/Client Test einer Suchanfrage). Feature 19 Der Begriff Feature wird hier gegenüber dem Begriff der Benutzeraktion abgegrenzt, da ein Feature in der Regel eine Menge von Benutzeraktionen beinhaltet. Walkthrough 20 Ein Walkthrough ist eine besondere Review-Technik. Das Ziel eines Walkthrough ist es, möglichst alle Fälle eines Konzeptes zu durchlaufen, um es zu validieren bzw. Fehler darin zu finden. Dazu führt ein Entwickler (einen) andere(n) Entwickler oder einen Kunden durch das erstellte Konzept, damit diesem Fehler auffallen. Das Konzept ist im Kontext dieser Thesis der GUI-Prototyp bzw. das Storyboard. Big Bang 21 Der Begriff des Big Bang beschreibt in der Informatik das plötzliche Zusammentreffen von Problemen bei der Integration verschiedener Softwarekomponenten eines zu entwickelnden Softwaresystems, deren gemeinsame Schnittstellen nicht passen, da sie von min. einer zu integrierenden Komponente nicht (vollständig) implementiert werden. Truck Hit Factor 22 Der Truck Hit Factor beschreibt die fiktive Situation, dass ein Entwickler mit viel Projektwissen von einem Truck (LKW) überfahren wird und damit sein ganzes Wissen auf einmal verloren geht. Diese Situation wird auch noch dadurch verschlimmert, da die verlorengegangenen Inhalte vorher nicht dokumentiert wurden. 10

12 Action-Transcription-Pattern 23 Das Action-Transcription-Pattern ist ein eher selten benutztes Anti-Pattern, das in Verbindung mit der GUI-Programmierung und der agilen Softwareentwicklung dennoch zum Einsatz kommt. Es drückt aus, dass durch die grundliegend Feature-orientierte Entwicklungsweise der agilen Softwareentwicklung unweigerlich und implizit bei der Implementierung Slices (funktionale Durchstiche) erzeugt werden, die zusammengenommen kein geschlossenes Architekturbild, sondern voneinander isolierte bzw. direkt übertragene (transcripted) Aktionen (actions), ergeben. Diese Slices können demnach auch nach Belieben unterschiedlich implementiert sein. Dies geht soweit, dass Funktionalitäten in falschen Verantwortlichkeitsbereichen (Komponenten) implementiert werden, wie z. B. eine Datenbank-Verbindung im Button-Event-Handler (Frontend), nur um das Feature zwar schlecht, aber trotzdem umzusetzen. Refactoring 24 Als Refactoring bezeichnet man in der Informatik das Zerlegen von Programmcode genau dann, wenn der Programmcode schon als abgeschlossen gilt. Dabei spielt es keine Rolle, ob der Programmcode temporär (Iteration) oder vollständig abgeschlossen (Projektende) ist. Der Begriff Refactoring ist negativ vorbelegt, da nachträgliche Änderungen am Programmcode eine zeitliche Verzögerung des Projektverlaufs bedeuten können. Traceability 25 Mit dem Begriff Traceability lassen sich beliebige Rückverfolgungen beschreiben. Er bezeichnet aber meist die formale Rückverfolgung von Anforderungen. Dabei können bei einer vollständigen Traceability im einfachsten Fall Implementierungen von Anforderungen rückverfolgt werden. 11

13 1 Einführung Um in Zukunft erfolgreich Software-Produkte und -Dienste entwickeln zu können, benötigt es heutzutage schon ein interdisziplinäres Entwicklerteam, das auf mehr Schichten agiert, als nur auf einer rein technischen. Das liegt unter anderem an der ständig wachsenden Verbreitung und Akzeptanz von Software, die beide ihrerseits einen erheblichen Teil an Nicht-Funktionalität fordern. Erfahrungen im Interaktionsdesign, im visuellen sowie im Industriedesign sind daher bis heute essentiell wichtig geworden. Mit den heutigen Möglichkeiten und Mitteln für Softwaresysteme herausragende graphische Benutzeroberflächen und eine einfache Benutzerführung zu entwickeln, steigen aber auch zugleich die Anforderungen an das Entwicklerteam. Neben dem Pflichten- und dem Lastenheft stellt der Prototyp einer graphischen Benutzeroberfläche heutzutage und auch in Zukunft eine der wichtigsten und offensichtlichsten Kommunikationsgrundlagen mit dem Kunden 1 dar. 1.1 Problemstellung Nach [FNB07] sind Entwicklerteams und Stakeholders dabei zu erkennen, dass Software- Projekte Ressourcen-sparender ablaufen können und im Gesamtaufwand geringer ausfallen können, wenn im Projektverlauf früh ein konkretes Bild des Software-Produktes anhand von GUI-Prototypen erarbeitet wurde, das allen am Projekt beteiligten Parteien vertraut ist und unmissverständlich verstanden und verinnerlicht werden kann. Durch eine verbildlichte bzw. weniger abstrakte Kommunikationsweise mit dem Kunden, haben sich innerhalb wie auch außerhalb der Software-Projekte essentielle Verbesserungen beim Erfassen von Anforderungen an die zu entwickelnden Anwendungen ergeben, die sich zudem mit der formalen Erfassung von Anforderungen und mit der technischen Planung von Software (UML) komplettieren lassen. Die Modellierung eines GUI-Prototyps einer zu entwickelnden Anwendung mit modernen Prototyping-Tools hat in der Vergangenheit, gerade auch in der agilen Softwareentwicklung, einen Aufschwung erlebt, der dem GUI-Prototyp mittlerweile einen mindestens genauso hohen Stellenwert einräumt, wie den traditionellen technischen Proof-of-Concept 2 -Ansätzen (technische Machbarkeitsstudien). Ein GUI-Prototyp ist aussagekräftiger und ergiebiger als es konventionelle 12

14 fachliche Analysetechniken sind. Obwohl es im Usability Engineering schon konkrete Methoden zur Modellierung von GUI-Prototypen gibt, wurde noch kein Softwareentwicklungsprozess beschrieben, der GUI-Prototypen integriert und strukturiert verwendet, um daran fachliche und technische Anforderungen des zu entwickelnden Softwaresystems abzuleiten. Dadurch, dass es solch einen Softwareentwicklungsprozess nicht gibt, leitet sich die Motivation für diese Thesis ab, die Abschnitt 1.2 nun formuliert. 1.2 Motivation Da in der Praxis bzw. in der Anwendungsentwicklung nach [SNM10] sehr häufig schon GUI-Prototypen von entstehenden Softwaresystemen eingesetzt werden, sind hier die Potentiale Risiken, wie Irrtümer von Entwicklern, Missverständnisse von Kunden und Entwurfsfehler schon in der Anforderungsanalysephase stark reduzieren zu können, am größten. Der GUI-Prototyp, der zu entwickelnden Anwendung, ist bereits in der Lage, das Abbild einer Domäne in Softwareform technisch bedienbar als graphische Darstellung wiederzugeben und ist somit durch seine Nähe zum zu entwickelnden Software-Produkt der konventionellen Geschäftsprozessmodellierung überlegen. Ein GUI-Prototyp kann bestimmte Problemlösungen einiger in der Anwendungsentwicklung immer wiederkehrender Problemfelder, die sich während der Entwicklung von Anwendungen ergeben, stark vereinfachen. Liste nennt die wichtigsten dieser Problemfelder. Herausfinden der Interaktionsmöglichkeiten (Benutzeraktionen, Controls 3 ) Herausfinden der Benutzerführungen (Ansichten, Dialoge) Herausfinden der Rollen und Rechte (Autorisierungskonzepte, Anwenderklassen) Herausfinden des Deployment 4 (Installation und Verteilung) Aufbau eines Bezuges zum späteren Mengenmodell der Anwendung (Performance-Abschätzung) und iteratives Verbessern der Kunden-Kommunikation Iteratives Ausbauen des Verständnisses der Kunden-Domäne (fachliches Modell) Iteratives Verbessern des Frontend 5 bzw. der Bedienung der Anwendung Iteratives Erweitern des Kenntnisstandes über Erfahrungen der Anwender mit Controls, Controls aus Legacy 6 -Anwendungen oder der Legacy-Anwendung selbst Liste 1.2.1: Problemfelder der Anwendungsentwicklung, die GUI-Prototypen leichter lösen. 13

15 Die Zielsetzung dieser Thesis ergibt sich somit wie im nächsten Abschnitt 1.3 geschildert. 1.3 Zielsetzung In der Anwendungsentwicklung werden GUI-Prototypen für zu entwickelnde Anwendungen meist mit zusätzlichen Beschreibungen (Annotations 7 ) versehen, die die Benutzeraktionen und die Benutzerführungen, ähnlich wie in einem Storyboard aus der Spielfilmbranche, beschreiben. Daher sind diese GUI-Prototypen auch unter dem Begriff der Storyboards in der Informatik bekannt geworden. Ein Storyboard definiert im traditionellen Sinne einen Handlungsverlauf in Form einer Aneinanderreihung von Konzeptszenen eines zu drehenden Films. Um eine Vorstellung von einem traditionellen Storyboard zu bekommen, zeigt Abb beispielhaft eines für einen Spielfilm (Star Trek) mit seinen Leserichtungen. Abb : Traditionelles Storyboard aus der Spielfilmbranche mit seinen Leserichtungen. [2DF11] Definition : Storyboard (in der Informatik) [RF10] Ein Storyboard zeigt mithilfe der Benutzerschnittstelle, wie ein System oder Produkt verwendet wird. Es stellt wichtige Aspekte der Anwendung bildlich dar und dient damit der Kommunikation zwischen allen Beteiligten. Im Wesentlichen handelt es sich dabei um die Visualisierung eines Szenarios Abhängig vom Kommunikationszweck kann ein Storyboard in unterschiedlichen Ausprägungen erstellt werden. Die Palette reicht von skizzenar- 14

16 tigen oder realistisch gestalteten Abfolgen der Benutzerschnittstelle (User Interface Storyboard) bis zu Bildergeschichten, die auch Kontext und handelnde Personen darstellen. Aus Definition kann die Zielsetzung für die Thesis abgeleitet werden. Es wird demnach ein neuartiges Vorgehensmodell für die Anwendungsentwicklung vorgestellt, das Anwendungsentwickler durch die Verwendung von Storyboards der zu entwickelnden Software unterstützt. Dazu stellt das neue Vorgehensmodell das Storyboard in seinen Mittelpunkt und ermöglicht es den Anwendungsentwicklern bei der Entwicklung neuer Anwendungen Storyboard-getrieben vorzugehen. Dazu werden das Frontend, Teile der Business-Logik und Teile des Domain-Backend 8, der zu entwickelnden Software, über fachliche und technische Analysen des Storyboard inkrementell und iterativ bestimmt. Die graphische Anforderungsanalyse, die den Kern des Storyboard-getriebenen Vorgehensmodells darstellt, wird im weiteren Verlauf der Thesis vorgestellt und in ein agiles Vorgehensmodell integriert. Kapitel 2 gibt nun einen Überblick über die Software-Technologien, die heutzutage in der Anwendungsentwicklung verwendet werden. 2 Der heutige Stand der Technologien Alle Software-Technologien in der Anwendungsentwicklung wie z. B. Technologien zur Entwicklung von Desktop- oder Serveranwendungen, aber auch Technologien zum Persistieren oder zum Abfragen von Daten über Web-Services, sind die temporären Ergebnisse einer stetigen und rapiden Anpassung an äußere Gegebenheiten. Diese Anpassung wird durch die Anforderungen an die Funktionalitäten, an die Umstände und an die heterogenen Einsatzgebiete der Software-Produkte immer weiter vorangetrieben. Dabei etablieren sich meist diejenigen Technologien in der Anwendungsentwicklung, die sich zugleich als robuster, flexibler und mächtiger gegenüber bestehenden Tools und kompatibel zu bestehenden Sprachtechnologien erweisen. Durch die hohen Anforderungen an alle diese Eigenschaften, dominieren die Technologien des Software-Unternehmens Microsoft den heutigen Markt der ganzheitlichen, proprietären Solutions 9 in der Anwendungsentwicklung. Im weiteren Verlauf des zweiten Kapitels werden somit die Teilbereiche der Anwendungsentwicklung und ihre momentan aktuellen Solutions genauer beleuchtet. 15

17 2.1 Heutige Entwicklungsumgebungen und GUI-Designers Tabelle gibt einen groben Überblick über die derzeitige Entwicklungsumgebungen und GUI-Designers, die im Bereich der Anwendungsentwicklung heutzutage im Einsatz sind. Software-Hersteller, die All-in-One 10 -Solutions anbieten, die das gesamte Spektrum an Funktionalitäten für Anwendungsentwickler abdecken, sind nach Tabelle die Ausnahme und bringen immer unvermeidbare Abhängigkeiten mit sich, die aber meist durch zusätzliche Dienstleistungen, wie z. B. eine integrierte Online-Produktdokumentation, ein intelligentes Code-Handling (z. B. MS IntelliSense) oder Entwicklerschulungen (Webinars 11, Trainings, Tech Summits etc.) kompensiert werden. Wie man in Tabelle erkennt, sind die meisten Technologien aus der Anwendungsentwicklung, wie ihr Umfeld überwiegend heterogen. IDE GUI Designer Framework/Sprache Plattform Visual Studio 2010 (Microsoft) WinForms Designer (integriert) WPF, Visual C#, Visual Basic, Visual F#, ASP.NET, C, C++/CLI Windows XP, Vista, 7 und MS.NET Expression Blend 4 (Microsoft) SketchFlow (eigenständig) WPF, Silverlight, XAML, C#, VB Windows XP, Vista, 7 und MS.NET Eclipse (Open Source) Jigloo, Window Builder Pro, Visual Builder, JFormDesigner (integrierbar) Java SE/EE, PHP, Java Script, C, C++, Ruby, COBOL Plattformunabhängig (Java RE) NetBeans 7 (Open Source) Matisse Swing GUI Builder (integriert) Java Web/FX, ME/SE/EE, Ruby, Groovy, PHP, Java Script, C, C++, FORTRAN Plattformunabhängig (Java RE) JDeveloper 11g (Oracle) Oracle Forms (eigenständig) Java, XML, PL/SQL, HTML, JavaScript, BPEL Plattformunabhängig (Java RE) JIDE (JIDE Software) JIDE (integriert) Java Plattformunabhängig (Java RE) IntelliJ IDEA 10 (JetBrains) IntelliJ IDEA (integriert) Java, Groovy, JavaScript, Ruby/JRuby, SQL, PHP, ColdFusion uvm. Plattformunabhängig (Java RE) Tabelle 2.1.1: Überblick derzeitiger Solutions für Entwicklungsumgebungen und GUI-Designers. 16

18 All-in-One-Solutions vereinfachen auf Entwicklerseite die Evaluierung, der für ein Software-Projekt in Frage kommenden Technologien um ein Vielfaches, da alle Funktionalitäten solcher Solutions nahtlos ineinander greifen und somit das Entwickeln stark vereinfachen. Insbesondere zahlen sich solche Solutions auch in der längsten Phase des Produktlebenszykluses einer Software (Wartungs- und Supportphase) durch ihren direkten und verlässlichen Support aus (First-, Second-, Third-Level-Support). 2.2 Microsoft.NET-Framework 4 Das.NET-Framework ist eine für die Anwendungsentwicklung konzipierte Software- Plattform, die von Microsoft entwickelt wird. Sie ist frei verfügbar und dient zur Vereinheitlichung der Windows-Desktop-, Windows-Web-, Windows-Device- und Windows- Cloud-Programmierung. Sie kann als das zukünftige technologische Paradigma für die Entwicklung unter dem Betriebssystem Microsoft Windows verstanden werden und ist somit die Voraussetzung für alle.net-programmiersprachen,.net-anwendungen und.net-dienste. Viele der heutzutage entwickelten Windows-Anwendungen setzen bereits auf das.net-framework auf, da es reichhaltige Funktionsbibliotheken und Schnittstellen, eine leichtere Ansteuerung der Hardware (Treiberanbindung), einen leichteren Umgang mit Dateien und Datenbanken (Zugriff auf Ressourcen durch Abstraktion der Datenquellen), ein ausgefeiltes Eventsystem für die GUI-Programmierung, eine umfangreiche Fensterbibliothek (WinForms) bzw. einen komplett skalierbaren Presentation Layer (Windows Presentation Foundation) sowie ein robustes Exception-Handling und Debugging uvm. Out-of-the-Box 12 für Anwendungsentwickler bereitstellt. Anwendungsentwickler können sich dank des.net-framework wieder mehr auf die zu entwickelnde Business-Logik konzentrieren und müssen sich daher weniger mit technischen Details auseinandersetzen. Abb zeigt den Stack des.net-framework und gibt einen Eindruck über dessen riesigen Funktionsumfang. Viele neue Funktionalitäten sind in der vierten und neuesten Version des.net- Framework hinzugekommen, die das Entwickeln unterschiedlicher Projekte noch einfacher machen. Einige der nennenswerten Neuerungen der vierten Version sind in Liste 17

19 2.2.1 zusammengefasst und stellen zugleich den technologischen State-of-the-Art 13 im Bereich der Anwendungsentwicklung dar. Unterstützung von Multi-Touch-Geräten in Windows 7 Unterstützung des Ribbon Control Erstellung von WPF-Anwendungen in Visual Studio per Drag-and-Drop Productivity Framework ASP.NET MVC 2 ASP.NET AJAX Framework ASP.NET Dynamic Data ADO.NET Entity Framework v2 Unterstützung mehrerer Prozessorkerne - Parallel Computing Parallel LINQ (PLINQ) Dynamische Programmiersprachen (F#, IronRuby und IronPython) Managed Extensibility Framework (MEF) Side-by-Side Kompatibilität Liste 2.2.1: Nennenswerte Neuerungen der 4. Version des Microsoft.NET-Framework. [MS1] Abb : Stack des gesamten Microsoft.NET-Framework ab der Version 2.0. [Wik2] 18

20 2.3 User Experiences mit Infragistics Das Unternehmen Infragistics ist durch seine performanten Controls [IG1] führend im Bereich der Entwicklung von GUI-Komponenten zur Entwicklung graphischer Benutzeroberflächen bzw. User Experiences (UX) für MS.NET und andere Basis-Technologien. Die Technologien von Infragistics ermöglichen es Entwicklern von graphischen Benutzeroberflächen ihre Frontends sehr intuitiv durch eine ansprechende optische Gestaltung und flexibel durch funktionsreiche moderne Controls zu entwickeln und dadurch einen enormen Wettbewerbsvorteil gegenüber klassisch gestalteten Anwendungen zu erreichen. Dabei erweitert Infragistics mit seiner Net-Advantage-Produktfamilie bestehende Basis- Techno-logien. Diese Erweiterungen werden in Liste genannt. NetAdvantage for ASP.NET NetAdvantage for Windows Forms NetAdvantage for WPF NetAdvantage for Silverlight NetAdvantage for jquery NetAdvantage for WPF Data Visualization NetAdvantage for Silverlight Visualization Liste 2.3.1: Von Infragistics erweiterte Basis-Technologien zum Bau von User Experiences. [IG2] Für den Implementierungsteil dieser Thesis wurde das Paket NetAdvantage Windows Forms 2010 Vol. 3 verwendet. Es beinhaltet WinForms-Controls, die in ihren Funktionalitäten stark erweitert sind. Im Lieferumfang des Paketes ist unter anderem auch die neuartige Ribbon-Menüleiste, bekannt aus den Microsoft Office Produkten, mit dabei. Sie wird durch den Design-Wizard von Infragistics erst einfach und flexibel programmierbar. Infragistics unterstützt zusätzlich die Gestaltung der ganzen Anwendung durch Stilvorlagen, deren Formatierungsinformationen in ISL-Dateien (Infragistics Style Language) abgelegt sind. Das Aussehen einer Anwendung kann daher flexibel gehalten werden und besser an Kundenwünsche angepasst werden. Auch zur Laufzeit kann somit das Aussehen der Anwendung durch Referenzieren einer anderen ISL-Datei verändert werden. ISL- Dateien sind Human Readable und werden mit einem Infragistics-eigenen XML-Dialekt formuliert. Sie werden oft mit den CSS-Dateien von Websiten oder XAML-Dateien von 19

21 WPF-Anwendungen verglichen. Nur mit dem Unterschied, dass mit ISL-Dateien nur WinForms-Komponenten von Infragistics im Aussehen verändert werden können. 2.4 Microsofts IDE und Presentation Foundation Microsoft Visual Studio 2010 ist die neuste Version der integrierten Entwicklungsumgebung (IDE) von Microsoft. Sie unterstützt die schon in Tabelle erwähnten.net- Programmiersprachen und -Technologien. In dieser Thesis wurde das MS.NET-Framework 4 zusammen mit der Programmiersprache Visual C# und der Entwicklungsumgebung MS Visual Studio 2010 unter dem Betriebssystem MS Windows 7 für den Implementierungsteil verwendet. Die neue skalierbare Präsentationsschicht (WPF) von Microsoft wurde bereits in Abschnitt 2.2 erwähnt. Mit WPF ist es möglich, sowohl Desktop- als auch Web-Anwendungen zu entwickeln, die Hardware-beschleunigt Graphiken (Bitmaps), Graphik-Primitiven (Geometrie) oder Typographie (Schrift) erzeugen und weitere Medien wie z. B. Audio oder Video einbinden können. Die WinForms-Komponenten-Technologie wird trotz der neueren WPF-Technologie noch bis heute durch Firmen wie Infragistics auf dem Technologie-Markt für GUI-Komponenten stark unterstützt und daher wurde in dieser Thesis der älteren Technologie der WinForms der Vorrang gewährt. Die genauen technischen Gründe für die Wahl der Microsoft-Technologien, wie Visual C#, MS.NET und MS Visual Studio 2010 für diese Thesis, gibt Liste wieder. Gute Programmierkenntnisse im Bereich Visual C#, MS.NET, MS Visual Studio und WinForms-Programmierung vorhanden durch Projekt 1 im Studiengang AI. Produktiveres Entwickeln mit MS Visual Studio 2010, als mit NetBeans 6.8 durch ausgereifte, stabile und komfortable Entwicklungsumgebung. Schnelleres und robusteres GUI-Prototyping mit dem WinForms-Designer von MS Visual Studio 2010, als mit Matisse (GUI Designer) von NetBeans 6.8. Bessere Entwicklung der User Experience von WinForms-Anwendungen mit Infragistics Net-Advantage Windows Forms 2010 Vol. 3 (s. Abschnitt 2.3). Liste 2.4.1: Technische Gründe für die Wahl der Technologien von Microsoft und Infragistics. 20

22 2.5 Heutige Shape-Tools und Mockup-Designers Eigenständige Shape-Tools und Mockup-Designers sind Anwendungen, um GUI-Prototypen (s. Kapitel 3, Definition 3.2.1) von graphischen Benutzeroberflächen zu erstellen. Dazu zählen z. B. Microsoft Visio oder Microsoft Sketch Flow. Sie beschränken sich jedoch auf das Aussehen der GUI-Prototypen (Controls sind reine Graphiken) ohne jegliche Interaktivität zu bieten. Mockup-Designers, die Interaktivität bieten, wie z. B. das GUI Design Studio 4 von Caretta, bieten jedoch lediglich die Interaktivitäten als glaubhafte Animationen der Controls und Graphiken, ohne sprachabhängigen Programmcode des Gezeigten zu erzeugen. Vielen Entwicklern reicht diese Art der Interaktivität solcher Tools vollkommen aus, da sie schnell, komfortabel und ohne Wissen eines Graphikers einen GUI- Prototyp erstellen können. Die Testbarkeit durch GUI Testautomation Tools, wie z. B. Ranorex, ist daher durch den fehlenden Programmcode bei beiden Toolarten nicht gegeben. Die meisten Shape-Tools und Mockup-Designers beschränken sich auf das schnelle und komfortable Erstellen, Verändern und Verwerfen von Low-Fidelity-Prototypen (s. Kapitel 3, Abschnitt 3.2.1). Tabelle gibt einen Überblick über die derzeitig aktuellen Lösungen im Bereich des professionellen Low-Fidelity-Prototyping. Shape-Tool/ Mockup-Designer Software-Hersteller Plattform GUI Design Studio 4 Caretta Software MS Windows 2000, NT, XP, Vista, 7 Storyboard Designer Crank Software MS Windows XP, Vista, 7 Antetype ERGOSIGN Technologies MS Windows XP, Vista, 7 Axure RP Pro Axure Software Solution MS Windows XP, Vista, 7, Mac Storyboarding stpsoft (MS Visio Addin) MS Windows XP, Vista, 7 Sketch Flow Microsoft MS Windows XP, Vista, 7 Fireworks CS5 Adobe MS Windows XP SP 2, Vista SP 1, 7, Mac Balsamiq Mockups Balsamiq Studios MS Windows, Mac, Linux und Adobe Air For Desktop MockupScreens 4.29 MockupScreens MS Windows 2000, XP, Vista, 7, Mac LucidChart LucidChart MS Windows XP, Vista, 7 ForeUI 2.7 EaSynthSolution MS Windows XP, Vista, 7, Mac, Linux, Solaris Tabelle 2.5.1: Überblick über die Solutions im Bereich des Low-Fidelity-Prototyping. 21

23 3 Grundlagen des GUI-Prototyping Spricht man von Softwarekomplexität im Allgemeinen, so lässt sich diese auf funktionale und nicht-funktionale Anforderungen herunter brechen. Die Komplexität einer Software lässt sich also einerseits über ihren funktionalen Charakter quantitativ über die Anzahl der Abhängigkeiten ihrer Komponenten durch Metriken und andererseits qualitativ über ihren nicht-funktionalen Charakter über Benutzerstudien erfassen. Tabelle 3.1 zeigt die Entwicklung der Quelltextgröße des Betriebssystems Microsoft Windows über die Zeit und zeigt gleichzeitig dessen Komplexitätsanstieg. Dieser Trend kann auch bei Anwendung festgestellt werden und ist einer der Gründe, warum heutige Anwendungen durch ihren enormen Funktionszuwachs ohne graphische Benutzeroberfläche nicht mehr bedienbar sind. Mit dem Anstieg der Komplexität der Anwendungen stieg ab den 1990er Jahren auch die Komplexität ihrer Bedienung enorm. Dies legt die Schlussfolgerung nahe, dass die graphischen Benutzerschnittstellen auch in Zukunft zunehmend komplexere APIs besitzen werden, um den Anforderungen moderner und intuitiver Benutzeroberflächen noch gerecht zu werden. Die Weiterentwicklung der graphischen APIs, deren Event- Systeme und GUI-Prototyping-Tools trägt entscheidend dazu bei, trotz steigender Softwarekomplexität, die heutigen Anwendungen bedienbar zu halten. Erscheinungsjahr MS Windows-Version Code-Zeilen in Mio MS Windows MS Windows NT MS Windows MS Windows MS Windows MS Windows XP MS Windows Vista (geschätzt) 50 Tabelle 3.1: Entwicklung der Quelltextgröße des Betriebssystems Microsoft Windows. [HO08] Die weiteren Abschnitte dieses Kapitels werden nun näher auf die Thematik des GUI- Prototyping eingehen und erklären, welche Vorteile es bei richtiger Anwendung haben kann und welche Arten von GUI-Prototypen es gibt. 22

24 3.1 Vorteile des GUI-Prototyping Unter GUI-Prototyping versteht man die Erstellung eines GUI-Prototyps einer Benutzeroberfläche eines zu entwickelnden Softwaresystems. Die Hauptaufgabe liegt hierbei im iterativen Sammeln von Feedback des Kunden zum GUI-Prototyp, welches die Erstellung der Anwendung begleiten und steuern soll. Es können somit bereits sehr früh in der Entwicklung Rückmeldungen des Kunden genutzt werden, grundliegende Missverständnisse, Architektur-Entwurfsfehler oder unhandliche Bedienung leichter zu korrigieren, als es später in einem fortgeschrittenen Stadium des Software-Projektes möglich ist. Das spätere meist aufwendigere Korrigieren der eben genannten Fehler, kann mit GUI-Prototyping bei richtiger Anwendung meist stark reduziert werden. Liste gibt eine Reihe von weiteren Vorteilen wieder, die veranschaulichen sollen, dass das GUI-Prototyping den in ihn investierten Zeitaufwand wert ist und die zeigen, dass es große Potentiale hat, Risiken bereits in der Anforderungsanalysephase einzugrenzen. GUI-Prototyping ermöglicht es, Storyboard-getrieben bei der Entwicklung vorzugehen, Anforderungen an Schnittstellen, Komponenten und Items 14 über fachliche und technische Analysen vom GUI-Prototyp abzuleiten und Spezifikationen graphisch festzuhalten. hochwertiges Feedback vom Kunden einzuholen und daher eine Reduzierung der Interpretationsspielräume beim Bau der Dialoge und bei der Auswahl der Controls zu erzielen, da der Kunde die Anwendung schon mit dem GUI-Prototyp gedanklich zu bedienen lernt (ihm wird demnach auch bewusst, wie sich die Anwendung im Fehlerfall verhält). dem Kunden früher einen tieferen Einblick in das der Software zu Grunde liegende Mengenmodell zu geben, da er Möglichkeiten aufgezeigt bekommt, wie er in Zukunft mit großen Datenmengen arbeiten kann. den Entwicklern nach [MA06] frühzeitig die Benutzbarkeit (Usability) und damit die Akzeptanz des entstehenden Softwaresystems mit dem Kunden iterativ zu validieren, da ab einem gewissen Zeitpunkt der Entwicklung immer ein aktueller GUI-Prototyp vorliegt, der als konkrete Grundlage für Benutzbarkeitstests und Systemtests verwendet werden kann. 23

25 Präsentationen (Vision des Kunden) des zu entwickelnden Softwaresystems auszuarbeiten und dem Kunden oder den Stakeholders darzubieten. dem Marketing und dem Vertrieb die geplanten Entwicklungen bereits im Vorfeld mit Kunden zu diskutieren und wertvolles Feedback dazu einholen zu können, was eine noch bessere Orientierung an den Bedürfnissen des Kunden ermöglicht, das Produkt insgesamt attraktiver macht und direkt den Wettbewerbsvorteil der entstehenden Software erhöhen kann. dem Software-Hersteller die eigene Produkt-Roadmap gegenüber den Kunden, Partnern und Stakeholders anschaulich zu vermitteln, um z. B. finanzielle Unterstützungen oder Kaufentscheidungen zu erleichtern. die Projekt-Dokumentationen, Produkt-Handbücher und Hilfesysteme mit GUI- Prototyp-Zeichnungen zu ergänzen (vorausgesetzt diese sind hinreichend gut). Liste 3.1.1: Vorteile des GUI-Prototyping. Im allgemeinen Prototyping unterscheidet man zwischen drei verschiedenen Arten von Prototypen. Diese drei allgemeinen Arten werden im folgenden Abschnitt vorgestellt, in Bezug zum GUI-Prototyping gestellt und hinsichtlich des zentralen Begriffs des Storyboard erklärt. 3.2 Arten von Prototypen Definition (in der Informatik): Prototyp Ein Prototyp steht für ein lauffähiges Stück Software oder eine anderweitige konkrete Modellierung (z.b. Mock-up) einer Teilkomponente des Zielsystems. Dieser Prototyp dient anschließend oft als Basis für eine bessere Kommunikation mit den Kunden oder auch innerhalb des Entwicklungsteams über konkrete Dinge (statt abstrakte Modelle). [Wik1] Nach Definition ist ein Prototyp ein wesentlicher Entwicklungsschritt in einem Konzept, der modelliert (abstrahiert) oder konkret funktional (lauffähig) sein kann, aber in jedem Fall auf den Zweck (kann Teilaspekt sein) bezogen vollständig ist und in jedem Fall zur Veranschaulichung und Klärung von Details eines Konzeptes dient. Abb zeigt u. 24

26 a. die bekannten Arten von Prototypen, wie man sie auch im Software-Engineering findet und markiert diejenigen, die den Storyboards ihre Eigenschaften verleihen. Wie Abb auch zeigt ist der High-Fidelity-Prototyp (s. Abschnitt 3.2.2) durch seinen Detailreichtum und seine zusätzlichen Funktionalitäten sowohl ein horizontaler, als auch ein vertikaler Prototyp. Ein Storyboard kann prinzipiell in zwei unterschiedlichen Ausprägungen (High-Fidelity und Low-Fidelity) vorliegen. Die beiden Ausprägungen stehen für den Detailgrad des GUI-Prototyps bzw. des Storyboard. Der experimentelle und der explorative Prototyp werden dabei zu den Low-Fidelity-Prototypen (schematisch) und nur der evolutionäre Prototyp zu den High-Fidelity-Prototypen (realistisch) gezählt. Abb : Bekannte Arten von Prototypen im Software-Engineering in Bezug auf Storyboards. Bevor die Abschnitte und nun auf das Low- und High-Fidelity-Prototyping eingehen, nennt Liste die sechs Möglichkeiten, die nach [IEEES10] in der Praxis verwendet werden, um GUI-Prototypen zu erstellen. 1. Gestalterisch (Analog: Stift, Papier, Schere) 2. Graphik-Software (z. B. Adobe Photoshop) 3. Präsentationssoftware (z. B. MS Power Point) 4. HTML-Software (z. B. Adobe Dreamweaver) 5. Shape-Editor oder Mockup-Designer (z. B. MS Visio oder z. B. MS Sketch Flow) 6. GUI API (Programmiersprache) (z. B. C#, Java, Action Script) Liste 3.2.1: Erstellungsmöglichkeiten für GUI-Prototypen bzw. Storyboards.[IEEES10] 25

27 3.2.1 Low-Fidelity-Prototyping Low-Fidelity-Prototyping oder Wireframing ist ein Vorgang, bei dem schematische Zeichnungen von graphischen Benutzeroberflächen angefertigt werden. Sie haben keinerlei Funktionalitäten und die gezeichneten einzelnen Ansichten der Anwendung sind nicht miteinander verknüpft. Sie sind nach [YA07] meist einfach und schnell erstellt, verändert oder ganz verworfen. Selbst nicht standardisierte Controls und neuartige Bedienkonzepte können z. B. mit Low-Fidelity-Prototypen aus Papier hinreichend gut und schnell gezeichnet und mit dem Kunden diskutiert werden. Der Schwerpunkt von Low-Fidelity-Prototypen liegt somit auf der einfachen und schnellen Erstellung und Darstellung von nicht interaktiven Oberflächen-Layouts, die dem Kunden lediglich einen Eindruck über die Anwendung selbst, die Benutzeraktionen und die Benutzerführung vermitteln sollen. Die Informationen des Kunden (Stories) werden als Annotations in Form von Notes (Post-Ists), Bubbles (Sprechblasen) oder Boxes (Kästchen) den gezeichneten Ansichten hinzugefügt. Annotations, zur Beschreibung der Benutzeraktionen, Benutzerführung und anderer Anforderungen an den Low-Fidelity-Prototyp, machen ihn zum Storyboard. Abb zeigt exemplarisch ein Low-Fidelity-Storyboard, das mit Stift und Papier erstellt wurde. Die beiden existierenden und in Abb gezeigten Formen von Low-Fidelity-Prototypen unterscheiden sich, obwohl sie beide horizontale Prototypen sind, in ihren Zielen. Der experimentelle Prototyp hat dabei das schlichte Sammeln von Benutzererfahrungen und das Finden von Möglichkeiten zur Realisierung verschiedener Bedienkonzepte zum Ziel (Benutzerführung). Abb : Von Hand gezeichnetes Storyboard (Low-Fidelity). 26

28 Der explorative Prototyp hat hingegen zum Ziel, die Funktionalität der Anwendung herauszufinden, bestimmte Vorgehensweisen in Bezug auf die Funktionalität hingehend ihrer Anwendbarkeit auf konkrete Produkt-spezifische Problemstellungen zu validieren und wichtige Hinweise zu den Funktionalitäten zu dokumentieren (Benutzeraktionen). Beide fallen trotz ihrer Unterschiedlichkeiten im Gesamtaufwand, durch ihre wenigen Details in Graphik und Beschreibungen, prinzipiell gering aus. Storyboards der Form, wie sie mit Punkt 1 der Liste erstellt werden können, werden häufig in Meetings mit dem Kunden für einen ersten Überblick über die zu entwickelnde Anwendung benutzt, jedoch wegen ihrer Ungenauigkeit nie durchgängig bis zum Projektende verwendet. Storyboards der Form, wie sie mit den Punkten zwei bis vier der Liste erstellt werden können, werden hingegen häufig benutzt, wenn weder ein hinreichend gutes Shape-Tool, noch ein hinreichend guter Mockup-Designer im Software-Repertoire des Software-Herstellers zum Erstellen der Storyboards vorhanden ist. Alle in Liste genannten Erstellungsmethoden außer Punkt 6 sind von der Technologie bzw. der Programmiersprache, die zur Implementierung der späteren Anwendung verwendet wird, unabhängig. Abb zeigt noch einmal den ersten Punkt und Abb die Punkte zwei bis vier der Liste bildlich für ein besseres Verständnis. Abb : Papier-Storyboard mit Stencil Kit für Windows Phone erstellt (Low-Fidelity). [ST1] 27

29 Abb : Mit Graphik-, Präsentations-, HTML-Software, Shape Editor oder Mockup Designer erstelltes Storyboard (Low-Fidelity) High-Fidelity-Prototyping Möchte man einen Schritt weiter gehen und einen detaillierteren GUI-Prototyp bzw. ein detaillierteres Storyboard erstellen, um dem Kunden einen noch realistischeren Eindruck über die entstehende Anwendung zu vermitteln, so kann ein High-Fidelity-Prototyp (High- Fidelity-Storyboard) erstellt werden. Bei High-Fidelity-Storyboards wird im Hintergrund meist Programmcode erzeugt (Code Behind 15, s. Abb ). Sie sind nach [YA07] immer abhängig von der Technologie (Programmiersprache) mit der die spätere Anwendung entwickelt wird z. B. VB, Flash, C#. High-Fidelity-Prototypen besitzen meist verknüpfte Ansichten und sogar meist echte Grundfunktionalitäten der späteren Anwendung. Die Ansichten können auf Wunsch sogar aussagekräftige Kundendaten (Dummy-Daten) laden und durch Chart Controls oder Grid Controls anzeigen. Falls im Hintergrund des GUI- Prototyps Programmcode erzeugt wird, kann er sogar einem voll funktionsfähigen Frontend gleichen (wie hier in dieser Thesis). Frontends können, vorausgesetzt ihr Programmcode kann weiterverwendet werden, durch das Software-Projekt hinweg bis zur vollen Reife inkrementell weiter entwickelt werden und bieten daher eine sich stetig verbessernde Kommunikationsgrundlage mit dem Kunden und Code Base 16. Zum Beispiel unter- 28

30 stützt MS Visual Studio 2010 die Frontend-Entwicklung (GUI-Prototyping) durch das Generieren von Programmcode für Controls und Dialoge (u. a. WPF, WinForms). Es stellt zusätzlich ein robustes Wiring 17 -System zur Anbindung der Controls zur Verfügung. Abb zeigt ein Frontend bzw. ein High-Fidelity-Prototyp (schematisch) mit seinen Click- Events und einem kleinen Teil seines Code Behind, der ihm seine Interaktivität verleiht. Das Storyboard in der High-Fidelity-Form eines Frontend ist daher sogar eine lauffähige Anwendung, die sich stetig verbessert und somit den Vorstellungen des Kunden mit seinen Funktionalitäten, seiner Handhabung und seinem Aussehen schneller nähert, als ein Low-Fidelity-Prototyp. Die Zufriedenheit des Kunden und die Qualität des Kunden- Feedback zu einer graphischen Benutzeroberfläche hängt somit direkt vom Detailgrad (Fidelity) des GUI-Prototyps/Storyboard ab. High-Fidelity-Prototypen können daher u. U. zeitsparender erstellt werden, als Low-Fidelity-Prototypen, da das Mitführen ihrer Annotations entfällt und Low-Fidelity-Prototypen durch ihre Ungenauigkeit nach [YPLE08] in der Regel sowieso öfter korrigiert werden, als High-Fidelity-Prototypen. Die Annotations, die ein Storyboard als Artefakt üblicherweise beschreiben, sind bei High-Fidelity- Storyboards weitestgehend schon im Code Behind implementiert und nach [DLW06] schon in Form von Controls und den Verknüpfungen der einzelnen Ansichten und Dialoge gegeben. 29

31 Abb : High-Fidelity-Storyboard erstellt mit MS Visual Studio 2010 (schematisch). Abb zeigt das für diese Thesis mit MS Visual Studio 2010 und Infragistics- WinForms-Komponenten entwickelte Frontend (High-Fidelity-Storyboard) für die Anwendung Inspector C 2.0 aus Projekt 2. Abb : High-Fidelity-Storyboard erstellt mit MS Visual Studio 2010 und Infragistics. High-Fidelity-Prototypen sind bei jedem Projekt in der Anwendungsentwicklung zu empfehlen, solange es die im Projekt verwendete Technologie erlaubt. Ob ein High-Fidelity- Prototyp oder eher ein Low-Fidelity-Prototyp im Projekt eingesetzt werden kann, muss individuell vor dem Projektstart evtl. in einer Technologiestudie überprüft, mit dem Kunden vereinbart und mit dem Projektzeitplan in Einklang gebracht werden. Nachdem Kapitel 3 die Grundlage zum Verständnis des GUI-Prototyping/Storyboarding gelegt hat, wird Kapitel 4 nun die graphische Anforderungsanalyse vorstellen und näher auf das Entwickeln und Analysieren von Storyboards eingehen. 30

32 4 Graphische Anforderungsanalyse Die Phase der Anforderungsanalyse in einem Softwareentwicklungsprozess ist die erste und wichtigste Phase, auf die alle weiteren Entwicklungsphasen aufbauen. In ihr werden die funktionalen und nicht-funktionalen Anforderungen an das zu entwickelnde Softwaresystem erörtert und formuliert, so dass beide Arten von Anforderungen gleichermaßen erfüllt werden. Die Anforderungsanalysephase ist aber auch diejenige Phase, in der die meisten und für den weiteren Projektverlauf schwerwiegendsten Fehler gemacht werden können. Dies liegt nicht zuletzt daran, dass diese Phase zwar Tool-gestützt abläuft, es aber meist aus Zeit- oder Kostengründen versäumt wird, die gesammelten Angaben rückverfolgbar, redundanzfrei, vollständig und eindeutig zu erörtern, zu erfassen und zu dokumentieren (Kommunikationsbarriere) oder die Möglichkeiten der zur Verfügung stehenden Anforderungsanalysetechniken voll auszuschöpfen. In der Anwendungsentwicklung haben sich im Laufe der Zeit verschiedene Techniken zur Anforderungsanalyse etabliert. Alle diese Techniken fokussieren sich auf bestimmte Aspekte eines zu entwickelnden Softwaresystems und sind darauf spezialisiert, Anforderungen unter diesen Aspekten ganz besonders gut erörtern zu können. Liste 4.1 nennt die meisten der etablierten Anforderungsanalysetechniken und erläutert sie kurz. Scenarios (Formulierung der Benutzungsszenarien der Kunden- Domäne) Surveys/Polls (Befragung von möglichen Anwendern, auch online) User Stories (Formulierung von Anforderungen in Alltagssprache) Personas (Formulierung von Anwendereigenschaften, -zielen und -aufgaben) Use Cases (Formulieren von Anwendungsfällen mit dem Zielsystem) Storyboarding (Modellierung der graphischen Benutzeroberfläche) Business Flows (Modellierung von Geschäftsprozessen) Proof of Concept (Machbarkeitsnachweis eines Konzeptes) UML (Formulierung technischer Spezifikationen) Liste 4.1: Etablierte Anforderungsanalysetechniken in der Softwareentwicklung. 31

33 Die Technik des Storyboarding ist im Gegensatz zu den in Liste 4.1 vorgestellten Techniken eher eine vielseitige Technik zur Anforderungserfassung. Sie vereint alle fachlichen Analysetechniken aus Liste 4.1. Abb. 4.1 zeigt die Analysetechniken aus Liste 4.1 nochmals nach ihrem technischen Abstraktionsgrad sortiert. Abb. 4.1: Anforderungsanalysetechniken aus der Anwendungsentwicklung nach Abstraktionsgrad. Wie in Abb. 4.1 deutlich wird, befinden sich nur die Analysemethoden Storyboards und Business Flows auf der Mittellinie des Diagramms. Dies bedeutet, dass beide Analysetechniken Abläufe besonders gut modellieren können, die sowohl fachlich, als auch technisch sind. Demnach können nur die Techniken, die sich auf oder oberhalb der Mittellinie befinden, zur graphischen Anforderungsanalyse ergänzend hinzugenommen werden, bereits a die graphische Anforderungsanalyse die Techniken unterhalb der Mittellinie vereint. Liste 4.2 gibt die technischen Analysetechniken, die zur graphischen Anforderungsanalyse ergänzend hinzugenommen werden können, nochmals wieder. Business Flows (Geschäftsprozessmodellierung) Proof of Concept (Technische Machbarkeitsstudien über Prototypen) UML (Unified Modeling Language) Liste 4.2: Anforderungsanalysetechniken, die die graphische Anforderungsanalyse ergänzen. 32

34 Die graphische Anforderungsanalyse ist eine neuartige Analysetechnik, die das Ableiten von Anforderungen aus einem GUI-Prototyp/Storyboard ermöglicht. Sie vereinfacht die Wahl der geeigneten Anforderungsanalysetechniken in der Anforderungsanalysephase eines Software-Projektes, da sie mehrere fachliche Techniken bereits beinhaltet und nur noch technische Analysetechniken ergänzend zu ihr erlaubt (s. Abb. 4.1). Um also eine graphische Anforderungsanalyse durchführen zu können, benötigt es mindestens ein Storyboard, das eine zu entwickelnde Anwendung abbildet. Da Storyboards immer zusammen mit dem Kunden iterativ und inkrementell entwickelt werden, erklärt Abschnitt 4.1 zunächst den Erstellungsprozess von Storyboards mit dem Kunden. 4.1 Storyboard-Entwicklung mit dem Kunden Zur Erstellung eines Storyboard können die in Kapitel 3, Abschnitt 2, Liste vorgestellten Techniken verwendet werden. Dieser Abschnitt legt sich somit nicht auf eine bestimmte Erstellungstechnik fest. Um einen Kunden an eine zu entwerfende graphische Benutzerschnittstelle heranzuführen, empfiehlt es sich, sich am Modellierungsablauf des allgemeinen Usability Engineering zu orientieren. Abb zeigt den Ablauf des an das Usability Engineering angelehnten Erstellungsmeeting für ein Storyboard. Dabei werden zuerst die Bedürfnisse des Kunden und dessen Vorstellungen erfragt (Abb , Punkt 1) und danach die damit verbundenen Benutzeraktionen modelliert. Die gewonnenen Erkenntnisse werden dann in das Storyboard integriert und zusammen mit den Domänenspezifischen Annotations im Storyboard vermerkt (Abb , Punkt 2). Nach dem die erörterten Informationen in das Storyboard integriert wurden, muss die Benutzeroberfläche nochmal im Gesamtzusammenhang betrachtet werden bzw. validiert werden (Abb , Punkt 3). Ergeben sich durch die Validierung weitere Änderungen im Storyboard, muss zusätzlich validiert werden, ob diese erwünscht sind oder nicht. Ein Storyboard modelliert jeweils ein(e) Dialog/Ansicht der zu entwickelnden Anwendung. Daher muss der in Abb gezeigte Modellierungsablauf mehrmals durchlaufen werden und erstreckt sich daher meist über mehrere Erstellungsmeetings (Sitzungen) mit dem Kunden. 33

35 Abb : Modellierungsablauf für Meetings zur Erstellung von Storyboards. Wenn Erstellungsmeetings mit dem Kunden durchgeführt werden, ist es wichtig, dass diese auf das jeweilige Projekt bezogen immer derselbe Verantwortliche des Softwaredienstleisters übernimmt, damit Kunden Sachverhalte nicht mehrmals erklären müssen und der Verantwortliche sein Domänenwissen stufenweise ausbauen kann. Die Rolle, die der Verantwortliche dabei einnimmt, ist nach [MJ10] die Rolle eines besonderen Analysten/Architect/Key Stakeholder, der im Rahmen des hier neu zu entwickelnden Softwareentwicklungsprozesses Graphical Requirements Engineer (GRE) genannt wird. Dies kann ein Requirements Engineer/Senior Developer/Senior Software Architect mit Erfahrungen im Bereich des RE (Requirements Engineering) sein. Wichtig bei der graphischen Anforderungsanalyse ist, dass der Kunde selber mit seinem Domänenwissen, seinen Erwartungen und seinen Interaktionswünschen im Vordergrund steht und keine abstrakten Objekt- Modelle, keine technischen Best Practices und keine Komponenten/Schnittstellen/Utilities oder Features 19 diskutiert werden. Abb verdeutlicht das hier vorgestellte Grundprinzip eines inkrementellen Erstellungsmeeting für Storyboards noch einmal. 34

36 Abb : Grundprinzip eines inkrementellen Erstellungsmeeting für Storyboards. Die drei Punkte in Abb werden nun im weiteren Verlauf des Abschnittes genauer erklärt. Da der erste Punkt in Abb das Erfassen der Kundenbedürfnisse beschreibt, benötigt der GRE hier viel Erfahrung aus dem Bereich des Requirements Engineering. Der GRE muss also mit Hilfe seiner RE-Erfahrungen den Aussagen des Kunden eine Struktur geben können, die im weiteren Verlauf des Meeting zu weiteren verwertbaren Ergebnissen führt. Dabei muss er die Domäne, die vom Kunden meist als ein Gesamtprozess beschrieben wird, zuerst in viele kleinere isolierte Prozesse zerlegen, diese als einzelne Storyboards (Ansichten und Dialoge der Anwendung) zusammen mit dem Kunden modellieren und anschließend an den geeigneten Stellen wieder miteinander verknüpfen. Der GRE sollte sich bei der Erstellung der Storyboards daher genau markieren, wo die einzelnen Teile später wieder zusammengefügt werden müssen und auch Fachbegriffe des Kunden in die Storyboards (oder in ein Glossar) mit aufnehmen, damit der Kunde sich verstanden fühlt und auch bereit ist, das volle Spektrum der Benutzeraktionen (nicht Features) mit eigenen fachlichen Beschreibungen wiederzugeben. Zur systematischen Erfassung der Tätigkeiten, die ein Anwender mit einem Softwaresystem erledigen können muss, kann der GRE eine HTA (Hierarchical Task Analysis) verwenden, bei der von einer Tätigkeit abgeleitete Benutzeraufgaben in ihre Unteraufgaben soweit zerlegt werden, bis sich nur noch atomare Benutzeraktionen finden lassen. Abb zeigt ein Teil einer HTA für ein Textverarbeitungsprogramm, deren oberste Aufgabe Schreibe Brief aus der Intention: Kundenkorrespondenz in ihre Unteraufgaben zerlegt wird. Dabei stellen die Unteraufgaben von Speichere Brief unter hier exemplarisch die atomaren Benutzeraktionen dar, die nicht weiter zerlegt werden können. 35

37 Abb : Teil einer HTA für ein Textverarbeitungsprogramm. [MH09] Die in Abb gezeigte HTA macht schnell deutlich, dass nicht alles, was auf den ersten Blick wie eine modellierbare Benutzeraktion aussieht, auch wirklich eine bedienbare Benutzerfunktionalität ist. Nur die Blattknoten einer HTA sind direkt als Benutzeraktionen in Form von Controls modellierbar. Alle Knoten darüber bis auf den Wurzelknoten können als Gruppierung (z. B. Menüs, Group Boxes, Panels, Containers, Dialoge etc.) verwendet werden, da sie nur die benötigten Kategorien bzw. Kontexte für Benutzeraktionen darstellen. Der Wurzelknoten an sich entspricht einer Hauptaufgabe in der Intention des Anwenders bzw. in der Tätigkeit, die er mit dem graphischen Benutzeroberfläche des Softwaresystems durchführen will (hier: Kundenkorrespondenz). Die HTA kann sich auch an einer Legacy-Anwendung orientieren und bereits vorhandene Aufgaben oder Benutzeraktionen für das zu erstellende Storyboard neu zerlegen oder direkt übernehmen. Der zweite Punkt in Abb beschreibt einen Integrationsvorgang. Dazu zeigt Tabelle 4.1.1, welche Charakteristika eine Aufgabe im Allgemeinen besitzen. Der GRE sollte diese Tabelle bei einem Erstellungsmeeting zwingend vorliegen haben, um für jede vom Kunden genannte und zerlegte Aufgabe die Tabelle einmal durchgehen zu können, um jede Eigenschaft der Aufgabe einmal beleuchten zu können. Tabelle sollte somit als Checkliste beim Erfassen von Benutzeraktionen zu Rate gezogen werden. 36

38 Kriterium Beschreibung Ziel Grund Inhalt Teilaufgabe Bedingungen Frequenz Repetitivität Wichtigkeit Dringlichkeit Sicherheit Durchführungszeit Handlungsspielraum Offenheit Mit der Durchführung der Aufgabe verfolgtes Ziel (Arbeitsergebnis) Grund oder Ursache für die Durchführung der Aufgabe Arbeitsgegenstände und Inhalt der Aufgabe Hierarchische Aufgliederung und Verfeinerung der Inhalte der Aufgaben in Teilaufgaben sowie Regeln oder Prozeduren zur Abarbeitung der Teilaufgabe (sequenziell, parallel, wiederholt, alternativ, etc.) Besondere Randbedingungen bei der Durchführung der Aufgabe hinsichtlich des Zustandes des Arbeitsumfeldes und der Arbeitsgegenstände (Vorbedingungen, Nachbedingungen) Häufigkeit der Aufgabe in einem Aufgabenspektrum Auftreten direkter Wiederholungen der Aufgabe Inhaltliche Priorität (Bedeutsamkeit) der Aufgabe in einer Menge von Aufgaben Zeitliche Priorität der Aufgabe in Bezug zu anderen, gleichzeitig anstehenden Aufgaben Anforderungen zur Fehlervermeidung bei der Durchführung der Aufgabe Zeitliche Anforderungen an die Durchführung der Aufgabe (Zeitpunkt des Beginns und/oder Abschlusses, Zeitdauer der Durchführung, Wartezeiten) Spielräume der Bearbeiter bei der Zergliederung der Aufgabe und der damit verbundenen Wahl der Arbeitsmittel zur Durchführung der Aufgabe Grad der Formalisierbarkeit einer Aufgabe und ihrer Bearbeitung Tabelle 4.1.1: Allgemeine Charakteristika einer Aufgabe. [MH09] Tabelle setzt die Grundlage, dass der GRE einerseits die Aufgaben richtig einschätzen und diese auch fehlerlos in die Storyboards mit dem Kunden zusammen integrieren kann. Die gesammelten Informationen über die Eigenschaften der Benutzeraktionen werden in den schon erwähnten Annotations in den Storyboards festgehalten. Da der Gesamtprozess der Domäne in Teilprozesse zerlegt wurde und die zu den Teilprozessen gehörenden Tätigkeiten in atomare Aktionen zerlegt wurden, ist auch die festzuhaltende Menge der Zusatzinformationen auf kleine Teilmengen pro Storyboard reduziert worden, so dass alle relevanten Informationen als Annotations in den Storyboards untergebracht werden können. 37

39 Der dritte Punkt in Abb beschreibt einen Validierungsvorgang, bei dem es nicht darum geht, dass der GRE den Kunden dazu drängt, möglichst alle entwickelten Anwendungsszenarien zu bestätigen, sondern vielmehr darum, dass er das Modellierte kreativ hinterfragt und den Kunden auf die Stellen hinweist, an denen es später zu Problemen bei der technischen Umsetzung kommen könnte. Die Review-Technik, die in solchen Validierungen oft zum Einsatz kommt, ist ein Walkthrough 20. Der GRE sollte während des Walkthrough der Storyboards also an den Reaktionen, den Beschreibungen und Vorstellungen des Kunden festhalten, bis dieser dem was er sieht vollkommen zustimmt oder dies explizit verwirft. Auch ein Verwerfen eines Storyboard ist ein gültiger Ausgang einer Validierung. Abb zeigt den gesamten Ablauf der graphischen Anforderungsanalyse als Überblick für die noch folgenden Kapitel. Dabei entspricht der erste Kasten in Abb der in diesem Kapitel vorgestellten Thematik. Die Abbildung soll auch noch einmal zeigen, dass der Kunde im Mittelpunkt der Erstellungsmeetings steht, er weitestgehend ein großes Mitspracherecht in der graphischen Anforderungsanalyse der Storyboards gegenüber dem GRE besitzt und, dass es mehrere Iterationen bzw. mehrere Erstellungsmeetings dauern kann, bis jede Ansicht der Anwendung modelliert, vollständig durch Annotations beschrieben und vom Kunden abgenommen werden konnte. Abb : Gesamtüberblick über den Ablauf der graphischen Anforderungsanalyse. Wenn der Kunde einen modellierten Lösungsansatz akzeptiert oder verwirft, benutzt er meist eine überwiegend Domänen-spezifische Argumentation. Daher sollte der GRE nicht 38

40 versuchen, diese Erklärungen technisch zu sehen. Die Validierung, die im dritten Punkt von Abb angesprochen wurde, darf an dieser Stelle nicht als endgültige Abnahme verstanden werden. Vielmehr entwickeln der GRE und der Kunde die Storyboards inkrementell, so dass später im Verlauf der Entwicklung noch Änderungen am Storyboard gemacht werden können. Die fachliche Analyse ist nun der nächste wichtige Schritt, um die einzelnen Storyboards zu verknüpfen bzw. sie in genau einen GUI-Prototyp zu vereinen. Desweiteren werden weitere tiefergehende fachliche Sachverhalte auf der Grundlage der erstellten Storyboards analysiert und in den Annotations festgehalten. 4.2 Fachliche Analyse Die erstellten Storyboards werden in dieser Phase herangezogen, um direkt an ihnen funktionale, wie auch nicht-funktionale Anforderungen für die zu entwickelnde Anwendung abzuleiten und weitere fachliche Details zu erörtern. Die fachliche Analyse von Storyboards ist immer der vorbereitende Schritt zu einer anschließenden technischen Analyse ohne den Kunden und muss immer im Hinblick darauf betrieben werden. Dies bedeutet, dass es auf keinen Fall versäumt werden darf auch nicht-funktionale Anforderungen mit dem Kunden zu erörtern und die funktionalen Anforderungen so einzugrenzen, dass eine spätere technische Analyse ohne Schwierigkeiten durchgeführt werden kann. Über diesen Aspekt muss sich der GRE während dem Erstellungsprozess immer im Klaren sein, da sonst Anforderungen vergessen werden können. Das Ziel der fachlichen Analyse ist es, die Anforderungen so zu erfassen, dass der Kunde in der nachfolgenden technischen Analyse nicht mehr gebraucht wird bzw. nur noch zu Rate gezogen wird, wenn Missverständnisse oder andere Unstimmigkeiten auftreten. Abb zeigt eine solche fachliche Analyse mit dem Kunden im Überblick. Bei der fachlichen Analyse werden die einzelnen Storyboards aus der vorangegangenen Erstellungsphase miteinander verknüpft und somit ein Teil der Benutzerführung automatisch festgelegt und validiert. Die bisher analysierten und beschriebenen Benutzeraktionen werden hinsichtlich der Verwendbarkeit für die zu modellierenden Items der Domäne validiert. Desweiteren wird besprochen, welche Anwenderklassen, wann und warum verschiedene Benutzeraktionen in der Anwendung durchführen dürfen (Rechte und Rollen), 39

41 ob die Darstellung der Daten im User Interface akzeptiert wird (GUI-Akzeptanz) und angemessen in Bezug auf das Mengenmodell der Anwendung ist. Auch nicht-funktionale Anforderungen müssen beleuchtet werden z. B. wie und mit welcher möglichen Altanwendung die zu entwickelnde Anwendung kollaborieren muss, ob sie eine verteilte Anwendung wird oder auf welche Plattform/Infrastruktur sie beim Kunden letztlich aufsetzt (uvm.), um nur einen kleinen Überblick über die möglichen zu erörternden fachlichen Anforderungen zu geben. Abb : Fachliche Analyse der verknüpften Storyboards zusammen mit dem Kunden. Für die Erfassung von Anforderungen gibt es verschiedene Hilfsmittel. Im weiteren Verlauf des Abschnittes 4.2 werden nun drei von diesen Hilfsmitteln vorgestellt und genauer beleuchtet. Dem GRE stehen somit mindestens drei grundliegende Hilfsmittel zur strukturierten Erfassung von Anforderungen mit dem Kunden zur Verfügung. Liste nennt diese drei Hilfsmittel und erklärt sie kurz. Eigenschaften einer Anforderung (Rolle, Typ, Kategorie, Umsetzung) FURPS+ oder IEC (Kategorisierungen für Anforderungen) SOPHIST-Schablone (Formulierungshilfe für Anforderungen) Liste 4.2.1: Vorgestellte drei Hilfsmittel zur strukturierten Erfassung von Anforderungen. 40

42 Die Eigenschaften einer Anforderung werden nun im nachfolgenden Abschnitt exemplarisch erläutert Eigenschaften einer Anforderung Abb zeigt die allgemeinen Eigenschaften einer Anforderung, dabei kann eine Anforderung aus jeder Kategorie genau eine Eigenschaft besitzen. Liste erklärt (auch durch Beispiele), was sich hinter den einzelnen Eigenschaften verbirgt. Abb : Allgemeine Eigenschaften einer Anforderung. 1. Rolle o Vorgabe (Richtlinien, Standards, Normen, Gesetze, Infrastruktur) o Kundenwunsch (Kunden-Domäne, Fakten, Arbeitsabläufe, Prozesse) o Abschätzung (Annahmen des Entwicklerteams) o 2. Typ o Funktional Der Kontostand wird um den eingezahlten Betrag erhöht. o Nicht-Funktional Deklarativ Der Server muss auf einem Linux-System lauffähig sein. 41

43 Quantitativ Die Antwortzeit des Servers muss unter 2 Sek. liegen. Qualitativ Der Server muss eine hohe Verfügbarkeit aufweisen. 3. Umsetzung o Graduell: Anforderung kann nicht absolut erfüllt werden o Absolut (binäres Verhalten): Anforderung ist ganz oder gar nicht erfüllt 4. Kategorie Als Kategorie kann z. B. eine Kategorie von den zwei schon vorgestellten Kategorisierungsmodellen für Anforderungen genommen werden (FURPS+ oder IEC 25000). Liste : Eigenschaften einer Anforderung. Die beiden Kategorisierungsmodelle zur Erfassung von Anforderungen werden im nachfolgenden Abschnitt genauer vorgestellt und erklärt FURPS+ und IEC Der GRE bei der Anforderungsanalyse wenn möglich am FURPS+ Kategorisierungsmodell orientieren. FURPS+ wurde von Hewlett Packard (Robert Grady und Deborah Caswell) 1987 entwickelt und gilt heute als De-Facto-Industriestandard zur Erfassung von Anforderungen. Liste gibt die Kategorien des FURPS+ Modells wieder. Functionality Usability Reliability Performance Supportability (+) Localizability Liste : Kategorien des FURPS+ Modells. Für eine genauere Auflösung der in Liste gezeigten FURPS+ Kategorien enthält Anhang A die vollständige Tabelle der Kategorien und Kriterien von FURPS+. Auch die ISO 42

44 (International Organization for Standardization) hat mit der Norm ISO 9126 vor einigen Jahren ein weiteres Modell zur Kategorisierung von Anforderungen vorgestellt, um die Softwarequalität sicherzustellen. Die ISO Norm 9126 ging mittlerweile in der Norm IEC auf und ersetzt diese vollständig. Die folgenden Beispiele verdeutlichen die Nützlichkeit solcher Kategorien und erklären exemplarisch einige der IEC Kategorien (s. Anhang A für alle Kategorien bzw. Kriterien des IEC Modells). Functionality Security: Nach dem Hochfahren des Betriebssystems, muss ein Anmeldevorgang des lokalen Benutzers am Lizensierungsserver stattfinden. Reliability Recoverability: Nach einem Komplettabsturz der Anwendung, dürfen max. 2 min. vergehen, ehe die Anwendung wieder hochgefahren und bereit ist. Usability Operability: Die Anwendung muss intuitiv bedienbar sein, so dass der Einarbeitungsaufwand pro Benutzeraktion max. 20 Minuten beträgt. Efficiency Resource Utilization: Wenn die Anzahl der Test-Items überschreitet, muss die zyklische Speicherung ausgesetzt und eine asynchrone Speicherung erfolgen, bis die Anzahl der Test-Items wieder unter gesunken ist. Maintainability Testability: Die Anwendung muss ihre Zustandsinformationen über die Serielle Schnittstelle permanent ausgeben, damit ihre Zustandsübergänge im Fehlerfall überprüft werden können. Liste : Beispiele für Anforderungen aus den meisten IEC Kategorien. Im nächsten Abschnitt wird nun die SOPHIST-Schablone zur strukturierten Formulierung von Anforderungen vorgestellt und genauer erklärt. 43

45 4.2.3 SOPHIST-Schablone Um Anforderungen richtig formulieren zu können, gibt es ein weiteres Hilfsmittel: die SOPHIST-Schablone. Abb zeigt den Ablauf der SOPHIST-Schablone. Liste demonstriert zwei Beispiele formulierter Anforderungen, die mit der SOPHIST-Schablone entstanden sind. Die SOPHIST-Schablone gibt dabei nicht vor, ob fachlich oder technisch formuliert wird, lediglich die Struktur der Formulierung wird vorgegeben. Liste zeigt eine mögliche Anforderung für ein Bibliotheksverwaltungssystem. Die Anforderung wurde einmal fachlich und einmal technisch mit der SOPHIST-Schablone formuliert. Abb : SOPHIST-Schablone zur Formulierung von Anforderungen an ein System. Fachlich: [Condition/User] [Legal Constraint] [System Name] [Enable/Do] [Specific Item] [Operation] Technisch: [Condition/User] [Legal Constraint] [System Name] [Enable/Do] [Specific Item] Falls der Bibliothekar am Bibliotheksverwaltungssystem angemeldet ist, soll es dem Bibliothekar die Möglichkeit bieten eine Bestandsliste der aktuell verliehenen Bücher auszudrucken. Falls die Rolle Verwaltungsmitarbeiter angemeldet ist, muss der Anwender mit der QueryEngine von elibrary über die MySQL-Datenbank abfragen können, welche Bücher momentan im Zustand verliehen sind und diese als Result Set zurück bekommen damit er max. 30 Einträge dieses Result Set pro A4 Seite 44

46 [Operation] über den Druckertreiber an den Drucker schicken kann, um diese auszudrucken. Liste : Fachliche und technische Formulierung einer Anforderung mit SOPHIST-Schablone Zusammenfassung Tabelle gibt die Analysepunkte der fachlichen Analyse noch einmal stichwortartig wieder. Analysepunkt Beschreibung Erfassen Funkt./Nicht-Funkt. Anforderungen Benutzerführung Rechte und Rollen Benutzererfahrungen Items Corporate Identity Erfassen der funktionalen und nicht- funktionalen Anforderungen und Festhalten dieser an den geeigneten Stellen im Storyboard. Erfassen der Benutzerführung bzw. Verknüpfen der einzelnen Storyboards miteinander. Erfassen der Rechte und Rollen bzw. welche Aktionen welche Anwenderklassen wann und warum durchführen dürfen. Erfassen der Erfahrungen des Kunden mit Legacy-Controls und Legacy- Anwendungen. Modellieren der notwendigen, sichtbaren bzw. manipulierbaren Objekte der Kunden-Domäne und deren Hilfsobjekte, die beide zur Erledigung der Arbeitsaufgaben benötigt werden. Erfassen des CI (Corporate Identity) des Kunden (falls vorhanden). Validieren Benutzeraktionen Darstellbarkeit Akzeptanz des GUI Validieren der bereits erstellten Benutzeraktionen aus den Erstellungsmeetings. Validieren der Darstellbarkeit von Kunden-Daten und der Aussagekraft von Items. Validieren des gesamten GUI-Prototyps über Anwenderszenarien. Tabelle : Fachliche Analysepunkte im Überblick. 45

47 Kapitel 4.3 erklärt nun im Folgenden, wie auf Basis der Ergebnisse der fachlichen Analyse, die technische Analyse ohne den Kunden durchgeführt wird und ihre Ergebnisse zu einem modularen Frontend für eine beliebige Ziel-Architektur (Software-Architektur) führen. 4.3 Technische Analyse Die technische Analyse führt der GRE in der Rolle eines leitenden Entwicklers mit seinen Entwicklerkollegen im Team ohne den Kunden durch. Um eine technische Analyse durchführen zu können, werden folgende Annahmen bzgl. der Ziel-Architektur getroffen, die in Liste zusammengetragen sind. Die Ziel-Architektur ist rein exemplarisch und ist vor der technischen Analyse noch nicht vorhanden. Vielmehr entwickelt sie sich während dieser Analysephase. Alle in der fachlichen Analyse erfassten funktionalen sowie nicht-funktionalen Anforderungen sind hinreichend genau spezifiziert worden, um sie technisch umzusetzen oder zumindest technisch zerlegen zu können. Die Beispiel-Software-Architektur ist eine einfache MVC-Architektur (Single Thread, Model View Control) nach Trygve Reenskaug 1979 für interaktive Systeme als Ausgangsbasis für eine beispielhafte Integration der nach der technischen Analyse als Analyseergebnisse abgeleiteten Logik-Komponenten. Da die Software- Architektur hier als Beispiel dient, kann sie jederzeit ausgebaut, anpasst oder verworfen werden. Sie kann auch auf Wunsch auch als Grundstruktur für eine Multi-Threading-Architektur verwendet werden. Jede Schicht beherbergt nur die für sie benötigten Komponenten. Das MVC-Architekturmuster erlaubt in dieser Thesis nur angemessene GUI-Logik, wie das Nachladen und Umwandeln von Items zur Darstellung oder das Delegieren von Benutzeraktionen auf die Business-Logik-Schicht. Die Business-Logik ist in Komponenten gekapselt und erlaubt eine Parametrierung durch das Frontend für eine direkte Manipulation des Domain-Backend. Liste 4.3.1: Software-architektonische Grundannahmen für die technische Analyse. 46

48 Die Begründung dafür, warum hier in dieser Thesis eine MVC-Architektur als Beispielarchitektur verwendet wurde ist, weil die konsequente Trennung der Verantwortlichkeiten durch die Entkopplung der Business-Logik vom Frontend und vom Domain-Backend ein guter Ansatz für die Austauschbarkeit der Komponenten, die Erweiterbarkeit (u. a. Skalierbarkeit) und die Testbarkeit der gesamten Software-Architektur darstellt. Abb zeigt die eben angesprochene MVC-Architektur mit ihren OO-Beziehungen und erklärt die Verantwortlichkeiten der einzelnen Schichten. Damit die Architektur möglichst genau verstanden werden kann, ist in Liste der Anwendungsfall (Slice, vertikaler Durchstich durch die gesamte Architektur) Neues Projekt anlegen beispielhaft gegeben. Er soll veranschaulichen, wie die spätere Software-Mechanik prinzipiell in einer MVC-Architektur funktioniert. Es muss an dieser Stelle nochmals betont werden, dass bei der Anwendung der technischen Analyse anfänglich noch keine Software-Architektur vorhanden ist, um mögliche Analyseergebnisse direkt einordnen zu können, wie es im Verlauf dieses Kapitels demonstriert wird. Vielmehr entwickelt sich die Software-Architektur während der technischen Analyse Stück für Stück. Die technische Analyse ist vollkommen Architekturneutral. Abb : Beispiel-Software-Architektur nach MVC-Entwurfsmuster (Trygve Reenskaug 1979). 47

49 1. Der Anwender klickt im Frontend auf den Tab Project, danach in der Tab Page auf den Button New und legt im Projekt-Wizard (Nachfolge-Dialog) ein neues Projekt nach seinen Kriterien (Parametern) an. 2. Das Frontend stößt nach dem Klicken auf den Finish-Button des Projekt-Wizard (Abschluss des Wizard) gezielt eine Operation eines dedizierten für die Verwaltung von Projekt-Items verantwortlichen Controller in der Business-Logik-Schicht darunter (s. Abb ) über eine Schnittstelle an. Dabei wird der Aufruf an die Business-Logik-Schicht delegiert und die Benutzerdaten, die im Rahmen der Projekterstellung im Frontend gesammelt wurden, übergeben. 3. Der dedizierte Controller in der Business-Logik-Schicht empfängt die Benutzerdaten aus dem Frontend, erzeugt ein neues Projekt (Projekt-Item) mit den Benutzerpräferenzen und übergibt (operiert auf dem Backend) das noch unfertige Projekt-Item über einen Aufruf dem Domain-Backend zur Verwaltung während der Laufzeit der Anwendung. 4. Das Domain-Backend (auch Data Container genannt) führt weitere Verwaltungsoperationen mit dem erstellten Projekt-Item durch, ordnet es in sein Domänen- Modell (strukturelles Abbild der Kunden-Domäne) ein und benachrichtigt das Frontend (den Anwender) über die Zustandsänderung über eine Schnittstelle. 5. Das Frontend nimmt die Benachrichtigung entgegen, werten ihren Update Type aus und aktualisiert das Frontend gezielt, indem es das Projekt-Item darstellt (Aktualisieren einer spezifischen Ansicht bzw. eines spezifischen Control, z. B. TreeView). Der Anwender sieht nun sein neu angelegtes Projekt als manipulierbares Projekt-Item (in der TreeView) im Frontend und kann damit arbeiten. Zusätzlich kann eine Meldung in der Statusbar des Frontend gezeigt werden. Liste 4.3.2: Anwendungsfall (Slice) - Neues Projekt anlegen. Für diese Thesis wurde nur die oberste Schicht (s. Abb ) bzw. das Frontend der MVC- Architektur umgesetzt. Dabei handelt es sich um ein eigenständiges, voll funktionsfähiges Frontend (s. Kapitel 6). Die Implementierungen der Schichten der Business-Logik und des 48

50 Domain-Backend sind daher nicht Teil dieser Thesis. Im Laufe der Thesis wird an verschiedenen Stellen immer wieder einmal auf dieses Frontend referenziert, um verschiedene Sachverhalte zu erläutern. Screenshots des Frontend sind auf der CD in Anhang E zu finden. Nach der Einführung in die Beispiel-Architektur, wird nun im nachfolgenden Abschnitt der erste Schritt der technischen Analyse beschrieben: die Schnittstellenanalyse Schnittstellenanalyse Um vom Storyboard (Frontend) die für die Controller-Schicht (Business-Logik-Schicht) benötigten Schnittstellen ableiten zu können, werden die Funktionalitätsgruppierungen, Controls und deren Kontexte (Containers, Menüs, Panels, Tabs etc.) aus dem Storyboard untersucht. Ist das Frontend mindestens nach den zwei folgenden wichtigen Softwareergonomischen Gesichtspunkten aus Liste entworfen worden, findet man gleiche Funktionalitäten immer auf dieselbe Weise präsentiert und gruppiert wieder. Die in Liste genannten Gesichtspunkte sind somit die Mindestvoraussetzungen für die Schnittstellenanalyse. Kompaktheit: Dem Anwender werden nur die Informationen gezeigt, die er zur Erfüllung der Arbeitsaufgabe benötigt. Konsistenz: Gleiche Informationen werden entsprechend den Erwartungen des Anwenders immer auf die gleiche Weise dargestellt. Liste : Software-ergonomische Mindestvoraussetzungen für Schnittstellenanalysen. GUI-Elemente, wie Fenster, Menüs, Group Boxes, Drop Down Boxes, Panels, Charts, Tabs oder andere Drittanbieter-Controls (uvm.), gruppieren Funktionalitäten für eine bestimmte Arbeitsaufgabe. Dies ist eigentlich mindestens genau das, was ein für diese Arbeitsaufgabe dedizierter Controller in der Business-Logik-Schicht (darunter) ausmacht. Ist die 49

51 Funktionalitätsgruppierung im Frontend hinreichend vollständig ergonomisch modelliert worden, können daraus Anforderungen für eine spätere Schnittstelle für einen Controller in der Business-Logik-Schicht zur Manipulation von Items abgeleitet werden. Abb zeigt die Ribbon-Menüleiste des für die Thesis entwickelten Frontend und leitet aus den zwei Gruppierungen des Tab Traceability die Schnittstelle IRequirements-Management für einen späteren Controller ab, der sich dediziert um die Verwaltung von Requirement- Items und deren Dokument-Items kümmern soll. Wie der erste Entwurf dieser Schnittstelle in C# spezifiziert sein könnte, ist in Anhang C gegeben. Abb : Schnittstellenanalyse zweier Funktionalitätsgruppierungen aus dem Frontend. Es gibt allerdings auch Einschränkungen bei der Analyse von Schnittstellen über das Frontend. Ist das Frontend nicht vollständig ergonomisch (min. die zwei Punkte in Liste ) mit dem Kunden zusammen modelliert worden, können hier bereits Analysefehler entstehen. Sie führen durch falsches Ableiten zu schweren Folgefehlern im weiteren Verlauf der technischen Analyse. Werden diese Analysefehler nicht umgehend korrigiert, können sogar Probleme bei der späteren Integration der einzelnen Software-Schichten (Big Bang 21 ) entstehen. Man kann somit festhalten, dass umso früher in der technischen Analyse Unstimmigkeiten beim Analysieren auftreten, desto schwerwiegender die Folgefehler im weiteren Verlauf des Software-Projektes sind. Darum müssen Schnittstellenanalysen immer im Hinblick auf spätere Komponenten einer möglichen Ziel-Architektur betrieben werden und Missverständnisse dem Kunden umgehend kommuniziert werden, da 50

52 sie wahrscheinlich in einer Neubewertung der Funktionalitätsgruppierungen im Frontend/Storyboard resultieren. Abschnitt geht nun auf den zweiten Schritt der technischen Analyse ein: die Komponentenanalyse. Sie baut direkt auf den Ergebnissen der Schnittstellenanalyse auf und kann daher immer erst nach ihr durchgeführt werden Komponentenanalyse Wenn alle Schnittstellen aus dem Frontend fehlerfrei abgeleitet werden konnten, ergibt sich ein ähnliches Bild wie es Abb zeigt. Das Frontend kann jetzt schon durch die lose Kopplung der abgeleiteten Schnittstellen modular ausgetauscht werden. Dies ist wichtig, wenn man sich die Vielfalt der heutigen Formate der Gerätedisplays und die daraus resultierenden unterschiedlichen Frontends (Dockingverhalten, Inhaltsreduzierung, Format, Auflösung, Dimensionen, Farbmodell) einmal vor Augen führt, die alle auf dieselbe Kernfunktionalitäten zugreifen können müssen. Durch die Entkopplung des Frontend ist es somit nicht mehr zwingend nötig ein einziges Frontend zu entwerfen, das sich an jeden Graphik-Kontext (Graphik-Modus) jedes Ausgabegerätes anpassen kann. Vielmehr können Frontends getrennt und individuell gestaltet und entwickelt werden. Dies wird gerade im Hinblick auf moderne Präsentationsschichten (wie z. B. Microsofts WPF- Technologie) oder im Hinblick auf verteilte Anwendungen (Client/Server oder Web- Services) immer wichtiger. Die Entkopplung ermöglicht es der Frontend-Schicht daher sogar über ein Rechnernetz hinweg mit der Business-Logik-Schicht/Backend-Schicht der Anwendung zu kommunizieren, z. B. als Thin-Client. Durch das Einhalten vereinbarter Schnittstellen zwischen der Darstellungsschicht (Frontend) und der Business-Logik-Schicht können somit verschiedene Frontends auf die Controller-Schicht aufgesteckt werden. Dieser Mechanismus kann auch für ganz andere Zwecke verwendet werden, z. B. für die spätere Wartung des Softwaresystems über eine Administratorkonsole (minimales Administrator-Frontend zur erweiterten Parametrierung über autorisierte Controller über ein Fassade Pattern). 51

53 Abb : Lose gekoppelte Schichten: modulares Frontend und Business-Logik/Backend. Da die einzelnen Schnittstellen den Controllers die Funktionalitäten zur Manipulation der Items vorgeben, ist die Aufgabe der Komponentenanalyse, die Business-Logik auf eine Einteilung in Komponenten zur Aufgabenbewältigung hin zu untersuchen und den gefundenen Einteilungen bzw. Komponenten mindestens eine der schon analysierten Schnittstelle zuzuordnen. In der MVC Beispiel-Architektur entsteht nach der Komponentenanalyse meist eine ähnliche Einteilung der Business-Logik-Schicht wie in Abb zu sehen ist. Die Business-Logik-Schicht, eingeteilt in die von den Schnittstellen abgeleiteten Komponenten, macht zum ersten Mal sichtbar, wie der Anwender des Frontend die Controllers in der Business-Logik zur Aufgabenbewältigung benutzen wird, um Items für seine Arbeitsaufgaben zu manipulieren. Komponenten, die wiederum Komponenten enthalten oder Controllers, die mit anderen Controllers zusammenarbeiten (kollaborierende Controllers bzw. Controller-Strategien), werden aus den Verantwortlichkeiten der abgeleiteten Komponenten bzw. Controllers oder mit Hilfe der Annotations bestimmt und ergänzt. Sie werden hier nicht weiter beleuchtet, da die Umsetzung vom Know How der Entwickler abhängt und nicht vom Frontend ableitbar ist. Abb deutet die kollaborierenden Controllers aber dennoch an, um einen Eindruck zu bekommen, wie die Controller-Schicht skaliert werden kann. 52

54 Abb : Aus den Schnittstellen abgeleitete Komponenteneinteilung in der Business-Logik. Komponenten, die dem Frontend (dem Anwender) keine Schnittstellen zur Parametrierung bieten, sind für es (ihn) unsichtbar. Weitere unsichtbare Controller werden daher mit Hilfe der Informationen aus den Annotations abgeleitet, da dort die Abläufen bzw. weiteren Funktionalitäten der Anwendung (funktionale und nicht-funktionale Anforderungen) aus der Kunden-Domäne festgehalten sind. Kapitel 5 wird später noch einmal auf die abgeleiteten Controllers zurückkommen und deren Implementierung beleuchten. Das Storyboard selber wird jedoch noch einmal im nächsten Abschnitt wichtig, wenn es darum geht, manipulierbare (sichtbare) Items und (unsichtbare) Hilfsobjekte für das Domain-Backend der Anwendung direkt abzuleiten. Abschnitt wird daher nun die Funktionsweise einer Items-Analyse erklären Items-Analyse Das Domain-Backend einer Anwendung kümmert sich hauptsächlich um die Verwaltung der manipulierbaren Items aus der Anwendung, um deren Hilfsobjekte und um die Integration der beiden Item-Typen in verschiedene Persistenzmedien. Integration bedeutet hier, dass das Domain-Backend Strategien kennt, wie es verschiedene Datenformate speichern (z. B. als TXT, CSV, XML oder DBMS uvm.) oder in die Anwendung hinein laden kann 53

55 (öffnen/importieren). Desweiteren kennt das Domain-Backend auch Skalierungsstrategien, die es ihm erlauben, sein Integrationsverhalten an die Menge der Items anzupassen. Die Arbeitsobjekte bzw. die Items, die der Kunde bei der Erstellung der Storyboards mit dem GRE eingezeichnet hatte, sind die Elemente mit denen er in der späteren Anwendung arbeiten möchte. Sie können für eine Modellierung im Domain-Backend herangezogen werden und für eine Modellierung des Objektmodells der Kunden-Domäne direkt übernommen werden. Die Hilfsobjekte aus dem Domain-Backend, die nicht direkt manipuliert werden können bzw. im Frontend nicht sichtbar sind, werden aus den Verantwortlichkeiten der schon analysierten Komponenten, Controllers, Items oder mit Hilfe der Annotations bestimmt und ergänzt. Hilfsobjekte dienen zur Unterstützung der manipulierbaren Items bzw. einer Arbeitsaufgabe und sind meist abstrakter/technischer Natur für den Anwender, wie z. B. Datenbank- oder Netzwerk-Verbindungen, Positionen, Deskriptoren, Handlers, Mapping-Objekte (uvm.). Manipulierbare Items dagegen können graphische Einzelelemente (oft mit Icon), Listenelemente, zwei- oder drei-dimensionale Elemente (CAD-Modelle in einer Simulations- oder Modellierungsumgebung) sein, können funktions- (Aktion über Hauptmenü) oder objektorientierte Interaktionen (Aktion über Kontextmenü) mit dem Anwender zulassen, die unterschiedlichsten Attribute und das unterschiedlichste Aussehen besitzen. Was sie aber alle gemeinsam haben ist, dass sie alle zu einem bestimmten Maße dazu beitragen, eine Arbeitsaufgabe mit dem Anwender zusammen zu erfüllen. Bei der Items-Analyse macht man daher nichts anderes, als dass man die manipulierbaren Items im Storyboard erst einmal identifiziert und sie damit von ihren Kontexten, wie Containers, Menüs, Panels, Group Boxes (uvm.) trennt. Die identifizierten Items werden danach als Klassen (OO-Klassen) mit ihren Eigenschaften für das Domain-Backend modelliert, um sie später in der Anwendung als Items nutzen zu können. Um eine klarere Vorstellung davon zu bekommen, was bei der Vielfalt der Anwendungen und Abbildungen von Domänen alles ein Item darstellen kann, zeigt Abb die Ribbon-Menüleiste des entwickelten Frontend von Inspector C 2.0 und die darin identifizierten Items aus der Domäne von Projekt 2. Diese sind durch blau umrandete Bereiche markiert und modellieren jeweils eine C#-Klasse. 54

56 Abb : Identifizierte manipulierbare Items im Frontend von Inspector C 2.0. Abb zeigt die um die identifizierten Items erweiterte MVC-Architektur und zeigt beispielhaft, welche bereits abgeleiteten Controllers auf welchen Items arbeiten würden. Abb : Manipulierbare und nicht manipulierbare Objekte in der MVC Beispiel-Architektur. Der Sachverhalt, dass Items geschachtelt vorliegen können und Controllers nur über die kapselnden Items (Wrapper) oder über weitere Schnittstellen auf konkrete Items Zugriff haben, wird hier vernachlässigt, da dies prinzipiell von der speziellen Modellierung der Kunden-Domäne abhängt, die allein die Entwickler festlegen (Know How). Der nächste 55

57 Abschnitt fasst die technische Analyse noch einmal zusammen und zeigt den Ablauf detaillierter mit einem UML Aktivitätsdiagramm Zusammenfassung Abb zeigt den Ablauf der technischen Analyse im Überblick. Abb : Ablauf einer technischen Analyse im Überblick. Wichtig bei der technischen Analyse ist, dass sich das Entwicklerteam bewusst ist, dass sie lediglich strukturgebend ist, so dass in einem weiteren Schritt die konkreten Implementierungen der analysierten Controllers, weiterer Domänen-spezifischer Komponenten und 56

58 weiterer Hilfsobjekte für die zu entwickelnde Anwendung ergänzt wird. Das Entwicklerteam darf im Fall von Unstimmigkeiten, wie in der fachlichen Analyse auch, auf keinen Fall Annahmen treffen, sondern es muss der Kunde zu Rate gezogen werden, um den Fehler über die fachliche Analyse, wenn nötig zurück bis zum Erstellungsprozess des einzelnen Storyboard, verfolgen und beheben zu können. Nachdem die Erstellung der Storyboards, die fachliche und die technische Anforderungsanalyse nun vollständig erklärt wurden, wird die gesamte graphische Anforderungsanalyse in Kapitel 5 in einen agilen Softwareentwicklungsprozess integriert, damit die analysierten Controllers implementiert werden können. Wie dieser agile Softwareentwicklungsprozess von der Storyboard-getrieben Vorgehensweise profitiert, wird in Kapitel 5 ebenfalls erklärt. 57

59 5 Storyboard-getriebene Frontend-Entwicklung Um zu verstehen, wie ein Storyboard einer zu entwickelnden Anwendung im Umfeld der Anwendungsentwicklung platziert und eingesetzt werden kann, wird dieser Aspekt zunächst erklärt. Abb. 5.1 zeigt das vereinfachte Ausgangsszenario der Anwendungsentwicklung mit seinen Kardinalitäten. Es stellt das zu entwickelnde Softwaresystem in Beziehung zum Kunden und Softwaredienstleister. Betrachtet man Abb. 5.1, so wird die Schwierigkeit in einem heterogenen Umfeld Software zu entwickeln schnell deutlich. Zum besseren Verständnis von Abb. 5.1 ist Liste 5.1 gegeben, die das Ausgangsszenario noch einmal beschreibt. Abb. 5.1: Vereinfachtes Ausgangsszenario der Anwendungsentwicklung. 1. Ein Kunde kann mehrere weitere Kunden beauftragen seine Software und seine Server zu verwalten (Systemhäuser). 2. Ein Softwaresystem (z. B. eine Workflow-Anwendung) kann bei einem Softwaredienstleister zur Entwicklung in Auftrag geben werden, der für die Entwicklung des Softwaresystems mit den Kunden seines Kunden in Kontakt treten muss. 3. Die Workflow-Anwendung kann auf Seiten des Softwaredienstleisters wiederum durch mehrere Softwaredienstleister (z. B. Software-Fabriken) umgesetzt werden. Liste 5.1: Zusammenhänge im vereinfachten Ausgangsszenario der Anwendungsentwicklung. Wie Abb. 5.1 deutlich zeigt, ist das gemeinsame Element innerhalb der Schnittmenge der Kunden-Domäne (fachlicher Bereich) und der Softwareentwicklung (technischer Bereich) das zu entwickelnde Softwaresystem. Das heißt ein visueller Prototyp, wie ein Storyboard, stünde genau an dieser Stelle, da er das visuelle Abbild des zu entwickelnden Softwaresystems darstellt. Abb. 5.2 zeigt, wie sich die graphische Anforderungsanalyse in das auf- 58

60 gegriffene vereinfachte Ausgangsszenario der Anwendungsentwicklung demnach integriert. Abb. 5.2: Integration des Storyboarding in das Zentrum des vereinfachten Ausgangsszenarios. Wie man in Abb. 5.2 schnell erkennt, steht das Storyboard als GUI-Prototyp im Mittelpunkt des Ausgangsszenarios und bildet somit die schon erwähnte bildliche Kommunikationsebene zwischen Kunde und Entwickler. Ein zu entwickelnder Softwareentwicklungsprozess sollte deswegen bestehendes Zentrum unterstützen, indem er Kommunikation und Agilität fördert. Ein bekannter Softwareentwicklungsprozess, der das Manifest für Agile Software Development nach Kent Beck (et al.) umsetzt, ist Scrum. 5.1 Definition: Agile Softwareentwicklung Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lat. agilis: flink; beweglich) in der Softwareentwicklung. Je nach Kontext bezieht sich der Begriff auf Teilbereiche der Softwareentwicklung wie im Fall von Agile Modeling oder auf den gesamten Softwareentwicklungsprozess Agile Softwareentwicklung versucht mit geringem bürokratischen Aufwand und wenigen Regeln auszukommen. [Wik3] Aus Definition 5.1 lässt sich erschließen, warum das hier in dieser Thesis vorgestellte neue Vorgehensmodell Scrum als agilen Unterbau nutzt. Scrum unterstützt Kommunikation mit dem Kunden, Agilität bei der Entwicklung, Prototyping als Kernelement und Eigenverantwortung der Entwickler. Das neue Vorgehensmodell wird daher durch die Anlehnung an Scrum: Scrum SD (Scrum Storyboard Driven) genannt und im weiteren Verlauf der Thesis auch so referenziert. Die Anforderungen an Scrum SD gibt Liste 5.2 an. 59

61 1. Ressourcen-, Rollen-Management (Personelle Steuerung - Wer) 2. Aktionsmanagement (Inhaltliche Steuerung - Was) 3. Phasen- und Agilitätsmanagement (Zeitliche Steuerung - Bis Wann) 4. Kommunikation (Informationssteuerung - Wer mit Wem) 5. Anforderungsanalysetechnik (Graphische Anforderungsanalyse) Liste 5.2: Anforderungen an den Softwareentwicklungsprozess Scrum SD. Dadurch, dass Scrum SD das klassische Scrum nutzt, kann es davon profitieren, dass Scrum die Punkte 1-4 aus Liste 5.2 bereits vollständig umsetzt. Damit der Aufbau und der Ablauf von Scrum SD verstanden werden kann, wird im Verlauf dieses Kapitels erst ein tieferer Einblick in Scrum mit seinen Rollen, Artefakten, Aktionen und seinem zeitlichen Verhalten gegeben und danach auf Scrum SD mit seinen Vorteilen gegenüber Scrum eingegangen. 5.1 Scrum im Überblick Bei traditionellen Vorgehensmodellen, wie z. B. dem klassischen Wasserfallmodell, wird angenommen, dass die Entwicklung einer Software eine Sequenz von fest definierten aufeinanderfolgenden Schritten ist. Es werden daher meist alle Anforderungen in einer Analysephase gesammelt, für ein Software-Design verwertet, implementiert und anschließend getestet. Danach geht die entwickelte Software in den Einsatz und befindet sich somit in der Wartungsphase. Abb zeigt die traditionelle Vorgehensweise anhand des klassischen Wasserfallmodells nach Royce, um einen Überblick über die traditionellen Entwicklungsphasen zu bekommen. In diesen Vorgehensmodellen gibt es aus Gründen der Sequenzialität daher so gut wie keine Chance mehr, bei Änderungen z. B. an den Anforderungen, an der Grundidee, an den Zielen oder an technischen Aspekten etwas zu ändern (verbessern) bzw. in der Sequenz der Phasen zurückzugehen. Anders ist dies bei den agilen Vorgehensmodellen. Die agile Vorgehensweise (Definition 5.1) wurde entwickelt, um die Softwareentwicklung allgemein flexibler und schlanker zu gestalten, als die traditionelle. Das Hauptaugenmerk der agilen Softwareentwicklung liegt darauf, die technisch zu lösenden Probleme und sozialen Kompetenzen der Entwickler wieder zurück 60

62 in den Mittelpunkt der Entwicklung zu stellen. Die agile Softwareentwicklung wird daher oft als Gegenbewegung zur traditionellen Softwareentwicklung, wie z. B. dem Wasserfallmodell, dem Rational Unified Process (IBM) oder dem V-Modell angesehen. Abb : Beispiel eines traditionellen Entwicklungsprozesses: Wasserfallmodell (Royce 1970). Software agil zu entwickeln bedeutet, eine Software durch Selbstorganisation und geringem Dokumentationsaufwand zu entwickeln. Agile Vorgehensmodelle bestehen nicht aus einem einzigen großen Ablauf aus konsekutiven Entwicklungsphasen, sondern aus vielen kleinen Iterationen, die dazu da sind, eine lauffähig Teillösung des zu entwickelnden Softwaresystems inkrementell, iterativ und agil weiterzuentwickeln, bis es ab einer bestimmten Reife nahtlos in ein Produkt übergehen kann und abgeschlossen ist. Dabei werden in jeder Iteration alle Entwicklungsphasen vollständig durchlaufen. Abb zeigt den Kern der agilen Vorgehensweise: die Iteration. Bei allen agilen Vorgehensmodellen stehen die folgenden zentralen vier Punkte im Vordergrund, die Liste nochmal deutlich macht. Abb : Der Kern der agilen Softwareentwicklung: die Iteration. 61

63 Personen und Aktionen gelten mehr als Abläufe und Tools. Funktionierende Software gilt mehr, als ausschweifende Dokumentationen. Kommunikation und Zusammenarbeit mit dem Kunden stehen über vertraglichen Vereinbarungen. Engagement und Offenheit gegenüber Änderungen stehen über der Durchführung von festgelegten Schritten. Liste 5.1.1: Zentrale Punkte der agilen Softwareentwicklung. Scrum ist ein Vertreter dieser agilen Vorgehensweise. Dabei spezifiziert Scrum die Planung der Iterationen und definiert feste Rollen, für die an der Entwicklung beteiligten Personen. Wie Scrum im Detail funktioniert, erklären die folgenden Abschnitte bis Artefakte in Scrum In Scrum gibt es nach [SM11] vier verschiedene Artefakte. Liste nennt diese und erklärt ihre Funktionen. Product Backlog Der Product Backlog ist eine Liste mit allen Features der zu entwickelnden Software, die sich der Kunde wünscht (Soll- und Kann-Anforderungen). Er wird vor jedem Sprint (s. Abschnitt 5.1.3) neu bewertet bzw. vom Product Owner (s. Abschnitt 5.1.2) und vom Kunden neu priorisiert. Bei diesem Vorgang können bestehende Features entfernt oder neue hinzugefügt werden. Nach der Bewertung werden die am höchsten priorisierten Features im Aufwand geschätzt und von den Entwicklern in den Sprint Backlog übernommen. Der Product Backlog zeichnet sich dadurch aus, dass er hoch priorisierte Features sehr detailliert beschreibt, niedrig priorisierte eher weniger ausführlich. Durch diese Eigenschaft wird mehr Zeit für wichtigere bzw. wesentlichere Features verwendet, als für unwesentliche. Der Product Backlog enthält auch technische und administrative Aufgaben. 62

64 Sprint Backlog Der Sprint Backlog ist eine Liste mit den zu erledigenden Aufgaben für einen Sprint. Für jeweils eine Aufgabe darf nicht länger als ein Tag gebraucht werden. Längere Aufgaben müssen in Teilaufgaben von jeweils einem Tag Länge zerlegt werden. Sind alle Aufgaben erledigt, so ist der Sprint erfüllt. In einem Sprint können nur so viele Aufgaben eingeplant werden, wie das Entwicklerteam in diesem Sprint für umsetzbar hält. Die Anzahl der in einem Sprint möglichen Aufgaben wird aus der Geschwindigkeit des vorherigen Sprint bestimmt. Der Sprint Backlog benennt ebenso, welche Entwickler welche Aufgaben im Sprint übernehmen werden. Abb zeigt den Zusammenhang zwischen Product Backlog und Sprint Backlog. Abb : Zusammenhang zwischen Product Backlog und Sprint Backlog. Impediment Backlog Der Impediment Backlog ist eine Liste mit den Dingen (Ereignisse, Aktionen, Umstände, Informationen), die das Entwicklerteam während eines Sprint behindert hat. Diese Hindernisse werden vom Scrum Master (s. Abschnitt 5.1.2) zusammen mit dem Entwicklerteam wenn möglich aus dem Weg geräumt. Burndown Chart Die Burndown Chart ist ein Diagramm, das im Daily Scrum (s. Abschnitt 5.1.3) bzw. täglich während eines Sprint verwendet wird, um den Projektverlauf zu visualisieren. Den Projektverlauf zeigt die Burndown Chart als noch anstehende Restaufwände des Projektes an. Die Kurve in der Burndown Chart sollte daher stetig fallen, da in einem Sprint jeden Tag min. eine Aufgabe abgeschlossen werden kann. Am Ende eines Sprint ist somit kein Restaufwand mehr vorhanden. Entstehen in der Kurve waagerechte Stellen oder flache Gefälle, so sieht das Entwicklerteam schon während eines Sprint, wie stark es sich mit der Arbeitslast für den 63

65 aktuellen Sprint verkalkuliert hat und kann somit gleich gegensteuern und diese Erfahrungen im nächsten Sprint zur verbesserten Abschätzung mit einbringen. Abb zeigt eine einfache Burndown Chart für einen ein-wöchigen Sprint mit einem nicht optimalen Verlauf als Beispiel. Abb : Burndown Chart zur Verfolgung des Projektverlaufes. Liste : Artefakte in Scrum Rollen in Scrum Scrum sieht nach [SM11] drei verschiedene Rollen für die an einem Scrum-Projekt beteiligten Personen vor. Die nachstehende Liste nennt diese und erklärt, welche Aufgaben sie in einem Scrum-Projekt haben. 1. Entwickler Ein Entwicklerteam kann aus sieben bis neun Personen bestehen. Es trifft sich vor jedem Sprint zu einem Planungstreffen, in dem die Product Backlog Items abgeschätzt und die höchstpriorisierten Product Backlog Items in konkrete Aufgaben zerlegt werden. Wie viele der hochpriorisierten Product Backlog Items das Entwicklerteam auswählt bzw. wie viele Commitments (Sprint-Ziele) es vor dem Sprint vorgibt, hängt von dessen alleiniger Entscheidung ab. Das Entwicklerteam übernimmt die ausgewählten Backlog Items in den Sprint Backlog und implementiert diese dann im Sprint, der in der Regel aus mehreren Iterationen besteht. 64

66 2. Product Owner Der Product Owner legt die Items im Product Backlog zusammen mit dem Kunden fest, die das Entwicklerteam alle nach und nach umsetzen muss. Um diese zu erfassen, zu formulieren und zu priorisieren kann er verschiedene Techniken einsetzen z. B. die graphische Anforderungsanalyse (Storyboarding), SOPHIST- Schablone usw. 3. Scrum Master Der Scrum Master überwacht die Aufteilung der Rollen und gibt während der gesamten Entwicklungszeit Hilfestellungen, die Entwicklung zu verbessern und das Entwicklerteam produktiv zu halten. Er steckt die Rahmenbedingungen für die ordnungsgemäße Durchführung und Implementierung des Scrum-Projektes ab. Der Scrum Master darf aber dennoch nicht als Kommunikationskanal zwischen dem Entwicklerteam und dem Product Owner verwendet werden. Er ist weder in der Rolle des Product Owner, noch Teil des Entwicklerteams. Liste : Rollen in Scrum Ablauf von Scrum Der Ablauf von Scrum gliedert sich nach [SM11] grob in sechs Aktionen, die sich iterativ wiederholen. Abb zeigt den Ablauf von Scrum, um die in Liste gegebenen Aktionen besser verstehen zu können. Abb : Ablauf von Scrum im Überblick. 65

67 1. Erstes Planungstreffen Der Product Owner erläutert dem Team in diesem Treffen die Product Backlog Items für den anstehenden Sprint. Das Entwicklerteam gibt daraufhin seine Commitments (Sprint-Ziele) ab. Schließlich werden die höchstpriorisierten Product Backlog Items in den Sprint Backlog übernommen und im anstehenden Sprint versucht diese zu implementieren. 2. Zweites Planungstreffen An diesem Treffen ist nur das Entwicklerteam beteiligt. Es geht in diesem Treffen hauptsächlich darum, die Items aus dem Sprint Backlog intern an die Teammitglieder zu verteilen. Die Items werden für jedes Teammitglied in Aufgaben herunter gebrochen. Die Aufgaben und wer diese erledigt, wird auch im Sprint Backlog festgehalten. 3. Sprint Wie schon erwähnt, arbeiten agile Softwareentwicklungsprozesse in Iterationen - so auch Scrum. Der Sprint ist das zentrale Element von Scrum. Dabei enthält ein Sprint üblicherweise mehrere Iterationen. Für jedes Feature (Sprint Backlog Item) müssen alle Phasen einer Iteration durchlaufen werden (s. Abb ). Üblicherweise gibt Scrum eine Sprintlänge von 30 Tagen vor. In der Praxis hat sich aber eine Dauer von einer bis vier Wochen abhängig des Teams eingependelt. Im Sprint wird versucht den Sprint Backlog vollständig abzuarbeiten bzw. zu implementieren. Um im Sprint zu entwickeln, organisiert sich das Team selbstständig, d. h. ohne Vorschriften des Projektmanagement, da es dieses nicht gibt. Der Sprint hat eine feste Zeitvorgabe, die zwingend eingehalten werden muss (Time Box). In dieser Zeit darf das Entwicklerteam nicht gestört werden. Sprints sind daher nur in Ausnahmefällen abbrechbar. Am Ende eines Sprint muss immer eine lauffähige, bereits getestete und inkrementell verbesserte Software vorhanden sein, als zu Beginn des Sprint. 66

68 4. Daily Scrum Während eines Sprint wird täglich ein kurzes (maximal 15 Minuten) Daily-Scrum- Meeting gehalten. Ein Daily-Scrum-Meeting dient dazu, alle Teammitglieder auf den neusten Stand des Sprint zu bringen. In diesen Meetings werden jedem Teammitglied die folgenden Fragen (meist reihum) gestellt. Dabei bezieht man sich immer auf das Daily-Scrum-Meeting des Vortages. o Welche Aufgaben sind seit dem letzten Meeting von Dir fertig geworden? o Welche Aufgaben bearbeitest Du bis zum nächsten Meeting? o Sind Probleme aufgetreten, die Dich bei deinen Aufgaben behindern bzw. behindert haben? 5. Review Ein Review kann in Scrum wie ein Quality Gate (Qualitätsstation) verstanden werden. Nach jedem Sprint wird ein Review gehalten, an dem nur das Entwicklerteam und der Product Owner teilnehmen, um das Ergebnis des Sprint zu validieren. Die laufende Software bzw. der GUI-Prototyp wird dabei gezeigt. Durch das Hinzufügen, Verändern, Entfernen oder durch eine Umpriorisierung der Items im Product Backlog können Änderungen an ihm vorgenommen werden, z. B. wenn Features unzureichend oder gar nicht implementiert werden konnten. 6. Retrospektive Die Retrospektive sorgt für die iterativ Verbesserung der Sprints, denn in ihr wird der soeben beendete Sprint rückblickend betrachtet und beurteilt. Die Beurteilung teilt sich in zwei Leitfragen auf: o Welche Aktionen im Sprint waren herausragend gut? o Welche Aktionen im Sprint sind verbesserungswürdig? Die verbesserungswürdigen Aktionen, die in den Daily-Scrum-Meetings gesammelt wurden, werden priorisiert und einem von zwei Bereichen: Team oder Organisation zugeordnet. Dabei übernimmt der Scrum Master die verbesserungswürdigen organisatorischen Aktionen in den Impediment Backlog, die verbesserungswürdigen Team-Aktionen werden in den Product Backlog übernommen. Liste : Schritte im Ablauf von Scrum. 67

69 5.1.4 Vor- und Nachteile von Scrum Liste erklärt nun die Vor- und Nachteile von Scrum, die in späteren Abschnitten für die Einordnung gegenüber Scrum SD noch von Bedeutung sein werden. Vorteile o Unterstützt iteratives Abarbeiten von Anforderungen bzw. Korrekturen können flexibel durchgeführt werden. o Ständige Überwachung und Kontrolle der Qualität der entwickelten Funktionalitäten. o Ständige Verbesserung der Iterationen und damit des gesamten Prozesses durch Festhalten von Impediments (Hindernisse) pro Sprint. o Schnelles Fertigstellen von Funktionalitäten bzw. eines lauffähigen Prototyps. o Frühe Präsentation eines funktionalen Prototyps möglich. Nachteile o Nicht für verteile oder große Teams geeignet. o Nicht für Anwendungen mit hohen Sicherheitsanforderungen geeignet. o Nicht für Kunden, die nicht regelmäßig an den geforderten Meetings teilnehmen können geeignet. o Hoher Truck Hit Factor 22 durch wenig Dokumentation o Redundantes Testen durch Überschneidung der Durchstiche/Features (Slices). o Nicht Architektur-neutral: Action-Transcription-Pattern 23 wird gefördert. o Sehr hoher Refactoring 24 -Aufwand. o Kann nur mit viel Erfahrung der Entwickler durchgeführt werden. Liste : Vor- und Nachteile von Scrum. 68

70 5.2 Agile Softwareentwicklung mit Scrum SD Scrum SD kann als Erweiterung von Scrum verstanden werden. Dabei wird das klassische Scrum um eine ausgefeilte graphische Anforderungsanalysephase und damit um eine sehr wertvolle und reichhaltige visuelle Kommunikationsebene mit dem Kunden erweitert. Um die Vorteile der graphischen Anforderungsanalyse und die Vorteile der agilen Softwareentwicklung nun in der Anwendungsentwicklung nutzbar zu machen, wird hier die Verbindung zwischen dem Softwareentwicklungsprozess Scrum und der graphischen Anforderungsanalysephase hergestellt. Scrum SD verbessert Scrum daher in den in Liste gegebenen Punkten direkt. Visuelle Kommunikationsebene zwischen Kunde und Scrum Owner und dadurch bessere Vermittlung der Vision des Kunden gegenüber dem Entwicklerteam. Reduzierung der Sprintzeiten durch Storyboarding und besseres Feedback des Kunden. Dies resultiert in einen geringeren Refactoring-Aufwand. Vermeidung des Action-Transcription-Pattern durch technische Analysen hinsichtlich der Software-Architektur und Spezifikation von Schnittstellen, Komponenten und Items. Einfacheres Zusammenfügen der Ziel-Architektur durch stufenweise Analysephasen (fachliche und technische Analyse). Frühes Erkennen von Missverständnissen, falschen Benutzeraktionen und falscher Benutzerführung, falscher Darstellung von Items und falschem Erscheinungsbild der Anwendung. Liste 5.2.1: Direkte Vorteile für Scrum durch die Erweiterung auf Scrum SD Rollen in Scrum SD In Scrum SD gibt es dieselben Rollen, wie im klassischen Scrum. Die Rolle des GRE (Graphical Requirements Engineer), der in Scrum SD zusammen mit dem Kunden die graphische Anforderungsanalyse durchführt, fällt dabei auf die Rolle des Product Owner aus Scrum, da sein Kontakt mit dem Kunden in das kommunikative Aufgabenfeld eines 69

71 Requirements Engineer fällt. Abb zeigt die Einordnung der Rolle des Product Owner als GRE in das vereinfachte Ausgangsszenario der Anwendungsentwicklung. Abb : Zusammenlegung der Rollen - GRE aus Scrum SD und Product Owner aus Scrum Artefakte in Scrum SD Auch die Artefakte von Scrum werden in Scrum SD genutzt. Es kommt bei Scrum SD lediglich das Storyboard mit seinen Annotations als Artefakt hinzu. Neben dem Storyboard kann während der fachlichen Analyse ein Lastenheft und während der technischen Analyse ein Pflichtenheft geführt werden, wenn dies vom Kunden gewünscht wird bzw. wenn eine formale Form der Abnahme der zu entwickelnden Software vereinbart wurde. Lasten- und Pflichtenheft sind aber nicht nötig für Scrum SD. Desweiteren kann der GRE (wie in Kapitel 4, Abschnitt 1 schon erwähnt) ein Glossar führen, das Fachbegriffe der Kunden- Domäne festhält und erklärt. Im Allgemeinen dient das Storyboard aber als Hauptartefakt bzw. Kommunikationsvehikel Ablauf von Scrum SD Scrum SD verbindet graphische Anforderungsanalyse und agile Softwareentwicklung miteinander. Abb zeigt einen Überblick über Scrum SD und wie die beiden Teile miteinander verbunden sind. Die graphische Anforderungsanalyse ist dabei dem klassischen Scrum iterativ vorgeschaltet und stellt eine Vorbereitungsstufe zur Erfassung von Anforderungen und zur Priorisierung der erfassten Anforderungen für den Product Backlog dar. 70

72 Diese Vorbereitungsstufe bewirkt, dass an ihrem Ende die aufgenommenen Anforderungen direkt als Items in den Product Backlog von Scrum SD übernommen werden können. Die Zeit für einen Sprint kann dadurch prinzipiell kürzer ausfallen, da die Items (Anforderungen) durch die gute Vorbereitung eindeutig formuliert wurden und somit weniger Refactoring betrieben werden muss. Nach jedem Sprint wird wie in Scrum ein Review abgehalten, die implementierten Features mit den Zielen im Sprint Backlog verglichen und Impediments des durchgeführten Sprint festgehalten. Abb : Ablauf von Scrum SD im Überblick. Falls sich während eines Sprint keine Änderungen an den Anforderungen bzw. an den Product Backlog Items ergeben haben, d. h. falls keine Items neu hinzugekommen, entfernt oder verändert wurden, wird in Scrum SD (wie in Scrum) mit dem nächsten Sprint iterativ fortgefahren und weitere Product Backlog Items abgearbeitet. Sollte es aber während eines Sprint eine Änderung an den Product Backlog Items gegeben haben, so folgt Scrum SD dem Ablauf des UML Aktivitätsdiagramms in Abb

73 Abb : Verlauf von Scrum SD bei Änderungen am Product Backlog während eines Sprint Zusammenfassung Scrum SD ist ein agiler moderner Softwareentwicklungsprozess, der für die Anwendungsentwicklung konzipiert wurde und der im Gegensatz zu Scrum nicht Feature-orientiert, sondern Anwender-orientiert bzw. Storyboard-getrieben vorgeht. Er ist eine Erweiterung für Scrum und unterstützt das inkrementelle Storyboarding bzw. die graphische Anforderungsanalyse. Durch Scrum als agilen Unterbau, profitiert Scrum SD von dessen agiler Vorgehensweise (Iterationen und Sprints). Scrum SD vereint daher die graphische Anforderungsanalyse mit der agilen Softwareentwicklung. Die dem klassischen Scrum vorgeschaltete graphischen Anforderungsanalyse ermöglicht Scrum SD zusätzlich eine hochwertige fachliche Kommunikation und Modellierung der Domäne mit dem Kunden und schafft wenig Freiraum für Interpretationen bei der Implementierung in den Sprints. Scrum SD ist Architektur-neutral und baut wie Scrum auch auf die Eigenverantwortlichkeit der Entwickler, auf deren Kommunikationsbereitschaft und kommt daher mit wenig Do- 72

74 kumentation zurecht. Kapitel 6 geht nun auf die Konzeption des für diese Thesis entwickelten Frontend ein und erläutert diese. 6 Konzeption des Frontend Dieses Kapitel widmet sich der Konzepte des Frontend, die für die Anwendung Inspector C 2.0 entwickelt wurden. Es wird dabei auf Entwurfsentscheidungen und die konkreten Umsetzungen eingegangen. 6.1 Single View Konzept Inspector C 2.0 arbeitet mit einem Single View Konzept, das vergleichbar mit dem Konzept einer SDI-Anwendung (Single Document Interface) ist. Bei SDI-Anwendungen kann zu jedem Zeitpunkt nur ein bearbeitbares Dokument in der Anwendung geöffnet sein. Inspector C 2.0 benutzt hingegen Views (Ansichten) statt Dokumente. Eine View ist hier ein Control vom Typ UserControl. Für jede View der Anwendung gibt es solch ein eigenes UserControl, das genau dann umgeschaltet (sichtbar) wird, wenn der Anwender in der Ribbon-Menüleiste die Tab Pages wechselt. Eine View dient entweder zum Verwalten eines Item-Typs oder zur Steuerung einer Aufgabe. Abb zeigt das Prinzip des Ansichtswechsels in Inspector C 2.0. Abb : Prinzip des Single View Konzeptes. Inspector C 2.0 muss mit einem großen Mengenmodell zurechtkommen. Die Anzahl der insgesamt verwaltbaren Test-Items liegt im Bereich von ca Um diese große Men- 73

75 ge verwalten zu können, enthält jede verwaltende View ein GridView-Control (WinForms- Tabellen-Komponente), die die einzelnen Items mit ihren Eigenschaften tabellarisch auflistet. Das SDI-Konzept steht dem MDI-Konzept (Multiple Documents Interface) gegenüber. Das MDI-Konzept wurde bei der Konzeption aber verworfen, da es sich beim Entwurf schnell als unbrauchbar herausstellte. Bei großen Mengen von Items in mehreren Views graphisch nebeneinander verschlechterte sich die Übersicht für den Anwender. 6.2 Eigenschaften-Dialoge In Inspector C 2.0 können, wie in Abschnitt 6.1 schon erwähnt, über verschiedene Views einzelne Aufgaben erledigt und die in der Anwendung benötigten Items verwaltet werden. Möchte man nun als Anwender die einzelnen Eigenschaften (Properties) der einzelnen Items einsehen oder bearbeiten, so wechselt man für eine detailliertere Ansicht in einen modalen Eigenschaften-Dialog. Ein solcher Dialog erlaubt es, Änderungen an den Eigenschaftswerten eines Items vorzunehmen und beim Verlassen des Dialogs die an den Eigenschaften vorgenommenen Änderungen zu speichern. Modale Dialoge haben zusätzlich den Vorteil, dass sie den Rest der Benutzeroberfläche sperren, wenn sie angezeigt werden. So kann der Anwender z. B. nicht das Item löschen, das er gerade genauer betrachtet. Beispielsweise zeigt Abb den Eigenschaften-Dialog zur Änderung der Details einer Anforderung und Abb zeigt den Eigenschaften-Dialog zur Änderung der Details eines Projektes. In Inspector C 2.0 besitzen nicht alle Items solche Eigenschaften- Dialoge, nur diese, bei denen Eigenschaftswerte geändert werden können sollen. Somit lassen sich die Items für Inspector C 2.0 konkret in die folgenden Stufen zur Manipulation unterteilen. Liste nennt die Items, ihre jeweilige Manipulationsstufe und auch die in Inspector C 2.0 für sie verwendeten Controls. Sichtbar und manipulierbar o Project TreeView o Requirement, Test, TestResult, Baseline GridView Sichtbar und nicht manipulierbar o AnalysisSummary GridView Liste 6.2.1: Items von Inspector C 2.0, ihre Stufen zur Manipulation und ihre Controls. 74

76 Abb : Modaler Eigenschaften-Dialog für die Details einer Anforderung. Abb : Modaler Eigenschaften-Dialog für die Details eines Projektes. Kapitel 7 wird nun auf Teile der Implementierung des Frontend von Inspector C 2.0 eingehen und diese erklären. Dabei kann das Domänenwissen aus Projekt 2 hilfreich sein. Es ist aber nicht zwingend notwendig, da die Thematik von Projekt 2 zum Verständnis nochmals kurz erläutert wird. Die Programmcodes des Frontend sind auf der CD in Anhang E enthalten. 75

77 7 Implementierung des Frontend Wie im Vorwort dieser Thesis bereits erwähnt, hat das Frontend, das für diese Thesis entwickelt wurde, einen zweifachen Nutzen. Liste 7.1 nennt diesen nochmals und erläutert ihn. 1. Exemplarisches Frontend zur Einführung ins Storyboarding und zur Demonstration eines High-Fidelity-Prototyps. 2. Voll funktionsfähiges neues Frontend für Inspector C 1.0 (Projekt 2 Thematik). Liste 7.1: Zweifacher Nutzen des entwickelten Frontend. Der erste Nutzen aus dem Frontend wurde in den vorigen Kapiteln schon ausführlich vorgestellt. Der weitere Nutzen des Frontend wird in diesem Kapitel erklärt (Liste 7.1, Punkt 2). Dazu wird kurz auf die damalige Thematik der Lehrveranstaltung Projekt 2 und danach auf das Software-Design, auf Implementierungen und den Funktionsumfang des Frontend eingegangen. 7.1 Thematik aus Projekt 2 Das Thema in Projekt 2 lautete Smart Embedded Systems Unit Testing und handelte davon eine Software zu entwickeln, die dem Anwender (Test Engineer, Quality Manager) in der Brache Embedded Systems die Traceability 25 von Anforderungen an ein zu entwickelndes Softwaresystem und ein einfaches Testmanagement bieten sollte. Dazu sollte eine Komponente in der Anwendung Analysen durchführen und Anforderungen (Requirements), fertige Tests (Blackbox Tests, Whitebox Tests) und fertige Testergebnisse (Text-Dateien) miteinander in Beziehung setzen und verschiedene Metriken aus den Beziehungen berechnen. Die errechneten Werte (Analyseergebnisse) sollten über Diagramme (Charts) angezeigt werden und auch in Form von Berichten (Reports) an andere Personen weitergegeben werden können (z. B. PDF-Report per ). Abb zeigt das Grundprinzip der Anwendung Inspector C 1.0. Die Anwendung sollte drei verschiedene Klassen von Anforderungen, sowohl einzeln, als auch geschachtelt verwalten können. Liste nennt und erläutert diese Anforderungsklassen kurz. 76

78 Marktanforderungen: Sie beschreiben eher eine Nachfrage auf einem Markt, als eine spezifische Produkteigenschaft. Produktanforderungen: Sie beschreiben eher spezifische Eigenschaften eines Produktes, als spezifische Funktionalitäten eines Produktes. Softwareanforderungen: Sie beschreiben spezifische und detaillierte Funktionalitäten eines Produktes. Liste 7.1.1: Anforderungsklassen der Anwendung Inspector C 1.0. Abb : Grundprinzip der Anwendung Inspector C 1.0. Die eben erwähnte Schachtelung der drei Anforderungsklassen sollte durch Verlinken der erstellten oder importierten Anforderung (CSV-Dateien) realisiert werden, so dass sich eine Hierarchie von Anforderungen bilden konnte. Marktanforderungen sollten beliebig 77

79 viele Produktanforderungen und Produktanforderungen sollten wiederum beliebig viele Softwareanforderungen enthalten können. Allen Anforderungen aller Klassen sollten importierte Tests (C-Unit Tests) zugeordnet werden können, jedem Test sollte zu jedem Zeitpunkt immer nur genau ein Testergebnis (importierte TXT-Datei) zugewiesen werden können. Abb zeigt die durch die Analyse von Inspector C 1.0 erzeugte interne Abbildung der Domäne aus Projekt 2. Abb : Rückverfolgbarkeit von Anforderungen, ihrer Tests und Testergebnisse (Traceability). Das Frontend der Anwendung sollte die Möglichkeit bieten, diese drei Komponenten über Datei-Auswahl-Dialoge importieren zu können und Anforderungen zusätzlich in der Anwendung selbst anlegen zu können, in der sie dann anschließend analysiert werden sollten (verlinkt werden sollten). Das Ergebnis der Analyse war die Testabdeckung (Anzahl Tests pro Anforderung und andere Metriken) zur Qualitätsüberwachung der verschiedenen Klassen und einzelnen Anforderungen. Desweiteren sollte der Anwender die Traceability auch graphisch, durch die Darstellung der Analyseergebnisse über Diagramme auch für größere Mengen von Items nachvollziehen können, um zu jedem Zeitpunkt zu wissen, wie die Testabdeckung war. Das Ziel der Anwendung war es somit, bestehende Unit Testframeworks um die fehlende Funktionalität der Traceability mit Hilfe von Inspector C 1.0 zu erweitern. Die Zielgruppe der Anwendung waren KMUs, die größere Investitionen für teure graphische Testumgebungen scheuen würden. Inspector C 1.0 sollte in Kombination mit einem Unit Testframework, wie z. B. Check oder µcunit (beide für die Programmiersprache C) den Testprozess in der Qualitätssicherung eines Software- 78

80 dienstleisters nachhaltig verbessern. Dabei sollte während der Entwicklung von Inspector C 1.0 auch immer darauf geachtet werden, dass das Frontend von Entwicklern (Zielgruppe) benutzt werden konnte, da diese in der Branche Embedded Systems die Hauptanwender darstellten und komplizierte GUI-Lösungen regelrecht ablehnten. Die Anwendung sollte eine wie in Abb gezeigte Traceability aus importierten Anforderungen, Tests und Testergebnissen herstellen und zwei-dimensionale sowie drei-dimensionale Charts der analysierten Daten anzeigen können. Inspector C 1.0 aus Projekt 2 war eine reine Oracle Java 6 Lösung, die mit der IDE NetBeans 6.8 und Matisse (GUI-Designer) entwickelt wurde. Abschnitt 7.2 beschreibt nun aufbauend auf Abschnitt 7.1 die implementierten Erweiterungen des Frontend von Inspector C 2.0, das vollständig mit C#, MS.NET 4.0 und Infragistics implementiert wurde und geht gleichzeitig auf dessen Validierung ein. Für eine vollständige Liste der implementierten Features des Frontend siehe Anhang B. 7.2 Validierung des Frontend Dieses Kapitel widmet sich der Validierung des Frontend. Es erklärt einzelne Implementierungskonzepte exemplarisch und zeigt die damit verbundenen Ansichten des Frontend Moderne Wizards Ein Wizard ist ein besonderer Benutzerdialog, der es dem Anwender erlaubt einer Anwendung Daten schrittweise für eine bestimmte Aufgabe, strukturiert und eindeutig zu übergeben. Wizards bestehen aus Einzelschritten hintereinander geschaltet, wobei sich jeder Schritt um die Aufnahme von Teildaten kümmert. Moderne Wizards bieten eine Vielzahl von Interaktionsmöglichkeiten für die unterschiedlichsten Aufgaben. So gibt es Wizards zum Laden von Vorlagen (Templates), Wizards zum Erstellen von Items (z. B. Project-Item), Wizards zur Selektion von Controller-Strategien (z. B. Archivierungsformate: ZIP, RAR, TAR), Wizards zur Installation (Setup) und uvm. Liste nennt die Funktionalitäten, die jeder moderne Wizard in der Regel besitzt und erklärt diese kurz. 79

81 1. Zurücksetzung Rollback-Strategien zum Aufräumen von Schritten. 2. Selektion Auswahl von Strategien zum Setzen der Schrittsequenz. 3. Erzeugung Auswahl von Factory-Strategien zum Erzeugen von Items. 4. Datenakzeptanz Generisch gegenüber verschiedenen Benutzereingaben. 5. Eingabevalidierung Validierung der übergebenen Daten zur validen Controller-Parametrierung (defensive Programmierung). Liste : Funktionalitäten von modernen Wizards. Der im Frontend für Inspector C 2.0 implementierte Wizard setzt die in Liste genannten Punkte vollständig um. Anhang D zeigt die drei Ausprägungen des Wizard zur Erstellung der Items: Project, Requirement, Baseline. Der Wizard bietet dabei für jede Erzeugerstrategie eine enum Konstante an, mit der der Typ des Wizard festgelegt werden kann (ItemType.Project, ItemType.Requirement und ItemType.Baseline). Eine mögliche Ausprägung des Wizard ist demnach der Projekt-Wizard. Er bietet eine Eingabevalidierung auf einen gültigen Projektnamen und lässt keine für MS Windows 7 verbotenen Zeichen im Projektnamen zu. Der Baseline-Wizard z. B. bietet, abhängig von den gewählten Optionen in den Schritten, die Veränderung der Schrittsequenz zur Laufzeit, denn nicht für jede Option sind alle verfügbaren Schritte des Baseline-Wizard relevant. Da die Schritte unterschiedliche Eingabedaten (Datentypen) erlauben können, werden die Benutzereingaben entlang der Schrittsequenz zunächst in einer allgemeingültigen List, deren Elemente des Typs Dictionary<object, object> sind, gespeichert. Vor der späteren Erstellung eines spezifischen Item (Project, Requirement oder Baseline) führt die Erzeugerstrategie Casts (OO-Casts) der für die Erzeugung benötigten Benutzerdaten auf nur ihr bekannte Datentypen durch, damit das zu erzeugende Item anschließend mit den konkreten Datentypen (Objektreferenzen) erzeugt werden kann. Wenn der Wizard erfolgreich abgeschlossen oder abgebrochen wurde, sorgt er selbst dafür, dass über die aktuelle Liste der Wizard-Schritte (IStep) iteriert wird und von jedem Schritt die Rollback- Strategie aufgerufen wird, die den Schritt individuell zurücksetzt (zurückrollt). Abschnitt geht nun auf die Validierung des Anwender-orientierten Design von Inspector C 2.0 ein. 80

82 7.2.2 Anwender-orientiertes Design Das Frontend von Inspector C 2.0 implementiert die neuste Menüleiste von Microsoft: das Ribbon. Das Ribbon (engl.: Band) ist ein neuartiges graphisches Bedienkonzept für Anwendungsprogramme, bei dem Funktionalitäten in Gruppen (Tabs) und mit Icons dem Anwender präsentiert werden. Die Ribbon-Menüleiste bewegt sich semantisch von einer klassischen Menüleiste weg und nähert sich eher einer modernen Symbolleiste an. Microsoft Office ab der Version 2007 verwendet bereits diese neuartige Ribbon-Symbolleiste. Abb zeigt die Ribbon-Symbolleiste von Inspector C 2.0 mit ihren Tabs. Abb : Ribbon-Symbolleiste des Frontend von Inspector C 2.0. Message Boxes sind dagegen ein alt-bewährtes Konzept, dem Anwender Vorgänge in der Anwendung zu signalisieren. So teilen Message Boxes dem Anwender in der Regel mit, welche Vorgänge die Anwendung gerade angestoßen oder abgeschlossen hat. Rückmeldungen (Feedback) zum Anwender hin sind entscheidend im Konzept der intuitivbedienbaren graphischen Benutzeroberfläche. Abb zeigt zwei Message Boxes und zwei Option Boxes aus dem Frontend von Inspector C

83 Abb : Beispiele für Rückmeldungen zum Anwender in Inspector C 2.0. Ein weiteres Anwender-orientiertes Konzept, ist das Konzept der direkten Hilfestellung, um Missverständnisse bei der Bedienung unmittelbar aufklären zu können. Dazu wurde in Inspector C 2.0 eine WinForms-Browserkomponente integriert, die HTML-Hilfeseiten anzeigen kann. Die Hilfeseiten enthalten ausführliche Erklärungen über alle in der Anwendung zur Analyse verwendeten Metriken und Begriffe (Glossar). Abb zeigt die Help View des Frontend mit der geöffneten lokalen Startseite der Help Topics. Abb : Lokale Startseite der integrierten Hilfe in der Help View von Inspector C 2.0. Desweiteren wurde eine Slider an der rechten Seite der Anwendung verankert. Er gehört zu den zahlreichen erweiterten Windows-Form-Komponenten von Infragistics und ermög-licht es von jeder View aus in die Hilfethemen (Help Topics) zu springen. Abb zeigt den in Inspector C 2.0 integrierten Slider. Der Slider fährt von der rechten 82

84 Seite der Anwendung nach links über die momentan gezeigte View und präsentiert Links zu den Hilfeseiten. Abb : Integrierter Slider zur direkten Hilfestellung aus jeder View heraus Manipulation von Items In Inspector C 2.0 gibt es eine Reihe von Operatoren (Funktionalitäten), die zur Manipulation der Items benutzt werden können. Die Operationen, die auf jeden Items ausgeführt werden, sind die der Traceability-Analyse (Analysekomponente). Abb zeigt den groben Ablauf der Traceability-Analyse als UML Aktivitätsdiagramm. Liste gibt die Items aus der Domäne von Projekt 2 wieder und begründet, warum die Traceability- Analyse nur bei bestimmten Operationen auf den Items zusätzlich angestoßen wird. Anforderungen (Requirement-Item) o Erstellen oder öffnen: Die Traceability-Analyse wird in beiden Fällen angestoßen, um die neu erstellte oder geöffnete Anforderung mit schon bestehenden Anforderungen, einem schon bestehenden Test und einem schon bestehenden Testergebnis zu verlinken. o Bearbeiten: Die Traceability-Analyse wird angestoßen, um die mögliche Änderung an der Verlinkung der bearbeiteten Anforderung neu setzen zu können. 83

85 o Löschen: Die Traceability-Analyse wird angestoßen, um nach dem Löschen der Anforderung, ihrer Kind-Anforderungen, Tests und Testergebnisse, die Verlinkung neu setzen zu können. Tests (Test-Item) o Öffnen oder löschen: Die Traceability-Analyse wird in beiden Fällen angestoßen, um den neuen Test mit einer schon bestehenden Anforderung und einem schon bestehenden Testergebnis verlinken zu können. Testergebnisse (Test-Result-Item) o Öffnen oder löschen: Die Traceability-Analyse wird in beiden Fällen angestoßen, um das neue Testergebnis mit einem schon bestehenden Test verlinken zu können. Liste : Operationen von Items, nach denen die Traceability-Analyse aufgerufen wird. Abb : Grober Ablauf der Operationen der Traceability-Analyse auf den Items. 84

86 8 Zusammenfassung und Ausblick In der Anwendungsentwicklung gibt es zwei wesentliche Entwicklungsansätze: der Top- Down-Ansatz und der Bottom-Up-Ansatz. Der Top-Down-Ansatz beschreibt, dass die graphische Benutzeroberfläche bzw. das Frontend einer zu entwickelnden Software zeitlich vor dem Domain-Backend entwickelt wird. Dieser Ansatz steht dem traditionellen Bottom-Up Ansatz, bei dem die Business-Logik/Domain-Backend zuerst und danach an den Anwender gedacht wird bzw. das Frontend (GUI) der Anwendung entwickelt wird, direkt gegenüber. Der hier vorgestellte neuartige und agile Softwareentwicklungsprozess Scrum SD ist eine Erweiterung für Scrum, die es erlaubt mit Scrum Storyboard-getrieben zu entwickeln. Dabei stützt sich Scrum SD auf eine graphische Anforderungsanalyse, mit der Anforderungen aus Storyboards abgeleiten werden können und integriert diese graphische Anforderungsanalysephase in Scrums agile Vorgehensweise. Das für Scrum SD benötigte und hier vorgestellte Storyboarding bzw. die graphische Anforderungsanalyse wird jedem Sprint von Scrum vorgeschaltet, um die vom Storyboard abgeleiteten Anforderungen für den Product Backlog vorzubereiten und sie anschließend für eine Umsetzung direkt priorisieren zu können. Umso realistischer daher der visuelle Prototyp während dem Storyboarding ist, desto besser lassen sich Anforderungen ableiten und für eine Implementierung in einem Sprint ohne Missverständnisse umsetzen. Scrum SD ermöglicht es somit nicht nur eine Anwendung inkrementell, iterativ und agil zu entwickeln, sondern auch deren Frontend frühzeitig zu diskutieren, das Mengenmodell zu beleuchten, die Gestaltung zu besprechen, die Benutzerführung und Interaktivität zu erörtern, Rechte und Rollen der späteren Anwender zu besprechen, Erfahrungen über Altanwendungen zu integrieren und alle diese Aspekte zusätzlich noch durch Usability-Tests frühzeitig zu validieren. Scrum SD bietet somit einen agilen Storyboard-getriebenen, graphisch analytischen und Architektur-neutralen Softwareentwicklungsprozess für die zukünftige agile Anwendungsentwicklung und macht die undurchsichtige Phase der Anforderungsanalyse, durch sein visuell gesammeltes Kunden-Feedback in Zukunft ein Stück weit transparenter und zufriedenstellender für den Kunden, zuverlässiger und verständlicher für die Entwickler und besser vorstellbar und planbarer für alle anderen Projektbeteiligten. 85

87 Rechtliche Übertragungen Diese Bachelor-Thesis ist urheberrechtlich geschützt, unbeschadet dessen wird folgenden Rechtsübertragungen zugestimmt: der Übertragung des Rechts zur Vervielfältigung der Bachelor-Thesis für Lehrzwecke an der Hochschule Offenburg ( 16 UrhG), der Übertragung des Vortrags-, Aufführungs- und Vorführungsrechts für Lehrzwecke durch Professoren der Hochschule Offenburg ( 19 UrhG), der Übertragung des Rechts auf Wiedergabe durch Bild- oder Tonträger an der Hochschule Offenburg ( 21 UrhG). Prof. Dr.-Ing. Daniel Fischer Johannes Stoll 86

88 Eidesstattliche Erklärung Hiermit versichere ich eidesstattlich, dass die vorliegende Bachelor-Thesis von mir selbstständig und ohne unerlaubte fremde Hilfe angefertigt worden ist, insbesondere, dass ich alle Stellen, die wörtlich oder annähernd wörtlich oder dem Gedanken nach aus Veröffentlichungen, unveröffentlichten Unterlagen und Gesprächen entnommen worden sind, als solche an den entsprechenden Stellen innerhalb der Arbeit durch Zitate kenntlich gemacht habe, wobei in den Zitaten jeweils der Umfang der entnommenen Originalzitate kenntlich gemacht wurde. Ich bin mir bewusst, dass eine falsche Versicherung rechtliche Folgen haben wird. Offenburg, den 16. Mai 2011 Unterschrift (Johannes Stoll) 87

89 Tabellenverzeichnis Tabelle Titel Seite Überblick derzeitiger Solutions für Entwicklungsumgebungen und GUI- 16 Designers Überblick über die Solutions im Bereich des Low-Fidelity-Prototyping Entwicklung der Programmcodegröße des Betriebssystems Microsoft Windows Allgemeine Charakteristika einer Aufgabe Fachliche Analysepunkte im Überblick. 45 Abbildungsverzeichnis Abb. Titel Seite Traditionelles Storyboard aus der Spielfilmbranche mit seinen Leserichtungen Stack des gesamten Microsoft.NET-Framework ab der Version Bekannte Arten von Prototypen im Software-Engineering in Bezug auf Storyboards Von Hand gezeichnetes Storyboard (Low-Fidelity) Papier-Storyboard mit Stencil Kit für Windows Phone erstellt (Low-Fidelity) Mit Graphik-, Präsentations-, HTML-Software erstelltes Storyboard (Low- 28 Fidelity) High-Fidelity-Storyboard erstellt mit MS Visual Studio 2010 (schematisch) High-Fidelity-Storyboard erstellt mit MS Visual Studio 2010 und Infragistics Anforderungsanalysetechniken aus der Anwendungsentwicklung nach Abstraktionsgrad Modellierungsablauf für Meetings zur Erstellung von Storyboards Grundprinzip eines inkrementellen Erstellungsmeeting für Storyboards Teil einer HTA für ein Textverarbeitungsprogramm Gesamtüberblick über den Ablauf der graphischen Anforderungsanalyse Fachliche Analyse der verknüpften Storyboards zusammen mit dem Kunden Allgemeine Eigenschaften einer Anforderung SOPHIST-Schablone zur Formulierung von Anforderungen an ein System

90 4.3.1 Beispiel-Software-Architektur nach MVC-Entwurfsmuster (Trygve Reenskaug ) Schnittstellenanalyse zweier Funktionalitätsgruppierungen aus dem Frontend Lose voneinander gekoppelte Schichten: Frontend und Business-Logik/Backend Aus den Schnittstellen abgeleitete Komponenteneinteilung in der Business- 53 Logik Identifizierte manipulierbare Items im Frontend von Inspector C Manipulierbare und nicht manipulierbare Objekte in der MVC Beispiel- 55 Architektur Ablauf einer technischen Analyse im Überblick Vereinfachtes Ausgangsszenario der Anwendungsentwicklung Integration des Storyboarding in das Zentrum des vereinfachten Ausgangsszenarios Modell eines traditionellen Entwicklungsprozesses: Wasserfallmodell (Royce ) Der Kern der agilen Softwareentwicklung: die Iteration Zusammenhang zwischen Product Backlog und Sprint Backlog Burndown Chart zur Verfolgung des Projektverlaufs Ablauf von Scrum im Überblick Zusammenlegung der Rollen - GRE aus Scrum SD und Product Owner aus 70 Scrum Ablauf von Scrum SD im Überblick Verlauf von Scrum SD bei Änderungen am Product Backlog während eines 72 Sprint Prinzip des Single View Konzeptes Modaler Dialog für die Details einer Anforderung Modaler Dialog für die Details eines Projekts Grundprinzip der Anwendung Inspector C Rückverfolgbarkeit von Anforderungen, ihrer Tests und Testergebnisse 78 (Traceability) Ribbon-Symbolleiste des Frontend von Inspector C Beispiele für Rückmeldungen zum Anwender in Inspector C Lokale Startseite der integrierten Hilfe in der Help View von Inspector C Integrierter Slider zur direkten Hilfestellung aus jeder View heraus Grober Ablauf der Operationen der Traceability-Analyse auf den Items

91 Listenverzeichnis Liste Titel Seite Problemfelder der Anwendungsentwicklung, die GUI-Prototypen leichter lösen Nennenswerte Neuerungen der 4. Version des Microsoft.NET-Framework Von Infragistics erweiterte Basis-Technologien zum Bau von User Experiences Technische Gründe für die Wahl der Microsoft und Infragistics Technologien Vorteile des GUI-Prototyping Erstellungsmöglichkeiten für GUI-Prototypen bzw. Storyboards Etablierte Anforderungsanalysetechniken in der Softwareentwicklung Anforderungsanalysetechniken, die die graphische Anforderungsanalyse ergänzen Vorgestellte drei Hilfsmittel zur strukturierten Erfassung von Anforderungen Eigenschaften einer Anforderung Kategorien des FURPS+ Modells Beispiele für Anforderungen aus den meisten IEC Kategorien Fachliche und technische Formulierung einer Anforderung mit SOPHIST- 45 Schablone Software-architektonische Grundannahmen für die technische Analyse Anwendungsfall (Slice) - Neues Projekt anlegen Software-ergonomische Mindestvoraussetzungen für Schnittstellenanalysen Zusammenhänge im vereinfachten Ausgangsszenario der Anwendungsentwicklung Anforderungen an den Softwareentwicklungsprozess Scrum SD Zentrale Punkte der agilen Softwareentwicklung Artefakte in Scrum Rollen in Scrum Schritte im Ablauf von Scrum Vor- und Nachteile von Scrum Direkte Vorteile für Scrum durch die Erweiterung auf Scrum SD Items von Inspector C 2.0, ihre Stufen zur Manipulation und ihre Controls Zweifacher Nutzen des entwickelten Frontend Anforderungsklassen der Anwendung Inspector C Funktionalitäten von modernen Wizards Operationen von Items, nach denen die Traceability-Analyse aufgerufen wird

92 Abkürzungsverzeichnis A ADO AI ASP API C CI CSS D DBMS G GUI GRE H HTA HTML I IDE ISL ISO K KMU L LCD M MDI MS MVC N.NET O OO R RE S SD SDI SUT U UI UML UX W WF WCF WinForms WPF X XAML XML Active Data Object Angewandte Informatik Active Server Pages Application Programming Interface Corporate Identity Cascading Stylesheets Database Management System Graphical User Interface Graphical Requirements Engineer Hierarchical Task Analysis HyperText Markup Language Integrated Development Environment Infragistics Style Language International Organization for Standardization Kleine und mittelständische Unternehmen Liquid Crystal Display Multiple Documents Interface Microsoft Model View Control.NET-Framework Objekt-orientiert Requirements Engineering Storyboard Driven Single Document Interface System Under Test User Interface Unified Modeling Language User Experience Windows Workflow Foundation Windows Communication Foundation Windows Forms Windows Presentation Foundation Extensible Application Markup Language Extensible Markup Language 91

93 Literaturverzeichnis SF05 Sousa K., Furtado E., From Usability Tasks to Usable User Interfaces, IEEE 2005 MA06 Meszaros G., Aston J., Adding Usability Testing to an Agile Project, IEEE 2006 DLW06 Draheim D., Lutteroth C., Weber G. - Graphical User Interfaces as Documents, IEEE 2006 FNB07 Ferreira J., Noble J., Biddle R., Agile Development Iterations and UI Design, IEEE 2007 YA07 Yasar A., Enhancing Experience Prototyping by the help of Mixed-Fidelity Prototypes, IEEE 2007 YPLE08 Yeung L., Plimmer B., Lobb B., Elliffe D., Effect of Fidelity in Diagram Presentation, IEEE 2008 HO08 Dirk W. Hoffmann, Software-Qualität, Springer-Verlag Berlin Heidelberg, 2008 MH09 Herczeg M., Software Ergonomie - Theorien, Modelle und Kriterien für gebrauchstaugliche interaktive Computersysteme, Oldenbourg Wissenschaftsverlag GmbH, 2009 MJ10 Madison J., Agile Architecture Interactions, IEEE 2010 IEEES10 How is User Interface Prototyping Really Done in Practice? A Survey of User Interface Designers, 2010 IEEE Symposium on Visual Languages and Human-Centric Computing SNM10 Sajid A., Nayyar A., Mohsin A., Modern Trends Towards Requirement Elicitation, ACM 2010 RF10 Richter M., Flückiger M. D. - Usability Engineering Kompakt, 2. Auflage, 2010 Internet Links SM Wik Wik Wik DF MS IG IG

94 Anhang A FURPS+ Kategorien von Hewlett Packard 93

95 ISO 9126/IEC Kategorien 94

96 Anhang B Features des Frontend von Inspector C 2.0 ID Features Beschreibung 1 Project Editor Dialog Dialog, um Projekte zu editieren 2 Requirements Editor Dialog Dialog, um Anforderungen zu editieren 3 Requirements File Open Dialog Dialog, um Anforderungen zu importieren (CSV-Dateien) 4 Test File Open Dialog Dialog, um Tests zu importieren (*.*) 5 Test Result File Open Dialog Dialog, um Testergebnisse zu importieren (TXT-Dateien) 6 Project File Open Dialog Dialog, um Projekte zu öffnen (ZIP- Dateien) 7 Document File Open Dialog Dialog zum Anhängen von Dokumenten (*.*) 8 About Dialog Info über die Anwendung 9 Help Slider Slider für direkte Hilfestellungen 10 Projects Explorer Arbeiten an mehreren Projekten gleichzeitig 11 Projects Wizard Wizard zum Anlegen von Projekten 12 Baselines Wizard Wizard zum Anlegen von Baselines 13 Requirements Wizard Wizard zum Anlegen von Anforderungen nach SOPHIST 14 Dashboard View Ansicht für den Überblick über den Projektstand (graphisch) 15 Traceability View Ansicht für Anforderungen (tabellarisch und graphisch) 16 Tests View Ansicht für importierte Tests 17 Test Results View Ansicht für importierte Test Ergebnisse 18 Baselines View Ansicht für Baselines (tabellarisch und graphisch) 19 Help View Ansicht für HTML Hilfe-Seiten 20 Ribbon Manage Projects Ribbon Group zur Verwaltung von Projekten 21 Ribbon Manage Requirements Ribbon Group zur Verwaltung von Requirements 22 Ribbon Manage Tests Ribbon Group zur Verwaltung von Tests 23 Ribbon Manage Test Results Ribbon Group zur Verwaltung von Testergebnissen 24 Ribbon Manage Baselines Ribbon Group zur Verwaltung von Baselines 95

97 Installationsvoraussetzungen Betriebssystem Mindestens Microsoft Windows XP, 32 Bit Mindestens Microsoft.NET-Framework 3.5 Download des Web-Installer (869 KB) unter: b0e5-b386f32c0992&displaylang=en 96

98 Anhang C Programmcode einer abgeleiteten Schnittstelle (C#) namespace InspectorC2.Logic.RequirementsManagement { /// <summary> /// This interface provides functionality to manage requirements. /// </summary> public interface IRequirementsManagement { /// <summary> /// Adds a requirement. /// </summary> void AddRequirement(IRequirement requ); /// <summary> /// Deletes a requirement. /// </summary> void DeleteRequirement(IRequirement requ); /// <summary> /// Opens a specific requirement. /// </summary> List<IRequirement> OpenRequirement(string sfilepath); /// <summary> /// Returns a specific requirement by the ID specified. /// </summary> IRequirement GetRequirementById(int id); /// <summary> /// Gets or sets requirements. /// </summary> List<IRequirement> Requirements { get; set; } /// <summary> /// Attaches a specific document to a requirement specified. /// </summary> AttachDocumentToRequirement(string sdocpath, IRequirement requ); } } /// <summary> /// Detaches a specific document from a requirement specified. /// </summary> DetachDocumentFromRequirement(int idocid, IRequirement requ); 97

99 Anhang D Die drei Wizard-Typen in Inspector C 2.0 Wizard, um Baselines anlegen zu können. Wizard, um Projekte zur Analyse anlegen zu können. Wizard, um Anforderungen anlegen zu können. 98