Arbeitspapiere. Nr. 18 Y. Taranovych, S. Rudolph C. Förster, H. Krcmar. Standards für Entwicklungsprozesse digitaler Produktionen

Transkript

1 Arbeitspapiere Lehrstuhl für Wirtschaftsinformatik Technische Universität München Nr. 18 Y. Taranovych, S. Rudolph C. Förster, H. Krcmar Standards für Entwicklungsprozesse digitaler Produktionen Prof. Dr. H. Krcmar, Technische Universität München Institut für Informatik, Lehrstuhl für Wirtschaftsinformatik (I 17) Boltzmannstr. 3, Garching b. München Tel. (089) , Fax: (089) Garching, Juni 2005

2 Inhaltsverzeichnis Inhaltsverzeichnis... II Abbildungsverzeichnis... II Tabellenverzeichnis... II 1 Einführung Begriffsdefinitionen Digitale Produktionen Vorgehensmodell Vorgehensmodelle zur Entwicklung digitaler Produktionen Wasserfall-Modell zur Multimedia Entwicklung Prototypen-Modell Rational Unified Process SMART-Modell Vergleich der Vorgehensmodelle Zusammenfassung Literaturverzeichnis... III Abbildungsverzeichnis Abb. 1: Wasserfall-Modell zur Multimedia Entwicklung Abb. 2: Das Prototypen-Modell Abb. 3: Phasen und Arbeitsschritte im RUP Abb. 4: SMART Artefakte und ihre Abhängigkeiten Abb. 5: Beispielhaft gefüllte SMART Modellübersicht Tabellenverzeichnis Tab. 1: Anzahl von Iterationen abhängig von der Projektkomplexität Tab. 2: Vergleich der Vorgehensmodelle für das Umfeld digitaler Produktionen II

3 1 Einführung Ein Standard schafft kreative Freiräume. Er räumt Stolpersteine aus dem Weg und schafft den notwendigen Rahmen für einen erfolgreichen Projektverlauf (Osswald 2003, 57). Die Standardisierung der Entwicklungsprozesse sowohl in der Software-Branche als auch in der Branche digitaler Produktionen 1 erhöht die Effizienz und Qualität sowohl der Entwicklung als auch der erzielten Ergebnisse. Sie trägt einer besseren Strukturierung, Planung und Controlling der Entwicklungsprojekte und dadurch auch einer erhöhten Transparenz und einem besserem Verständnis der Entwicklungsprozesse bei. Nur durch Prozessstandardisierung wird erst eine vergleichende Analyse und ein Benchmarking unterschiedlicher Projekte ermöglicht. Die wertvollen Erfahrungen aus den vergangenen Entwicklungsprojekten können somit auf entstehende Projekte einfacher und systematischer übertragen werden. Darüber hinaus kann durch die Standardisierung der Entwicklungsprozesse die Kundenintegration und Kundenbeteiligung in der Entwicklung erleichtert und transparenter gemacht werden (Chroust 1992, 9). Oben genannte Aspekte sprechen dafür, dass die Standardisierung der Entwicklungsprozesse ein wichtiger Erfolgfaktor für die Entwicklungsprojekte und deren Projektmanagement ist. Sie trägt der systematischen Verbesserung des Managements der Entwicklungsprojekte bei, wodurch die Prozesse beschleunigt und vereinfacht werden können. Diese geforderte Standardisierung kann durch den Einsatz eines Vorgehensmodells gewährleistet werden (Chroust 1992, 9). Ein solches Vorgehensmodell beschreibt alle für das Projekt wichtigen Aktivitäten, Ergebnisse, Meilensteine, beteiligte Rollen und ihre Abhängigkeiten voneinander. Es dient somit als methodische Unterstützung bei Strukturierung, Planung und Durchführung von Projekten. Ziel dieser Arbeit ist es, einen Überblick über die Standardisierungsbestrebungen in Form von Vorgehensmodellen für die Entwicklung digitaler Produktionen zu geben. Im Rahmen dieser Arbeit werden etablierte und vielfach verwendete Vorgehensmodelle zur Strukturierung, Planung und Controlling von Entwicklungsprojekten aus dem Umfeld digitaler Produktionen vorgestellt. Obwohl das Problem einer fehlenden Standardisierung bei der Entwicklung digitaler Produktionen in der Branche allgemein bekannt ist (Osswald 2003, 45; Hitzges/Laich 1995; Sawhney 1995), behaupten wir, dass die vorgestellten Vorgehensmodelle die ersten ernsthaften Kandidaten auf dem Weg zur Standardisierung der Entwicklung digitaler Produktionen sind. In Kapitel 2 werden die in dieser Arbeit immer wieder auftauchenden Begriffe wie digitale Produktionen und Vorgehensmodell definiert. Kapitel 3 gibt einen Überblick über die etablierten und meist verwendeten Vorgehensmodelle für die Entwicklung digitaler Produktionen dar. In Kapitel 4 werden Parallelen zwischen den vorgestellten Modellen gezogen sowie Ähnlichkeiten und Unterschiede einzelner Modelle beleuchtet. In Kapitel 5 werden die aus der Arbeit gewonnen Erkenntnisse zusammengefasst. 1 Unter dem Begriff digitale Produktionen verstehen wir die Entwicklung bzw. Erstellung von Multimedia- Inhalten sowie die Bündelung und Bereitstellung dieser Inhalte als auch die Entwicklung und Herstellung anwendunggsorientierter Unternehmenssoftware (Rudolph/Krcmar 2004, 2)

