«Ist hier noch frei?» - Wie aus Unsicherheit eine klare Ansage wurde.

Unser Kunde benötigte ein Reservierungssystem für Sitzplätze im öffentlichen Verkehr – genauer: ein System, das pro Platz automatisch anzeigt, ob der Sitz reserviert ist oder nicht.

Die Anforderungen im Detail:

• Situative Anzeige der Reservierungsdaten – dynamisch, platzgenau
• Echtzeit-Updates – auch kurzfristige Änderungen müssen sofort sichtbar sein
• Integration mit einem kundeneigenen Display-Framework – kein Standard, sondern spezifische Schnittstellen und Abläufe
• Ein System, das nicht nur verlässlich funktioniert, sondern auch bei voller Fahrt mitdenkt.

Das neue Reservierungssystem läuft – und bleibt flexibel. Der Kunde kann das System modular zusammenstellen – passend für verschiedene Einsatzszenarien im öffentlichen Verkehr. Kein starres Setup, sondern eine konfigurierbare Lösung, die sich je nach Einsatzgebiet anpassen lässt.

Für Entwicklung und Tests wurde zusätzlich eine vollständige Simulation gebaut – damit das System auch ohne hunderte physischer Displays getestet und weiterentwickelt werden kann. Das spart nicht nur Hardware, sondern auch Zeit und Nerven.

Das Ganze wurde sauber ins bestehende System integriert, direkt über das kundeneigene Framework. So bleibt der Kunde unabhängig von Drittanbietern – bei Wartung, Weiterentwicklung oder bei neuen Anforderungen.
Und dank der modularen Architektur ist selbst ein Wechsel der Display-Hardware in Zukunft kein Problem: Die Software bleibt, das Interface passt sich an.

Das Projekt lief in zwei klar strukturierten Phasen – von der Idee bis zur fertigen Integration:

Phase 1: Anforderungen klären, sauber dokumentieren
Gemeinsam mit dem Kunden haben wir die Grundlagen erarbeitet. Daraus entstanden: ein Anforderungspflichtenheft und ein Realisierungspflichtenheft, jeweils durch den Kunden geprüft und ergänzt. Auch technische Abklärungen, etwa zur Integration ins kundeneigene Framework, flossen direkt mit ein.

Phase 2: Umsetzung, Integration, Abnahme
Basierend auf den Spezifikationen haben wir das System umgesetzt und beim Kunden integriert. Dabei wurde die Software nicht nur getestet, sondern auch gegen Coding-Guidelines und Architekturvorgaben geprüft. Die finale Abnahme durch den Kunden folgte direkt im Anschluss.

Das Projekt folgte bewusst einem klassischen Wasserfallmodell – pragmatisch, weil Zielbild und Komplexität von Anfang an klar waren. Einzelne Erweiterungen wurden später punktuell ergänzt – ein guter Stresstest für die Architektur: modular, erweiterbar, wartungsfreundlich.