Lektion: Projekte und Vorgehensmodelle

[Audio] In dieser Einheit der Lektion lernen Sie, etablierte Vorgehensmodelle zu unterscheiden und Stärken und Schwächen zu benennen, um für ein Vorhaben das geeignete Vorgehensmodell auswählen zu können..

[Audio] Es gibt viele verschiedene Empfehlungen, wie ein Softwareprojekt durchgeführt und organisiert werden soll. Große Unternehmen haben oft ein eigenes Vorgehensmodell dafür entwickelt. Ein Prozess- bzw. Vorgehensmodell bietet eine Orientierung für die Projektmitarbeiter*innen.​ Der Auswahl-, Einführungs- oder Entwicklungsprozess wird dadurch plan- und kontrollierbar. Vorgehensmodelle enthalten Methoden, Werkzeuge und Vorlagen beispielsweise für die Projektplanung, die Ziel- oder Anforderungsdokumentation, Kosten- und Qualitätskontrolle, Risikobetrachtung, Tests oder Abnahmeprotokolle. Gleichzeitig zerlegt der Ablaufplan das Vorhaben in überschaubare, zeitlich und inhaltlich begrenzte Einheiten, die leichter auszuführen und zu koordinieren sind. Der Ablaufplan fördert damit eine Umsetzung Schritt für Schritt. Außerdem entstehen bei konsequentem Einsatz eines Vorgehensmodells Standardisierungseffekte, die es zum Beispiel erleichtern neue Mitarbeiter*innen in ein Projekt einzuarbeiten oder Projekte miteinander zu vergleichen. In Unternehmen werden Vorgehensmodelle mit unterschiedlichem Detaillierungsgrad eingesetzt und oft bringen auch Beratungshäuser oder Softwareanbieter definierte Vorgehensweisen mit, die dann in einem Projektvorgehen miteinander kombiniert werden. Dabei gibt es bestimmte Muster, die Ihnen vertraut sein sollten..

[Audio] Das erste Muster, welches wir uns ansehen, ist das sogenannte Wasserfallmodell. Das Wasserfallmodell ist eines der ältesten und bekanntesten Vorgehensmodelle für IT-Projekte. Es basiert auf einer Zerlegung des Projekts in sequentiell hintereinander ablaufende Phasen, die jeweils eigene Methoden und Ergebnisse haben. In seiner Reinform schreibt das Wasserfallmodell vor, dass mit der Bearbeitung der nächsten Phase erst begonnen werden kann, wenn die vorangehende abgeschlossen wurde und alle Ergebnisse bzw. Meilensteine erreicht sind. Rückkopplungen waren in frühen Versionen des Wasserfallmodells nicht vorgesehen, was sich aber als nicht praktikabel erwies. Daher wird heute in der Regel ein einstufiger Rückschritt erlaubt, wenn die Zwischenergebnisse nicht zufriedenstellend sind..

[Audio] Zum Wasserfallmodell sollten Sie sich merken, dass jedes Unternehmen, jede Projektorganisation ihre eigenen Phasen definiert, die meisten Wasserfälle aber über fünf bis sieben Stufen fließen. Es gibt keine festen Vorgaben. Eines aber haben Wasserfallmodelle gemeinsam, und zwar, dass alle stark am Fortschritt orientiert sind, was auch einen Vorteil darstellt, weil man sich stetig vorwärts zum Ziel bewegt. Das ist in zyklischen Modellen manchmal nicht der Fall, hier kann man das Gefühl bekommen, dass man sich ständig im Kreis dreht und nicht vorankommt. Neben den inhaltlich unterschiedlich fokussierten Projektphasen gibt es Aufgaben, die kontinuierlich geplant und ausgeführt werden, zum Beispiel Dokumentation und Qualitätssicherung..

[Audio] Das sogenannte V-Modell ist eine Variante des Wasserfallmodells. Es betont einen top-down Ansatz bei der Softwareentwicklung beziehungsweise bei der Implementierung betrieblicher Anwendungssysteme. Die Idee ist, sich von recht grob, aus Sicht der Benutzer*innen formulierten Anforderungen schrittweise zu immer genaueren und technischeren Spezifikationen vorzuarbeiten. Das V-Modell räumt dabei dem systematischen Testen eine große Bedeutung ein. Für jede Ebene der Spezifikation werden Testfälle kreiert, die dann systematisch abgearbeitet werden. Dabei gilt das Prinzip des Wasserfalls: der nächste Test ist nur dann möglich, wenn der vorangehende erfolgreich abgeschlossen wurde. Die Grundidee des V-Modells, Spezifikationen schrittweise zu verfeinern und zu jeder Ebene passende Tests durchzuführen, ist in der Praxis heute noch verbreitet und wird beispielsweise bei Medizinproduktherstellern bis heute erfolgreich für die Entwicklung, Konfiguration und Inbetriebnahme von Standardsoftware verwendet..

