Das Qualitätsmanagement begleitet parallel den gesamten Entwicklungsprozess .

Siehe auch: Wasserfallmodell

Die einzelnen Phasen der Softwareentwicklung sind niemals getrennt voneinander zu betrachten und stellen idealisierte Einzelmodule dar. In der Realität finden sich dynamische Abfolgen, Vorgehensmodelle (engl. Software development process ), die die einzelnen Phasen – u. U. mit kleinen Modifikationen – einmal (z. B. Wasserfallmodell) oder meistens mehrmals durchlaufen (z. B. Spiralmodell). Bei mehrmaligen Durchläufen erfolgt eine iterative Verfeinerung der einzelnen Softwarekomponenten. Um die best practice oder 'optimalen' Vorgehensmodelle werden teilweise Glaubenskriege ausgefochten. Zweifellos verhält es sich so, dass je statischer und eindimensionaler die Betrachtungsweise, desto weniger hat sie mit der Praxis der Programmierung zu tun.

Weitere Modelle neben den schon genannten zwei sind:

• V-Modell
• Rational Unified Process
• Extreme Programming
• Top-Down- und Bottom-Up-Design
• Chaosmodell
• (Rapid) Prototyping
• Evolutionäres Prototyping
• Iterative und Inkrementelle Entwicklung / Spiralmodell

Nicht alle diese Modelle umfassen den vollständigen Entwicklungszyklus!

Es existieren verschieden Bewertungsverfahren für den Softwareprozess, u. a. das Capability Maturity Model oder Spice

Es ist umstritten, ob der Entstehungsprozess von Software so gut verstanden wird, dass eine "ingenieurmäßige Herstellung" möglich ist: Kritiker argumentieren, dass Software nichts anderes sei als "ausführbares Wissen ". Wissen jedoch lässt sich nicht ingenieursmäßig herstellen (wie sich etwa eine Brücke oder ein Hochhaus herstellen lässt), sondern wird in einem kreativen Prozess gefunden. Eine Richtung der Softwaretechnik (Agile Software-Entwicklung) beschäftigt sich daher mit sehr flexiblen Methoden, die die Kreativität des einzelnen Entwicklers betonen und Verwaltungsaspekte in den Hintergrund treten lassen.

Kritiker argumentieren, dass besonders die heftig diskutierten Vorgehensmodelle (Wasserfallmodell, V-Modell etc.) und Modellierungssprachen (UML) in der Softwaretechnik-Wissenschaft den behelfsmäßigen, unterstützenden ad-hoc-Charakter verdecken und den Entwicklungsprozess unnötig bürokratisieren. Diese Methoden hemmen, so die Kritiker, dadurch Kreativität und Problemlösungskapazität des Entwicklers.

Struktogramme und ähnliche Werkzeuge werden in der Praxis ca. selten benutzt. Wenn, dann für Ausschnitte aus dem Problem aber nicht für eine Modellierung des gesamten Projektes. In dem Bereich hat sich jedoch UML als praxistauglicher erwiesen und wird von Entwicklern häufig benutzt.

Es ist umstritten, ob die Softwarekrise durch Softwaretechnik oder vielmehr durch robustere, strukturiertere Programmiersprachen und Entwicklungswerkzeuge gelöst werden kann.