Softwareentwicklungsprozess: So läuft ein Projekt ab

Wer schon einmal einen Softwareentwicklungsprozess durchlaufen hat, weiß, dass das Problem selten technisch ist. Es liegt bei den Entscheidungen. Eine Frage, die drei Wochen unbeantwortet bleibt, kostet drei Wochen, unabhängig von der Teamgröße.

Ein Individualsoftware-Projekt hat vier Momente, die zählen: Discovery, iterative Entwicklung, Abnahme und Go-live. Alles andere im Softwareentwicklungsprozess ist eine Frage der Methode. Die Discovery definiert das Problem und den Umfang. Die Entwicklung läuft in kurzen Zyklen, die jeweils mit funktionierender Software enden. Bei der Abnahme entscheidet jemand auf Kundenseite, ob das Gebaute seinen Zweck erfüllt. Der Go-live beginnt das Leben des Systems, statt das Projekt zu beenden.

Dieser Artikel beschreibt, was im Softwareentwicklungsprozess zwischen Unterschrift und Go-live tatsächlich passiert. Es geht nicht um die Wahl des Anbieters, die eine frühere und andere Entscheidung ist. Es geht darum, was Sie erwarten können, wenn diese Wahl getroffen ist.

Dauer	Projekt	Typischer Umfang
1–3 Monate	Eng abgegrenztes MVP	Ein Hauptablauf, ein Nutzerprofil, keine komplexen Integrationen
3–6 Monate	Mittleres Projekt	Mehrere Module, ein oder zwei Integrationen, getrennte Zugriffsrollen
6–12 Monate	Großes Projekt	Datenmigration, mehrere Integrationen, Audit-Anforderungen
12–24 Monate	Enterprise-Plattform	Ablösung produktiver Systeme, Phasenplanung ist Pflicht

Die Variable, die Zeitpläne am stärksten dehnt, steckt in keiner dieser Spannen: wie schnell Entscheidungen von der Kundenseite kommen.

Was passiert, bevor jemand Code schreibt?

Die Discovery, und sie ist der einzige Teil des Projekts, in dem Meinungsänderungen noch billig sind. Meist zwei bis vier Wochen. Das Ziel ist nicht, Dokumentation zu erzeugen. Es geht darum, eine kleine Zahl von Fragen so genau zu beantworten, dass man darauf aufbauen kann.

1
Was genau ist das Problem? Nicht „wir wollen den Prozess digitalisieren“, sondern welcher Prozess, ausgeführt von wem, mit welchen Schritten und was heute nicht funktioniert.
2
Wer nutzt das und in welchem Kontext? Ein geschulter interner Nutzer und ein Endkunde ohne jede Schulung führen zu unterschiedlichen Oberflächen.
3
Mit welchen Systemen kommuniziert es? Jede Integration braucht einen Namen, einen Verantwortlichen, Dokumentation und eine Person, die Zugriff gewähren kann. Integrationen ohne benannten Verantwortlichen sind ein Terminrisiko.
4
Welche Daten gibt es und in welchem Zustand? Hier hört die Migration auf, eine Zeile im Lastenheft zu sein, und bekommt ihre tatsächliche Größe.
5
Was muss erfüllt sein, damit das live gehen kann? Gesetzliche Anforderungen, interne Freigaben, Schulungen, Wartungsfenster.

Die Discovery endet mit einem schriftlichen Umfang, einer vorgeschlagenen Architektur, einer Schätzung mit ausgewiesenen Annahmen und einer Risikoliste. Fehlt eines dieser vier Dinge, ist die Discovery nicht abgeschlossen. Es lohnt sich, sie separat zu kaufen: Eine bezahlte Discovery mit dem Anbieter, den Sie in Betracht ziehen, kostet einen Bruchteil des Projekts und liefert auch dann etwas Brauchbares, wenn Sie nicht weitermachen, nämlich einen schriftlichen Umfang, den Sie anderswo verwenden können. Sie ist außerdem der günstigste Weg herauszufinden, ob das Team das Problem versteht, bevor ein Sechsmonatsvertrag auf dem Tisch liegt.

