Lade Inhalt...

Das Änderungsmanagement in ITIL und Scrum

Über konvergente und kontroverse Aspekte in Sicherheitssystemen

Bachelorarbeit 2014 45 Seiten

BWL - Unternehmensführung, Management, Organisation

Leseprobe

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Ziel und Abgrenzung der Arbeit
1.2 Vorgehensweise
1.3 Wissenschaftliche Methoden

2 Grundlagen
2.1 ITIL Change Management
2.1.1 Change Management: Zweck und Ziele
2.1.2 Change-Management-Prozess
2.1.3 Zusammenfassung
2.2 Scrum
2.2.1 Scrum: Zweck und Ziele
2.2.2 Scrum: Prinzipien und Vorgehensweise
2.2.3 Zusammenfassung
2.3 Analysekriterien

3 Vergleich und Auswertung
3.1 Umsetzung der Änderungen unter Einhaltung des zeitlichen Rahmens
3.1.1 Change Management ITIL
3.1.2 Scrum
3.1.3 Fazit
3.2 Risikominimierung bei der Umsetzung von Änderungen
3.2.1 Change Management
3.2.2 Scrum
3.2.3 Fazit
3.3 Einhaltung der Qualität der Änderungen
3.3.1 Change Management
3.3.2 Scrum
3.3.3 Fazit
3.4 Kostenoptimale Umsetzung von Änderungen
3.4.1 Change Management
3.4.2 Scrum
3.4.3 Fazit

4 Schlussfolgerung

Anhang

Anhang A: Interview I

Anhang B: Interview II

Anhang C: Change-Management-Prozessfluss

Anhang D: Change-Autorisierungsmodell

Anhang E: Scrum-Prozessmodell

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1 Beispiel für den Prozessfluss eines normalen Change

Abbildung 2 Beispiel für ein Change-Autorisierungsmodell

Abbildung 3 Scrum-Prozessmodell

1 Einleitung

Für heutige Unternehmen ist es eine überlebenswichtige Herausforderung, schnell auf Veränderungen zu reagieren. Diese müssen möglichst risikofrei und Erfolg versprechend durchgeführt werden.1 Insbesondere die InformationstechnologieBranche (IT-Branche) ist von stetigen Veränderungen geprägt.2 In diesem Umfeld existieren verschiedene Best-Practice-Ansätze, die eine effiziente und effektive Umsetzung von Änderungen an Informationsund Kommunikationssystemen (IKS) versprechen.3 Dennoch gilt es oftmals, individuell die Balance zwischen Sicherheit und Geschwindigkeit zu finden.

Ein Ansatz mit Schwerpunkt im Bereich Sicherheit ist der de facto Standard ITIL und sein Change-Management-Prozess.4 Seine Aufgabe ist es, die Implementierung von Änderungen risikoarm und ohne Auswirkung auf die laufenden Informationsund Kommunikationssysteme zu gewährleisten.5 Im Gegenzug finden in den letzten Jahren agile Managementansätze mit Schwerpunkt auf Geschwindigkeit immer häufiger Anwendung.6 Ein Ansatz in der Softwareentwicklung ist Scrum. Er zielt darauf ab, Produkte möglichst schnell und effizient zu entwickeln – unter ständiger Berücksichtigung der Änderungswünsche der Kunden in allen Phasen der Leistungserbringung.7 In beiden Ansätzen stehen die Änderungen im Mittelpunkt. Diese Arbeit soll die augenscheinliche Widersprüchlichkeit hinterfragen und mögliche Gemeinsamkeiten aufzeigen.

1.1 Ziel und Abgrenzung der Arbeit

Im Rahmen dieser Arbeit wird das Änderungsmanagement in ITIL und Scrum auf mögliche Übereinstimmungen oder Unterschiede überprüft. Dabei steht die Umsetzung von Änderungen im Vordergrund. Unter Änderungsmanagement in ITIL ist der beschriebene Change-Management-Prozess zu verstehen. Im Rahmen dieser Arbeit wird der Begriff Change Management stets im Sinne von ITIL verwendet.

1.2 Vorgehensweise

