Softwarearchitektur

360°-Sicht auf das Projekt

In der Startphase eines Projekts ist die Unsicherheit für den Auftraggeber häufig groß. In einem integrierten Workshop, der sogenannten Foundation Phase, betrachten alle Projektbeteiligten das System dazu mit aufeinander abgestimmten Requirements Engineering-Methoden gezielt von allen Seiten. Das Ergebnis: ein visualisierter Überblick über die fachlichen Anforderungen, technische Umgebung und Risiken sowie eine Umsetzungs-Roadmap. Das gibt Sicherheit für die Umsetzungsentscheidung und das ganze Projekt.

Martin Kleckers

Author

28.08.2020
Lesezeit: 16 Minuten
62 Views

Ein Haus ist nur so gut, wie das Fundament, auf dem es erbaut ist. Gleiches gilt für IT-Projekte. Ist auf der Portfolioebene die Entscheidung für ein Projekt gefallen, müssen jetzt die Anforderungen geschärft und ein Plan für die Umsetzung erarbeitet werden. Ohne die potenziellen Einflussfaktoren, die auf das System einwirken, zu kennen, sind Aussagen zu Kosten oder Projektdauer wenig belastbar. Daher ist es wichtig, die Anforderungen vor Projektbeginn ganzheitlich aus verschiedenen Perspektiven zu betrachten und damit eine solide Grundlage für das Projekt zu schaffen. Der Chaos-Report der Standard Group stellt drei Erfolgsfaktoren für IT-Projekte heraus:

Einbindung der Endbenutzer,
Unterstützung durch das obere Management und
klare Anforderungen.

Für die Klärung von Anforderungen stellt das moderne Requirements Engineering (RE) eine Vielzahl von Werkzeugen zur Verfügung. Der theoretische Hintergrund ist gut beschrieben und auch hier wird auf die Einbindung von Stakeholdern und das Erheben von Anfor-derungen bei Endbenutzern hingewiesen [Got05]. Im Folgenden stellen wir mit der Foundation Phase einen integrierten Workshop vor, der einen einheitlichen Rahmen für eine High Level Analyse bietet und sich unserer Erfahrung nach als Ausgangspunkt für eine effektive und effiziente Projektumsetzung bewährt hat. Zunächst geht der Artikel auf die Planung des Workshops ein: Wer sollte teilnehmen, welche Methoden werden genutzt und welche Arbeitsmittel werden benötigt. Im Anschluss wird die konkrete Durchführung der Foundation Phase beschrieben, einschließlich Beispielen für geeignete RE-Methoden in den jeweiligen Stufen.

Foundation Phase: ein integrierter RE-Workshop

Eine Foundation Phase schafft den Start für strukturiertes Requirements Engineering in einem integrierten Workshop. Diese Phase hat das Ziel, das Projekt auf einem hohen Übersichtsniveau von allen Seiten zu beleuchten, um einen Gesamtüberblick zu erhalten und die nächsten Schritte planen zu können (siehe Abbildung 1). Dazu wird eine Reihe aufeinander abgestimmter RE-Methoden in einem Workshop kombiniert. Die eingebundenen Projektbeteiligten – das Management, Stakeholder, Fachbereiche, Endbenutzer, der Betrieb, Entwickler und Architekten – lernen sich kennen und verstehen, dass ihre Partizipation wertvoll für den Erfolg des Projekts ist. Die gesammelten Erkenntnisse der Zusammenarbeit werden sofort visualisiert und sind im Workshopraum, dem War Room, zugänglich. Das Ergebnis der Foundation Phase ist ein priorisiertes Gesamtbacklog mit groben Anforderungen auf Feature-Ebene, Festlegung eines Minimum Viable Product (MVP) sowie eine grobe Releaseplanung. Das Backlog kann bei Bedarf geschätzt werden.

Abb. 1: Ablauf einer Foundation Phase

