Projektmanagement. Die Entwicklung von Webprojekten durch horizontales "Prototyping"

Inhaltsverzeichnis

Abstract

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Zielstellung der Arbeit
1.3 Grundlegendes und Begriffsdefinitionen
1.3.1 Projekt
1.3.2 Projektmanagement
1.3.3 Webanwendungen
1.3.4 Web Engineering
1.3.5 Webprojekt
1.3.6 Prototyping

2 Ablauforganisationsplanung
2.1 Vorgehens-Grundmodelle
2.1.1 Sequenzielle Vorgehensmodelle
2.1.2 Nebenläufige Vorgehensmodelle
2.1.3 Inkrementelle Vorgehensmodelle
2.1.4 Evolutionäre Vorgehensmodelle
2.1.5 Agile Vorgehensmodelle
2.2 Konkrete Vorgehensmodelle
2.2.1 Ad-hoc-Vorgehen
2.2.2 Schleifenmodell
2.2.3 Spiralförmiges Vorgehensmodell
2.2.4 V-Modell
2.2.5 Scrum-Framework
2.2.6 eXtreme Programming
2.3 Phasenmodelle
2.3.1 Phasen eines Webprojektes
2.4 Entscheidung der Vorgehensweise bei Webprojekten
2.4.1 Einsatzentscheidung von Prototyping in Webprojekten

3 Projektvorbereitung und –start
3.1 Projektinitialisierung
3.1.1 Ziele bestimmen
3.1.2 Horizontales Prototyping (Off-line-Prototyping)
3.1.3 Anforderungen formulieren
3.1.4 Stakeholder-Analyse
3.1.5 Grobplanung
3.1.6 Entscheidung
3.1.7 Kick-Off-Meeting
3.2 Projektplanung
3.2.1 Projektstrukturplan
3.2.2 Risiko- und Chancenplanung
3.2.3 Zeitplanung
3.2.4 Ressourcenplanung
3.2.5 Projektorganisation
3.2.6 Kosten- und Cashflowplanung
3.2.7 Informations- Kommunikations- und Dokumentationsplanung
3.2.8 Projektauftrag

4 Projektdurchführung
4.1 Systementwicklung
4.2 Horizontales Prototyping (On-line-Prototyping)
4.3 Projektmanagement
4.3.1 Projektsteuerung
4.3.2 Kommunikationsmanagement
4.3.3 Änderungs-/ Nachforderungsmanagement

5 Projektende und -betreuung
5.1 Abschlussdokumentation
5.1.1 Abschlussbericht
5.1.2 Erfahrungssicherung
5.2 Projektabschluss
5.2.1 Nachbetrachtung
5.2.2 Abnahme
5.3 Nachbetreuung

6 Zusammenfassung

Literaturverzeichnis

Glossar

Anhang

A Das agile Manifest

Abstract

Die vorliegende Arbeit beschäftigt sich mit dem Projektmanagement in der webbasierenden Softwareentwicklung und legt dabei den Fokus auf die Verwendung von sogenannten horizontalen Prototypen innerhalb des Projektverlaufes.

Es wird untersucht, welche Vorgehen sich unter den speziellen Umständen der Webentwicklung eignen und für welche Arten von Webprojekten sich welche Vorgehensweisen am besten anbieten. Dabei werden anhand verschiedenster Spezifikationen die etablierten Vorgehensmodelle untersucht und einander gegenübergestellt. Zusätzlich wird betrachtet, unter welchen Voraussetzungen es sinnvoll ist, Prototyping zu verwenden. Es wird gezeigt, dass es für das Management die unterschiedlichsten Gestaltungsmöglichkeiten rund um die Projektplanung gibt, wie zum Beispiel die Durchführung von Webprojekten. Zudem werden die wichtigsten Phasen und Methoden beschrieben, unabhängig von der aufbauenden Vorgehensweise eines Webprojektes und anhand eines durchgehenden Fallbeispiels praxisnah illustriert.

Die Untersuchungen, Auswertungen und Bewertungen beruhen auf spezifischer Fachliteratur sowie den langjährigen Erfahrungen des Autors.

Abbildungsverzeichnis

Abbildung 1.1: Statistik über das Scheitern von Webprojekten, aus [TIMEKONTOR01]

Abbildung 1.2: Einflussfaktoren auf das Projektmanagement, inspiriert von [KAMISKE11], S. 9

Abbildung 1.3: Die Netzwerkkommunikation zwischen Client (linke Seite) und Server (rechte Seite)

Abbildung 1.4: Projektfelder eines Webprojektes nach [STOYAN07], S. 3

Abbildung 1.5: Die Prototypstrategien, inspiriert durch [BALZERT98], S. 116

Abbildung 2.1: Der Aufbau der Ablauforganisationsplanung

Abbildung 2.2: Minimalistische Illustration der Vorgehens-Grundmodelle

Abbildung 2.3: Beispielhafte Illustration eines Ad-hoc-Vorgehens

Abbildung 2.4: Illustration des Schleifenmodells

Abbildung 2.5: Illustration des Spiralmodells

Abbildung 2.6: Illustration des V-Modells

Abbildung 2.7: Phasen eines Webprojektes von der britischen Webagentur pres.co

Abbildung 2.8: Wahlkriterien zum Vorgehensmodell auf Grundlage von [SARRE06], S. 22

Abbildung 2.9: Beispiel für einen horizontalen Prototypen auf der Datenbankebene