Eingangs werden in Kapitel 1 die grundlegende Problemstellung und das Ziel der Untersuchung dargelegt. In Kapitel 2 werden relevante, theoretische Grundlagen und Zusammenhänge erläutert. Im dritten Kapitel erfolgt ein Vergleich anhand ausgewählter Kriterien und deren Auswertung. Eine Schlussfolgerung und Zusammenfassung der Ergebnisse schließt die Arbeit in Kapitel 4 ab.

1.3 Wissenschaftliche Methoden

Im Rahmen dieser Arbeit werden die Literaturrecherche und Experteninterviews als wissenschaftliche Methode angewandt. Es werden IT-Berater mit mehrjähriger Praxiserfahrung aus den Bereichen Change Management und Scrum befragt.

2 Grundlagen

Dieses Kapitel gibt einen Überblick über Change Management und das Rahmenwerk Scrum. Ebenfalls werden die begleitenden Prozesse und die jeweiligen Vorund Nachteile erläutert.

2.1 ITIL Change Management

ITIL ist eine Sammlung von Best Practices, die als Leitfaden für eine serviceorientierte IT-Organisation und Management dient. Das Rahmenwerk aktuellen Version ITIL V3 verfolgt die Ziele einer optimalen Geschäftsprozessgestaltung, der Kostenreduktion und einer verbesserten Qualität von IT-Dienstleistungen.8 Der Leitfaden basiert auf dem Servicelebenszyklus, der in fünf Phasen erfolgt: Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement.9 Die Phasen sind im Einzelnen in jeweils fünf Kernpublikationen beschrieben. Zur Vertiefung des ITIL-Rahmenwerks wird auf weiterführende Literatur verwiesen.10 Das Change Management eine Disziplin innerhalb der Service Transition. In dieser Phase sind die Leitlinien für eine möglichst reibungslose und risikoarme Einführung von neuen Services, Änderungen oder Stilllegungen der bestehenden Services mit dem Ziel der Nutzenmaximierung beschrieben. Dabei ist die Aufgabe des Change Managements, eine mehrwerterbringende Steuerung und Kontrolle aller Änderungen zu übernehmen.11

2.1.1 Change Management: Zweck und Ziele

Der Zweck des Change Managements ist, Änderungen über deren gesamte Lebensdauer hinweg zu steuern und zu verwalten. Dabei liegen die Schwerpunkte durch den Einsatz von standardisierten Vorgehensweisen auf der Minimierung von Risiken und der Maximierung des Mehrwerts für das Geschäft.12 Die grundlegende Zielsetzung besteht darin, eine kontrollierte Planung, Priorisierung, Umsetzung, Überprüfung, Dokumentation und Bewertung von Changes zu gewährleisten.13 Dies wird durch das Configuration Management unterstützt.14

Configuration Management ist eine weitere Disziplin innerhalb der Service Transition. Seine Hauptaufgabe besteht darin, jedes Configuration Item (CI)15 und dessen Konfigurationsstatus über seine gesamte Lebensdauer zu identifizieren, aufzuzeichnen, pflegen, kontrollieren und verwalten.16 Dies geschieht mit Hilfe des Configuration Management System (CMS), das das Verwalten und Auslesen von Daten ermöglicht.17 Eine der wichtigsten Komponenten des CMS ist eine Configuration Management Database (CMDB), in der alle Eigenschaften aller CIs sowie alle vorgenommenen Änderungen durch die Configuration Records aufgezeichnet werden. So stehen Change Management und Configuration Management in einem engen Zusammenhang. Das Configuration Management stellt die Basis für alle relevanten Informationen dar, die das Change Management zur Erfüllung seiner Aufgaben benötigt.18

2.1.2 Change-Management-Prozess

Dieses Kapitel bezieht sich auf die ITIL Publikation „ITIL Service Transition“. Hier wird der Change-Management-Prozess beschrieben.19