[Audio] Das Spiralmodell zur Softwareentwicklung stellt eine weitere Verfeinerung des Wasserfallmodells dar. Darin sind noch verschiedene Phasen zu erkennen, sie werden aber in einem zyklischen Prozess arrangiert. Charakteristisch für das Spiralmodell, ist, dass in jedem Zyklus ein Prototyp erstellt wird, in der im Lehrbuch von Hansen, Mendling und Neumann zu findende Abbildung beispielsweise die Prototypen eins, zwei und drei und dann der erste operationale das heißt nutzbare Prototyp. Die Prototypen werden dabei in der Regel von Schritt zu Schritt vollständiger und enthalten mehr Funktionen. Diese schrittweise Vervollständigung entspricht auch die stetige Weiterentwicklung des Entwurfs von einer Systemspezifikation über einen Architekturentwurf hin zum Feinentwurf. Auch die enthaltene Validierung bzw. Überprüfung der Zwischenergebnisse ändert in jedem Zyklus ihren Charakter. Am Anfang wird die Spezifikation überprüft, später dann die Entwürfe und nachdem ein nutzbares System zur Verfügung steht, erfolgt die Validierung der Komponenten, die Integration und schließlich ein Abnahmetest. Im Spiralmodell beginnt sich der im Wasserfallmodell vorgesehene Ansatz des stetigen Voranschreitens in Phasen aufzulösen. Während im V-Modell die Anzahl der Stufen noch fest vorgegeben war, ist die Anzahl der Prototypen und damit zusammenhängend die Anzahl der Umdrehungen beim Spiralmodell nicht mehr von vornherein festgelegt..

[Audio] Bei einer Individualentwicklung hat das Spiralmodell verschiedene Vorteile. Benutzer*innen können bereits in frühen Phasen in den Entwicklungsprozess eingebunden werden und Prototypen testen. Dies gilt umso mehr für die nächste Weiterentwicklung, die agilen Vorgehensmodelle. Agile Vorgehensmodelle wollen Entwicklungsprozesse durch den Abbau von Bürokratie und stärkerer Berücksichtigung menschlicher Aspekte flexibler, schlanker und effizienter machen. Es gibt ein Manifest der agilen Softwareentwicklung, in dem vier Prinzipien festgeschrieben sind. Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge Funktionierende Software ist wichtiger als umfassende Dokumentation Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten Leistungsbeschreibungen. Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan Das Schaubild aus dem bereits mehrfach verwendeten Wirtschaftsinformatiklehrbuch zeigt, wie bei der agilen „Scrum"-Methode gearbeitet wird. Hier gibt es klar festgelegte Rollen, die zu Beginn des Projektes Kommunikationsregeln vereinbaren. Das Team ist zusammengesetzt aus Benutzer*innen und Entwickler*innen. Zudem gibt es zwei herausgehobene Rollen, zum einen die Produktverantwortliche und zum anderen den sogenannten Scrum Master, der für die als „Sprint" bezeichneten Entwicklungszyklen verantwortlich ist. Ein Sprint ist eine 2 bis 4 Wochen lange Iteration, während der eine Aufgabenliste möglichst vollständig abgearbeitet wird. Welche Aufgaben in der Liste erscheinen und bearbeitet werden, entscheidet das Team vor jeder Iteration selbst. Dadurch ist es selbstbestimmter als bei anderen Vorgehensmodellen. Der Scrum Master überwacht während des Sprints, dass die vorgegebenen Zeiten eingehalten werden. Wenn Aufgaben nicht erfüllt wurden, kommen sie zurück in die Anforderungsliste. Am Ende eines Sprints präsentiert das Team die Ergebnisse der Produktverantwortlichen. Oft werden die Ergebnisse direkt in das System eingespielt und können sofort erprobt werden. Ausführlichere Erläuterungen zum agilen sowie zu den vorangegangenen Vorgehensmodellen finden Sie auch in den Materialen des WiLMo Themengebiets, das sich mit der Entwicklung von Informationssystemen und Software Engineering befasst..

