Share ZU:
29 December 2015 @ Björn Czybik

Formale Prozesse – Hinderungsgrund in der Entwicklung?

PhasenorientiertIm Systems Engineering haben sich seit vielen Jahren phasenorientierte Vorgehensmodelle etabliert, um Entwicklungsprojekte zu strukturieren. In der Praxis findet man häufig, dass der Entwicklungsprozess formalisiert wird und sich strikt an diesen Prozess gehalten wird. In diesem Blog wollen wir anhand eines Beispiels diskutieren, welche Probleme entstehen können, wenn sich zu stark an den formalen Prozess gehalten wird.

Formaler Prozess

Ein Entwicklungsunternehmen für Produktionsstraßen hat den phasenorientierten Entwicklungsprozess aus der oberen Abbildung definiert. In jeder dieser Phasen sind verschiedene Abteilungen verantwortlich für die Anforderungsdefinition. Erst nach Abschluss einer Phase werden die Dokumente an die Abteilung(en) der nächsten Phase übergeben und die nächste Phase beginnt. In dem Beispielprojekt werden in der ersten Phase die Kundenanforderungen durch das Produktmarketing definiert. In der zweiten Phase entwickelt und bewertet die Vorentwicklung neue Konzepte. In der dritten Phase werden die Architektur und das Gesamtsystem spezifiziert. In der vierten Phase werden die Subsysteme durch die jeweiligen Fachabteilungen spezifiziert und in der fünften Phase werden die Funktionen implementiert und in Betrieb genommen.

Problem

Im letzten Entwicklungsprojekt hat man jedoch festgestellt, dass das phasenorientierte Vorgehen dazu führt, dass nicht alle Kundenanforderungen abgedeckt sind. Die Ursache der Nicht-Implementierung von Kundenanforderungen lag darin, dass die Fachexperten und Softwareentwickler erst sehr spät im Projekt involviert wurden, da sich sehr streng an den Prozess gehalten wurde. Dieses hatte zur Folge, dass Fehlannahmen durch die Vorentwicklung, Einfluss auf die Architektur des Gesamtsystems hatte, diese Fehlannahmen jedoch erst in der fünften und letzten Phase entdeckt wurden. Um jedoch das Projektende nicht zu gefährden, wurden einige Kundenanforderungen nicht implementiert.

Lösung

Phasen_inkrementell

Um frühzeitig mögliche Fehlannahmen zu vermeiden, liegt eine mögliche Lösung in sogenannten cross-funktionalen Teams, wie auch meine Kollegin in ihrem Blog zum agilen PEP schreibt. In jeder Phase werden Experten aus allen beteiligten Fachabteilungen involviert: Produktmanager, Experten aus der Vorentwicklung, Architekten, Fachexperten der Subsysteme und Softwareentwickler. Dadurch, dass bereits in frühen Phasen Experten aus verschiedenen Disziplinen / Fachabteilungen vertreten sind, können die Probleme aus verschiedenen Blickwinkeln beleuchtet werden und die jeweilige Expertise frühzeitig in die Lösung einfließen.

 

Tags

Björn Czybik

Kontaktieren Sie Björn Czybik

Björn Czybik ist als Berater und Coach im Bereich des Agilen Requirements Engineering tätig. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung und des Coachings unserer Kunden bei der kontinuierlichen Verbesserung von Anforderungen und Spezifikationen, sowie der Einführung von agilen Methoden. Durch seinen Fokus auf ein kooperatives Miteinander, findet er gemeinsam mit den Beteiligten Lösungen, um die Hindernisse bei der täglichen Arbeit aus dem Weg zu räumen. Durch seine Erfahrungen als Ingenieur der industriellen Informationstechnik in Projekten im Bereich der Automatisierungstechnik und Industrie 4.0 hat er ein tiefes Verständnis von technischen Zusammenhängen. Die Erfahrungen und Beobachtungen aus den Projekten gibt er gerne an interessierte Kunden weiter.