Der erste Schritt des Change-Management-Prozesses ist ein formeller Änderungswunsch in Form eines Request for Change (RFC). Hier sind die Anforderungen und die ersten Schätzungen des Aufwands und der Kosten enthalten. Als Nächstes erfolgen die Annahme und die Aufzeichnung des RFC. Hierfür müssen die Rollen und dazugehörigen Verantwortlichkeiten für die jeweiligen Aktivitäten je nach Organisationsstruktur definiert werden. Nach der Aufnahme des RFC wird ein Change Record eröffnet. Hier werden alle Informationen zum Change über seine gesamte Lebensdauer dokumentiert und sind anschließend im CMS wieder- zufinden.20 Im nächsten Schritt wird ein RFC nach Redundanz, Unvollständigkei- ten oder vorherige Ablehnung geprüft. Je nach Ergebnis der Überprüfung können RFCs zur Vervollständigung oder Budgetgenehmigung an den Auftragsteller zurückgeleitet oder abgelehnt werden. Wenn der RFC weiter bearbeitet werden kann, wird eine Bewertung, Evaluierung und Priorisierung von Auswirkungen eines Changes auf das Geschäftsgeschehen vorgenommen. Außerdem werden verschiedene Fragen zum Change beantwortet. Es werden Perspektiven wie Wichtigkeit, Dringlichkeit, Ressourceneinsatz, Nutzen oder Risiken beleuchtet. Im weiteren Verlauf wird die Risikokategorisierung eines Changes vorgenommen, beispielsweise mittels einer Kombination der möglichen Auswirkung und der Eintrittswahrscheinlichkeit dieser Auswirkung. Dadurch wird deutlich, zu welcher Risikokategorie ein Change gehört und welche hierarchische Entscheidungsebene die Genehmigung für den Change erteilen soll.21 Weiterhin lässt sich die Priorität eines Changes anhand des Auswirkungsgrades und der Dringlichkeit bestimmen. Im nächsten Schritt – nachdem die Ergebnisse der Evaluation und Priorisierung vorliegen – wird die Entscheidung zur Umsetzung oder Ablehnung getroffen. An- schließend erfolgt die Planung und Terminierung. Mehrere Changes können für die Umsetzung sinnvoll gebündelt werden. Die Reihenfolge und der Zeitplan zur Umsetzung der Changes werden vom Change Management erstellt. Auch ihr Ressourceneinsatz und ihr zeitlicher Rahmen für die Umsetzung werden geplant und festgelegt. Als Nächstes erfolgt die Autorisierung für die Buildund Test-Phase. Hier muss die Autorisierung für die Entwicklung eines Changes erfolgen. Diese hängt von der jeweiligen organisatorischen Hierarchie ab. Je schwerwiegender die möglichen Auswirkungen sind, desto höher ist die autorisierende Ebene. Wenn die Entwicklung freigegeben wurde, erfolgen das eigentliche Design und die Entwicklung eines Changes. Hier übernimmt das Change Management die Koordination und Kontrolle, dass alle Changes unter Einhaltung der Qualitätsvorgaben gründlich entwickelt und getestet worden sind. Danach erfolgt die Autorisierung für das Change Deployment, indem der „produzierte“ Change evaluiert und auf Zielsetzung und Risiken überprüft wird. Sollte der entwickelte Change die Zielsetzung nicht erreichen, dann müssen Verbesserungen vorgenommen werden, die wieder auf ihre Zielsetzung evaluiert und überprüft werden. Hier kann es zu einer iterativen Vorgehensweise kommen.22 Dabei kann es passieren, dass geplante Im- plementierungszeiten oder Releases verschoben werden. Anschließend erfolgt die Koordination des Change Deployment. Das Change Management hat die Aufgabe, sicherzustellen, dass alle Changes gemäß den geplanten Vorgaben implementiert werden. An dieser Stelle muss erwähnt werden, dass die Koordination von Build und Test, sowie die Autorisierung und das anschließende Deployment von Changes vom Release und Deployment Management übernommen werden können, falls der Change Teil eines Releases ist. Im letzten Schritt des Prozesses erfolgt die Prüfung auf den Erfüllungsgrad der Anforderungen des Changes und auf mögliche unerwartete Folgen. Wenn keine Störungen aufgetreten sind und der Auftraggeber mit den Ergebnissen zufrieden ist, kann der Change Record schlossen werden.23

2.1.3 Zusammenfassung

Aus Kapitel 2.1 lässt sich erkennen, dass das Change Management viele Vorteile in Umgang mit Änderungen bietet. Jedoch existieren auch gewisse Hindernisse.