Abbildung 3.1: Vom Projektstart bis zum Projektende – Illustration

Abbildung 3.2: Off-line-Prototyp der innovativen Desktop-Variante

Abbildung 3.3: Off-line-Prototyp der mobilen Variante von der Produktdetailansicht

Abbildung 3.4: Ein gemischter Projektstrukturplan für das Fallbeispiel

Abbildung 3.5: Übersicht über den Arbeitsplan der Projektmitarbeiter, erstellt mit MS Project

Abbildung 3.6: Diagramm zu den Plankosten von Personal/ Dienstleistungen

Abbildung 4.1: Das konstruierte Vorgehensmodell für das Fallbeispiel

Abbildung 4.2: On-line-Prototyp als Pilotsystem nach dem zweiten Entwicklungszyklus

Abbildung 4.3: On-line-Prototyp als Pilotsystem nach dem vierten Entwicklungszyklus

Abbildung 4.4: On-line-Prototyp als Demonstrationsprototyp für eine mobile Webanwendung

Abbildung 4.5: Die Facetten der Projektkontrolle - eine Illustration

Tabellenverzeichnis

Tabelle 2.1: Vorgehensmodelle im Vergleich

Tabelle 3.1: Projektziele bestimmen

Tabelle 3.2: Eine Anforderungssammlung für ein Zielsystem

Tabelle 3.3: Eine Stakeholder-Analyse für das Fallbeispiel

Tabelle 3.4: Bewertung eines Projektes anhand des Fallbeispiels

Tabelle 3.5: Agenda für ein Kick-Off-Meeting

Tabelle 3.6: Risikobewertung für das Fallbeispielprojekt

Tabelle 3.7: Die Projektzeitplanung, erstellt mit MS Project Professionell 2013

Tabelle 3.8: Eine grobe Terminplanaufstellung

Tabelle 3.9: Plankalender zum Ressourcengebrauch, erstellt mit MS Project Professionell 2013

Tabelle 3.10: Kostenaufstellung zum Fallbeispiel, erstellt mit MS Project

Tabelle 3.11: Beispiel eines Berichtsplans

Tabelle 3.12: Kommunikationsregeln für das Fallbeispiel

Tabelle 3.13: Beispiel für einen Projektauftrag

Tabelle 4.1: Gewichtung der individuellen Vorgehenskriterien

Tabelle 4.2: Vergleich von SOLL- und IST-Projektkosten

Tabelle 4.3: Ein Auszug eines Statusberichtes

Tabelle 4.4: Kommunikationsmatrix für das Fallbeispiel

Tabelle 4.5: Beispiel für eine Agenda für eine Besprechung/ Meeting/ Treffen

Tabelle 4.6: Beispiel eines Gesprächsprotokolls

Tabelle 4.7: Change-Antrag – Projektspezifikationen schriftlich abändern

Tabelle 4.8: Change Log – eine Auflistung sämtlicher Projektänderungen

Tabelle 5.1: Ein Projektabschlussbericht für das Fallbeispiel

Tabelle 5.2: Ein Auszug aus dem Projektreview für das Fallbeispiel

Tabelle 5.3: Feedbackbogenbeispiel für interne Projektmitarbeiter

Tabelle 5.4: Eine Agenda für das Abnahmetreffen mit anschließender Abschlussfeier

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Diese Bachelorarbeit beschäftigt sich mit den verschiedenen Möglichkeiten der Herangehensweisen für die Durchführung von webbasierten Projekten und den damit zusammenhängenden Aspekten. Dabei werden die verschiedenen Herangehensweisen untersucht und auf ihre Tauglichkeit zum jeweiligen Projektumfeld überprüft. Es wird dabei versucht, eine Sensibilisierung für die Gestaltung des individuellen Projektablaufes zu schaffen, um dabei die wichtigsten Abschnitte eines Webprojektes zu beleuchten, mit einer Spezialisierung auf das horizontale Prototyping. Dabei wird ebenfalls untersucht, welche Einsatzmöglichkeiten sich für das Prototyping ergeben und in welchen Fällen ein solcher Einsatz Sinn macht. Die in der Arbeit beschriebenen Methoden und Vorgehensweisen beziehen sich dabei stets auf sämtliche Arten der internetbasierten Softwareentwicklung. Durch den Umfang werden die einzelnen Elemente breit beschrieben, um einen möglichst umfassenden Überblick über die zahlreichen Möglichkeiten zu gewährleisten. Dabei liegt hier der Fokus speziell auf das horizontale Prototyping.

Ein Fallbeispiel untermauert die Arbeit, welches praxisnah die theoretischen Ansätze veranschaulicht. Das Beispiel ist in markierten Bereiche jeweils gekürzt. In der Praxis fallen die jeweiligen Methoden wesentlich komplexer aus. Zudem ist die Gestaltung der einzelnen Methoden und Dokumente Geschmackssache und sollte dem jeweiligen Projekt angepasst werden; somit ist das Beispiel nicht als Garant oder Musterbeispiel anzusehen. Das Fallbeispiel ist durch seitliche Striche an der linken Seite in den einzelnen Bereichen kenntlich gemacht.

Der Auftraggeber

Herr Mustermann (männlich, 49 Jahre, ledig) ist ein selbstständiger Einzelhandelskaufmann und betreibt einen sehr gut laufenden und berühmten Schmuckladen in Berlin. Durch seine exzentrische Art, den medienwirksamen Auftritten und seinem Gespür für alles, was reiche Menschen mögen, hat er seinen Laden zu einer äußerst lukrativen Einnahmequelle gemacht. Es ist ihm anzumerken, dass er kein computer-affiner Mensch ist und dass er das Internet lediglich zum Netzwerken und Promoten verwendet.