4 2 Begriffsdefinitionen In diesem Kapitel werden die in dieser Arbeit immer wieder auftauchenden Begriffe wie digitale Produktionen und Vorgehensmodell definiert. 2.1 Digitale Produktionen Bei vielen Multimedia-Produktionen bzw. Interaktiven Medien (Osswald 2003, 3) tritt neben der Erstellung multimedialer Inhalte wie Internetapplikationen, Flash-Anwendungen, etc. die Entwicklung von Software-Komponenten in den Vordergrund des Leistungsportfolios. Eine eindeutige Unterscheidung zwischen Multimedia- und Softwareprodukten und - dienstleistungen wird somit erschwert, so dass Bedarf nach einer neuen Definition besteht. Der Terminus der digitalen Produktion soll diesen Mangel beheben. Digitale Produktionen werden als Produktionen verstanden, die zum einen der Entwicklung oder Erstellung von Multimedia-Inhalten bzw. interaktiven Medien sowie der Bündelung und Bereitstellung dieser Inhalte dienen. Zum anderen wird darunter auf Grund des zunehmenden Softwareerstellungsfokus von Multimedia-Unternehmen auch der Aspekt der Entwicklung und Herstellung von anwendungsorientierter Unternehmenssoftware subsumiert, da dies im Rahmen des Leistungserstellungsprozesses von Multimedia-Produktionen einen zunehmend wichtigen Bestandteil darstellt (Rudolph/Krcmar 2004, 2). 2.2 Vorgehensmodell Jede Entwicklung digitaler Produktionen soll in einem festgelegten organisatorischen Rahmen erfolgen. Ein solcher Rahmen kann durch ein Vorgehensmodell beschrieben werden. Ein Vorgehensmodell beschreibt den Lebenszyklus eines (digitalen) Produkts in Form von Aktivitäten. Es wird festgelegt, in welcher Reihenfolge die Aktivitäten durchgeführt werden können und welche Überschneidungen zulässig sind. Der Anfang und das Ende jeder Aktivität sind durch Meilensteine festgelegt. Das Vorgehensmodell liefert außerdem die Informationen über die für eine Aktivität relevanten Objekte und die einsetzenden Methoden und Werkzeuge (Alpar et al. 2002, 268; Zuser/ Grechenig/Köhle 2004, 69). Eine Methode ist eine Vorschrift zur Durchführung einer Aktivität und zur Repräsentation ihrer Ergebnisse (Alpar et al. 2002, 268). 3 Vorgehensmodelle zur Entwicklung digitaler Produktionen Es existieren in der Praxis eine Reihe von Vorgehensmodellen, um den Arbeitsablauf eines Projektes zu gliedern und die einzelnen Arbeitsschritte zu benennen. Viele Modelle stammen aus der Softwareentwicklung und werden an die individuellen Bedürfnisse der Branche digitaler Produktionen angepasst. Im Folgenden wird auf einige ausgewählte Vorgehensmodelle eingegangen, die sich in der Praxis in der Branche digitaler Produktionen wieder finden. Die Auswahl der Modelle wurde basierend auf Studien zur Vorgehensweisen und Methoden für die Entwicklung digitaler Produktionen getroffen (Osswald 2003; o.v. 1998; Hitzges/Laich 1995; Sawhney 1995; Boles/Wütherich 1997)

5 3.1 Wasserfall-Modell zur Multimedia Entwicklung Laut der Studie von Osswald (2003, 47) wenden über 80% der Unternehmen aus dem Umfeld digitaler Produktionen das Wasserfall-Modell für die Strukturierung ihrer Projekte an. Der Begriff Wasserfall-Modell wurde von Boehm (1981) eingeführt. Es handelt sich dabei um ein zyklisches Phasenmodell, das den Lebenszyklus bei der Softwareentwicklung in Phasen unterteilt, die sequenziell nacheinander abgearbeitet werden. Die nächste Phase beginnt erst, wenn der vorherige Schritt vollständig abgeschlossen wurde. Jede Phase des Modells hat eine Rückkopplung zur angrenzenden Vorphase, wodurch die Validierung und Verifikation der vorherigen Phase ermöglicht wird (Alpar et al. 2002, 272). In der Praxis verlaufen nahezu alle Projektphasen zu gewissen Teilen parallel und werden nie streng angehalten. Es findet oft eine Überlappung einzelner Phasen statt und diese sind meistens nicht klar voreinander trennbar. Das Vorgehensmodell zahlreicher Unternehmen aus dem Umfeld digitaler Produktionen basiert demnach auf einem Wasserfall-Modell, das aus ineinander fließenden Phasen besteht (Osswald 2003, 47). In der Abb. 1 wird ein beispielhaftes Wasserfall-Modell dargestellt, das für den Einsatz im Rahmen einer Entwicklung digitaler Produktionen optimiert wurde. Die Optimierung des Modells äußert sich in einer Überlappung und Parallelisierung einzelner Phasen sowie Orientierung der Phasenbenennungen an den Entwicklungsprozessen digitaler Produktionen. Der Grad der Überlappung, die Dauer sowie die konkrete Bedeutung einzelner Projektphasen variieren in Abhängigkeit der jeweiligen Anforderungen und Rahmenbedingungen des Projekts. Trotz der Anpassung des Modells an Gegebenheiten der Branche erfüllt es nicht alle Anforderungen an die Projektrealisierung im Umfeld digitaler Produktionen. Die typische Vorgehensweise bei der Entwicklung digitaler Produktionen schließt die Implementierung von Prototypen sowie Berücksichtigung der Risikofaktoren ein und hat oft einen iterativen Charakter. Diese Aspekte werden in diesem Modell allerdings nicht berücksichtigt. Analysis and Planning Design Implementation Testing Maintenance and Support (ongoing) Abb. 1: Wasserfall-Modell zur Multimedia Entwicklung Quelle: Straus (1997, 94) Zeit - 5 -