[Audio] Nachdem wir in der vorangehenden Einheit verschiedene Vorgehensmodelle kennengelernt haben, wollen wir jetzt untersuchen, welche Stärken und Schwächen sie haben und fragen, in wie fern sie für die Auswahl und Einführung eines betrieblichen Anwendungssystems geeignet erscheinen..

[Audio] Wir unterscheiden die klassischen oder planorientierten Vorgehensmodelle auf der einen und die agilen oder evolutionären Modelle auf der anderen Seite. Klassische Vorgehensmodelle, bei denen die Ziele früh festgelegt und dann abgearbeitet werden, haben Nachteile, die das Risiko von Fehlentwicklungen, unerwarteten Kostensteigerungen oder Verlängerungen der Projektdauer erhöhen. Zum einen werden im Wasserfall und besonders im V-Modell die Anforderungen, die das betriebliche Anwendungssystem erfüllen soll, schon sehr früh festgeschrieben. Alle folgenden Aktivitäten sind davon abhängig, dass die Anforderungen zu Beginn vollständig und sinnvoll festgelegt wurden. Das ist aber oft nicht möglich, weil während der Durchführung der Projekte neue Erkenntnisse gewonnen werden oder sich die Prioritäten verändern. Zum anderen sehen diese planorientierten Modelle eine dokumentenorientierte Qualitätssicherung beim Übergang zwischen zwei Phasen vor. Zu Meilensteinen wird beispielsweise ein Konzeptdokument oder ein Testprotokoll hergestellt, überprüft, kommentiert, überarbeitet und abgenommen. Das erzeugt viel zusätzliche Arbeit, verlangsamt das Projekt und macht es besonders beim Einsatz externer Beratungsressourcen auch teurer. Dieser Aufwand ist für kleine Vorhaben oft nicht zu rechtfertigen. Agile Vorgehensmodelle sind selbstverständlich nicht planlos, aber Sie erlauben es, den Plan zu vervollständigen und evolutionär, d.h. sich ändernden Bedingungen entsprechend weiterzuentwickeln. Dementsprechend haben sie den Vorteil, dass die Entwicklungsarbeit mit weniger vorausgehender Dokumentation gestartet werden kann. Das erwartete Ergebnis steht zum Beginn in groben Zügen fest, Details der Umsetzung und Anforderungen können laufend erweitert und angepasst werden. Zudem beziehen agile Vorgehensweisen wie die Scrum Methode „den Kunden" also zum Beispiel die zukünftigen Benutzer*innen mehr in die Projektarbeit ein, so dass sie selbst Verantwortung für das Ergebnis übernehmen und insgesamt viel besser über den Projektfortschritt informiert sind. Dadurch können die Dokumentationsarbeiten auf das Notwendige reduziert werden. Weniger Dokumentationsarbeit und der Verzicht auf eine detaillierte und vollständige Vorabfestlegung des Projektergebnisses, führen dazu, dass agile Projekte oft schneller erste Ergebnisse liefern..

[Audio] Es gibt aber auch eine andere Sichtweise auf die Unterschiede zwischen klassischen und agilen Vorgehensmodellen. Das Prinzip der Selbstorganisation, die geteilte Verantwortung für das Projektergebnis und der Verzicht auf detaillierte und vorab festgeschriebene Anforderungen und Mindestergebnisse des Projektes, funktionieren nämlich umso besser wenn alle Projektbeteiligten das gleiche Ziel verfolgen und es keine grundsätzlichen Interessenskonflikte gibt. Das ist aber insbesondere beim Einsatz externer Ressourcen und der Nutzung einer Standardsoftware nicht uneingeschränkt gegeben. Auch wenn alle Parteien ein erfolgreiches Projekt wünschen, existiert natürlich zwischen Auftraggeber und Auftragnehmer ein grundsätzlicher Interessenkonflikt, der darin besteht, dass der Auftraggeber maximale Leistung und möglichst geringen Kosten wünscht und der Auftragnehmer seine Leistungen gewinnbringend verkaufen möchte. Ein ständiges Korrigieren und Erweitern der Anforderungen kann also Konflikte verursachen, wenn für die Konfiguration und Einführung beispielsweise ein Festpreis vereinbart wurde. Andersherum haben die externe Berater*innen oft einen so großen Wissensvorsprung, dass sie ihre Interessen in agilen Projekten machtvoll durchsetzen können. Insbesondere weil beim Einsatz von Standardsoftware viele Eigenschaften des Anwendungssystems vorab festgelegt sind und gar nicht verhandelt oder definiert werden können. Auch die Reihenfolge der Konfigurationsschritte kann durch die Softwarekonzepte vorgeben sein. In Abwesenheit vorab definierter Mindestanforderungen fehlen dann unter Umständen Kontrollmöglichkeiten, um das Projekt zum Abschluss zu bringen und sicherzustellen, dass die Anforderungen des Anwenders optimal realisiert wurden. Außerdem gewährt das agile Vorgehen dem Projektteam so viel Freiheit, dass eine Qualitätskontrolle von außen nicht einfach möglich ist..

