{"id":1979,"date":"2026-04-30T09:06:53","date_gmt":"2026-04-30T09:06:53","guid":{"rendered":"https:\/\/www.pickplace.de\/?post_type=glossary&#038;p=1979"},"modified":"2026-04-30T09:14:45","modified_gmt":"2026-04-30T09:14:45","slug":"wasserfallmodell","status":"publish","type":"glossary","link":"https:\/\/www.pickplace.de\/en\/glossar\/wasserfallmodell\/","title":{"rendered":"Wasserfallmodell"},"content":{"rendered":"<p>Das Wasserfallmodell ist ein klassisches, lineares Vorgehensmodell im Projektmanagement und insbesondere in der Software- und Systementwicklung, das auf einer strikt sequenziellen Abarbeitung von Projektphasen basiert. Der grundlegende Gedanke besteht darin, dass ein Entwicklungsprozess in klar voneinander abgegrenzte Phasen unterteilt wird, die jeweils vollst&#xE4;ndig abgeschlossen sein m&#xFC;ssen, bevor die n&#xE4;chste beginnt. Typischerweise umfasst dieser Ablauf die Schritte Anforderungsanalyse, Systementwurf, Implementierung, Test sowie Auslieferung und Wartung. Jede dieser Phasen erzeugt definierte Ergebnisse, h&#xE4;ufig in Form umfangreicher Dokumentation, die als verbindliche Grundlage f&#xFC;r die nachfolgenden Schritte dient. Der Name des Modells leitet sich aus der bildhaften Darstellung dieser Abfolge ab, bei der die Phasen wie Kaskaden eines Wasserfalls aufeinander folgen und Ergebnisse &#x201E;nach unten weitergereicht&#x201C; werden.<\/p>\n\n\n\n<div class=\"wp-block-stackable-image stk-block-image stk-block stk-3edd3c8\" data-block-id=\"3edd3c8\"><figure><span class=\"stk-img-wrapper stk-image--shape-stretch\"><img loading=\"lazy\" decoding=\"async\" class=\"stk-img wp-image-1983\" src=\"https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/waterfall-model-wasserfallmodell.jpg\" width=\"1200\" height=\"600\" alt=\"Flowchart des Wasserfallmodells: Anforderungen, Entwurf, Entwicklung, Testen, Einf&#xFC;hrung, Wartung &#x2013; embedded software\"\/><\/span><\/figure><\/div>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Inhalt<\/h2><nav><ul><li class=\"\"><a href=\"#merkmale-des-wasserfallmodells\">Merkmale des Wasserfallmodells<\/a><ul><li class=\"\"><a href=\"#dokumentenorientierung\">Dokumentenorientierung<\/a><\/li><li class=\"\"><a href=\"#grundannahme-konsistenz-anforderungen\">Grundannahme: Konsistenz der Anforderungen<\/a><\/li><\/ul><\/li><li class=\"\"><a href=\"#grunde-fur-das-wasserfallmodell\">Gr&#xFC;nde f&#xFC;r das Wasserfallmodell<\/a><\/li><li class=\"\"><a href=\"#verwendung\">Verwendung<\/a><\/li><li class=\"\"><a href=\"#zusammenfassung\">Zusammenfassung<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"merkmale-des-wasserfallmodells\">Merkmale des Wasserfallmodells<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"dokumentenorientierung\">Dokumentenorientierung<\/h3>\n\n\n\n<p>Charakteristisch f&#xFC;r das Wasserfallmodell ist seine starke Dokumentenorientierung. Am Ende jeder Phase steht ein formal &#xFC;berpr&#xFC;fbares Artefakt, etwa ein Lastenheft, ein Pflichtenheft, Architektur- oder Designbeschreibungen, Testprotokolle oder Freigabedokumente. Diese Dokumente erf&#xFC;llen nicht nur eine technische Funktion, sondern dienen auch der Steuerung, Kontrolle und Nachweisf&#xFC;hrung innerhalb des Projekts. Dadurch entsteht ein hoher Grad an Formalisierung, der insbesondere in regulierten Umgebungen als Vorteil betrachtet wird. Gleichzeitig f&#xFC;hrt diese Dokumentenlast zu einem erheblichen Overhead, insbesondere in Projekten mit dynamischen oder unscharfen Anforderungen.<\/p>\n\n\n\n<p>Historisch betrachtet stammt das Wasserfallmodell nicht urspr&#xFC;nglich aus der Softwareentwicklung, sondern aus klassischen Ingenieurdisziplinen wie dem Bauwesen oder der industriellen Fertigung. In diesen Bereichen ist es &#xFC;blich, dass Anforderungen fr&#xFC;hzeitig weitgehend vollst&#xE4;ndig definiert werden k&#xF6;nnen und sp&#xE4;tere &#xC4;nderungen mit hohen Kosten oder Risiken verbunden sind. Dieses Paradigma wurde in den fr&#xFC;hen Tagen der Softwareentwicklung &#xFC;bernommen, als es noch kaum etablierte Prozesse oder methodische Standards gab. <\/p>\n\n\n\n<p>Eine zentrale Rolle in der historischen Einordnung spielt Winston W. Royce, dessen Ver&#xF6;ffentlichung aus dem Jahr 1970 h&#xE4;ufig als Ursprung des Wasserfallmodells zitiert wird. Interessanterweise beschrieb Royce selbst das lineare Modell nicht als Best Practice, sondern wies explizit auf dessen Schw&#xE4;chen hin und schlug bereits iterative Elemente wie fr&#xFC;he Prototypen und kontinuierliche Kundenbeteiligung vor. Die sp&#xE4;tere Interpretation seiner Arbeit reduzierte diese differenzierte Sicht jedoch oft auf das vereinfachte, strikt lineare Modell.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"grundannahme-konsistenz-anforderungen\">Grundannahme: Konsistenz der Anforderungen<\/h3>\n\n\n\n<p>Ein wesentliches Merkmal des Wasserfallmodells ist die Annahme, dass Anforderungen zu Beginn eines Projekts vollst&#xE4;ndig, konsistent und stabil erfasst werden k&#xF6;nnen. Diese Annahme ist in der Praxis jedoch h&#xE4;ufig nicht haltbar, insbesondere in der Softwareentwicklung, wo Anforderungen durch technologische Entwicklungen, Marktver&#xE4;nderungen oder neue Erkenntnisse w&#xE4;hrend des Projekts beeinflusst werden. Die Konsequenz ist, dass &#xC4;nderungen, die nach Abschluss der Anforderungsphase auftreten, nur schwer integriert werden k&#xF6;nnen. Da jede Phase auf den Ergebnissen der vorherigen aufbaut, f&#xFC;hren Anpassungen oft zu aufwendigen R&#xFC;ckspr&#xFC;ngen, die das gesamte Projekt verz&#xF6;gern und verteuern k&#xF6;nnen.<\/p>\n\n\n\n<p>Ein weiterer kritischer Punkt ist die zeitliche Struktur des Modells. Da funktionierende Teilsysteme erst relativ sp&#xE4;t im Projekt entstehen, erfolgt die Validierung des Gesamtsystems ebenfalls sp&#xE4;t. Fehler oder Fehlannahmen werden h&#xE4;ufig erst in der Integrations- oder Testphase sichtbar, zu einem Zeitpunkt, an dem Korrekturen besonders aufwendig sind. Dieser sogenannte &#x201E;Late Feedback&#x201C;-Effekt ist einer der Hauptgr&#xFC;nde, warum das Wasserfallmodell in vielen modernen Entwicklungsumgebungen als problematisch angesehen wird. Im Gegensatz dazu setzen neuere Ans&#xE4;tze auf fr&#xFC;he und kontinuierliche Validierung, um Risiken fr&#xFC;hzeitig zu identifizieren und zu reduzieren.<\/p>\n\n\n\n<p>Die lineare Struktur f&#xFC;hrt zudem zu einem sogenannten <a href=\"https:\/\/www.geeksforgeeks.org\/software-testing\/big-bang-integration-testing\/\" target=\"_blank\" rel=\"noopener\">&#x201E;Big Bang&#x201C;-Integrationsansatz<\/a>. Einzelne Komponenten werden unabh&#xE4;ngig voneinander entwickelt und erst am Ende zusammengef&#xFC;hrt. Dadurch steigt das Risiko von Integrationsproblemen erheblich, da Schnittstellen, Annahmen und Abh&#xE4;ngigkeiten oft nicht ausreichend getestet wurden. In komplexen Systemen kann dies zu erheblichen Verz&#xF6;gerungen f&#xFC;hren, insbesondere wenn grundlegende Architekturentscheidungen revidiert werden m&#xFC;ssen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"grunde-fur-das-wasserfallmodell\">Gr&#xFC;nde f&#xFC;r das Wasserfallmodell<\/h2>\n\n\n\n<p>Trotz dieser Nachteile bietet das Wasserfallmodell einige Eigenschaften, die in bestimmten Kontexten weiterhin als vorteilhaft gelten. Die klare Strukturierung der Phasen erm&#xF6;glicht eine relativ einfache Planung und Kontrolle des Projektfortschritts. Meilensteine sind eindeutig definiert, und der Fortschritt kann anhand abgeschlossener Dokumente nachvollzogen werden. Dies erleichtert insbesondere die Kommunikation mit Stakeholdern, die nicht tief in den technischen Details involviert sind. Zudem erm&#xF6;glicht die fr&#xFC;he Festlegung von Anforderungen eine vergleichsweise pr&#xE4;zise Absch&#xE4;tzung von Kosten und Ressourcen, zumindest unter der Voraussetzung stabiler Rahmenbedingungen.<\/p>\n\n\n\n<p>Ein weiterer Aspekt ist die Nachvollziehbarkeit und Auditierbarkeit des Entwicklungsprozesses. In stark regulierten Branchen, etwa in der Luft- und Raumfahrt, der Medizintechnik oder im <a href=\"https:\/\/www.pickplace.de\/rustung-und-verteidigung\/\" data-type=\"page\" data-id=\"1041\">Verteidigungsbereich<\/a>, sind detaillierte Dokumentation und formale Freigaben zwingend erforderlich. Hier spielt das Wasserfallmodell seine St&#xE4;rken aus, da es eine klare Zuordnung von Anforderungen, Designentscheidungen und Implementierungen erm&#xF6;glicht. Jede Entscheidung kann dokumentiert und sp&#xE4;ter &#xFC;berpr&#xFC;ft werden, was f&#xFC;r Zertifizierungsprozesse und Compliance-Anforderungen essenziell ist.<\/p>\n\n\n\n<p>Gleichzeitig zeigt sich jedoch, dass diese Vorteile in vielen anderen Bereichen durch die Nachteile &#xFC;berlagert werden. Insbesondere in dynamischen M&#xE4;rkten oder bei innovationsgetriebenen Projekten ist die notwendige Flexibilit&#xE4;t nicht gegeben. Die Unf&#xE4;higkeit, auf neue Erkenntnisse schnell zu reagieren, f&#xFC;hrt dazu, dass entwickelte Systeme zum Zeitpunkt ihrer Fertigstellung bereits veraltet sein k&#xF6;nnen. Dies ist besonders kritisch in der Softwareentwicklung, wo sich Technologien, Anforderungen und Nutzererwartungen schnell &#xE4;ndern.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"verwendung\">Verwendung<\/h2>\n\n\n\n<p>Aus diesem Grund gilt das Wasserfallmodell heute in vielen Bereichen als &#xFC;berholt. Die IT-Industrie hat in den letzten Jahrzehnten eine Vielzahl alternativer Vorgehensmodelle entwickelt, die auf Iteration, Inkrementalisierung und kontinuierlichem Feedback basieren. Dazu geh&#xF6;ren unter anderem agile Methoden wie SCRUM oder Extreme Programming, aber auch strukturiertere Ans&#xE4;tze wie das Spiralmodell oder der Rational Unified Process. Diese Modelle adressieren gezielt die Schw&#xE4;chen des Wasserfallmodells, indem sie kurze Entwicklungszyklen, fr&#xFC;he Prototypen und enge Zusammenarbeit mit dem Kunden f&#xF6;rdern.<\/p>\n\n\n\n<p>Dennoch ist das Wasserfallmodell nicht vollst&#xE4;ndig verschwunden. Es findet weiterhin Anwendung in spezifischen Dom&#xE4;nen, in denen die Rahmenbedingungen seine Struktur beg&#xFC;nstigen. Besonders relevant ist dies im Bereich der &#xF6;ffentlichen Sicherheit, der Verteidigung, der kritischen Infrastruktur sowie in Teilen der Luft- und Raumfahrt. In diesen Bereichen stehen Aspekte wie Nachweisbarkeit, Zertifizierung, Sicherheitsfreigaben und regulatorische Anforderungen im Vordergrund. &#xC4;nderungen m&#xFC;ssen kontrolliert, dokumentiert und nachvollziehbar sein, was iterative und flexible Ans&#xE4;tze erschwert. Hier bietet das Wasserfallmodell eine Struktur, die den formalen Anforderungen entspricht, auch wenn dies auf Kosten von Flexibilit&#xE4;t und Geschwindigkeit geht.<\/p>\n\n\n\n<p>Ein weiterer Grund f&#xFC;r die fortbestehende Nutzung in diesen Bereichen ist die langfristige Planungssicherheit. Projekte im &#xF6;ffentlichen Sektor oder in sicherheitskritischen Anwendungen haben oft lange Laufzeiten und hohe Investitionsvolumina. Eine detaillierte Planung zu Beginn ist notwendig, um Budgets zu rechtfertigen und politische oder organisatorische Entscheidungen abzusichern. Das Wasserfallmodell liefert hierf&#xFC;r ein geeignetes Framework, auch wenn es aus technischer Sicht nicht optimal ist.<\/p>\n\n\n\n<p>In der heutigen Praxis findet man das Wasserfallmodell vor allem noch in traditionell gepr&#xE4;gten und stark regulierten Bereichen wie R&#xFC;stung, Marine, Energiesystemen und klassischen Utilities, also &#xFC;berall dort, wo Projekte langfristig geplant werden, Anforderungen vergleichsweise stabil sind und umfangreiche Dokumentation sowie Nachweisbarkeit gegen&#xFC;ber Beh&#xF6;rden oder Auftraggebern zwingend erforderlich sind. Also alles was bauindustrienah sowie im Umfeld der &#xF6;ffentlichen Hand, insbesondere im Ausschreibungs- und Vergabekontext, zu finden ist. <\/p>\n\n\n\n<p>Dort sind Anforderungen fr&#xFC;h vertraglich fixiert, Leistungen detailliert beschrieben und &#xC4;nderungen mit erheblichem organisatorischem und rechtlichem Aufwand verbunden, wodurch ein sequenzielles, dokumentgetriebenes Vorgehen strukturell beg&#xFC;nstigt wird. Die Trennung von Phasen passt zu klassischen Vergabeverfahren, in denen Spezifikation, Angebot, Umsetzung und Abnahme strikt voneinander getrennt sind. Nicht umsonst f&#xF6;rdern Standards wie <a href=\"https:\/\/www.pickplace.de\/hub\/warum-mil-498-noch-immer-relevant-ist\/\" data-type=\"post\" data-id=\"1484\"><a class=\"glossaryLink\"  aria-describedby=\"tt\"  data-cmtooltip=\"cmtt_618d33d519dcd1a7f02de6b8065e04c1\"  href=\"https:\/\/www.pickplace.de\/glossar\/mil\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>MIL<\/a> 498<\/a> diese stark dokumentenorientierte Herangehensweise.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"zusammenfassung\">Zusammenfassung<\/h2>\n\n\n\n<p>Zusammenfassend l&#xE4;sst sich festhalten, dass das Wasserfallmodell eine historisch bedeutende Rolle in der Entwicklung von Vorgehensmodellen gespielt hat, heute jedoch in vielen Kontexten als nicht mehr zeitgem&#xE4;&#xDF; gilt. Einige Autoren argumentieren sogar &#x201E;<a href=\"https:\/\/mareks-082.medium.com\/the-waterfall-methodology-is-always-bad-a4ece5f61e39\" target=\"_blank\" rel=\"noopener\">The waterfall methodology is always bad<\/a>&#x201E;. Seine St&#xE4;rken liegen in der Strukturierung, Dokumentation und Nachvollziehbarkeit, w&#xE4;hrend seine Schw&#xE4;chen insbesondere in der mangelnden Flexibilit&#xE4;t und der sp&#xE4;ten Fehlererkennung liegen. In modernen Entwicklungsumgebungen, die von Unsicherheit, Komplexit&#xE4;t und schnellen Ver&#xE4;nderungen gepr&#xE4;gt sind, haben sich iterative und adaptive Ans&#xE4;tze weitgehend durchgesetzt. Das Wasserfallmodell bleibt jedoch in bestimmten Nischen relevant, vor allem dort, wo formale Prozesse, regulatorische Anforderungen und stabile Rahmenbedingungen eine gr&#xF6;&#xDF;ere Rolle spielen als Geschwindigkeit und Anpassungsf&#xE4;higkeit.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Das Wasserfallmodell ist ein klassisches, lineares Vorgehensmodell im Projektmanagement und insbesondere in der Software- und Systementwicklung, das auf einer strikt sequenziellen Abarbeitung von Projektphasen basiert. Der grundlegende Gedanke besteht darin, dass ein Entwicklungsprozess in klar voneinander abgegrenzte Phasen unterteilt wird, die jeweils vollst\u00e4ndig abgeschlossen sein m\u00fcssen, bevor die n\u00e4chste beginnt. Typischerweise umfasst dieser Ablauf die [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"menu_order":0,"template":"","meta":{"footnotes":""},"class_list":["post-1979","glossary","type-glossary","status-publish","hentry"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1979","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary"}],"about":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/types\/glossary"}],"author":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":3,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1979\/revisions"}],"predecessor-version":[{"id":1985,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1979\/revisions\/1985"}],"wp:attachment":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/media?parent=1979"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}