Vorgehensmodelle für IT-Projekte

Vorgehensmodelle Ein Vorgehensmodell stellt Methoden und Elemente des Projektmanagements zu Prozessen und Phasen eines standardisierten Projektablaufes zusammen. In diesem Sinne ist ein Vorgehensmodell als Projektmanagementsystem nach DIN 69904 und 69905 anzusehen. Voraussetzung für ein sinnvolles Vorgehensmodell ist die Einengung auf eine Projektart, da ansonsten doch wieder das gesamte Fachwissen des Projektmanagements integriert werden müsste.

Merkmale eines Vorgehensmodells Ein Vorgehensmodell ist ein generischer Leitfaden. Projekte benutzen es als Schablone oder als Baukasten zur Generierung eines eigenen, für den jeweiligen Projekttyp angepassten Planungsleitfadens ( „Projekt-Vorgehensmodell“ !! ) Ein Vorgehensmodell ist ( aufgrund der langjährigen praktischen Erfahrungen ) eine sehr fundierte, vorgedachte Abbildung eines IT-Projektes: es beinhaltet alle wesentlichen Aktivitäten und Ergebnisse eines IT-Projektes die Reihenfolge der Aktivitäten praktische erprobte Methoden Es ist eine Art Checkliste, die eine professionelle Planungsbasis für jedes konkrete Projekt darstellt.

Vorgehensmodell: Zusammenhang der Aktivitäten SWE KM ÄW QM PM PC = Softwareentwicklung Konfigurationsmanagement Änderungswesen Qualitätsmanagement Projektmanagement Projektcontrolling Anmerkung: In der Literatur beschriebene Vorgehensmodelle umfassen nicht immer alle Aktivitäten

