Auf diesem Flugplatz durften die LBA-Inspektoren mit ihrem Dienstbus auch das Flugfeld befahren. So konnte auch ein Flugzeug überprüft werden, welches nach seiner Landung in einer der hinteren Hallen des Flugplatzes zu verschwinden und so einer Prüfung zu entgehen drohte. Bei der anschließenden Überprüfung wurde aber festgestellt, dass es sich um ein relativ neues sowie modern ausgestattetes Flugzeug ohne jegliche Mängel handelte. Bei einem weiteren überprüften Flugzeug älteren Baujahres wurden dagegen kleinere Beanstandungen festgestellt. Diese wurden im Rahmen einer Sofortmaßnahme vom Halter noch während des Surveys umgehend behoben. So konnte dem Halter noch vor Ort ein Protokoll ohne offene Beanstandungen ausgehändigt werden. Das PDF mit diesem Protokoll wurde von der Anwendung mit den erfassten Daten erstellt und konnte noch auf dem Flugfeld mit einem mobilen Drucker ausgedruckt werden. Bei abgelegenen Flugplätzen kann die Durchführung eines Surveys bis hin zum Druck sogar offline durchgeführt werden. Sobald dann eine Online-Verbindung wieder hergestellt wird, können die Ergebnisse auch nachträglich ins zentrale System hochgeladen werden.

Das Luftfahrt-Bundesamt ist mit der Überwachung der Lufttüchtigkeit der in Deutschland zugelassenen Luftfahrzeuge betraut und prüft diese im Rahmen von spontanen Prüfungen auf Flughäfen und -plätzen(sogenannte Ramp Surveys) oder langfristig geplanten tiefergehenden Prüfungen(sogenannte In-Depth Surveys). Dabei sind je nach Luftfahrzeugkategorie festgelegte Checklisten abzuarbeiten und gefundene Beanstandungen zu notieren und zu bewerten. Als Ergebnis erhält der Halter oder der Pilot ein Protokoll der Prüfung. Wurden gravierende Beanstandungen gefunden, so ist deren Behebung zu verfolgen und zu attestieren.

Die neue ACAM-Software löst die bisherige Nutzung von Papier-Checklisten, händisch ausgefüllten Protokollen mit Durchschlägen und der Dokumentation in Excel ab. Um sich dafür in die Arbeitsweise des Anwenders hineinversetzen zu können, wurden bereits in der Startphase die Anwender bei ihrer Arbeit begleitet. Die Entwicklung selbst fand mit der agilen Methode Scrum statt, bei der nach festen Sprints von drei Wochen der auslieferbare Stand der entwickelten Software den Anwendern präsentiert wird. Durch diese regelmäßige Überprüfung von den Anwendern werden Fehlentwicklungen aufgrund von Missverständnissen vermieden. Stattdessen wird gemeinsam an der Verbesserung der Software gearbeitet. Mit der schrittweisen Umsetzung der allerwichtigsten Funktionen nach einer regelmäßig überprüften Priorisierung wird sichergestellt, dass auch bei Abbruch der Entwicklung der bestmögliche Nutzen erzielt werden konnte. Die wichtigsten Funktionen sind dann auf jeden Fall bereits in der erstellten Software enthalten.

Inzwischen deckt die ACAM-Software neben der Grundfunktionalität der Survey-Durchführung und deren strukturierter Nacharbeit inklusive der Erstellung von Beanstandungslisten bis hin zum Schließen der Akte auch die zufallsbasierte Erstellung eines Prüfprogrammes eines Jahres bei vorgegebenen Kriterien ab. Prüflisten können verwaltet, Luftfahrzeuge können gesucht und zentral dazu gespeicherte Daten in die Kopfdaten eines Surveys übernommen werden. Sämtliche deutschen Flughäfen und -plätze können mit ihren GPS-Koordinaten eingesehen und auch Besuche ohne durchgeführte Surveys dokumentiert werden. Für die Auswertung stehen verschiedene Excel-Exporte zur Verfügung. Insgesamt lässt sich die Software laut den Anwendern sehr gut für ihre Arbeit nutzen. Nur noch einzelne Verbesserungswünsche haben sich durch die Nutzung in der Praxis ergeben. Insbesondere die frühe Einbindung der späteren Anwender in die Entwicklung durch die regelmäßige Präsentation von auslieferfähigen Zwischenergebnissen einschließlich der Möglichkeit, damit auch “herumzuspielen”, förderte die Nutzbarkeit und Akzeptanz der Software.

Wir danken dem LBA und insbesondere den ACAM-Inspektoren für die Einblicke in ihre Arbeit sowie ihr hohes Interesse und Engagement, zusammen mit uns die Software zu dem zu machen, was sie jetzt ist und noch zukünftig sein wird.

‍Text: Silke Loges, Product Ownerin im LBA-Team von evodion

Fotos: Thomas Hess, Softwareentwickler im LBA-Team von evodion

Technisches Umfeld: Angular, Spring Boot, PrimeNG, Cypress, REST Assured, ESLint, Sonar, OWASP Dependency-Check

Anmerkung: Aus Gründen der besseren Lesbarkeit wird bei Personenbezeichnungen und personenbezogenen Hauptwörtern in diesem Dokument das generische Maskulinum (geschlechtsneutrale Form) verwendet. Entsprechende Begriffe gelten für alle Geschlechter

‍