Planung des Workshops

Die Planung der Foundation Phase ist ein Prozess, der viel Abstimmung erfordert und für den die erforderliche Zeit eingeplant werden muss. Je nach Projektgröße kann der Vorlauf zwischen vier bis acht Wochen betragen. Für die endgültige Festlegung und Feinabstimmung ist ein Planungsworkshop mit den bereits feststehenden Beteiligten und dem involvierten Management zu empfehlen. Bei der Planung sollte das Management von Beginn an eingebunden sein. Es spielt die entscheidende Rolle in der Herausarbeitung der Ziele. Zudem hilft es bei der Organisation der erforderlichen Ressourcen und gegebenenfalls bei auftretenden Priorisierungskonflikten bei den Teilnehmern.

Workshopdauer
Die Dauer des Workshops wird in Abhängigkeit vom Inhalt des Projekts sowie einer groben Abschätzung der Projektgröße oder des Budgets geplant. Für Projekte mit Budgetgrößen von beispielsweise 500.000 EUR bis 1.000.000 EUR empfiehlt es sich erfahrungsgemäß, eine Foundation Phase über drei bis vier Tage einzuplanen. Bei kleineren Projekten kann der Workshop auch an einem Tag durchgeführt werden. In beiden Fällen ist eine enge Abstimmung mit dem Management und dem Projektsponsor erforderlich.

Teilnehmer
Die Teilnehmer müssen während des Workshops vor Ort sein und entsprechend Zeit dafür einplanen. Dazu ist es erforderlich, im Vorfeld die zukünftigen Nutzer und die Stakeholder eines Systems zu identifizieren. Es sollten alle Stakeholder, die die grundsätzliche Ausrichtung des Projekts beeinflussen können, teilnehmen. Eine Checkliste der potenziellen Nutzer hilft, niemanden zu übersehen. Zu den Nutzern, die gerne vergessen werden, gehören zum Beispiel der Betrieb, Administratoren und die Verwaltung. Es ist weder notwendig noch sinnvoll, dass alle Teilnehmer über die gesamte Dauer des Workshops anwesend sind. Die Teilnehmer bringen jeweils ihre speziellen Anforderungen ein und würden sich während vieler Workshop-Phasen langweilen oder sogar stören. Durch geeignete Visualisierungstechniken werden die vorhandenen Ergebnisse neuen Teilnehmern transparent gemacht.

Methoden
Die sieben Stufen des Ablaufs der Foundation Phase aus Abbildung 1 geben den Rahmen vor. Die darin eingesetzten Methoden hängen vom Projektinhalt, dem gewünschten Detaillierungsgrad der Ergebnisse und den Teilnehmern ab. Die Erarbeitung von Zielen mit dem Management sollte immer erfolgen. Nur so kann sichergestellt werden, dass im Folgenden wirklich an den richtigen Themen gearbeitet wird und das Projekt langfristig die wohlwollende Begleitung durch das Management erfährt. Die Teilnehmer beeinflussen die Methodenwahl durch ihre Vorkenntnisse und Affinität zu den geplanten Methoden. Sie sollen ihre Aufgaben, die Arbeitsweise und die Ergebnisse verstehen und sich gerne beteiligen. Zumindest ein Teil der Teilnehmer wird ja auch zukünftig für die Zusammenarbeit in dem Projekt benötigt. Die jeweiligen Ergebnisse werden im weiteren Austausch mit den Stakeholdern verwendet, und sollen auch später noch verstanden werden. Zugleich müssen die Ergebnisse im gewünschten Detaillierungsgrad erreicht werden. Speziell bei der Aufzeichnung von Geschäftsprozessen gibt es hier Spielräume. Sind Geschäftsprozessspezialisten dabei, kann eventuell die grafische Spezifikationssprache BPMN eine gute Wahl sein. Mit Beteiligten, die sich zum ersten Mal mit Geschäftsprozessen beschäftigen, ist Domain Storytelling [Hof18] eine gute Alternative. Beim technischen Umfang sind die Beteiligten in der Regel mit den Methoden vertraut beziehungsweise haben keine Schwierigkeit, die Konzepte zu verstehen. Generell sollte die Planung der Methoden immer nach dem Motto „Überblick ist wichtiger als Details“ erfolgen.

