Ein Softwarearchitekt schlägt den technischen Inhalt und die Reihenfolge aufeinander folgender Iterationen vor,
indem er eine bestimmte Anzahl von Szenarios auswählt, die analysiert und entworfen werden sollen. Dieser technische
Vorschlag wird von den verschiedenen Entwicklungsteams basierend auf der Personalverfügbarkeit, den Kundenanforderungen
in Bezug auf die erzeugenden Liefergegenstände, die Verfügbarkeit der Tools und COTS-Produkte und den Bedürfnissen
anderer Projekte vervollständigt und präzisiert.
Die Auswahl der Szenarios und Anwendungsfälle, die als "architektonisch relevant" eingestuft werden (d. h. die
Anwendungsfallsicht der Architektur bilden), wird von verschiedenen Schlüsselfaktoren gesteuert, die im Folgenden
zusammengefasst sind.
-
Der Vorteil des Szenarios für die Stakeholder: kritisch, wichtig, hilfreich.
-
Der Auswirkung des Szenarios auf die Architektur: ohne, Erweiterung, Änderung. Es kann kritische Anwendungsfälle
geben, die jedoch nur wenig oder gar keine Auswirkungen auf die Architektur haben, und Anwendungsfälle, die zwar
relativ wenig Vorteile für die Stakeholder bieten, aber große Auswirkung auf die Architektur haben. Letzte müssen
vom Projektleiter überprüft werden, um festzustellen, ob sie möglicherweise außerhalb des Rahmens liegen.
-
Zu mindernde Risiken (Leistung, Verfügbarkeit eines Produkts, Eignung einer Komponente).
-
Abdeckungsgrad der Architektur (sicherstellen, dass am Ende der Ausarbeitungsphase jedes zu entwickelnde
Softwareelement seinen Platz in der Implementierungssicht gefunden hat).
-
Weitere taktische Zielsetzungen oder Vorgaben: Demonstration für den Benutzer usw.
Es kann zwei Szenarios geben, die dieselben Komponenten behandeln und ähnliche Risiken ansprechen. Wenn Sie A zuerst
implementieren, ist B architektonisch nicht relevant. Wenn Sie B zuerst implementieren, ist A architektonisch nicht
relevant. Diese Attribute können von der Iterationsreihenfolge abhängig sein und müssen erneut ausgewertet werden, wenn
sich die Reihenfolge ändert und wenn sich die Anforderungen selbst ändern.
Architektonisch relevante Anwendungsfälle, die schlecht zu verstehen sind oder wahrscheinlich geändert werden, sollten
zur Klärung und Stabilisierung vorrangig behandelt werden. Manchmal bedeutet dies, dass weitere Anforderungsanalysen
durchgeführt werden müssen, bevor die Anforderung implementiert wird. In anderen Fällen bietet sich eher die Erstellung
eines Prototyps an.
|