Die vorliegende Arbeit soll anhand des Design Science Research Framework nach Hevner aufzeigen, ob es möglich ist, eine Entscheidungsgrundlage für die projektspezifische Entscheidung über die Wahl der geeigneten architekturellen Vorgehensweise zu bieten. Die Ausgangssituation bildet dabei ein mit SCRUM durchzuführendes Großprojekt mit dessen Projektumfeldbedingungen.
Der Fokus der Arbeit liegt dabei auf der Identifikation der geeigneten kritischen Erfolgsfaktoren für die Auswahl der Vorgehensweise in der IT-Architektur, wie diese im Kontext zueinander stehen und wie der Prozess zur Entscheidungsfindung vonstatten gehen kann.
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1 Einleitung
1.1 Ausgangslage
1.2 Ziel der Arbeit
1.3 Aufbau der Arbeit
2 Definitionen
2.1 SCRUM
2.2 Großprojekt
2.3 IT-Architektur
2.3.1 Definition
2.3.2 Gibt es ein sinnvolles Maß an IT-Architektur?
2.4 Der Projektstrukturplan
3 Erarbeitung einer Entscheidungsmatrix
3.1 Kritische Erfolgsfaktoren
3.2 Risikoanalyse
4 Auswirkungen des Agilen Festpreisvertrages
5 Vorgehensweise im Gesamtprozess
6 Reflexion
7 Ausblick
Literaturverzeichnis
Abbildungsverzeichnis
1 Aufbau der Arbeit
2 Welches Maß an Architektur ist sinnvoll? [CB10, S. 160]
3 Beispielhafte Darstellung einer Projektabhängigkeitsmatrix [MC01]
4 Netzplan - Erweiterte kritische Entscheidungsfaktoren nach Boehm [BT03]
5 Visualisierte Vorgehensweise im Gesamtprozess
Tabellenverzeichnis
1 Die sieben Richtlinien nach Hevner in Bezug auf diese Arbeit [HMP+04, S. 83]
2 Krit. Erfolgsfaktoren bei der Wahl der Projektvorgehensweise [BT03, 51ff]
3 Kumulierte Vorgehensweise im Gesamtprozess
4 Erfüllungsgrad der sieben Richtlinien nach Hevner [HMP+04, S. 83] .
1 Einleitung
1.1 Ausgangslage
Agile Methoden, wie beispielsweise SCRUM, erlauben eine hocheffiziente Entwicklung und schnelle Auslieferung von Softwareartefakten. Der Fokus agiler Methoden liegt grundsätzlich auf kleinen Teams, mit der Vorgehensweise ”ScrumofScrums“ist auch auch eine Skalierung auf Großprojekte möglich. In der Praxis werden die Möglichkeiten der agilen Softwareentwicklung gerne als der einzig wahre Lösungsweg für Projekte angepriesen, ohne genau im Detail zu beleuchten, welche Voraussetzungen
und Umgebungen geschaffen werden müssen, um einen erfolgreichen Einsatz dieser zu erreichen. Diese nicht vollständig durchdachte Einführung agiler Methoden in die Unternehmens-/Projektstruktur wird oftmals als [FWVH12, S. 69]).
”WaterScrumFall“bezeichnet(vgl.
Aus diesen unvollständigen Integrationen werden die Argumente der Kritiker geschürt, dass agile Softwareprojekte nicht planbar, chaotisch und Ergebnisse in variabler Qualität liefern. Um diesen Sachverhalt zu verbessern, wurde u.a. die Vorgehensweise des Reliable SCRUM entworfen (vgl. [GP02; Mül12]). Jedoch wird selten beleuchtet, welche architekturelle Vorgehensweise, in jeweils extremer Ausbildung als Front Design“ (BUFD) bzw.
”BigUp- ”Youain’tgonnaneedit“(YAGNI)bezeichnet,die niedrigsten langfristigen Kosten aufweist und somit den Projekterfolg maßgeblich unterstützt.
Die vorliegende Arbeit soll anhand des Design Science Research Framework nach Hevner (vgl. Kapitel 1.2) aufzeigen, ob es möglich ist eine Entscheidungsgrundlage für die projektspezifische Entscheidung über die Wahl der geeigneten architekturellen Vorgehensweise zu bieten. Die Ausgangssituation bildet dabei ein mit SCRUM durchzuführendes Großprojekt mit dessen Projektumfeldbedingungen. Der Fokus der Arbeit liegt dabei auf der Identifikation der geeigneten kritischen Erfolgsfaktoren (vgl. Abb. 4) für die Auswahl der Vorgehensweise in der IT-Architektur, wie diese im Kontext zueinander stehen und wie der Prozess zur Entscheidungsfindung (vgl. Abb. 5) vonstatten gehen kann.
1.2 Ziel der Arbeit
Als Primärziel der vorliegenden Arbeit ist die Informationsgewinnung während der Analysephase und Evaluierung von IT-Artefakten definiert [HMP+04; OBF+10]. Da die Arbeit eine praxisrelevante Ausrichtung hat, werden die angeführten Veröffent- lichungen in Anlehnung an das Design Science Research Framework nach Hevner entwickelt. Dessen Ansatz liegt darin, neue und innovative (IT-) Artefakte zu er- stellen, welche den aktuellen Wissenskorpus erweitern und nachgewiesen relevant sind. Hierfür müssen die sieben von Hevner definierten Richtlinien erfüllt sein. Die folgende Auflistung in Tabelle 1 zeigt, wie diesen im Rahmen der vorliegenden Arbeit begegnet wird:
Richtlinie Beschreibung Bezug zur Arbeit Design als Arte- Die Design Science For- fakt schung muss ein tragfähi- ges Artefakt in Form ei- nes Konstruktes, einer Methode, eines Modells oder einer Instanziierung hervorbringen. Relevante Pro- Das Ziel der Design blemstellung Science Forschung ist es, technologiebasierte Lösungen für wichtige und relevante Unter- nehmensprobleme zu entwickeln.
Evaluierung des Die Brauchbarkeit, Qua- Designs lität und Wirksamkeit ei- nes Design-Artefakt muss konsequent in einem gut ausgeführten Bewertungs- verfahren nachgewiesen werden.
In der vorliegenden Arbeit wird versucht, aus praktischen Er- fahrungswerten und angeeigne- tem (theoretischen) Domänenwis- sen ein neues Modell als Entschei- dungsgrundlage für die Wahl der architekturellen Vorgehensweise in einem agilen Großprojekt zu schaf- fen.
Die Zielsetzung der vorliegenden Arbeit zielt auf ein wirtschaftlich relevantes Problem ab, für wel- ches explizit Lösungsalternativen gesucht werden.
Der abstrakt entwickelte Netzplan kann im Rahmen der Hausarbeit nicht an einem realen Fallbeispiel verprobt werden. Dies kommt ei- ner ersten, nur teilweise repräsen- tativen Evaluation gleich. Forschungs- Effektive Design Science beitrag Forschung muss klare und überprüfbare Beiträge in den Bereichen Design Ar- tefakt, Design Stiftun- gen und/oder Design- Methoden aufweisen.
Forschungs- Die Design Science For- sorgfalt schung beruht auf der An- wendung gründlicher Me- thoden sowohl in der Kon- struktion als auch in der Evaluation des Designs Artefakts.
Design als Such- Die Nutzung iterativer prozess Suchprozesse sollte der Lösungsentwicklung fol- gen, während die Metho- den des jeweiligen For- schungsgebietes genutzt werden. Die Iteration dient der stetigen Verbes- serung der Lösung.
Ergebnis- Die Ergebnisse müssen kommunikation verständlich, sowohl dem technisch- als auch dem managementorientierten Publikum präsentiert werden.
Die Erarbeitung eines Netzpla- nes und der prozessualen Vorge- hensweise als Grundlage für die Wahl der architekturellen Vor- gehensweise ist in diesem Maß noch nicht durchgeführt worden und soll einen entsprechenden For- schungsbeitrag leisten.
Die praktischen Erfahrungen und die der Literatur entnommenen Domänenkenntnisse ermöglichen die Konstruktion eines Design Artefakts. Eine Evaluation kann im Rahmen der Hausarbeit nicht durchgeführt werden und muss so- mit in weiteren Arbeiten erfolgen. Die bisher gesammelte Erfahrun- gen des Autors werden mit theo- retischen Grundlagen verheiratet.
Die Erarbeitung eines Netzpla- nes und Prozessvorgehens soll eine generische Empfehlungsgrundlage für die Wahl der architekturellen Vorgehensweise bieten und mittel- und langfristig durch weitere Ar- beiten verbessert werden.
Die im Rahmen der Arbeit auf- kommenden Ergebnisse werden durch eine Präsentation in einem Fachkreis im Rahmen des Studi- ums kommuniziert und dient einer Sensibilisierung der dort anwesen- den Personen. Eine spätere Publi- kation der Ergebnisse ist nicht aus- geschlossen.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Die sieben Richtlinien nach Hevner in Bezug auf diese Arbeit [HMP+04, S. 83]
1.3 Aufbau der Arbeit
Nach der Präsentation der Ausgangslage und Zielsetzung im Abgleich mit der zugrun- de liegenden Forschungsmethodik in Kapitel 1.2 befasst sich Kapitel zwei mit den theoretischen Grundlagen und Begriffsdefinitionen. Hierzu werden die für die Haus- arbeit relevanten Begrifflichkeiten erläutert. Anschließend erfolgt eine Beschreibung der fünf kritischen Erfolgsfaktoren in Kapitel 3.1 nach Boehm und eine Erweiterung seines Netzmodells auf sieben Faktoren.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Aufbau der Arbeit
Das darauf folgende Subkapitel geht auf die Risikoanalyse bei der Bewertung der Vorgehensweise innerhalb eines Projektes ein und bietet die letzte Sicht für die Modellierung des Gesamtprozesses in Kapitel 5. Der Fokus liegt vor allem auf der Definition und Absicherung der Vorgehensweise. Abschließend erfolgen eine kri- tische Würdigung der Arbeit sowie ein Ausblick auf zukünftige Forschungs- und Entwicklungsmöglichkeiten (vgl. Abbildung 1).
2 Definitionen
2.1 SCRUM
Das SCRUM Framework wird bereits seit 1993 in Projekten eingesetzt, weit vor der Definition des agilen Manifests [BBB+01; Lar03; Sut04]. ”Scrumisteinagiles Management-Framework zur Entwicklung von Software, das aus wenigen klaren Re- geln besteht. Diese beinhalten die Anwendung der drei Rollen Product Owner, Team und Scrum Master, die Verwendung eines priorisierten Product Backlog sowie das Er- stellen von Produktinkrementen innerhalb kurzer Arbeitszyklen, die Sprints genannt werden“ [Pic08, S. 1]. Zusätzlich finden am Ende jedes iterativen Entwicklungszyklus die Kundenabnahme (=Review) und eine Retrospektive statt (vgl. [Pic08; Sch04]).
Nur durch eine disziplinierte Anwendung dieser wenigen Regeln ist ein Erfolg mit Hilfe von SCRUM möglich. Der gesamte Anforderungskatalog ist im Product Backlog hinterlegt und die Anforderungen werden partiell pro Sprint in Produktinkremente gewandelt, welche direkt Verwendung im produktiven Einsatz finden können. Die Sprints sind im Vorfeld in ihrer Länge fest terminiert und dürfen während der Laufzeit nicht verändert werden, dies würde das Prinzip des ”timeboxing“verletzen.
Bevor der erste Sprint gestartet werden kann, müssen das Product Backlog mit den Anforderungen befüllt und die Stakeholder, das Team, der Scrum Master und der Product Owner einsatzbereit sein [Pic08].
2.2 Großprojekt
Ob ein Projekt ein ”Großprojekt“odernurein ”großesProjekt“ist,hängtvom Standpunkt des Betrachters ab. Was für ein Unternehmen Alltag ist, kann für das andere ein singuläres Ereignis sein. Die vorliegende Hausarbeit orientiert sich an folgenden Beurteilungskriterien [Ang]:
- Das Projektbudget sollte den Jahresumsatz des Unternehmens übersteigen
- Ein Scheitern des Projektes birgt ein erhebliches wirtschaftliches Risiko
- Die Projektlaufzeit sollte über ein Jahr betragen
- I.d.R. wird eine eigene Projektorganisation gegründet. Daraus folgen auch eigenständige Führungs- und Entscheidungsstrukturen
- I.d.R. 500 - 100.000 Vorgänge mit einer Vernetzungszahl >1
- Ein Großprojekt muss in Teilprojekte gegliedert sein
2.3 IT-Architektur
2.3.1 Definition
Der Begriff der IT-Architektur ist im Bereich der Informationstechnologie nicht eindeutig definiert. Grundsätzlich werden darunter die Fundamente und Säulen eines Software-Systems verstanden. Es werden hierbei die Systembestandteile samt Funk- tionen, die Bestandteil-Beziehungen, die Systemumwelt und die Beziehung von/zur Umwelt beschrieben, wobei Implementierungsdetails nicht enthalten sind. Es soll nur eine Übersicht über die Systemkomplexität aufgezeigt werden [VAC+08, 8ff]. Die Erarbeitung der Architektur für ein Software-System kann auf verschiedene Arten hergeleitet werden.
Zum Einen kann sie mühsam aus den Anforderungen und Rahmenbedingungen, zum Zweiten aus Erfahrungen vergangener Projekte oder zum Dritten aus Referenzarchi- tekturen bzw. Entwurfsmustern erarbeitet werden. Das Ziel ist der Entwurf einer den Anforderungen und Rahmenbedingungen gerecht werdenden Architektur [Ang12, S. 5]. Was jedoch ist eine gerecht werdende Architektur? - Unter Berücksichtigung des Laufzeitverhaltens sollte die Software mit vertretbarem Aufwand erstellbar und leicht verständlich sein [Sho06]. Ein weiteres Augenmerk muss auf eine kostengünstige Anpassung gelegt werden, da durchschnittlich 40 bis 90 Prozent der Softwarekosten in der Wartungsphase, und somit im Produktivbetrieb, entstehen[PP06, S. 20]. 2.3.2 Gibt es ein sinnvolles Maß an IT-Architektur? Kaum ein Thema polarisiert so extrem, wie sinnvoll?“ bzw.
”WelchesMaßanIT-Architekturist ”WannistderoptimaleZeitpunktzwischenGeschäftsrisikoundder Rendite erreicht?“. Hier existieren zwei Extreme, welche die maximalen Ausprägun- gen der IT-Architektur beschreiben; BUFD für ”bigup-frontdesign“undYAGNIfür ”Youain’tgonnaneedit“.InderRealitätgibtesnochvieleGestaltungsspielräume zwischen den genannten Extremen, da zwar weder BUFD noch YAGNI die vollkom- mene Wahrheit darstellen, aber in vielen Punkten ihre Daseinsberechtigung aufweisen.
BUFD kann u.a. nicht mit verspätet/unerwartet auftauchenden Anforderungen um- gehen, denn dies bedeutet einen massiven vorhergehenden Aufwand. Präventive Systemspekulationen bieten am Ende des Tages Systemfunktionalitäten, die keinen direkten Mehrwert für den Kunden darstellen und somit auch keine Nutzung erfahren. Diese Aspekte der Software-Entwicklung sind ein offenes Geheimnis und sind Teil der modernen Software-Engineering Landschaft geworden.
Der Trend wendet sich von BUFD ab. Die Argumentation bezüglich YAGNI ge- staltet sich subtiler, zumindest in Anbetracht der derzeitigen üblichen Software- Entwicklungen. Mit YAGNI kann das Gedankengut der agilen Software-Entwicklungs- methoden gut repräsentiert werden, da es vermieden wird, Dinge zu entwickeln, die eventuell nicht benötigt werden [JA01, 219ff]. Aufgrund der Lage der IT-Architektur
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Welches Maß an Architektur ist sinnvoll? [CB10, S. 160]
ist es schwierig, grundlegende Implementierungsdetails abzuändern, wenn diese einmal angewendet und implementiert sind. Dieser Sachverhalt legt nahe, einen vorhergehenden Planungs- und Prozessgedanken im Rahmen der architekturellen Vorgehensweise zu implementieren. BUFD und YAGNI bilden hier nur die zwei Extreme des gesamten Spektrums ab, wobei die langfristigen Kosten des Produktes bei beiden Alternativen auf einem gleichen Niveau liegen (vgl. Abbildung 2). Um eine Senkung der langfristigen Kosten erreichen zu können, bedarf es eines Modells bzw. einer Entscheidungsgrundlage, auf Basis derer die Auswahl der geeigneten IT-Architektur erfolgt, um die Produktentwicklung zu ermöglichen und Nacharbeiten zu minimieren, allerdings nicht so weit, dass nicht benötigte Artefakte erstellt werden [CB10, 159ff]. Um diese Entscheidungsgrundlage erarbeiten zu können, muss das gesamte Projekt mit Hilfe eines Projektstrukturplans in plan- und kontrollierbare Elemente untergliedert werden.
2.4 Der Projektstrukturplan
Der Projektstrukturplan, kurz PSP, ist eine Gliederungsstruktur, die innerhalb eines Projektes stattfindet. Es werden dort alle relevanten technischen, Projektmanagement- und Problemlösungsaktivitäten abgebildet. Die Überprüfung auf Vollständigkeit ge- staltet sich sehr simpel und dadurch leitet sich ein weiterer Vorteil der detaillierten Projektstrukturierung ab: Es können keine notwendigen Arbeitspakete vergessen wer- den und somit wird Termin- und Kostenüberschreitungen, sowie Qualitätsmängeln vorgebeugt.
Zunächst wird das ganze Projekt in Teilaufgaben zerlegt, um alle notwendigen Ar- beitspakete zu erfassen. Diese Aufwände der Arbeitspakete können präzise erhoben werden. Zudem wird eine Hilfestellung bei der Strukturierung des Projektablaufplans gegeben und die Unterscheidung in mögliche Teilprojekte und -aufgaben ermöglicht eine Kompetenzaufteilung des Gesamtprojekts. Es existieren drei mögliche Arten, wie ein Projektstrukturplan strukturiert sein kann; Gemischt, Objekt- und Funkti- onsorientiert.
Bedingt durch die Möglichkeiten des Projektstrukturplans kann ein Großprojekt bis in ein gewisses Detaillevel aufgespalten und auf Vollständigkeit geprüft werden. Bei dedizierten und abgrenzbaren Aktivitäten ist es möglich, eigene Kompetenzberei- che zu schaffen und so Teilprojekte innerhalb des Großprojektes zu gründen. Die Darstellung erfolgt typischerweise in einer Baumstruktur [And13, 430ff].
3 Erarbeitung einer Entscheidungsmatrix
3.1 Kritische Erfolgsfaktoren
Um eine Entscheidungsmatrix für die Wahl der geeigneten architekturellen Vor- gehensweise innerhalb eines Projektes erarbeiten zu können, müssen zunächst die kritischen Erfolgsfaktoren bestimmt werden. Nach Barry Boehm (2003) existieren fünf kritische Erfolgsfaktoren, die bei der Wahl der Projektvorgehensweise beachtet werden müssen (vgl. Tabelle 2). Diese Faktoren sind die Projektgröße, -kritikalität, -dynamik, -mitarbeiter und -kultur und werden mit ihren grundlegenden Prinzipien kombiniert, um eine gegenseitig abhängige Skalierung zu erreichen.
Das Ergebnis kann grafisch in einem Netzplan dargestellt werden. Die Faktoren der Projektgröße und -kritikalität basieren dabei auf den Ergebnissen von Alistair Cockburn [Coc01]. Die Projektkultur reflektiert die Realität, dass agile Methoden in einem chaotischen Umfeld eine höhere Erfolgsquote aufweisen, als sequentiell durchgeführte Projekte [Pet91; BT03].
Diese fünf Faktoren zeigen eine erste Tendenz für die Wahl der geeigneten IT- Architektur auf. Da ein Großprojekt mit Hilfe des in Kapitel 2.4 vorgestellten Projektstrukturplanes in 1-n Teilprojekte unterteilt werden kann, kann für jeden definierten Kompetenzbereich ein solcher Netzplan befüllt werden. Da in einem Großprojekt die einzelnen Teilprojekte voneinander abhängig sind, Faktor Agile Diskriminatoren Plangesteuerte Projektgröße Auf kleine Projekte zuge- schnitten; Vertrauen auf im- plizites Wissen schafft eine Grenze bei der natürlichen Skalierbarkeit.
Projektkritikalität Bis dato ungetestet auf dem Gebiet der sicherheitskriti- schen Produkten; Mögliche Schwierigkeiten mit einfa- chem Design und unzurei- chender Dokumentation.
Projektdynamik Das einfache Design und das kontinuierliche Refactoring sind exzellent für hoch dyna- mische Umgebungen; Es birgt jedoch die Gefahr von teuren Doppelarbeiten zu Gunsten der Systemstabilität.
Projektpersonal Benötigt kontinuierliche Präsenz von Experten (Level 2-3); Der Einsatz von, speziell nicht-agilen, unerfahrenen Personen ist riskant (Level 1B).
Projektkultur Gedeiht in einer Kultur, in der die Menschen sich wohl fühlen und durch viele Frei- heitsgrade ein hohes Maß an Selbstbestimmung aufweisen. Methoden, um große Pro- dukte zu entwickeln; Schwie- rig auf kleine Projekte zuzu- schneiden.
Methoden, um auch sicher- heitskritische Produkte zu entwickeln; Schwierig auf ge- ring sicherheitskritische Pro- dukt zu eskalieren. Detaillierte Planung und ein hohes Maß an Vorausplanung sind für ein stabiles Umfeld ausgelegt; Eine nachträgliche Dynamisierung kann teure Doppelarbeiten nach sich zie- hen.
Benötigt eine kritische Mas- se an Experten zur Definiti- onsphase; Spätere Arbeiten können mit weniger Experten vollzogen werden. Kann auch mit einem gewissen Prozent- satz an unerfahreren Perso- nen umgehen. Gedeiht in einer Kultur, in der die Menschen sich wohl fühlen und durch klare Richt- linien und Vorgehensbeschrei- bungen den Rahmen ihrer Rolle vorgegeben bekommen.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2: Krit. Erfolgsfaktoren bei der Wahl der Projektvorgehensweise [BT03, 51ff]
um den Erfolg des Gesamtprojektes sicherstellen zu können, muss dies mit Hil- fe einer Projektabhängigkeitsmatrix, wie beispielhaft in Abbildung 3 dargestellt und in die weitere Bewertung integriert werden [MC01]. Aus den Ergebnissen der Projektabhängigkeitsmatrix lassen sich zwei weitere Bewertungsgrößen ableiten: jekteinfluss“ und ”Pro- ”Projektbeeinflussung“.JehöherderEinflusseinesTeilprojektes auf andere Teilprojekte ist, desto strukturierter und sequenzieller sollte dieses Projekt vorgehen, damit die abhängigen Projekte eine möglichst gute Planungsgrundlage für ihr Teilprojekt erarbeiten können.
[...]