6 3.2 Prototypen-Modell Bei der Entwicklung digitaler Produktionen ist Prototyping als zentrales Element der meisten Entwicklungszyklen nicht mehr wegzudenken (o.v. 1998; Boles/Wütherich 1997). Alpar et al. definieren den Begriff Prototyp als: eine früh ausführbare Version des Systems, die bereits die relevanten grundlegenden Merkmale des späteren Produkts aufweist (Alpar et al. 2002, 274). Alpar et al. bezeichnen Prototyping (Prozess der Erstellung eines Prototypen) als die Vorgehensweise, Prototypen solange inkrementell zu entwickeln, zu bewerten und zu verfeinern, bis das endgültige Produkt entstanden ist (Alpar et al. 2002, 274). Prototyping hat sich in der Entwicklung digitaler Produktionen als notwendig erwiesen, da es nicht immer möglich ist, das Produkt in der Anfangsphase (z.b. Konzeptionsphase) vollständig zu spezifizieren. Die Ursachen dafür sind, dass der Auftraggeber aufgrund der Komplexität digitaler Produktionen oft keine klare Vorstellung über das zu entwickelnde Produkt bzw. Anforderung an das Produkt hat. Dies erschwert den Entwicklungsprozess und führt oft zu schlechten Produktergebnissen, Kommunikationsproblemen zwischen den Entwicklern und dem Auftraggeber sowie Zeitverlusten für daraus folgende Änderungen. Laut der am Lehrstuhl für Wirtschaftsinformatik durchgeführten Studie (Rudolph et al. 2004b, 32-36; Rudolph et al. 2004a) sind die Änderungen von Anforderungen (Change Requests) als Regelfall bei der Entwicklung digitaler Produktionen aufzufassen. Mit der Integration des Prototypings in den Entwicklungsprozess können solche Probleme zumindest teilweise vermieden werden (Mertens et al. 2001, ; Pomberger/ Pree/Stritzinger 1992). Prototyping wird nicht als eigenständiger Prozess durchgeführt, sondern in ein klassisches Vorgehensmodell (z.b. in das im Kapitel 3.1 beschriebenen Wasserfall-Modell) eingebetet. Die Erstellung eines Prototypen ist ein iterativer Prozess (Implementierung Evaluation - Adaption). Dadurch entsteht ein Lebenszyklus (Erstellung eines Prototypen) im Lebenszyklus (Erstellung des gesamten Produkts). Durch den Einsatz des Prototyping wird die Wahrscheinlichkeit, die gestrebten Ziele zu erreichen, wesentlich erhöht und das Risiko für falsche Entscheidungen signifikant reduziert, da die Anforderungsdefinition schrittweise anhand eines Prototypen und in der Interaktion mit dem Auftraggeber entwickelt wird. Das von Balzert (1998) vorgeschlagene Prototypen-Modell unterstützt systematisch die frühzeitige Erstellung von Prototypen des zukünftigen Produkts, um Umsetzung von Anforderungen und Entwürfen digitaler Produktionen zu demonstrieren und mit ihnen experimentieren. Budde et al. (1992) unterscheiden vier Arten von Prototypen: Ein Demonstrationsprototyp, der in der Regel schnell aufgebaut wird (rapid prototyping), dient zur Auftragsaquisition. Er soll dem potenziellen Auftraggeber einen ersten Eindruck vermitteln, wie das zu entwickelnde Produkt aussehen kann, und ist vom tatsächlichen Produkt noch weit entfernt. Ein Prototyp im eigenen Sinne wird parallel zur Definitionsphase erstellt, um die spezifische Aspekte der Benutzungsschnittstelle oder Teile der Funktionalität zu veranschaulichen. Ein solcher Prototyp ist ein vorläufiges, funktionierendes Produkt, das die Anforderungsanalyse unterstützen soll

7 Ein Labormuster dient dazu, konstruktionsbezogene Fragen zu beantworten, und demonstriert die technische Umsetzbarkeit des Produktmodells oder dessen Teile. Die Endbenutzer nehmen an der Evaluation eines Labormusters in der Regel nicht teil. Ein Pilotsystem ist ein Prototyp, der nicht nur zur experimentellen Erprobung oder zur Veranschaulichung dient, sondern selbst der Kern des Produkts ist. Das Pilotsystem wird von den Endbenutzern evaluiert und in Zyklen weiterentwickelt, so dass der Unterschied zwischen dem Prototyp und dem Produkt verschwindet. Abb. 2 veranschaulicht das Prototypen-Modell von Balzert. Planen (Akquirieren, Vorbereiten) Durchführbarkeitsstudie Demo-PT Akquirieren Definieren PT i.e.s Änderungen Produktmodell Benutzerbeteiligung Benutzerbeteiligung Änderungen Entwerfen Produktarchitektur Implementieren Benutzerbeteiligung Erweiterungen des Benutzers Pilotsystem Benutzerbeteiligung Produkt Labormuster Legende: PT = Prototyp Erläuterungen: Die grauen Graphikteile kennzeichnen das Prototypen-Modell. Die Gesamtgraphik zeigt eine Ergänzung der traditionellen Modelle um Prototypen. Jeder Prototyp selbst muss definiert, entworfen und implementiert werden. Der graue Teil der Aktivitäten zeigt, dass Prototypen immer nur Ausschnitte oder Teilaspekte behandeln. Abb. 2: Das Prototypen-Modell Quelle: Balzert (1998, 118) Die Einführung des Prototypen-Modells bringt auch die Nachteile mit sich. Prototyping macht das Projektmanagement komplizierter, da auf Grund der schnellen Entwicklungszeiten des Prototypen und seiner Offenheit zu Änderungen die Planung und Steuerung des Projekts erheblich erschwert werden. Bei den Anwendern und beim Management kann ein Eindruck entstehen, dass Änderungswünsche beliebig oft und lange angenommen werden können und dass mit dem ersten Prototyp das Projekt fast abgeschlossen ist. Solche Effekte müssen vermieden werden. Daher sollen unnötige Iterationen durch zusätzliche Steuerungsmechanismen (z.b. durch Meilensteine) verhindert werden. Ein solcher Mechanismus kann beispielsweise darin bestehen, Prototypen in bestimmten Projektphasen zu entwickeln (Alpar et al. 2002, 275). 3.3 Rational Unified Process Laut der Studie von Osswald (2003) setzten einige Unternehmen aus dem Umfeld digitaler Produktionen den Rational Unified Process (RUP) für Strukturierung, Planung und Controlling ihrer Projekte ein

