Der Entwicklungsprozess gliedert die Arbeit in Phasen. Jede Phase beantwortet eine Frage und liefert ein Ergebnis:

Die Reihenfolge gilt als Grundgerüst. Wie oft und in welcher Ordnung man die Phasen durchläuft, bestimmt das Vorgehensmodell (unten).

Das Lastenheft schreibt der Auftraggeber. Es beschreibt, was die Software leisten soll und wofür, ohne die technische Umsetzung. Das Pflichtenheft schreibt der Auftragnehmer auf dieser Grundlage. Es legt fest, wie und womit die Anforderungen umgesetzt werden, und dient als Grundlage des Vertrags. Funktionale Anforderungen nennen Funktionen („zeige den Plan einer Klasse“), nichtfunktionale nennen Eigenschaften wie Antwortzeit, Datenschutz oder Bedienbarkeit.

Agile Teams schreiben Anforderungen oft als User Story: „Als [Rolle] möchte ich [Ziel], damit [Nutzen].“ Dazu gehören Akzeptanzkriterien, an denen man prüft, ob die Story erfüllt ist. Ein Prototyp ist eine früh gebaute, unvollständige Version, etwa eine Skizze auf Papier oder ein Klickmodell. Nutzer probieren ihn aus, und man erkennt früh, ob die Anforderungen richtig verstanden wurden.

Ein Vorgehensmodell legt fest, in welcher Ordnung die Phasen durchlaufen werden.

• Wasserfallmodell: Die Phasen laufen nacheinander, jede wird abgeschlossen, bevor die nächste beginnt. Stärke: klare Planung und Dokumente, gut bei festen, gut verstandenen Anforderungen. Schwäche: Fehler der Analyse fallen spät auf, der Kunde sieht das Produkt erst am Ende.
• Iteratives (inkrementelles) Vorgehen: Die Phasen werden mehrfach durchlaufen. Jede Runde liefert ein lauffähiges Stück, das Inkrement, und die Software wächst. Rückmeldungen kommen früh.
• Spiralmodell: iterativ mit Risikoanalyse. Jeder Umlauf legt Ziele fest, bewertet Risiken (oft mit einem Prototyp), entwickelt und testet und plant den nächsten Umlauf. Es passt zu großen Projekten mit hohen Risiken.
• Agile Vorgehensweisen, zum Beispiel Scrum: Kurze Zyklen (Sprints, höchstens ein Monat, oft zwei Wochen) und ein selbstorganisiertes Team. Die Wünsche stehen als User Stories im Product Backlog, der Product Owner setzt Prioritäten, der Scrum Master hilft dem Team bei der Arbeitsweise. Nach jedem Sprint gibt es ein nutzbares Inkrement, das mit dem Kunden besprochen wird. Anforderungen dürfen sich ändern.

Ein Projekt hat ein Ziel, einen Anfang und ein Ende und begrenzte Mittel. Die Planung zerlegt die Arbeit in Arbeitspakete, ordnet sie zeitlich und setzt Meilensteine, also überprüfbare Zwischenziele. Zur Organisation gehören Rollen (Projektleitung, Entwicklung, Test, Kunde), feste Treffen und eine Aufwandsschätzung.

Agile Teams schätzen User Stories in Story Points, einer relativen Größe: Eine Story mit 5 Punkten gilt als etwa 2,5-mal so aufwendig wie eine mit 2 Punkten. Die Velocity ist die Zahl der Story Points, die das Team in einem Sprint tatsächlich schafft. Sie dient dazu, die Dauer des Projekts abzuschätzen.

Software hat einen Lebenszyklus: Planung und Entwicklung, Einführung und Betrieb, Wartung und Pflege (Fehler beheben, an neue Bedingungen anpassen, erweitern) und schließlich die Ablösung. Wartung dauert oft Jahre und verursacht häufig den größten Teil der Gesamtkosten. Deshalb lohnen sich ein gutes Pflichtenheft, ein sauberer Entwurf und eine verständliche Dokumentation schon bei der Entwicklung.