Die Durchführung von Softwareentwicklungs- und Integrationsprojekten ist in der heutigen globalisierten, vernetzten und zunehmend digitalisierten Welt zunehmend mit hoher Komplexität verbunden.  Dies wirkt sich auch auf die funktionalen und qualitativen Anforderungen an die neu zu integrierenden Systeme und die eingesetzten Technologien aus. Doch wann sprechen wir überhaupt davon, dass ein Projekt oder ein System komplex ist und welche Ansätze gibt es, um diese Komplexität zu beherrschen?

 

Einfache, komplizierte und komplexe Systeme

Systeme lassen sich grundsätzlich in drei verschiedene Kategorien einteilen. Es existieren einfache, komplizierte und komplexe Systeme. In der Literatur finden sich viele unterschiedliche Definitionen zum Thema Komplexität und wie Systeme danach klassifiziert werden können. Alle Definitionen identifizieren aber folgende Eigenschaften als wichtige Einflussfaktoren:

  • Anzahl der Systemelemente
  • Unterschiedlichkeit der Systemelemente
  • Interaktionsgrad der Systemelemente
  • Dynamik der Interaktionen

Um die einzelnen Einflussfaktoren veranschaulichen und mit Beispielen erläutern zu können, bedienen wir uns eines Praxisbeispiels aus unserem Projektgeschäft.

Folgend ist ein Ausschnitt einer schwer vereinfachten Systemlandschaft abgebildet. Darin zu sehen ist eine Fachapplikation, welche sich aus drei Softwarekomponenten zusammensetzt. Diese Fachapplikation erhält Stamm- und Bewegungsdaten aus einem vorgelagerten System und sendet Abrechnungsdaten an ein nachgelagertes System.

Komplexität RE

Abbildung 1: Ausschnitt Systemlandschaft

 

Anzahl der Systemelemente

Eine grosse Anzahl involvierter Systemelemente, wie beispielsweise die in Abbildung 1 aufgelisteten Softwarekomponenten, Technologien, Frameworks oder Schnittstellen, können ein System zwar unübersichtlich, schwierig zu überschauen und Änderungen aufwändig machen, jedoch führt dies noch nicht zwingend zu einem komplizierten oder komplexen System.

 

Unterschiedlichkeit der Systemelemente

Bei näherer Untersuchung der einzelnen Systemelemente kann sich jedoch herausstellen, dass sich diese inhaltlich in einem grossen Mass unterscheiden können. Diese Unterschiedlichkeit in der Ausprägung führt dazu, dass sich die Handhabung verkompliziert.

Liegt nun sowohl eine grosse Anzahl an Systemelementen, als auch eine grosse Unterschiedlichkeit dieser zueinander vor, spricht man daher nicht mehr von einem einfachen System, sondern von einem komplizierten System.

Komplexität RE

Abbildung 2: Kompliziertes System

 

Beispiel 1

Vorfälle im Betrieb der Fachapplikation haben gezeigt, dass die durch das vorangehende System gelieferten Stammdaten nicht immer der erwarteten Datenqualität entsprechen. In einem ersten Schritt soll daher die Datenanzeige der Softwarekomponente „Stammdaten“ um Filterung erweitert werden.

Obschon in dieser Softwarekomponente eine Vielzahl verschiedener Stammdaten verarbeitet und angezeigt und sich diese in den Ausprägungen unterscheiden, sind die Voraussetzungen für ein kompliziertes System nicht gegeben. In dieser Betrachtung kann das System als einfach eingestuft werden.

 

Interaktionsgrad der Systemelemente

Neben den beiden oben beschriebenen Eigenschaften, welche ein kompliziertes System ausmachen, spielt auch die Interaktion zwischen den Systemelementen eine Rolle. Es kann daher betrachtet werden, wie oft und wie stark diese Elemente miteinander interagieren. Haben Elemente starke Abhängigkeiten zueinander und beeinflussen sich in grossem Masse gegenseitig, so ist dies ein weiterer Anhaltspunkt für ein komplexes System.

 