8 Beim RUP handelt es sich um eine Implementierung des Unified Software Development Process (Jacobson/ Booch/Rumbaugh 1999). Der RUP wurde von der Firma Rational entwickelt und wird von dieser auch als ein Produkt vertrieben. Zur Unterstützung des RUP bietet Rational auch eine Reihe von darauf abgestimmten Werkzeugen in Form von Software, Handbüchern, und Dokumentationsvorlagen (Zuser/ Grechenig/Köhle 2004, 91). Das Ziel von RUP ist ein System-Entwicklungsprozess, der sich auf eine wiederholbare und nachvollziehbare Erstellung qualitativ hochwertiger Systeme konzentriert. Das Vorgehen beinhaltet die sechs Best Practices iterative Entwicklung, Anforderungsmanagement, komponentenbasierte Architektur, visuelle Modellierung, Prüfung der System-Qualität und kontrolliertes Änderungsmanagement (Krcmar 2005, 153; Kruchten 1999, 17). Der RUP definiert neun Hauptarbeitsschritte (Process-Workflows), die eine logische Einteilung und Gruppierung von Arbeiten und Aktivitäten nach Aufgabenbereichen und Disziplinen repräsentieren. Es gibt sechs Ingenieurs Arbeitsschritte (Engineering Workflows): Geschäftsprozessmodellierung (Business Modeling), Anforderungsmanagement (Requirements), Analyse und Design (Analysis and Design), Implementierung (Implementation), Test (Test), Verteilung (Deployment). Obwohl diese sechs Ingenieurs Arbeitsschritte auf den ersten Blick mit den Phasen des Wasserfallmodells übereinstimmen können, unterscheiden sich diese vor allem dadurch, dass die Arbeitsschritte im Laufe des Prozesses iterativ immer wieder durchlaufen werden. Weiterhin existieren drei unterstützende Arbeitsschritte: Konfigurations- und Änderungsmanagement (Configuration and Change Management), Projektmanagement (Project Management), Umgebung (Environment). Alle diese Arbeitsschritte durchlaufen sämtliche Etappen der Produktentwicklung. Die Höhe der Kurve in Abb. 3 stellt für jeden Arbeitsschritt dar, wie groß der Aufwand innerhalb einer bestimmten Projektphase ist. Ein kompletter Arbeitsschritt des RUP durchläuft diese neun Hauptarbeitsschritte und wiederholt diesen Durchlauf in unterschiedlichen Phasen des Projekts, wobei die Intensität und Dauer des Durchlaufs verändert wird. Zeitlich erfolgt für das gesamte Entwicklungsprojekt eine Einteilung in die Phasen Vorbereitung (Inception), Ausarbeitung (Elaboration), Konstruktion (Construction) und Übergang (Transition), welche jeweils mehrere Iterationen (in Abbildung mit I1 bis I11 gekennzeichnet) durchlaufen können, bevor der Übergang in die nächste Phase erfolgt. Während der Phase Vorbereitung erfolgt die Spezifizierung der Endproduktvision sowie der wesentlichen Geschäftsvorfälle. Zudem werden der Umfang des Projektes abgesteckt und Kosten und Risiken eruiert. Innerhalb der Ausarbeitung erfolgt das Design der Architektur wie auch die Planung der dafür notwendigen Aktivitäten und Ressourcen. Ziel der Konstruktion ist das fertige Produkt, für dessen Erreichung i.d.r. mehrere Iterationen durchlaufen werden müssen. Der Ü- bergang eines Systems an die Benutzer bildet zusammen mit der Qualitätsprüfung und dem sich daran anschließenden Training und Support den Abschluss eines RUP gesteuerten Projektes (Krcmar 2005, ; Zuser/ Grechenig/Köhle 2004, 91-96; Gornik 2001). Die genaure Anzahl der Iterationen hängt von der Projektgröße ab. Kruchten (1999) definiert folgende Werte für die Zahl der Iteration pro Phase: Komplexität Des Projekts Summe Iterationen Iterationen Beginn Iterationen Ausarbeitung Iterationen Konstruktion Iterationen Umsetzung Niedrig Normal Hoch

9 Tab. 1: Anzahl von Iterationen abhängig von der Projektkomplexität Quelle: Kruchten (1999) Abb. 3: Phasen und Arbeitsschritte im RUP Quelle: In Anlehnung an (Kruchten 1999, 23) Die Unternehmen aus der Branche digitaler Produktionen konnten bereits positive Erfahrungen mit dem RUP sammeln. Keines der Unternehmen hat aber die Anpassung des Modells an Anforderungen digitaler Produktionen komplett abgeschlossen. Der RUP eignet sich gut besonders bei großen Projekten. Für die pragmatischen Bedürfnisse eines Unternehmens durchschnittlicher Größe aus dem Umfeld digitaler Produktion ist das Modell zu umfangreich (Osswald 2003, 54). 3.4 SMART-Modell Zur Planung, Überwachung und Steuerung von Projekten im Umfeld digitaler Produktionen stellt Osswald (Osswald 2003, ) das SMART-Modell vor. Die Abkürzung SMART steht für Skalierbares Multimedia Aufgaben- und Ressourcenplanungs-Tool. Das SMART- Modell ist von Aufbau und Konzeption an den RUP angelehnt und wurde an die Belange der Branche digitaler Produktionen ausgerichtet. Es liefert ein flexibles Rahmenwerk, das an unterschiedliche Projektausprägungen und Unternehmensausrichtungen angepasst werden kann. So lassen sich Projekte mit eher technischer Ausrichtung ebenso planen und durchführen mit der Unterstützung des SMART-Modells, wie solche, die einen gestalterischen Charakter haben. Der zeitliche Verlauf des Projektes wird in drei sequenziell durchlaufenden vordefinierten Phasen Strategie, Kreation und Konzeption unterteilt und schaffen eine Trennung zwi

