„Changes always happen in a project and at every project phase” [1].

Diese Aussage ist bekannt. Jede Organisation und jedes einzelne Projekt tickt jedoch anders. Betrachten wir das Änderungsmanagement in Verbindung mit dem Application Lifecycle Management (ALM), ergeben sich viele zu beantwortende Fragen:

  • Wie geht das Projekt mit Änderungen um?
  • In welchen Phasen und Entwicklungs-Disziplinen eines Projekts können welche Arten von Änderungen auftauchen? Wer wird die Änderungen bearbeiten?
  • Welche Änderung wird implementiert und wer entscheidet darüber?

Betrachten wir einmal die Gründe für Änderungen innerhalb eines Lebenszyklus einer Software mit den Phasen „Define“, „Develop“, „Operate“, „Adapt“, „Feedback“ und „Portfolio“.

ChM_im_ALM

Abbildung 1: Artefakte des Change Management im ALM

Siehe auch Beschreibung der ALM-Phasen in [2] und [3]. GründeALM_Änderungen

Abbildung 2: Gründe für Änderungen im ALM

Änderungsanfragen stellen hinsichtlich Kosten/Aufwand und Risiko die höchste Herausforderung für ein Projekt innerhalb einer Organisation dar. Änderungsanfragen müssen analysiert, bewertet und mit dem Kunden abgestimmt werden. Danach muss die Implementierung der Änderungsanfrage in Spezifikationen, User Stories etc. stattfinden. Schlussendlich kommt die Implementierung, Test und Deployment des Gesamtsystems. Hierbei werden Änderungsanfragen durch externe Stakeholder getrieben. Betrachten wir die ALM-Phase Develop oder Operate so finden Änderungen auch hier statt. Diese Änderungen dienen zum einen selbst identifizierte Fehler in der Software zu beheben und zum anderen die oben erläuterten Änderungsanfragen der Kunden zu realisieren. Projektspezifische und produktspezifische Änderungen können sich gegenseitig und gleichzeitig beeinflussen. Zum Beispiel können Ressourcen-Engpässe die Realisierung von konzeptionellen Änderungen negativ beeinflussen; eine Bewertung der strategisch oder technisch erforderliche Änderungen können so ausfallen, dass Budgetaufstockungen erforderlich sind oder eine Bewertung von unterschiedlichen Lösungsalternativen ist aufgrund von Ressourcenänderungen nicht mehr möglich. Wenn wir nun die identifizierten Gründe für Änderungen den ALM Artefakten zuweisen, erhalten wir folgendes Bild:

Artefakte_CM

Abbildung 3: Artefakte des Change Management im ALM

Strategisch, technische Änderungen aus der ALM-Phase „Portfolio“ oder konzeptionelle Änderungen aus der ALM-Phase „Define“ sind entweder durch einen Change Request eines externen Stakeholders oder durch Change Requests innerhalb der Organisation getrieben. Zudem können sich auch Defects auf konzeptionelle Änderungen auswirken.

In der folgenden Blog-Reihe beschreibe ich die einzeln definierten Artefakte innerhalb des Änderungsmanagements und gehe hierbei auf die Aktivitäten, Rollen und Zustände der Artefakte näher ein.

Quellen:

[1] Hood Colin et all: Requirements Management The interface between Requirements Development and all other systems engineering processes

[2] Harry, Brian: Building an Engineering Organization for Continuous Delivery. Redmond: Keynote ALM Summit 3th, 2013

[3] Donig, Jens: Perfekte Softwareentwicklung – Prozesse, Technologien und Methoden für erfolgreiche Softwareprojekte – Application Lifecycle Management (ALM), Symposion Publishing, Hrsg. Lang, Scherber; Düsseldorf 2013

Series Navigation#2: Der „Bug“ >>