Wie ist der Softwareentwicklungsprozess nach dem Kick-off organisiert?

In kurzen Zyklen von ein bis drei Wochen, die jeweils mit Software enden, die funktioniert und gezeigt werden kann. Das ist keine methodische Vorliebe. Es ist Risikomanagement. Ein Zweiwochenzyklus bedeutet, dass sich höchstens zwei Wochen Fehler unbemerkt ansammeln können. Ein Projekt, das bis zum sechsten Monat nichts zeigt, sammelt sechs Monate Missverständnisse an, bevor es jemand bemerkt.

Was ein Zyklus enthält

Planung

Auswahl dessen, was in den Zyklus kommt, aus einer priorisierten Liste, mit dem Verantwortlichen des Kunden im Raum

›

Entwickeln

Entwicklung, Code-Review und automatisierte Tests, verantwortet vom technischen Team

›

Demo

Das Gebaute wird beiden Seiten funktionierend gezeigt, wo möglich mit echten Nutzern

›

Anpassung

Die Prioritätenliste wird mit dem Gelernten neu geordnet, und der Verantwortliche des Kunden legt die Reihenfolge fest

Der Teil, der meist fehlt, ist der letzte. Eine Prioritätenliste, die sich nie ändert, bedeutet, dass niemand aus dem bereits Gelieferten lernt, und damit geht die Hälfte des Nutzens von Zyklen verloren. Außerdem müssen drei Rollen benannten Personen statt Abteilungen zugeordnet werden: eine Person auf Kundenseite, die Prioritäten setzt und Lieferungen abnimmt, jemand für die Architektur mit der Befugnis, Nein zu sagen, und jemand, der auf beiden Seiten für die Zugänge zuständig ist.

Sie bereiten ein Projekt vor? Schicken Sie uns das Problem statt des Lastenhefts.

Mit unserem Team sprechen →

Wo entgleist der Softwareentwicklungsprozess?

Fünf Fehler im Softwareentwicklungsprozess, grob nach Häufigkeit geordnet. Keiner davon ist technisch.

Anforderungen, die sich ändern, ohne dass etwas wegfällt. Hinzufügen ist normal. Das Problem ist Hinzufügen, ohne etwas zu streichen, bei gleichem Termin. Die richtige Frage ist nicht „Können wir das aufnehmen?“, sondern „Was ersetzt das?“.

Zugänge, die nicht kommen. Die Testumgebung eines Drittanbieters braucht sechs Wochen bis zur Freigabe, und niemand hat am Anfang danach gefragt. Das Team wartet, die Kosten laufen weiter.

Abnahme ohne definierte Kriterien. Wenn „fertig“ nicht vor dem Bau der Funktion schriftlich festgelegt ist, findet der Streit darüber, ob sie fertig ist, danach statt, und beide Seiten sind sicher, recht zu haben.

Echte Daten, die zu spät kommen. Das System läuft mit Testdaten und bricht mit Produktivdaten, weil Produktivdaten zwanzig Jahre undokumentierter Ausnahmen mitbringen. Echte Daten früh zu laden ist die günstigste Absicherung, die es gibt.

Der Betrieb als letztes Detail. Monitoring, Backups, Zugriffsverwaltung, Wiederherstellungsplan. Wer das auf die letzte Woche verschiebt, macht aus einer Auslieferung einen Notfall.

Was bedeutet „fertig“ und wer entscheidet?

Fertig heißt, dass die Funktion ein Kriterium erfüllt, das vor ihrem Bau geschrieben wurde, und dass jemand auf Kundenseite schriftlich bestätigt hat, dass sie es erfüllt. Ein brauchbares Abnahmekriterium ist so konkret, dass es überprüfbar ist. „Der Nutzer kann das Formular absenden“ reicht nicht. „Ein Nutzer mit der Rolle Manager kann das Formular mit ausgefüllten Pflichtfeldern absenden, erhält eine Bestätigung, und der Datensatz erscheint in weniger als zwei Sekunden in der Liste“ ist überprüfbar.