Dynamik der Systemelemente

Sind diese Eigenschaften auch noch einer grossen Dynamik ausgesetzt, verändern sich also häufig, kann das System grundsätzlich als Komplex eingeschätzt werden.

Komplexität RE

Abbildung 3: Komplexes System

 

Beispiel 2

Die in der Fachapplikation eingesetzte Java Version 6 wird ab Dezember 2018 – auch mit dem erweiterten Support – offiziell nicht mehr unterstützt. Eine Aktualisierung der eingesetzten Java Version ist daher notwendig.

In diesem Beispiel sind sämtliche Systemelemente der Fachapplikation betroffen, welche ebenfalls unterschiedliche Ausprägungen haben. Es finden Interaktionen zwischen den betroffenen Systemelementen statt, diese ist jedoch Intensität und Häufigkeit gleichbleibend. Die Änderung wird einmal vollzogen und ist danach stabil. Sie unterliegt daher keiner speziellen Dynamik. In dieser Betrachtung kann das System als kompliziert eingestuft werden.

 

Beispiel 3

Das vorgelagerte System muss sich einem neuen, schweizweit gültigen Standard anpassen. Dieser Standard betrifft sowohl die inhaltlich gelieferten Stamm- und Bewegungsdaten, wie auch die Architektur der Schnittstelle, über welche diese Daten übertragen werden.

In diesem Beispiel sind mehrere Systemelemente, über verschiedene Systeme hinweg betroffen, welche ebenfalls unterschiedliche Ausprägungen haben. Es finden Interaktionen zwischen den betroffenen Systemelementen statt, welche sich durch die neuen Schnittstellen in Intensität und Häufigkeit ändern werden. Die Änderung wird einmal vollzogen und ist danach stabil. Sie unterliegt daher keiner speziellen Dynamik. Grundsätzlich könnte man in dieser Betrachtung anhand der Ausprägung der Einflussfaktoren auch von einem komplizierten System sprechen, wenn da nicht noch weitere Einflussfakten wären. Welche dies sind, erfahren Sie im nächsten Kapitel.

 

Eigenheiten von komplexen Systemen

Der Übergang von einfachen zu komplexen Systemen ist fliessend. Der Grad der Komplexität hängt dabei immer von der Ausgeprägtheit der vier oben genannten Einflussfaktoren. Es ist daher nur schwer möglich komplexe Systeme in ihrer Gesamtheit zu überschauen, zu verstehen und auch deren Verhalten zu prognostizieren. Es wird daher stets nur näherungsweise gelingen, diese zielgerichtet und punktgenau steuern zu können.

 

Modelle zur Einschätzung der Komplexität

Neben der Einschätzung der Komplexität über die im oberen Kapitel genannten Einflussfaktoren, stehen uns zwei in der Praxis häufig verwendete Modelle zur Verfügung, welche auf ähnlichen Prinzipien basieren aber die Beurteilung etwas anders vornehmen. Dies ist zum einen die Stacey Matrix und zum anderen das Cynefin-Modell. In diesem Blog wird dabei bewusst nur auf die Stacey-Matrix eingegangen, da diese explizit auch den immer schneller fortschreitenden technologischen Wandel berücksichtigt.

Komplexität RE

Abbildung 4: Stacey Matrix

 

Die Einschätzung des Vorhabens in die verschiedenen Bereiche der Komplexität kann dabei anhand der folgenden Kriterien erfolgen:

 

Einfache Anforderungen

Ein Vorhaben gilt als einfach, wenn die relevanten Anforderungen zu dessen Erledigung bekannt, klar, stabil und ohne grosse Abhängigkeiten zu weiteren Anforderungen sind und auf bewährten sowie im Unternehmen weitgehend bekannten Technologien und Software-Architekturen beruhen.