Das Change Management in Verbindung mit einem CMS ermöglicht die Transparenz innerhalb aller Systeme. Es erlaubt, Abhängigkeiten nachzuvollziehen, sodass bei der Realisierung von Changes Potenzial genutzt und die Risiken minimiert werden können.24 Mit dem Change-Management-Prozess wird die DurchDurchführung unautorisierter Changes vermindert, da sich alle Beteiligten an eine definierte Vorgehensweise halten sollen. Dies führt dazu, dass Systemausfälle, die durch unautorisierte Änderungen verursacht worden sind, minimiert werden. Die Suche nach Fehlern, die durch eine unautorisierte Änderung entstanden sind, und deren Behebung entfallen.25 Als Folge daraus werden unnötige Kosten und der Verbrauch zusätzlicher Ressourcen vermieden und die Produktivität gesteigert.26 Durch die genaue Analyse von Änderungen werden Nutzen und Risiken bestimmt und Prioritäten gesetzt. So können die wichtigsten Änderungen zuerst bearbeitet werden. Doch die in der Literatur beschriebene Planung für die Entwicklung und Terminierung für die Umsetzung von Changes kann sich als aufwendig erweisen, da es eine langfristige Planung mit einem hohen zeitlichen Aufwand ist.27 Beim Eintreten von unerwarteten Zuständen können geplante Termine evtl. nicht eingehalten werden.28 Auch die Autorisierungsphasen für einen Change können sich auf die Schnelligkeit der Change-Implementierung auswirken.29 Des Weiteren bedarf ein funktionierender Change-Management-Prozess der Akzeptanz der Mitarbeiter, sodass es nicht zu Versuchen kommt, ihn zu umgehen.30

2.2 Scrum

Scrum ist ein agiles Rahmenwerk zum Steuern von komplexen Aufgaben. Dabei stellt es die notwendigen Rahmenbedingungen, Prozesse und Techniken zur Verfügung.31 Die Grundidee für Scrum wurde von Ken Schwaber und Jeff Sutherland aus dem Ansatz zu Produktentwicklung der japanischen Wissenschaftler H. Takeuchi und I. Nonaka abgeleitet und weiterentwickelt.32 Anfangs wurde Scrum als Prozessmodell für die Softwareentwicklung verwendet, doch im Laufe der Jahre entwickelte es sich zu einem Managementansatz und wird auch für das Steuern komplexer Organisationen eingesetzt.33 Unter Agilität ist die Fähigkeit zu verstehen, auf Veränderungen schnell zu reagieren, sie effektiv und effizient zu gestalten und daraus die möglichen Vorteile zu ziehen.34 Das Rahmenwerk stellt einen Managementansatz für die Leistungserbringung, die mit Veränderungen wächst und sich an unabsehbare Ereignisse anpasst, dar.35

2.2.1 Scrum: Zweck und Ziele

Als agiler Managementansatz, hat Scrum das Ziel, schnell, qualitativ und flexibel Produkte zu erstellen.36 Dabei bedient es sich einer iterativen, inkrementellen Vorgehensweise. Das Ergebnis eines Schritts stellt den Input für den nächsten Schritt dar, bzw. der Output des ersten Schrittes wird um den Output des zweiten Schrittes erweitert.37 Wie das im Scrum Guide beschrieben ist, wird nach jedem Schritt das Ergebnis auf die aktuelle Zielsetzung und die Erfüllung der Anforderungen überprüft. Sollten sich die Anforderungen geändert haben oder lässt sich während der Erfüllung erkennen, dass die ursprüngliche Zielsetzung nicht mehr sinnvoll ist, so können im nächsten Schritt ein schneller Richtungswechsel und eine Anpassung vorgenommen werden, um das optimale Endergebnis zu erreichen.38 Dabei werden die Optimierung der Prognosesicherheit in Bezug auf den zeitlichen Rahmen und die Qualität der Ergebnisse, die Risikominimierung, die Ergebnisse mit einem höchstmöglichen Wert zu generieren, unter der Gewährleistung einer effizienten und effektiven Leistungserbringung angestrebt.39

2.2.2 Scrum: Prinzipien und Vorgehensweise