Es gibt eine zweite Ebene, die oft mit der ersten verwechselt wird. Eine Funktion kann fachlich abgenommen und trotzdem nicht produktionsreif sein, weil Testabdeckung, Dokumentation oder Fehlerbehandlung fehlen. In regulierten Branchen sind Qualitätsnachweise nicht optional: Bei einem Audit wird jemand nach dem Testbericht fragen.

Was passiert am Tag der Auslieferung und danach?

Der Go-live ist ein Datum, kein Endzustand. Die drei Wochen rund um dieses Datum umfassen meist die finale Datenmigration, Nutzerschulungen, eine Phase verstärkten Supports und die Behebung der ersten Welle von Problemen, die erst im echten Einsatz auftauchen. Diese Welle kommt immer, und ein Plan, der sie nicht vorsieht, ist schlecht geplant.

Danach geht das System in den normalen Betrieb über, und der kostet Geld. Öffentliche Referenzen setzen die jährliche Wartung bei 15 bis 20 Prozent der Entwicklungskosten an, dazu kommen 200 bis 1.500 € pro Monat für Hosting und Infrastruktur. Dieses Budget kauft keine neuen Funktionen. Es kauft aktualisierte Abhängigkeiten, Sicherheitskorrekturen, Kompatibilität mit sich ändernden Betriebssystemen und mit gesetzlichen Anforderungen, die sich ebenfalls ändern.

Am Tag der Auslieferung ist zu entscheiden, wer diese Arbeit macht: das Team, das gebaut hat, ein internes Team, das den Code übernimmt, oder ein gemischtes Modell. Jedes davon funktioniert. Keines funktioniert, wenn die Entscheidung erst sechs Monate später fällt, wenn sich niemand mehr erinnert, warum dieses Modul so gebaut wurde.

Welche Rolle spielt KI im Softwareentwicklungsprozess?

Eine echte Rolle beim Bauen und keine beim Entscheiden. Laut dem Tech Talent Trends Report 2026, dem Branchenbericht von Landing.Jobs, nutzen bereits 54 Prozent der Entwickler KI-Werkzeuge in ihrem regulären Arbeitsablauf, was das Schreiben von Code, das Erzeugen von Tests und das Ausloten technischer Alternativen beschleunigt.

Was sich nicht ändert, ist alles, was dieser Artikel als den schwierigen Teil beschreibt. Die Discovery hängt weiterhin davon ab, dass jemand das Problem erklären kann. Die Abnahme hängt weiterhin davon ab, dass jemand entscheidet. Die Datenmigration braucht weiterhin eine menschliche Entscheidung darüber, was verloren geht. Projekte scheitern an diesen Dingen, nicht daran, wie schnell Code getippt wird.

Wie bereitet sich ein Kunde auf den Softwareentwicklungsprozess vor?

Die meisten Verzögerungen in einem Projekt gehen auf etwas zurück, das der Kunde vor dem Kick-off hätte vorbereiten können. Nichts davon ist technisch. Alles davon ist günstiger, wenn man es früh regelt.

Benennen Sie eine Person, die entscheiden kann. Kein Gremium und niemand, der jedes Mal bei einem Gremium nachfragen muss. Fragen zum Umfang kommen jede Woche. Das Projekt bewegt sich im Tempo der Antworten.

Geben Sie dem Team Zugang zu echten Nutzern. Zehn Minuten mit den Menschen, die das System jeden Tag nutzen werden, klären Fragen, die ein Anforderungsdokument wochenlang offenlässt.

Listen Sie auf, was schon existiert. Die Systeme, mit denen die neue Software kommunizieren muss, die Daten, die migriert werden müssen, und die Personen, die jeweils dafür verantwortlich sind. Integrationen, die erst mitten in der Entwicklung auftauchen, sind die häufigste Ursache ungeplanter Kosten.