10 schen der Definition von Projektzielen, der Schaffung einer kreativen Idee und der Erarbeitung von konkreten Inhalten. Die Phasen Strategie und Kreation werden in der Regel zeitlich nicht weiter unterteilt. Jede weitere Phase kann einen oder mehrere kleinere zeitliche Abschnitte beinhalten, so genannte Iterationen, und wird mit einem konkreten Meilensteinergebnis abgeschlossen, bevor die nächste Phase beginnt. Die Anzahl von Phasen kann abhängig von der Projektsituation erweitert werden. Darüber hinaus beschreiben verschiedene Workflows die zu erledigenden Aufgaben und zu erzeugenden Zwischenergebnisse. Sie strukturieren den Projektverlauf inhaltlich und werden phasenübergreifend durchgeführt. Die Workflows lassen sich an individuelle Gegebenheiten der Projektaufgabe anpassen und erweitern. Das SMART-Modell definiert folgende zehn Workflows: Anforderungsmanagement Strategieentwicklung Ideenfindung auf Metaebene Definition der Funktionalitäten Redaktion Informationsarchitektur Graphisches Konzept Technisches Konzept Zeit- und Kostenmanagement Qualitätsmanagement Zwischenergebnisse, die im Verlauf der einzelnen Workflows entstehen, werden als Artefakte bezeichnet. Das SMART-Modell setzt die 50 beispielhaften Artefakte zueinander in Abhängigkeit, so dass jederzeit erkennbar ist, welche anderen Zwischenergebnisse zur Erstellung eines bestimmten Artefakts benötigt werden und welche parallel zueinander entstehen. Folgende Liste stellt einen Ausschnitt aus den Artefakten des SMART-Modells dar: Angebot Benchmark Analyse Change Request Datenbankarchitektur Designvorschlag Navigationskonzept Prototyp Programmierspezifikation Storyboard/Drehbuch Funktionsspezifikation Kostenvorschlag Szenario Technische Spezifikation Usibility Analyse Vision Zieldefinition Das SMART-Modell bildet nicht zeitliche, sondern inhaltliche Zusammenhänge der Artefakte ab. Abb. 4 stellt ein Beispiel der Zuordnung einzelner Aktefakte zu den Workflows sowie die Abhängigkeiten zwischen diesen dar. Aus der Abbildung kann erkannt werden, welche Artefakte zur Bearbeitung anderer Zwischenergebnisse notwendig sind und welche sich gegenseitig ergänzen

11 Input aus Briefing und Recherche Anforderungsmanagement Strategieentwicklung Szenario Funktionsspezifikation Definition der Funktionalitäten Zieldefinition Mission Statement Storyboard/Drehbuch Navigationskonzept Informationsarchitektur Technischer Überblick Technische Spezifikation Datenbank Architektur Technisches Konzept Benchmark Analyse Ideenfindung auf Metaebene Programmierspezifikation Prototyp Vision Designvorschlag Usibility Analyse Graphisches Konzept Kostenvorschlag Angebot Zeit- und Kostenmanagement Risikoanalyse Qualitätsmanagement Change Request Abb. 4: SMART Artefakte und ihre Abhängigkeiten Quelle: in Anlehnung an (Osswald 2003, 82-83) Jedem dieser Artefakte werden im SMART-Modell bestimmte Rollen zugeordnet. Diese Rollen beschreiben erforderliche Kompetenzen, die zur Erarbeitung des jeweiligen Zwischenergebnisses benötig werden. Die Rollebeschreibungen treffen eine Aussage darüber, welche Fähigkeiten zur Erarbeitung des jeweiligen Artefakts erforderlich sind, und bieten dadurch eine gute Arbeitsgrundlage für eine effektive Zusammenstellung des Projektteams. Zu Projektbeginn erfolgt zunächst eine Definition der benötigten Kompetenzen in Form von Rollen. Erst in einem zweiten Schritt werden diese Zuständigkeitsbereiche konkreten Personen zugeordnet. Eine Rolle muss nicht zwangsläufig durch genau ein Projektmitglied personifiziert werden. In der Praxis können mehrere Rollen funktional verschmelzen und von einem Projektmitarbeiter ausgeführt werden. So nimmt ein Mitarbeiter mitunter verschiedene Rollen in mehreren Projekten ein oder mehrere Mitarbeiter betreuen die Zuständigkeiten einer Rolle. Die Rollen ähnlich zu anderen Modellkomponenten können je nach Projektsituation erweitert oder angepasst werden. Das SMART-Modell definiert folgende Rollen: Anforderungsmanager Art Director Backend Programmierer Business Stratege Creative Director Daten- und Objektmodellierer Frontend Programmierer Informationsarchitekt Konzepter Marketing Stratege Markt Analytiker Projektkoordinator Projektleiter Redakteur Screendesigner Technischer Stratege Usability Analystiker