Das Unternehmen

Das Unternehmen ist ein Webentwicklungsstudio aus Berlin mit insgesamt 50 Mitarbeitern. Es hat sich durch seine preiswerten Dienstleistungen und positiven Rezensionen auf den Markt gut positioniert. Der Erfahrungsschatz des Unternehmens beläuft sich auf mittlerweile zehn erfolgreiche Geschäftsjahre.

1.1 Problemstellung

„Selbst wenn sich in 9 von 10 Fällen eine gewisse Vorgehensweise im Umgang mit Kunden etabliert hat, irgendwann kommt dieser 10. Kunde, für den diese Vorgehensweise nicht passt.“ ^[1]

Was Dennis Erdmann in diesem Zitat aussagt, ist ein wichtiger Punkt in Webprojekten; jedes Webprojekt ist außerordentlich unterschiedlich und stellt somit eine neue Herausforderung für das ausführende Unternehmen dar, welche mit individuellen Methoden und Verfahren in Angriff genommen werden muss. Neben den unterschiedlichen Arten von Auftraggebern und sich wechselnden Projektumfeldern kommt noch hinzu, dass Webprojekte in ihrem Umfang und ihrer Ausprägung so unterschiedlich sind, dass sich kein „Allrounder“-Vorgehensmodell herauskristallisieren lässt. Die Möglichkeiten, Dienste im Internet zu realisieren, waren nie so vielfältig wie heute. Durch diese große Vielfalt an technischen- und gestalterischen Möglichkeiten des Produktes auf der einen Seite und die Vielfalt an unterschiedlichen Typen von Auftraggebern auf der anderen Seite, lässt sich die Projektarbeit in Webprojekten nicht homogen gestalten.

Nach der Studie: "Wie zufrieden sind Sie mit ihrem IT-Dienstleister?", wurde 2001 im Raum Berlin-Brandenburg, ermittelt, dass Webprojekte in 19,3% der Fälle scheiterten und in 6,3% der untersuchten Beispielfälle, frühzeitig abgebrochen wurden.^[2] Entweder, da diese zu spät oder mit zu vielen Ressourcen erstellt wurden, die zeitlichen Rahmen nicht eingehalten wurden, der Auftraggeber mit dem Resultat unzufrieden war und vieles andere mehr. Die Ursachen hierfür sind vielfältig. Hauptsächlich wurde von den Beteiligten mangelnde Kommunikation als Grund des Scheiterns angegeben, aber auch eine schlechte Projektplanung, schlecht gewählte Vorgehensmodelle und überforderte Auftraggeber stehen oben auf der Mängelliste (siehe Abbildung 1.1).^[3]

Abbildung 1.1: Statistik über das Scheitern von Webprojekten, aus [TIMEKONTOR01]

Anhand der Statistik in der Abbildung 1.1 ist zu sehen, wie wichtig es ist, die Projektdurchführung ordentlich zu planen und das korrekte Vorgehen sowie die passenden Methoden zu wählen. Je größer und komplexer die Projekte werden, desto höher ist die Gefahr des Scheiterns. Dabei erlebt die Webentwicklung, durch den technologischen Fortschritt, eine steigende grundlegende Komplexität, bei gleichzeitig steigendem Zeit- und Konkurrenzdruck.

Durch diese Umstände werden viele Webprojekte falsch durchgeführt und entwickeln sich zu einer Belastung, sowohl für den Auftraggeber als auch für den Auftragnehmer und sind somit zum Scheitern verurteilt. Das Problem der Auswahl der richtigen Herangehensweise stellt viele Leiter von Webprojekten vor ein reales Problem. Welches Vorgehen sollte bei welchem Kunden, welcher Projektart sowie welchem Projektumfeld verwendet werden? Wie sehen die Methoden und Instrumente dieser Vorgehensmodelle aus und wie kann ich sie einsetzen?

Mit genau diesen Problemen soll sich die vorliegende Arbeit beschäftigen.

1.2 Zielstellung der Arbeit

Die Zielstellung dieser Bachelorarbeit ist es, verschiedene Herangehensweisen für Webprojekte aufzuzeigen, die mit ihren Methoden und Instrumenten, passend zur individuellen Art von Webprojekten sind. Dabei sollen die angewandten Methoden und Instrumente aus der Theorie sowie der praktischen Arbeit einer kritischen Beurteilung unterzogen werden. Es soll aufgezeigt werden, dass jedes Vorgehen eine begründete Existenzberechtigung aufweist und für welche Art von Webprojekt sich welche Vorgehensmodelle eignen. Zusätzlich wird untersucht, unter welchen Umständen Prototyping, speziell horizontales Prototyping, eingesetzt werden sollte. Anhand vorgehensneutraler Phasen und Methoden wird der komplette Projektlebenszyklus der Softwareentwicklung betrachtet; basierend auf der Ebene der Internettechnologien.

Dabei wird darauf Wert gelegt, dass die Arbeit verständlich geschrieben ist- und somit für eine möglichst breite Leserschaft zur Verfügung steht. Zusätzlich werden die einzelnen Abschnitte mit einem durchgehenden Fallbeispiel zur praktischen Veranschaulichung der theoretischen Ansätze versehen; dabei wird ein Webprojekt konstruiert, das den Fokus auf das horizontale Prototyping hält.

