Lade Inhalt...

Scrum versus Wasserfallmodell. Methoden des Projektmanagements im Vergleich

Seminararbeit 2016 21 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

II. Abbildungsverzeichnis

III. Abkürzungsverzeichnis

1 Einleitung

2 Klassisches Projektmanagement „Wasserfall“
2.1 Beschreibung der Methode
2.2 Rollen
2.3 Phasen
2.3.1 Anforderungsanalyse
2.3.2 Systemspezifikation
2.3.3 Implementierung/ Programmierung
2.3.4 Systemtests & Qualitätssicherung
2.3.5 Abschluss / Betrieb
2.4 Vorteile und Nachteile
2.4.1 Vorteile
2.4.2 Nachteile

3 Scrum
3.1 Beschreibung der Methode
3.2 Rollen
3.3 Artefakte
3.3.1 Product Backlog
3.3.2 Sprint Backlog
3.3.3 Inkrement
3.4 Aktivitäten
3.4.1 Sprint
3.4.2 Sprint Planning
3.4.3 Daily Scrum
3.4.4 Sprint Review
3.4.5 Sprint Retrospektive
3.5 Vorteile und Nachteile
3.5.1 Vorteile
3.5.2 Nachteile

4 Vergleich der Methoden und kritische Bewertung

5 Schluss

IV. Literatur- und Quellenverzeichnis

II. Abbildungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

III. Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

„Ein Projekt ist ein zielgerichtetes, einmaliges Vorhaben, das aus einem Satz von abgestimmten, gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Ressourcen [...] und Qualität ein Ziel zu erreichen.“[1] „Als Projektmanagement bezeichnet man das Initiieren, Planen, Steuern, Kontrollieren und Abschließen von Projekten.“[2]

Projekte unterscheiden sich durch ihre Einmaligkeit und Individualität. Kein Projekt ist wie das andere. Dadurch wird das Planen und Steuern deutlich erschwert. Um Projekte dennoch erfolgreich zu managen, existieren Regelwerke, die einen Leitfaden zum Durchführen von Projekten bereitstellen. Durch die darin beschriebene Standardisierung einzelner Projektschritte soll das Managen von Projekten vereinfacht werden. Die Regelwerke reduzieren die Komplexität und geben so dem Projektverantwortlichen ein Hilfsmittel zur erfolgreichen Projektdurchführung an die Hand. In den Regelwerken werden Standards des allgemeinen Ablaufs, der einzelnen Prozessschritte, der beteiligten Personen und der entstehenden Artefakte beschrieben, um das Projekt übersichtlicher und handhabbarer zu gestalten. Diese Regelwerke nennt man Projektmanagementmethoden. Projektmanagementmethoden können auf Projekte der unterschiedlichsten Bereiche angewendet werden. Die Spanne ist weit gefasst und kann sich von Bauvorhaben über Marketingkampagnen bis hin zu Strategieprojekten erstrecken. Diese Arbeit konzentriert sich gezielt auf Projekte aus dem Bereich der Softwareentwicklung.

In der Softwareentwicklung haben sich vor allem zwei Methoden herauskristallisiert, die in dieser Arbeit näher beleuchtet werden sollen - das klassische Wasserfallmodell und der agile Scrum-Ansatz.

Das Wasserfallmodell wurde erstmalig 1970 von Winston W. Royce formal beschrieben und seither immer weiterentwickelt. Es stammt ursprünglich aus dem Bau- und Produktionsprozess. In beiden Bereichen ist es wichtig eine gute Planung zu Beginn zu machen, da Änderungen im Nachgang oft teuer und schwer umzusetzen sind. Nachdem damals kein formaler Softwareentwicklungsprozess existierte, wurden die dort verwendeten Prozesse einfach für Softwareentwicklung übernommen. Die Vorgehensweise stieß aber im Softwareentwicklungsprozess an ihre Grenzen. So wurden neue Methoden entwickelt, die die Schwächen des Wasserfallmodells beseitigen sollten. Eine dieser Methoden ist Scrum. Scrum wurde zu Beginn der 1990er Jahre gemeinsam von Ken Schwaber und Jeff Sutherland erarbeitet und beschrieben. Ihr Ziel war es Softwareprodukte schneller und flexibler zu entwickeln, um so IT-Projekte erfolgreicher abzuschließen. Scrum ist ein Rahmenwerk, das aufgrund seiner innovativen Methode verspricht den Softwareprozess schlank und effizient zu gestalten.

Doch ist Scrum tatsächlich das Allheilmittel, um die Probleme des klassischen Vorgehens zu umgehen und Projekte schneller und erfolgreicher abzuschließen? Oder kann das Wasserfallmodell trotz seiner nachgesagten Schwächen im Softwareprojektmanagement mithalten?