In diesem Kapitel werden die Prinzipien und die Werkzeuge, die das Rahmenwerk Scrum ausmachen, vorgestellt. Scrum ist an eine empirische Prozesssteuerung angelehnt, der drei Prinzipien zugrunde liegen: Transparenz, Überprüfung und Anpassung.40 Diese werden als Grundlageprinzipien für das gesamte Rahmenwerk verstanden. Transparenz bedeutet, dass die wirksamen Aspekte für das Ergebnis des Verfahrens und für die Verantwortlichen sichtbar sein müssen,41 beispielsweise eine einheitliche Definition für einen Zustand, in dem die Aufgabe als erledigt gilt.42 Das Prinzip der Überprüfung besagt, dass die Ergebnisse oder Verfahrensziele ausreichend oft auf Abweichungen hin überprüft werden müssen. Falls die Abweichungen in einem inakzeptablen Bereich liegen, kommt das Anpassungsprinzip zum Einsatz und der Prozess oder der zu verarbeitende Input werden angepasst.43 Ein weiterer wichtiger Grundsatz, der im Scrum verankert ist, ist das Timeboxing. Darunter wird für die jeweilige Aktion eine fest vorgegebene Zeitspanne, die nicht überschritten werden darf, verstanden. Damit werden klare Rahmenbedingungen geschaffen und die Bedeutung des „Möglichen“ wird vermittelt.44

Die nachstehenden Beschreibungen sind an den Scrum Guide 2013 angelehnt. Die Werkzeuge des Rahmenwerkes Scrum sind das Prozessmodell und die dazugehörigen Rollen, Artefakte, Aktivitäten und Ereignisse und Regeln. Der ScrumProzess beginnt mit einer Vision oder einem Auftrag.45 Der Product Owner nimmt diesen Auftrag entgegen und überprüft ihn auf Realisierbarkeit. Er ist für die Zielerreichung gegenüber dem Auftraggeber verantwortlich. Der Product Owner for- muliert, präzisiert und priorisiert die Anforderungen im Product Backlog. In der Fachliteratur wird beschrieben, dass die Priorisierung anhand des Mehrwertes, der Risiken oder der Kosten, die mit der Verwirklichung der Anforderungen einhergehen, erfolgen.46 Das Product Backlog ist die Grundlage dafür, wie das Endergebnis aussehen soll. Hier werden die Eigenschaften, Funktionalitäten und Merkmale sowie die Verbesserungen und Korrekturen aufgelistet. Es ist keine endgültige Anforderungsspezifikation, sondern es entwickelt sich schrittweise mit jedem Inkrement. Der Product Owner ist für die Pflege, die Vervollständigung und das Management des Product Backlogs während der gesamten Auftragsabwicklung verantwortlich.

Als Nächstes wird das Product Backlog dem Team, das für die Auftragserfüllung zuständig ist, vorgestellt. Das Team schätzt gemeinsam mit dem Product Owner den für die Auftragsrealisierung notwendigen Aufwand. Dadurch werden die Kosten, die Risiken und der Aufwand des Auftrags sichtbar und je nach Organisation muss eine Budgetgenehmigung erfolgen.47 Danach nimmt das Team die Arbeit auf, welche in Sprints erledigt wird, die maximal 30 Tage dauern (Timeboxing- Prinzip). Am Anfang jedes Sprints werden eine Sprint-Planung und ein Sprint Backlog erstellt. Im Sprint Backlog werden ausgewählte Anforderungen aus dem priorisierten Product Backlog für den jeweiligen Sprint festgelegt, das sogenannte Sprint-Ziel. Zudem wird die Planung der Aktivitäten für den Sprint aufgezeichnet. Das Team verpflichtet sich, auf ein gemeinsames Ziel hinzuarbeiten, und erledigt seine Aufgaben selbstverantwortlich.48 Anschließend beginnt die Umsetzung der Anforderungen. Das Team trifft sich, an jedem Arbeitstag zur gleichen Uhrzeit für 15 Minuten zu einer Besprechung, dem Daily Scrum. Hier werden Fortschritte und Probleme identifiziert und daraus resultierende weitere Arbeiten abgestimmt. Stellt das Team während des Sprints fest, dass der Umfang der Anforderungen zu hoch oder zu niedrig ist, kann dies zusammen mit dem Product Owner in dem Sprint Backlog angepasst werden. Das Team kann auch während des Sprints die eigene Arbeit anpassen. Es muss jedoch immer das Sprint-Ziel vor Augen haben und dies am Ende erreichen. Aus den Sprint-Backlog-Einträgen lässt sich der Fortschritt der Arbeit ermitteln.49