1.3 Grundlegendes und Begriffsdefinitionen

Damit die wesentlichen Aspekte und Fragestellungen des webbasierten Projektmanagements mit horizontalen Prototyping geklärt werden können, sollte zunächst Klarheit über die Begrifflichkeiten bestehen, die mit dem Projektmanagement einhergehen; auf diesen Fundament wird die Thesis aufgebaut. Folgend werden die zentralen Begriffe des Projekt-managements bei der Entwicklung von Webprojekten definiert und abgegrenzt.

1.3.1 Projekt

Der Begriff „Projekt“ ist ein heutzutage häufig verwendeter Begriff. Verglichen mit bestehenden Definitionen, gelingt es dem Betrachter zu erkennen, dass die meisten Projekte gar keine sind.

Ein Projekt kennzeichnet sich dadurch, dass es zum Zwecke der Vollendung eines Vorhabens über einer temporären Organisation durchgeführt wird, mithilfe moderner Management-Methoden. Es ist ein einmaliges, neuartiges, zielorientiertes, komplexes, risikobehaftetes, dynamisches, fachübergreifendes sowie bedeutendes Vorhaben, zu welchem sich bestimmte Ressourcen für einen bestimmten Zeitrahmen mit einem bestimmten Leistungsanteil zusammenfassen (die drei Konstanten eines Projektes).^[4]

Die genannte Definition erscheint offensichtlich, allerdings kranken viele Projekte in der Praxis daran, dass einzelne Eigenschaften, wie beispielsweise klar definierte Ziele, nicht eindeutig festgelegt werden.

1.3.2 Projektmanagement

Wie unter der Definition von „Projekt“ zu lesen ist, ist ein Projekt ein komplexes Unterfangen, zu dessen erfolgreichem Gelingen eine spezielle- und koordinierte Art der Aufgabenbewältigung angewandt werden muss. Das Projektmanagement ist die Gesamtheit von Führungsaufgaben (Führungsorganisation, Führungstechniken, Führungsmittel) für die Abwicklung eines Projektes mit der Aufgabe, das Gesamtziel/ den Erfolg des Projektes effizient und effektiv im zeitlichen Rahmen zu erreichen, durch eine systematische, durchgehende sowie zielorientierte Koordination von Ressourcen.^[5]

Entsprechend der drei Konstanten in einem jeden Projekt (Ressourcen, dem Umfang des Projektes und der gegebenen Zeit) kann das Projektmanagement die Qualität des Projektergebnisses steuern. Im Mittelpunkt steht dabei stets das Projektziel, auf dem, im Projektmanagement, alle erforderlichen Methoden und Führungsmittel auszulegen sind. Beim Projektmanagement sollte eine enge Verbundenheit zwischen den fachlichen, methodischen (Planung, Controlling, etc.) und soziologischen Aspekten (Führung, Teamentwicklung, Kommunikation, etc.) gegeben sein, wie in der Abbildung 1.2 zu sehen.^[6]

Zusätzlich muss im Projektmanagement die Einbettung des Projektes in die vorgegebene Umgebung beachtet werden, welche geprägt ist durch das geschäftliche Umfeld, die Öffentlichkeit, den Kunden sowie durch die Firmenorganisation und die relevanten firmeninternen Prozesse. ^[7]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2: Einflussfaktoren auf das Projektmanagement, inspiriert von [KAMISKE11], S. 9

1.3.3 Webanwendungen

Eine Webanwendung (oder Webapplikation, Web-App, Websystem), ist ein Sammelbegriff für jegliche Art von Anwendungsprogrammen/ Softwaresystemen, welche über eine Benutzerschnittstelle und den Webbrowser ablaufen bzw. dargestellt werden und dabei auf webspezifische Ressourcen aufbauen. Ein wesentlicher Aspekt dieser Anwendungen ist die Zusammenwirkung zwischen dem Anwender und der Software, was eine Erweiterung des Problembereichs darstellt.

Webanwendungen können sich je nach Art (Vielzahl von Spezifikationen) und Umfang stark voneinander unterscheiden. Häufig verwendete Spezifikationen für diese Unterteilung sind: Inhalt, Erreichbarkeit, Sprache, Flexibilität, Funktionalität, Performance, Sicherheitsanforderungen und Zielpublikum.^[8]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.3: Die Netzwerkkommunikation zwischen Client (linke Seite) und Server (rechte Seite)

Webanwendungen werden meist auf einem Webserver gespeichert. Der Zugriff auf diese Anwendungen erfolgt sowohl über öffentliche IT-Netze (Internet), als auch über interne IT-Netze (Intranet) mittels eines Übertragungsprotokolls wie http (siehe Abbildung 1.3). Webanwendungen benötigen, anders als Desktopanwendungen, kein spezielles Betriebssystem (OS) und sind somit Plattformunabhängig. Daher können Webanwendungen plattformübergreifend eingesetzt werden (teilweise werden spezielle Laufzeitumgebungen allerdings gefordert). Da eine Webanwendung über ein Zusatzprogramm (Webbrowser beim Client) aufgerufen wird und über spezielle Protokolle geleitet werden muss, sind Webanwendungen an entsprechenden Restriktionen gebunden. Je nach der Programmierung der Anwendung werden mehr oder weniger Berechnungen auf den Client oder Server ausgeführt, was eine entsprechende Auslastung des jeweiligen Systems mit sich zieht.^[9]