Reservieren Sie die Zeit für Reviews im Voraus. Jeder Entwicklungszyklus endet mit einer Demonstration, bei der jemand aus dem Fachbereich anwesend sein muss. Tragen Sie diese Termine beim Kick-off ein, bevor andere Verpflichtungen sie belegen.

Ein Kunde, der mit diesen vier Dingen vorbereitet kommt, verkürzt die Discovery in der Regel um Wochen. Der Softwareentwicklungsprozess wird nicht schneller, weil das Team härter arbeitet. Er wird schneller, weil weniger Fragen auf eine Antwort warten.

Häufige Fragen

Zeitplan und Phasen im Softwareentwicklungsprozess

Wie lange dauert die Entwicklung individueller Software?

Öffentliche Referenzen nennen 1 bis 3 Monate für ein eng abgegrenztes MVP, 3 bis 6 Monate für ein mittleres Projekt, 6 bis 12 Monate für ein großes und 12 bis 24 Monate für eine Enterprise-Plattform. Die Entscheidungsgeschwindigkeit auf Kundenseite beeinflusst den Zeitplan genauso stark wie der technische Aufwand.

Was ist die Discovery-Phase und ist sie wirklich nötig?

Sie ist die Anfangsphase, meist zwei bis vier Wochen, in der Problem, Umfang, Architektur und Risiken definiert werden, bevor es Code gibt. Sie ist der einzige Zeitpunkt, an dem Meinungsänderungen billig sind, und sie liefert einen schriftlichen Umfang, der auch dann nützlich bleibt, wenn Sie einen anderen Anbieter wählen.

Entscheidungen und Abnahme

Wer entscheidet, was in jede Projektphase kommt?

Eine benannte Person auf Kundenseite mit der Befugnis, Prioritäten zu setzen und Lieferungen abzunehmen. Gremien entscheiden langsam und ändern ihre Position zwischen den Sitzungen, was die häufigste Ursache für Verzögerungen ohne technischen Grund ist.

Was bedeutet es, dass eine Funktion fertig ist?

Dass sie ein Abnahmekriterium erfüllt, das vor ihrem Bau geschrieben wurde und objektiv überprüfbar ist, und dass jemand auf Kundenseite das bestätigt hat. In regulierten Branchen gilt eine zweite Ebene: Testabdeckung und Dokumentation, die einem Audit standhalten.

Nach dem Go-live und kommerzielle Bedingungen

Was passiert, nachdem die Software live gegangen ist?

Eine Phase verstärkten Supports für die erste Welle echter Probleme, danach der normale Betrieb des Systems. Öffentliche Referenzen setzen die jährliche Wartung bei 15 bis 20 Prozent der Entwicklungskosten an, noch ohne neue Funktionen.

Festpreis oder Aufwand?

Ein Festpreis funktioniert, wenn der Umfang abgeschlossen ist und sich nicht bewegt, was bei Individualsoftware selten ist. Abrechnung nach Aufwand funktioniert dort, wo Vertrauen und Transparenz über die geleistete Arbeit bestehen. Die häufigste Mischform ist ein Festpreis für die Discovery und eine eng begrenzte erste Phase, danach Abrechnung nach Aufwand.

Team Caixa Mágica

Caixa Mágica Software ist ein portugiesisches Softwareunternehmen mit über 20 Jahren Erfahrung in Individualsoftware, KI-Lösungen und Nearshore-Entwicklungsteams für europäische Unternehmen.

Softwareentwicklung · Caixa Mágica Software

Sprechen Sie mit einem Team, das liefert und danach wartet

Wir entwickeln Individualsoftware für portugiesische und europäische Kunden und begleiten Systeme im Betrieb über Jahre mit demselben Kunden. Wenn Sie ein Projekt vorbereiten, schicken Sie uns das Problem statt des Lastenhefts. Sie erhalten ein Discovery-Angebot mit dem Umfang, den wir in zwei bis vier Wochen abschließen können.

Individuelle Softwareentwicklung Gespräch beginnen