Allgemeines Phasenschema Missstand, Initialzündung, Projektidee Phasenmodelle kamen zuerst bei der Realisierung Von Raumfahrt- oder Militärprojekten in den USA Zur Anwendung (z. B. 1964 bei der US Air Force und 1968 bei der NASA. Sie gingen auf ebenfalls von amerikanischen Unternehmen entwickelte Grundlagen des Systems Engineering zurück. In Europa wurde dieses Planungsinstrument beim Bau von Trägerraketen für die Weltraumfahrt verwendet. Projektspezifische Phasenabläufe im deutsch- sprachigen Raum fanden sich in Projekten des Bundesverteidigungsministeriums zur Entwicklung der Wehrtechnik (1971). Auch bei der Entwicklung von Elektronik-Komponen- ten setzte der Philips Konzern dieses Instrument ein (1973). : Meilenstein = Entscheidung über Abbruch oder Fortsetzung

Phasenmodell der HOAI (Stand 1.1.96) Ein Beispiel für ein sehr bekanntes Phasenmodell, das in der Wirtschaft außerhalb der Informatik angewandt wird, ist das Phasenmodell der HOAI (Honorarordnung für Architekten und Ingenieure, das schon aus der Mitte der 70iger Jahre stammt. Auch hier ist die Grundlage, dass z. B. der Bau eines Hauses in einer bestimmten Reihenfolge abläuft. Da der Architekt als Freiberufler meist nicht solange warten kann, bis der Bau steht, dient das Phasenmodell als Basis für die Abrechnung von Teilleistungen. .

Wasserfallmodell Das Wasserfall-Modell ist eine Weiterentwicklung des „stagewise model“ (Bennington 1956). Das Modell legt fest, dass Software in sukzes- Siven Stufen entwickelt wird. Das von Royce 1970 vorgeschlagene Wasserfall-Modell erweitert das „stagewise model“ um Rückkopplungs- Schleifen zwischen den Stufen. Die Rückkopplungen werden jedoch auf angrenzende Stufen beschränkt, um teure Überarbeitungen über Mehrere Stufen hinweg zu vermeiden. Dieses Modell wurde von Boehm 1981 Wasserfallmodell genannt.

Vorgehensmodelle: V-Modell Das V-Modell ist eine Erweiterung des Wasserfallmodells. Es integriert die Qualitätssicherung. Organisatorisches Umfeld Technisches Umfeld SE 1: System-Anforderungsanalyse IT-System SE 2 : Systementwurf SW-/HW- Einheit SE 3 : SW-/HW-Anforderungsanalyse V-Modell Software Hardware SE 4-SW: SW-Grobentwurf SE-4-HW: HW-Grobentwurf SE 5-SW: SW-Feinentwurf SE-5-HW: HW-Feinentwurf SE 6-SW: SW-Implementierung SE-6-HW: HW-Implementierung SE 7-SW: SW-Integration SE-7-HW: HW-Integration SE 8 : System-Integration SE 9 : Überleitung in die Nutzung

Erweitertes V-Modell Die Abbildung zeigt die erweiterte Fassung von Daich. Ausgehend vom allgemeinen V-Modell wurde ein Vorgehensmodell zunächst für die Bundeswehr und anschließend die Behörden entwickelt (1992/93). Es dient der Standardisierung der Softwareentwicklung im Bereich der Bundesverwaltung. 1997 wurde das V-Modell wesentlich überarbeitet, da es sich als sehr schwerfällig und Dokumentationslastig erwiesen hatte.

Prototyping-Modell Erfahrungsgemäß treten bei der Softwareentwicklung eine Reihe von Problemen auf, die mit traditionellen Prozessmodellen – wie dem Was- serfallmodell und dem V-Modell – nur unvollkommen gelöst werden können (z. B. Unfähigkeit des Anwenders, seine Anforderungen vollständig zu spezifizieren, experimentelle Erprobung verschiedener Lösungsmöglichkeiten, ausprobieren der Anforderungen an z. B. Echtzeitbetrieb). Diese Probleme können – zumindest teilweise – durch das Prototypingmodell gelöst werden.

Arbeit in Gruppen (3-5), Zeit 20 Minuten Übung Welche Vor- und Nachteile hat Ihrer Meinung nach das Prototyping im Gegensatz zu einer sequentiellen Entwicklung? Welche Voraussetzungen beim Anwender und bei den Entwicklern müssen gegeben sein, damit Prototyping erfolgreich eingesetzt werden kann? Arbeit in Gruppen (3-5), Zeit 20 Minuten

Lösung – Vorteile (vgl. Balzert) Das Prototypingmodell besitzt folgende Vorteile: Reduzierung des Entwicklungsrisikos durch frühzeitigen Einsatz von Prototypen Prototypen können sinnvoll in andere Prozessmodelle integriert werden Prototypen können durch geeignete Werkzeuge schnell erstellt werden Prototyping verbessert die Planung der Softwareentwicklung Labormuster fördern die Kreativität für Lösungsalternativen Starke Rückkopplung mit dem Endbenutzer und dem Auftraggeber Auch für die Entwicklung von Expertensystemen und Management-Informationssystemen geeignet

Lösung – Nachteile (vgl. Balzert) Das Prototypingmodell besitzt folgende Nachteile: Höherer Entwicklungsaufwand, da Prototypen meist zusätzlich erstellt werden Gefahr, dass ein „Wegwerf“-Prototyp aus Termingründen doch Teil des Endprodukts wird Standardverträge für die Softwareerstellung berücksichtigen Prototyping oft nicht Prototypen werden oft als Ersatz für die fehlende Dokumentation angesehen Die Beschränkungen und Grenzen von Prototypen sind oft nicht bekannt

Lösung - Voraussetzungen (vgl. Balzert) Erfolgreiches Prototyping setzt folgendes voraus Es muss ausreichend Wissen über das Anwendungsgebiet vorhanden sein Allein auf der Basis vorgegebener schriftlicher Dokumente kann kein Prototyp erstellt werden. Die Entwickler müssen deshalb Zugang zu den Benutzern haben Der Endbenutzer muss am Prototyping beteiligt werden, die Benutzerbeteiligung ersetzt jedoch nicht die kreativen Ideen und Lösungsvorstellungen der Entwickler Alle an der Entwicklung beteiligten Personengruppen müssen in direktem Kontakt stehen Prototypen müssen im richtigen Umfang dokumentiert werden Die Vorgehensweise hängt von der zu untersuchenden Fragestellung ab (also nicht Standard!) Geeignete Werkzeuge müssen verfügbar sein

Spiralmodell Bei dem von Boehm 1988 entwickelten Modell handelt es sich um ein Meta-Modell. Für jedes Teilprodukt und jede Verfeinerungsebene sind vier zyklische Schritte zu durchlaufen. Die Vorgehensweise erfordert einen hohen Managementaufwand, minimiert aber die Risiken der Ent- wicklung. Sie ist deshalb besonders für große (und teure) Projekte geeignet, bei denen das Endergebnis noch nicht ganz feststeht.

SAP-Einführung

Der Rational Unified Process (RUP) Der RUP ist eine konkretisierte, jedoch umfangreichere Variante des sog. Unified Software Development Process (aus Verschmelzung der Methoden Objectory, Booch Method, Object Modeling Technique entstanden). Die Schlüsselkonzepte und Ansätze sind vollständig aus dem USDP übernommen. Er werden jedoch zahlreiche Unterstützungsprozesse (z. B. Projektmanagement, Configuration Management) und neue Aspekte (z. B. Prototyping) beschrieben, die im abstrakteren USDP nicht vorhanden sind. Der RUP stellt ein mächtiges Prozessrahmenwerk dar, das auf verschiedene Entwicklungssituationen zurecht geschnitten werden kann.

JEF Engineering Process (Lufthansa Systems) Der JEF (Java Enterprise Framework) Engineering Process ist ein von der LH Systems aus dem RUP Process entwickeltes Vorgehensmodell für die Entwicklung von Java-Anwendungen (Möller, 2003).

IS Generic Lifecycle (Airbus 2002) Entry into Service (Release N ) Decision for Project scoping IS Project Launching Commitment Development Launching Go ahead for Deployment M1 M3 M5 M7 M11 M13 Service Delivery Global IS Functional & Technical Design Business objectives Business Preliminary needs Business case Requirement Definition Requirement Analysis & Solution Preliminary Design Coding & Customizing Detailed Design WP 1 Test Technical & Functional Acceptance WP 2 Test Implemen- tation & Final Test Training Problem Management & Escalation WP n Test Change Process M0 M10 M12 M14 Business Changes Ideas Final Acceptance Begin Acceptance Test End Project Review after 1st period of use Opportunity Study Concept Phase Solution Definition Solution Development Acceptance Testing Deploy- ment Operational Use Release N+1 ( phase depending on context) Legend : Red milestones (M3, M5, M11 and M12) are GO / NO GO milestones

PRO-IV: Phase I PRO-IV ist ein von der Airbus 1997 entwickeltes Vorgehensmodell, das hier beispielhaft für detaillierte Ausarbeitungen des allgemeinen Wasserfall- Modells durch Firmen steht

PRO-IV: Phase II .

PRO-IV: Phase III

PRO-IV: Phase IV

Nutzen in der praktischen Arbeit Der gesamte Entwicklungsprozess muss nicht in jedem Projekt neu überlegt werden. Nutzung als „Checkliste“ oder „to do-Liste“ um nichts zu vergessen ( gibt Sicherheit ) um zu entscheiden, ob im konkreten Projekt eine Aktivität durchgeführt und ein bestimmtes Ergebnis erzeugt werden muss. Ein erster Plan liegt ( fast ) auf Knopfdruck vor. Erleichterung der Kommunikation im Team und mit dem Management ( z.B. Begriffsklarheit Aktivitäten und Ergebnisse ) Muster-Ergebnisse sind vorhanden und können verwendet werden Erfahrungswerte bezogen auf den Aufwand und die benötigten Rollen liegen für jede Aktivität vor. Der Einsatz eines Mitarbeiters in einem anderen Projekt oder Bereich wird durch eine einheitliche Terminologie erleichtert.

Einfacher Ansatz zur Projektplanung Eine einfache standardisierte Vorgehensweise: Auswahl eines Prozessmodells (Vorgehensmodells = Modell des Entwicklungsprozesses, z. B. das bekannte V-Modell oder das Modell PRO-IV) Zuschneiden des Prozessmodells auf die Projektbelange (Tailoring) Zerlegung der Aufgaben des Prozessmodells in Vorgänge bzw. Teilaufgaben Gruppieren der Teilaufgaben in Arbeitspakete Festlegen der Meilensteine

Übung: Projektaufgaben festlegen Beschäftigen Sie sich mit dem Vorgehensmodell und fragen sich: Welche Tätigkeiten müssen für dieses Projekt durchgeführt werden? Kann man Tätigkeiten eventuell weglassen, da sie für die IAA Entwicklung nicht relevant sind? Gibt es zusätzliche Tätigkeiten? Wenn Sie Fragen zu einzelnen Tätigkeiten des Vorgehensmodells haben, stellen Sie diese bitte. Zeit: 45 Minuten Präsentieren (und begründen!) Sie anschließend Ihr Ergebnis.