1 Teil 1: Grundlagen des V-Modells

1.3 Managementmechanismen und Projektdurchführung

1.3.11 Problem- und Änderungsmanagement

In den meisten Projekten ist mit Problemen und Änderungswünschen zu rechnen, z.B. aufgrund von Fehlverhalten des Systems, aufgeschobener Fehlerbehebung, fehlender oder zusätzlich gewünschter Systemfunktionalität, Veränderungen des Umfelds bei Auftraggeber oder Auftragnehmer, Problemen mit externen Zulieferungen, Missverständnissen im Auftrag, neu erkannten Abhängigkeiten und vielem mehr. Zur geordneten Behandlung von Problemen und Änderungen enthält der Vorgehensbaustein Problem- und Änderungsmanagement allgemeine Regelungen, die im jeweiligen Projekt projektspezifisch ausgestaltet werden müssen.

Das entsprechende Thema des Projekthandbuchs legt fest, für welche Arten von Änderungen ein sogenanntes formales Problem- und Änderungsmanagement angewendet werden muss. Sinn dieser Regelung ist, dass Änderungen im Rahmen der „normalen“ Erarbeitung von Produkten oder kleinere Korrekturen und Bugfixes ohne weitere Formalismen durchgeführt werden können. Erst ab einem gewissen Fertigstellungsgrad (meist nach dem erstmaligen Erreichen des Produktzustands fertig gestellt) und nur für relevante Änderungen ist es notwendig, die Änderungen an Produkten formal zu verfolgen und nachzuvollziehen. Ziel dabei ist, Änderungen an bereits abgestimmten Informationen sauber zu dokumentieren, zu bewerten und zu kommunizieren – insbesondere, wenn sie Auswirkungen auf viele Produkte und Projektbeteiligte haben,

Im Rahmen des formalen Problem- und Änderungsmanagements wird für jede Problemmeldung bzw. jeden Änderungsantrag (siehe Produkt Problemmeldung/Änderungsantrag) ein Änderungsverantwortlicher bestimmt. Er dokumentiert und bewertet die betreffenden Inhalte und bereitet Änderungsentscheidungen vor, die dann durch die Änderungssteuerungsgruppe (Change Control Board) getroffen werden. Die personelle Zusammensetzung und Entscheidungskompetenz der Änderungssteuerungsgruppe (Change Control Board) wird im Projekthandbuch festgelegt und sollte sich an den Auswirkungen von Änderungen orientieren. In der Praxis wird man hier ein gestaffeltes Verfahren vorsehen: Beispielsweise könnten kleinere Bugfixes ohne Entscheidung durchgeführt werden, Schnittstellenänderungen eine Entscheidung der wöchentlich tagenden Architektur-Änderungssteuerungsgruppe erfordern und projektübergreifende Änderungen eine Entscheidung der übergreifenden, monatlich tagenden AG-/AN-Änderungssteuerungsgruppe.

Problemmeldungen und Änderungsanträge können während der gesamten Projektlaufzeit und während des gesamten Systemlebenszyklus auftreten und von allen Betroffenen erstellt werden, z.B. von Anwendern, SW-Entwicklern oder Ergonomieverantwortlichen. Im V-Modell sind die entsprechenden Produkte als extern gekennzeichnet, da sie nicht planbar sind und zudem nicht vom Projektteam erstellt werden können (wobei die meisten Problemmeldungen und Änderungsanträge in der Regel innerhalb des Projekts entstehen). Problemmeldungen und Änderungsanträge werden von den Änderungsverantwortlichen (Rolle Änderungsverantwortlicher) zentral über eine Änderungsstatusliste dokumentiert und verfolgt. Diese Liste gibt Auskunft über Art und Status einer Änderung, über den Stand der Entscheidungen und über die zeitliche Planung. Idealerweise ist sie nicht in Form eines Dokuments, sondern mithilfe eines Werkzeugs realisiert, um einen einfachen Zugriff für alle Projektbeteiligten zu ermöglichen.