[Audio] Zum Abschluss dieser Einheit eine Frage für Sie: Welches der verschiedenen Vorgehensmodelle ist für die Auswahl und Einführung betrieblicher Anwendungssysteme am geeignetsten?.

[Audio] Wie erläutert wurde, haben die verschiedenen Vorgehensmodelle unterschiedliche Vor- und Nachteile, aber keines der Modelle passt perfekt zu einem Auswahl- und Einführungsprojekt beim Einsatz von Standardanwendungssoftware. Gegen ein von Anfang bis Ende klassisches​ oder „planorientiertes" Vorgehen spricht, dass es die auswählende Organisation während des Prozesses weiter dazu lernt, neue Anforderungen erkannt und auch neue Lösungsmöglichkeiten gefunden werden. Je nach Auswahl eines Produktes erscheint es dann vielleicht sinnvoll bestimmte ursprünglich formulierte Anforderungen anzupassen oder sogar zugunsten anderer fallen zu lassen. Auch während der Implementierung und Einführung von Standardsoftware kann ein agiles auf Wiederholungen basierendes Vorgehen wie im Spiralmodell oder bei Scrum Vorteile haben, weil die Funktionen der Anwendung hier Schritt für Schritt eingeführt werden und Erfahrungen mit dem Einsatz zur Verbesserung genutzt werden können. Ein rein evolutionäres Vorgehen ist allerdings auch nicht passend. Einerseits müssen bis zur Auswahl eines Anbieters bestimmte Schritte in einer logischen Reihenfolge vollzogen werden. Beispielsweise müssen Anforderungen an die Anbieter kommuniziert werden, damit diese Angebote und Aufwandsschätzungen abgeben können. Zudem ist ohne Phasen und Termine die für einen fairen Prozess notwendige Synchronisation der Kommunikation mit den Anbietern schwer möglich. Außerdem werden im Auswahlprozess Entscheidungen getroffen die später schwer oder gar nicht revidiert werden können, auch das widerspricht einem evolutionären Prozess..

[Audio] Wenn also weder ein rein planorientiertes noch ein rein evolutionäres Vorgehen passend erscheint, liegt es nahe die Stärken beider Ansätze zu kombinieren. Auswahlprozesse laufen bedingt durch die notwendige Reihenfolge der Schritte und das Bedürfnis, Anbieter parallel zu bewerten, meist wasserfallartig ab. Rücksprünge und gewisse Zyklen sind dabei nicht ausgeschlossen, aber selten. Ab dem Zeitpunkt des Vertragsabschlusses kann sich die Vorgehensweise aber ändern. Teilweise behalten Anwender nach der Auswahl eines Softwarelieferanten die wasserfallartige Vorgehensweise bei. So ist es üblich, dass Verträge zwischen Anwendern und Softwareanbietern oder Integrationspartnern bis zu Go-Live ein Wasserfall-ähnliches Phasenmodell vorsehen, in dem Meilensteine definiert sind, zu denen die Auftragnehmer Zwischenrechnungen stellen können, beispielsweise für die Erstellung des Feinkonzepts. Aber erst wenn der Auftraggeber mit dem Zwischenergebnis zufrieden ist und die Abnahme erteilt, wird die entsprechende Rechnungsbetrag fällig. So kann der Auftraggeber Kontrolle über die Qualität und den Fortschritt des Projekts ausüben. In anderen Fällen wird bereits in der Einführungsphase ein auf Wiederholungen basierendes Modell gewählt um die vielen Schritte der Einführung flexibler abzuarbeiten. Spätestens nach der Produktivsetzung wechseln viele Projekte dann in einen eher agilen Modus, in dem es einfacher möglich ist, die nächsten umzusetzenden Szenarios, Funktionen, Prozesse oder Anforderungen flexibler zu definieren..