Hallo zusammen!
Damit die Konzeption gestartet werden konnte, benötigte ich zuerst ein Verständnis über die Domain und die möglichen Anforderungen. Ich führte dazu Recherchen und Gespräche mit Stakeholdern durch, die entsprechendes Domain-Knowledge besaßen, mit dem Ziel, einen Anforderungskatalog zu erstellen. Gleichzeitig bat ich diese, sowie Personen mit Informatikbackground der Hagen GmbH, um die Niederschrift einiger Anforderungen, die sie persönlich für wichtig erachteten. Es entstand ein ungeordneter Anforderungskatalog, der sich grob in zwei Kategorien untergliedern ließ: Anforderungen auf Basis des Domain-Knowledge und technische Anforderungen an das System. Der Katalog gab mir einen groben Überblick über das Projekt, obwohl er weder komplett noch detailliert genug war, um ein vollständiges System-Design abzuleiten. Dies stellte sich im Nachhinein nicht als Nachteil dar, fehlte dieser Momentaufnahme nicht nur der Blick in die Zukunft, die neue Anforderungen und Prioritätsänderungen brachte, sondern auch mir die zeitlichen Möglichkeiten, bedingt durch die Wochenarbeitszeit, alle Anforderungen umsetzen zu können.
Durch die Änderung der Prioritäten einzelner Anforderungen und dem Hinzufügen neuer Anforderungen über die Zeit in Kombination mit der zur Verfügung stehenden geringen Wochenstundenzahl mussten Designentscheidungen flexibler Natur getroffen werden, um einen anpassungsfähigen Systemkern zu schaffen. Dies möchte ich am Beispiel des Schema-Designs der Datenbank verdeutlichen:
Für den Start des Schema-Designs erwies sich die allseits bekannte ER-Modellierung als sehr nützlich, um erste Ideen zu skizzieren und stets eigene Gedankengänge selbstkritisch beleuchten zu können. Implizit wurde so nach und nach ebenfalls das möglichst kleinste Universe of Discourse festgelegt, um keine unnötige Komplexität einzubringen. Doch trotz guter Modellierung wurden Auswirkungen mancher Abwägungen erst durch die sukzessive Implementierung des Gesamtsystems deutlich. Hierbei musste das Datenbankschema häufiger iterativ angepasst werden, da sich Edge Cases zeigten. So war beispielsweise ein teilweises Redesign des Schemas nötig, um zeitpunktgenaue Neuzuweisungen von Gateways zu Installationen und an den Gateways angeschlossenen Geräten zu diesen Installationen darstellen zu können. Das Problem, dass Geräte und Gateways, die von einer Installation zur anderen wechseln können, deren bereits produzierte Daten jedoch im System mit der korrekten Zuordnung verbleiben sollten, musste abstrakt genug gelöst werden, um auch zukünftigen Gerätetypen, unbekannter Art und Konfiguration, Sorge zu tragen, sowie Daten korrekt zuordnen zu können, die aufgrund von Teilsystemausfällen unbekannter Art noch nicht (vollständig) übermittelt wurden. Diese iterative Entwicklungsarbeit an der Datenbank wurde durch das Führen eines statischen, versionsverwalteten DDL-Skripts zur Erstellung des Schemas beschleunigt. So konnten Änderungen, die das Schema offen für spätere Erweiterungen machten, schneller erprobt werden.