Im letzten Teil unserer Blogserie haben wir Ihnen die Herausforderungen, die bei der Kontextabgrenzung eines Systems auftreten können, vorgestellt. Das Hauptproblem dabei war, dass die Architektur oftmals bereits zu frühen Phasen oder zu Beginn der Systemanalyse festgelegt wird, dabei sollte (laut Theorie) die Systemanalyse doch relativ architekturneutral durchgeführt werden. Doch das ist nicht die einzige Herausforderung, die es bei der Entwicklung eines Systems zu bewältigen gilt, vielmehr müssen Sie sich weiteren Herausforderungen, vor allem bei der Dokumentation der Systemarchitektur, stellen. In diesem Blogartikel möchten wir auf diese Herausforderungen eingehen, sodass Sie für diese in Ihrem Projekt gewappnet sind.
In jedem Entwicklungsprojekt ist irgendwann der Zeitpunkt erreicht, an dem Systemanforderungen an die Systemarchitekten übergeben werden. Genau zu diesem Zeitpunkt können verschiedene Probleme entstehen, die den Projekterfolg negativ beeinflussen. Eine häufige Ursache dabei ist, dass in einem Unternehmen meist unterschiedliche Abteilungen für die Anforderungsanalyse und Architektur verantwortlich sind. Dies ist per se nicht schlimm, jedoch führt dies oftmals dazu, dass die Mitarbeiter dieser Abteilungen dem Lesen und Beschreiben unterschiedlicher Notationsarten für die Dokumentation mächtig sind. In der Anforderungsanalyse werden häufig Prosabeschreibungen verwendet, wobei bei der Architektur oftmals die SysML/UML als Notation bevorzugt wird. Ein zusätzlicher Problemverursacher ist dabei die räumliche Trennung der Abteilungen. Dadurch wird die doch wichtige Kommunikation zwischen Architekt und Analytiker erheblich beeinträchtigt. Die resultierende Probleme daraus: falsch interpretierte, ungenaue oder fehlende Anforderungen.
Diese Probleme können vermieden werden, indem Analytiker und Architekten schon in frühen Phasen der Systemanalyse Kontakt aufnehmen und ein gemeinsames Vorgehen erarbeiten. Dabei hilft es vor allem ein gemeinsames Glossar oder Begriffsmodell zu erstellen, gemeinsame Artefakte zu definieren (z.B. Systemziele) und eine einheitliche, für jeden lesbare Notation festzulegen. Außerdem ist es wichtig, dass die Systemarchitekten durch Feedback-Mechanismen in die Analysephase mit eingebunden werden. Dadurch können die Architekten ihre groben Architekturvorstellungen an die Analytiker zurückgeben und die Anforderungen verbessert werden.
Die Entwicklung eines Systems ist häufig projektgetrieben, das bedeutet Projekte verfolgen meist kurzfristige Ziele und sind z.B. Budget- oder Zeitgetrieben. Kritische Entscheidungen werden anhand verbleibender Zeit und vorhandenem Budget anstatt der Systemqualität getroffen. Zur Erläuterung des Problems nehmen wir am besten ein Beispiel aus dem Projektalltag: Ein Großteil der geplanten Funktionalität ist bereits umgesetzt, das Projekt ist zeitkritisch und Budget ist noch wenig vorhanden. Plötzlich soll eine noch nicht realisierte Funktionalität durch einen dringenden Change Request anders als geplant umgesetzt werden. Aus Sicht des Architekten ein aufwendiger und zeitintensiver Prozess. Das Projekt entscheidet sich gegen eine aufwendige Dokumentation der Architektur, dafür für eine schnellere und kostengünstigere Lösung. Das kann dazu führen, dass die Architektur in späteren Lebenszyklen des Systems z.B. der Wartung nicht mehr nachvollziehbar und wartbar ist. Dadurch entstehen wiederum Mehraufwände in diesen Lebenszyklen. Es ist deshalb notwendig, eine sinnvolle Balance zwischen den Zielen des Projekts und den Zielen, die zur Erreichung der Systemqualität dienen, zu finden.
Ihnen kommen diese Herausforderungen bekannt vor? Sind Sie vielleicht sogar in eigenen Projekten mit derartigen Problemstellungen konfrontiert? Die SOPHISTen unterstützen Sie gern und haben ein Systems Engineering Training für Sie konzipiert. In „Systems Engineering – Wie viel Requirements und Architektur benötigen Sie wirklich?“ erfahren Sie alles rund um das Thema Systems Engineering. Sie erhalten Einblicke in Requirements Engineering und die Kontextabgrenzung. Darüber hinaus lernen Sie, worauf es bei der Dokumentation von Architekturen ankommt und wir stellen Ihnen ein Beispiel für die Gliederung einer Gesamtsystembeschreibung vor. Die Termine für die offenen Trainings 2017 stehen bereits fest, zögern Sie also nicht und lassen Sie uns gemeinsam Ihre Projekte zum Erfolg führen.
Im nächsten Beitrag unserer Blogserien stellen wir Ihnen eine weitere Hürde vor, die uns die bereits vorgestellten Herausforderungen noch zusätzlich erschwert. Denn in der schier unendlichen Summe an Lösungs- und Umsetzungsmöglichkeiten werden wir (zumindest bei der Entwicklung sicherheitskritischer Systeme) durch Vorgaben an die Sicherheit des Systems immens eingeschränkt. Verpassen Sie also nicht den nächsten Teil von „Herausfoderungen in Systems-Engineering-Projekten“, es geht um Leib und Leben.
Viele Grüße und passen Sie auf sich auf!
Ihre SOPHISTen
Teil 1: Herausforderungen in Systems-Engineering-Projekten
Teil 2: Herausforderungen in Systems-Engineering-Projekten –Architektur und Kontextabgrenzung
Teil 4: Herausforderungen in Systems-Engineering-Projekten – nicht-funktionale Anforderungen