Hallo zusammen!
Zeitschätzungen der Dauer, bis Projektteile fertiggestellt sein würden, gestalteten sich stets als schwierig. Nicht nur die schiere Größe des Projektes, bedingt durch die zum professionellen Einsatz nötige Tiefe der Anforderungen jedes Projektteils, sondern ebenfalls fehlende Erfahrungswerte bezüglich der Schätzung als Werkstudent trugen maßgeblich dazu bei. Insbesondere dann, wenn man wie ich bei der Bearbeitung universitärer Projekte gerne die Zeit außer Acht lässt und davon unabhängig arbeitet bis ein Projekt einen akzeptablen Stand erreicht. Zusätzlich nahmen etwa Fragen des Deployments in den jeweiligen Produktionsumgebungen, beispielsweise zur Sicherheit und Ausfallsicherheit, viel Zeit in Anspruch, ohne ein für technisch Außenstehende offensichtliches Ergebnis zu erzielen. Trotz dieses intransparenten Fortschritts lohnte sich der Fokus auf das Minimum Viable Product (MVP), auch wenn das Funktionalitätsspektrum bis zur „vollständigen Implementierung“ der Grundfunktionen nicht wuchs. Die letztendlich benötigte Zeit lag meist ein gutes Stück über der ursprünglichen Schätzung, hauptsächlich mit Blick auf die zur Verfügung stehenden Wochenstunden und die daraus resultierende absolute Dauer. Hier lohnte es sich, präventives Erwartungsmanagement mit Bezugnahme auf diese lediglich 10 in der Woche zur Verfügung stehenden Stunden vorzunehmen, um offene und ehrliche Kommunikation zu wahren.
Um grundsätzlich möglichst schnellen Fortschritt zu erzielen, Softwareunterstützung zu erfahren und IT-Sicherheit zu gewährleisten, rentierte sich in allen Fällen eine Recherche nach den aktuellen Best Practices und Standardlösungen, wie der für jede Kommunikation genutzten mTLS-Verschlüsselung. Ebenfalls gaben Industrienormen und technische Standards weiteren Aufschluss über die Handhabe üblicher Problemstellungen, welche sich häufig auch auf andere Bereiche des Systems übertragen ließen. So lieferten etwa standardisierte Datenaustauschmodelle für Energiesystemkomponenten Inspiration für die Modellierung von Zeitreihendatenpunktarten. Typische Anbindungsprotokolle zwischen Gateway und Geräten waren meist von der Industrie genormte, teilweise jedoch proprietäre Protokolle, die eher schlecht als recht dokumentiert waren und keinen Best Practices, wie etwa der Protokollversionierung, folgten, was für deutlichen Zeitaufwand auf meiner Seite sorgte. Falls möglich, lässt sich empfehlen, von der Verwendung proprietärer Schnittstellen abzusehen. In der Architektur etwa ersetzte eine Standardlösung die anfänglich gRPC-basierte Custom-Implementierung eines Persistent-Queue Services. Der eingesetzte Message Broker standardisierte effektiv und zeiteffizient das Protokoll, die Autorisierung und die Zuordnung unterschiedlicher Datenströme zu entsprechenden Services, während gleichzeitig Durability sichergestellt wurde. Wo möglich, lohnte es sich in jeder Situation, Standardkomponenten einzusetzen. Insbesondere in sicherheitsfokussierten Bereichen, wie etwa des Identity & Access Managements, der Zertifikatsverwaltung und auf der Nutzungsseite in der Authentifizierung und Autorisierung. Für diese sicherheitskritischen Systembestandteile sollte wenn möglich immer auf bereits bestehende Software zurückgegriffen werden, um Sicherheitslücken zu vermeiden.