Entwicklungsprozess
Zwischen einer Idee und einem funktionierenden System liegen dutzende Entscheidungen: Wer baut was, in welcher Reihenfolge, mit welchen Prüfungen? Der Entwicklungsprozess gibt diesem Weg eine Struktur. In der Softwareentwicklung beschreibt er den gesamten Ablauf von der ersten Anforderung bis zum laufenden Betrieb.
Was ein Entwicklungsprozess regelt
Ein Entwicklungsprozess definiert Phasen, Rollen und Übergabepunkte für die Erstellung von Software. Er legt fest, wann Anforderungen erhoben werden, wann Code entsteht, wann getestet wird und wie das Ergebnis in den Betrieb gelangt. Ohne diese Struktur entstehen typische Probleme: Doppelarbeit, verspätete Fehlersuche und Ergebnisse, die an den tatsächlichen Anforderungen vorbeigehen.
Beispiel: Ein Team aus fünf Entwicklern arbeitet an einer Webanwendung. Ohne definierten Prozess schreibt jeder Code nach eigenem Ermessen. Bei der Integration am Ende des Monats kollidieren Änderungen, Tests fehlen, und das Deployment scheitert. Mit einem definierten Prozess gibt es feste Zeitpunkte für Integration, automatisierte Tests und Review-Schritte.
Beispiel: Ein Startup entwickelt eine mobile App. Die Anforderungen ändern sich wöchentlich. Ein starrer Prozess mit monatelangen Planungsphasen würde das Team ausbremsen. Ein iterativer Prozess mit Zwei-Wochen-Zyklen erlaubt schnelle Anpassung an neue Erkenntnisse.
Die Kernphasen in den meisten Prozessmodellen sind: Anforderungsanalyse, Entwurf (Design), Implementierung, Test und Deployment. Die Reihenfolge und Gewichtung dieser Phasen unterscheidet sich je nach Modell erheblich.
Sequenzielle und iterative Modelle
Das bekannteste sequenzielle Modell ist das Wasserfallmodell. Jede Phase wird vollständig abgeschlossen, bevor die nächste beginnt. Anforderungen werden zu Beginn festgelegt und gelten als stabil. Das funktioniert bei Projekten mit klaren, unveränderlichen Vorgaben. Bei den meisten Softwareprojekten ist diese Annahme unrealistisch.
Beispiel: Die Entwicklung einer Steuerungssoftware für ein medizinisches Gerät folgt oft einem sequenziellen Modell. Die Anforderungen sind durch Regulierung vorgegeben, Änderungen erfordern erneute Zulassung. Hier ist die Starrheit des Wasserfalls ein Vorteil: Sie erzwingt vollständige Dokumentation und lückenlose Nachverfolgbarkeit.
Iterative Modelle wie Scrum oder Kanban setzen auf kurze Zyklen. Am Ende jedes Zyklus steht ein lauffähiges Inkrement. Feedback fließt direkt in den nächsten Zyklus ein. Der agile Ansatz akzeptiert, dass sich Anforderungen ändern, und macht diese Änderungen zum Bestandteil des Prozesses.
Beispiel: Ein E-Commerce-Unternehmen entwickelt eine Empfehlungsfunktion. Im ersten Sprint entsteht ein Prototyp mit einfacher regelbasierter Logik. Nach dem Nutzertest zeigt sich, dass die Nutzer andere Filterkriterien erwarten. Im nächsten Sprint wird die Logik angepasst. Ein Wasserfallmodell hätte die Fehleinschätzung erst nach Monaten sichtbar gemacht.
Fachliche Einordnung: Die Unterscheidung zwischen sequenziellen und iterativen Modellen ist eine Vereinfachung. In der Praxis kombinieren die meisten Organisationen Elemente aus beiden Ansätzen. Das Scaled Agile Framework (SAFe) etwa verbindet agile Teamzyklen mit planungsgetriebenen Programminkrementen. Die Wahl des Modells hängt von Faktoren wie Teamgröße, regulatorischen Anforderungen und Komplexität der Domäne ab.
Rollen und Verantwortlichkeiten
Jeder Entwicklungsprozess verteilt Verantwortung auf definierte Rollen. Die Aufteilung variiert je nach Modell, aber bestimmte Funktionen tauchen in fast jedem Prozess auf: jemand sammelt und priorisiert Anforderungen, jemand entwirft die Architektur, jemand schreibt Code, jemand prüft die Qualität.
Beispiel: In einem Scrum-Team übernimmt der Product Owner die Priorisierung der Anforderungen. Er entscheidet, welche Funktion als nächstes umgesetzt wird. Das Entwicklungsteam entscheidet, wie die Umsetzung technisch erfolgt. Der Scrum Master sorgt dafür, dass der Prozess eingehalten wird. Ohne diese Trennung entsteht häufig ein Zustand, in dem technische Entscheidungen von fachfremden Personen getroffen werden.
Beispiel: In einem DevOps-Team verschmelzen Entwicklung und Betrieb. Dieselben Personen schreiben Code und betreiben die Infrastruktur. Das verändert den Entwicklungsprozess grundlegend: Deployment wird kein einmaliges Ereignis am Projektende, sondern ein täglicher, automatisierter Vorgang.
Die Rollenverteilung beeinflusst direkt die Qualität des Ergebnisses. Wenn niemand explizit für Testabdeckung verantwortlich ist, sinkt sie erfahrungsgemäß innerhalb weniger Monate auf ein Niveau, das Fehler in der Produktion wahrscheinlich macht.
Besonderheiten bei KI-Projekten
Bei Projekten mit Machine Learning weicht der Entwicklungsprozess in mehreren Punkten von klassischer Softwareentwicklung ab. Die Anforderungsphase arbeitet mit Hypothesen statt mit festen Spezifikationen. Ob ein Modell eine bestimmte Aufgabe lösen kann, steht nicht vorab fest. Es muss experimentell ermittelt werden.
Beispiel: Ein Unternehmen will automatisch Rechnungen klassifizieren. Die Anforderung lautet: Genauigkeit über 95 Prozent. Ob das erreichbar ist, hängt von der Datenqualität ab. Die ersten Wochen des Projekts bestehen aus Datenanalyse, Labelprüfung und Baseline-Experimenten. Erst danach zeigt sich, ob die Anforderung realistisch ist.
Die Implementierungsphase bei KI-Projekten umfasst neben dem Anwendungscode auch Datenpipelines, Fine-Tuning-Schritte und Evaluierungslogik. Fehler in den Trainingsdaten wirken sich oft stärker aus als Fehler im Code. Ein einzelnes falsch gelabeltes Beispiel kann bei kleinen Datensätzen das Modellverhalten messbar verändern.
Beispiel: Ein Textklassifikator wird mit 500 Beispielen trainiert. 20 Beispiele sind falsch gelabelt. Das Modell lernt die falschen Zuordnungen und verhält sich im Betrieb unvorhersehbar. Ein klassischer Unit-Test findet diesen Fehler nicht, weil der Code fehlerfrei ist. Erst eine systematische Datenprüfung im Prozess deckt das Problem auf.
Die Testphase erfordert bei KI-Projekten zusätzliche Methoden. Neben funktionalen Tests (gibt die API das richtige Format zurück?) sind Evaluierungen auf Benchmark-Datensätzen notwendig. Metriken wie Precision und Recall messen die Modellqualität auf eine Weise, die klassische Softwaretests nicht abbilden.
Automatisierung im Entwicklungsprozess
Moderne Entwicklungsprozesse automatisieren wiederkehrende Schritte. Continuous Integration (CI) bedeutet, dass Codeänderungen automatisch zusammengeführt, gebaut und getestet werden. Continuous Deployment (CD) geht einen Schritt weiter und bringt getesteten Code automatisch in die Produktivumgebung.
Beispiel: Ein Entwickler verändert eine Funktion und pusht den Code in das gemeinsame Repository. Innerhalb von Minuten laufen automatisch 2.000 Tests. Schlägt einer fehl, wird der Entwickler benachrichtigt, bevor die Änderung in den Hauptzweig gelangt. Ohne CI würde der Fehler erst Tage später auffallen, wenn ein anderer Entwickler auf den fehlerhaften Code aufbaut.
Beispiel: Bei einem KI-System umfasst die CI-Pipeline zusätzlich Modell-Evaluierungen. Nach jeder Änderung an den Trainingsdaten oder am Modellcode wird automatisch ein Trainings- und Evaluierungslauf gestartet. Sinkt die Precision unter einen definierten Schwellenwert, blockiert die Pipeline das Deployment.
Die Automatisierung verändert den Entwicklungsprozess strukturell. Manuelle Übergabepunkte entfallen. Die Geschwindigkeit steigt, aber auch die Anforderungen an die Testabdeckung: Automatisiertes Deployment ohne ausreichende Tests führt dazu, dass Fehler schneller in die Produktion gelangen.
Technische Schulden und Prozessdisziplin
Technische Schulden entstehen, wenn Entwicklungsteams bewusst oder unbewusst Abkürzungen nehmen: fehlende Tests, duplizierter Code, veraltete Abhängigkeiten. Der Entwicklungsprozess bestimmt, wie mit diesen Schulden umgegangen wird. Prozesse ohne explizite Regelung führen dazu, dass technische Schulden kontinuierlich wachsen.
Beispiel: Ein Team entscheidet sich, eine Datenbankabfrage ohne Index zu implementieren, weil der Sprint-Zeitdruck hoch ist. Bei 1.000 Datensätzen funktioniert die Abfrage. Bei 100.000 Datensätzen dauert sie 30 Sekunden. Die technische Schuld wurde bei der Entstehung nicht dokumentiert und gerät in Vergessenheit, bis die Performance einbricht.
Beispiel: Ein definierter Prozess enthält ein "Tech-Debt-Budget": 20 Prozent der Sprint-Kapazität sind für den Abbau technischer Schulden reserviert. Das Team entscheidet selbst, welche Schulden priorisiert werden. Ohne dieses Budget würden neue Features immer Vorrang haben.
Bei KI-Systemen entstehen zusätzliche Formen technischer Schulden: veraltete Trainingsdaten, undokumentierte Feature-Transformationen, Modellversionen ohne reproduzierbare Trainingsparameter. Der Entwicklungsprozess muss diese KI-spezifischen Schulden explizit adressieren.
Metriken und Prozessverbesserung
Ein Entwicklungsprozess ist nur so gut wie seine Feedback-Mechanismen. Metriken machen sichtbar, wo der Prozess funktioniert und wo nicht. Typische Prozessmetriken sind: Lead Time (Zeit von der Anforderung bis zum Deployment), Deployment-Frequenz, Mean Time to Recovery (MTTR, mittlere Wiederherstellungszeit nach Ausfällen) und Change Failure Rate (Anteil fehlgeschlagener Deployments).
Beispiel: Ein Team misst eine Lead Time von 45 Tagen. Die Analyse zeigt, dass 30 Tage auf manuelle Review-Prozesse entfallen. Das Team automatisiert Teile des Reviews durch statische Codeanalyse und reduziert die Lead Time auf 20 Tage.
Beispiel: Die Change Failure Rate liegt bei 25 Prozent. Jedes vierte Deployment verursacht einen Fehler in der Produktion. Die Ursache: unzureichende Testabdeckung im Integrationsbereich. Der Prozess wird um verpflichtende Integrationstests ergänzt. Nach drei Monaten sinkt die Rate auf 8 Prozent.
Die vier genannten Metriken stammen aus dem DORA-Framework (DevOps Research and Assessment) und gelten als belastbare Indikatoren für die Leistungsfähigkeit von Softwareentwicklungsteams. Teams mit hoher Deployment-Frequenz und niedriger Change Failure Rate liefern in der Regel zuverlässigere Software aus.
Grenzen und Einordnung
Kein Prozessmodell garantiert Projekterfolg. Prozesse reduzieren bestimmte Risiken, schaffen aber neue Abhängigkeiten. Übermäßige Prozessformalisierung kann Teams verlangsamen und bürokratische Hürden erzeugen, die den eigentlichen Zweck unterlaufen.
Beispiel: Ein Konzern führt einen sechsstufigen Genehmigungsprozess für jede Codeänderung ein. Die Change Failure Rate sinkt auf 2 Prozent. Gleichzeitig steigt die Lead Time auf 90 Tage. Features, die der Markt in zwei Wochen braucht, erreichen die Nutzer erst nach drei Monaten.
Agile Methoden sind kein Allheilmittel. Sie funktionieren gut bei Projekten mit hoher Unsicherheit und kleinen Teams. Bei großen, regulierten Projekten mit vielen Abhängigkeiten stoßen rein agile Ansätze an Grenzen. Die Koordination zwischen 20 Teams lässt sich nicht allein durch Zwei-Wochen-Sprints lösen.
Bei KI-Projekten kommt eine weitere Grenze hinzu: Die Reproduzierbarkeit von Ergebnissen ist schwieriger sicherzustellen als bei deterministischer Software. Trainingsabläufe hängen von Zufallsinitialisierungen, Hardware und Bibliotheksversionen ab. Ein Prozess, der Reproduzierbarkeit nicht explizit einplant, erzeugt Modelle, die sich im Fehlerfall nicht nachvollziehen lassen.
Fachliche Einordnung: Die Forschung zur Effektivität von Entwicklungsprozessen zeigt konsistent, dass nicht das spezifische Modell entscheidend ist, sondern die Konsequenz der Umsetzung. Der jährliche "State of DevOps Report" von DORA belegt, dass Teams mit konsistenten Prozessen (unabhängig vom konkreten Framework) bessere Ergebnisse erzielen als Teams, die häufig das Modell wechseln. Entscheidend ist die Fähigkeit, den eigenen Prozess zu messen und iterativ zu verbessern.