Raum
Die Foundation benötigt einen Raum (War Room, siehe Abbildung 2), der, zumindest während der Dauer des Workshops, durchgängig exklusiv zur Verfügung stehen sollte. Die Wände und Fenster des Raums dürfen mit den Visualisierungen der Arbeitsergebnisse behängt werden. Der Raum muss groß genug sein, um mit der geplanten Anzahl von Workshopteilnehmern angenehm arbeiten zu können. Dabei sollte bedacht werden, dass die gemeinsame Arbeit an den verschiedenen Stationen hauptsächlich im Stehen stattfindet. Gleichzeitig müssen jedoch für alle Beteiligten Sitzplätze vorhanden sein, denn Klebezettel lassen sich besser im Sitzen beschriften. Für die Planung der mindestens erforderlichen Raumgröße muss für jede Methode überlegt werden, wie viele Teilnehmer anwesend sein werden. Insbesondere ein zu kleiner Raum mit zu wenig Luft und Bewegungsfreiheit sollte vermieden werden. Wenn für das Projekt bereits ein Projektraum existiert, sollte geprüft werden, ob dieser für die Foundation Phase geeignet sein könnte. In diesem Fall können die Arbeitsergebnisse hängen bleiben und weiterbearbeitet werden. Das bietet sich insbesondere für die Story Map [Pat15] an. Zur Raumplanung gehört auch die Versorgung der Teilnehmer mit Getränken und Snacks. Dabei sollte berücksichtigt werden, wie viele Teilnehmer an jedem Tag den Workshop durchlaufen.

Abb. 2: Ein War Room bietet Platz zur Visualisierung des Projekts

Moderation
Die Foundation Phase benötigt drei Moderatoren. Der Hauptmoderator führt durch den gesamten Workshop. Er bildet den Rahmen und kümmert sich um organisatorische Dinge. Die fachlichen Methoden werden von einem erfahrenen Requirements Engineer und die technischen Methoden von einem erfahrenen Architekten durchgeführt. Die Moderation eines solch großen und komplexen Workshops muss gut vorbereitet werden. Die Moderatoren supervisieren und unterstützen sich gegenseitig.

Arbeitsmaterial
Im Laufe des Workshops wird viel Arbeitsmaterial benötigt, insbesondere Klebezettel in allen Größen und Farben. Bei der Beschaffung der Klebezettel muss unbedingt auf Qualität geachtet werden, da sie immer wieder umgehängt werden. Als Arbeitsfläche bieten sich Pinnwände oder die Wände des Raumes an. Es sollte immer auf Papier gearbeitet werden, um die Ergebnisse umhängen und transportieren zu können. Für jeden Teilnehmer müssen mittelstarke Filzstifte zur Beschriftung der Klebezettel vorhanden sein.

Durchführung

Zum Start der Foundation Phase versammeln sich möglichst viele der Teilnehmer im War Room. Ein Sitzplatz für alle ist nicht erforderlich. Der Hauptmoderator erläutert das Ziel des Workshops und den weiteren Ablauf. Der Ablauf wird mit Zeitplanung und Bearbeitungsstatus auf einem Board visualisiert. Die einzelnen Schritte der Foundation Phase sind mit einer Timebox versehen. Die zeitlichen Vorgaben werden überwacht. Die Moderatoren unterstützen sich bei Überwachung und Einhaltung der Timeboxen gegenseitig.