1.3.4 Web Engineering

„Moderne Web-Anwendungen stellen vollwertige, komplexe Softwaresysteme dar. Die Entwicklung dieser Web-Anwendungen erfordert daher eine ingenieurmäßige und methodisch fundierte Herangehensweise. Ausgehend vom Software Engineering umfasst Web Engineering die Anwendung systematischer und quantifizierbarer Ansätze, um Spezifikation, Implementierung, Betrieb und Wartung qualitativ hochwertiger Web-Anwendungen durchführen zu können.“ ^[10]

Web Engineering transferiert die Methoden des Software Engineerings auf die Entwicklung von Webanwendungen und erstreckt sich über den kompletten Lebenszyklus eines Websystems. Somit ist das Web-Engineering eine Art des Software Engineerings, die viele Gemeinsamkeiten aufweisen, allerdings zu einer eigenständigen Spezialisierung führen, aufgrund der besonderen Eigenschaften von Webanwendungen (siehe 1.3.5). ^[11]

Die besonderen Anforderungen an das Web Engineering werden aus den Charakteristiken von Webanwendungen abgeleitet (siehe die Besonderheiten von Webprojekten unter dem Punkt 1.3.5), die sich aus der Sicht des Softwareprodukts sowie aus der Sicht seiner Entwicklung und seiner Nutzung ergeben.^[12]

1.3.5 Webprojekt

„Ein Webprojekt dient zur Neuerstellung oder Änderung einer Website. […] Webprojekte sind E-Businessprojekte, die wiederum einen Teil der Projekte der Informationstechnologie (IT) ausmachen. Genauso sind Webprojekte jedoch auch Designprojekte.“ ^[13]

Je nach den Gegebenheiten (die Projekteigenschaften sind aus dem Abbildung 1.4 zu entnehmen) des Webprojektes, ist es in Relation der Projektfelder zuzuordnen. Entsprechend ihrer Zuordnung sollten die Vorgehensweisen und Methoden für das Projekt gewählt werden (mehr dazu siehe im Abschnitt 2 dieser Arbeit).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.4: Projektfelder eines Webprojektes nach [STOYAN07], S. 3

Abbildung 1.4: Projektfelder eines Webprojektes nach [STOYAN07], S. 3

Besonderheiten von Webprojekten gegenüber IT-Projekten

Webprojekte weisen einige Besonderheiten gegenüber klassischen Softwareprojekten auf, welche das Projektmanagement in seiner Ausführung beeinflussen; diese werden folgend nach Robert Stoyan^[14] aufgeführt:

Die Projektzyklen sind aufgrund der Schnelligkeit im Web sehr kurz

Der Inhalt (Content) sollte ständig im System aktualisiert werden

Inhaltspflege, Weiterentwicklung, Betreuung, etc. verursachen i.d.R. höhere Kosten als die Erstellung des Systems

Durch das Treffen sämtlicher Unternehmen im Internet ist die Abgrenzung zwischen diesen ein wichtiger Faktor (sogenannte Markenfusion)

Die Anwender/ Zielgruppen sind hier besonders unterschiedlich/ vielfältig

Bei Webprojekten findet eine stark-interdisziplinäre Zusammenarbeit statt

Websysteme sind ständigen Änderungseinflüssen ausgesetzt

Die Preis- sowie Zeitplanung (Vertragsgestaltung) ist schwierig umzusetzen

1.3.6 Prototyping

„Ein Prototyp ist die erste Version eines Softwaresystems, die dazu verwendet wird, Konzepte zu demonstrieren, Entwurfsmöglichkeiten auszuprobieren und Erkenntnisse über das Problem und seine möglichen Lösungen zu gewinnen.“ ^[15]

„We define a prototype as a concrete representation of part or all of an interactive system.“ ^[16]

Prototyping ist grundsätzlich eine Methodik, die in einer Phase des Projektes abgearbeitet werden kann. Prototyping ermöglicht es das Zielsystem schnell und ressourcenschonend zu realisieren, innerhalb des Rahmens der für den Verwendungszweck (siehe Verwendungsarten weiter unten) benötigt wird. Die Kommunikation zwischen den verschiedenen Projektbeteiligten und den verschiedenen Disziplinen in der Webentwicklung wird durch die Erstellung von Prototypen gestärkt. Prototypen ermöglichen zudem eine Art von Interaktion, welche durch textliche Beschreibungen so nicht möglich ist (beispielsweise können Ausgaben und Größe/ Position von Elementen visualisiert werden).^[17]

„Ein Bild sagt mehr als tausend Worte“ ^[18]

Es können hauptsächlich zwei verschiedene Arten des Prototyping unterschieden werden: Evolutions-Prototyping und Wegwerf-Prototyping. Bei den Evolutions-Prototyping handelt es sich lediglich um die evolutionäre Systementwicklung. Bei dem evolutionären Vorgehensmodell wird das Zielsystem in mehreren iterativen Schritten entwickelt (siehe 2.1.4). Das unfertige System, welches stetig weiterentwickelt wird und zum Testen dient, nennt man auch Prototyp (Pilotsystem). Dabei wird der Prototyp solange weiterentwickelt (evolutionär Entwickelt), bis sämtliche Anforderungen und Zielsetzungen erfüllt sind.