12 In Abb. 5 wird ein beispielhaftes SMART-Modell dargestellt, das einen Überblick über das gesamte Vorgehensmodell liefert. Die Projektphasen, Workflows sowie deren Position und Intensität sind ebenso beispielhaft zu verstehen. Workflows Anforderungsmanagement Strategieentwicklung Ideenfindung auf Metaebene Definition der Funktionalitäten Redaktion Informationsarchitektur Graphisches Konzept Technisches Konzept Zeit- und Kostenmanagement Qualitätsmanagement Programmierung Tests Hosting Phasen Strategie Kreation Konzeption und Umsetzung n n+1 Abb. 5: Beispielhaft gefüllte SMART Modellübersicht Quelle: (Osswald 2003, 65) 4 Vergleich der Vorgehensmodelle In diesem Kapitel sollen die vorgestellten Vorgehensmodelle anhand der nachfolgend ausgearbeiteten Eigenschaften miteinander verglichen werden. Die Zusammenstellung der Eigenschaften erfolgte auf Basis einer Literaturrecherche (Alpar et al. 2002; Balzert 1998; Krcmar 2005; Osswald 2003; Zuser/ Grechenig/Köhle 2004). Tab. 2 zeigt einen zusammenfassenden Überblick über die Vorgehensmodelle für das Umfeld digitaler Produktionen. Eigenschaften des Modells Wasserfall- Modell Prototypen- Modell RUP SMART- Modell Ablaufgestaltung sequenziell iterativ iterativ iterativ Grad des Formalismus hoch mittel hoch hoch Anpassbarkeit/ Erweiterbarkeit mittel mittel hoch hoch Komplexität des Modells gering gering hoch hoch Managementaufwand gering gering hoch hoch Eignung für Projekt- kleine kleine mittlere mittlere

13 größe mittlere mittlere große große Grad der Standardisierung hoch mittel hoch mittel Kontrollmöglichkeit (z.b. in Form von gering mittel hoch hoch Meilensteinen) Berücksichtigung von Risikofaktoren gering gering hoch hoch Rückkopplung zum Endbenutzer/ gering hoch hoch hoch Auftragsgeber Definition und Zuweisung von Rollen nein ja ja ja Definition von Aktivitäten/Workflows nein nein ja ja Grad der Integration in andere Modelle hoch hoch gering gering Grad der Toolunterstützung hoch mittel hoch gering Tab. 2: Vergleich der Vorgehensmodelle für das Umfeld digitaler Produktionen Quelle: eigene Darstellung Bei der Auswahl eines der oben beschriebenen Vorgehensmodelle für ein spezifisches Projekt aus dem Umfeld digitaler Produktionen spielen Modelleigenschaften wie Grad des Formalismus, Ablauf einzelner Projektphasen, Größe eines Projektes, Anpassung an das Anwendungsgebiet sowie Belange eines konkreten Projektes, Komplexität des Modells, Managementaufwand und Einsatz von unterstützenden Werkzeugen eine besondere Rolle (Krcmar 2005, 155). Das Wasserfall-Modell ist ein klassisches und verständliches Vorgehensmodell und trägt einem disziplinierten, sichtbaren und kontrollierbaren Prozessablauf bei. Die Verwendung des stark formalisierten Wasserfall-Modells mit der sequenziellen Ablaufstruktur erfordert im Vorfeld eine genaue Planung, da während der Entwicklung keine explizite Wiederholung einer Phase vorgesehen ist. Da das Modell einfach ist und nur wenig Managementaufwand erfordert, eignet es sich besonders gut für kleine und mittlere Projekte. Die einzelnen Phasen des Modells sowie deren Dauer können leicht an die Belange eines Projekts angepasst werden. Diese Anpassung berücksichtigt aber zu wenig Kontrollmöglichkeiten und Risiken. Da der Grad der Bekanntheit des Wasserfall-Modells besonders in der Software-Industrie sehr hoch ist, ist die Toolunterstützung in Form von CASE-Tools (Balzert 1993) reichlich vorhanden. Das Prototypen-Modell zeichnet sich durch ein iteratives und exploratives Vorgehen bei der Entwicklung digitaler Produktionen aus. Wegen einer geringeren Formalisierung wird Prototyping nicht als eigenständiger Prozess durchgeführt, sondern in ein klassisches Phasenmodell integriert (z.b. Wassefall-Modell). Das Prototypen-Modell eignet sich für kleine und mittlere Projekte insbesondere für die Anforderungs- und Konzeptionsphasen, da es unkompliziert und relativ wenig Managementaufwand erfordert. Dabei soll aber besondere Rücksicht auf die Change Requests seitens Auftraggebers genommen werden. Das Prototypen-Modell kann an die Anforderungen eines spezifischen Projekts angepasst werden