Bewährtes Vorgehen: Agiles oder klassisches Vorgehen ist hierzu geeignet. Das Vorhaben kann nach vorhandenen „Best Practise“ umgesetzt werden.

 

Komplizierte Anforderungen

Ein Vorhaben gilt aus Anforderungssicht als kompliziert, wenn die relevanten Anforderungen zu dessen Erledigung wenig bekannt, unklar, instabil sind oder grosse Abhängigkeiten zu weiteren Anforderungen haben. Jedoch auf bewährten sowie im Unternehmen weitgehend bekannten Technologien und Software-Architekturen beruhen.

Bewährtes Vorgehen: Es empfiehlt sich ein agiles Vorgehen in einem interdisziplinär zusammengesetzten Team. Durch das agile Vorgehen können noch unklare Anforderungen iterativ geschärft, umgesetzt und mit eng getakteten Feedbackloops, bis zur Zufriedenstellung des Kunden gebracht werden.

Sie haben noch nie von agilem Vorgehen gehört oder Ihr Wissen dazu ist bereits etwas eingerostet? Besuchen Sie unsere Blogserie „Xperts in Projektmanagement“ und erfahren Sie mehr darüber.

 

Komplizierte Technologie / Software-Architektur

Ein Vorhaben gilt aus technologischer Sicht als kompliziert, wenn die relevanten Anforderungen zu dessen Erledigung zwar bekannt, klar, stabil und ohne grosse Abhängigkeiten zu weiteren Anforderungen sind, jedoch auf neuen im Unternehmen nicht weit bekannten Technologien und Software-Architekturen beruhen.

Bewährtes Vorgehen: Es empfiehlt sich ein agiles Vorgehen in einem interdisziplinär zusammengesetzten Team. Durch den gezielten Einsatz von „Proof of Concepts“ oder Prototypen können noch nicht völlig bekannte Technologien oder Software-Architekturen analysiert und auf deren Einsatzfähigkeit geprüft werden.

 

Komplexe Anforderungen

Ein Vorhaben gilt als komplex, wenn sowohl seitens Anforderungen, als auch seitens eingesetzter Technologie und Software-Architektur mehr unklar als klar ist.

Bewährtes Vorgehen: Es empfiehlt sich ein agiles Vorgehen in einem interdisziplinär zusammengesetzten Team. Es gilt dabei, die vorhandenen Unsicherheiten so gut wie möglich zu verringern. Falls möglich, lohnt es sich, einzelne Aspekte zu isolieren und danach gezielt zu analysieren. Fundierte und auf Erfahrungen gemachte Annahmen können Sie dabei unterstützen. Schritt für Schritt kann so die Komplexität verringert werden.

 

Chaotische Anforderungen

Ein Vorhaben gilt als chaotisch, wenn sehr wenig darüber bekannt ist.

Bewährtes Vorgehen: Bevor mit dem Vorhaben gestartet wird, sollte überlegt werden, wie die noch vorhandenen Unklarheiten seitens Anforderungen oder Technologie / Software-Architektur verringert werden können. Es können dabei die gleichen Vorgehensweisen wie bei einem komplexen System genutzt werden. So lange das Vorhaben als chaotisch eingeschätzt wird, sollte damit nicht gestartet werden.

 

Stehen Sie kurz davor, ein neues Vorhaben in die Tat umzusetzen? Nutzen Sie die oben beschriebenen Methoden, um die Komplexität Ihres Vorhabens einzuschätzen und das gewählte Vorgehen zu hinterfragen.

Mit unserer langjährigen Erfahrung in den Bereichen Projektmanagement, Requirements Engineering und Business Analyse sowie Applikationsintegration unterstützen wir Sie gerne bei Ihren Herausforderungen.

Möchten Sie keinen Beitrag mehr verpassen, dann folgen Sie uns auf LinkedIn.

Jean-Marc Riser

Jean-Marc Riser

Senior Technical Consultant

 jean-marc.riser@valion.ch

Share This