Die Aufgabe: Modernisierung der Testsoftware
Die bestehende Testsoftware unseres Kunden erfüllte zwei essentielle Anforderungen nicht: Sicherstellung der Timings, im Verbund mit der eingesetzten Hardware und eine vollumfängliche Abdeckung aller Use Cases von Prüfung, Inbetriebnahme über den Servicefall. Gesucht wurde eine moderne Nachfolge — hersteller- und hardwareneutral, langfristig stabil, plattformübergreifend. Auf dem Tisch lag zunächst ein umfangreicher Funktionskatalog: die vollständige Abbildung des Daten-Protokolls, Unterstützung von mehreren Betriebssystemen, eine vollständige Software für alle Use Cases in einem Schritt. Trotzdem wurde am Ende nur ein Use Case in einem MVP umgesetzt.
Über den Kunden: Ein Branchenverband der Gebäudeautomation
Als eingetragener Verein vereint unser Kunde die Interessen von über 30 Mitgliedsunternehmen aus dem Bereich der Gebäudeautomation. Hauptbestandteil des Vereins ist die Herausgabe eines gemeinsamen Hardware- und Datenprotokolls, das als Standard für alle Mitgliedsunternehmen gilt und gleichzeitig die Zertifizierung und Registrierung der Produkte unter dieser Schirmherschaft übernimmt.
Die Herausforderung: Die Entwicklung einer herstellerneutralen Lösung, die einen einheitlichen Standard, aber zugleich mit offenen Schnittstellen eine Plattform zur flexiblen Anbindung bietet.
Die Herausforderung: Die Entwicklung einer herstellerneutralen Lösung, die einen einheitlichen Standard, aber zugleich mit offenen Schnittstellen eine Plattform zur flexiblen Anbindung bietet.
Unsere Leistungen: Requirement Engineering, MVP Entwicklung und Arc42 Dokumentation
Wir haben das Projekt als Komplettleistung übernommen — von der ersten Anforderungserhebung bis zum fertigen, dokumentierten Software MVP. Drei Leistungsblöcke bilden den Kern.
Requirement Engineering
Um die Anforderungen der Mitgliedsunternehmen möglichst gleichermaßen abdecken, ohne ein einzelnes Mitglied zu bevorzugen, haben wir eine zweistufige Anforderungserhebung durchgeführt:
1. Experteninterviews mit ausgewählten Vertretern der Mitgliedsunternehmen, um die fachliche Tiefe der Anforderungen zu erfassen
2. Eine breitere Umfrage in der Arbeitsgruppe Technik, für eine Priorisierung zwischen Must Haves und Nice to Haves.
Interessant: Beide Quellen lieferten an einer Stelle leicht abweichende Bilder — der Wunsch nach kabelloser Verbindung war in den Interviews präsenter als in der späteren Umfrage. Wir haben beide Quellen transparent gegenübergestellt und dokumentiert, statt eine zugunsten der anderen zu unterdrücken. Diese Transparenz ist Pflicht, wenn die spätere Ausbaustufe auf belastbarem Boden stehen soll.
1. Experteninterviews mit ausgewählten Vertretern der Mitgliedsunternehmen, um die fachliche Tiefe der Anforderungen zu erfassen
2. Eine breitere Umfrage in der Arbeitsgruppe Technik, für eine Priorisierung zwischen Must Haves und Nice to Haves.
Interessant: Beide Quellen lieferten an einer Stelle leicht abweichende Bilder — der Wunsch nach kabelloser Verbindung war in den Interviews präsenter als in der späteren Umfrage. Wir haben beide Quellen transparent gegenübergestellt und dokumentiert, statt eine zugunsten der anderen zu unterdrücken. Diese Transparenz ist Pflicht, wenn die spätere Ausbaustufe auf belastbarem Boden stehen soll.
MVP Software Entwicklung
Als Entwicklungs-Framework haben wir Flutter mit Dart gewählt. Damit lassen sich aus einer einzigen Codebasis native Anwendungen für macOS und Windows erzeugen, die beiden primären Betriebssysteme der Entwickler und Testingenieure in den Mitgliedsunternehmen.
Die App ist modular aufgebaut und trennt die BLE-Kommunikationsschicht sauber von der Darstellungslogik. Einzelne Funktionsmodule können dadurch unabhängig voneinander erweitert oder ausgetauscht werden.
Die bidirektionale Kommunikation zwischen App und Testgateway läuft über zwei BLE-Charakteristiken innerhalb dedizierter GATT-Services.
Dieser Mechanismus ist so spezifiziert, dass jedes Mitgliedsunternehmen ein eigenes Testgerät daran ausrichten kann, ohne dass die Software für einen einzelnen Hersteller modifiziert werden müsste.
Die App ist modular aufgebaut und trennt die BLE-Kommunikationsschicht sauber von der Darstellungslogik. Einzelne Funktionsmodule können dadurch unabhängig voneinander erweitert oder ausgetauscht werden.
Die bidirektionale Kommunikation zwischen App und Testgateway läuft über zwei BLE-Charakteristiken innerhalb dedizierter GATT-Services.
Dieser Mechanismus ist so spezifiziert, dass jedes Mitgliedsunternehmen ein eigenes Testgerät daran ausrichten kann, ohne dass die Software für einen einzelnen Hersteller modifiziert werden müsste.
Arc42 konforme Architekturdokumentation
Verbands-Software ist Infrastruktur. Infrastruktur muss über Jahre stabil bleiben, oft länger, als ein einzelner Entwickler im Projekt verfügbar ist. Wir haben deshalb ein Architekturdokumentation nach Arc42 erstellt.
Arc42 ist ein etablierter Standard für Architekturdokumentation, der zwölf Sichten auf das System beschreibt — von der Kontextabgrenzung über Bausteinsicht und Laufzeitsicht bis zu Architektur-Entscheidungen und Risiken.
Auch wenn das ursprüngliche Entwicklungsteam in fünf Jahren nicht mehr verfügbar wäre, kann ein anderes qualifiziertes Team die Software auf Basis der Arc42-Dokumentation weiterentwickeln, ohne die ursprünglichen Annahmen neu erraten zu müssen.
Arc42 ist ein etablierter Standard für Architekturdokumentation, der zwölf Sichten auf das System beschreibt — von der Kontextabgrenzung über Bausteinsicht und Laufzeitsicht bis zu Architektur-Entscheidungen und Risiken.
Auch wenn das ursprüngliche Entwicklungsteam in fünf Jahren nicht mehr verfügbar wäre, kann ein anderes qualifiziertes Team die Software auf Basis der Arc42-Dokumentation weiterentwickeln, ohne die ursprünglichen Annahmen neu erraten zu müssen.
Warum ein MVP für die Entwicklung der Testsoftware der richtige Einstieg war
Vier Use Cases gleichzeitig in produktionsreifer Qualität zu liefern, wäre der klassische Großprojekt-Fehler gewesen: hohes Budget, lange Laufzeit, viele gleichzeitige Architektur-Annahmen, die alle gleichzeitig richtig sein müssten. Gemeinsam mit dem Vorstand des Vereins haben wir deshalb entschieden, zunächst ein Minimum Viable Product (MVP) zu realisieren, das einen klar abgegrenzten Anwendungsfall vollständig abdeckt: die automatisierte Übergabe und Ausführung von Zertifizierungsmakros über eine kabellose Verbindung zu einem Testgateway.
Was Mittelständler und Verbände von diesem Projekt lernen können
Dieses Projekt zeigt drei Muster, die in vielen Software-Vorhaben des Mittelstands wiederkehren und über Erfolg oder Scheitern entscheiden.
MVP statt Vollausbau
Wer sechsstellig in Software investiert, ohne die kritischen Architektur-Annahmen vorher an einem echten Anwendungsfall validiert zu haben, kauft Risiko, das er nicht einpreisen kann. Ein sauber abgegrenzter MVP ist der wirtschaftlich klügere Einstieg in fast jedes Software-Vorhaben.
Zweistufiges Requirements Engineering
Was Menschen in Workshops mit vielen Teilnehmern sagen, was sie brauchen und was sie wirklich brauchen, wenn etwas Greifbares vor ihnen steht, sind oft zwei verschiedene Dinge. Eine zweistufige Anforderungserhebung (Interviews plus Validierung) deckt diese Lücke auf, statt sie zu verschleiern.
Architekturdokumentation als Versicherung
Ohne saubere Arc42-Dokumentation entsteht eine Abhängigkeit vom ursprünglichen Entwickler, die spätestens bei Personalwechsel teuer wird. Das gilt für Verbände wie für Mittelständler gleichermaßen.