Ziele definieren
Um einen guten Überblick über die Aufgabenstellung zu bekommen, werden zunächst die relevanten Business Driver, das heißt, die übergeordneten Ziele des Projekts, erarbeitet und priorisiert. Die Definition der Business Driver erfolgt immer zu Beginn der Foundation Phase und ist der maßgebliche Erfolgsfaktor für die darauf aufbauenden Schritte. Zugleich stellt sie die größte Herausforderung dar. Es muss darauf geachtet werden, dass die Ziele SMART sind, das heißt spezifiziert, messbar, akzeptiert, realistisch und terminiert. Ideal sind ein bis fünf gut formulierte Ziele, die besonders für das Impact Mapping eine zentrale Rolle spielen [Adz12]. Zu viele Ziele machen die nachfolgenden Schritte unübersichtlich und erschweren es den Beteiligten, gute Entscheidungen zu treffen. Für die Erarbeitung der Business Driver als Projektziele sind Manager mit der erforderlichen Kompetenz und Entscheidungsspielräumen erforderlich. Zusätzlich werden die einzelnen Nutzergruppen des Systems festgestellt und in der erforderlichen Granularität beschrieben.

Fachlicher Scope
Im nächsten Schritt wird der fachliche Umfang näher betrachtet. Hierfür eignen sich besonders die Instrumente Impact Mapping, Geschäftsprozesse und Screenflow. Ausgehend von den Geschäftszielen, wird im Rahmen des Impact Mapping [Adz12] erarbeitet, mit welchen Maßnahmen die Nutzer eines Systems die Ziele erreichen möchten und wie das zu erstellende System die Nutzer dabei unterstützt (siehe Abbildung 3). Der Vorteil von Impact Mapping ist, dass jedes Feature des neuen Systems mit einem Geschäftsziel verknüpft ist. Dies verhindert Wunschkonzerte, in denen Features geplant werden, die ein Stakeholder schon immer mal gerne gehabt hätte. Darüber hinaus werden die wesentlichen Geschäftsprozesse, die das System abbilden soll, von den Beteiligten identifiziert und mittels einfacher Geschäftsprozessdiagramme, Business Process Model and Notation (BPMN) oder Domain Storytelling [Hof18] beschrieben. Zuletzt wird gemeinsam mit den zukünftigen Nutzern ein grober Screenflow beschrieben, der Überblick über die Lösung und Abläufe gibt. Die Einbeziehung der zukünftigen Nutzer setzt dabei wertvolles implizites Wissen frei. Die Beteiligten im fachlichen Teil sind Anwender, Fachbereichsmitarbeiter, der Product Owner, sofern er schon feststeht, sowie Architekten. Die Anwender und Fachbereichsmitarbeiter haben zum Teil keine Erfahrung mit den angewendeten Methoden. Daher müssen diese zu Beginn jeder Aufgabe gut erklärt werden. Die Moderation des fachlichen Teils übernimmt ein Requirements Engineer, die beiden anderen Moderatoren unterstützen und leisten Supervision. Dies betrifft insbesondere das Impact Mapping. Daher wird zu Beginn allen Beteiligten das Impact Mapping erklärt und mit einem spielerischen Beispiel eingeübt. Das Impact Mapping wird jeweils mit allen Beteiligten für jeden Business Driver durchgearbeitet. Die entstehenden Impact Maps benötigen viel Platz. Da erfahrungsgemäß die verwendeten Klebezettel immer wieder umgehängt werden, sollten die Verbindungslinien erst am Ende eingezeichnet werden.
Bei der Aufzeichnung der Geschäftsprozesse ist es wichtig, zunächst die Geschäftsprozesse an sich zu identifizieren. Dann wird jeder Prozess Schritt für Schritt erarbeitet. Dabei muss auf die Granularität geachtet werden. Überblick ist wichtiger als Details.

Abb. 3: Beispiel für eine Impact Map