Während des gesamten Scrum-Prozesses übernimmt der Scrum Master die Aufgabe, das Team in allen Fragen der Umsetzung zu unterstützen. Er sorgt dafür, dass die Scrum-Richtlinien eingehalten werden. Am Ende des Sprints steht ein zur Verwendung fertiges Ergebnis. Nach dem Sprint erfolgt ein Sprint Review. Hier werden dem Produkt Owner und dem Auftraggeber in einer begrenzten Zeitspan- ne die Ergebnisse vorgestellt. Das Wichtigste dabei ist, dass das Meeting kein formeller Akt ist und dass keine offiziellen Berichte erstellt werden.50 Es hat vielmehr das Ziel, das Ergebnis zu überprüfen, zu testen und Feedback zu erhalten, um das Product Backlog an die eventuellen Veränderungen anzupassen.51

Zwischen dem Sprint Review und dem nächsten Sprint erfolgt eine SprintRetrospektive durch die Teammitglieder. Hier wird die Zusammenarbeit betrachtet, um Verbesserungspotenzial zu identifizieren und im nächsten Sprint zu implementieren. Hierfür sieht Scrum einen Zeitrahmen von drei Stunden vor. 52

2.2.3 Zusammenfassung

Durch regelmäßiges Überprüfen und Anpassen, können Veränderungen schnell und effektiv realisiert werden. Der enge Kundenkontakt, der durch den Sprint Review erfolgt, ermöglicht es, die Anforderungen genau zu erarbeiten, sodass die Ergebnisse anschließend dem Kundenwunsch entsprechen. Die Kundenzufriedenheit wird gewährleistet und am Ende jeder Iteration entstehen einsatzfähige Produkte. Es werden sowohl der zeitliche Rahmen als auch der Ressourcenaufwand eingehalten, denn die notwendige Teamkapazität wird am Anfang der ProductBacklog-Erstellung festgelegt.53 Die Herausforderung ist die zielgerichtete und selbstständige Arbeit des Teams. Der Faktor Mensch ist gleichzeitig als Stärke und Schwäche zu betrachten.54 Das Schätzen und Planen von Kosten am Beginn des Auftrags erlauben jedoch keine genaue und langfristige Budgetplanung.55

2.3 Analysekriterien

Für einen erfolgreichen Betrieb von Informationsund Kommunikationssystemen (IKS) ist es notwendig, diese zu warten und die erforderlichen Anpassungen durchzuführen.56 Dabei ist es wichtig, die benötigten Veränderungen frühzeitig zur Verfügung zu stellen, sodass der Mehrwert generiert wird und die gewinn- bringenden Vorteile realisiert werden.57 Fehlfunktionen und Sicherheitslücken müssen schnellstmöglich behoben werden, sodass gravierende Serviceunterbrechungen, die einen Geschäftsschaden nach sich ziehen können, verhindert werden. Dabei müssen die Anpassungen trotz zeitlichen Drucks in der erforderlichen Qualität zur Verfügung gestellt werden.58 Nicht zuletzt müssen die Nützlichkeit und die Notwendigkeit einer Änderung immer wieder betrachtet werden, da die Umsetzung mit Kosten verbunden ist.59 Dementsprechend müssen die Änderungen innerhalb der vereinbarten Zeit und entsprechend der Kundenbedürfnisse umgesetzt werden. Ein wirtschaftlicher Einsatz von Ressourcen und eine Vermeidung von Unterbrechungen der IKS werden vorausgesetzt. Folglich steht das Änderungsmanagement vor der Herausforderung, Flexibilität und Stabilität zu vereinen.60 Um Gemeinsamkeiten und Unterschiede von Change Management und Scrum in Bezug auf das Änderungsmanagement herauszufindend, werden die Vergleichskriterien aus den beschriebenen Herausforderungen abgeleitet. Der Vergleich erhebt nicht den Anspruch auf Vollständigkeit.

[...]


1 Vgl. Bergmann, R., Bungert, M. (2011), Strategische Unternehmensführung S. 223-224

2 Vgl. Doppler, K., Lauterburg, C. (2005), Change Management, S. 21-24; Statistisches Bundesamt (2013), IKT-Branche in Deutschland 2013, (18.03.2013 Dokument 1 auf der CD)

3 Vgl. Andenmatten, M. (2008), ISO:2000 Praxishandbuch für Servicemanagement und ITGovernance, S. 22-24

