10. Projektaspekte

Inhalt Unter diesem Hauptkapitel sammeln Sie eine Reihe von organisatorischen und Projektmanagement-relevanten Aspekten, die im Zusammenhang mit der Software- Architektur geklärt werden müssen.

Motivation
Software-Architekten arbeiten im Projekt an zentraler Stelle und müssen anderen Projektbeteiligten, wie dem Projektleiter, dem Betrieb und den Auftraggebern architekturrelevante Informationen bieten.

10.1 Change Request

Inhalt
Liste der Change Requests

Motivation
Eigentlich ein Requirements-Thema. Wenn es dort nicht behandelt wird muß der Architekt sich damit auseinandersetzen.

10.2 Technische Risiken

Inhalt Eine nach Prioritäten geordnete Liste der erkannten technischen Risiken

Motivation

"Risikomanagement ist Projektmanagement für Erwachsene" (Tim Lister, Atlantic Systems Guild.)

Unter diesem Motto sollten Sie technische Risiken in der Architektur gezielt ermitteln, bewerten und dem Projektmanagement als Teil der gesamten Risikoanalyse zur Verfügung stellen.

Form
Risikolisten mit Eintrittswahrscheinlichkeit, Schadenshöhe, Maßnahmen zur Risikovermeidung oder Risikominimierung, ...

10.3 Offene Punkte

Inhalt
Ungeklärte oder noch nicht behandelte Sachverhalte oder aufgeschobene Entscheidungen.

Motivation
Sie können nicht alle Entscheidungen gleichzeitig treffen.

Hintergründe
Erfassen Sie hier alle globalen, offenen Punkte. Sie finden Abschnitte "offene Punkte" auch bei den einzelnen Bausteinen, wo sie Feinheiten festhalten können.

10.4 Erwartete Änderungen

Inhalt
Erwartete Änderungen von organisatorischen oder technischen Randbedingungen, die große Auswirkungen auf die Gesamtarchitektur oder wesentliche Teile davon haben könnten.

Motivation
Machen Sie diese erwarteten Änderungen explizit, so dass das Architektenteam dies bei seinen Entscheidungen und der Strukturfindung berücksichtigen kann.

Form
Tabelle oder Text.

Hintergründe
Dieser Abschnitt ist einer der wichtigsten der gesamten Architekturdokumentation. Die erwarteten Änderungen rechtfertigen Flexibilität – die Sie niemals nur zum Selbstzweck in einem System schaffen sollten. Sie müssen von den maßgebenden Stakeholdern des Projektes in Erfahrung bringen, welche Teile oder Funktionen des Systems flexibel oder änderbar sein müssen – im Idealfall hilft Ihnen dabei Ihre Erfahrung weiter.

Ja - korrekt: Erwartete Änderungen können (und sollten!) Sie auch bei den jeweils betroffenen
Bausteinen in der Bausteinsicht (Abschnitt 4.xx) dokumentieren. Hier, bei den Projektaspekten,
sollte das "big-picture" solcher erwarteten Änderungen stehen.

10.5 Migration

Inhalt
Organisatorische und technische Aspekte, die bei der Migration berücksichtigt werden müssen.

Motivation
Für die meisten Systeme gibt es existierende Altsysteme, die durch die neuen Systeme abgelöst werden sollen. Denken Sie als Architekt nicht nur an Ihre neue, schöne Architektur, sondern rechtzeitig auch an alle Aspekte, die zur Einführung der Architektur beachtet werden müssen.

10.6 Auswirkungen

Inhalt
Erwartete Auswirkungen des neuen Systems auf

  • Betriebsumgebung
  • Andere IT-Systeme
  • Umwelt
  • Benutzer

Motivation
Auch hier geht es darum, über den Tellerrand der Architektur hinaus nachzudenken und Auswirkungen der Architektur zu Papier zu bringen.