14 Der RUP als Vertreter der formalisierten und iterativen Modelle kann zur Unterstützung mittlerer und großer Projekte herangezogen werden. Das Modell kann flexibel an die Belange der Projekte aus dem Umfeld digitaler Produktionen angepasst werden. Es bietet Berücksichtigung von Kontrollmöglichkeiten (z.b. in Form von Meilensteinen zum Ende jeder Projektphase) und Risikofaktoren. Darüber hinaus ist eine Planung der zu erledigenden Aufgaben in Form von Workflows und Zuweisung von Rollen möglich. Der RUP wird als komplex eingestuft und ist für die pragmatischen Bedürfnisse eines Unternehmens durchschnittlicher Größe zu umfangreich und wird mit einem hohen Managementaufwand verbunden. Die Firma Rational bietet eine Reihe von den RUP unterstützenden Tools in Form von Software, Handbüchern und Vorlagen. Das SMART-Modell richtet sich an die Anforderungen der Unternehmen und Projekte aus dem Umfeld digitaler Produktionen. Es existiert seit 2002 und ist dementsprechend in der Branche noch nicht etabliert. Da das Modell sehr stark an den RUP anlehnt, erbt es damit seine sämtliche Eigenschaften. Zu den Vorteilen des SMART-Modells zählt auch die Verwendung der auf die Branche digitaler Produktionen abgestimmten Workflows, Rollen und Aktefakte. Dem SMART-Modell mangelt es momentan an Tool-Unterstützung, wobei die Verwendung und Anpassung von RUP-Tools nicht ausgeschlossen ist. 5 Zusammenfassung Diese Arbeit gibt einen Überblick über die Standardisierungsbestrebungen in Form von Vorgehensmodellen für die Entwicklungsprozesse digitaler Produktionen. Die etablierten und häufig verwendenden Vorgehensmodelle in diesem Umfeld wurden vorgestellt und anhand der ausgearbeiteten Kriterien miteinander verglichen. Dieser Vergleich kann als eine Empfehlung für die Auswahl eines Vorgehensmodells für ein konkretes Projekt herangezogen werden. Bei der Auswahl eines derartigen Vorgehensmodells spielen Modelleigenschaften wie Grad des Formalismus, Ablauf einzelner Projektphasen, Größe eines Projektes, Komplexität des Modells, Managementaufwand und Einsatz von unterstützenden Werkzeugen eine besondere Rolle. Unabhängig von der Wahl eines Vorgehensmodells muss berücksichtigt werden, dass dieses stets an die Belange eines konkreten Projektes angepasst werden muss

15 Literaturverzeichnis Alpar, P.; Grob, H.-L.; Weimann, P.; Winter, R. (2002): Anwendungsorientierte Wirtschaftsinformatik. Strategische Planung, Entwicklung und Nutzung von Informationsund Kommunikationssystemen. (3. Aufl.), Vieweg Verlag, Braunschweig Wiesbaden Balzert, H. (1993): CASE. Systeme und Werkzeuge. (5 Aufl.), BI-Wissenschaftsverlag, Mannheim et. al Balzert, H. (1998): Lehrbuch der Software-Technik. Software-Management, Software- Qualitätssicherung, Unternehmensmodelierung, Spektrum, Heidelberg Berlin Boehm, B.W. (1981): Software Engineering Economics, Prentice Hall, Englewood Cliffs Boles, D.; Wütherich, G. (1997): Transformationelle Multimedia-Softwareentwicklung. Paper presented at the HIM'97, Dortmund. Budde, R.; Kantz, K.; Kuhlenkamp, K.; Züllighofen, H. (1992): Approaches to Prototyping, Springer-Verlag, Berlin Chroust, G. (1992): Modelle der Software-Entwicklung, R. Oldenburg, München et. al Gornik, D. (2001): IBM Rational Unified Process: Best Practices for Software Development Teams. IBM Corporation, Hitzges, A.; Laich, U. (1995): Projektmanagement bei der Entwicklung multimedialer Anwendungen. Frauenhofer-Institut für Arbeitswirtschaft und Organisation IAO, Jacobson, I.; Booch, G.; Rumbaugh, J. (1999): The Unified Software Development Process, Addison-Wesley, Reading, MA et al Krcmar, H. (2005): Informationsmanagement. (4 Aufl.), Springer, Berlin et al Kruchten, P. (1999): Der Rational Unified Process - Eine Einführung, Addison Wesley, München Mertens, P.; Bodendorf, F.; König, W.; Picot, A.; Schumann, M. (2001): Grundzüge der Wirtschaftsinformatik. (7., neu überarbeitete Aufl.), Springer, Berlin et al o.v. (1998): Prototyping - Theorie und Praxis. Ergonomie und Informatik. Osswald, K. (2003): Konzeptmanagement. Interaktive Medien - Interdisziplinäre Projekte, Springer-Verlag, Berlin Heidelberg Pomberger, G.; Pree, W.; Stritzinger, A. (1992): Methoden und Werkzeuge für das Prototyping und Ihre Integration. In: Informatik Forschung und Entwicklung, Vol. 7 (1992), S Rudolph, S.; Krcmar, H. (2004): Stand digitaler Produktionen (Arbeitspapier Nr. 3). Lehrstuhl für Wirtschaftsinformatik, TU München, Rudolph, S.; Pracht, B.; Taranovych, Y.; Walter, S.; Krcmar, H. (2004a): Erfolgskriterien in Projekten: eine empirische Studie zur Situation des Projektmanagements in digitalen Produktionen. Paper presented at the Konferenz zur Zukunft im Projektmanagement - InterPM 2004, Glashütten, S Rudolph, S.; Taranovych, Y.; Pracht, B.; Förster, C.; Walter, S.; Krcmar, H. (2004b): Erfolgskriterien im Projektmanagement digitaler Produktionen (Projektveröffentlichung Nr. 7). Lehrstuhl für Wirtschaftsinformatik, TU München, 2004b. Sawhney, M. (1995): Entwicklung eines Vorgehensmodells für die Multimedia- Anwendungsentwicklung am Beispiel eines Informations- und Orientierungssystems für eine Universität, Universität Osnabrück Straus, R. (1997): Managing Multimedia Projekts, Focal Press, Burlington Zuser, W.; Grechenig, T.; Köhle, M. (2004): Software Enginiering mit UML und dem Unified Process. (2., überarb. Auflage Aufl.), Pearson Studium, München III