Das Ziel dieser Arbeit ist es, durch die Analyse der beiden Methoden eine Aussage über die jeweiligen Vor- und Nachteile zu treffen, sowie diese zu bewerten. Jedes Projekt hat durch seine Individualität bestimmte Charakteristika, die durch bestimmte Rahmenparameter geprägt sind. Anhand der Analyse soll es möglich sein, die Rahmenparameter von Projekten zu erkennen, um anhand dieser die richtig einzusetzende Methode auszuwählen.

Die Seminararbeit enthält fünf Kapitel, die wie folgt unterteilt sind: Strukturell beginnt die Arbeit in Kapitel 1 mit der hier niedergeschriebenen Einleitung. In den folgenden beiden Kapiteln werden die beiden ausgewählten Projektmanagementmethoden detailliert erklärt. Das zweite Kapitel beschreibt die klassische Methode „Wasserfallmodell“ und erklärt dessen Rollen und Phasen. Nach der Beschreibung werden die Vor- und Nachteile dieser Methode erläutert. Das dritte Kapitel beschäftigt sich daraufhin mit der zweiten gewählten Methode, dem Scrum-Verfahren. Der Scrum-Ansatz wird ebenfalls mit seinen Rollen, Artefakten und Aktivitäten erklärt und die Vor- und Nachteile herausgearbeitet. In Kapitel 4 werden anschließend die beiden Methoden miteinander verglichen, um sie kritisch gegeneinander abzugrenzen und sie zu bewerten. Das Kapitel 5 enthält den Schluss und damit das Fazit der Arbeit.

2 Klassisches Projektmanagement „Wasserfall“

2.1 Beschreibung der Methode

Spricht man vom klassischen Projektmanagement, so ist im Allgemeinen das Wasserfallmodell gemeint.

Das Wasserfallmodell ist ein nicht iteratives Vorgehensmodell, das definierte Phasen sequentiell durchschreitet. Parallele Arbeiten in verschiedenen Phasen sind nicht vorgesehen.

Ist eine Phase vollständig durchlaufen und damit beendet, resultiert ein Ergebnisdokument bzw. ein Ergebnisprodukt. Erst nach Abnahme des Ergebnisartefaktes wird in die nächste Phase übergegangen. Es dient als Ausgangsbasis für den Einstieg in die nächste Phase.

Typische Phasen im Wasserfallmodell sind die Anforderungsanalyse, Systemspezifikation, Implementierung/ Programmierung, Systemtests und Betrieb. In Ausnahmesituationen sind Rücksprünge in eine vorangegangene Phase erlaubt.

Abbildung in dieser Leseprobe nicht enthalten

Durch die grafische Darstellung der nacheinander absteigend verlaufenden Phasen hat das Wasserfallmodel seinen Namen erhalten.

2.2 Rollen

Im Wasserfallmodell werden im Allgemeinen drei Rollen unterschieden, die im Projekt unterschiedliche Aufgaben haben. Die Rollen und deren Aufgaben- und Verantwortungsbereiche werden im Folgenden genauer beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

2.3 Phasen

2.3.1 Anforderungsanalyse

In der Phase Anforderungsanalyse werden die Anforderungen an das IT-System ermittelt.

Ziel der Analysephase ist die Sammlung aller Informationen, die für die Planung und Realisierung des geplanten Systems von Bedeutung sind, also z.B. Informationen über Arbeitsabläufe, Ausbaustrukturen, Organisationskonzepte, Aufgaben, Methoden bzw. Verfahren, Datenstrukturen und Datenflüsse. Es wird sowohl die Ist-Situation als auch der gewünschte Soll-Zustand beschrieben. Dies wird entweder vom Fachbereich selbst durchgeführt oder, falls die entsprechenden Kenntnisse nicht vorhanden sind, von einem Requirements Engineer[3] gemeinsam mit dem Fachbereich.

Ziel dieser Phase ist es, alle funktionalen[4] sowie nicht-funktionalen[5] Anforderungen zu erfassen und im Lastenheft[6] niederzuschreiben. Es wird auch dokumentiert, welche Themen im Rahmen des Projektes nicht umgesetzt werden sollen, um die Inhalte des Projektes klar abzugrenzen.

Das Ergebnisdokument dieser Phase ist das Lastenheft.

2.3.2 Systemspezifikation

Nachdem die fachlichen Anforderungen vollständig ermittelt, niedergeschrieben und abgenommen wurden, startet die Phase der Systemspezifikation. Auf Basis des Lastenhefts wird ein vollständiges, umfassendes Lösungskonzept entwickelt. Inhalt der Spezifikation sind die Entscheidungen zur IT-Infrastruktur, der einzusetzenden Plattform, mögliche Anpassungen einer Standardsoftware, möglicher Schnittstellen, sowie der Server- und Datenbankarchitektur. Die Systemspezifikation ist eine sehr technische Phase und wird daher von der IT-Abteilung durchgeführt.

Das Ergebnisdokument dieser Phase ist das Pflichtenheft[7].

