Case Study: Entwicklung einer Plattform zur Steuerung von Produktionsmaschinen mit Echtzeitanforderungen
Hintergrund
In der Industriebranche ist Effizienz, Stabilität und Echtzeitfähigkeit entscheidend für den Erfolg komplexer Produktionsprozesse. Ziel dieses Softwareentwicklungsprojekts war es, eine Plattform zu entwickeln, die unterschiedlichste Produktionsmaschinen zentral steuern kann. Aufgrund der industriellen Anforderungen mussten Echtzeitverarbeitung und hohe Systemzuverlässigkeit gewährleistet werden. Gleichzeitig sollte die Plattform so konzipiert sein, dass sie langfristig wartbar bleibt und für verschiedenste Anwendungsfälle eingesetzt werden kann – ganz im Sinne von “write once and use often”.
Herausforderung
Die größte Herausforderung bestand darin, alle relevanten Stakeholder frühzeitig einzubinden, um die Anforderungen so vollständig wie möglich zu erfassen. Das Ziel war, durch einen maximalen gemeinsamen Nenner Synergien zu schaffen und damit eine nachhaltige, modulare Architektur zu ermöglichen. Dabei musste das Projektteam mit einer hohen Volatilität der Anforderungen umgehen, da diese stark durch dynamische Marktbedingungen getrieben waren.
Ein häufiger Zielkonflikt bestand darin, früh eine stabile Architektur zu entwickeln und gleichzeitig agil genug zu bleiben, um neue oder geänderte Anforderungen schnell integrieren zu können. Architekturänderungen im späteren Projektverlauf wirken sich oft negativ auf Zeitpläne und Release-Zyklen aus – genau das galt es zu vermeiden.
Lösung
Die Lösung begann mit einem klar strukturierten Vorgehen zur Anforderungserhebung. In initialen Kick-Offs und Workshops wurden alle Stakeholder systematisch einbezogen. Dabei konnten Anforderungen nicht nur gesammelt, sondern auch gemeinsam priorisiert werden. Diese strukturierte Sammlung wurde anschließend analysiert, gruppiert und hinsichtlich ihrer Tragweite bewertet.
Ein erster Architekturentwurf wurde nicht wie üblich sofort umgesetzt, sondern diente als Grundlage für eine detaillierte Risikoanalyse. Diese Phase erwies sich als entscheidend, um die Reihenfolge der Umsetzung an den technisch-kritischen Punkten auszurichten. Erst nachdem die größten Risiken identifiziert und minimiert waren, wurde die Architektur final verfeinert und mit den Anforderungen abgeglichen.
Erst ab diesem Punkt wurde ein detaillierter Projektplan erstellt. Da zu diesem Zeitpunkt ein tiefes Verständnis für die Systemarchitektur und die Aufgabenpakete vorhanden war, konnten Abschätzungen viel präziser getroffen werden. Infolgedessen war es möglich, das Entwicklungsteam kontrolliert zu skalieren und die Arbeitspakete effizient umzusetzen.
Ergebnisse
Die Praxis hat gezeigt, dass sich der initiale Mehraufwand in der Planungsphase deutlich auszahlt. Durch die frühe und strukturierte Einbindung aller Stakeholder und die konsequente Anforderungsanalyse konnte eine nachhaltige Architektur aufgebaut werden. Diese ermöglichte es, Features nicht nur effizient zu implementieren, sondern neue Anforderungen präzise zu evaluieren und in kurzer Zeit zu realisieren.
Ein weiterer Effekt war die erhebliche Verbesserung der Planbarkeit. Durch die stabile Architektur wurden die Aufwandsschätzungen für neue Features deutlich genauer, wodurch sich auch Folgeprojekte schneller und risikoärmer realisieren ließen – im Gegensatz zu einer iterativen Vorgehensweise, bei der ständige Architekturänderungen notwendig wären.
Testability – oftmals unberücksichtigt
Hintergrund
Bei der Entwicklung eines komplexen Software-Produkts arbeiteten verschiedene spezialisierte Teams parallel an unterschiedlichen Bereichen: Backend, Middleware und Frontend. Ergänzend dazu war ein eigenes Test-Team dafür verantwortlich, automatisierte Tests für die neu entwickelten Features zu erstellen und zu pflegen.
Jede Nacht wurde ein neuer Software-Build erzeugt, auf den mehrere vollständige Testdurchläufe folgten. Nach jedem Durchlauf wurde ein detaillierter Report erstellt, um die Testergebnisse zu dokumentieren.
Ein immer wieder auftretendes Problem in diesem Prozess waren sogenannte “Flaky Tests” – Tests, die bei wiederholter Ausführung trotz unverändertem Code unterschiedliche Ergebnisse lieferten.
Herausforderung
Durch die Aufteilung des Systems in Backend, Middleware und Frontend stellte sich bei fehlgeschlagenen Tests häufig die Frage nach der eigentlichen Fehlerquelle:
Lag der Fehler im Backend, in der Middleware, im Frontend oder handelte es sich um einen Bug in der Test-Software selbst?
Mit zunehmender Komplexität der Software gestaltete sich die Fehlersuche immer aufwändiger. Dadurch blieb im Entwicklungsalltag oft zu wenig Zeit, um neue Features in der gewünschten Geschwindigkeit zu implementieren.
Lösung
Um die Fehleranalyse zu vereinfachen, wurden verschiedene Maßnahmen eingeführt:
- Logging: Alle Module wurden mit verbesserten Log-Mechanismen ausgestattet, um Fehler schneller lokalisieren zu können.
- UI-Screenshots: Im Bereich des UI-Testing wurden automatisierte Screenshots integriert, um visuelle Hinweise auf Fehlerquellen zu erhalten.
- Beseitigung von Flaky Tests:
Es stellte sich heraus, dass mehrere Ursachen zu den instabilen Tests führten:
- Unerwartete Fehlermeldungen wurden von der Test-Software nicht korrekt behandelt.
- Im Web-Frontend fehlten eindeutige Identifikatoren (IDs) für UI-Elemente. Stattdessen wurden XPath-Selektoren verwendet, die bei geringsten Änderungen der UI-Struktur zu Testfehlern führten.
Durch die konsequente Vergabe eindeutiger IDs für alle relevanten UI-Elemente konnte die Testability signifikant verbessert werden. Dadurch wurde die Anzahl der “flaky” Tests erheblich reduziert.
Ergebnisse
Dank der getroffenen Maßnahmen konnten geplante Meilensteine zuverlässiger eingehalten werden.
Die Effizienz der Entwicklungsarbeit stieg deutlich, da weniger Zeit für aufwändige Fehlersuchen verloren ging. Gleichzeitig konnten mehr Features innerhalb der vorgesehenen Zeiträume realisiert werden.
Das Software-Produkt erreichte insgesamt eine deutlich höhere Stabilität und Robustheit.
C++
Robot Framework
C#
Yocto
Java
Embedded Linux
SQL
swupdate
Phyton
uboot