Bei dem Wegwerf-Prototyping wird ein Prototyp unabhängig von der Zielsystementwicklung erstellt, i.d.R. innerhalb des ersten Projektabschnittes. Mit Hilfe von diesen Prototypen können Anforderungen erhoben und Tests vollzogen werden, ohne dabei Ressourcen zu vergeuden. Das Wegwerf-Prototyping kann sowohl in sequenziellen als auch in iterativen Vorgehensmodellen eingesetzt werden. Sollte das Zielsystem fertiggestellt sein, so wird dieser Prototyp nicht weiter verwendet (sprichwörtlich: weggeworfen).

Wie in der Abbildung 1.5 zu sehen, existieren unterschiedliche Prototyp-Strategien, welche Zeit einsparen können: Horizontale-, vertikale-, Szenario- und aufgabenorientierte Prototypen. Im Folgenden werden diese nun vorgestellt.^[19]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.5: Die Prototypstrategien, inspiriert durch [BALZERT98], S. 116

Vertikales Prototyping

„Cutting down on the number of features is called vertical prototyping since the result is a narrow system that does include in-depth functionality, but only for a few selected features.“ ^[20]

Beim vertikalen Prototyping wird ein kleiner Teil des Systems sichtbar gemacht, bei einer möglichst vollständigen Funktionalität.^[21]

Horizontales Prototyping

„Reducing the level of functionality is called horizontal prototyping since the result is a surface layer that includes the entire user interface to a full-featured system but with no underlying functionality.” 4

Das horizontale Prototyping bildet lediglich eine spezifische Ebene eines Softwareproduktes ab und somit eine Ebene des Websystems. Die strikte Umsetzung lediglich einer Ebene ist hierbei nicht vorgeschrieben und kommt in der Praxis kaum vor.^[22]

Diese Ebene kann sowohl die Benutzeroberfläche als auch beispielsweise die Datenbankstrukturierung sein. Durch die Beschränkung auf eine Ebene sind horizontale Prototypen schnell entworfen und können in ihrer Ausführung sehr unterschiedlich ausfallen. In der Webentwicklung wird, aufgrund der starken Ausprägung des visuellen Charakters, größtenteils das horizontale Prototyping auf Ebene der Benutzeroberfläche (Design) realisiert (ähnlich bei Unterhaltungssoftware).^[23]

“Prototyping is primarily a design activity, although we use software engineering to ensure that software prototypes evolve into technicallysound [sic] working systems and we use scientific methods to study the effectiveness of particular designs.” ^[24]

Horizontale Prototypen, welche auf der Benutzeroberfläche realisiert werden

(Design-Prototyp), bilden die Mensch-Computer-Schnittstelle ab und können in zwei unterschiedliche Arten unterschieden werden: Off-line- (siehe 3.1.2) und On-line-Prototypen (siehe 4.2).

Szenario-Prototyping

Wenn die Funktionalität als auch die Benutzeroberfläche redundant wird, so erhält man ein Szenario.

„Scenarios are the ultimate minimalist prototype in that they describe a single interaction session without any flexibility for the user. As such, they combine the limitations of both horizontal prototypes […] and vertical prototypes […].“ ^[25]

Szenarien helfen während des Entwicklungsprozesses zu verstehen, wie Benutzer mit einem System interagieren. Zudem können Szenarien verwendet werden, um schnelle Evaluationen zur Benutzeroberfläche zu erhalten, ohne einen lauffähigen Prototypen- oder gar ein komplettes System zu konzipieren (beispielsweise für Softwareergonomie-Tests an bestimmten Funktionen).^[26]

Aufgabenorientiertes Prototyping

„Task-based prototypes are organized as a series of tasks, which allows both designers and users to test each task independently, systematically working through the entire system.“ ^[27]

Aufgabenorientierte Prototypen beinhalten lediglich die Oberflächen und Funktionalitäten, welche für eine spezifische Programmaufgabe erforderlich sind. Durch die Kombination von horizontalen und vertikalen Prototypen ist es möglich, eine genaue Analyse einer Aufgabe im Programm durchzuführen.^[28]

Prototypische Verwendungsarten

Ein „Demonstrationsprototyp“ soll eine Vorschau auf das komplette oder auf einen Teil des Zielsystems ermöglichen. Durch eine schnelle und oberflächliche Prototypgenerierung entstehen keine hohen Kosten. Eine weitere Verwendung wird dem Prototyp nicht zuteil.

Bei einem „Prototyp im engeren Sinne“ wird dieser, der Anwendungsentwicklung, nebenläufig entwickelt, um Teile des Systems (Funktionen wie Oberflächen) zu veranschaulichen und zu analysieren. Der Prototyp wird in der Regel nach dem Projekt entsorgt.

Ein „Labormuster“ demonstriert die funktionelle/ architektonische Umsetzbarkeit von Systemen. Anhand des Labormusters können Fragen im konstruktionstechnischen Rahmen beantwortet werden und geben ggf. Aufschluss über mögliche Alternativen. Die Umsetzung findet in der Regel innerhalb des Projektteams statt und sollte mit den jeweiligen Zielsystemen übereinstimmen.

Die vierte Verwendungsart von Prototypen ist das „Pilotsystem“, welches eine andere Bezeichnung für das evolutionäre Prototyping ist. ^[29]

2 Ablauforganisationsplanung

„Ein gutes Projektmanagement basiert auf einem zielgerichteten Phasenmodell, beziehungsweise Vorgehensmodell. Dieses standardisiert die ablauforganisatorische Gestaltung des Vorgehens.“ ^[30]