2.3.3 Implementierung/ Programmierung

Auf Basis des Pflichtenheftes wird anschließend mit der Umsetzung des Projektes begonnen.

Die Implementierung wird anhand der im Pflichtenheft beschriebenen Anforderungen vorgenommen. In einem Softwareprojekt wird nun begonnen Programmcode zu produzieren. Das Entwicklungsteam wird in dieser Phase bereits erste Komponententests und Reviews durchführen, um die Lauffähigkeit der Software sicherzustellen. Am Ende der Phase sind die Anforderungen aus dem Pflichtenheft durch das Entwicklungsteam umgesetzt.

Das Ergebnisprodukt ist eine weitestgehend funktionierende Software.

2.3.4 Systemtests & Qualitätssicherung

Die Software wird nach der Implementierung dem Fachbereich in einer Testumgebung zugänglich gemacht, damit dieser nun ausführliche Systemtests durchführen kann.

Der Fachbereich prüft sowohl die fehlerfreie Umsetzung, die fachliche Richtigkeit als auch die Vollständigkeit aller definierten Anforderungen.

Besonderes Augenmerk sollte hierbei auf besonders kritische Prozesse der Anwendung gelegt werden. Grundsätzlich gilt, dass ein System nie hundertprozentig getestet werden kann. Allerdings sollten alle wichtigen Prozesse funktionieren, bevor das System in den Produktivbetrieb übergeht. Eine ungetestete, fehlerbehaftete Applikation schafft eine große Unzufriedenheit bei den Endanwendern und sollte unbedingt vermieden werden.

Idealerweise wird phasenbegleitend ein Testprotokoll mit den definierten Testfällen gepflegt, um die Nachvollziehbarkeit und die Kommunikation zwischen dem Fachbereich und dem Entwicklungsteam zu erleichtern. Sind die Tests erfolgreich abgeschlossen, wird das System vom Fachbereich abgenommen und zur Produktivsetzung freigegeben.

Das Ergebnis dieser Phase ist eine vollständig umgesetzte, fehlerfrei funktionierende Software.

2.3.5 Abschluss / Betrieb

Die freigegebene Software wird in der letzten Phase aus der Testumgebung in die Produktivumgebung überführt. Es erfolgt der sogenannte „Go Live“ des Systems.

Hierbei müssen mögliche Downtimes[8] geplant werden. Diese sollte nicht zu Stoßzeiten durchgeführt werden, um die Endanwender bei ihrer Arbeit mit dem System nicht zu stören.

Um einen reibungslosen Ablauf zu gewährleisten, sollten alle Projektbeteiligten zur Zeit des Livegangs greifbar sein.

Ist das System produktiv gesetzt, geht es in den laufenden Betrieb über. Um einen stabilen Betrieb zu gewährleisten, werden häufig zwei Dokumente zur Unterstützung bereitgestellt. Das Entwicklungsteam erstellt zum einen das Betriebshandbuch zur Administration des Systems. Dies wird an die Support-Abteilung des Systems übergeben. Zum anderen wird eine Anwenderdokumentation durch den Fachbereich geschrieben und den Endanwendern zur Verfügung gestellt.

Das Ergebnis dieser Phase ist eine im täglichen Betrieb stabil laufende Software.

[...]


[1] Quelle: https://de.wikipedia.org/wiki/Projekt [letzter Zugriff: 25.03.2016]

[2] Quelle: https://de.wikipedia.org/wiki/Projektmanagement [letzter Zugriff: 25.03.2016]

[3] Ein Requirements Engineer ist eine Person, die professionell Anforderungen ermittelt, dokumentiert, prüft und abstimmt.

[4] Funktionale Anforderungen beschreiben gewünschte Funktionalitäten […] eines Systems (http://www.anforderungsmanagement.ch, 28.03.2016).

[5] Nichtfunktionale Anforderungen sind Anforderungen, an die "Qualität" in welcher die geforderte Funktionalität zu erbringen ist (http://www.anforderungsmanagement.ch, 28.03.2016).

[6] Ein Lastenheft ist ein Dokument, in dem die fachlichen Anforderungen an eine Software

beschrieben werden.

[7] Das Pflichtenheft enthält die Dokumentation der technischen Spezifikationen.

[8] Downtimes werden die Zeiten genannt, an denen das System für die Endanwender nicht verfügbar ist.

Details

Seiten
21
Jahr
2016
ISBN (eBook)
9783668257184
ISBN (Buch)
9783668257191
Dateigröße
438 KB
Sprache
Deutsch
Katalognummer
v322443
Institution / Hochschule
Internationale Fachhochschule Bad Honnef - Bonn
Note
1,3
Schlagworte
scrum wasserfallmodell methoden projektmanagements vergleich

Autor

Teilen

Zurück

Titel: Scrum versus Wasserfallmodell. Methoden des Projektmanagements im Vergleich