4 Vgl. Stych, C., Zeppenfeld, K. (2008), S. 14

5 Vgl. Buchsein, R. at al. (2008), IT-Management mit ITIL V3, S. 54

6 Vgl. o.V., Studie: Agile Softwareentwicklung ist Mainstream (2013), http://www.heise.de/developer/meldung/Studie-Agile-Softwareentwicklung-ist-Mainstream- 912207.html (18.03.2014 Dokument 2 auf der CD)

7 Vgl. Meyer, K., et al. (2007), Entwicklung IT-basierter Dienstleistungen. Co-Design mit Software und Services mit ServCASE, S. 305-316

8 Vgl. Stych, C., Zeppenfeld, K. (2008), ITIL, S. 5-12

9 Vgl. Arraj, V., The APM Group and The Stationery Office, White Paper (2013), ITIL the basics, Compliance Process Partners, S. 3-4, (18.03.2014 – Dokument 3 auf der CD)

10 Vgl. Olbrich, A. (2008), ITIL kompakt und verständlich, 4. Auflage

11 Vgl. Rance, S., Rudd, C. (2011), ITIL Service Transition, S. 4-6, 8, 41

12 Vgl. Buchsein, R., at. al. (2008), IT-Management mit ITIL V3, S. 74-75; Stych, C., Zeppenfeld, K. (2008), ITIL, S. 72

13 Vgl. van Bon, J., at.al. (2009), Foundations in IT Service Management, S. 101; Rance, S., Rudd, C. (2011), ITIL Service Transition, S. 68-69

14 Vgl. Rance, S., Rudd, C. (2011), ITIL Service Transition, S. 98-99; Schiefer H., Schitterer, E. (2008), Prozesse optimieren mit ITIL, S. 101-102

