Die mit dem Begriff Prozessparadigma bezeichneten allgemeinen Vorgehensmodelle im Software Engineering basieren auf Erkenntnissen und Beobachtungen, die im Zuge der Durchführung von industriellen Softwareprojekten gemacht wurden.
Das in untenstehender Abbildung dargestellte Wasserfallmodell wurde 1970 von Royce beschrieben und ist das älteste Prozessparadigma. Grundidee hinter dem Wasserfallmodell ist die schrittweise Bearbeitung der einzelnen Phasen Anforderungen, Analyse, Entwurf, Implementierung, Test und Betrieb in einer festgelegten Reihenfolge. Wie in einem Wasserfall "fällt" ein Softwareprojekt der Reihe nach von "oben nach unten". Jede einzelne Phase wird vollständig fertiggestellt, erst dann geht es weiter zur nächsten Phase. Zwischen benachbarten Phasen gibt es die Möglichkeit der Rückkopplung. Falls Fehler gefunden werden oder es mit dem Ergebnis einer Phase in der nachfolgenden Phase Probleme gibt, kann der Softwareprozess wieder um eine Phase zurückgehen. So können sich benachbarte Phasen im Problemfall mehrfach hintereinander abwechseln.
Mit dem Wasserfallmodell wurde den bis dahin oft unstrukturierten Softwareprojekten eine feste Struktur gegeben. Neben der strikten Trennung der einzelnen Phasen, legt es großen Wert auf vollständige und aktuelle Dokumentation. Ein Phasenübergang kann nur stattfinden, wenn die Ergebnisse einer Phase vollständig und ausführlich dokumentiert sind und erfolgreich qualitätsgesichert wurden.
Aus Managementsicht hat das Wasserfallmodell den Vorteil, dass der Softwareprozess in klare Phasen mit definierten Ergebnissen gegliedert ist.
Somit lassen sich zum einen klare organisatorische Zuständigkeiten festlegen und zum anderen der aktuelle Zustand und der
Projektfortschritt überwachen. Insbesondere in verteilten Projekten, in denen mehrere Organisationen an mehreren Standorten
zusammenarbeiten, lassen sich die Aufgabenbereiche klar gliedern. Durch die Einforderung der umfassenden und vollständigen Dokumentation
der Ergebnisse können Übergabepunkte zwischen einzelnen Organisationen vertraglich festgelegt werden.
Jedoch steht die Festlegung einer starren Reihenfolge vollständig abzuschließender Aktivitäten komplett entgegengesetzt zur Natur der Erkenntnisgetriebenheit von Softwareprojekten. Obwohl es vielfach gefordert wird, lassen sich Anforderungen an industrielle Informationssysteme nicht zu Beginn eines Softwareprozesses vollständig beschreiben. Alle weiteren Aktivitäten bis hin zur Implementierung dienen implizit der Klärung von entweder bis dahin unbekannten oder noch nicht vollständig klaren Anforderungen. Außerdem verhindert eine strikte Einhaltung des Wasserfallmodells den Start von Nachfolgephasen von bereits fertiggestellten, einzelnen Elementen. Selbst wenn zum Beispiel ein Großteil, jedoch nicht das ganze System spezifiziert ist, darf nach dem Wasserfallmodell noch nicht mit der Architektur oder der Implementierung begonnen werden. Weiterhin sorgen die Maßnahmen zur Qualitätssicherung der vollständig dokumentierten Ergebnisse der einzelnen Phasen dafür, dass zwischen Fertigstellung des Ergebnisses und dem Weiterarbeiten erst auf den Abschluss der Prüfung gewartet werden muss.
Aus heutiger Sicht sollte das Wasserfallmodell bei der Erstellung von Softwareprozessmodellen für industrielle Informationssysteme nur als grobe Orientierungshilfe eingesetzt werden. Insbesondere die Forderung nach klar abgetrennten Phasen und der Konzentration auf eine zu jeder Zeit vollständigen Dokumentation führen in der Praxis oft dazu, dass mit viel Aufwand große Dokumente erstellt und geprüft werden, die jedoch mit den erlangten Erkenntnissen der nächsten Phase schnell überaltern und nicht mehr aktuell sind.
Das Prozessparadigma "V-Modell" wurde gegen Ende der 1970er Jahre entwickelt und ist eine Basis verschiedener Softwareprozessmodelle
im öffentlichen Sektor. Der Grundgedanke des V-Modells ist wie in folgender Abbildung dargestellt die 1:1 Zuordnung von konstruktiven
Phasen (linke Hälfte im V) und zu prüfenden Phasen (rechte Hälfte im V).
Der Weg durch den Softwareprozess ergibt sich aus der Reihenfolge der festgelegten Phasen. Begonnen mit der fachlichen Anforderungsanalyse werden wie im Wasserfallmodell die Software Engineering Kernaktivitäten bis zur fertigen Konstruktion des Softwaresystems durchgeführt. Anschließend bewegt sich das Softwareprojekt über verschiedene Teststufen hinweg bis hin zur Abnahme des Systems. Jeder Phase der Konstruktion wird dabei eine konkrete Teststufe zugeordnet, die sich auf der gleichen Detaillierungsebene befindet wie die konstruktive Phase. Wie beim Wasserfallmodell gilt auch für das V-Modell, dass die Vorgängerphase erfolgreich abgeschlossen werden muss. Bevor also mit den Integrationstests begonnen werden kann, müssen die Unit-Tests alle abgeschlossen sein.
Das Prozessparadigma "evolutionäre Entwicklung" bezeichnet ein allgemeines Vorgehensmodell, dessen Grundidee die Erstellung des Softwaresystems in mehreren sich wiederholenden Zyklen ist. Mit jeder Version wächst der Funktionsumfang des zu erstellenden Softwaresystems. Erkenntnisse, die bei der Umsetzung und der Bewertung der aktuellen Version gewonnen werden, können in den folgenden System-Versionen berücksichtigt werden. Die folgende Abbildung illustriert ein allgemeines Schema der evolutionären Entwicklung. Statt den Fokus auf vollständige Dokumente und Spezifikationen zu legen, steht hier eine Version lauffähige Software im Vordergrund. Ein Zyklus läuft dabei wie folgt ab:
Im Gegensatz zum Wasserfallmodell fällt der Softwareprozess bei der evolutionären Entwicklung nicht strikt entlang der Kernaktivitäten des Software Engineerings einmal "von oben nach unten". Bei der evolutionären Entwicklung "dreht sich" der Softwareprozess "im Kreis" um ein fertiges Stück Software. Die Software Engineering Kernaktivitäten werden hierbei nicht am Stück (in einer Phase) jeweils vollständig durchgeführt und dokumentiert, sondern kleinteiliger und miteinander verzahnt in jedem Zyklus ein bisschen.
Somit berücksichtigt die evolutionäre Entwicklung, dass viele Erkenntnisse zu Anforderungen und technologischen Lösungsansätzen erst während der Softwareentwicklung gewonnen werden können. In jedem neuen Zyklus können die neuen Erkenntnisse direkt eingebracht werden. Darüber hinaus können Fehler und Ungenauigkeiten in der Spezifikation oder dem Programmcode schnell erkannt und behoben werden. Ein weiterer Vorteil der evolutionären Entwicklung ist die schnelle Verfügbarkeit eines grundsätzlich lauffähigen Systems. Selbst wenn noch nicht alle Funktionen vollständig umgesetzt sind, gibt es jedoch schon ein in Teilen einsetzbares Ergebnis.
Da es im Vergleich zum Wasserfallmodell keine ganz klar abgegrenzten Phasen mit fest definierten Ergebnissen gibt, sondern sich alle Software Engineering Kernaktivitäten kleinteilig in kurzen Zyklen wiederholen, wird zu Beginn des Softwareprozesses keine vollständige Spezifikation erstellt. Das bedeutet, dass der konkrete Funktionsumfang des Systems erst während der Entwicklung genau festgelegt wird. Daher erscheint die evolutionäre Entwicklung aus Sicht des Managements unstrukturiert und ohne klar definiertes Ergebnis. Mit dem auf der Erstellung eines lauffähigen Softwaresystems liegenden Hauptaugenmerk besteht das Risiko, schnell Programmcode zu erzeugen und die notwendige Evolution der Systemarchitektur und die begleitenden Architektur- und System-Dokumentationen zu vernachlässigen, sodass man bereits während der initialen Entwicklung mit den im Kapitel Weiterentwicklung genannten Herausforderungen konfrontiert ist.
In der Literatur wird noch das Prozessparadigma Spiralmodell genannt.