Technischer Scope
Im Rahmen der technischen Analyse werden der architekturelle Kontext, in den das neue System eingebettet wird, sowie Aufbau und Struktur des Systems mithilfe verschiedener Instrumente bestimmt. Als Methode bietet sich hier das C4-Modell an [C4]. Das Kontextdiagramm beschreibt die Umgebung, in der das neue System läuft. Dabei werden sowohl die Nutzer als auch die umgebenden Systeme visualisiert. Da es einen Blick von weit oben gibt und Details ausklammert, ist es für fachliche Mitarbeiter und Projektleiter leicht nachvollziehbar. Das Komponentendiagramm hingegen ermöglicht einen Zoom auf das System, indem es die logischen fachlichen Komponenten und deren Interaktionen untereinander darstellt. Um zu verstehen, wie sich das System in die übergeordnete IT-Struktur einfügt, ist die Erstellung eines Containerdiagramms hilfreich. Das neue System wird hierbei als Struktur von zusammenwirkenden technischen Containern beschrieben und zeigt, wie diese miteinander kommunizieren. Noch tiefer ins Detail geht das C4-Komponentendiagramm, in dem für jeden Container beschrieben wird, aus welchen technischen Komponenten er besteht (siehe Abbildung 4). Die Beteiligten im technischen Teil sind der Product Owner, Architekten und Softwareentwickler. Die Moderation liegt jetzt beim Architekten. Die anderen Moderatoren unterstützen und leisten Supervision. Für den Aufbau des Kontextdiagramms ist es sinnvoll, im ersten Schritt die ungefähre Anzahl der beteiligten Systeme abzufragen, um eine sinnvolle Spielfeldgröße zu planen. Die nachfolgenden Diagramme bauen darauf auf. Das Containerdiagramm ist für das Verständnis der Architektur sehr wichtig.

Abb. 4: Beispiel für ein Komponentendiagramm

Nicht funktionale Anforderungen
Neben den fachlichen Anforderungen an das System sollten auch nicht funktionale Anforderungen in einem Brainstorming gesammelt, konsolidiert und verfeinert werden, da sie einen beträchtlichen Einfluss auf die Komplexität der Software haben können. Zu den nicht funktionalen Anforderungen zählen zum Beispiel qualitative Merkmale und weitere Randbedingungen wie Sicherheitsanforderungen, das Look-and-Feel, Skalierbarkeit, Wartbarkeit oder Compliance. Teilnehmer dieser Workshop-Phase sind der Product Owner, Architekten und Softwareentwickler.

Backlog
Aus allen bisher gesammelten Ergebnissen werden grobe Storys erstellt, die in der Story Map ([Pat15], siehe Abbildung 5) strukturiert und priorisiert werden. Auf dieser Basis wird das MVP definiert und eine grobe Releaseplanung erstellt. An der Erstellung des Backlogs sind Architekten, Softwareentwickler und der Product Owner beteiligt. Die Moderation liegt jetzt wieder beim Requirements Engineer. Dieser hat zur Vorbereitung das Schema, anhand dessen die Storys gruppiert werden, erarbeitet. Die initiale Erstellung des Backlogs startet mit dem Einsammeln der Storys. Dazu werden die Arbeitsergebnisse durchgegangen und die Storys „geerntet“. Die Storys sind keine User-Storys im engeren Sinn. Es handelt sich in der Regel um große User-Storys und Features. Bei der Erstellung der Storys können Formalismen außer Acht gelassen werden. Entscheidend sind die richtigen Stichwörter und dass jeder weiß, was gemeint ist. Werden viele Storys erwartet, sollten alle Teilnehmer beim Schreiben einbezogen werden. Dabei kann parallel gearbeitet werden. Die Storys werden in das Schema einsortiert. Wichtig ist die gemeinsame Priorisierung. Auch bei dieser bietet es sich an, zunächst parallel zu arbeiten. Bei der Festlegung des MVP wird die Priorisierung gegebenenfalls noch mal geändert. Priorisierungen können bis zuletzt geändert werden, und es ist auch nicht ungewöhnlich, dass „vergessene“ Storys nachgereicht werden.

