Etappe: Ausgangspunkt – bevor überhaupt von Analyse oder Modell die Rede sein kann

Wann beginnt eigentlich die Entwicklung?

Motchi hat sich entschieden: Sein Café braucht eine Softwarelösung. Reservierungen, Bestellungen und Kundendaten sollen endlich digital verwaltet werden. Doch kaum ist diese Entscheidung gefallen, stellt sich eine scheinbar einfache Frage.

Viele Menschen würden spontan antworten: „Sobald der erste Programmcode geschrieben wird.“ Tatsächlich beginnt professionelle Softwareentwicklung jedoch deutlich früher. Bevor Entwicklerinnen und Entwickler Klassen anlegen, Datenbanken erstellen oder Benutzeroberflächen gestalten, müssen sie zunächst verstehen, welches Problem überhaupt gelöst werden soll.

Denn selbst die beste technische Umsetzung hilft wenig, wenn am Ende die falsche Lösung entwickelt wurde.

Die größte Herausforderung ist selten das Programmieren

Moderne Programmiersprachen bieten heute leistungsfähige Werkzeuge. Informationen lassen sich speichern, Benutzeroberflächen erstellen, komplexe Abläufe automatisieren. Die technische Umsetzung ist oft einfacher als früher. Die eigentliche Herausforderung liegt deshalb häufig an ganz anderer Stelle:

• Welche Anforderungen hat Motchi wirklich?
• Welche Funktionen werden tatsächlich benötigt?
• Welche Informationen müssen gespeichert werden?
• Welche Regeln gelten innerhalb des Systems?
• Wie sollen die einzelnen Bestandteile zusammenarbeiten?

Wer diese Fragen nicht beantworten kann, läuft Gefahr, viel Zeit in eine Lösung zu investieren, die am eigentlichen Problem vorbeigeht.

Ein Blick auf andere Berufe

Stell dir vor, ein Architekt würde direkt mit dem Bau eines Hauses beginnen, ohne zuvor einen Plan zu erstellen. Wahrscheinlich würde schnell Chaos entstehen: Räume müssten versetzt, Wände wieder abgerissen werden, und wichtige Anforderungen würden erst bemerkt, wenn es bereits zu spät ist. Deshalb entsteht vor jedem Gebäude zunächst ein Bauplan.

In der Softwareentwicklung verhält es sich nicht anders. Bevor entwickelt wird, müssen Anforderungen analysiert, Zusammenhänge verstanden und Lösungen geplant werden.

Warum Projekte scheitern

Wenn Softwareprojekte Probleme bekommen, liegt die Ursache überraschend selten in der Programmierung selbst.

Stell dir vor, Motchis Software würde ohne vorherige Analyse gebaut. Vielleicht würde ein Entwickler annehmen, dass jeder Tisch nur für eine einzige Reservierung pro Tag genutzt wird – und übersieht, dass Chez Motchi an einem Abend mehrere Reservierungen pro Tisch braucht. Ein solcher Fehler fällt oft erst auf, wenn die Software längst im Einsatz ist.

Je später solche Fehler entdeckt werden, desto aufwendiger und teurer wird ihre Korrektur. Deshalb versuchen Entwicklerinnen und Entwickler, Probleme möglichst früh sichtbar zu machen. Genau dabei helfen Modelle und Diagramme.

Modellieren bedeutet Denken

Viele Einsteigerinnen und Einsteiger betrachten UML-Diagramme oder andere Modelle zunächst als zusätzliche Arbeit, die vor dem eigentlichen Programmieren erledigt werden muss. In Wirklichkeit erfüllen sie jedoch einen wichtigen Zweck: Sie zwingen uns dazu, über ein System nachzudenken, bevor wir es umsetzen.

Ein Modell beantwortet Fragen, die später im Programmcode oft nur schwer zu erkennen sind:

• Welche Bestandteile besitzt das System?
• Welche Aufgaben übernehmen diese Bestandteile?
• Welche Beziehungen bestehen zwischen ihnen?
• Welche Regeln müssen eingehalten werden?

Je klarer diese Fragen beantwortet sind, desto einfacher wird die spätere Entwicklung – bei Chez Motchi genauso wie bei jedem anderen Softwareprojekt.