Leseprobe
Inhaltsverzeichnis
A Planung von Softwareprojekten
1 Einleitung
1.1 Motivation
1.2 Rahmenbedingungen
1.3 Die Projektphasen im Überblick
1.3.1 Projektstart
1.3.2 Projektplanung
1.3.3 Projektrealisierung
1.3.4 Projektabschluss
2 Fokus Projektplanung
2.1 Festlegung der Projektmethodik
2.1.1 Wasserfall-Modell
2.1.2 Agile Methodik
2.1.3 Entscheidung
2.2 Projektorganisation
2.3 Projektstrukturplan (PSP)
2.4 Projektablaufplan (PrAP)
3 Zusammenfassung
B Verzeichnisse
1 Literaturverzeichnis
2 Abbildungsverzeichnis
3 Abkürzungsverzeichnis
A Planung von Softwareprojekten
1 Einleitung
1.1 Motivation
Die Informations- und Kommunikationstechnik (ITK) hat in der Wirtschaft mittlerweile einen essentiellen Stellenwert erlangt. Die Unterstützung der Prozesse mittels ITK liefert in nahezu jeder Branche und jedem Unternehmen einen nicht mehr wegzudenken Beitrag zur Sicherstellung von Effektivität und Effizienz. Gleichwohl hat eine einmal getätigte Investition in eine beliebige IT-Lösung in den seltensten Fällen langen Bestand. So müssen Updates der Software eingespielt werden, oder Anpassungen (Customizing, Entwicklung) vorgenommen werden, um Anforderungen des Marktes, der Kunden oder der eigenen Aufbau-/Ablauforganisation gerecht zu werden. Im geringen Umfang können diese Updates und Anpassungen im Tagesgeschäft einer IT-Abteilung vorgenommen werden.
Bei größeren Anpassungen, wie Rollouts von Lösungen von einem Land in ein anderes, Ersteinführungen von komplexer Software, wie ERP, oder dem hier unterliegenden Beispiel der Einführung eines Webshops, ist das Aufsetzen eines eigens dafür vorgesehenen Projektes unerlässlich [1] .
Ein Projekt ist gem. DIN 69901 ein Einzelvorhaben mit folgenden Eigenschaften [2] :
1) Es verfolgt ein konkretes Ziel,
2) in einem definierten Zeitraum,
3) mit begrenztem Budget,
4) mit einer eigenen Organisationform und
5) ist klar abgegrenzt von anderen Vorhaben;
6) zudem ist es einmalig
Kritische Erfolgsfaktoren für ein Projekt sind nicht nur die Hauptaktivitäten, die zur hochwertigen Software an sich führen; hierzu zählen Analyse, Konzeption, Implementierung und Test. In Anbetracht der mit ca. 70-80% sehr hohen Quote an gescheiterten Projekten[3], kommt v.a. der Planung [4] ein zentraler Stellenwert zu, ein Projekt hinsichtlich Funktion, Zeit, Budget und Qualität erfolgreich[5] abzuschließen. Da größere Software-Projekte i.d.R. immer auch eine Auswirkung auf die Aufbau- und/oder Ablauforganisation haben, oder sogar die Ursache hiervon sind, ist das Change-Management (CM) ein weiterer kritischer Erfolgsfaktor, um mit Widerständen oder Akzeptanzproblemen von Mitarbeitern angemessen umzugehen, diese zu managen und weitestgehend zu vermindern[6]. Welchen Einfluss diese beiden Erfolgs-Faktoren haben, wird anhand der größten Problempunkte von Projekten [7] ersichtlich, diese liegen in/bei (der):
1. Zieldefinition (Planung)
2. Personalproblemen (Change-Management)
3. Planungsproblemen (Planung)
4. Problemen hinsichtlich der Benutzerakzeptanz (Change-Management)
Dieses Buch setzt den Fokus auf den ersten Erfolgsfaktor, der Planung eines Softwareprojektes. Neben der allgemeinen Beschreibung dieser Phase wird auf die Vorgehensmodelle im Besonderen eingegangen und eine Auswahl für das hier unterlegte Fallbeispiel der W-AG eingegangen. Zudem wird als weitere Planungselemente eine Projektstruktur- und Projektablaufplanung für das Fallbeispiel ausgeführt.
1.2 Rahmenbedingungen
Für das fiktive Fallbeispiel, anhand dessen die exemplarische Planung eines Softwareprojektes verdeutlicht werden soll, gelten nachfolgende Annahmen bzw. Rahmenbedingungen.
Ein mittelständischer Werkzeughersteller, kurz die W-AG, beauftragt ein Beratungshaus, im Folgenden die Con-GmbH, mit der Projektierung eines Webshops. Die W-AG ist der Spin-Off eines alteingesessenen deutschen Maschinenbau-Unternehmens (hier A-AG); die Leitung ist konservativ und wenig interessiert an modernen Ansätzen, was bei der späteren Auswahl des Vorgehensmodells aufgegriffen wird. Kernkompetenz der W-AG ist die Herstellung und Veredlung von Feinmechanik-Werkzeug. Neben der Herstellung von eigenen Werkzeugen, werden auch Handelswaren vertrieben. Vor dem Spin-Off zur W-AG war es ein eigener Bereich in der A-AG. Durch den Spin-Off soll nicht nur nach wie vor das Altunternehmen mit Werkzeugen versorgt werden, sondern auch der sonstige Bedarf anderer Unternehmen gedeckt werden. Um den Vertriebsweg unabhängig von teurem Vertriebspersonal zu halten, soll der Webshop als Zugang zu den Kunden dienen.
Das ausgewählte Beratungshaus, die Con-GmbH, stellt ein Team von 4 IT-Beratern
- 1 Projektmanager / Coach
- 2 Analysts / Entwickler
- 1 Tester
Die W-AG stellt 4 Fachbereichsvertreter aus
- Vertrieb
- Einkauf
- Produktion sowie
- IT / Organisation
Der IT-Mitarbeiter soll dem Projekt vollständig zur Verfügung stehen.
1.3 Die Projektphasen im Überblick
Im Allgemeinen unterteilt sich ein Software-Projekt[8] (bspw. bei Anwendung der Wasserfallmethode) in folgende Phasen:
- Projektstart
- Projektplanung
- Projektrealisierung
- Projektabschluss
Diesen Phasen übergreifend laufen die Projektsteuerung-/Projektcontrolling sowie die Projektdokumentation.
1.3.1 Projektstart
In der Phase 1. dem Projektstart erfolgen alle notwendigen Maßnahmen, die für die Projektplanung erforderlich sind, hierein fällt insbesondere das formelle Mandat des Projektes, der Projektauftrag. Dieser enthält alle grundsätzlichen Rahmendaten zum Projekt, wie das zentrale Projekt-Ziel; umzusetzende Anforderungen sowie formale Projekt-Eckdaten zu Zeiten, Kosten, Ressourcen und Risiken. Je nach Umfang des Projektes kann dieser grob umschrieben sein, da die Detailarbeit in der Projektrealisierungsphase erfolgt. Bei komplexen Projekten reichern umfassende Dokumente (wie ein Lastenheft) den Projektauftrag an.
Da die Angaben des Projektauftrages hins. Kosten, Nutzen, Terminen und Ressourcen ggf. nur auf Schätzangaben basiert, werden diese Angaben häufig mittels Vorstudien verifiziert und validiert. Bei komplexen Projekten erfolgt die Vorstudie wiederum als Vorprojekt ab. Innerhalb dieser Kosten-/Nutzen-Betrachtung werden auch Abwägungen zum „make or buy“ der Projektleistung getroffen und festgelegt, in welchem Umfang das Projekt durch Externe unterstützt wird.
Um das Projekt offiziell zu beginnen, wird das Kick-Off durchgeführt. Innerhalb dessen werden die (zukünftigen) Projektteilnehmer sowie wichtige Stakeholder über wesentliche Angaben des Projektes, wie verfolgte Ziele, zentrale Anforderungen, Projektorganisation sowie Angaben zur Termin- und ggf. Kostensituation und Team- und Aufgabenschnitt informiert. Innerhalb des Kick-Off werden häufig auch Regelmeetings, Kommunikationswege und obligatorische Dokumentenvorlagen erläutert. Bei komplexen Projekten erfolgt das Kick-Off bei einer hohen Anzahl von Projektteilnehmern erst in der Projektplanungsphase, da im Kick-Off detailliertere Angaben zum Team- und Arbeitspaketschnitt bekannt gegeben werden müssen, die in der Phase des Projektstarts ggf. noch nicht vorliegen.
1.3.2 Projektplanung
Die Phase der Projektplanung dient zur allgemeinen Strukturierung des Projektes und zur gedanklichen Antizipation von Inhalten und Aktivitäten sowie sich der daraus ergebenden Kosten, Aufwände, Ressourcenbelastung.
Eines der ersten Schritte in der Projektplanungsphase ist die Festlegung des dem Projekt zugrunde liegenden Vorgehensmodelles. Dies ist erforderlich, da sich die Art der Planung teilweise sehr unterschiedlich sein kann. So unterscheiden sich die Vorgehensmodelle u.a. vollständig hinsichtlich Umfang und Vollständigkeitsgrad von Analysen und Konzepten, Flexibilität im Scope/Zielsetzung und Dezentralisierungsgrad.
Bei den klassischen Methodiken ̶ Wasserfall (WFM) und V-Modell (WM), ggf. ergänzt um Prototyping-Ansätze ̶ erfolgt eine Gesamtbetrachtung der zu analysierenden und zu konzipierenden Inhalte. Es werden voll umfängliche Analysen und Designs erstellt, die ggf. angereichert um Prototyping-Ansätze in Teilstadien den Fachbereichen vorgestellt werden. Entsprechend umfassend erfolgt auch die Planung und Steuerung des Projektes. Bei reiner Anwendung des WFM oder VM erhält der Fachbereich vollständige Analysen und abgeschlossene Konzepte, die mittels nachstehendem Review zu korrigieren und am Ende abzunehmen hat. Ist ein Konzept erst einmal final, wird auf Basis dieses Standes die vollständige Implementierung in der Folgephase vorgenommen. Eine spätere Erweiterung dieser einmal abgenommenen Konzepte bedeutet einen Change und wird entsprechend bewertet, genehmigt/abglehnt und i.d.R. erst zeitlich versetzt implementiert. Im Extremfall kann das durch die Fachbereiche aus dem SOLL-Konzept interpretierte Ergebnis stark von dem implementierten abweichen. Im schlimmsten Falle fällt dies erst zum GoLive auf, wenn das Software-Produkt zum ersten Mal im Arbeitsalltag verwendet wird.
Das Prototyping mildert diese Form ein wenig ab, da wesentliche Arbeitsstände oder Bestandteile des SOLL-Konzeptes als Teilrealisierung dem Fachbereich gezeigt werden und dieser hieran eine gewisse Arbeitstauglichkeit ableiten kann.
[...]
[1] vgl. hierzu die Projektarten und deren Projekt-spezifische Besonderheiten: FRÖHLICH/HEIDEN/HEYDEMANN (2002), S. 77ff.
[2] vgl. FRÖHLICH/HEIDEN/HEYDEMANN (2002), S. 11
[3] Vgl. PATZAK/RATTAY (2009), S. 21 ff.
[4] vgl. FRIEDRICH/KUPTZ (2011), S. 7
[5] vgl. FRIEDRICH/KUPTZ (2011), S. 5
[6] vgl. WOLFF/BERNING (k.A.), S. 48 und 57ff. sowie MEIER (2007), S. 172ff. und KEITSCH (2007), S. 148ff. sowie DOPPLER/LAUTERBURG (2014), S. 338ff. und 354ff.
[7] vgl. FRIEDRICH/KUPTZ (2011), S. 6ff.
[8] vgl. FRIEDRICH/KUPTZ (2011), S. 7