https://hugo.globuklumbo.de/tags/wasserfall/Recent content in Wasserfall on FISI LernzettelHugodehttps://hugo.globuklumbo.de/09_projektmanagement/klassisches-projektmanagement/Mon, 01 Jan 0001 00:00:00 +0000https://hugo.globuklumbo.de/09_projektmanagement/klassisches-projektmanagement/<h1 id="klassisches-projektmanagement-wasserfall">Klassisches Projektmanagement (Wasserfall)<a class="anchor" href="#klassisches-projektmanagement-wasserfall">#</a></h1> <p>Im Gegensatz zu <a href="../09_projektmanagement/agile_methoden.md">agilen Methoden</a> plant das <strong>klassische (plangetriebene) Projektmanagement</strong> ein Projekt vollständig im Voraus und arbeitet die Phasen <strong>sequentiell</strong> ab.</p> <hr> <h2 id="das-wasserfallmodell">Das Wasserfallmodell<a class="anchor" href="#das-wasserfallmodell">#</a></h2> <pre class="mermaid" data-mermaid-src="Zmxvd2NoYXJ0IFRECiAgQVtBbmZvcmRlcnVuZ3NhbmFseXNlXSAtLT4gQltQbGFudW5nL0Rlc2lnbl0KICBCIC0tPiBDW1Vtc2V0enVuZ10KICBDIC0tPiBEW1Rlc3RdCiAgRCAtLT4gRVtBYm5haG1lL0VpbmbDvGhydW5nXQogIEUgLS0&#43;IEZbV2FydHVuZ10=">flowchart TD A[Anforderungsanalyse] --&gt; B[Planung/Design] B --&gt; C[Umsetzung] C --&gt; D[Test] D --&gt; E[Abnahme/Einführung] E --&gt; F[Wartung]</pre><p>Jede Phase wird <strong>vollständig abgeschlossen</strong>, bevor die nächste beginnt — ein Rücksprung in eine vorherige Phase ist im klassischen Modell nicht vorgesehen (im Gegensatz zu iterativen/agilen Modellen).</p> <h2 id="merkmale">Merkmale<a class="anchor" href="#merkmale">#</a></h2> <table> <thead> <tr> <th>Merkmal</th> <th>Beschreibung</th> </tr> </thead> <tbody> <tr> <td><strong>Planung im Voraus</strong></td> <td>Anforderungen werden zu Beginn vollständig erhoben und fixiert</td> </tr> <tr> <td><strong>Sequentieller Ablauf</strong></td> <td>Phasen werden nacheinander, nicht parallel/iterativ durchlaufen</td> </tr> <tr> <td><strong>Klare Meilensteine</strong></td> <td>Jede Phase endet mit einem definierten, abnehmbaren Ergebnis</td> </tr> <tr> <td><strong>Umfangreiche Dokumentation</strong></td> <td>Lasten-/Pflichtenheft, Spezifikationen vor Projektstart</td> </tr> </tbody> </table> <h2 id="wasserfall-vs-agil">Wasserfall vs. Agil<a class="anchor" href="#wasserfall-vs-agil">#</a></h2> <table> <thead> <tr> <th>Kriterium</th> <th>Klassisch (Wasserfall)</th> <th>Agil (Scrum/Kanban)</th> </tr> </thead> <tbody> <tr> <td><strong>Anforderungen</strong></td> <td>Zu Beginn fixiert</td> <td>Können sich während des Projekts ändern</td> </tr> <tr> <td><strong>Kundenfeedback</strong></td> <td>Erst am Ende (Abnahme)</td> <td>Fortlaufend, nach jedem Sprint</td> </tr> <tr> <td><strong>Änderungen</strong></td> <td>Aufwendig, da spätere Phasen betroffen sind</td> <td>Eingeplant, Teil des Prozesses</td> </tr> <tr> <td><strong>Eignung</strong></td> <td>Klar definierte, stabile Anforderungen (z. B. Bauprojekte, gesetzlich vorgeschriebene Systeme)</td> <td>Unklare/sich ändernde Anforderungen, Softwareentwicklung</td> </tr> <tr> <td><strong>Dokumentation</strong></td> <td>Umfangreich, vorab</td> <td>Schlanker, &ldquo;working software over documentation&rdquo;</td> </tr> </tbody> </table> <blockquote class='book-hint tip'> <p>Wasserfall eignet sich, wenn Anforderungen <strong>von Anfang an klar und stabil</strong> sind (z. B. Behörden-Projekte mit festen gesetzlichen Vorgaben). Bei unsicheren/sich ändernden Anforderungen ist ein agiles Vorgehen geeigneter.</p>