Da es in der Softwareentwicklung unmöglich ist, ein universelles Vorgehensmodell (Denkansatz, wie ein Projekt durchgeführt wird), aufgrund der zu vielen Variablen, zu finden, sollte zu jedem Projekt ein individuelles Vorgehen bestimmt werden, nach dem das Projekt durchgeführt werden soll.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Der Aufbau der Ablauforganisationsplanung

Die Ablauforganisation von Projekten besteht grundsätzlich aus einem Vorgehensmodell (kann aus Grundmodellen abgeleitet sein), welches den Ablauf des Projektes in den Grundzügen regelt. Innerhalb des Vorgehensmodells befinden sich Phasen, welche aus Phasenmodellen (siehe 2.3) aufgebaut sein können oder davon abgeleitet sind und sich in ihrer Ausrichtung an dem Vorgehensmodell orientieren. Die Phasen geben grob vor, was in welchem zeitlichen Abschnitt im Projektzyklus jeweils zu tun ist. Die einzelnen Phasen wiederum beinhalten Prozesse, Methoden und Richtlinien, welche konkrete Vorgaben vermitteln, die zeigen, auf welche Art was zu tun ist. Eine Illustration dazu findet sich in der Abbildung 2.1 auf der Seite 16.

Da die konkrete Betrachtung der Ablauforganisationsplanung den Rahmen dieser Arbeit sprengen würde, werden lediglich die für diese Arbeit jeweils wichtigen und relevanten In-halte behandelt.

Zum Thema Ablauforganisationsplanung können die Bücher [SOMMERVILLE12], [BALZERT98] und die Dissertation [GNATZ05] empfohlen werden. Zum Thema Prototyping im IT-Projekt wird [NIELSON93] empfohlen.

2.1 Vorgehens-Grundmodelle

„Eine planvolle, systematische Beschreibung der einzelnen Prozessschritte wird als Vorgehensmodell bezeichnet. […] In Vorgehensmodellen wird der organisatorische Ablauf für die Entwicklung eines IT-Systems beschrieben. Im Vordergrund steht die Frage: ‚Was ist wann zu tun?‘ “ ^[31]

Ein Vorgehensmodell ist eine Abstraktion einer vorgeschlagenen Vorgehensweise für ein konkretes Projekt. Bedingt dadurch existiert eine große Anzahl an Vorgehensmodellen mit ihren möglichen Ausprägungen (konkrete Vorgehen werden im Kapitel 2.2 behandelt). Die Hauptintention von Vorgehensmodellen kann auf die Effizienzsteigerung und auf die Nachvollziehbarkeit von Projekten reduziert werden.^[32]

„Das Vorgehensmodell selbst kann als ein übergeordneter Plan angesehen werden, der Vorgehensweisen, Richtlinien, Empfehlungen und Prozessbeschreibungen enthält, die dann auf ein konkretes Projekt übertragen werden können.“ ^[33]

Vorgehensmodelle stellen eine Wiederholbarkeit und Nachvollziehbarkeit eines Ablaufprozesses sicher. Dabei gewährleisten sie die Qualität und Vollständigkeit der Projektergebnisse. Durch einheitliche Begriffe und Ereignisse tragen Vorgehensmodelle zur besseren Kommunikation aller Projektbeteiligten bei.^[34]

In diesem Abschnitt wird eine Auswahl an passenden Vorgehens-Grundmodellen vorgestellt, die für die Webentwicklung wichtig sind (siehe Abbildung 2.2). Die Vorgehensmodelle werden dabei nicht umfassend untersucht, sondern es wird lediglich eine kurze Beschreibung der wesentlichen Eckdaten dargestellt, wie deren Unterschiede untereinander und die jeweiligen Verwendungsvorschläge.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Minimalistische Illustration der Vorgehens-Grundmodelle

2.1.1 Sequenzielle Vorgehensmodelle

Bei den sequenziellen Vorgehensmodellen, auch lineare Vorgehensmodelle genannt, werden die definierten Projektphasen chronologisch angeordnet und streng abgegrenzt voneinander durchlaufen. Die Idee hinter diesen Modellen ist, dass die Phasen Schritt für Schritt durchlaufen werden; dabei muss eine Phase zunächst abgeschlossen sein, bevor die nächste Phase angefangen werden kann. Das bedeutet allerdings auch, dass spätere Änderungen oder Erkenntnisse keinen Einfluss mehr auf die bereits abgeschlossenen Phasen haben. Daher ist es wichtig, dass die Zwischenergebnisse (Phasenprodukte) valide und gut vorgeplant worden sind. Der typischste Vertreter dieses Vorgehensmodells ist das erweiterteWasserfall-Modell (auch Schleifenmodell genannt, siehe 2.2.2) und das V-Modell (siehe 2.2.4).^[35]

Sollten sich im Laufe der Entwicklung Anforderungsänderungen ergeben, so muss für die Änderungen die Prozesskette noch einmal komplett vom Punkt der Veränderung bestritten werden. Aus diesem Grund ist bei diesem Vorgehensmodell wichtig, dass die Eigenschaften und Funktionen (Anforderungen) möglichst im Vorfeld abgeklärt worden sind. Daher wird in diesem Verfahren viel Wert auf eine gründliche Projektstartphase gelegt.