15 CI: „bezeichnet man die Betriebsmittel und die daraus resultierenden IT Services… Jedes Betriebsmittel, dessen Existenz und Version erfasst wird ist ein CI“ (van Bon J., et al. (2006), Foun- dations in IT Service Management, S. 76

16 Vgl. van Bon J., at. al. (2006), Foundations in IT Service Management, S. 75-77

17 Vgl. Rance, S., Rudd, C. (2011), ITIL Service Transition, S. 107-109

18 Vgl. Rance, S., Rudd, C. (2011), ITIL Service Transition, S. 102-103; Buchsein, R., Machmeier, V. (2008), IT-Management mit ITIL V3, S. 53-54, 75

19 Siehe Anhang C

20 Vgl. Rance, S., Rudd, C. (2011), ITIL Service Transition, S. 82

21 Siehe Anhang D

22 Vgl. Rance, S., Rudd, C. (2011), ITIL Service Transition, S. 90

23 Der ganze Abschnitt bezieht sich auf die Quelle: Rance, S., Rudd, C. (2011), ITIL Service Transition, S. 68-105

24 Vgl. van Bon J., at.al. (2006), Foundations in IT Service Management, S. 99

25 Vgl. Stych, C., Zeppenfeld, K. (2008), ITIL, S. 76-8

26 Vgl. Linemann, G. (2006), ITIL – Change Management, S. 69-71

27 Vgl. Linemann, G. (2006), ITIL – Change Management, S. 84–86

28 Vgl. Interview I, Frage 4, Anhang A

29 Vgl. Linemann, G. (2006), ITIL – Change Management, S. 74–75.

30 Vgl. Rance S., Rudd, C. (2011), ITIL Service Transition, S. 90; Interview I, Frage 8, Anhang A

31 Vgl. Schwaber K., Sutherland, J. (2013), Der Scrum Guide, S. 3, (18.03.2014 – Dokument 4 auf der CD)

32 Vgl. Brandstäter, J. (2013), Agile IT-Projekte erfolgreich gestalten, S. 10–11

33 Vgl. o.V. Scrum.org, White Papers (2014), Agile Processes in Telecom Sales Teams, (18.03.2014 – Dokument 5 auf der CD)

34 Vgl. Highsmith, J. (2002), Agile Software Development Ecosystems, S. xxiii; Müller, W. M. (2011), Lean und Agil: Das Ganze sehen, S. 43–44.

35 Vgl. Schwaber, K., Beedle, M. (2002), Agile Software Development with Scrum, S. viii-ix

36 Vgl. Highsmith, J. (2010), Agile project management, S. 5

37 Vgl. Schwaber, K. (2003), Agile Project Management with Scrum, S. 5–6.

38 Vgl. Pichler, R. (2008), Scrum. Agiles Projektmanagement erfolgreich einsetzen, S. 3

39 Vgl. Schwaber, K., Sutherland, J. (2013), Der Scrum Guide, S. 4, 11, (18.03.2014 – Dokument 4 auf der CD); Pichler, R. (2008), Scrum. Agiles Projektmanagement erfolgreich einsetzen, S. 4-5

40 Vgl. Schwaber, K., Sutherland, J. (2013), Der Scrum Guide, S. 3-4, (18.03.2014 – Dokument 4 auf der CD)

41 Vgl. Schwaber, K. (2003), Agile Project Management with Scrum, S. 3

42 Vgl. Schwaber, K. (2003), Agile Project Management with Scrum, S. 141

43 Vgl. Schwaber, K., Sutherland, J. (2013), Der Scrum Guide, S. 16-17, (18.03.2014 – Dokument 4 auf der CD)

44 Vgl. Schwabe, K. (200), Agile Project Management with Scrum, S. 37

45 Vgl. Schwaber, K. (2003), Agile Project Management with Scrum, S. 7; Interview II, Frage 1, Anhang B

46 Vgl. Pichler, R. (2008), Scrum. Agiles Projektmanagement erfolgreich einsetzen, S. 39-48; Gloger, B. (2011), Scrum. Produkte zuverlässig und schnell entwickeln, S. 131-148

47 Vgl. Gloger, B. (2011), Scrum. Produkte zuverlässig und schnell entwickeln, S. 11; Interview II, Frage 1, Anhang B

48 Vgl. Schwaber, K., Beedle, M. (2002), Agile Software Development with Scrum, S. 51

49 Der ganze Abschnitt bezieht sich auf die Quelle: Schwaber, K., Sutherland, J. (2013), Der Scrum Guide, S. 5, 15, (18.03.2014 – Dokument 4 auf der CD)

50 Vgl. Schwaber, K. (2003), Agile Project Management with Scrum, S. 9

51 Vgl. Schwaber, K. (2003), Agile Project Management with Scrum, S. 137

52 Der ganze Abschnitt bezieht sich auf die Quell: Schwaber, K., Sutherland, J. (2013), Der Scrum Guide, S. 3-16, (18.03.2014 – Dokument 4 auf der CD)

53 Der ganze Abschnitt bezieht sich auf die Quellen: Wiedermann, R. (2009), Scrum mit User Stories, S. 25-27, 32-36; Pichler, R. (2008), Scrum. Agiles Projektmanagement erfolgreich einsetzen, S. 3-5; Interview II, Fragen 4-6, Anhang B

54 Vgl. Schwaber, K. (2003), Agile Project Management with Scrum, S. 48; Interview II, Frage 8, Anhang B

55 Vgl. Oestereich, B., Weiss, C. (2008), APM Agiles Projektmanagement, S. 307

56 Vgl. Teßmer, M. (2012), Architekturbezogene Qualitätsmerkmale für die Softwarewartung, S. 1-3, (18.03.2014 Dokument 6 auf der CD)

57 Vgl. Klose, P., et. al. (2011), Lean und Agil. Das ganze sehen, S. 48-49

58 Vgl. Köhler, P., T. (2007), ITIL, S. 94-95

59 Vgl. Teßmer, M. (2012), Architekturbezogene Qualitätsmerkmale für die Softwarewartung, S. 1-2, (18.03.2014 – Dokument 6 auf der CD); Kelter, U. (2007), Software-Wartung – Grundbegrif-fe und Einordnung, S. 3, 10, (18.03.2014 – Dokument 7 auf der CD)

60 Vgl. Bergmann, R., Bungert M. (2011), Strategische Unternehmensführung, S. 223-224

Details

Seiten
45
Jahr
2014
ISBN (eBook)
9783668972483
ISBN (Buch)
9783668972490
Sprache
Deutsch
Katalognummer
v468678
Institution / Hochschule
Hochschule RheinMain
Note
2.0
Schlagworte
änderungsmanagement itil scrum über aspekte sicherheitssystemen

Autor

Zurück

Titel: Das Änderungsmanagement in ITIL und Scrum