16 Bisher erschienene Arbeitspapiere und Studien des Lehrstuhls für Wirtschaftsinformatik der Technische Universität München Stand: August 2006 Arbeitspapiernr Böhmann, T.; Schermann; M.; Krmcar, H. (2006): Reference Model Evaluation: Towards an Application-Oriented Approach. Arbeitspapier Nr. 21, Garching Walter, S.; Leimeister, J.M.; Krcmar, H. (2006): Chancen und Herausforderungen digitaler Wertschöpfungsnetze im After-Sales-Service- Bereich der deutschen Automobilbranche. Arbeitspapier Nr. 20, Garching Hauke, R.; Baume, M.; Krcmar, H. (2005): Kategorisierung von Planspielen Entwicklung eines übergreifenden Strukturschemas zur Einordnung und Abgrenzung von Planspielen, Arbeitspapier Nr. 19, Garching Taranovych, Y.; Rudolph, S.; Förster, C. (2005): Standards für die Entwicklungsprozesse digitaler Produktionen. Arbeitspapier Nr. 18, Garching Voelkel, D; Taranovych, Y; Rudolph, S; Krcmar H. (2005): Coach- Bewertung zur Unterstützung der Coach-Suche im webbasierten Coaching digitaler Produktionen. Arbeitspapier Nr. 17, Garching Mohr, M.; Krcmar, H. (2005): Bildungscontrolling: State of the Art und Bedeutung für die IT-Qualifizierung, Arbeitspapier Nr. 16, Garching Jehle, H.; Krcmar, H. (2005): Handbuch: Installation von SAP R/3 Enterprise, ECC 5.0 und BW 3.5 IDES auf SunFire v40z. Arbeitspapier Nr. 15, Garching Kutschke, C; Taranovych, Y; Rudolph, S; Krcmar H. (2005): Web Conferencing als Erfolgsfaktor für webbasiertes Projekt-Coaching. Arbeitspapier Nr. 14, Garching Baume, M.; Hummel, S.; Krcmar, H. (2004): Abschlussbericht der Evaluation im Projekt Webtrain. Arbeitspapier Nr. 13, Garching Baume, M.; Krcmar, H. (2004): Beurteilung des Online-Moduls Informationsmanagement aus kognitionswissenschaftlicher, lerntheoretischer und mediengestalterischer Sicht. Arbeitspapier Nr. 12, Garching Leimeister, J.M. (2005): Mobile Sportlerakte. Arbeitspapier Nr. 11, Garching Mohr, M.; Wittges, H.; Krcmar, H. (2005): Bildungsbedarf in der SAP-Lehre: Ergebnisse einer Dozentenbefragung. Arbeitspapier Nr. 10, Garching 2005.

17 Hummel, S.; Baume, M.; Krcmar, H. (2004): Nutzung von Teamspace im Projekt WebTrain. Arbeitspapier Nr. 9, Garching Hummel, S.; Luick, S.; Baume, M.; Krcmar, H. (2004): Didaktisches Konzept für das Projekt WebTrain. Arbeitspapier Nr. 8, Garching Wolf, P.; Krcmar, H. (2003): Wirtschaftlichkeit von elektronischen Bürgerservices Eine Bestandsaufnahme Arbeitspapier Nr. 7, Garching Esch, S.; Mauro, C.; Weyde, F.; Leimeister, J.M.; Krcmar, H.; Sedlak, R.; Stockklausner, C.; Kulozik, A. (2005): Design und Test eines mobilen Assistenzsystems für krebskranke Jugendliche.Arbeitspapier Nr. 6 Garching Schweizer, K.; Leimeister, J.M.; Krcmar, H. (2004): Eine Exploration virtueller sozialer Beziehungen von Krebspatienten. Arbeitspapier Nr. 5, Garching Knebel, U.; Leimeister, J.M.; Krcmar, H. (2004): Empirische Ergebnisse eines Feldversuchs: Mobile Endgeräte für krebskranke Jugendliche. Arbeitspapier Nr. 4, Garching Rudolph, S.; Krcmar, H. (2004): Zum Stand digitaler Produktionen. Arbeitspapier Nr. 3, Garching Mohr, M.; Hoffmann, A.; Krcmar, H. (2003): Umfrage zum Einsatz des SAP Business Information Warehouse in der Lehre. Arbeitspapier Nr. 2, Garching Daum, M.; Krcmar, H. (2003): Webbasierte Informations- und Interaktionsangebote für Krebspatienten 2002 Ein Überblick. Arbeitspapier Nr. 1, Garching Studiennr. 7 6 Mohr, M.; Krcmar, H.; Hoffmann, A. (2006): Studentenorientiertes Anwender-Einführungstraining für integrierte Unternehmenssoftware: Konzeption und Kursdesign am Beispiel mysap ERP. Studie Nr. 7, Garching Böhmann, T.; Taurel, W.; Dany, F.; Krcmar, H. (2006): Paketierung von IT- Dienstleistungen: Chancen, Erfolgsfaktoren, Umsetzungsformen: Zusammenfassung einer Expertenbefragung. Studie Nr. 6, Garching Hauke, R.; Baume, M.; Krcmar H. (2006): Computerunterstützte Management-Planspiele: Ergebnisse einer Untersuchung des Planspieleinsatzes in Unternehmen und Bildungseinrichtungen. Studie Nr. 5, Garching 2006.

18 Rudolph, S.; Taranovych, Y.; Pracht, B.; Förster, C.; Walter, S.; Krcmar, H. (2004): Erfolgskriterien im Projektmanagement digitaler Produktionen. Studie Nr. 4, Garching Wittges, H.; Mohr, M.; Krcmar, H.; Klosterberg, M. (2005): SAP-Strategie Die Sicht der IT-Entscheider. Studie Nr. 3, Garching Hummel, S.; Baume, M.; Krcmar, H. (2004): Abschlussbericht des Projekts WebTrain - Teilprojekt der TUM. Studie Nr. 2, Garching Junginger, M.; Krcmar, H. (2004): Wahrnehmung und Steuerung von Risiken im Informationsmanagement - Eine Befragung deutscher IT-Führungskräfte. Studie Nr. 1, Garching 2004