Auch bei einer gründlichen Projektplanung kann es vorkommen, dass Anforderungsänderungen sich im Laufe eines Projektes ergeben. Diese sind in diesem Vorgehen zeitintensiver als beispielsweise evolutionäre Vorgehensweisen und sind daher nach Möglichkeit zu vermeiden.^[36]

Vorteile

Einfacher und gut überwachbarer Projektablauf für alle Projektbeteiligten

Sehr gute Strukturierung und Dokumentation vom Projekt

Relativ einfache Gestaltung von Projektverträgen^[37]

Sehr gute Skalierbarkeit

Geringes Kosten- und Zeitrisiko für den Auftraggeber

Widerspruchsfrei - anders als andere Vorgehensmodelle^[38]

Nachteile

Spätere Anwender werden nur zu Beginn und zum Ende des Projekts eingebunden

Sichtbare Ergebnisse sind erst spät im Projektverlauf sichtbar

Es müssen früh weitreichende Festlegungen getroffen werden

Entwickler wenden oft Tricks in der späteren Implementierung an, um Probleme der ersten Phasen auszumerzen^[39]

Niedrige Ressourcenauslastung durch ggf. auftretende Wartezeiten

2.1.2 Nebenläufige Vorgehensmodelle

Nebenläufige Vorgehensmodelle, auch parallele Vorgehensmodelle genannt, sind zwar in ihrer Herangehensweise sequenziell, aber es wird dabei versucht möglichst viele Aktivitäten parallel ausführen zu lassen, um Zeit einzusparen. Dabei können sowohl Entwicklungsaktivitäten, als auch komplette Projektphasen parallelisiert werden. Wie bei den sequenziellen Vorgehensmodellen wird auch hier ein erhöhter Zeitaufwand in die Anfangsplanung des Projektes, sowie in die Ausarbeitung der Anforderungen, gesteckt.

Zu beachten ist, dass die nebenläufigen Vorgehensmodelle einen großen Kommunikations- und Koordinationsaufwand mit sich bringen. Dabei kann es zu einem kaskadenartigen Effekt kommen (Managementaufgaben häufen sich proportional), wobei ganze Teilprojekte still stehen können oder gar komplett scheitern. Daher ist dieses Vorgehensmodell für große oder stark verteilte Projekte nicht zu empfehlen.

Vorteile

Durch Parallelisierung wird die Zielprodukterstellung mittels optimaler Zeitaus-nutzung verkürzt

Relativ einfache Gestaltung von Projektverträgen^[40]

Sehr gute Skalierbarkeit

Geringes Kosten- und Zeitrisiko für den Auftraggeber

Der erhöhte Kommunikationsaufwand bringt das Expertenwissen im Team früh voran

Nachteile

Erhöhter Managementaufwand, um die Ressourcen zu planen und ggf. aufzuteilen, sodass Engpässe antizipiert werden können

Spätere Anwender werden nur zu Beginn und zum Ende im Projekt eingebunden

Sichtbare Ergebnisse sind erst spät im Projektverlauf sichtbar

Es müssen früh weitreichende Festlegungen getroffen werden

Entwickler wenden ggf. Tricks in der späteren Implementierung an, um Probleme der ersten Phasen auszumerzen^[41]

Bürgt durch das parallele Ausführen zusätzliche Risiken

[...]

---

^[1] [ERDMANN13]

^[2] Vgl. [TIMEKONTOR01]

^[3] Vgl. [SCHNEIDER12], S. 36 ff

^[4] Vgl. [STOYAN07], S. 2; [KAMISKE11], S. 8; DIN 69901

^[5] Nach der DIN 69901

^[6] Vgl. [TIEMEYER07], S. 277 f

^[7] Vgl. [KAMISKE11], S. 9 ff

^[8] Vgl. [STOYAN07], S. 7 ff

^[9] Vgl. [MUENZ08], S. 17 ff

^[10] [KAPPEL04], S. 1

^[11] Vgl. [KAPPEL04], S. 3 f

^[12] Vgl. [DESHPANDE02], S. 6

^[13] [STOYAN07], S. 2 f

^[14] Vgl. [STOYAN07], S. 4 ff

^[15] [SOMMERVILLE12], S. 72

^[16] [LAFON02], S. 1007

^[17] Vgl. [NIELSON93], S. 93

^[18] unbekannter Ursprung

^[19] Vgl. ebd., S. 93 ff

^[20] Ebd., S. 95

^[21] Vgl. ebd., S. 95

^[22] Vgl. [NIELSON93], S. 95

^[23] Vgl. [LAFON02], S. 1007 ff

^[24] Ebd., S. 1007

^[25] [NIELSON93], S. 99

^[26] Vgl. ebd., S. 100

^[27] [LAFON02], S. 1013

^[28] Vgl. ebd., S. 1013

^[29] Vgl. [BALZERT98], S. 115

^[30] [JENNY01], S. 63

^[31] [RUF08], S. 25

^[32] Vgl. [FRITZSCHE07], S. 8

^[33] Vgl. [SCHNEIDER12], S. 36

^[34] Vgl. [GNATZ05], S. 2

^[35] Vgl. [RUF08], S. 29 f ; Vgl. [JENNY01], S. 63 f

^[36] Vgl. [SCHNEIDER12], S. 37

^[37] Vgl. [FRITZSCHE07], S. 9

^[38] Vgl. [SOMMERVILLE12], S. 58

^[39] Vgl. ebd., S. 58

^[40] Vgl. [FRITZSCHE07], S. 9

^[41] Vgl. [SOMMERVILLE12], S. 58