Abb. 5: Schema für eine Story Map

Risikoanalyse
Jedes Projekt sollte realistisch betrachtet werden, um sich auf eventuell auftretende Probleme bestmöglich vorzubereiten. Es ist daher wichtig, eine Übersicht aller potenziellen Risiken, die das Projekt gefährden könnten, zu erstellen. In einer anschließenden Risikoanalyse werden die Risiken hinsichtlich ihrer Auswirkung und Wahrscheinlichkeit bewertet und in einer Risikomatrix (siehe Abbildung 6) eingeordnet. In diesem Schritt sollte, neben dem Product Owner, den Architekten und Softwareentwicklern, das Management wieder mit beteiligt sein.

Abb. 6: Je früher Risiken erkannt werden, desto besser

Schätzen des Backlogs
Das Backlog wird bei Bedarf im Nachgang mit einer den Teilnehmern geläufigen Methode für Massenschätzungen geschätzt. Beteiligte an der Aufwandsschätzung sind Architekten, Softwareentwickler und der Product Owner.

Abendliche Retrospektive
Nach dem Workshoptag tauschen sich alle Teilnehmer darüber aus, was gut und was nicht so gut gelaufen ist. Es werden Maßnahmen für den nächsten Tag beschlossen. Der Zeitplan und die geplanten Methoden werden gegebenenfalls angepasst. Die Teilnehmer werden am nächsten Morgen über eventuell erforderliche Planänderungen informiert.

Abschluss der Foundation Phase
Zum Abschluss des Workshops wird eine Feedbackrunde durchführt, denn Gutes soll bewahrt, weniger Gutes verbessert werden. Die Ergebnisse der Foundation Phase müssen dokumentiert und gesichert werden. Neben dem obligatorischen Fotoprotokoll sollten die Originalergebnisse aufbewahrt oder in andere Projekträume überführt werden, falls der War Room nicht weiter genutzt werden kann. Dazu ist es sinnvoll, die Klebezettel zusätzlich mit einem Klebestift zu fixieren. Die Dokumentation und die Verpackung eines War Room ist ein erheblicher Aufwand, der für den Abschlusstag eingeplant werden sollte, insbesondere wenn im Anschluss noch gereist werden muss.

Fazit

Die Durchführung einer Foundation Phase ermöglicht es, im Vorfeld ein grundlegendes Verständnis für die Problemstellung zu entwickeln und eine fundierte Informationsbasis für das weitere Projektvorgehen zu schaffen. Da es sich um einen komplexen mehrtägigen Workshop mit vielen Teilnehmern handelt, muss er sorgfältig vorbereitet werden. Die Planung und Durchführung des Workshops sind aufwendig und mit Kosten verbunden. Doch diese Kosten sind gut investiert: Das Projekt erhält einen Überblick über die fachlichen Anforderungen, das technische Umfeld, die nicht funktionalen Anforderungen, Risiken und eine Roadmap für die Umsetzung. Damit beruhen Aussagen zu Machbarkeit und Kosten auf umfassenden Informationen. Dies gibt Sicherheit für die Planung der nächsten Schritte. Der Überblick enthält noch keine Details, liefert aber einen Plan, an welcher Stelle begonnen werden sollte, Details herauszuarbeiten.
Im Idealfall begleiten die visualisierten Ergebnisse der Foundation Phase das gesamte Projekt und werden mit fortlaufender Projektdauer weiterentwickelt. Sie helfen dabei, dauerhaft gute Entscheidungen zu treffen, und verhindern, dass ein Projektteam im Umsetzungsalltag das große Bild aus den Augen verliert. Die Zielgenauigkeit wird erhöht und es entstehen im Laufe des Projektes weniger Change Requests, was die Umsetzung beschleunigt.