FLOW-Patterns-Katalog -...

Institut für Praktische Informatik - Fachgebiet Software Engineering

FLOW-Patterns-Katalog

Masterarbeit von Xiaoxuan Ge

08. April 2008

2

Inhaltsverzeichnis

1 Verwendung des FLOW-Patterns-Katalogs ......................................................... 4

1.1 Wer benutzt den Katalog?.................................................................................. 4

1.2 Wie liest man den Katalog? ................................................................................ 4

1.3 Wie verwendet man gezielt den Katalog? ......................................................... 5

2 Erweiterte FLOW-Notation ................................................................................ 8

2.1 Definitionen der FLOW-Grundelementen .......................................................... 8

2.1.1 Informationsspeicher .................................................................................. 8

2.1.2 Informationsflüsse ...................................................................................... 9

2.1.3 Blackbox ...................................................................................................... 9

2.1.4 Aktivität ..................................................................................................... 10

2.2 Syntax und Semantik zur formalen Definition ................................................. 10

2.2.1 Start und Ende eines FLOW-Ausschnittes ................................................. 14

2.2.2 Belastbarkeit eines Akteurs ...................................................................... 15

2.2.3 Rolle und Gegenstand ............................................................................... 15

2.2.4 Informationsmenge .................................................................................. 16

2.2.5 Abrollen auf der Zeitachse ........................................................................ 19

3 Die FLOW-Patterns-Klassifikation .................................................................... 21

3.1 Kategorien der Mustergruppen ....................................................................... 21

3.2 Klassifikation der Muster.................................................................................. 21

3.2.1 Struktur ..................................................................................................... 22

3.2.2 Mustergruppe ........................................................................................... 23

3.2.3 Komplexität ............................................................................................... 24

3.2.4 Form .......................................................................................................... 24

3.2.5 Qualität ..................................................................................................... 25

3.3 Verwandtschaftsintensität ............................................................................... 25

3.3.1 Verwandtschaftsmatrix ............................................................................. 26

4 Die FLOW-Pattern-Schablone .......................................................................... 27

4.1 FLOW-Mustergruppe-Schablone ...................................................................... 27

4.2 FLOW-Muster-Schablone ................................................................................. 28

5 Der FLOW-Patterns-Katalog ............................................................................. 29

5.1 Mustergruppen-Katalog ................................................................................... 29

5.1.1 Parallele Flüsse .......................................................................................... 29

5.1.2 Unterbrechung .......................................................................................... 30

5.1.3 Zyklus ........................................................................................................ 31

5.1.4 Sequenz ..................................................................................................... 32

5.1.5 Hub ............................................................................................................ 33

5.1.6 Abweichung Ist-Soll ................................................................................... 34

5.1.7 Talking Only ............................................................................................... 35

5.1.8 Rollenbasierte Muster .............................................................................. 36

3

5.1.9 Mainly Writing .......................................................................................... 37

5.2 Muster-Katalog ................................................................................................. 38

5.2.1 Interaktion................................................................................................. 38

5.2.2 Ü bersprungenes Dokument ...................................................................... 43

5.2.3 Synergie ..................................................................................................... 51

5.2.4 Stille Post ................................................................................................... 57

5.2.5 Solitär ........................................................................................................ 62

5.2.6 Osmose ..................................................................................................... 66

5.2.7 Hierarchie .................................................................................................. 71

5.2.8 Dead Document ........................................................................................ 76

5.2.9 Write For One ........................................................................................... 81

5.2.10 Wiederholte Information .......................................................................... 87

5.2.11 Person als Senke ....................................................................................... 92

5.2.12 Missing Experience ................................................................................... 96

5.2.13 Permuted Order ...................................................................................... 100

5.2.14 Lightweight Documentation ................................................................... 108

5.2.15 Bürokratie ............................................................................................... 113

5.2.16 Alleinkämpfer .......................................................................................... 118

5.2.17 Wichtiges Dokument (VID) ..................................................................... 122

5.2.18 Experienced Expert ................................................................................. 126

5.2.19 Kunde zu Analytiker ................................................................................ 130

5.2.20 Analytiker zu Architekt ............................................................................ 134

5.2.21 Architekt zu Entwickler ........................................................................... 137

5.2.22 Validierung .............................................................................................. 140

6 Literaturverzeichnis ........................................................................................ 144

4

1 Verwendung des FLOW-Patterns-Katalogs

Dieser Katalog ist im Rahmen der Masterarbeit von Xiaoxuan Ge entstanden. Bei

Unklarheiten dient die Ausarbeitung der Masterarbeit als Hilfsmittel oder Nachschlagewerk

für diesen Katalog. [Ge 2008]

In Bezug auf die Verwendung des Katalogs sollen Antworten auf die drei Fragen gegeben

werden: Wer benutzt und verwendet den Katalog? Wie kann dieser Katalog gelesen

werden? Und welche Ziele können mit dem Katalog erreicht werden und wie verwendet

man ihn, um die Erreichbarkeit der Ziele sicherzustellen?

1.1 Wer benutzt den Katalog?

Alle Stakeholder eines Softwareprojektes, wie z.B. der Kunde, der Projektleiter oder die

Entwickler, die hinsichtlich Informationsflussanalyse ihre Kommunikation und

Dokumentation verbessern, optimieren oder nach Fehler bzw. Anomalien suchen wollen,

können als potentielle Anwender betrachtet werden.

1.2 Wie liest man den Katalog?

Am besten wird der Katalog mit der vorliegenden Ausarbeitung zusammen gelesen und

verwendet, da die theoretischen Grundlagen in dieser Arbeit detailierter erläutert werden.

Trotzdem kann der Katalog auch einzeln als Nachschlagewerk benutzt werden. Dennoch

wird für das bessere Verständnis das Verwenden des Katalogs zusammen mit dieser Arbeit

empfohlen.

Der Katalog kann auf unterschiedlichste Weise den Anwendern dienen. Man kann ihn von

Anfang bis Ende durchlesen, aber auch von Muster zu Muster springen. Für den Einstieg

kann man das Muster Stille Post nehmen, obwohl es nicht das erste Muster im Katalog ist.

An die Softwaretechniken denken

Beim Durchlesen und Verstehen des Katalogs immer im Hinterkopf an die Methoden,

Prozesse und Modelle der Softwareentwicklung denken und sich damit identifizieren.

Die Beschreibungen der Muster sind so formuliert, dass immer wieder an die

Techniken in der Softwareentwicklung erinnert oder beispielhaft erläutert wird.

Kurzfassung des FLOW-Patterns-Katalogs lesen

Zeitsparend kann man querschnittlich nur die Klassifikation und informale

Beschreibung der FLOW-Muster durchlesen. Dadurch kann ein guter Überblick über

alle Muster verschafft werden.

5

Bei Unklarheiten nachbohren

Bei Unverständlichkeit der Klassifizierung oder Missverständnisse der informalen

Beschreibung sollte man in die genaue Beschreibung der einzelnen Aspekte schauen.

Die Formulierung der Aspekte sind so gewählt, dass man die einzelnen Punkte

unabhängig voneinander verstehen kann, auch ohne den Kontext zu den anderen

Aspekten zu kennen.

Verwandte Muster mit untersuchen

Der Vergleich von verwandten Mustern kann zu unerwarteten Effekten führen. Denn

man denkt oft nicht an alles Wichtige und vieles wird vergessen. Bei der Anwendung

von FLOW-Mustern sollte man sich die in Relation stehenden Muster zusätzlich

anschauen um Ideen, Gedanken und Verbesserungsmöglichkeiten anzuregen.

1.3 Wie verwendet man gezielt den Katalog?

In diesem Abschnitt wird beschrieben, wie man sicherstellen kann, dass die Ziele der

Anwender erreicht werden können.

Ziel: Identifikation von FLOW-Muster in der Informationsflussanalyse

Die Voraussetzung hierfür ist alle Muster und deren Beschreibung zu kennen. Das

heißt, der Anwender sollte zumindest die Kurzfassung aller FLOW-Muster gelesen

haben. Mit diesem Wissen kann er versuchen, in einer Analyse der Informationsflüsse

ein FLOW-Modell aufstellen und die Muster darin zu identifizieren. Bei Unsicherheit

und Ungewissheit kann er immer wieder auf den Katalog zurückgreifen und nachlesen.

Ziel: Anomalien vermeiden und Kommunikationsoptimierung mithilfe des Katalogs

Mithilfe des Katalogs können Anomalien in der Kommunikation und Dokumentation

eines Softwareprojektes gezielt vermieden werden. Der Anwender sollte sich in diesem

Falle besonders an die negativen Muster aus dem Katalog erinnern und versuchen,

dieser in der Realität aus dem Weg zu gehen. Bei Bedarf kann immer noch auf den

Katalog zurückgegriffen werden.

Ziel: Suche und Auswahl von FLOW-Muster für ein bestimmtes Problem

Beim Auswählen eines Musters zum gezielten Lösen eines bestimmten Problems muss

man dazu erstmal versuchen, das Problem in den angegebenen Facetten ein wenig

einzuordnen. Dabei könnte man das Problem aus der Perspektiven Charakteristik und

Auswirkung betrachten. Somit kann man die Suche nach einem Muster, wie z.B. in den

Tabelle 1.1 und 1.2 eingrenzen. Aus einem wesentlich kleineren Kreis der Muster

könnte man gezielt in dem Katalog nachlesen und sich für ein bestimmtes Muster

entscheiden.

6

Charakteristik

Charakteristische Struktur

dominant

rezessiv

Ch

arak

teri

stis

che

Ko

mp

lexi

tät

unitär

Interaktion

Solitär

Missing Experience

Kunde zu Analytiker

Analytiker zu Architekt

Architekt zu Entwickler

linear

Stille Post

Hierarchie

Wiederholte Information

mehr-dimensional

Synergie

Dead Document

Write For One

Person als Senke

Bürokratie

Alleinkämpfer

Wichtiges Dokument

(VID)

Experienced Expert

Übersprunges Dokument

kombinatorisch

Osmose

Permuted Order

Lightweight

Documentation

Validierung

Tabelle 1.1: Zuordnung der FLOW-Muster in Dimensionen der Charakteristik

Ziel: Gemeinsame Kommunikationsbasis verschaffen

Wenn man sich in der Kommunikation mit anderen Beteiligten über ein bestimmtes

Phänomen oder Problem in der Softwareentwicklung diskutieren und austauschen

möchte, sollte man die FLOW-Muster gut studieren. Vor allem die Beispiele spiegeln

die FLOW-Muster in der Realität wider, so dass man diese Muster leichter verstehen

können. Aufbauend auf die Erkenntnisse über die Muster können die Anwender sich

besser verständigen. Der FLOW-Patterns-Katalog dient in diesem Falle als eine

Sprachgrundlage für eine unmissverständliche Kommunikation.

+ –

1

2

3

4

7

Auswirkung

Form der Auswirkung

zeitlich

quantitativ

Qu

alit

ät d

er A

usw

irku

ng

positiv

Kunde zu Analytiker



Validierung

Interaktion

Osmose

Lightweight Documentation

Wichtiges Dokument (VID)

Experienced Expert

kontext-

abhängig

Übersprunges Dokument

Hierarchie

Write For One


Permuted Order

Bürokratie

Synergie

Alleinkämpfer

negativ

Stille Post

Solitär

Dead Document

Person als Senke

Missing Experience

Tabelle 1.2: Zuordnung der FLOW-Muster in Dimensionen der Auswirkung

{1, 2,…}

P

K

N

8

2 Erweiterte FLOW-Notation

2.1 Definitionen der FLOW-Grundelementen

Grundbegriffe eines FLOW-Modells

Definition: Ein FLOW-Grundelement können folgende Objekte sein:

Informationsfluss, Informationsspeicher und Blackbox.

Definition: Mit Informationsfluss bezeichnet man der Fluss von Informationen in

einem FLOW-Modell. Informationsflüsse in einem FLOW-Modell ist immer

gerichtet.

Definition: In einem FLOW-Modell werden mit Informationsspeicher Personen, also

Akteure oder geschriebene feste Dokumente in einem Softwareprojekt bezeichnet.

Definition: Mehrere Akteure und Dokumente können auch als Akteurengruppe oder

Dokumentengruppe auftreten.

Definition: Als Informationsverlauf bezeichnet man den Verlauf von Informationen

durch die verschiedenen Informationsflüsse.

Definition: Ein FLOW-Modell muss immer ein Start- und Endzustand besitzen, um

den Informationsverlauf von Anfangs bis Ende verfolgen kann.

2.1.1 Informationsspeicher

fester Speicher flüssiger Speicher

Ein einzelnes Dokument:

<Bez. des Dokuments>

Ein einzelner Akteur:

<Bez. des Akteurs>

Mehrere Dokumente,

eine Dokumentengruppe:

{n = Anzahl der Dokumente}

(optional)


Mehrere Personen,

eine Akteurengruppe:

{n = Anzahl der Akteure}

(optional)

<Bez. des Akteurs>

Definition: Eine Bezeichnung kann sowohl ein Name, als auch eine Rolle des Akteurs

bzw. ein Gegenstand des Dokumentes sein.

Definition: Sei die Anzahl gleich n und n ist eine natürliche Zahl. Die Angabe über

die Anzahl ist optional, ohne Angabe bedeutet die Anzahl ist beliebig größer als 3:

n ∈ [3, ∞).

9

2.1.2 Informationsflüsse

Typ Projektinformationsfluss Erfahrungsfluss

fest zu fest

fest zu

flüssig

flüssig zu

fest

flüssig zu

flüssig

2.1.3 Blackbox

Notation für Blackbox

Gilt sowohl für feste als auch für flüssige Informations- und Erfahrungsflüsse:

Definition: Eine Blackbox ist ein FLOW-Element, dessen innerer Aufbau und genaue

Funktionsweise für die Semantik von FLOW unbekannt ist oder als nicht von großer

Bedeutung erachtet wird. Von Interesse ist vielmehr nur das Verhalten der Blackbox,

die über definierte In und Out Schnittstellen sicherstellt.

Definition: Der inhaltliche Aufbau und genaue Funktionsweise einer Blackbox ist

unbekannt und kann nicht in FLOW-Elementen dargestellt werden.

Definition: Die Ein- und Ausgangsflüsse können sowohl flüssige bzw. feste

Informationsflüsse sein.

Definition: An den Ein- und Ausgangsflüsse kann auch eine Bezeichnung des

Informationsinhaltes stehen.

Definition: In die Blackbox kann eine bestimmte Informationsmenge Input (In) hinein

{Eingangsmenge In}(optional)

<Werkzeug>(optional)

<Bez. Blackbox>

{Ausgangsmenge Out}(optional)

<Bez. Steuerungsfluss>(optional)

{Erfahrungsmenge E}(optional)

10

übertragen werden, und aus der Blackbox kann eine bestimmte Informationsmenge

Output (Out) heraus übertragen werden.

Definition: Ein Werkzeug bezeichnet die für die Informationsweitergabe bzw.

-übertragung eingesetzte Methoden oder Tools. Diese Angabe ist optional.

2.1.4 Aktivität

Notation für Aktivität

Definition: Eine Aktivität eines FLOW-Modells ist eine Ausführungseinheit eines

FLOW-Ablaufs. Sie ist eine Zusammenfassung von vielen FLOW-Elementen und

kann als einen bestimmten Ausschnitt eines FLOW-Modells dargestellt werden.

Definition: Eine Aktivität stellt ein gekapselter Abschnitt eines FLOW-Modells dar.

Der innere Aufbau ist bekannt und kann bei Bedarf verfeinert modelliert werden.

Definition: Eine Aktivität dient lediglich zur Zusammenfassung von verschiedenen

FLOW-Elementen und bestimmten Teilabschnitten von einem gesamten

FLOW-Modell. Sie kann jegliche Kombinationen von FLOW-Elementen enthalten.

Definition: Die Ein- und Ausgangsflüsse können sowohl flüssige bzw. feste

Informationsflüsse sein.

Definition: An den Ein- und Ausgangsflüsse kann auch eine Bezeichnung des

Informationsinhaltes stehen.



2.2 Syntax und Semantik zur formalen Definition

Bezeichnung und Bedeutung Ausdruck mit Beispiele

Anzahl der Wiederholung

Der Ausdruck in der

geschweiften Klammer wird

zum n mal wiederholt, dabei ist

n eine ganze Zahl und gilt

immer: n ≥ 1

<Bez. Eingangsinformation>(optional)

<Werkzeug>(optional)

<Bez. Aktivität>

<Bez. Ausgangsinformation>(optional)

{n ≥ 1}

11

Kombinationen der

FLOW-Elementen

Verschiedene FLOW-

Elemente werden kombiniert

und als eine Einheit weiter

verarbeitet. Mit einer

sprachlichen Beschreibung zu

einer Aktivität kann dies

ebenfalls ermöglicht werden.

Wenn diese FLOW- Elemente

in eckigen Klammern stehen,

dann werden diese als eine

Einheit gesehen.

Beispiel 1:

Beispiel 2:

Beispiel 3:

Beispiel 4:

ist äquivalent mit

Konkatenationsoperator ● Das nacheinander Platzieren

der FLOW- Elementen zu einer

Sequenz des Informations-

flusses

Beispiel:

ist äquivalent mit

und ist ebenfalls äquivalent mit

AkteurN

DokuMAkteurN

Dokument2lesen

Akteur1 DokuM Akteur2

Akteur1

DokuM

Akteur2



12

Selektionsoperator |

Auswählen bzw. Selektieren

zwischen den FLOW-

Elementen. Nur einer der Teile

darf ausgewählt werden.

Beispiel:

ist äquivalent mit

Vereinigungsoperator &

Alle FLOW-Elemente werden

verundert und ausgewählt.

Beispiel:

ist äquivalent mit

Wiederholen von

Akteuren

Beispiel:

ist äquivalent mit

und ist äquivalent mit


Akteur1 AkteurN DokuM

Akteur1 AkteurN Akteur1 DokuM

oder

Dokument&

Dokument

AkteurN

{n ≥ 3}

Dokument

Dokument

{n ≥ 3}

AkteurN

13

Wiederholen von

Informationsflüssen

Beispiel:

ist äquivalent mit

Wiederholen von

Kombinationen der

FLOW-Elementen

Ohne dem Konkatenations-

operator werden die Elementen

immer vom dem vorherigen

FLOW-Element ausgegangen,

mit dem Konkatenations-

operator ist immer eine

hintereinander Ausführung

gemeint.

Beispiel 1:

ist äquivalent mit

Dokument

Akteur1

Akteur2

Akteur3

…

{n ≥ 6}

Akteur1

Akteur1

…

…

{n ≥ 3}

Akteur1 DokuN

14

Beispiel 2:

ist äquivalent mit

2.2.1 Start und Ende eines FLOW-Ausschnittes

Start und Ende eines Informationsverlaufs

Start

Ende

Definition: Der Start eines Informationsaustauschs ist der Anfangspunkt, wo die

Informationen in dieses Modell reinfließt.

Definition: Vom Start aus könnte eine bestimmte Informationsmenge Input (In) in das

FLOW-Modell übertragen werden.

Definition: Das Ende eines Informationsaustauschs ist der Ausgangspunkt, wo die

Informationen aus dieses Modell rausfließt.

Akteur1

…

Doku1

Doku2

Doku3

{n ≥ 2}

Akteur1 AkteurN

Akteur1 Akteur2 AkteurN

…

…

…

{Eingangsmenge In}

(optional)

{Ausgangsmenge Out}

(optional)

15

Definition: In dem Ende/ Endzustand können eine bestimmte Informationsmenge

Output (Out) aus das FLOW-Modell übertragen werden.

Definition: Die Angabe über die Ein- und Ausgangsinformationsmenge ist optional.

2.2.2 Belastbarkeit eines Akteurs

Belastbarkeit eines Akteurs

Standard Ü berfordert Unterfordert

genug ausgelastet, gerade

gut ausgelastet zu sehr ausgelastet

wenig ausgelastet,

Kapazität vorhanden

Definition: Ohne Angabe über die Belastbarkeit bedeutet der Akteur befindet sich in

der Standardsituation, d.h. gerade genug ausgelastet.

2.2.3 Rolle und Gegenstand

Festzuordnung einer Rolle bzw. eines Gegenstandes

Ein einzelnes Dokument:

<Gegenstand des Dokuments>


<Rolle des Akteurs>

Mehrere Dokumente,

eine Dokumentengruppe:

{n = Anzahl der Dokumente}

(optional)

<Gegenstand des Dokuments>

Mehrere Personen,

eine Akteurengruppe:

{n = Anzahl der Akteure}

(optional)

<Rolle des Akteurs>

Definition: Um eine Rolle einem Akteur festzuzuordnen wird die Bezeichnung der

Rolle unterstrichen.

Definition: Um ein Gegenstand einem Dokument festzuzuordnen wird die

Bezeichnung des Gegenstandes unterstrichen.

16

2.2.4 Informationsmenge

Definition der Software-Quanten

Definition: Eine übertragene Informationsmenge in einem Informationsfluss ist eine

Menge von Software-Quanten. Sie stellt eine bestimmte Informationsmenge in ei-

nem FLOW-Modell dar.

Definition: Software-Quanten können sowohl Anforderungen als auch Erfahrungen

sein, die in einem FLOW-Modell fließen.

Wissenstand der Informationen in den Speichern

fester Speicher flüssiger Speicher

Ein einzelnes Dokument/Datensatz:

{K = Knowledge} oder

{∆K = Delta Knowledge}



{K = Knowledge} oder

{∆K = Delta Knowledge}

<Bez. des Akteurs>

Definition: Der Wissensstand Knowledge eines Dokumentes oder eines Akteurs wird

als optionale Angabe über dem Speicher gekennzeichnet.

Definition: Die Änderung des Wissensstandes Delta Knowledge eines Dokumentes

oder eines Akteurs wird ebenfalls als optionale Angabe über dem Speicher

gekennzeichnet. Sie gibt an, wie sich der Wissensstand geändert hat.

17

Informationsgehalt eines Informationsflusses

Gilt ebenfalls für Erfahrungsflüsse:

fester Fluss:

flüssiger Fluss:

Definition: Die Bezeichnung des Informationsinhalts ist optional und gibt eine

Beschreibung der übermittelte Information.

Definition: Die übertragene Informationsmenge ist eine Menge der

Software-Quanten.

Definition: Sei die übermittelte Informationsmenge Transferred (T), sei die

wahrgenommene Informationsmenge Received (R). Ein Teil Lost (L) der Infomationen

geht verloren, ein neuer falscher Teil Wrong (W) der Information kommnt hinzu: R =

T – L + W = T – (L – W)



Vernachlässigung von falscher Informationsmenge

Definition: Wenn nicht explizit angegeben, ist die Standard-Annahme bei den

Informationsflüssen: Pure Informationsweitergabe und Vernachlässigung von

falscher Informationsmenge

Definition: Sei die übermittelte Informationsmenge Transferred (T), sei die

wahrgenommene Informationsmenge Received (R). Ein Teil Lost (L) der

Infomationen geht verloren, ein neuer falscher Teil Wrong (W) der Information

kommnt hinzu. Der falscher Teil Wrong (W) der Information wird vernachlässigt:

R = T – L.

<Bez. Informationsinhalt>

(optional)

<Werkzeug>

(optional)

{Ü bermittelte Menge T}

(optional)

{Wahrgenommene Menge R}

(optional)

<Bez. Informationsinhalt>

(optional)

<Werkzeug>

(optional)

{Ü bermittelte Menge T}

(optional)

{Wahrgenommene Menge R}

(optional)

18

Gesonderte Notation für keine Informationsflüsse zwischen Speicher


fest

flüssig

Definition: Informationsstau bedeutet die übermittelte Informationsmenge wird nie

angekommen. D. h. T wird übermittel, aber R = 0. Es bedeutet ebenfalls, dass keine

Informationen zwischen den Speichern fließen.

Pure Informationsweitergabe vs. Kreativer Entwicklungsprozess


Pure

Informationsweitergabe

Kreativer

Entwicklungsprozess

Definition: Der Unterschied zwischen Pure Informationsweitergabe und kreativer

Entwicklungsprozess werden nur bei Informationsflüsse zwischen Akteuren

betrachtet.

Definition: Pure Informationsweitergabe bedeutet, die Information wird von einem

Akteur verarbeitet und genauso an einem andere Speicher weitergegeben. D. h. R1

wird übermittelt, der Akteur2 verarbeitet dies, und gibt diese Information unverändert

d.h. T2 =∆K = R1 weiter.

Definition: Kreativer Entwicklungsprozess bedeutet, die Information wird von einem

Akteur angenommen, im Gedanken verarbeit und kreativ weiterentwickelt. D. h. R1

wird übermittelt, der Akteur2 verarbeitet dies, und gibt mehr nützliche Informationen

weiter als er bekommen hat, d.h. T2 =∆K > R1.

Definition: Wenn nicht explizit angegeben, geht man immer von einer puren

Informationsweitergabe aus.

T R = 0 =

= R = 0 T

… T1 R1 T2 =∆K

R2

Akteur1 Akteur2

… R1 T1

Akteur2 Akteur1

R2

∆K = R1

∆K > R1

T2 =∆K

19

Akteur2

Zeit t

tflüssig-flüssig

Akteur1

Zeit t

Akteur1

Doku1

tflüssig-fest

2.2.5 Abrollen auf der Zeitachse

Notation zur Beschreibung des Zeitaufwands

Zeitachse Lebenslinie Zeitraum

Gibt den zeitlichen

Verlauf des

FLOW-Modells an

Gibt den beschränkten oder

unbeschränkten Lebensdauer eines

FLOW-Elements oder Aktivität an

Gibt einen bestimmten

Zeitraum auf der

Zeitachse an.

Zeit Informationsflusstyp Abrollen auf der Zeitachse

tflüssig-flüssig

tflüssig-fest

Zeit t

Doku1Akteur2 Aktivität1

Zeit t

tfest-fest

tOutput

20

Zeit t

Akteur1Doku1

tfest-flüssig

Zeit t

Doku2

tfest-fest

Doku1

tfest -flüssig

tfest -fest

Definition: Sei der Zeitaufwand für einen flüssigen Informationsfluss zwischen zwei

Akteure tflüssig-flüssig, und zwischen einem Akteur und einem Dokument tflüssig-fest. Sei

der Zeitaufwand für einen festen Informationsfluss zwischen einem Dokument und

einem Akteur tfest -flüssig, und zwischen zwei Dokumenten tfest -fest.

Definition: Es gilt folgendes:

tflüssig-fest> tflüssig-flüssig, mit tflüssig-fest = 2 tflüssig-flüssig

tflüssig-fest = tfest -flüssig

tfest -fest> tflüssig-fest, mit tfest -fest = 3 tflüssig-flüssig = 1,5 tfest -flüssig

21

3 Die FLOW-Patterns-Klassifikation

3.1 Kategorien der Mustergruppen

Kategorien der Mustergruppen

Definition: Es existieren drei Kategorien für die neun Mustergruppen: flussbasierte,

akteurbasierte und dokumentenbasierte Muster

Definition: Die Mustergruppen sind den drei Kategorien zugeordnet.

3.2 Klassifikation der Muster

Klassifikation

22

Definition: Die gesamte Klassifikation ist in fünf verschiedene Facetten untergeteilt.

Definition: Die Strukturfacette unterteilt die Muster in dominante und rezessive

Muster

Definition: Die Komplexitätsfacette unterteilt die Muster nochmal in: einfache,

lineare und komplexe Muster.

Definition: Die Mustergruppenfacette klassifiziert alle Muster in 9 Mustergruppen:

Parallele Flüsse, Unterbrechung, Sequenz, Zyklus, Abweichung Ist-Soll, Hub, Talking

Only, Rollenbasierte Muster und Mainly Writing.

Definition: Die Formfacette gibt Aussage darüber ob das Muster ein zeitliches, oder

quantitatives Muster ist.

Definition: Die Qualitätsfacette klassifiziert die Muster in positiven,

kontextabhängigen oder negativen Muster.

3.2.1 Struktur

Charakteristische Struktur

Faktor

Bedeutung dominant rezessiv

Beschreibung

Muster, wo die strukturelle

Definition ausreichend ist um die

charakteristische Eigenschaft von

dem Muster darzustellen und ihn

in einem FLOW-Modell als

Muster zu erkennen.

Muster, wo die charakteristische

Eigenschaft nicht durch die

strukturelle Definition sichtbar ist

und evtl. nur mit erweiterten

Aspekten sichtbar gemacht werden

kann.

+ –

23

3.2.2 Mustergruppe

Mustergruppe

Katalogdiagramm der Muster

Definition: Die Muster lassen sich als Knoten in der Hierarchie einordnen. Darüber

liegen Knoten, die Mustergruppen repräsentieren, aus denen sich die bereits bekann-

ten FLOW-Muster als Spezialisierung herleiten, das sind die eigentlichen Muster.

Definition: Jede Mustergruppe besitzt Submuster oder Muster, die zugeordnet wer-

den. Ein Muster kann aber auch mehreren Mustergruppen zugeordnet werden. Eine

Mehrfachgruppierung ist zulässig.

24

3.2.3 Komplexität

Charakteristische Komplexität

Faktor

Bedeutung unitär linear mehrdimensional kombinatorisch

Beschreibung

Bei unitären

Mustern ist die

Anzahl der

beteiligten

Informationsflüs

se begrenzt

festgelegt. Die

strukturelle

Definition ist

anzahlsmäßig

klein und daher

überschaubar.

Muster, die

eine lineare

Struktur in

der

strukturelle

n Definition

besitzen.

Muster, die aus

vielen zusammen-

wirkenden

FLOW-

Elementen

bestehen und

keine klare

strukturelle Form

besitzen.

Die

kombinatorischen

Muster werden aus

Aktivitäten und

andere FLOW-

Elementen

zusammengesetzt

und somit die

Details der

beteiligten Speicher

und

Informationsfluss

nicht bekannt ist.

3.2.4 Form

Form der Auswirkung

Darstellung

Bedeutung zeitlich quantitativ

Beschreibung

Zeitliche Muster sind die

Muster, die Auswirkung des

Musters auf das gesamte

Projekt durch die zeitliche

Abfolge der Ausführung

gekennzeichnet ist.

Bei quantitativen Mustern ändern sich

die Quantität der Informationsmenge

oder Wissensmenge nach einem

Innformationsfluss und wirkt sich

somit quantitativ auf das Projekt aus.

1 2 3 4

{1, 2,…}

25

3.2.5 Qualität

Qualität der Auswirkung

Bezeichnung

Bedeutung positiv kontextabhängig negativ

Beschreibung

wenn eindeutig

sicher, dass ein

Muster positive

Auswirkung auf

das Projekt hat

Wenn es nicht eindeutig

feststellbar ist, ob dieses

Muster negative oder positive

Auswirkung auf das Projekt

hat; Oder wenn dieses Muster

sich sowohl positiv als auch

negativ auswirken kann.

wenn eindeutig

sicher, dass ein

Muster negative

Auswirkung auf das

Softwareprojekt hat

3.3 Verwandtschaftsintensität

Verwandtschaftsintensität

Farbe

Bedeutung Sehr

verwandt verwandt

Wenig

verwandt

Nicht

verwandt disjunktiv

Beschreibung

Zwei

Muster, die

sehr ähnlich

sind

und evtl.

auch zum

selben

Supermuster

gehört.

Zwei

Muster, die

zwar nicht

zum selben

Supermuster

gehört, aber

mit einander

in

Verbindung

gebracht

werden

kann

Zwei

Muster, die

NUR zu

dem selben

Supermuster

gehört

Zwei

Muster, die

nichts

miteinander

zu tun

haben und

auch nicht

in

Verbindung

gebracht

werden

kann.

Wenn ein

Muster das

Problemmuster

und das andere

das

Lösungsmuster

vom einen ist.

P K N

26

3.3.1 Verwandtschaftsmatrix

Solitär

Hierarchie

Miss. Exp.

Perm. Ord.

Interaktion

Osmose

Synergie

Stille Post

Wdh. Inform.

Write For One

Person a. Senke

Dead Docum.

Validierung

Kunde Anal.

Analy. Archit.

Archit. Entw.

Bürokratie

Lightw. Docum.

Skip Docum.

Alleinkämpfer

Exp. Expert

Dokument (VID)

Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

alyt

.

An

alyt

. A

rch

it.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

(VID

)

27

4 Die FLOW-Pattern-Schablone

4.1 FLOW-Mustergruppe-Schablone

Aspekte Bemerkung

Mustername Vermittelt knapp den wesentlichen Gehalt des Musters, mit

bildlicher Darstellung

Kategorie Zu welcher Kategorie gehört diese Mustergruppe?

Beschreibung In diesem Abschnitt wird das Muster in der natürlichen Sprache

beschrieben

Struktur Angabe über eine Allgemeine Definition der für alle Muster in

dieser Mustergruppe.

Beschreiben in FLOW-Modell, FLOW-Notation, in Kombination

mit einer Regulären Ausdrücken ähnlicher Notation.

Verweis auf Muster Welche Muster besitzt diese Mustergruppe?

Muster

28

4.2 FLOW-Muster-Schablone

Aspekte Bemerkung

Mustername Vermittelt knapp den wesentlichen Gehalt des Musters, mit bildlicher

Darstellung

Klassifikation Zu welcher Facettenklassifikation gehört dieses Muster?

Struktur

Komplexität

Mustergruppe

Form

Qualität

Metapher Wie entsteht dieses Muster? Welche Metapher steht dahinter?

Beschreibung In diesem Abschnitt wird das Muster in natürlicher Sprache informal

beschrieben

Charakteristik

Struktur Beschreiben in FLOW-Modell, FLOW-Notation, in Kombination mit

einer Regulären Ausdrücken ähnlicher Notation.

Komplexität Begründen, warum das Muster diese Komplexität besitzt. Wie komplex

ist dieses Muster?

Mustergruppe Begründen, warum dieses Muster zu diesen Mustergruppen gehört.

Auswirkung

Form In welcher Form ist dieses Muster? Warum besitzt das Muster diese

Form?

Qualität Über die Qualität diskutieren, in Hinblick auf:

Wenn PM, dann evtl. Problemmuster angeben oder

Problemsituation beschreiben

Wenn KM, dann evtl. auftretende Auswirkung beschreiben, sowohl

positiv als auch negativ

Wenn NM, evtl. Lösungsvorschlag oder Lösungsmuster angeben

Vor- und Nachteile des Musters schildern

Diskussion

Verweis auf

Muster

Verwandtschaftsintensität

Welches andere Muster dieses Katalogs steht mit diesem Muster in

Beziehung? Und in was für einer Beziehung? Verwandtschaft oder

Disjunktion?

Mit Angabe von Verwandtschaftsmatrix.

Auftreten Unter welcher Situation kann dieses Muster vorkommen? Wo kann man

meistens dieses Muster vorfinden?

Beispiele Dokumentation von Anwendungsbeispiele in der Praxis

Sonstige

Bemerkung

Zusätzliche Informationen über das Muster oder Umfeld

29

5 Der FLOW-Patterns-Katalog

5.1 Mustergruppen-Katalog

5.1.1 Parallele Flüsse

[Quelle: http://home.arcor.de/d.mietke/analog/an_pict/i_mess.gif]

Zwei Widerstände werden parallel geschaltet. Der Strom teilt sich auf und fließt durch beide

Widerstände.

Kategorie Flussbasierte Muster

Beschreibung Die Mustergruppe Parallele Flüsse beschreibt also das Phänomen in einem

FLOW-Modell, wo Informationsflüsse parallel in gleicher Richtung vom

selben Startakteur zum gleichen Endakteur verlaufen. Die parallel

verlaufenden Informationsflüsse können sowohl fest als auch flüssig sein.

Struktur Bei Parallele Flüsse stehen die parallel verlaufenden Informationsflüsse

im Mittelpunkt.

Allgemeine Definition:

Verweis auf

Muster

Zur Mustergruppe Parallele Flüsse gehören folgende Muster:

Skip Document



AkteurN

{n ≥ 1}

ParallelerFluss 1

AkteurM

{n ≥ 1}

Paralleler Fluss 2

Fluss

30

5.1.2 Unterbrechung

[Quelle: www.der-eiserne-rhein.de/erb_weblog_archiv2005.htm]

Diese Unterbrechung der Eisenbahnstrecke entsteht durch eine Baustelle.


Beschreibung Im Allgemeinen ist eine Unterbrechung ein Abbrechen des bisher

fortgesetzte Tätigkeit oder Sachverhalte. Für eine Unterbrechung gibt es

immer ein Grund, bzw. eine Ursache. In der Informatik versteht man unter

Unterbrechung (Englisch: Interrupt) ein kurzfristiges Abbrechen eines

Programms durch eine von der CPU abzuarbeitende Befehlssequenz. In

FLOW ist Unterbrechung eine Mustergruppe, wo der Informationsfluss an

eine Stelle unterbricht, d.h. er versiegt an dieser Stelle, was resultierend zu

Problemen führen könnte.

Struktur Der Informationsfluss versickert an einer Unterbrechung.


Verweis auf

Muster

Zur Mustergruppe Unterbrechung gehören folgende Muster:

Person als Senke

Dead Document

Solitär

Unterbrechung

Fluss

31

5.1.3 Zyklus

[Quelle: http://www.hrudifisch.de/html/coaching/COACHING2.jpg]

Herr Schlaumeier spielt mit den Domino-Steinen. Mit einem Stoß bringt er die Steine zum

Fallen. Nach einem Zyklus kommen die Steine zum Ausgangspunkt zurück und der letzte

Stein wird ebenfalls umgeworfen.


Beschreibung In der Graphentheorie bezeichnet man eine Kantenfolge, deren Start- und

Endknoten identisch sind, als eine geschlossene Kantenfolge oder besser

als einen „Zyklus“. In FLOW bildet Zyklus einen Informationsfluss, der

über andere Akteure verläuft und letztendlich wieder zu dem Starakteur

zurückkehrt.

Struktur Die Informationsübertragung in Zyklus bildet einen Kreislauf der

Informationsflüsse.


Verweis auf

Muster

Zur Mustergruppe Zyklus gehören folgende Muster:

Interaktion

Validierung

Kunde zu Analytiker



AkteurN

{n ≥ 1}

Schleife1

AkteurM

{n ≥ 1}

Schleife2

Fluss

32

5.1.4 Sequenz

[Quelle: http://www.scout-out.ch/download/picts/sequenz.jpg]

Ein Foto- Sequenz von Snow-Boarding.


Beschreibung Mit dem Begriff „Sequenz“ bezeichnet man eine Aufeinanderfolge von

Gleichartigen. In FLOW ist eine Sequenz eine Abfolge von bestimmte

FLOW-Elementen oder FLOW-Kombinationen, das sich wiederholt und

somit eine kettenförmige Informationsübertragung entsteht.

Struktur Der Informationsfluss in FLOW bildet eine Sequenz mit flüssigen oder

festen linear übertragene Informationen.


Verweis auf

Muster

Zur Mustergruppe Sequenz gehören folgende Muster:

Stille Post

Hierarchie

Bürokratie

Sequenz1 SequenzN

{n ≥ 2}

Fluss

33

5.1.5 Hub

[Quelle: http://www.towanet.de/dateien/main_bottom-dateien/images/stern_top.gif]

Ein Computerhub wird aus 64 gewöhnliche Computer gebaut. der Regel sind die einzelnen

Elemente eines Hubs untereinander über ein schnelles Netzwerk verbunden.


Beschreibung Ein Hub ist ein wichtiger Kommunikationsknoten in einem Netzwerk, der

einer Stern-Topologie entspricht. Meistens beteiligen sich an einem Hub

mehrere Knoten, die physisch sternförmig mit dem Hub verbunden werden.

In FLOW ist bezeichnet Hub eine Mustergruppe, die aus vielen zu einem

Speicher führenden Informationsflüssen besteht.

Struktur Ein Speicher steht im Mittelpunkt und wird von vielen

Informationsflüssen umschlossen. Das heißt dieser Speicher ist sehr viel

genutzt und ist strukturell sehr auffällig in einem FLOW-Modell.


Verweis auf

Muster

Zur Mustergruppe Hub gehören folgende Muster:

Experienced Expert

Alleinkämpfer

Wichtiges Dokument (VID)

{n ≥ 3}

Akteur Dokument

Fluss

34

5.1.6 Abweichung Ist-Soll

[Quelle: http://static.twoday.net/jackie/images/Toffifee-Vergleich.jpg]

Ich wollte ein Toffiffee mit eigenen Zutaten nachmachen. Leider weicht meine nachgemachte

Kopie in der Größe und Geschmack vom Originalen ab.


Beschreibung Wie bereits der Name dieser Mustergruppe schon andeutet, weichen die

Ist-Situationen der Muster in Abweichung Ist-Soll von den Soll-Situationen

ab. Die Ursachen können unterschiedlich sein und werden in den Mustern

ausführlich beschrieben.

Struktur Allgemeine Definition:

Verweis auf

Muster

Zur Mustergruppe Abweichung Ist-Soll gehören folgende Muster:

Skip Document

Write For One

Permuted Order

Missing Experience

≠Soll-FLOW-Modell

Ist-FLOW-Modell

Fluss

35

5.1.7 Talking Only

[Quelle: http://www.f1online.de/premid/000183000/183814.jpg]

Das Projektteam hat sein regelmäßiges Meeting immer dienstagmorgens.

Kategorie Akteurbasierte Muster

Beschreibung Nur flüssige Informationsflüsse um Akteure herum tauchen in dieser

Mustergruppe Talking Only auf. In Muster dieser Mustergruppe haben

viele direkte und flüssige Kommunikationen zwischen Akteure

stattgefunden.


Im Mittelpunkt stehen die Akteure und flüssigen Informationsflüsse. Die

Muster in dieser Mustergruppe bestehen ausschließlich aus Akteure und

flüssigen Informationsflüsse.

Verweis auf

Muster

Zur Mustergruppe Talking Only gehören folgende Muster:

Stille Post

Synergie

Osmose

Akteur

36

5.1.8 Rollenbasierte Muster

[Quelle: http://www.wetteraukreis.de/imperia/md/images/erleben/kultur/theater_mimikri_490x326.jpg]

Benjamin in seine Rolle als König muss er gewisse Pflichten erfüllen.

Kategorie Akteurbasierte Muster

Beschreibung In der Mustergruppe Rollenbasierte Muster sind Muster zusammengefasst,

die rollenbedingt existieren.


In Muster dieser Mustergruppe müssen bestimmte Rollenvorgabe

definiert, d.h. diese Muster sind rollenabhängig. Ohne die rollenbedingte

Definition würden die Muster keinen Sinn ergeben.

Verweis auf

Muster

Zur Mustergruppe Rollenbasierte Muster gehören folgende Muster:

Hierarchie

Validierung

Kunde zu Analytiker



Akteur

37

5.1.9 Mainly Writing

[Quelle: http://www.verocel.com/images/documentation.jpg]

Nachdem ein Projekt beendet ist, werden sehr viele geschriebene Dokumentationen aus dem

Projekt archiviert.

Kategorie Dokumentenbasierte Muster

Beschreibung Wie der Name Mainly Writing schon aussagt, beteiligen sich bei diesen

Muster mehr Dokumente als Akteure, bzw. mehr feste Informationsflüsse

als flüssige. Das heißt im Mittelpunkt der Muster in dieser Mustergruppe

stehen hauptsächlich das Erzeugen der Dokumente und die

Informationsflüsse um ein Dokument herum.


Die Muster in dieser Mustergruppe basieren auf Dokumenten und

fokussieren mehr auf das Erzeugen der Dokumente.

Verweis auf

Muster

Zur Mustergruppe Mainly Writing gehören folgende Muster:

Bürokratie

Lightweighted Documentation

Write For One

Dokument

38

5.2 Muster-Katalog

5.2.1 Interaktion

[Quelle: http://www.heile-welt.de/Archiv/life/pages/Kommunikation_jpg.htm]

Wolfgang führt gerade ein interaktives Gespräch mit Dieter.

Klassifikation Struktur:

Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster

unitäres Muster

Zyklus

quantitatives Muster

positives Muster

Metapher Der Begriff „Interaktion“ bezeichnet das wechselseitige aufeinander

Einwirken von Akteuren oder Systemen und ist eng verknüpft mit den

übergeordneten Begriffen Kommunikation, Handeln und Arbeit. In der

Soziologie und Psychologie handelt es sich um einen geläufigen Terminus,

mit dem "aufeinander bezogenes Handeln zweier oder mehrerer Personen"

oder die "Wechselbeziehung zwischen Handlungspartnern" bezeichnet

wird. In der Informatik ist der Begriff der Interaktion mit dem Begriff der

Kommunikation identisch: er befasst sich damit, wie einzelne

Komponenten eines Systems sich gegenseitig beeinflussen bzw.

miteinander kommunizieren.

Beschreibung In einem FLOW-Modell ist Interaktion ein Muster, wo zwei Akteure direkt

miteinander kommunizieren. Man spricht hier auch von einer synchronen

Kommunikation zwischen den beiden Akteuren. Wenn ein Akteur direkt

mit einem anderen Akteur flüssig kommuniziert, wie z.B. in einem

persönlichen Gespräch, und der zweite Akteur daraufhin synchron

interagiert, wie z. B. per Telefonat antwortet, dann ist das eine Interaktion.

Es ist ebenfalls eine Interaktion, falls der zweite Akteur in schriftlicher

Form auf das Gespräch reagiert, bzw. während des Gesprächs synchron

mitschreibt. Bei diesem Muster ist es besonders zu erwähnen, dass die

Interaktion nicht unbedingt nach einem Schritt vorbei ist. Es zeichnet

gerade dieses Muster aus, die wechselseitige synchrone Kommunikation

{1, 2,…}

+

1

P

39

zwischen den beiden Akteuren andauert und dass dadurch beide Akteure

nach der Interaktion über mehr Wissen und Informationen verfügen als

vorher.

Charakteristik

Struktur Dominantes Muster

Es existieren zwei Akteure, die direkt miteinander kommunizieren

Beide Akteure können sowohl Start- als auch Endakteur sein.

Es müssen Informationsflüsse vorhanden sein, die diese beiden

Akteure direkt miteinander verbinden.

Einer der beiden Informationsflüsse muss flüssig sein. Der andere

Fluss kann sowohl flüssig als auch fest sein.

Definition 1: Beide Informationsflüsse flüssig

Definition 2: Ein flüssiger und ein fester Informationsfluss

Interaktion ist ein dominantes Muster. Wenn die oben dargestellte

Definition in einem FLOW-Modell auftritt, dann kann man schon anhand

der Struktur aussagen, dass das Muster eine Interaktion ist.

Komplexität Unitäres Muster

In der Komplexitätsfacette gehört dieses Muster zu den unitären Mustern,

aufgrund der wenigen notwendigen Akteuren und Informationsflüssen, die

laut der strukturellen Definition vorhanden sein müssen.

Mustergruppe Zyklus

Die Mustergruppe Zyklus definiert die Muster, die in Kreislauf fließenden

Informationsflüsse besitzen. Dazu gehört eindeutig Interaktion.

Auswirkung

Form Quantitatives Muster

Interaktion ist ein quantitatives Muster. Denn die Auswirkung der

Interaktion kann zu einem kreativen Entwicklungsprozess führen, der

wiederum quantitativ eine Wissenszunahme der Akteure bedeutet. Eine

besondere Eigenschaft von diesem Muster ist die immer wiederkehrende

wechselseitige Kommunikation zwischen den beiden Akteuren. D. h. die

Informationsflüsse fließen meistens nicht einmal, sondern mehrere Male

und immer wieder.

Akteur1 Akteur2

Doku1

Akteur1 Akteur2

1

{1, 2,…}

+

40

Es kann dabei von einer puren Informationsweitergabe ausgegangen

werden, dann wird die Übertragung der Informationsmenge

folgendermaßen aussehen:

Dadurch, dass die beiden beteiligten Akteuren viele Informationen

ununterbrochen austauschen, kann bei der Interaktion auch von einem

kreativen Entwicklungsprozess ausgegangen werden, wie folgt:

Qualität Positives Muster

Interaktion ist ein Muster mit positiver Auswirkung. Immer wenn

Interaktion in einem FLOW-Modell auftritt, kann man positiv über die

Kommunikation der Akteure in dem Softwareprojekt aussagen. Es ist

immer positiv zu erkennen, dass zwischen zwei Akteure nicht nur flüssige

Information in eine Richtung fließt, sondern auch noch in die andere

Richtung. Dies kennzeichnet eine Rückmeldung bzw. Bestätigung des

geflossenen Informationsflusses. Somit kann immer der

Informationsgehalt bestätigt werden um Missverständnisse vorzubeugen.

Interaktion führt auch zu engere Kommunikation der Akteure und unter

Umständen auch zu kreativer Entwicklungsprozess. Und laut Definitionen

können sogar flüssige Informationen verfestigt werden. Somit können

Informationen auch für später nachvollziehbar gemacht werden.

Diskussion

Verweis auf

Muster

Verwandtschaftsintensität:

Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

T1 R1

Akteur1 Akteur2

T2R2

T1 R1

Akteur1 Akteur2

T2R2

P

∆KAkteur2=R1

∆KAkteur1=R2

∆KAkteur1>R2

∆KAkteur2>R1

41

Wenig verwandt mit Validierung:

Mit diesen Mustern gehört Interaktion zur selben Mustergruppe.

Verwandt mit Synergie:

Synergie besitzt ebenfalls interaktive Eigenschaften. Bei ihr wird auch

etwas Kreatives entstehen und eine Wissenszunahme der Akteure

erwartet.

Sehr verwandt mit Kunde zu Analytiker, Analytiker zu Architekt und

Architekt zu Entwickler:

Mit diesen Mustern gehört Interaktion zur selben Mustergruppe

Zyklus. In gewisser Weise kann man die letzten drei Muster als eine

spezielle Interaktion zwischen bestimmte Rollen vorstellen, da sie

ebenfalls interaktive Eigenschaften besitzen.

Gegensätzlich und disjunkt mit Solitär, Hierarchie, Stille Post, Write

For One, Person als Senke, Wiederholte Information und Bürokratie:

Interaktion kann als Lösungsmuster für viele Muster vorgeschlagen

werden.

Interaktion kann als Lösungsmuster für Solitär vorgeschlagen werden.

Die solitäre Person sollte einfach mehr mit den anderen Akteuren

interagieren.

Bei den Mustern Stille Post, Bürokratie und Hierarchie könnte die

sequentielle Informationsübertragung zu Informationsverfälschung

und -verluste führen. Mit einer Interaktion könnte eine direkte

Kommunikation erzwungen und damit das Problem gelöst werden.

Write For One ist von seiner Auswirkung her als negatives Muster

eingestuft. Als Lösungsvorschlag ist eine direkte Kommunikation zu

dem einzigen Zielakteur gegeben. In diesem Falle würde eine

Interaktion dieselbe positive Auswirkung erzielen, sie bietet sogar

noch weitere Möglichkeiten um sich Feedback von dem Zielakteur

geben zu lassen.

Mit einer Interaktion kann eine Wiederholung der Information in

Wiederholte Information durch Feedback-gebende Flüsse gestoppt

werden.

Eine Person als Senke würde durch eine Interaktion seine Einstufung

als Informationssenke endgültig verlieren. Genauso kann es bei Solitär

auch der Fall sein. Denn durch Interaktion muss die agierende Person

Informationen von sich an andere übertragen, was positive

Auswirkung auf das Projekt erzielt.

Auftreten Eine Interaktion ist ein sehr wichtiger Bestandteil einer Kommunikation,

deshalb ist sie ein sehr wichtiges und grundlegendes Muster in FLOW.

Interaktionen fördert die Kommunikation und ermöglicht schnelles

Handeln. Hinzukommt, dass Interaktion ein sehr einfaches Muster ist.

Daher begegnet uns dieses Muster mit einer einfachen Definition immer

42

wieder in der Softwareentwicklung, was auch gut ist.

Beispiele Da die Muster Kunde zu Analytiker, Analytiker zu Architekt und Architekt

zu Entwickler als eine spezielle Interaktion zwischen bestimmte Rollen

angesehen werden können, wird an dieser Stelle auf diese Muster

verwiesen [siehe Kunde zu Analytiker, Analytiker zu Architekt und

Architekt zu Entwickler].

43

5.2.2 Ü bersprungenes Dokument

[Quelle: http://www.reitzentrum-doktorbauer.at/images/ludwig_springen.jpg]

Der Hengst Ludwig überspringt mit Mühe das Hindernis. Klassifikation Struktur:

Komplexität:

Mustergruppe:

Form:

Qualität:

rezessives Muster

mehrdimensionales Muster

Abweichung Ist-Soll, Parallele Flüsse

zeitliches Muster

kontextabhängiges Muster

Metapher Ein Dokument zu überspringen bedeutet meistens im täglichen Gebrauch,

dass das Dokument fehlt im Vergleich zu einer bestimmten

Standardeinstellung. Dieses Dokument wurde entweder einfach vergessen,

aus einem bestimmten Grund weggelassen oder zu einem späteren

Zeitpunkt nachträglich erzeugt. Bei der Vergessenheit verbindet man das

Überspringen des Dokumentes häufig mit negativer Auswirkung. Jedoch

wurde das Dokument mit Absicht gestrichen oder nicht erzeugt, ist dieses

Überspringen also begründet, dann kann man mit positiver Auswirkung

rechnen, wie z.B. Zeit gespart etc.

Beschreibung In einem FLOW-Modell ist Übersprungenes Dokument ein Muster, wo ein

Dokument bei der Erzeugung übersprungen wurde und dann hinterher

erzeugt oder gleich weggelassen wird. Ein oder mehrere Akteure sollten

ein Dokument erzeugen und dieses Dokument wird von einem anderen

Akteur oder vielen anderen Akteure gelesen und verwendet. Aber

eigentlich wurde das Dokument erst hinterher erzeugt und die in dem

Dokument enthaltenen Informationen wurden schon früher mündlich an

den Akteuren weitergegeben. Es begründet, warum dieses Muster zu der

Mustergruppe Abweichung Ist-Soll gehört. Die Ist-Situation weicht also

von der Soll-Situation ab. Wenn diese Abweichung begründet ist, d.h. sie

ist gewollt, dann wirkt Übersprungenes Dokument sich positiv auf das

Projekt aus. Wie z.B. das Dokument wird erst im Nachhinein erstellt um

das Prozessmodell zu befriedigen. Wenn aber das Dokument aus

Vergessenheit übersprungen wurde und gar nicht oder erst nach Bemerken

nachträglich erstellt wird, dann wirkt sich dieses Muster definitiv negativ

–

3

K

44

auf das Projekt aus, denn dadurch ist Zeit verloren gegangen. Wenn aber

absichtlich ein Dokument gestrichen und während der Entwicklung als

überflüssig empfunden wird, dann ist wieder das Übersprungenes

Dokument ein positives Muster.

Charakteristik

Struktur Rezessives Muster

Es existieren mehr als zwei Akteure dessen Reihenfolge bestimmt ist.

Ein direkter flüssiger Informationsfluss verläuft von den ersten

Akteuren zu den empfangenen Akteuren.

Die eine Akteurengruppe kann ein schriftliches Dokument erzeugen

Dieses erzeugte Dokument wird von einem oder mehreren Akteuren

gelesen oder verwendet

Definition 1: Nachträglich wird ein Dokument erzeugt

Variante 1:

Definition 2: Nachträglich wird kein Dokument mehr erzeugt.

Variante 2:

Durch die obere strukturelle Definition ist es in einem FLOW-Modell nicht

eindeutig zu erkennen, ob es sich um ein Übersprungenes Dokument

handelt oder nicht. Erst mit der Betrachtung des zeitlichen Aspekts wird

das Muster erkenntlich gemacht [siehe Aspekt Mustergruppe].

{n ≥ 1}

AkteurN AkteurMDoku1

{n ≥ 1}

Akteur1 Akteur2Doku1

{n ≥ 1}

AkteurN AkteurMDoku1

{n ≥ 1}

Akteur1 Akteur2Doku1

–

45

Komplexität Mehrdimensionales Muster

In der Komplexitätsfacette gehört dieses Muster zu den

mehrdimensionalen Mustern. Die beteiligten Akteure sind in der Anzahl

nicht begrenzt. Die Informationsflüsse fließen zwar in einer Richtung, aber

sie fließen parallel und nicht linear. Deshalb wird Übersprungenes

Dokument zu den mehrdimensionalen Mustern zugeordnet.

Mustergruppe Parallele Flüsse, Abweichung Ist-Soll

In der Mustergruppefacette gehört Übersprungenes Dokument zur

Mustergruppe Parallele Flüsse, denn es stimmt mit dessen Definition

überein, dass ein fester und flüssiger Fluss parallel in gleicher Richtung

vom selben Speicher zum gleichen Zielspeicher verläuft.

Übersprungenes Dokument gehört ebenfalls zur Mustergruppe

Abweichung Ist-Soll. Das FLOW-Modell des Musters ist zwar bestimmt,

aber hieraus kann leider der zeitliche Aspekt nicht erkannt werden, welche

der Informationsflüsse zeitlich zuerst geflossen ist. Im Folgenden wird die

Soll- und Ist-Situation verglichen und die FLOW-Darstellung des Musters

wird auf die Zeit abgerollt. Hierbei werden die oberen vereinfachten

Varianten gewählt. Im folgenden ist eine mögliche Soll-Situation

dargestellt

Soll-Situation: Der flüssige Informationsfluss von Akteur1 zu Akteur2

könnte auch erst nach dem Lesen des Dokuments von Akteur2 an

Akteur2 übermittelt werden.

Ist-Situation 1: Für den Fall, dass nachträglich kein Dokument mehr

erzeugt wird, d.h. das Dokument wird einfach gestrichen.

Zeit t

Akteur1 Akteur2

Doku1

3

46

Ist-Situation 2: Für den Fall, dass nachträglich ein Dokument erzeugt

wird.

Aus dem Vergleich der Soll und Ist-Situation kann man erkennen, dass das

Dokument in der Ist-Situation entweder gar nicht oder zeitlich viel später

erzeugt wurde.

Auswirkung

Form Zeitliches Muster

Übersprungenes Dokument ist eindeutig ein zeitliches Muster. Der

zeitliche Aspekt wurde bereits in dem Vergleich der Soll- und Ist-Situation

betrachtet. In diesem Abschnitt wird der zeitliche Aspekt t noch mal für

die oben dargestellten Situationen analysiert.

Soll-Situation: Ein Dokument sollte erzeugt werden. Dabei beträgt die

Zeit bis das Wissen des zweiten Akteurs weiterübertragen werden

kann: tOutput_Soll. Das Dokument sollte bereits existieren, wenn Akteur2

sein Wissen weiter vermittelt. Also beträgt die Zeit bis das Dokument

erstellt ist: tDoku_Soll. Es folgt offensichtlich tOutput_Soll >tDoku_Soll.

Zeit t

Akteur1 Akteur2

Doku1

Zeit t

Akteur1 Akteur2

Doku1

47

Ist-Situation 1: Das Dokument wird nachträglich erzeugt. Daraus folgt

tOutput_Ist1<tDoku_Ist1. Im Vergleich mit der Soll-Situation folgt:

tOutput_Ist1<tOutput_Soll, tDoku_Ist1 >tDoku_Soll. Bei der nachträglichen

Erstellung des Dokumentes passiert das Übermitteln der

Informationen von Akteur2 viel früher als in der Soll-Situation, was zu

einer Einsparung der Zeit führen kann. Andererseits wird das

Dokument viel später erstellt.

Ist-Situation 2: Das Dokument wird gestrichen und gar nicht erst

erzeugt. Man kann eindeutig erkennen, dass tOutput_Ist2 deutlich kleiner

ist als tOutput_Soll: tOutput_Ist2 <tOutput_Soll. Das bedeutet, wenn ein

Dokument gar nicht erst nacherstellt wird, deutlich kleiner

tOutput

Zeit t

Akteur1 Akteur2

Doku1

tDoku

Start

Ende

Zeit t

Akteur1 Akteur2

Doku1

tOutput

tDoku

Start

Ende

48

Qualität Kontextabhängiges Muster

Übersprungenes Dokument ist ein kontextabhängiges Muster. Denn man

kann nicht eindeutig aussagen, ob das Muster positive oder negative

Auswirkung

Positive Auswirkung: Falls das Dokument mit Absicht und begründet

nachträglich erstellt wird, dann wirkt das Muster sich positiv auf das

Projekt. Bei einer vorgeschriebene Kommunikationsweise mit

haufenweise Dokumente, wie z.B. wenn die Bürokratie in FLOW

vorkommt, dann ist es manchmal sicherlich sinnvoll, Dokumente aus

Zeitgründen nachträglich zu erzeugen um schneller bestimmte

Projektmeilensteine zu erreichen.

Negative Auswirkung: Falls das Dokument wegen Vergessenheit oder

Faulheit einfach nicht erstellt wird oder erst nach Bemerken

nachträglich erstellt wurde.

Lösungsvorschlag 1: In diesem Fall kann vielleicht nach Bemerken

des Fehlens eine Lightweight Documentation helfen, um zeit- und

kostensparend nachträglich, zumindest ein wenig zu dokumentieren.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Missing Experience und Wiederholte

Information:

Mit diesen Mustern gehört Übersprungenes Dokument zur selben

Mustergruppe.

Verwandt mit und Dead Document und Write for One:

Zeit t

Akteur1 Akteur2

Doku1

Start

Ende

tOutput

K

49

Ein nachträglich erstelltes Dokument im Übersprungenem Dokument

kann dazu führen, dass keiner dieses Dokument noch braucht und

somit zu Dead Document wird. Ein Übersprungenes Dokument kann

oft mit diesem Muster in Verbindung gebracht werden.

Ein nachträglich erstelltes Dokument in Übersprungenes Dokument

kann auch dazu führen, dass es nur von einem einzigen Akteur genutzt

wird und somit das Muster Write for One auftritt.

Sehr verwandt mit Permuted Order:

Übersprungenes Dokument gehört nicht nur mit Permuted Order zur

Mustergruppe Abweichung Ist-Soll, es kann unter Umständen als eine

Spezialform von Permuted Order angesehen werden. Daher ist

Übersprungenes Dokument mit diesem Muster sehr verwandt.

Gegensätzlich und disjunkt mit Bürokratie, Lightweight

Documentation und Wichtiges Dokument (VID):

Übersprungenes Dokument könnte das Problemmuster für Bürokratie

sein. Denn bei der Bürokratie werden sehr viele Schriftstücke und

Dokumente zwischen den Akteuren nach Vorschriften und

Prozessabläufen erstellt und ausgetauscht, so dass bei Vergessenheit in

einem Übersprungenen Dokument zu unerwünschte Ergebnisse

geführt werden.

Lightweight Documentation kann unter Umständen als Lösung für

negatives Auftreten dieses Musters vorgeschlagen werden, wie oben

unter dem Aspekt „Qualität“ beschrieben.

Ein Wichtiges Dokument (VID) ist gegensätzlich zu Übersprungenem

Dokument. Denn wenn ein Dokument sehr wichtig ist und auch von

vielen gebraucht wird, dann ist es sehr selten der Fall, dass man so ein

Dokument vergisst oder einfach überspringt.

Auftreten Meistens kommt Übersprungenes Dokument häufig in Softwareprojekten

vor, die nach klassischen und konventionellen Prozessmodellen

entwickeln. Dabei lässt es sich in der Realität aus Zeitgründen nicht

vermeiden, dass Dokumente bei der Entwicklung erstmal weggelassen und

später erzeugt werden. Bei vielen agilen Entwicklungsmethoden werden

häufig bewusst schwergewichtige Dokumentation durch direkte

Kommunikation ersetzt, um die Effizienz der Entwicklung zu steigern und

am Markt mithalten zu können. In solchen Projekten wird das

Übersprungene Dokument häufig gezielt verwendet.

Beispiele Im Folgenden wird ein Beispiel in der Soll- und Ist-Situation verglichen.

Diese Ausschnitte stammen aus [Stapel 2006] und wurden in [Schneider

et. al. 2007] nochmals als ein reales Beispiel erläutert. Entsprechend dem

Prozessmodell des Unternehmens in der Bankenbrache [siehe hierzu Bei-

spiele aus Permuted Order] hätte die Soll-Situation zuerst „Softwareent-

wurf erstellen“ und dann „Implementierung“ die entsprechenden Doku-

50

mente liefern sollen.

Ausschnitt aus Soll-Prozess [Stapel 2006]

Wegen Anomalien beim Dokumentenfluss fand man heraus, dass der Ab-

lauf in Wahrheit regelmäßig anders verlief. Flüssige Informationen hatten

die Abläufe und die Dokumentation pervertiert.

Ausschnitt aus Ist-Prozess mit Problem „Entwurf nachträglich erstellen“ [Schneider et. al. 2007]

Denn in Wahrheit wurde zunächst „vorentworfen“, aber nicht dokumen-

tiert. Manche Ideen landeten in einem Wiki, anderes hat sich nur der De-

signer gemerkt. Auf dieser Basis hat er implementiert. Anschließend

wurde aus dem Code „der Entwurf extrahiert“ – um das Prozessmodell

zufrieden zu stellen. Das Dokument wurde in diesem Falle nachträglich

erstellt. Hier ist das Muster Übersprungenes Dokument aufgetreten.

51

5.2.3 Synergie

[Quelle: http://www.kubiss.de/bildung/projekte/schb_netz/b4_projekte/schueler/IK10C0405/02/teamwork.gif]

„Das Ganze ist mehr als die Summe seiner Teile.“


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster


Talking Only



Metapher Der Begriff „Synergie“ bezeichnet das Zusammenwirken von Lebewesen,

Stoffen oder Kräften im Sinne von „sich gegenseitig fördern“. Eine

Umschreibung von Synergie findet sich in dem Ausspruch „Das Ganze ist

mehr als die Summe seiner Teile“, auch als Holismus bezeichnet.

Synergie-Effekte werden interdisziplinär in der Synergetik untersucht. Von

Synergie spricht man auch in der Pharmazie, wenn zwei gleichzeitig

eingenommene Medikamente ihre Wirkungen gegenseitig verstärken.

Auch beim Zusammenwirken von Chemikalien spricht man von

synergetischen bzw. synergistischen Effekten, wenn sich die kombinierten

Wirkungen potenzieren.

Beschreibung Bei der Synergie sitzen drei oder mehr Akteure lokal dicht bei einander

und diskutieren über ein Thema oder ein Problem in der

Softwareentwicklung. Es kann durchaus ein Face-To-Face Meeting oder

Besprechung sein. Dabei fließen Informationen zwischen den Beteiligten

ununterbrochen. Während solchen Ereignissen kommuniziert jeder

beteiligter Akteur mit jedem und tauscht dabei wechselseitig flüssige

Informationen aus, d. h. sie kommunizieren synchron miteinander wie bei

einer Interaktion. Die Informationen werden durch die flüssige direkte

Kommunikation potenziell vermehrt. Aus so einem Ereignis können unter

Umständen mehr Informationen und Wissen als vorher in den einzelnen

Köpfen der Akteure entstehen, muss aber nicht immer und in jedem Kopf

der Akteure so sein. Der kreative Entwicklungsprozess wird somit

angeregt, aber nicht erzwungen.

{1, 2,…}

+

3

K

52

Charakteristik


Die Anzahl der beteiligten Akteure ist größer gleich drei.

Alle teilnehmenden Akteure können sowohl Start- als auch

Endakteur sein.

Die beteiligten Akteure müssen lokal dicht beieinander sitzen.

Jeder Akteur kommuniziert mit jedem.

Der Informationsaustausch erfolgt sehr schnell und die

Kommunikation ist synchron.

In beide Richtungen zwischen jeden einzelnen Akteuren fließen

schnelle flüssige Informationen.

Definition 1: Normale FLOW-Darstellung

Die Akteurengruppe Akteur3…N stellt eine Anzahl von mehr als drei

Akteuren dar, die ebenfalls an diesem Ereignis teilnehmen und flüssig in

beide Richtungen Informationen austauschen.

Definition 2: Blackbox-Variante

Variante 1: Eine Variante, die die obere Definition erfüllt wäre zum

Beispiel wie folgt. Hierbei ist nur zu erkennen, welche Akteure an

Synergie beteiligt sind. Man kennt aber aus der Definition von

Synergie, dass alle Akteure intensiv miteinander Informationen und

Wissen in beide Richtungen austauschen.

Akteur1 Akteur2

{n ≥ 1}

Akteur3…N

AkteurN

{n ≥ 3}

Synergie

+

53

Synergie ist eindeutig ein dominantes Muster. Durch seine starke

charakteristische Eigenschaft fällt eine Synergie in einem FLOW-Modell

sehr auf und dieses Muster ist ausschließlich durch seine Struktur geprägt.


Synergie ist ein komplexes Muster aufgrund von der vielen beteiligter

Akteure und der vielen in beide Richtungen fließenden

Informationsflüssen.

Mustergruppe Talking Only

Dieses Muster gehört eindeutig zu der Mustergruppe Talking Only, da

dieses Muster nur aus flüssigen Informationen und Akteure besteht.

Auswirkung


Mehr nützliche Informationen ergeben sich nach einer Synergie, wobei

man mit geringem Aufwand viel Wissen in den Köpfen der Akteure

erzeugen kann. Hier reicht es nicht mehr aus, nur pure

Informationsweitergabe zu betrachten, sondern auch kreativer

Entwicklungsprozess. Bei folgender FLOW-Darstellung wird von drei

beteiligten Akteuren ausgegangen.

Pure Informationsweitergabe: Der Wissenszuwachst der Akteure ist

gleich dem erhaltenen Informationsmenge.

Akteur3

Akteur1

Akteur2

Synergie

T12 R12

Akteur1 Akteur2

T23

R23

Akteur3

T31

R31

T21R21

T32

R32T13

R 13

{1, 2,…}

3

∆KAkteur1=R21+R31

∆KAkteur1=R12+R32

∆KAkteur3=R13+R23

54

Kreativer Entwicklungsprozess: Der Wissenszuwachs ist größer als

die erhaltene Informationsmenge:

Wenn man Synergie in der Blackbox–Variante sehen würde, dann

bedeutet diese, dass die Ausgangsmenge Out einer Synergie größer ist

als die Eingangsmenge In und größer ist als die Summe der von allen

Akteuren übertragene Informationsmenge:

Out > In und Out > T12+T21+T23+T32+T13+T31


Positive Auswirkung: Es ist meistens sinnvoll Synergie einzusetzen,

damit man schneller mit direkter Kommunikation zu einem Ergebnis

kommt. Die Stärke von Synergie liegt darin, mit geringem Aufwand

aber viele nützliche Informationen und mehr wissen zu erzeugen.

Negative Auswirkung: Allerdings durch die vielen flüchtigen und

flüssigen Informationsaustausch gehen viele Informationen schneller

verloren noch bevor diese dokumentiert werden können. Das ist ein

Nachteil von diesem Muster.

Lösungsvorschlag 1: Bei diesem Muster fehlt leider eine parallel dazu

laufende Dokumentation wie Lightweight Documentation, wo die neue

Ideen und die nützlichen Informationen und Anforderungen

zusammengefasst festgehalten werden.

Gerade weil Synergie keine Dokumentationen fordert, ist es von dem

zeitlichen Aspekt her betrachtet ein sehr effektives und schnelles Muster,

um die direkte und synchrone Kommunikation zwischen den Akteuren zu

fördern.

T12 R12

Akteur1 Akteur2

T23

R23

Akteur3

T31

R31

T21R21

T32

R32T13

R 13

T12 R12

Akteur1 Akteur2

T23

R23

Akteur3

T31

R31

T21R21

T32

R32T13

R 13

K

∆KAkteur3>R13+R23

∆KAkteur2>R12+R32

∆KAkteur1>R21+R31

In

Out

Synergie

55

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Stille Post:

Mit Stille Post gehört Synergie zur selben Mustergruppe Talking Only.

Verwandt mit Interaktion: [siehe Interaktion]

Sehr verwandt mit Osmose:

Synergie gehört nicht nur mit Osmose zur selben Mustergruppe

Talking Only, es ist ein sehr ähnliches Muster mit Osmose. Beide

Muster setzt eine Vielzahl von Akteuren voraus und diese sind lokal

dicht beieinander und kommunizieren sich ununterbrochen. Der

Unterschied liegt nur darin, dass bei Osmose der

Informationsaustausch nicht explizit als Aufgabe oder Ziel der

Tätigkeit gedacht ist.

Gegensätzlich und disjunkt mit Hierarchie, Bürokratie, Lightweight

Documentation und Write For One:

Synergie könnte das Lösungsmuster für Hierarchie und Bürokratie

sein. Denn mit Einberufung einer Besprechung der beteiligten

Akteuren von Hierarchie und Bürokratie könnte das Zeitproblem und

das unnötige indirekte Kommunikation durch schriftliche

Dokumentation behoben werden.

Und Lightweight Documentation kann unter Umständen als Lösung

für negatives Auftreten dieses Musters vorgeschlagen werden. Mit

wenig Aufwand kann mit Lightweight Documentation eine parallele

Dokumentation geführt werden. Sie ist zwar nicht so ausführlich wie

eine richtige Dokumentation, aber dafür existiert wenigstens

überhaupt eine.

Beim Muster Write For One könnte die negative Auswirkung des

Zeitaufwandes für das Erstellen des Dokuments durch direkte

Kommunikation mit dem einzigen Akteur ersetzt werden. Für mehrere

Beteiligte wäre eine Synergie gut geeignet, um direkt Informationen

auszutauschen.

Auftreten Der direkte Kommunikationsweg ist immer der beste Weg. Daher ist bei

der Entwicklung von Software unvermeidlich Face-To-Face

Besprechungen und Meetings als die sinnvollste Kommunikation

einzusetzen. Sowohl bei der klassischen als auch bei agilen Ansätzen. Nur

56

in agilen Softwareprojekten legt man viel mehr Wert auf den direkten

Informationstausch und die früh zu erwartende Kundenzufriedenheit, daher

wird man Synergie in solchen Projekten häufiger vorfinden.

Beispiele Mit einer leichtgewichtige Dokumentation kann der Nachteil von Synergie

gelöst werden [hierzu siehe Beispiele in Lightweight Documentation].

57

5.2.4 Stille Post

[Quelle: http://www.stille-post.de]

Stille Post ist ein Kinderspiel, was für die Verfälschung von Nachrichten durch die mehrfache

mündliche Weitergabe steht.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster

lineares Muster

Talking Only, Sequenz


negatives Muster

Metapher Bei dem Kinderspiel „Stille Post“ ordnen sich die Teilnehmer in einer

Reihe oder einem Kreis an. Ein Spieler denkt sich eine Nachricht aus.

Diese Nachricht wird nun flüsternd von Mund zu Ohr von einem

Teilnehmer zum jeweiligen Nachbarn weitergegeben. Das Spielvergnügen

ergibt sich durch die folgende Auflösung, bei der der oder die letzte in der

Reihe laut ausspricht, was als letzte Mitteilung ins Ohr geflüstert wurde.

Die zunehmende Verfälschung und Verringerung der ursprünglichen

Nachricht kann dadurch dokumentiert werden, dass jeder Teilnehmer die

verstandene Nachricht laut für alle wiederholt, was auch zu einem

Lacherfolg führt.

Beschreibung Stille Post in einem FLOW-Modell ist eine Abfolge von drei oder mehr

flüssigen Informationsübergaben unter Akteuren. D.h. beteiligte Akteure

geben dieselbe Information nur flüssig und ohne zu dokumentieren an eine

einzelne andere Person weiter wie bei dem Kinderspiel „Stille Post“. Die

Informationsübergabe verläuft aufgrund der Flüssigkeit zwar sehr schnell

aber meistens ist das Ergebnis der Informationskette nicht zufrieden

stellend. Denn der empfangene Informationsgehalt weicht zu sehr von der

ursprünglichen Informationsquelle ab. Daher gehört Stille Post zu den

negativen Mustern. Bei flüssigen Übergaben gehen immer bestimmte

Informationen verloren und ein falscher Teil kommt durch unvermeidliche

Missverständnisse oder Improvisation des Akteurs hinzu.

{1, 2,…}

+

2

N

58

Charakteristik


Die Anzahl der beteiligten Akteure sind größer gleich drei.

Es existieren ausschließlich flüssige Informationsflüsse zwischen den

Akteuren und diese verlaufen in einer Richtung.

Definition:

Variante 1: Eine Variante, die die vorausgesetzte Struktur erfüllt.

Komplexität Lineares Muster

Stille Post ist eindeutig ein lineares Muster. Seine Eigenschaften sind durch

die lange Sequenz der flüssigen Informationsweitergabe geprägt. Seine

strukturelle Bedingung setzt voraus, dass sich mehr als drei Akteure an der

Kette beteiligen müssen.

Mustergruppe Talking Only, Sequenz

Stille Post gehört zur Mustergruppe Talking Only, da es nur aus flüssigen

Informationsflüssen besteht. Es ist ebenfalls ein Muster zu Sequenz, da es

eine lange lineare Kette von Informationsflüssen ist und somit die

Voraussetzung für Sequenz erfüllt.

Auswirkung


Im Folgenden ist die oben dargestellte Variante 1 verfeinert mit

Darstellung der Informationsmenge in grünen und blauen

Anforderungsquanten. Die grünen sind die ursprünglich korrekten

Anforderungen und die blauen die falsch improvisierten. Der Vorgang

von Informationsverlust und mit hinzugefügtem improvisiertem Falschteil

kann verständlicher und überschaubarer ausgedrückt werden.

Durch die lange Abfolge der puren Informationsweitergabe geht ein Teil

der relevanten Informationen verloren und ein verfälschter improvisierter

{n ≥ 2}

Akteur1 AkteurN

Akteur1 Akteur2 Akteur3


R2

T1 = 19T2 = 15 + 5 T3 = 12 + 6

R1R3

+

2

{1, 2,…}

KAkteur1= 19

∆KAkteur2 = 20

∆KAkteur3 = 18

59

Teil von Informationen kommt hinzu.

Um sich auf die relevante und die richtig übertragene Informationsmenge

konzentrieren zu können, wird bei Stille Post von Vernachlässigung von

falsch hinzugefügten Informationen und puren Informationsweitergabe

ausgegangen:

Daraus ergibt sich folgende FLOW-Darstellung mit Angaben der

Informationsmenge für das obige Beispiel:

Qualität Negatives Muster

Stille Post ist ein Muster mit negativer Auswirkung. Der Vorteil von Stille

Post ist zwar, dass durch die flüssige Übergabe die Informationen sehr

schnell fließen und das Muster somit sehr kommunikativ ist, aber die

Übergabe ist zu flüchtig. Der Informationsverlust ist sehr hoch und zu viele

improvisierte Falschteile werden zum Zielakteur weiterübertragen.

Informationen fließen zu flüchtig, so dass keine feste Speicherung

vorhanden ist und vieles nach einiger Zeit in Vergessenheit gerät. Ein

Review nach längerer Zeit wäre in so einem Fall schwierig.

Lösungsvorschlag 1: Ein offensichtlicher Lösungsweg wäre, dass der

Akteur1 direkt mit dem AkteurN kommuniziert, so dass der

Informationsverlust am niedrigsten gehalten werden kann. Natürlich

auch gerne in der Interaktion, um Missverständnisse zu vermeiden.

Lösungsvorschlag 2: Man kann Dokumente gezielt einfügen um

flüssige Informationen fest abzuspeichern. Reviews sind in diesem

Fall sehr sinnvolle Methoden, um immer wieder mit dem

Vorgängerakteur abzugleichen. Aus der Definition des Zeitaufwandes

für feste und flüssige Informationsflüsse muss man also bei dieser

Lösung mit einem Zeitverlust rechnen; dafür werden aber feste

Dokumente erstellt, auf die man später bei Bedarf zurückgreifen und

alles nachvollziehen kann.

Lösungsvorschlag 3: Mit Muster Validierung könnten die negativen

Auswirkungen von Stille Post behoben werden. Siehe dazu den

unteren Aspekt Beispiele, da wird die Stille Post mit einer

Validierung behoben.



R2

T1 = 19

T2 = 15 T3 = 12R1R3

N

T1 R1

T2 < ∆KAkteur2

T3< ∆KAkteur3 R2

∆KAkteur2=R1

∆KAkteur3=R2

∆KAkteur2=19

∆KAkteur3=15

60

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Osmose, Synergie, Wiederholte Information und

Bürokratie:

Mit diesen Mustern gehört Stille Post zur selben Mustergruppen.

Sehr Verwandt mit Hierarchie:

Hierarchie ist auch ein Muster mit langer Kette von

Informationsflüssen. Der Unterschied zu Stille Post liegt darin, dass

bei der Hierarchie diese Kette rollenbasiert ist und somit

organisatorisch vorgeschrieben ist. D.h. bei der Hierarchie ist

manchmal sogar dieser lange Weg begründet, wo bei Stille Post das

nicht der Fall ist.

Gegensätzlich und disjunkt mit Interaktion und Validierung: [siehe

Interaktion]

Stille Post ist das Problemmuster dieser beiden Muster. Dazu siehe die

Beispiele dieses Musters.

Auftreten Im Prinzip kann so ein Muster überall vorkommen. Es ist auch ein viel

gesehenes Muster in einem Softwareprojekt. Besonders in agilen

Projekten, wo meistens die Zeit eine höhere Priorität hat als die

Dokumentation, tritt so ein Muster ziemlich oft auf.

Beispiele In einem Softwareprojekt liest sich der Analytiker die Anforderungen aus

dem vom Kunden erstellten Lastenheft. Um kostbare Zeit einzusparen wird

das Aufschreiben von Dokumenten durch mündliche

Informationsmitteilung an einen Fachexperten ersetzt. Leider fällt dieser

Fachexperte nach einiger Zeit aus und muss deshalb sein bisheriges Wissen

an einen anderen Fachexperten weitergeben. Aus Zeitgründen wieder

mündlich. Dieser bespricht das Konzept mit dem Designer und er setzt die

Anforderungen in einem Entwurf um. Ein typisches Muster für Stille Post,

da oft das Ergebnisdokument Entwurf durch die lange Kette der

Informationsweitergabe nicht mehr der ursprünglichen Anforderung des

Kunden entspricht.

61

Das Problem hier kann mit einer Validierung behoben werden. Das

FLOW-Modell könnte hierzu folgendermaßen aussehen:

Der Entwurf wird einfach noch mal dem Kunden vorgelegt und

abgestimmt, um an den ursprünglichen Anforderungen des Kunden

anzupassen.

62

5.2.5 Solitär

[Quelle: http://www.schuechtern-und-allein.de/img/balloons2.png]

Der kleine Fritz kommuniziert ungern mit anderen. Er ist ein solitäres Kind.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster

unitäres Muster

Unterbrechung


negatives Muster

Metapher Als „Solitär“ bezeichnet man etwas Einzelnes, Einzigartiges oder für

einzelne Geeignetes. In der Architektur ist ein solitäres Gebäude ein

einzeln stehendes Gebäude. Und in ein einzeln stehendes Möbelstück in

einem Raum kann man ebenfalls als „Solitär“ bezeichnen.

Beschreibung In FLOW wird ein einzelner und alleinstehender Akteur mit höchstens

einem einzigen Informationsfluss als Solitär bezeichnet. Um diesen Akteur

herum ist höchstens nur ein einziger Informationsfluss und auch kein

Erfahrungsfluss zu erkennen. Dieser fließt entweder von ihm heraus oder

zu ihm hinein. Ein solitärer Akteur ist wie ein Alleinstehender in einem

Softwareprojekt, der zu wenig Arbeit leistet. Meistens ist so ein Akteur

hinsichtlich dieses Projektes unterfordert und somit nicht genug belastet.

Deswegen ist ein identifizierter Solitär in einem FLOW-Modell ein

negatives Muster.

Charakteristik


Ein einzeln stehendes Akteur

Dieser Akteur besitzt höchstens ein einziger Informationsfluss

Dieser Informationsfluss fließt entweder zu ihm hinein oder von ihm

heraus, und kann sowohl von einem festen als auch von einem

flüssigen Speicher kommen.

Um diesen Akteur herum sind auch keine Erfahrungsflüsse zu

erkennen.

{1, 2,…}

+

1

N

+

63

Definition:

Variante 1:

Ein einzeln stehendes Akteur, der gar keine Informationsflüsse um

sich herum hat.

Variante 2:

Ein Akteur, der nur ein flüssiger Informationsfluss von sich hergibt.

Solitär ist gehört zu den strukturell sehr einfachen und daher zu den

dominanten Mustern. So ein Solitär würde in einem FLOW-Modell durch

seine klare Abgrenzung und wenige Informationsflüsse um sich herum sehr

auffallen.


In der Komplexitätsfacette gehört dieses Muster zu den unitären Mustern.

Denn Solitär besteht in der FLOW-Struktur nur aus einem einzigen Akteur

und höchsten einem Informationsfluss. Eine solitäre Person im Projektteam

ist meistens unterfordert und kann in der FLOW-Notation folgendermaßen

dargestellt werden:

Mustergruppe Unterbrechung

Solitär gehört zur Mustergruppe Unterbrechung. Es erfüllt die

Voraussetzung, dass an diesem Muster die Information an dem Ursprung

oder zum Ende geführt wird. Der Informationsübertragung unterbricht an

dieser Stelle.

Akteur1

{0 ≤ n ≤ 1}

Aktivität1

oder

Akteur1 Akteur1

Aktivität1

Akteur1

Akteur1

{0 ≤ n ≤ 1}

Aktivität1

1

64

Auswirkung


Die Auswirkung von Solitär ist quantitativ. Denn der Wissensvorrat K

eines solitären Akteurs in einem Projekt nimmt entweder sehr wenig zu,

oder gar nicht. Er bekommt nämlich aus irgendwelchen Gründen nur eine

oder keine Information von anderen Akteuren, daher ist bei ihm ∆K stets

sehr klein.


Solitär ist ein Muster mit negativer Auswirkung. Immer wenn Solitär

auftritt, muss man an dieser Stelle immer besonders aufpassen. Denn es ist

ein Warnzeichen dafür, egal ob begründet oder nicht, dass ein Akteur zu

wenig mit den anderen Akteuren kommuniziert, mit anderen Worten, zu

wenig zum Projekt beiträgt. An dieser Stelle versiegt irgendwie der

Informationsfluss.

Diskussion

Verweis auf

Muster


Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Dead Document:

Mit diesen Mustern gehört Solitär zur selben Mustergruppe.

Sehr Verwandt mit Person als Senke:

Person als Senke gehört mit Solitär zu einer Mustergruppe. In

gewissen Sinnen ist ein Solitär eine empfangene Person, der nichts mit

den Informationen tut. Diese beiden Muster können miteinander in

Verbindung gebracht werden, daher sind sie sehr verwandt.

Gegensätzlich und disjunkt mit Interaktion, Osmose und

Alleinkämpfer: [siehe Interaktion]

Eine Osmose könnte bei einem Solitär auch helfen. D. h. der Solitär

sollte mit anderen Personen, wie z.B. bei einer Kaffeepause

unterhalten, wobei ohne extra angestoßen wichtige Informationen

ausgetauscht werden können.

Mit Alleinkämpfer ist Solitär gegensätzlich. Denn der Alleinkämpfer

bekommt zu viele Aufgaben und trägt sehr große Verantwortung, was

evtl. zu Überforderung führt, der Solitär dagegen ist sehr

zurückhaltend und trägt zu wenig Verantwortung, was ja zu

Unterforderung führen kann.

{1, 2,…}

NM

65

Auftreten Da Solitär ein sehr einfaches und sogar ein grundlegendes Muster ist,

taucht es ziemlich häufig in der Softwareentwicklung auf. Unter der

Situation, dass ein Projektmitglied zu wenig tut oder selten mit anderen

kommuniziert, würde er als Solitär auffallen.

Beispiele Beispiele für Solitär gibt es zu viele. Akteure in einem Softwareprojekt, die

zwar offiziell zum Projektteam gehört, aber gar keine Arbeit in das Projekt

investieren und auch nicht mit den Teammitglieder Informationen über das

Projekt austauschen, sind Solitäre. Im folgenden wird ein Beispiel mit

einem externen Berater eines Unternehmens geschildert:

In dem Softwareunternehmen SoftNews soll ein externer beratender

Spezialist zu einem nicht vorankommenden Softwareprojekt eingestellt

werden. Dieser Experte ist auf Personalorganisation spezialisiert und soll

den Teammitgliedern die Zusammenarbeit erleichtern. Aber leider ist es

den Teammitgliedern nach einer FLOW-Analyse aufgefallen, dass dieser

Experte überhaupt nicht den Beteiligten kommuniziert und auch keine

Erfahrungen zu dem Projekt beigetragen hat.

In diesem Fall sollte man sich überlegen, ob dieser Experte, der eigentlich

die Kooperation verbessern soll, nicht überflüssig ist.

Externer Berater

Softwareprojekt des SoftNews

66

5.2.6 Osmose

[Quelle: http://www.cartoonstock.com/lowres/pha0139l.jpg]

Peter und Klaus sitzen gemütlich beim Kaffee und diskutieren nebenbei über den aktuellen

Projektstand.


Komplexität:

Mustergruppe:

Form:

Qualität:

rezessives Muster

kombinatorisches Muster

Talking Only


positives Muster

Metapher Die „Osmose“ hat eine besondere Bedeutung für biologische Systeme. Sie

beschreibt die gerichtete Diffusion von Lösungsmittel durch eine selektiv

permeable Membran. Triebkraft dieser Bewegung kann z.B. der

Konzentrationsunterschied zwischen beiden Seiten der Membran sein.

Diese Membranen sind durch bestimmte Proteine für das Lösungsmittel

Wasser durchlässig. Dagegen sind im Wasser gelöste Ionen meistens nicht

in der Lage, die Membran zu passieren. Ein Konzentrationsgefälle von

Ionen kann bei der Osmose nur durch Bewegungen des Lösungsmittels

ausgeglichen werden. Das Wasser auf der Seite mit der geringeren

Konzentration gelöster Ionen wandert durch die Membran auf die Seite der

höheren Konzentration.

Beschreibung Osmose bedeutet in FLOW, dass Akteure dicht beieinander sitzen und

gemeinsam an eine gestimmte Aufgabe arbeiten oder eine Tätigkeit

ausüben. Der Unterschied zu Synergie ist, dass die Vermittlung von

Informationen und Wissen nicht das Ziel der Tätigkeit ist und somit der

Informationsaustausch nicht bewusst stattfindet. Ohne besonders

angestoßen fließen aber trotzdem Informationen. D.h. in dieser

gemeinsamen Aktivität kann man keine genaue Aussage treffen, wie die

flüssigen Informationen fließen. Aber aus dieser Aktivität ist zu erkennen,

dass tatsächlich auf irgend eine Art und Weise Informationen geflossen

und Wissen übermittelt sind. Ein gutes Beispiel wäre z.B. eine gemeinsame

{1, 2,…}

–

4

P

67

Kaffee-Runde mit den beteiligten Teammitgliedern, wo unbewusst über

Projektwissen und Informationen gesprochen werden.

Charakteristik

Struktur Rezessives Muster

Die Anzahl der Akteure ist größer gleich zwei.

Alle teilnehmenden Akteure können sowohl Start- als auch

Endakteur sein.

Die beteiligten Akteure müssen lokal dicht beieinander sitzen und

haben aber ursprünglich nicht das Ziel, Informationen und Wissen

auszutauschen.

Informationsaustausch erfolgt sehr schnell und flüssig

Die Richtung des Informationsfluss ist nicht eindeutig zu erkennen, da

in beide Richtungen irgendwie flüssige Informationen zwischen jeden

beteiligten Personen fließen.

Es fließt irgendwie Informationen parallel zu der geplante Aktivität,

ohne dass der Vorgang zum Austausch der Informationen besonders

angestoßen wurde

Definition: Da es nicht eindeutig zu erkennen ist, wie und in welche

Richtung Wissen und Informationen fließen, wird bei der

FLOW-Darstellung ausschließlich die Blackbox-Variante gewählt.

Hierbei ist nur zu erkennen, welche Akteure sich an Osmose

beteiligen.

Die Akteurengruppe AkteurN stellt eine Anzahl von mehr als zwei

Akteuren dar, die ebenfalls an der Osmose teilnehmen und flüssig bzw. in

unbestimmter Weise Informationen austauschen.

Variante 1: Eine Variante, die die obere Definition erfüllt

AkteurN

{n ≥ 2}

Osmose

–

68

Die Voraussetzung, dass der Informationsaustausch unbewusst und

nebenläufig zu einer anderen Aktivität stattfindet, zeichnet dieses Muster

zu einem rezessiven Muster aus. Wenn das Muster nicht gezielt und mit

Absicht nach der Identifizierung in einer Blackbox dargestellt wird, ist es

ziemlich schwierig, rein aus der Tatsache heraus das Muster strukturell zu

erkennen.

Komplexität Kombinatorisches Muster

Osmose ist den kombinatorischen Mustern zugeordnet aufgrund von der

vielen in unbestimmter Weise fließende Informationsflüssen zwischen den

beteiligten Akteuren und der nicht zu umgehenden Blackbox-Darstellung.

Mustergruppe Talking Only

Dieses Muster gehört eindeutig zu der Mustergruppe Talking Only, da nur

schnelle und flüssige Informationen neben der eigentlichen Aktivität

fließen.

Auswirkung


Im Folgenden wird davon ausgegangen, dass sich zwei Akteure an der

Osmose beteiligen. Da bei Osmose nicht ganz klar ist, wie genau bzw. in

welcher Richtung die Informationen fließen und dass der

Informationsgehalt dabei zuwächst, wird hier die Blackbox-Variante weiter

analysiert.

Die Ausgangsmenge Out einer Osmose ist größer als die gesamte

Eingangsmenge ∑i Ini .In diesem Falle: Out > In1 + In2

Die Quantität der Osmose besteht darin, dass der Informationsgehalt und

der Wissensstand der Akteure sich vergrößern, ohne dass dieser

Akteur1

Osmose

Akteur2

Akteur1 OutOsmose

In1

In2

Akteur2

4

{1, 2,…}

69

Informationsaustausch besonders mit Absicht angestoßen wurde.

Der Wissensstand bzw. der Wissensveränderung der Akteure ist größer

als 0. D. h. bei der Osmose sind in irgendeine Art und Weise

Informationen und Wissen ausgetauscht wurde.


Osmose ist als ein positives Muster kategorisiert. Denn bei der Osmose

fließen immer irgendwie Informationen und Wissen neben der geplanten

Aktivität, was eigentlich immer positive Auswirkung auf das Projekt hat.

Man versucht bei der Softwareentwicklung die Kommunikation zwischen

den Beteiligten immer wieder zu fördern, jede empfangene und

übertragene Information, dass ungezwungen passiert, ist ein Gewinn für

das Projekt. Daher ist Osmose bei seinem Auftreten stets positiv.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Stille Post und Wiederholte Information: [siehe

Stille Post] Sie gehören alle zur Mustergruppe Talking Only.

Sehr Verwandt mit Synergie: [siehe Synergie]

Gegensätzlich und disjunkt mit Solitär, Person als Senke und Missing

Experience: [siehe Solitär]

Da eine Osmose ungezwungen und unbewusst passiert, könnte man bei

Missing Experience nochmal nachgehen, ob man evtl. einen

Erfahrungsaustausch in Form einer Osmose vergessen oder übersehen

hat. Ein Erfahrungsaustausch in Form einer Osmose kann den

negativen Effekt des Missing Experience beseitigen.

Osmose kann ebenfalls die gleiche Funktion für Person als Senke

bezwecken. Denn eine Person als Senke überträgt keine seine

Akteur2

Akteur1OutOsmose

In1>0

In2>0

P

∆KAkteur1>0

∆KAkteur2>0

70

erhaltene Informationen und Wissen an andere Akteure weiter. Unter

diesen Umständen kann man nachschauen, ob diese Person vielleicht

unbewusst Informationen an andere weitergegeben hat.

Auftreten Osmose tritt häufig in Softwareprojekten auf. Denn es ist eine

Kommunikationsmethode, wo nicht der Informationsaustausch als Ziel

bestimmt ist, aber dennoch sehr nützlich ist und positiv zu einem

Projekterfolg beiträgt. Besonders in den agilen Projekten passiert eine

Osmose oft. Gerade in solchen Projekten werden Techniken einsetzt, wo

sehr viel Gespräche und Diskussionen geführt werden. Daher lässt sich

einfach nicht vermeiden, z.B. beim Essen oder bei einer Kaffee-Pause

locker über das Projekt zu sprechen. Manche nützliche aber auch sehr

wichtige Informationen werden auf so eine Art und Weise übertragen.

Manchmal ist es sogar sinnvoll, Osmose gezielt einzusetzen, um die

Atmosphäre durch andere gemeinsame Aktivitäten aufzulockern aber

dennoch einen Informationsaustausch zu fördern statt zu erzwingen.

Beispiele Drei Softwareentwickler sitzen gemütlich beim Kaffee und plaudern

nebenbei ein wenig. Plötzlich ist einer der Entwickler eine Frage zur

Implementierung eingefallen und sie fangen an, über dieses Problem zu

sprechen. Unbewusst und ungezwungen haben drei Entwickler wichtige

Informationen über das Projekt ausgetauscht und dabei ist sogar eine gute

Idee entstanden, wie man besser implementieren kann. Im Folgenden ist

der Ausschnitt eines zugehörigen FLOW-Modells dargestellt:

Implementierung

OsmoseKaffee-Pause

Entwickler

{n = 3}

71

5.2.7 Hierarchie

[Quelle: http://www.linkezeitung.de]

Die Raben sind in einer strengsten Hierarchie eingeordnet.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster

lineares Muster

Rollenbasierte Muster, Sequenz

zeitliches Muster


Metapher Der Begriff „Hierarchie“ bezeichnet ein System von Elementen, die

einander über- bzw. untergeordnet sind. Die Einteilung oder Einordnung

von Objekten in eine Hierarchie impliziert häufig eine Wertigkeit, die

bereits in der Rangordnung enthalten ist, nach der die Objekte geordnet

werden. Deshalb werden Hierarchien häufig als Mittel zur Ausübung von

Herrschaft kritisiert.

Beschreibung In einem FLOW-Modell ist Hierarchie ein Muster, wo mehr als drei

Akteure nacheinander die Informationen weitergeben, also eine

Informationsabfolge wie bei Stille Post. Aber der Unterschied zu Stille Post

ist, dass eine Hierarchie aus einer Sequenz von flüssigen, festen oder

gemischten Informationen besteht. Unter Umständen kann diese

umständliche Reihenfolge gewollt und begründet sein. Eine Hierarchie

tritt auf, wenn solch eine Kette oder Abfolge von

Kommunikationsteilnehmern bei einem Softwareprojekt rollenbedingt,

bzw. organisatorisch vorgeschrieben ist, wie z.B. bei einer hierarchischen

Berichterstattung. Deswegen ist es manchmal schwer zu beurteilen, ob sich

eine Hierarchie positiv oder negativ auf das Projekt auswirkt. Somit gehört

dieses Muster zu den kontextabhängigen.

+

2

K

72

Charakteristik


Drei oder mehr Akteure beteiligen an dieser Informationsabfolge

Die Informationsflüsse, die die Akteure verbinden, können sowohl

flüssige, als auch feste Informationsflüsse sein.

D.h. entweder ein direkter flüssiger Fluss verbindet die benachbarten

Akteure, oder zwischen den benachbarten Akteure liegt ein

Dokument, was von dem einen Akteur erstellt und von dem anderen

gelesen wird.

Definition:

Variante 1: Eine Variante, die die vorausgesetzte Struktur mit

eingesetzten Rollen erfüllt

Die Identifikation dieses Muster hängt allein von seiner strukturellen

Reihenfolge der Rollen ab. Daher ist es ein dominantes Muster, weil man

durch „scharfes Hinsehen“ das Muster allein aufgrund seiner strukturellen

Kettenform sofort erkennen kann.


In der Komplexitätsfacette gehört dieses Muster zu den linearen Mustern.

Denn Hierarchie ist eine Sequenz von Informationsflüsse, die in eine

bestimmte Reihenfolge und rollenbedingt übermittelt wird.

Mustergruppe Rollenbasierte Muster, Sequenz

Hierarchie gehört eindeutig zu den rollenbasierten Mustern, denn die

hierarchische Informationsübertragung ist rollenbedingt und wird häufig

den Vorschriften nach verfolgt. Dieses Muster gehört ebenfalls zur

Mustergruppe Sequenz, da aus der Sicht der Wissensfluss die geflossenen

Informationen manchmal einen unnötigen Sequenz gemacht haben.

Auswirkung


Hierarchie ist ein zeitliches Muster. Es ist kein quantitatives Muster, weil

man wegen Dokumenten zwischen den Akteuren nicht genau bestimmen

kann, was und wie viel bei der Informationsübertragung verloren gegangen

ist. Durch die lange Kette der Informationsübermittlung gehen manchmal

unnötige Zeiten verloren. Selbst wenn die rollenbedingte Reihenfolge der

Rolle1

{n ≥ 2}

DokuMRolleN RolleM

Architekt Projektleiter Bericht Abteilungsleiter

2

+

73

Informationsweitergabe vorgeschrieben, ändert sich nichts daran, dass

mehr Aufwand und Zeitverlust für den Informationsfluss bedeutet.

Vergleiche hierzu den Aspekte Beispiele.


Hierarchie gehört zu den kontextabhängigen Mustern. Seine Auswirkung

ist nicht eindeutig bestimmt und ist kontext- und umfeldabhängig. Seine

Eigenschaften sind durch seine rollenbedingte bzw. organisatorische

Struktur geprägt. Das kann sowohl positiv als auch negativ auf die

Entwicklung wirken.

Meistens verfolgt die Hierarchie eine bestimmte Vorschrift oder Regelung

in den Prozessmodellen der Softwareentwicklung im Unternehmen und

lässt oft dieser lange Kette von Informationsflüssen mit viel Aufwand und

Zeitverluste nicht vermeiden. Zumindest aber garantiert diese Art von

Festlegung einen stabilen und meistens juristisch korrekten Prozessablauf.

Diskussion

Verweis auf

Muster


Solit

är

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Validierung, Kunde zu Analytiker, Analytiker zu

Architekt und Architekt zu Entwickler:

Mit diesen Mustern gehört Hierarchie zur selben Mustergruppe

Rollenbasiertes Muster.

Sehr verwandt mit Stille Post und Bürokratie: [siehe Stille Post]

Mit Stille Post und Bürokratie gehört Hierarchie nicht nur zur selben

Mustergruppe, mit diesen beiden Mustern wird Hierarchie oft in

Zusammenhang erwähnt. Bürokratie ist in gewisser Weise sehr

dokumentenlastig. Eine Hierarchie könnte auch sehr

dokumentenlastig, wenn es rollenbedingt und organisatorisch

vorgeschrieben ist.

Gegensätzlich und disjunkt mit Interaktion, Synergie, Write for One,

Permuted Order, Person als Senke und Dead Document: [siehe

Interaktion und Synergie]

Hierarchie kann als Lösungsmuster für Person als Senke und Dead

Document vorgeschlagen werden. Denn eine Hierarchie ist meistens

eine erzwingende Reihenfolge von Informationsaustausch und sie ist

vorschriftenmäßig festgelegt. Man muss bei einer Hierarchie nur die

Regeln folgen und schon findet Informationsaustausch statt,

K

74

wenigstens in eine Richtung. Somit können zumindest Person als

Senke und Dead Document vermieden werden.

Write for One könnte ein Problemmuster von Hierarchie werden, da

bei der hierarchischen Rangordnung des Informationsflusses könnte

Dokumente erzeugt werden, die nur von einem einzigen Akteur

gelesen werden, wie z.B. vom Vorgesetzten.

Hierarchie ist disjunkt mit Permuted Order, weil bei der Hierarchie

die Reihenfolge der Informationsübertragung sehr wichtig ist. Und

daher kann eine Vertauschung der Reihenfolge von den

auszuführenden Aktivitäten bei Permuted Order das Problembild von

Hierarchie darstellen.

Auftreten Eine Hierarchie verfolgt meistens eine Vorschrift oder Regelung, daher

kommt so ein Muster fast bei jedem Softwareprojekt vor, egal ob sie mehr

oder weniger nach Prozessmodellen arbeiten.

Beispiele Folgendes Beispiel soll die Eigenschaft der Hierarchie noch mal

verdeutlichen: In einem deutschen Großunternehmen ASoft werden viele

Großprojekte firmenübergreifend geführt. An einem EU-Projekt arbeitet

ASoft schon langjährig mit Firma BSoft zusammen. Jedes Unternehmen

stellt ein Team von Entwicklern zusammen und haben einen gemeinsamen

Projektleiter, der das gesamte Projekt koordiniert und organisiert. Ein

Entwickler vom Team ASoft stellt eines Tage bei der Entwicklung fest,

dass die verwendete Entwicklungstool sehr mühsam zu bedienen ist und

viele gebrauchte Methoden nicht zur Verfügung steht. Dafür kennt dieser

Entwickler ein anderes Tool, das viel besser geeignet wäre. Um das

Projektergebnis zu optimieren und unnötigen Aufwand zu ersparen, schlägt

er dem Teamleiter von ASoft vor, das neue Tool für das gesamte Projekt zu

übernehmen. Da das Projekt firmenübergreifend läuft, hat der Teamleiter

von ASoft nicht das Recht dazu, dies zu genehmigen. Laut Vorschriften

muss der Projektleiter des gesamten Projekts einen Antrag an die

Vorstände der beiden Firmen stellen.

75

Nachdem der Antrag korrekt von den Vorständen genehmigt worden,

erteilt der Projektleiter dem Teamleiter von BSoft über diese Entscheidung.

Erst danach kann der Entwickler von Team BSoft dieses neue Tool für

seine Entwicklung einsetzen.

Aus der Sicht des Informationsflusses könnte der Entwickler in Team

BSoft gleich von Entwickler von ASoft informiert werden. Aber

Vorschriften muss eingehalten werden trotz mehr Aufwand und

Zeitverlust.

Antrag

EnwicklerTeamA

Projektleiter

TeamALeiter

Genehmigung

EnwicklerTeamB

TeamBLeiter

Vorstand A und B

76

5.2.8 Dead Document

[Quelle: http://www.mathe-kaenguru.de/geschichte/versand06.htm]

Es wurden so viele Dokumente erzeugt, dass keiner Lust hat, diese durchzulesen.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster


Unterbrechung


negatives Muster

Metapher „Dead“ ist das englische Wort für „tot“. Der „Tod“ ist der dauerhafte und

endgültige Verlust der für ein Lebewesen typischen und wesentlichen

Lebensfunktionen. Der Tod ist also der Zustand eines Organismus nach der

Beendigung des Lebens. Im übertragenen Sinne werden viele Sachen als

tot und damit ein wenig übertreiben bezeichnet, die ihre ursprünglichen

Funktionen nicht mehr erfüllen und in bestimmter Art und Weise inaktiv

werden.

Beschreibung Als Dead Document bezeichnet man in FLOW die Dokumente, die zwar

irgendwie erzeugt, aber nicht gelesen oder verwendet werden. Diese

Dokumente erfüllen nicht mehr die ursprüngliche Funktion von anderen

gelesen oder genutzt zu werden, daher stammt die Bezeichnung als „tot“.

Die erzeugenden Flüssen können sowohl von Akteuren also auch von

Dokumenten stammen. Wenn ein fester Fluss von einem Dokument

stammt, dann wurde dieses Dokument mit einem bestimmten Werkzeug,

wie z.B. einem Generator, automatisch erzeugt. D.h. um dieses Dokument

herum fließen nur feste oder flüssige Informationsflüsse hinein. Das Dead

Document wird von keinem Akteur gebraucht, also fließen aus ihm keine

Informationsflüsse heraus.

Charakteristik


Ein einzeln stehendes Dokument

Um dieses Dokument herum fließen nur Informationsflüsse hinein.

Es existiert mindestens einen Informationsfluss, der das Dokument

{1, 2,…}

+

3

N

+

77

erzeugt.

Aus diesem Dokument fließen keine Informationsflüsse heraus, d.h.

es wird von keinem Akteur gebraucht oder erzeugt ebenfalls kein

anderes Dokument.

Definition:

Variante 1:

Variante 2:

Dead Document besteht in der FLOW-Darstellung nur aus einem einzigen

Dokument, das nur hinein fließende Informationen bekommt. Es würde in

einem FLOW-Modell durch diese Eigenschaft auffallen. Seine

Charakteristik kann man rein aus der strukturellen Definition erkennen,

daher ist es ein dominantes Muster.


In der Komplexitätsfacette gehört Dead Document zu den

mehrdimensionalen Mustern. Die Voraussetzung für so ein Muster ist zwar

sehr einfach gehalten, aber die Anzahl der in das Dokument hinein

fließenden Informationsflüssen ist nicht fest definiert. Daher kann so ein

Muster ziemlich viele Informationsflüsse enthalten.


Dead Document gehört zur Mustergruppe Unterbrechung. Es erfüllt die

Voraussetzung, dass an diesem Muster die Information an dem Ursprung

oder zum Ende gefunden wird. Die Informationsübertragung unterbricht an

einem Dead Document.

Auswirkung


Dead Document ist ein Muster mit quantitativer Auswirkung. Dieses

Dokument wird zwar erzeugt, wird aber von keinem Akteur aktiv genutzt.

Das heißt die Informationsmenge, womit dieses Dokument den anderen

Speicher versorgen sollte, beträgt TDokument = 0. Dies führt definitiv zu einer

negativen Auswirkung erläutert im unteren Aspekt.

Dokument

{n ≥ 1}

AktivitätN

Akteur1Dokument

Dokumenterstellen

DokumentDoku1<Generator>

3

{1, 2,…}

78


Dead Document ist eindeutig ein Muster mit negativer Auswirkung. Wenn

so ein Muster in der FLOW-Darstellung auftritt, dann wirkt es sich

sicherlich negativ auf das Projekt aus. Denn um ein Dokument zu erzeugen

kostet viel Zeit und Aufwand, wenn es aber gar nicht genutzt wird, dann ist

entweder in der Planung und Organisation des Projekts ein Fehler

unterlaufen, oder der Informationsaustausch hat aus bestimmten Gründen

nicht so funktioniert wie es sein soll. Dead Document ist immer ein

Warnzeichen für einen Fehler in der Kommunikation.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Solitär: [siehe Solitär]

Verwandt mit Übersprungenes Dokument und Write for One: [siehe

Übersprungenes Dokument]

Dead Document beschreibt ein Dokument, dass von keinem Akteur

genutzt wird. In Write For One wurde das Dokument nur für eine

einzige Person erzeugt und somit auch „fast“ ein Dead Document,

wenn dieser einzige Akteur das Dokument nicht nutzen würde.

Sehr verwandt mit Person als Senke:

Dead Document wird nicht nur mit Person als Senke zu derselben

Mustergruppe Unterbrechung zugeordnet, beide Muster werden auch

noch zusammen erwähnt. Dead Document ist ein „totes“ Dokument,

was von keinem gelesen wird, und Person als Senke ist quasi eine

„tote“ Person, die nur Informationen bekommen aber nichts von sich

abgeben.

Gegensätzlich und disjunkt mit Hierarchie, Lightweight

Documentation und Wichtiges Dokument VID: [siehe Hierarchie]

Dead Document ist für Lightweight Documentation das

Problemmuster. Meistens ist ein Dokument von einem bestimmten

Umfang und mit viel Mühe und Aufwand erstellt. Und daher erfordert

es meistens ebenfalls eine gewisse Einarbeitung um sich erstmal

einzulesen und in so einem Dokument zu Recht zu finden. Das könnte

durchaus einer der Gründe sein, warum das Dokument „tot“ herum

liegt. Eine Alternative wäre, z.B. in den Prozessmodellen des Projektes

gezielt schwergewichtige Dokumentationen durch Lightweight

N

79

Documentation zu ersetzen, um überhaupt gar nicht mit den Aufwand

des Erstellens eines Dokuments erst anzufangen. Eine Lightweighted

Documentation bietet neben der direkten Kommunikation eine

parallele einfache nicht ausführliche aber dafür schnelle

Dokumentation.

Dead Document ist gegensätzlich zu Wichtiges Dokument VID, da das

Wichtige Dokument VID das Gegenteil von einem Dead Document ist

und von vielen Speichern benötigt wird.

Auftreten Dead Document taucht in vielen Softwareprojekten auf, besonders in den

Projekten, wo streng nach bestimmten Vorgehensmodellen, wie z.B. nach

dem V-Modell, entwickelt werden. In agilen Softwareprojekten wird man

dieses Muster eher seltener vorfinden, da in solchen Projekten Wert darauf

gelegt wird, knapp und leichtgewichtig zu dokumentieren. Ein

funktionstüchtiges Release ist in solchen Projekten einfach wichtiger als

detaillierte Dokumentation.

Dieses Muster kann als strukturelles Prüfmuster in einem FLOW-Modell

dienen. Man kann gezielt danach suchen. Denn durch „scharfes Hinsehen“

sticht meistens ein Dead Document sofort ins Auge aufgrund der zu sich

hinein aber nicht wieder von sich heraus fließenden Informationsflüsse.

Beispiele In der Masterarbeit von Stapel [Stapel 2006] wird eine Projektsituation

eines Großunternehmens geschildert, wo ein Dokument nach dem Doku-

mentenmodell des Unternehmens erstellt werden müsste. Stattdessen wird

dieses Dokument weder erstellt noch irgendwo vorausgesetzt, so ist es nur

im Dokumentenmodell vorhanden. In der unteren Abbildung ist ein Bei-

spiel dieses Problems abgebildet.

Dokumentenmodell: Dokument wird nicht benutzt [Stapel 2006]

Für den Bereich Softwareentwurf sind alle möglichen

UML-Diagrammtypen angegeben, unter anderem auch das Klassen- und

das Aktivitätsdiagramm. Angenommen das Dokument Aktivitätsdiag-

ramm wird nach dem Dokumentenmodell unter Betracht der dynamischen

Aspekte erstellt. Aber nach der Erzeugung merken die Projektbeteiligten

nach der Informationsflussanalyse in FLOW, dass dieses Dokument kei-

ner braucht.

80

Trotz der Erstellung des Dokumentes ist ein negatives Muster aufgetreten.

Das Aktivitätsdiagramm wird zu einem Dead Document, wenn es von

keinem anderen Akteur gebraucht wird.

Entwickler

Aktivitätsdiagramm

DynamischeSicht

modellieren

81

5.2.9 Write For One

[Quelle: http://bildarchiv.kleinert.de/]

Herr Müller ist die einzige Person, die diese Dokumente liest.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster


Mainly Writing

zeitliches Muster


Metapher „Write For One“ bedeutet auf Deutsch „Für Einen schreiben“. Der „Eine“

ist speziell in FLOW als eine Person bzw. ein Akteur gemeint. Wie dieser

Name schon aussagt, bedeutet dieses Muster das Dokumentieren und

Protokollieren eines Ereignisses oder eines Prozesses in schriftlicher Form

für eine einzige Person.

Beschreibung Write For One stellt in FLOW ein Dokument dar, das von einem oder

mehreren Akteuren erzeugt wurden aber nur von einem einzigen Akteur

gelesen oder genutzt wird. Beim Vorkommen eines solchen Musters sollte

man sich überlegen und Gedanken darüber machen, zu welchem Zweck

dieses Dokument dient und warum es unbedingt mit viel Aufwand für diese

einzige Person erstellt werden muss. Ob diese einzige Person auch genauso

gut flüssig und direkt informiert werden kann, um Zeit und Aufwand zu

sparen, wäre z.B. eine Alternative. Diese Informationsübertragung in

schriftlicher Form kann aber auch in bestimmter Weise vorgeschrieben

sein. Sich positiv auswirken kann Write For One durch das Verfestigen

der Informationen und des Wissens in einem Dokument, dadurch versiegen

die Informationen nicht so schnell. Laut Informationsflussanalyse benutzt

zwar zur Zeit der Modellierung nur ein Akteur das Dokument, aber mit der

Zeit könnte es mehr werden. Außerdem dient das Dokument als eine Art

Gedankenprotokoll, was von dem einzigen Akteur bei Bedarf wiederholt

nachgelesen werden kann. Deshalb ist Write For One ein

kontextabhängiges Muster.

+

3

K

82

Charakteristik


Ein einzeln stehendes Dokument

Dieses Dokument wird von einem oder mehreren Akteuren erzeugt.

Es existiert genau einen einzigen festen Informationsfluss, der zu

einem anderen Akteur führt.

Dieser einzige Akteur liest und benutzt dieses Dokument, sonst wird

dieses Dokument von keinen anderen Akteuren genutzt.

Definition:

Variante 1:

Write For One ist strukturell ein dominantes Muster. Die charakteristische

Verbindung zwischen dem einzigen Akteur und dem Dokument

signalisiert Write For One und macht ihm zu einem dominanten Muster.


In der Komplexitätsfacette gehört dieses Muster zu den

mehrdimensionalen Mustern. Es ist strukturell nicht genau linear, da die

Anzahl der Akteure und damit die Anzahl der erzeugenden

Informationsflüsse für das Dokument nicht fest definiert sind.

Mustergruppe Mainly Writing

Im Mittelpunkt von Write For One steht das Dokument, dass von einem

einzigen Akteur gelesen wird. Daher gehört dieses Muster zu der

Mustergruppe Mainly Writing.

Auswirkung


Write For One gehören zu den Mustern mit zeitlicher Auswirkung. Immer

wenn dieses Muster auftritt, kann man von der FLOW-Sicht aus behaupten,

dass einen Zeitverlust stattgefunden hat. Es spielt in diesem Falle keine

Rolle mehr, ob das Erzeugen dieses Dokuments für diese eine Person

gewollt und begründet ist oder nicht. Mit dem Vorkommen von Write For

One ist immer mit einen Zeitverlust und einer Aufwandserhöhung

verbunden. Im Folgenden wird die Ist-Situation der Variante 1 der oberen

AkteurEinzigAkteurN

{n ≥ 1}

Dokument

Akteur1

Akteur2

AkteurEinzigDokument

3

+

83

Definition auf die Zeit abgerollt:

Selbst wenn das Dokument ein Teil eines Prozessmodells ist, das als

vorgeschrieben gilt, kann dies nicht die negative Auswirkung dieses

Muster begründen. In diesem Falle sollte man vielleicht schon mal an den

Sollprozessen arbeiten, um gezielt schwere Dokumentationen evtl. durch

direkte Kommunikation zu ersetzen. Folgender Lösungsvorschlag wäre die

naheliegende Alternative.


Write For One ist ein kontextabhängiges Muster. Im Gegensatz zu Dead

Document benutzt zumindest ein Akteur das erstellt Dokument.

Positive Auswirkung: Ein Write For One kann auch positive

Auswirkung erzielen. Denn die Akteure erzeugen zwar mit sehr viel

Aufwand ein Dokument, dafür wird dieses Wissen verfestigt und

versiegt nicht mehr. Dieses Dokument wird laut

Informationsflussanalyse nur von einem Akteur benutzt, aber dieser

Akteur kann dieses Dokument bei Bedarf wiederholt verwenden und

nachlesen, denn diese Informationen liegen unabhängig in Form einer

Dokumentation vor. Noch idealer wird es, wenn die

Informationsübertragung nicht nur durch das erstellte Dokument

erfolgt, sondern parallel dazu fließen zusätzlich flüssige

Informationen.

In dieser Situation kann das Dokument als eine Art schriftliche

Zeit t

Akteur1 Akteur2

Doku1

AkteurEinzig

tOutput

AkteurEinzigAkteurN

{n ≥ 1}

Dokument

K

84

Gedankenprotokoll zur flüssigen Kommunikation gesehen werden.

Dadurch wird ein besserer Informationsfluss mit weniger Verluste

ermöglicht. In diesem Falle kann das Dokument als eine parallele

Lightweight Documentation betrachtet werden.

Negativer Auswirkung: Write For One ist wie das Muster Dead

Document, ein Warnzeichen für Zeitverlust für das Erstellen des

Dokuments für eine einzige Person im Projekt und immer ineffektiv.

Lösungsvorschlag 1: Das Dokument wird nicht nur von einem

einzigen Akteur, zudem auch noch von anderen Akteuren genutzt. In

der Modellierung ist wahrscheinlich ein Fehler aufgetreten und die

anderen Akteure wurden übersehen.

Unter diesen Umständen lohnt sich der Aufwand für das Erstellen des

Dokumentes, denn es wird von mehreren Personen genutzt, die nicht mehr

leicht direkt informiert werden können.

Lösungsvorschlag 2: Das Erstellen des Dokumentes ist überflüssig.

Das bedeutet, die Kommunikation zwischen dem Zielakteur und den

Startakteuren kann direkt und flüssig ablaufen.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Bürokratie:

Mit diesem Muster gehört Write For One zur selben Mustergruppe.

Verwandt mit Dead Document, Übersprungenem Dokument und

Validierung: [siehe Dead Document und Übersprungenem Dokument]

Validierung kann im Extremfall als eine rollenbasierte Version von

Write for One angesehen werden. Wenn ein Akteur ein Dokument nur

AkteurN

{n ≥ 1}

Dokument AkteurM

{n ≥ 1}

AkteurEinzigAkteurN

{n ≥ 1}

Dokument

85

auf Kundenwunsch erstellt und dieses von keinen anderen Akteuren

gebraucht wird, dann ist es ein Muster Write for One.

Sehr verwandt mit Lightweight Documentation:

Write For One gehört mit Lightweight Documentation zu einer

Mustergruppe Mainly Writing. Im positiven Sinne ist Write For One

verwandt mit Lightweight Documentation. Denn das erstellte

Dokument für den einzigen Akteur kann als einem Gedankenprotokoll

angesehen werden, das bei Bedarf immer wieder von dem Akteur

nachgelesen werden kann.

Gegensätzlich und disjunkt mit Interaktion, Synergie, und

Hierarchie: [siehe Interaktion, Synergie, und Hierarchie]

Auftreten Write For One wurde als Muster erfasst, weil es häufig als

wiederkehrendes Phänomen in Softwareprojekten auftritt. Dieses Muster

ist zwar dominant, allerding ist es schwer als Muster in einem

FLOW-Modell zu identifizieren, wenn die beteiligten Akteure und

Dokumente zusätzlich viel mit anderen Speichern interagiert.

Vorausgesetzt Write For One wird als Muster identifiziert, dann ist es

definitiv als eine Aufwandserhöhung bzw. einen Kommunikationsmangel

festzustellen, was zu einem Zeitverlust führt.

Manchmal tritt Write For One in vielen klassischen Softwareprojekten auf,

die auf Prozessmodellen basieren. Denn da werden viele Dokumente

erzeugt, die wahrscheinlich nur von sehr wenigen, in diesem Falle von

einer einzigen Person gelesen wird. In diesem Falle sollte man vielleicht

schon mal an den Sollprozessen arbeiten, um gezielt solche Muster in der

Zukunft zu vermeiden.

Beispiele In dem Softwareunternehmen SoftNews wird immer monatlich einen

Bericht von zwei Teammitgliedern an dem Projektleiter abgegeben. Dies

hat immer zu unnötigen Zeitaufwand geführt. Stattdessen haben sie sich für

eine direkte Berichterstattung in Form einer Präsentation der Ergebnisse

entschieden. Die zugehörige FLOW-Modellierung könnte wie folgt

aussehen:

Damit kann der Aufwand für das Erstellen eines Dokumentes erspart

Teammitglied1

Teammitglied2

ProjektleiterBericht

86

werden und der Informationsfluss verläuft schneller und effizienter. Auf

die Zeit abgerollt zeigt sich die folgende FLOW-Darstellung:

Die Zeit tOutput in dem Abschnitt Form ist deutlich größer als dieses

Beispiel. Das bedeutet durch die direkte Kommunikation konnte viel Zeit

gewonnen werden. Zusätzlich ist eine flüssige Kommunikation effizienter

und kann schnell von dem Empfänger aufgenommen werden. Dagegen ist

aber das Dokument stabil und stets immer verfügbar. Daher sollte man

beim Anwenden des Lösungsvorschlags immer auf das Ziel des Projektes

achten.

Zeit t

Teammitglied1 Teammitglied2

Bericht

Projektleiter

tOutput

87

5.2.10 Wiederholte Information

Fritz erzählt Werner eine Geschichte über zwei Mönche in einem Kloster. Doch der Inhalt der

Geschichte wiederholt sich immer und die Geschichte könnte unendlich sein.


Komplexität:

Mustergruppe:

Form:

Qualität:

rezessives Muster

lineares Muster

Parallele Flüsse, Talking Only

zeitliches Muster


Metapher Eine „Wiederholung“ ist ein erneutes Auftreten eines Objekts, Ereignisses

oder Phänomens. Diese Kopien können in regelmäßigen zeitlichen oder

räumlichen Abständen wieder auftreten oder stochastisch, also zufällig

angeordnet sein. Im alltäglichen Gebrauch bedeutet „Wiederholte

Information“ wortwörtlich, dass eine Information ständig noch mal

vorkommt oder in Erscheinung tritt.

Beschreibung Eine Wiederholte Information bedeutet in FLOW, dass sich die gleiche

Information eines Informationsflusses zu unterschiedlichen Zeitpunkten

auftritt, und immer wieder von demselben Startakteur zum selben

Zielakteur übertragen wird. Durch die Wiederholung werden mehr Zeit in

Anspruch genommen und der Aufwand erhöht sich dadurch. Man muss

hierbei wieder unterscheiden, ob die Wiederholung dieser flüssigen

Information zur Bewährung von der ausreichend übertragenen

Informationsmenge gewollt und begründet ist, oder sich nur redundant und

überflüssig auswirkt.

Charakteristik

Struktur Es existieren ein Startakteur, der eine Information übermittelt, und ein

Zielakteur, der dieselbe Information empfängt.

Ein Informationsfluss mit einer bestimmten Information wird von dem

Startakteur zum Zielakteur übertragen

Diese Information wird nicht nur einmal übertragen, sondern sie wird

wiederholt vom Startakteur bis zum Zielakteur zu unterschiedlichen

–

2

K

–

88

Zeitpunkten übermittelt.

Definition:

Diese Definition ist allerdings nicht sinnvoll. Denn eine

FLOW-Darstellung, die zwischen zwei selben Akteure die gleiche

Informationsflüsse mehrere Male ließen, ist nicht erlaubt. Nur unter

Einbeziehen des zeitlichen Aspekts wäre so eine FLOW-Darstellung Sinn

machen. Daher wäre so ein Muster nur unter folgende Variante in einem

FLOW-Modell erkennbar:

Variante:

Dies ist auch die einzige erlaubte Variante in einem FLOW-Modell, da eine

bestimmte Information nur ein Mal modelliert wird, egal ob diese mehrere

Male oder mehrmals zu unterschiedlichen Zeitpunkten übertragen wurde.

Allerdings ohne Einbeziehen des zeitlichen Aspekts ist das Muster gar

nicht auffällig erkennbar. Deshalb gehört Wiederholte Information zu den

rezessiven Mustern.


Wiederholte Information wird zu den linearen Mustern zugeordnet. Die

Struktur des Musters ist relativ einfach gehalten, und die

Informationsflüsse fließen alle in dieselbe Richtung. Zwar können mehrere

Flüsse zwischen den beiden Akteuren vorkommen, dennoch ist die

Struktur überschaubar und im Allgemeinen als linear zu betrachten.

Mustergruppe Parallele Flüsse, Talking Only

Das Muster Wiederholte Information besitzt laut Definition nur agierende

Akteure und zwischen ihnen fließende flüssige Informationen, daher

gehört dieses Muster zur Mustergruppe Talking Only. Zusätzlich fließen

die flüssigen Informationsflüsse von demselben Startakteur zum selben

Zielakteur. Dies erfüllt wiederum die Voraussetzung für die Mustergruppe

Parallele Flüsse.

Auswirkung


Die Wiederholte Information ist ein zeitliches Muster. Die obere Definition

gibt nur an, dass zwischen den beiden agierenden Akteuren dieselbe

Information sich immer wiederholt. Eigentlich wären mehrere flüssige

Informationsflüsse zwischen zwei Akteure in FLOW nicht sinnvoll, aber

{n ≥ 1}

<Information1>

StartAkteur ZielAkteur

<Information1>


2

89

mit Abrollen auf die Zeit wird die FLOW-Darstellung zweckmäßig als

sinnvoll gesehen. Denn mit Betrachtung des zeitlichen Aspekts kann die

Charakteristik des Musters durch das folgende Beispiel verdeutlicht

werden.

Beispiel:

Die Information1 wurde nach Zeit t1 zum zweiten Mal an dem Zielakteur

übertragen. In der Zeit t1 könnte durchaus andere Tätigkeiten und

Aktivitäten ausgeführt wurden sein. Nach der Zeit t2 wurde die

Information1 wieder an Zielakteur übertragen.


Negative Auswirkung: Wiederholte Information ist ein Muster mit

negativer Auswirkung, nur wenn von der Menge der empfangenen

Informationen von dem Zielakteur abgesehen. Beim oberen Beispiel

ist ersichtlich, dass durch die wiederholte Übertragung eindeutig zu

Zeitverluste geführt hat. Die Wiederholung von

Informationsübertragung ist in diesem Falle redundant und daher

überflüssig.

Positive Auswirkung: Aber flüssige Informationen sind sehr flüchtig.

Durch direkte Gespräche und handschriftliche Kritzeleien kann man

flüssige Informationen schnell transportieren. Aber flüssige Informa-

tionen gehen auch leichter verloren oder werden vergessen. Daher

kann durchaus eine Wiederholte Information sich positiv auswirken,

um bestimmte wichtige flüssige Information im Kopf des Zielakteurs

zu „verfestigen“. Es stellt sich dabei offensichtlich die Frage, warum

man diese Wiederholung nicht gleich schriftlich festhält und doku-

Zeit t


t1

t2

K

90

mentiert. Die Antwort auf diese Frage kann auf den zeitlichen Aspekt

zurückzuführen. In vielen Projekten, wo die Zeit eine wichtige Rolle

spielen, wie z.B. in Projekten mit agilen Ansätzen, erlaubt der Zeit-

druck und die Flexibilität keine schwerwiegenden Dokumentationen.

Diskussion

Verweis auf

Muster


So

litär

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Osmose, Stille Post, Synergie und

Übersprungenes Dokument:

Mit diesen Mustern gehört Wiederholte Information zur selben

Mustergruppe.

Gegensätzlich und disjunkt mit Interaktion, Validierung und

Lightweighted Documentation: [siehe Interaktion]

Lightweighted Documentation kann die die flüssige Information in der

Wiederholte Information ohne viel Aufwand dokumentiert werden.

Damit müsste dann diese Information nicht dauernd wiederholt

werden um den Informationsgehalt zu sichern. Auf diese

leichtgewichtige Dokumente kann bei Bedarf verwiesen werden.

Zusätzlich gehört Wiederholte Information mit Lightweighted

Documentation zur selben Mustergruppe Parallele Flüsse. Eine

Wiederholte Information könnte z.B. mit einer Validierung behoben

werden, wenn die wiederholte Information von einem Kunden kommt.

Durch eine Validierung können die flüssigen Anforderungen und

Informationen verfestigt werden und somit vom Kunden sichergestellt

werden.

Auftreten Wiederholte Information taucht relativ häufig in Softwareprojekten mit

agilen Ansätzen auf. Ein agil arbeitendes Projektteam wird beispielsweise

einige Dokumente nicht erstellen, die für prozessmodellbasierte Projekte

selbstverständlich wären. Umgekehrt wird es einem konventionellen

Projekt nicht gelingen, unter Beachtung seiner eigenen Vorgaben und

Prozesse innerhalb weniger Tage eine größere Änderungsanforderung

aufzunehmen und umzusetzen. Agile Methoden ermöglicht dies, da sie die

Informationen auf mündlichen bzw. flüssigen Wegen weiterleiten und

mehr auf direkte Mensch-Zu-Mensch Kommunikation angewiesen sind.

Daher kommen Wiederholte Information in solchen Projekten schon

häufiger vor als in den konventionellen. Eine flüssige Information kann

91

oftmals wiederholt werden, um Missverständnisse und Vergessenheit

vorzubeugen, da diese flüchtig sind und nicht lange im Gedächtnis haften

bleibt.

Beispiele Eine Wiederholte Information kann im Prinzip im jedem Muster stecken,

wo Informationsflüsse zwischen zwei Akteuren wiederholt von einem

Akteur zum anderen übertragen wird. Es kann in vielen anderen Muster

versteckt sein kann. Wiederholte Information ist von der Struktur her sehr

einfach gehalten und daher ist sehr einfach zu verstehen. Ein Beispiel muss

nicht noch zusätzlich angegeben werden, um den Verständnis zu stärken.

92

5.2.11 Person als Senke

[Quelle: http://bildarchiv.kleinert.de/]

Herr Ruderer bekommt alles um die Ohren. Er ist die Senke der gesprochenen Befehle.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster


Unterbrechung


negatives Muster

Metapher Der Begriff „Senke“ wird in der Physik, der Elektrotechnik und den

Wirtschafts- und Geowissenschaften als das Gegenteil einer Quelle

bezeichnet. In der Graphentheorie der Informatik ist eine Senke ein Knoten

in einem gerichteten Graph, welcher keinen Nachfolger hat.

Beschreibung Die Bedeutung von „Senke“ in der Graphentheorie der Informatik wurde

auch für das Muster Person als Senke in FLOW übernommen. Eine Person

bzw. ein Akteur ist eine „Senke“ in FLOW, wenn er nur Informationen von

anderen erhält oder bekommt, aber nichts von sich hergibt oder

weiterleitet. D.h. aus ihm entspringt kein einziger Informationsfluss. In der

Realität ist so eine Person meist wegen der vielen Informationen

überfordert und kommt einfach nicht dazu, die wichtigen und wertvollen

Informationen weiter zu übertragen. Eine Person als Senke stellt eine

Unterbrechung und Versickern des Informationsflusses dar und kann sich

nur negativ auf ein Softwareprojekt wirken.

Charakteristik

Struktur Ein einzeln stehendes Akteur

Um diesen Akteur herum fließen nur Informationsflüsse hinein.

Mindestens zwei Informationsflüsse fließen in diesem Akteur hinein.

Aus diesem Akteur fließen keine Informationsflüsse heraus, d.h.

dieser Akteur bekommt sehr viele Informationen, verarbeitet diese

aber nicht und leitet sie nirgends weiter.

Definition:

{1, 2,…}

+

3

N

+

93

Variante 1:

Variante 2:

Eine Person als Senke ist strukturell wie ein Dead Document, aber im

Mittelpunkt des Musters steht kein Dokument, sondern eine Person. Seine

Eigenschaften sind ausschließlich durch seine strukturelle Definition

geprägt. Daher ist dieses Muster ein dominantes Muster. Durch „scharfes

Hinsehen“ sticht eine Person als Senke genau wie ein Dead Document

sofort ins Auge aufgrund der zu sich hinein aber nicht wieder von sich

heraus fließenden Informationsflüsse. So eine Senke bedeutet, die

Informationen versinken an dieser Stelle und die Übertragung ist

unterbrochen.


Person als Senke gehört in der Komplexitätsfacette zu den

mehrdimensionalen Mustern. Die Voraussetzung für so ein Muster ist zwar

sehr einfach gehalten, aber die Anzahl der Informationsflüsse und der

beteiligten Akteuren ist nicht beschränkt.


Person als Senke wird mit Dead Document zusammen zu der

Mustergruppe Unterbrechung zugeordnet. Es erfüllt die Voraussetzung,

dass an diesem Muster die Information an dem Ursprung oder zum Ende

gefunden wird. Die Informationsübertragung unterbricht an so eine Person

als Senke.

Auswirkung


Person als Senke ist ein Muster mit quantitativer Auswirkung, wie das

Muster Dead Document. Diese Person bekommt viele Information von

anderen Akteuren und benutzt evtl. auch viele Dokumente. Aber er

vermittelt sein gewonnenes Wissen nicht an anderen Akteuren weiter. Der

AkteurSenke

{n ≥ 2}

AktivitätN

Akteur1

Anforderungenerheben

AkteurSenke

Doku1

Doku2

AkteurSenke Akteur2

3

{1, 2,…}

94

Informationsfluss versickert an ihm. Das heißt die Informationsmenge,

womit dieser Akteur den anderen Speicher versorgen sollte, beträgt TAkteur

= 0. Dies führt definitiv zu einer negativen Auswirkung.


Person als Senke ist eine Senke, die keine Informationen weiter überträgt.

Daher wirkt so ein Muster sich stets negativ auf das Projekt aus.

Die Person als Senke würde mit den vielen Informationen gar nicht zurecht

kommen und würde diese als eine Belastung ansehen. Daher könnte er

überfordert sein und seine Unzufriedenheit würde seine Arbeit

beeinträchtigen. Dies kann einer der Gründe dafür sein, warum er nicht

dazu kommt, sein gewonnenes Wissen und seine erhaltene Information an

andere weitergeben.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Verwandt mit Alleinkämpfer:

Mit Alleinkämpfer ist Person als Senke verwandt, da diese beiden

Muster strukturelle ähnlich sind. Ein Alleinkämpfer ist durch seine

viele Informationsflüsse zu sehr überfordert und belastet. Das kann

auch eine Person als Senke sein durch die vielen in sich hinein

fließenden Informationsflüsse bekommt.

Sehr verwandt mit Solitär und Dead Document: [siehe Solitär und

Dead Document]

Gegensätzlich und disjunkt mit Interaktion, Osmose und Hierarchie:

[siehe Interaktion, Osmose und Hierarchie]

Auftreten Person als Senke ist ein negatives Muster. Immer wenn dieses Muster

Akteur1

Doku1

Doku2

AkteurSenke Akteur2

Akteur3

N

95

auftritt, dann deutet es auf einen Kommunikationsfehler in dem Projekt.

Gottseidank ist dieses Muster ein nicht häufig gesehenes Muster in der

Softwareentwicklung. Denn es würde ziemlich auffallen, wenn ein Akteur

im Projektteam keine relevanten Informationen an andere weitergeben.

Allerdings wenn so ein Muster in einem FLOW-Modell entdeckt wird, ist

das ein Warnsignal für schlechte Kommunikation und Wissenstransfer.

Beispiele In dem Softwareunternehmen SoftNews soll ein externer beratender



den Teammitgliedern die Zusammenarbeit erleichtern. [Siehe hierzu

Solitär]

Aber leider ist es den Teammitgliedern nach einer FLOW-Analyse

aufgefallen, dass dieser Experte keine Erfahrung an den Beteiligten

übermittelt hat. Er hat sowohl keine Einzelgespräche als auch keine

gemeinsame themenbezogene Versammlung geführt, obwohl die einzelnen

Teammitglieder entweder schon ihm persönlich berichtet oder schriftliche

Stellungnahme zugeschickt.

Eine Ursache könnte bei dem Experten liegen. Er bekommt zu viele

Informationen und ist erstmal überfordert. Wenn nach einer Zeit immer

noch nichts passiert, dann sind definitiv noch andere Ursachen zu klären.

[Fortsetzung siehe Alleinkämpfer]

Extern.Berater

Analytiker

Entwickler

ArchitektErfahrungsbericht

Entwickler

96

5.2.12 Missing Experience

Trotz guter Planung ist leider das dreistöckige Familienhaus aufgrund fehlender Erfahrung

eine Hütte geworden.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster

unitäres Muster

Abweichung Ist-Soll


negatives Muster

Metapher „Experience“ ist das englische Wort für „Erfahrung“. „Missing

Experience“ bedeutet wiederum auf Deutsch, „keine, fehlende oder

vermisste Erfahrung“. Eine „Erfahrung“ ist einerseits ein Erlebnis im Sinne

eines wahrgenommenen Ereignisses, und andererseits die Gesamtheit aller

aus Wahrnehmungen, Sinneseindrücken und kognitiven Prozessen der

Auseinandersetzung mit der Umwelt und sich selbst erworbenen

Kenntnissen oder Fähigkeiten. Alles, was in unserem Gedächtnis aus

vergangenen Erlebnissen haften bleibt, abrufbar ist und schließlich

angewendet werden kann, wird als Erfahrung bezeichnet. Fast alle

Lernprozesse, bzw. Wissenszuwachs sind mit vorausgehender Erfahrung

verbunden. Unter Erfahrungsaustausch versteht man meistens das

gegenseitige Lernen.

Beschreibung Missing Experience ist ein sehr spezielles Muster in FLOW. Es bedeutet

ein Muster, das, im Gegensatz zu den anderen Mustern, aus keinem

konkreten Informationsfluss oder Informationsspeicher besteht. Wenn in

einem FLOW-Modell keine einzigen Erfahrungsflüsse vorzufinden sind,

egal ob aus Vergessenheit keine Erfahrung modelliert sind oder es wurden

einfach keine Erfahrungen ausgetauscht, dann ist das ein Muster Missing

Experience mit definitiv negativer Auswirkung. Es ist ein FLOW-Muster

mit prüfenden Funktionen. Denn aus Erfahrung kann man behaupten, dass

wenn in einem Softwareprojekt keine Erfahrungen fließen, bringt dieses

sicherlich negative Auswirkung mit sich. Und Missing Experience kann

{1, 2,…}

+

1

N

97

sehr schnell in einem FLOW-Modell identifiziert werden.

Charakteristik

Struktur In dem gesamten FLOW-Modell ist kein einziger grauer

Erfahrungsfluss modelliert.

Keine Erfahrungsflüsse werden verfestigt.

Definition:

Diese FLOW-Definition für Missing Experience dient lediglich zur

formalen Beschreibung. Denn so ein Muster in FLOW-Notation

darzustellen wäre zweckmäßig überflüssig.

Obwohl dieses Muster aus keinen charakteristischen Informationsflüsse

oder Informationsspeicher besteht, ist es ein dominantes Muster. Gerade

weil die Definition keine Erfahrungsflüsse voraussetzt, wird dieses Muster

strukturell dominant. Missing Experience kann immer als erstes bei der

Informationsflussanalyse eingesetzt werden, um große Erfahrungsmängel

im Projekt zu identifizieren.


Missing Experience stellt ein Muster dar, dass in dem gesamten

FLOW-Modell keine Erfahrungsflüsse vorzufinden sind. Die Definition ist

sehr einfach gehalten, daher gehört es auch zu den unitären Mustern.

Mustergruppe Abweichung Ist-Soll

Missing Experience ist ein Muster der Mustergruppe Abweichung Ist-Soll.

In der Ist-Situation befinden sich keine modellierten Erfahrungsflüsse und

diese weicht definitiv von der Soll-Situation ab.

Soll-Situation Erfahrungen werden in den Projekten ausgetauscht

und diese sollen auch erfasst werden. In einem entsprechenden

FLOW-Modell sollen Erfahrungsflüsse gezielt ausgetauscht werden,

um den Projekterfolg zu unterstützen. Diese sollen zwischen den

Akteuren auf bestimmte Art und Weise fließen.

Missing Experience ist die Ist-Situation, die eindeutig von dieser

Soll-Situation abweicht.

Auswirkung


Es ist eindeutig, dass Missing Experience quantitative Auswirkung auf das

Projekt hat. Auf die Erfahrungsflüsse bezogen, ist die geflossene

Erfahrungsmenge in dem FLOW-Modell 0. Seine Charakteristik ist

einzigartig durch „keine Erfahrungsflüsse“ geprägt. Das heißt, wenn ein

Missing Experience identifiziert wurde, dann ist quantitativ gesehen die

Anzahl der modellierten Erfahrungsflüsse gleich 0, und die beteiligten

Akteure tauschen keine Erfahrungsflüsse aus.

FLOW-Modell

+

1

{1, 2,…}

98


Missing Experience ist sicherlich ein Muster mit negativer Auswirkung.

Die Ursachen für die negative Auswirkung sind leicht zu erklären:

Die Erfahrungsflüsse wurden abweichend zu der Soll-Situation aus

Vergessenheit und unpräzisen Arbeit nicht modelliert oder verfestigt,

dies ist der unkritische Fall.

Kritischer wird es, wenn überhaupt keine Erfahrungen zwischen den

Akteuren ausgetauscht wurden und somit auch keine Erfahrung zu

modellieren existieren.

In beiden Fällen verursacht das Muster negative Auswirkung auf das

Projekt. Jedoch kann die negative Auswirkung von keinem

Erfahrungstausch in dem Projekt nach der Identifizierung nicht so schnell

behoben werden. Es würde evtl. eine Umstrukturierung und

Kommunikationsförderung der Akteure und sogar das Aufstellen eines

Experience Bases für das gesamte Projekt bedeuten.

Besonders in den Projekten mit erfahrungsbasierten Methoden, die auf

systematischem Lernen aus Erfahrung aufbauen, müssen Erfahrungen

erfasst und sogar verfestigt werden. Wenn aber stattdessen Missing

Experience identifiziert wird, dann müssen die Ursachen dafür auf jeden

Fall geklärt werden.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Permuted Order, Write For One, und

Übersprungenes Dokument:

Mit diesen Mustern gehört Missing Experience zur selben

Mustergruppe Abweichung Ist-Soll.

Gegensätzlich und disjunkt mit Osmose und Experienced Expert:

Da eine Osmose ungezwungen und unbewusst passiert, könnte man bei

Missing Experience nochmal nachgehen, ob man evtl. einen

Erfahrungsaustausch in Form einer Osmose vergessen oder übersehen

hat. Ein Erfahrungsaustausch in Form einer Osmose kann den

negativen Effekt des Missing Experience beseitigen.

Experienced Expert könnte das Lösungsmuster für Missing Experience

sein. Denn eine einfache Methode um Missing Experience bei keinem

stattgefundenen Erfahrungsaustausch zu beheben, wäre einen

N

99

Experienced Expert in dem Projekt einzusetzen und nur Erfahrungen

mit den Akteuren austauschen oder Erfahrungsflüsse in das Projekt

herbei steuern.

Auftreten Erfahrungsbasierte Methoden bauen sehr stark auf direkte

Kommunikation, jedoch werden Erfahrungen typischerweise über

Projektgrenzen hinweg ausgetauscht. Es werden zentrale Erfahrungsbasen

errichtet und Austausch in verschiedenen Gruppierungen gefördert. Dafür

ist Missing Experience ein sehr gutes Muster, um überhaupt die Existenz

von Erfahrungen in einem Projekt zu prüfen. Es ist ein sehr leicht

gefundenes Muster. Die Auftretenshäufigkeit kann aber dadurch nicht

ausgesagt werden. Dieses Muster kann ebenfalls zur schnellen und

zeitsparenden Beurteilung der Kommunikation eines Softwareprojektes

genutzt werden.

Beispiele Das folgende Beispiel bezieht sich auf das Beispiel von Solitär: In dem

Softwareunternehmen „SoftNews“ soll ein externer beratender Spezialist

mit seiner Erfahrungen ein nicht vorankommendes Softwareprojekt

bereichern. Leider ist es den Teammitgliedern nach einer

Informationsanalyse in FLOW aufgefallen, dass dieser Experte gar keine

Erfahrungen zu dem Projekt beigetragen hat. Und überhaupt wurde kein

einziger Erfahrungsfluss im gesamten Modell modelliert und verfestigt.

Durch die schlechte Kommunikation und keinen Erfahrungsaustausch ist

das Projekt zum Stillstand gekommen.

In diesem Softwareprojekt ist das Muster Missing Experience mit

negativen Folgen aufgetreten.

Externer Berater

Softwareprojekt des SoftNews

100

5.2.13 Permuted Order

[Quelle: http://old.hki.uni-koeln.de]

Beim Programmieren wird die Reihenfolge einer verketteten Liste vertauscht.


Komplexität:

Mustergruppe:

Form:

Qualität:

rezessives Muster

Kombinatorisches Muster

Abweichung Ist-Soll

zeitliches Muster


Metapher „Permuted Order“ bedeutet auf Deutsch „vertauschte Reihenfolge“. Eine

Reihenfolge wird durch die Anordnung mehrerer Elemente in einer

geordneten Folge bestimmt. Reihenfolgen ergeben sich oftmals durch

Sortierung aufgrund von bestimmbaren Größen. So kann man die Zahlen

zwischen 1 und 5 nach ihrer Größe ordnen und in eine bestimmte

Reihenfolge bringen: 1, 2, 3, 4, 5. Und eine „vertauschte Reihenfolge“

bedeutet sinngemäß, dass die ursprüngliche Reihenfolge vertauscht und

durcheinander gebracht wurde. Ein Vertauschen der Elemente 3 und 4 der

eben erwähnten Reihenfolge von 1 bis 5 wäre z. B. : 1, 2, 4, 3, 5.

Beschreibung Mit Permuted Order stellt in FLOW ein Muster dar, das die Reihenfolge

der ursprünglich nacheinander auszuführenden FLOW-Aktivitäten

vertauscht. Diese Aktivitäten können eine Kombination aus

FLOW-Elementen, aber auch nur einfache Informationsflüsse. Wie genau

die Vertauschung stattfindet und wie sie passiert, ist nicht fest definiert. Sie

kann in beliebiger Form stattfinden. Nach der Vertauschung weicht die

Situation aber definitiv von der Soll-Situation ab. Daher ist dieses Muster

zwar ein häufig auftretendes Muster, aber es ist sehr schwer als Muster zu

identifizieren, da für seine Ist-Situationen keine einheitliche, formale und

verallgemeinerte Definition existiert. Denn in einem FLOW-Modell kann

die Reihenfolge auf unterschiedlichste Art und Weise vertauscht werden.

–

4

K

101

Charakteristik

Struktur Unterschiedliche Aktivitäten in einem FLOW-Modell werden

nacheinander ausgeführt werden.

Die Reihenfolge dieser Aktivitäten ist aber stattdessen vertauscht

unter Betrachtung des zeitlichen Aspekts.

Definition: [siehe Aspekt Mustergruppe]

Strukturell betrachtet ist Permuted Order ein rezessives Muster. Denn

seine Struktur kann nicht auf bestimmte festgelegte FLOW-Elementen zu

führen. Um ein Permuted Order strukturell in einem FLOW-Modell zu

identifizieren muss man schon eine genaue Informationsflussanalyse

durchführen.


In der Komplexitätsfacette gehört Permuted Order zu den

kombinatorischen Mustern. Es ist nicht genau fest definierbar, welche

Aktivitäten stattfinden und somit könnte die Struktur der Aktivitäten sehr

komplex und unübersichtlich sein.

Mustergruppe Abweichung Ist-Soll

Wie in der Beschreibung schon angedeutet, gehört Permuted Order zu der

Mustergruppe Abweichung Ist-Soll. Es ist allerdings sehr schwierig, die

gewollte Soll-Situation von der Ist-Situation zu unterscheiden, somit

erhöht sich die Schwierigkeit überhaupt dieses Muster zu identifizieren.

Trotzdem ist es eindeutig ein abweichendes Muster, schließlich ist

Permuted Order so definiert, dass die Ist-Situation von der Soll-Situation

in der Reihenfolge unterscheidet. Unten ist eine Variante der Soll-Situation

mit drei unterschiedlichen nacheinander auszuführenden Aktivitäten

dargestellt, die auf die Zeit abgerollt sind.

Soll-Situation:

4

–

102

Im Folgenden werden zwei Varianten der möglichen Ist-Situation

abgebildet, wie es in FLOW aussehen kann, aber von der Soll-Situation in

der Reihenfolge abweicht.

Ist-Situation 1: Aktivität2 und Aktivität3 werden parallel ausgeführt.

Ist-Situation 1: Die Aktivitäten werden in der Reihenfolge ganz

vertauscht und weiter nacheinander ausgeführt.

Zeit t

Aktivität1

Aktivität2

Aktivität3

Zeit t

Aktivität1

Aktivität2

Aktivität3

103

Auswirkung


Die zeitliche Abfolge der Ausführung der verschiedenen Aktivitäten spielt

eine sehr wichtige Rolle beim Permuted Order. Seine Charakteristik ist

ausschließlich durch den zeitlichen Aspekt geprägt und daher ist dieses

Muster ein zeitliches Muster. Außerdem könnten Aufwand und Zeit sogar

gespart werden, wenn einige Aktivitäten parallel ausgeführt werden.

Folgendes Beispiel zeigt, dass bei einer Parallelausführung die Zeit für das

Abarbeiten der drei Aktivitäten tExecute viel kleiner ist als bei der oberen

Soll-Situation.

Beispiel:

Zeit t

Aktivität1

Aktivität2

Aktivität3

Zeit t

Aktivität1

Aktivität2

Aktivität3

tExecute

104


Permuted Order ist ein Muster mit kontextabhängiger Auswirkung. Es

stellt sich hierbei wie beim Muster Hierarchie oder Übersprungenes

Dokument, ob die vertausche Reihenfolge des Abarbeitens der Aktivitäten

gewollt und begründet ist oder nicht.

Positive Auswirkung: Wenn der Tausch zweckmäßig dient, wie zum

Beispiel um Aktivitäten aus Zeitspargründen oder praktischen

Gründen parallel ausführt, dann ist Permuted Order wohlüberlegt und

beabsichtigt.

Negative Auswirkung: Wenn aber der Permuted Order unbeabsichtigt

aber dennoch identifiziert wird, dann ist das Muster definitiv negativ.

In diesem Falle muss man wieder in den Sollprozessen des

Vorgehensmodells nachbohren und evtl. Unstimmigkeiten darin

korrigieren. Eine Kommunikations- störung könnte die Ursache sein,

muss aber nicht unbedingt.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Missing Experience:

Mit diesem Muster gehört Permuted Order zur selben Mustergruppe

Abweichung Ist-Soll.

Sehr verwandt mit Übersprungenes Dokument: [siehe


Gegensätzlich und disjunkt mit Validierung, Hierarchie, Kunde zu

Analytiker, Analytiker zu Architekt und Architekt zu Entwickler: [siehe

Hierarchie]

Permuted Order ist sicherlich ein Problemmuster für die Muster, deren

Charakteristik durch die Reihenfolge der Aktivitäten geprägt ist.

Die Reihenfolge der Kommunikation ist bei den Mustern Kunde zu

Analytiker, Analytiker zu Architekt und Architekt zu Entwickler streng

rollenbedingt fest und wären definitiv keine positive Muster mehr,

wenn die Reihenfolge der Kommunikation ausgetauscht werden.

Und der Informationsverlust in Permuted Order könnte durch eine

Validierung behoben werden, wenn die Informationen und

Anforderungen von Kunden kommen, was meistens der Fall ist. Daher

ist unter Umständen eine Validierung ein Lösungsmuster für Permuted

K

105

Order.

Auftreten Das Muster Permuted Order stellt also ein Muster dar, dass die

auszuführende Aktivitäten bei der Ausführung in der Reihenfolge auf

bestimmter Weise von der Soll-Situation abweicht. Die Abweichung kann

beliebig sein. Wenn die Ist-Situation irgendwie in der Reihenfolge der

Ausführung von der Soll-Situation abweicht, dann ist Permuted Order

aufgetreten. Durch diese Aussage kann aber trotzdem die Häufigkeit des

Vorkommens von Permuted Order nicht geschätzt werden, da es durch die

vage Definition schwer erkennbar ist in einem Softwareprojekt und evtl.

durch viel Aufwand erst identifiziert werden kann.

Beispiele In einem kleinen Softwareprojekt eines Unternehmens aus der

Bankenbrache [Stapel 2006] hat sich ergeben, dass bestimmte Aktivitäten

schon begonnen werden, bevor die vorangegangene Aktivität

abgeschlossen ist. Der Informationsfluss ist vereinfacht wie folgt

dargestellt:

Ausschnitt aus Soll-Prozess [Stapel 2006]

Zeitlich abgerollt sieht die obere Abbildung mit dem Dokumentenfluss

von „fachlicher Entwurf“ bis zur „Implementierung“ folgendermaßen aus:

Soll-Situation:

106

Es wurde aber in der Wirklichkeit mit der „Implementierung“ aus

Zeitgründen begonnen, obwohl der „Softwareentwurf“ noch nicht in der

endgültigen Version vorliegt. Erste Programmteile wurden schon erstellt,

wenn der „Softwareentwurf“ noch nicht alle notwendigen Informationen

enthält. Diese Aktivitäten laufen also teilweise parallel ab wie in der

folgenden Situation

Ist-Situation:

Zeit t

Softwareentwurf erstellen

Implementierung

fachlicher Entwurf

Softwareentwurf

107

Zeit t

Softwareentwurf erstellen

fachlicher Entwurf

Softwareentwurf

Implementierung

108

5.2.14 Lightweight Documentation

[Quelle: http://www.fao.org/docrep/007/y3548e/y3548e07.htm]

Eine Gruppe von arabischen Agrarwissenschaftlern hat sich zusammengesetzt. Bei der Diskussion

um die Anschaffung von Kühen dokumentierten sie ohne viel Aufwand die wesentlichen Aspekte

auf einem Flip Chart.


Komplexität:

Mustergruppe:

Form:

Qualität:

rezessives Muster


Mainly Writing, Parallele Flüsse


positives Muster

Metapher Unter „Dokumentation“ versteht man die Verfestigung und

Nutzbarmachung von Informationen zur weiteren Verwendung. Ziel der

Dokumentation ist es, der dokumentierte Informationsgehalt, der mit Hilfe

der Dokumentation systematisch verwertet werden soll, gezielt

auffindbar und wiederverwendbar zu machen. Dokumentation bedeutet in

den Bereichen Projektmanagement und Softwareentwicklung, sämtliche

Schritte und Maßnahmen aufzuschreiben und zu protokollieren mit dem

Ziel, zum späteren Zeitpunkt bei Bedarf wieder den Prozess

nachvollziehen zu können.

Der Begriff „Leichtgewichtige Dokumentation“ stammt aus dem Namen

LIDs, was speziell für „Light-Weight Documentation of Experiences“

steht. LIDs ist eine Spezialtechnik zur systematischen

Software-Prozessverbesserung und wurde im Software Experience Center

von DaimlerChrysler im Jahre 2000 entwickelt. Bei diesem Ansatz werden

insbesondere die Erfahrungen der Mitglieder von Softwareprojekten direkt

nach deren Ende gesammelt und ohne viel Aufwand dokumentiert, um sie

in anderen Projekten wiederverwenden und nutzbar machen zu können.

Beschreibung Für dieses Muster wurde der Begriff Lightweight Documentation

[Schneider 2007] verallgemeinert. Es bezeichnet in FLOW eine parallel zu

{1, 2,…}

–

4

P

109

einer bestimmten Aktivität verlaufende Dokumentation, die ohne viel

Aufwand- und Zeitinvestition erstellt werden kann. Aus dieser

leichtgewichtigen Dokumentation ergeben sich einige Daten und

Dokumente, die ebenfalls abgelegt werden, um sie für den weiteren

Projektablauf nutzbar zu machen und bei Bedarf nachgeschlagen werden

zu können. Daten aus einer Lightweight Documentation unterscheiden sich

von normalen Dokumenten grundsätzlich in deren Form und

Ausführlichkeit. Zum Beispiel könnte eine Lightweight Documentation in

FLOW eine Audio-Datei eines aufgenommenen Gespräches sein, Fotos

von den Flip-Charts oder wohlbehaltene, nummerierte handschriftliche

Notizen und skizzierte Schriftstücke. Dennoch ist eine leichtgewichtige

Dokumentation aufgrund der vagen Formulierungen und schwer

nachvollbaren Notizen und Skizzierungen gegenüber einer richtigen

ausführlichen Dokumentation benachteiligt und bleibt daher nur eine

Alternative oder Notlösung für überhaupt keine Dokumentation. Eine

Lightweight Documentation ist daher keine Allzwecklösung oder

Wunderheilmittel für nicht verfestigte Informationsflüsse in Dokumenten.

Charakteristik

Struktur Eine bestimmte Aktivität wird zwischen mehr als zwei Akteuren

ausgeführt.

In diese Aktivität fließenden Informationsflüssen sind ausschließlich

flüssig.

Parallel zu dieser Aktivität wird eine Dokumentation geführt, mit der

Bedingung, dass diese Dokumentation leichtgewichtig erstellt wird,

d.h. mit weniger Aufwand als eine richtige Dokumentation.

Definition: Mit Blackbox-Darstellung

Variante 1: Eine Variante, die die obere Definition sehr vereinfacht

darstellt.

AkteurN

{n ≥ 1}

LeichteDokuN

Aktivität1

Leichtgewichtige Dokumentation

{n ≥ 1}

AkteurM

{n ≥ 1}

–

110

Eine Lightweight Documentation ist ein rezessives Muster. Die strukturelle

Definition kann ziemlich komplex und unübersichtlich sein, daher kann so

ein Muster nur nach genauer Analyse des Modells identifiziert werden.


Die Struktur der parallel laufenden Aktivität ist zwar nicht bekannt, aber in

diesem Muster geht es nur um die dazugehörige leichtgewichtige

Dokumentation. Diese Lightweight Documentation in der Blackbox wird

parallel zu der Aktivität ausgeführt, es bekommt Informationen von der

Aktivität und erzeugt dabei einige leichtgewichtige Dokumente. Dieses

Muster ist ein aus vielen möglichen FLOW-Elementen zusammengesetztes

Muster und daher auch ein kombinatorisches Muster.

Mustergruppe Mainly Writing, Parallele Flüsse

Im Mittelpunkt der Lightweight Documentation stehen die parallel

erzeugten leichtgewichtigen Dokumente, daher wird dieses Muster zu der

Mustergruppe Mainly Writing zugeordnet. Laut der oberen Definition

fließen die Informationsflüsse parallel und in dieselbe Richtung. Aus

diesem Grund erfüllt Lightweight Documentation ebenfalls die

Voraussetzung für Parallele Flüsse.

Auswirkung


Lightweight Documentation ist ein quantitatives Muster. Denn seine

Auswirkung ist wegen der zusätzlich zu den flüssigen Informationen

leichtgewichtig protokolierten Dokumente quantitativ. Bei diesem Muster

wird parallel zu den fließenden flüssigen Informationen eine

Dokumentation geführt, dadurch werden quantitativ mehr Informationen

und Wissen verfestigt und diese können nicht mehr so einfach versickern.


Lightweight Documentation ist ein Muster mit positiver Auswirkung, weil

sie unter Umständen flüssige Informationsflüsse zumindest zum Teil

verfestigen kann. Daher wird dieses Muster als Mittel für einfach

Dokumentation ohne viel Aufwand in Softwareprojekten eingesetzt.

Insbesondere in Projekten mit agilen und erfahrungsbasierten Ansätzen,

Akteur1

Anforderung1

Leichtgewichtige Dokumentation

Akteur2

<Anforderung1>

4

{1, 2,…}

P

111

wo es darauf ankommt viel direkt und flüssig miteinander zu

kommunizieren, wird seine positive Auswirkung ausgenutzt. Solche

Projekte können zwar schnelle funktionierende Releases liefern und sind

Änderungsanforderungen gegenüber sehr flexibel, aber viele wertvolle

Informationen und Erfahrungen gehen zu schnell durch flüssige

Kommunikation verloren und die Nachvollziehbarkeit könnte dadurch

gefährdet werden. Um die flüssig geflossenen Informationen dennoch ohne

viel Aufwand zu dokumentieren und zumindest den Kern der Idee oder der

Schwerpunkt des Gespräches zu protokollieren und für spätere Reviews

zumindest ein wenig nachvollziehbar zu machen, werden sehr häufig

Lightweight Documentation eingesetzt.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Bürokratie:

Mit Bürokratie gehört Lightweight Documentation zur selben

Mustergruppe Mainly Writing.

Verwandt mit Wichtiges Dokument (VID):

Eine Lightweight Documentation wird meistens einsetzt, um

aufwandsparend dennoch eine Dokumentation zu erzeugen. Demnach

ist das Dokumentierte sehr wichtig und wird von vielen Akteuren

benötigt. Ein mit Lightweight Documentation erstelltes Dokument ist

häufig ein Wichtiges Dokument (VID), wo jeder darauf Zugriff haben

möchte.

Sehr verwandt mit Dead Document und Write For One: [siehe Dead

Document und Write For One]

Gegensätzlich und disjunkt mit Synergie, Wiederholte Information

und Übersprungenes Dokument:

[siehe Synergie, Wiederholte Information und Übersprungenes

Dokument]

Auftreten Lightweight Documentation kann häufig als Lösungsmuster in

Softwareprojekten eingesetzt werden, wie oben ausführlich beschrieben.

Daher ist dieses Muster besonders in den Softwareprojekten mit agilen und

erfahrungsbasierten Ansätzen ein sehr häufig auftretendes Muster.

„Brainstorming“ mit Flip Chart wäre zum Beispiel auch ein häufig

eingesetztes Mittel, um flüchtige Ideen von Akteuren einzufangen.

112

Beispiele Das Muster Synergie wird mit einer leichtgewichtigen Dokumentation,

speziell mit dem Tool FOCUS ergänzt. FOCUS ist ein FLOW-Tool, auch

wenn es älter ist als FLOW. Damit kann man aus einzelnen Akteuren

schmerzlos bzw. mühelos viel flüssiges Wissen und flüssige Erfahrung

herausziehen und zum Beispiel als Records, Aufnahmen oder Skizzen

verfestigen. In FLOW kann die Synergie mit FOCUS folgendermaßen

aussehen:

FOCUS ist ein Plug-In für Software, womit man bei der Implementierung

mit Mauszeiger auf den Quellcode zeigen kann und dabei Bemerkungen

hinzufügen, die als Ton parallel aufgenommen werden können. Unten ist

ein Bildschirmausschnitt von FOCUS zu sehen.

FOCUS_Daten


SynergieReview Meeting

<FOCUS>

<Eclipse>

Entwickler

{n = 3}

113

5.2.15 Bürokratie

[Quelle: http://www-is.informatik.uni-oldenburg.de/~dibo/teaching/sem/Ausarbeitungen/elfreich/Image2.gif]

Anstatt direkt miteinander zu kommunizieren, schreibt Frau Meyer Herrn Schulz immer nur

schriftliche Dokumente. Es soll laut Vorschrift so gemacht werden.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster


Sequenz, Mainly Writing

zeitliches Muster


Metapher Der Begriff „Bürokratie“ ist sehr eng mit schriftlicher Dokumentation und

Formalitäten verbunden. Der Ursprung des Wortes „Büro“ bezog sich auf

den Stoff zum Beziehen von Schreibtischen. Danach wurde es auf den

Schreibtisch selbst angewendet und letztlich auch auf den Ort übertragen,

wo sich der Schreibtisch befindet. Im eigentlichen Sinne ist „Bürokratie“

die Wahrnehmung von Verwaltungstätigkeiten im Rahmen festgelegter

Kompetenzen. Eine Übersteigerung der Bürokratie ist eine bürokratisch

überzogene Handlungsorientierung und wird als „Bürokratismus“

bezeichnet, welche die Vorschrift über den Menschen stellt und ihn

weitgehend als Objekt behandelt

Beschreibung Eine Bürokratie in FLOW bezeichnet ein Muster, wo mehr als drei Akteure

in einer Kette schriftliche Dokumente als Austauschform für Information

gewählt haben. Die nacheinander folgenden Akteure bilden eine

Informationskette wie bei Stille Post oder Hierarchie. Der Unterschied

besteht darin, dass Bürokratie ausschließlich Dokumente zwischen je zwei

Akteuren austauschen und es können mehrere Dokumente zwischen zwei

Akteure liegen. Dieser dokumentenlastige Informationsfluss ist meistens

vorschriftenmäßig festgelegt, d.h. laut Regelung und Prozesskonzept

sollen bestimmte Dokumente von den Akteuren erzeugt werden um

angeblich die spätere Nachvollziehbarkeit und effizientere Reviews zu

garantieren. Dieses Muster tritt häufig in konventionellen

Softwareprojekten auf.

+

3

K

114

Charakteristik

Struktur Mehr als drei Akteure beteiligen an dieser Informationsabfolge

Zwischen jeden zwei Akteuren werden viele Dokumenten erzeugt,

die laut Vorschriften und Prozessen erstellt werden müssen.

Es fließen keine direkte flüssige Informationen zwischen den

beteiligten Akteuren

D.h. zwischen den benachbarten Akteuren liegen evtl. mehrere

Dokumente, welche von den Startakteuren erstellt und von den

anderen Zielakteuren gelesen werden.

Definition:

Variante 1:

Bürokratie wird in der Strukturfacette zu den dominanten Mustern

zugeteilt. Ihre Charakteristik ist durch ihre strukturellen Vorgaben definiert

und kann eben so in einem FLOW-Modell identifiziert werden.


In der Komplexitätsfacette wird Bürokratie, nicht wie Stille Post oder

Hierarchie zu den linearen Mustern eingeordnet. Denn Bürokratie

strukturiert zwar ebenfalls eine Abfolge von Informationsflüsse, aber

der Unterschied liegt bei den zwischen zwei Akteuren fließenden

Informationen und Anzahl der Dokumente. Deswegen wird Bürokratie den

mehrdimensionalen Mustern zugeordnet.

Mustergruppe Sequenz, Mainly Writing

Im Muster Bürokratie werden sehr viele Dokumente zwischen den zweier

Akteuren erzeugt, daher wird es zur Mustergruppe Mainly Writing

zugeordnet. Dieses Muster gehört ebenfalls zur Mustergruppe Sequenz, da

aus der Sicht des Wissensflusses die geflossenen Informationen sequentiell

nacheinander folgen und somit eine Abfolge oder Kette von

Akteur1 AkteurN

{n ≥ 2}

DokuN

{n ≥ 1}

Doku1

Akteur1 Akteur2 Akteur3Doku2

Doku3

Doku4

3

+

115

Informationsfluss bilden.

Auswirkung


Bürokratie verursacht zeitliche Auswirkung auf das Projekt. Durch die

vielen nach konventionellen Konzepten erzeugten Dokumenten werden

viel Zeit und Aufwand investiert. Im schlimmsten Fall, als der

Worst-Case kann die obere dargestellte Variante 1 zu einer sehr langen

tOutput kommen, wie in der Abbildung.


Bürokratie gehört zu den kontextabhängigen Mustern. Seine Auswirkung

ist nicht eindeutig bestimmt. Wie oben bereits erwähnt, taucht so ein

Muster häufig in den klassischen Softwareprojekten mit konventionellen

Ansätzen auf.

Positive Auswirkung: Wenn also der dokumentenlastige

Informationsaustausch vorschriftenmäßig erzwungen ist, dann ist eine

Bürokratie an vielen Stellen wahrscheinlich unvermeidbar.

Manchmal kann sogar positive Auswirkung erzielt werden, wenn

Zeit t

Akteur1 Akteur2

Doku1

Akteur3

tOutput

Doku2

Doku3

Doku4

K

116

einen dokumentenlastigen Prozessmodell genauestens verfolgt

werden. Zumindest werden Dokumente für die Nachvollziehbarkeit

zur Verfügung gestellt.

Negative Auswirkung: Negativ wird es dann, wenn diese

Dokumentenlastigkeit zu Ineffizienz der Informationsübertragung

führt. Leider ist es für dieses Muster sehr häufig der Fall.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Stille Post, Write For One und Lightweight

Documentation:

Mit diesen Mustern gehört Bürokratie zur selben Mustergruppe.

Sehr verwandt mit Hierarchie: [siehe Hierarchie]

Gegensätzlich und disjunkt mit Interaktion , Synergie und

Übersprungenes Dokument: [siehe Interaktion, Synergie und


Auftreten Eine Bürokratie verfolgt meistens eine streng zu befolgende Vorschrift

oder Sollkonzept, daher tritt dieses Muster häufig in Softwareprojekten mit

konventionellen Prozessmodellen auf.

Beispiele Im Folgenden wird ein fiktives Beispielprojekt, angelehnt an den Bei-

spielen aus [VModellXT], vorgestellt, dass die bürokratische Projektsitua-

tion in einem Softwareprojekt wiederspiegelt:

Durchführender des Softwareprojekt SoftRevolution ist ein Projektteam

117

aus SoftNews, bestehend aus Softwareentwickler. Am Anfang steht die

Idee für das Projekt fest. Sie wird zu einem Projektvorschlag ausgearbei-

tet. Da in dem Projekt alle Umstände stimmen, ist davon auszugehen, dass

die erste Projektfortschrittsentscheidung positiv ausfällt und der Ent-

scheidungspunkt Projekt genehmigt passiert wird. Im folgenden Projekt-

abschnitt, der zum Entscheidungspunkt Projekt definiert führt, wird die

Planung und Organisation des Projektes detailliert festgelegt. Die Doku-

menten Projekthandbuch, QS-Handbuch, Produktbibliothek, Projektsta-

tusbericht, QS-Bericht und Projektplan liegen bei der abschließend fest-

zuhaltenden Projektfortschritts- entscheidung vor. Für den Entschei-

dungspunkt Anforderungen festgelegt legt das Projektteam der SoftNews

das Dokument Anforderungen (Lastenheft) vor. Die Anforderungen sind

die Basis des neu zu erstellenden Systems. In diesem Projektabschnitt

erstellt das Projektteam mehrfach die Produktexemplare Anforderungs-

bewertung, deren Ergebnisse jeweils in das Anforderungsdokument ein-

fließen. Desweiteren muss hierbei das Ausschreibungskonzept festgelegt

werden. Die Anforderungen (Lastenheft) werden Teil der Ausschreibung,

die im folgenden Projektabschnitt vervollständigt werden kann. Ferner

erstellt das Projektteam den Kriterienkatalog für die Angebotsbewertung.

Die Ausschreibung wird veröffentlicht und der Entscheidungspunkt Pro-

jekt ausgeschrieben kann passiert werden.

Dieser ganze Vorgang ist noch nicht mal der vollständige Projektstufe I.

Unzählige Dokumente wurden während dieses Vorgehens erzeugt. Dies ist

ein typisches Beispiel für Bürokratie, wo die beteiligten Akteure mehr

Wert auf die Dokumentation legen anstatt auf eine direkte effizientere

Interaktion und Kommunikation.

118

5.2.16 Alleinkämpfer

[Quelle: http://www.effektives-praxismanagement.de/]

Dr. Zahn ist völlig mit seinen Aufgaben überfordert. Er ist ein Alleinkämpfer und muss viele

Tätigkeiten erledigen.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster


Hub



Metapher Nach der altnordischen Mythologie werden mit dem Begriff

„Alleinkämpfer“ die im Kampf gefallenen Helden bezeichnet. Ein

„Alleinkämpfer“ ist jemand, der auf stets auf sein eigenes Willen steht und

viele, meistens wichtige Aufgaben und Verantwortungen übernimmt und

alleine ausführt bzw. erledigt. Mit dem Begriff „Alleinkämpfer“ werden

unteranderem Einsatz- und Aufopferungsbereitschaft für ideale Ziele und

Mitmenschen impliziert.

Beschreibung In FLOW ist ein Alleinkämpfer ein Akteur oder eine Person, die viele und

komplexe Aufgaben und Tätigkeiten alleine ausführt. Er kommuniziert

viel, verfasst viele Dokumente und liest evtl. viele andere Dokumente. Das

heißt es fließen viele fest und flüssige Informationsflüsse zu ihm hinein und

auch viele Flüsse entspringen aus ihm heraus. Meistens trägt ein

Alleinkämpfer in Softwareprojekten sehr viel Verantwortung. Aber da er

für viele Aufgaben zuständig ist, ist er meistens mit seinen Tätigkeiten

überfordert.

Charakteristik

Struktur Es existiert ein Akteur.

Mindestens vier unterschiedliche Informationsflüsse fließen zu diesem

Akteur hinein oder aus ihm heraus.

Um diesen Akteur fließenden Informationsflüssen müssen aus einer

Kombination von fest und flüssig sein. D.h. es existiert mindestens ein

fest und ein flüssiger Informationsfluss.

Die beteiligten Informationsflüssen müssen aus einer Kombination

{1, 2,…}

+

3

K

+

119

von hineinfließenden und herausfließenden Informationsflüssen

bestehen. D. h. es existiert mindestens ein hineinfließenden und ein

herausfließenden Informationsfluss.

Definition:

Variante 1:

Alleinkämpfer wird in der Strukturfacette zu den dominanten Mustern

zugeordnet. Seine Charakteristik ist eindeutig durch die strukturellen

Vorgaben definiert und sehr leicht in einem FLOW-Modell identifiziert

werden.

Komplexität mehrdimensionales Muster

Alleinkämpfer gehört in der Komplexitätsfacette wegen seiner vielen

Informationsflüssen und der komplexen Definition eindeutig zu den

mehrdimensionalen Mustern.

Mustergruppe Hub

Alleinkämpfer ist ein Submuster von Hub. Aufgrund seiner Struktur erfüllt

es die Voraussetzung für Hub, da er viele um den agierenden Akteur herum

fließende Informationsflüsse besitzt, die ein Haufen bildet.

Auswirkung


Alleinkämpfer ist ein quantitatives Muster. Aufgrund seiner vielen

beteiligten Informationsflüssen um den agierenden Akteur herum, ist sein

Wissensänderung ∆K immer sehr groß. Dies führt dazu, dass sein

Wissenstand K, auf eine längere Zeit betrachtet, zunimmt. Aus der

Projektsicht betrachtet ist dies wieder ein positiver quantitativer Effekt,

wenn Beteiligten Wissen verarbeiten und dabei kreativ entwickeln.

Alleinkämpfer

{n ≥ 3}

AktivitätN

{n ≥ 1}

AktivitätM

Workshop moderieren

Doku1 Akteur1

Doku2Alleinkämpfer Akteur2

Akteur3

3

120


Seine Auswirkung in Bezug auf die Qualität ist nicht eindeutig

identifizierbar.

Positive Auswirkung: In vielen besonders kleinen Softwareprojekten

aus relativ kleine Softwareunternehmen brauchen manchmal

Alleinkämpfer, die ohne nach bestimmten Prozessmodellen

vorzugehen, alleine komplexe Aufgaben oder sogar viel

Verantwortung übernehmen kann. Meistens ist so eine Person sehr

belastbar und der ganze Erfolg des Projektes basiert auf Heldentum

solcher Alleinkämpfer. Bei mangelndem Personalien wirkt ein

Alleinkämpfer sich sicherlich positiv auf das Projekt aus.

Negative Auswirkung: Durch seine viele ausgeführten Aufgaben kann

ein Alleinkämpfer durchaus sehr überfordert werden, wie in der

unteren FLOW-Darstellung gezeigt. Damit ist er zu sehr belastet, so

dass er seine Aufgaben und Tätigkeiten nicht mehr in

qualitätsgesichert ausführen kann. In solchen Fällen wirkt sich das

Muster negativ auf das Projekt aus.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Wichtiges Dokument (VID):

Mit diesem Muster gehört Alleinkämpfer zur selben Mustergruppe

Hub.

Verwandt mit Person als Senke: [siehe Person als Senke]

Sehr verwandt mit Experienced Expert:

Ein Alleinkämpfer trägt oft große Verantwortung und übernimmt sehr

Doku1 Akteur1

Doku2

Doku3

Alleinkämpfer Akteur2

Akteur3

K

121

viele Aufgaben. Solch eine Person spielt eine entscheidende Rolle in

der Softwareentwicklung. Fast in der gleichen Situation befindet sich

ein Experienced Expert. Er trägt sehr viele Erfahrungen zu einem

Projekt bei und ist oft fachlich ein Spezialist. Daher kann ein

Experienced Expert oft ein Alleinkämpfer sein. Somit sind diese

beiden Muster sehr verwandt.

Gegensätzlich und disjunkt mit Solitär: [siehe Solitär]

Auftreten Alleinkämpfer tritt selten in einem streng nach Vorgehensmodellen

basierten Softwareprojekt auf, da in solchen Projekten die

Arbeitsaufteilung meistens nach den Prozessen geregelt ist. In relativ

kleine Softwareprojekte oder in kleinen Unternehmen mit wenig

Entwickler sieht die Situation schon anders aus. Da könnte Alleinkämpfer

schon häufiger auftreten, allein aufgrund des Personalmangelns.

Beispiele In dem Softwareunternehmen SoftNews soll ein externer beratender



den Teammitgliedern die Zusammenarbeit erleichtern. [siehe hierzu

Solitär]

[Fortsetzung aus dem Beispiel von Person als Senke] Der Geschäftsführer

des Unternehmens hatte bereits mit dem externen Berater gesprochen.

Denn er konnte keine Verbesserung in der Kooperation und Teamarbeit

merken. Dem Berater droht das Abbrechen der Einstellung. Er führt

daraufhin Einzelgespräche mit den Beteiligten und vermittelt seine eigenen

Erfahrungen an den Mitarbeitern.

Dadurch, dass der Berater viele Tätigkeiten aufgrund des Zeitdrucks

alleine ausführen muss, ist er ein Alleinkämpfer geworden. Unter diesen

Umständen müsste man die Qualität seiner Arbeit durch andere Methoden

überprüfen.

Extern.Berater

Analytiker

Entwickler

ArchitektErfahrungsbericht

Entwickler

122

5.2.17 Wichtiges Dokument (VID)

[Quelle: http://www.provincia.bz.it/pariservertrag/images/pariserVertragstext.jpg]

Ein Vertrag ist ein sehr wichtiges Dokument, das sich jeder durchlesen sollte.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster


Hub


positives Muster

Metapher Die Abkürzung „VID“ steht für „Very Important Document“ und leitet sein

Metapher von „VIP“ ab. „VIP“ steht für „Very Important Person“ und wie

der Name schon ausdrückt, ist diese Person in gewisser Hinsicht sehr

wichtig, und meistens auch mächtig, bekannt und prominent. Mit diesem

Begriff wird häufig für die prominenten Persönlichkeiten auf

Veranstaltung verwendet, impliziert damit die individuelle Bekanntheit

dieser Person in der Öffentlichkeit.

Beschreibung Als Wichtiges Dokument (VID) bezeichnet man in FLOW ein Dokument,

das von vielen Akteuren oder Aktivitäten gelesen bzw. gebraucht wird.

Dieses Dokument ist also in gewisser Hinsicht sehr wichtig, und wegen

seines Nutzens für andere Akteure und Aktivitäten hat sich der Aufwand

für sein Erzeugen richtig gelohnt. Es ist stets ein positives Muster, denn bei

Identifizierung von Wichtiges Dokument (VID) kann ausgesagt werden,

dass das Schriftstück eine gute Dokumentation für die Nachvollziehbarkeit

ist.

Charakteristik

Struktur Es existiert ein Dokument

Um dieses Dokument herum fließen mindestens drei feste

Informationsflüsse von ihm heraus.

Das heißt dieses Dokument wird von mehr als drei unterschiedliche

Aktivitäten gebraucht

{1, 2,…}

+

3

P

+

123

Definition:

Variante 1:

Wichtiges Dokument (VID) ist eindeutig ein dominantes Muster. Durch

seine starke charakteristische Eigenschaft fällt ein Wichtiges Dokument

(VID) in einem FLOW-Modell sehr auf und dieses Muster ist

ausschließlich durch seine Struktur geprägt.


Wichtiges Dokument (VID) gehört sowie das Muster Dead Document zu

den mehrdimensionalen Mustern. Die Voraussetzung für dieses Muster ist

ebenfalls sehr einfach gehalten, aber die es können durchaus sehr viele

Informationsflüsse an diesem Muster teilnehmen.

Mustergruppe Hub

Wichtiges Dokument (VID) gehört zur Mustergruppe Hub. Es ist ziemlich

eindeutig, dass Wichtiges Dokument (VID) die Voraussetzung von Hub

erfüllt. Das agierende Dokument besitzt viele von sich heraus fließende

Informationen, so dass diese zusammen ein Hub bildet.

Auswirkung


Wichtiges Dokument (VID) ist ein Muster mit quantitativer Auswirkung.

Mit der Identifizierung des Musters wird ein Dokument erkannt, das von

vielen Akteuren gebraucht wird. Somit fließen sehr viele Informationen

aus ihm heraus. Die in diesem Dokument enthaltenen Informationsmenge

(quasi der Wissensstand K von diesem Dokument) ist somit sehr wichtig

und muss genau nachgeprüft werden.


Die Auswirkung des Wichtigen Dokuments (VID) ist eindeutig positiv.

Durch gezieltes Suchen in einem FLOW-Modell kann man über die

Nutzbarkeit der Dokumente ausgesagt werden. Wenn so ein Muster in der

FLOW-Darstellung auftritt, dann ist das agierende Dokument ein sehr

wichtiges und häufig gebrauchtes Dokument. Damit hat sich der Aufwand

WichtigDokument

{n ≥ 3}

AktivitätN

Akteur1

WichtigDokument

Reviewdurchführen

Akteur2

3

{1, 2,…}

P

124

für das Erstellen gelohnt und in diesem Dokument stehen sicherlich

ziemlich wichtige Informationen oder Anforderungen. Nach der

Identifizierung des Wichtiges Dokument (VID) muss man mit der

Wichtigkeit dieses Dokumentes rechnen. Das heißt falls die darin

verfestigten Informationen fehlerhaft oder zu sehr abweichend sind, kann

dies schwere Folgen haben.

Genau wie sein gegenteiliges Muster Dead Document kann dieses Muster

auch als strukturelles Prüfmuster in einem FLOW-Modell genutzt werden,

allerdings in positiver Hinsicht.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Wenig verwandt mit Alleinkämpfer und Experienced Expert:

Mit diesen Mustern wird Wichtiges Dokument (VID) zur selben

Mustergruppe Hub zugeordnet.

Verwandt mit Lightweight Documentation: [siehe Lightweight

Documentation]

Gegensätzlich und disjunkt mit Dead Document und Übersprungenes

Dokument: [siehe Dead Document und Übersprungenes Dokument]

Auftreten Wichtiges Dokument (VID) ist ein häufig auftauchendes Muster in

unterschiedlichen Softwareprojekten. Immer wenn ein Dokument von

mehr als drei verschiedenen Akteuren oder Aktivitäten gebraucht werden,

ist er laut Definition ein Wichtiges Dokument (VID). Theoretisch sollten

viele erstellte Dokumente in einem Softwareprojekt diesen Zweck erfüllen.

Immer wenn dieses Muster entdeckt wird, ist es stets positiv, wie oben in

dem Aspekt Qualität beschrieben.

Beispiele In der Masterarbeit von Stapel [Stapel 2006] wird eine Projektsituation

eines Großunternehmens geschildert, wo ein Dokument nach dem Doku-

mentenmodell des Unternehmens erstellt werden müsste. [Siehe Dead

Document]

125

[Fortsetzung aus dem Beispiel von Dead Document] Aus dem Aktivitäts-

diagramm kann leicht ein Wichtiges Dokument (VID) entstehen, wenn das

Diagramm doch von einem drei köpfigen Programmierteam benötigt wird.

Es wurde festgestellt, dass diese Situation aus Vergessenheit nicht model-

liert wurde.

Entwickler

Aktivitätsdiagramm

DynamischeSicht

modellieren

Programmierteam

{n = 3}

126

5.2.18 Experienced Expert

[Quelle: http://www.saint-gobain.de/wir_ueber_uns/prinzipien/grafik/respect_500.jpg]

Der erfahrene Experte erklärt dem Projektteam, an welchen Stellen es beim letzten Projekt

gescheiterte.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster


Hub


positives Muster

Metapher Ein „Experte“ bezeichnet unscharf eine Person, die über umfangreiches

Wissen auf einem oder mehreren bestimmten Fachgebieten oder über

spezielle Fähigkeiten verfügt, wie beispielsweise ein Wissenschaftler.

Auch ein Wissensvorsprung gegenüber dem Durchschnitt kann einen

„Experte“ definieren. Neben dem theoretischen Wissen ist auch eine

kompetente Anwendung, also praktisches Handlungswissen,

kennzeichnend. Seine Wissenstiefe unterscheidet ihn vom Generalisten,

der sich in vielen Fachbereichen auskennt. Ein erfahrener Experte besitzt

zu seinem umfangreichen Fachwissen auch noch reichlich Erfahrung in der

praxisbezogenen Anwendung.

Beschreibung Experienced Expert in FLOW ist ebenfalls eine Person, die viele

Erfahrungen in einem bestimmten Themengebiet besitzt. Aus ihm

entspringen viele Erfahrungsflüsse, so dass dadurch seine in das Projekt

transportiertes Fachwissen und seine Erfahrungen eingebracht werden

können. Wenn solch eine Person in einem Projekt zur Seite steht und sein

Wissen und seine Erfahrung an andere Akteure weitergibt, dann wird diese

Person in FLOW als ein Experienced Expert modelliert. Durch seine

Anwesenheit werden viele Erfahrungen ausgetauscht, daher ist ein

Experienced Expert stets positiv.

{1, 2,…}

+

3

P

http://www.saint-gobain.de/wir_ueber_uns/prinzipien/grafik/respect_500.jpg

127

Charakteristik

Struktur Es existiert einen Akteur

Um diesen Akteur herum fließen mehr als drei Erfahrungsflüsse von

ihm heraus, entweder zu anderen Aktivitäten oder als Steuerungsfluss

in anderen Blackboxen.

Definition:

Variante 1:

Die Charakteristik des Experienced Expert ist einzigartig durch seine

Struktur geprägt. Häufig ist auch der Fall, dass so ein erfahrener Experte in

einem Projekt noch weitere Aufgaben und wichtige Verantwortung

übernimmt. D. h. um ihn herum fließen höchstwahrscheinlich nicht nur

Erfahrungsflüsse, sondern auch noch andere allgemeine

Informationsflüsse. Daher ist er ein auffallendes dominantes Muster.


Experienced Expert stellt ein Muster dar, dessen strukturelle Definition

anzahlsmäßig nicht eingeschränkt ist. Es könnte durchaus aus vielen

Erfahrungsflüssen bestehen. Daher ist Experienced Expert als ein

mehrdimensionales Muster klassifiziert.

Mustergruppe Hub

Dieses Muster erfüllt eindeutig die strukturelle Bedingung für Hub. Aus

einem Experienced Expert können viele Erfahrungsflüsse heraus fließen,

was das Muster zu einem Submuster von Hub macht.

Auswirkung


Die Begründung für die Quantität von Experienced Expert ist ähnlich wie

beim Muster Alleinkämpfer. Der Unterschied dabei ist, dass der erfahrene

Experte kein neues Wissen dazugewinnt, sondern seinen vorhandenen

Erfahrungen weitergibt.

Erf.ExperteBlackboxM

{n ≥ 3}

AktivitätN

<Steuerungsfluss>

Erf.Experte

Akteur2

Akteur1 Aktivität1

Blackbox1

<Steuerung>

3

{1, 2,…}

+

128

Der Wissens- und Erfahrungsstand von dem Experienced Expert ist KExperte.

Daher werden T1 ≤ KExperte, T2 ≤ KExperte und TAktivität ≤ KExperte an alle Akteure

oder Aktivitäten übertragen. Im besten Falle, also Best-Case, ist T = KExperte.


Experienced Expert ist ein Muster mit positiver Auswirkung. Denn wenn

dieses Muster durch seine Charakteristik identifiziert wurde, dann bedeutet

dies, dass Erfahrungsflüsse auf jeden Fall modelliert und sicherlich schon

irgendwie ausgetauscht wurden. Durch ein Experienced Expert kann das

Projekt nur positiv von den geflossenen Erfahrungen und Wissen

profitieren.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Do

kum

ent

VID

Wenig verwandt mit Wichtiges Dokument (VID):

Mit diesem Muster gehört Experienced Expert zur selben

Mustergruppe Hub.

Sehr verwandt mit Alleinkämpfer: [siehe Alleinkämpfer]

Gegensätzlich und disjunkt mit Missing Experience: [siehe Missing

Experience]

Auftreten Leider taucht ein Experienced Expert relativ selten in FLOW-Modellen

auf. Entweder wurden Erfahrungsflüssen ganz vergessen, oder man

verzichtet aus bestimmten Gründen, z. B. aus Zeitgründen, überhaupt auf

die Modellierung von Erfahrungen. Daher kann man behaupten, wenn

dieses Muster in einem FLOW-Modell identifiziert wurde, dann wirkt es

sich stets positiv auf das Projekt aus.

Beispiele In dem Softwareunternehmen SoftNews wurde ein neues Softwareprojekt

initiiert und mit Absicht von Anfang an ein Experienced Expert in das

Projekt mit eingebaut. Das FLOW-Modell zu Experienced Expert ist im

Folgenden dargestellt:

Erf.Experte

Akteur2

Akteur1 Aktivität1TAktivität

KExperte

P

129

Exp. Expert

Analytiker

Entwickler Experience Base schreiben

SynergieReview Meeting

<moderieren>

ExperienceBaseDokumentation

130

5.2.19 Kunde zu Analytiker

[Quelle: http://www.socioweb.de/seminar/interaktion/vertiefen/zuhoeren/sagen.gif]

Der Kunde Herr Clever stellt seine Anforderungen zu seinem gewünschten Software. Jan als

Softwareanalytiker versucht ihn zu folgen und analysiert nebenbei schon mal ein paar Daten.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster

unitäres Muster

Rollenbasiertes Muster, Zyklus

zeitliches Muster

positives Muster

Metapher Ein „Kunde“ ist eine Person, die Interesse an den Produkten und

Dienstleistungen eines Unternehmens oder an deren potenzieller Nutzung

hat, sowohl in Bezug auf Erwerb wie auch auf deren Vermarktung. Daher

darf die Kommunikation zwischen dem Entscheidungsträger Kunde und

dem Softwareanalytiker nicht fehlen.

Beschreibung In Muster Kunde zu Analytiker muss der Kunde direkt mit dem

Softwareanalytiker kommunizieren. Das heißt, es müssen flüssige

Informationen zwischen einem Akteur mit der Rolle Kunde und einem

anderen Akteur mit der Rolle Softwareanalytiker fließen. Dabei hat das

Muster noch mehr positive Auswirkung, wenn der Informationsfluss auch

noch dokumentiert ist, aber dies ist nicht zwingend erforderlich für das

Identifizieren des Musters. Für das Identifizieren des Musters ist die

zeitliche Abfolge der beiden charakteristischen Informationsflüsse

relevant: zuerst stellt der Kunde seine Anforderung und danach erhält er

von dem Softwarenanalytiker Feedbacks zurück.

Charakteristik

Struktur Es existiert ein Akteur mit der Rolle Kunde und ein Akteur mit der

Rolle Softwareanalytiker.

Diese beiden Akteure kommunizieren interaktiv miteinander

Zwischen dem Kunden und dem Softwarenanalytiker fließen in beider

Richtung direkte flüssiger Informationen.

Definition:

+

1

P

+

131

Es ist klar, dass dieses Muster durch seine strukturell einfache Eigenschaft

sofort identifiziert werden können. Seine Charakteristik ist durch diese

Struktur definiert. Deswegen gehört er zu den dominanten Mustern, wie

Analytiker zu Architekt und Architekt zu Entwickler.


Kunde zu Analytiker stellt ein sehr einfaches Muster dar und gehört deshalb

zu den unitären Mustern. Die strukturelle Definition ist sehr einfach

gehalten. Im Prinzip besteht es nur aus zwei Akteuren und drei

Informationsflüssen mit einem Dokument.

Mustergruppe Rollenbasiertes Muster, Zyklus

Kunde zu Analytiker ist definitiv ein rollenbasiertes Muster. Seine

Charakteristik ist durch die rollenbedingte Voraussetzung geprägt. Und

dieses Muster gehört zur Mustergruppe Zyklus, da es als eine rollenbasierte

Version von Interaktion angesehen wird und diese zur Mustergruppe

Zyklus gehört.

Auswirkung


Zugeordnet wird Kunde zu Analytiker zu den zeitlichen Mustern. Durch die

direkte Kommunikation zwischen dem Kunde und dem Analytiker wurde

viel Zeit gespart und unnötige Missverständnisse vermieden. Diese Form

von Informationstausch ist die schnellste und direkteste

Austauschmöglichkeit. Außerdem ist die zeitliche Abfolge der beiden

vorausgesetzten Informationsflüsse wichtig. Auf die Zeitachse abgerollt

sieht die Modellierung wie folgt aus:


Dieses Muster ist ein fundamentales Muster in FLOW. Genauso wie die

einfachen Muster Solitär etc. könnte und sollte dieses Muster als ein

Prüfmuster genutzt werden. Immer wenn in einem FLOW-Modell dieses

SoftwareanalytikerKunde

Zeit t

Kunde Softwarenanalytiker

1

P

132

Muster identifiziert wird, kann man daraus eine positive Auswirkung

erschließen, dass der Kunde zumindest seine Anforderungen an dem

Analytiker stellt und der Analytiker sich mit ihm intensiv beschäftigt.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Hierarchie:

Mit diesen Mustern gehört Kunde zu Analytiker zur selben

Mustergruppe Rollenbasiertes Muster.

Sehr verwandt mit Interaktion, Validierung, Analytiker zu Architekt

und Architekt zu Entwickler [siehe Interaktion]:

Das Muster Kunde zu Analytiker kann als eine vereinfachte Version

von Validierung angesehen werden. Beide Muster besitzen eine

Rollenzuweisung Kunde, dieser dann in irgendeiner Weise um

Verifikation von Anforderung gebeten wird.

Kunde zu Analytiker ist mit Analytiker zu Architekt und Architekt zu

Entwickler sehr verwandt. Sie gehören alle drei zu denselben zwei

Mustergruppen und sind sich in dem strukturellen Aufbau sehr

ähnlich. Diese drei Muster werden immer in Zusammenhang gebracht

und auch stets zusammen als Prüfmuster in einem FLOW-Modell

verwendet. Sie sind schon fast unzertrennlich und können als

gegenseitige Ergänzungen angesehen werden.

Gegensätzlich und disjunkt mit Permuted Order: [siehe Permuted

Order]

Auftreten Da Kunde zu Analytiker ein fundamentales positives Muster ist, sollte es

häufig in FLOW-Modellen vorgefunden werden können. Denn wenn der

Kunde nicht direkt mit dem Softwareanalytiker interagiert, ist es sicherlich

schlecht für das Softwareprojekt. Solch ein Muster muss als eine

Selbstverständlichkeit angesehen werden.

Beispiele Kunde zu Analytiker besitzt schon eine genaue Rollenzuweisung. Als

Muster kann es schon eine ziemlich realistische Projektsituation

repräsentieren. Ein fiktives Beispiel wie folgt:

133

Dabei hat das Muster noch mehr positive Auswirkung, wenn der Kunde

zusätzlich nochmal die analysierten Daten zur Verifikation bekommen

könnte, wäre diese Situation noch positiver.

SoftwareanalytikerKunde

AnalysierteDaten

134

5.2.20 Analytiker zu Architekt

Der Softwarearchitekt Robert denkt an die Daten vom Softwareanalytiker Herr Schulz und

versucht einen skizzierten Entwurf zu zeichnen.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster

unitäres Muster


zeitliches Muster

positives Muster

Metapher Ein Softwareanalytiker ist eine Person, die für die Anforderungsanalyse in

einem Softwareprojekt zuständig ist. Er übernimmt die Aufgabe in der

Software- und Systementwicklung den Analyseteil der

Anforderungserhebung. Dabei wird festgestellt, ob Anforderungen unklar,

nicht vollständig, widersprechend sind. Wenn ja, werden die Unklarheiten

weiter mit dem Kunden ausdiskutiert. Und wenn nein, dann muss er mit

dem Softwarearchitekt kommunizieren um die gewünschten

Anforderungen umzusetzen.

Beschreibung Dieses Muster ist wieder ein fundamentales Prüfmuster in FLOW. In

Muster Analytiker zu Architekt muss der Softwareanalytiker direkt mit dem

Softwarearchitekt kommunizieren. Das heißt, es müssen flüssige

Informationen zwischen einem Akteur mit der Rolle Softwareanalytiker

und einem anderen Akteur mit der Rolle Softwarearchitekt fließen. Für

das Identifizieren des Musters ist die zeitliche Abfolge der

charakteristische Informationsflüsse relevant: zuerst kommuniziert der

Softwareanalytiker direkt mit dem Softwarenanalytiker, danach erhält er

von dem Softwarearchitekt ein Feedback.

Charakteristik

Struktur Es existiert ein Akteur mit der Rolle Softwareanalytiker und ein

Akteur mit der Rolle Softwarearchitekt.


Zwischen dem Softwarenanalytiker und dem Softwarearchitekt

fließen in beider Richtung direkte flüssiger Informationen.

+

1

P

+

135

Definition:

Analytiker zu Architekt ist eindeutig ein dominantes Muster. [Vergleiche

hierzu Kunde zu Analytiker]


Analytiker zu Architekt stellt wieder ein sehr einfaches Muster dar. Die

strukturelle Definition ist sehr einfach gehalten, da es nur auch zwei

Akteure und zwei Informationsflüssen besteht, wie Kunde zu Analytiker.


Wie das Muster Kunde zu Analytiker ist Analytiker zu Architekt auch ein

rollenbasiertes Muster. Und dieses Muster gehört ebenfalls zur

Mustergruppe Zyklus, da es als eine rollenbasierte Version von Interaktion

angesehen wird.

Auswirkung


Zugeordnet wird Analytiker zu Architekt zu den zeitlichen Mustern.

[Vergleiche hierzu Kunde zu Analytiker] Die zeitliche Abfolge der beiden

strukturell definierten Informationsflüsse ist wie folgt:


Dieses Muster ist ebenfalls ein fundamentales Muster in FLOW. Genauso

wie Kunde zu Analytiker sollte dieses Muster als ein Prüfmuster genutzt

werden. Immer wenn in einem FLOW-Modell dieses Muster identifiziert

wird, wirkt es sich stets positiv auf das Softwareprojekt aus. Wenn aber

dieses Muster nicht erkannt wurde, und die vorausgesetzten Rollen aber

vorhanden sind, dann ist es ein Warnzeichen für schlechte Kommunikation

und dieses Problem muss behoben werden.

Softwareanalytiker Softwarearchitekt

Zeit t

SoftwarenarchitektSoftwarenanalytiker

1

P

136

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

alyt

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Hierarchie und Validierung:

Mit diesen Mustern gehört Analytiker zu Architekt zur selben


Sehr verwandt mit Interaktion, Kunde zu Analytiker und Architekt zu

Entwickler: [siehe Interaktion, Kunde zu Analytiker]


Order]

Auftreten Wie das Muster Kunde zu Analytiker ist Analytiker zu Architekt ein

fundamentales positives Muster ist, daher sollte und muss es in

Softwareprojekten identifiziert werden können, vorausgesetzt die

entsprechenden Rollen wurden in FLOW modelliert.

Beispiele [Siehe Beispiele in Kunde zu Analytiker] Alle drei Muster repräsentiert

schon sehr genau ein bestimmtes Unternehmensszenario und enthält eine

genaue Rollenzuweisung. Für Analytiker zu Architekt würde in der

folgende Situation noch mehr positive Auswirkung erzielen: zuerst

kommuniziert der Softwareanalytiker direkt mit dem Softwarenanalytiker,

stellt seine analysierten Daten zur Verfügung und danach erhält er von dem

Softwarearchitekt die skizzierte Softwarearchitektur in Form eines

Dokumentes zur Verifikation zurück.


SoftwareArchitektur

AnalysierteDaten

137

5.2.21 Architekt zu Entwickler

[Quelle: http://www.mis.coventry.ac.uk/~lisa/rept_wrt/img1.gif]

Der Softwarearchitekt Timmy stellt dem erfahrenen Softwareentwickler Paul sein neues Konzept

für die Software vor.


Komplexität:

Mustergruppe:

Form:

Qualität:

dominantes Muster

unitäres Muster


zeitliches Muster

positives Muster

Metapher Bestimmte Kommunikationen zwischen bestimmte Rollen der Akteure

dürfen einfach nicht fehlen. Ein Softwarearchitekt konzipiert die

strukturierte oder hierarchische Anordnung der Systemkomponenten sowie

Beschreibung ihrer Beziehungen. Der Informationsaustausch zwischen

einem Softwarearchitekt und einem Softwareentwickler ist dermaßen

wichtig, dass ohne diese Kommunikation das Projekt garantiert scheitert

oder zumindest an Qualität verliert.

Beschreibung Architekt zu Entwickler ist ebenfalls ein fundamentales Prüfmuster in

FLOW und ist sehr ähnlich mit den Mustern Kunde zu Analytiker und

Analytiker zu Architekt. Flüssige direkte Informationen fließen zwischen

einem Akteur mit Rolle Softwarearchitekt und einem Akteur mit Rolle

Softwareentwickler.

Charakteristik

Struktur Es existiert ein Akteur mit der Rolle Softwareanalytiker und ein

Akteur mit der Rolle Softwarearchitekt.


Zwischen dem Softwarenanalytiker und dem Softwarearchitekt

fließen in beider Richtung direkte flüssiger Informationen.

Definition:


+

1

P

+

138

Architekt zu Entwickler ist ein dominantes Muster. [Siehe Kunde zu

Analytiker und Analytiker zu Entwickler]


Architekt zu Entwickler stellt ein unitäres Muster, wie die beiden

Vorgängermuster. Die strukturelle Definition ist sehr einfach gehalten. Es

besteht nur auch zwei Akteure und zwei Informationsflüssen.


Architekt zu Entwickler ist definitiv ein rollenbasiertes Muster. Seine

Charakteristik ist durch die rollenbedingte Voraussetzung geprägt. Und

dieses Muster gehört zur Mustergruppe Zyklus, da es als eine rollenbasierte

Version von Interaktion angesehen wird und diese zur Mustergruppe

Zyklus gehört.

Auswirkung


Architekt zu Entwickler gehört zu den zeitlichen Mustern. Für die

Identifikation des Musters ist die zeitliche Abfolge der charakteristische

Informationsflüsse relevant: [Siehe hierzu ebenfalls Kunde zu Analytiker

und Analytiker zu Architekt]


Dieses Muster ist ebenfalls ein fundamentales Muster in FLOW. Genauso

wie Kunde zu Analytiker und Analytiker zu Architekt sollte dieses Muster

als ein Prüfmuster genutzt werden. Immer wenn in einem FLOW-Modell

dieses Muster identifiziert wird, wirkt es sich stets positiv auf das

Softwareprojekt aus. Wenn aber Architekt zu Entwickler nicht identifiziert

werden können, und die vorausgesetzten Rollen aber vorhanden sind, dann

ist es entweder ein Warnzeichen für schlechte Kommunikation, oder es

wurde schlecht in FLOW modelliert und diese Informationsflüsse fehlen

einfach. In beiden Fällen muss die Kommunikation des Softwareprojektes

erneut analysiert werden.

Zeit t

SoftwareentwicklerSoftwarenarchitekt

1

P

139

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Val

idie

run

g

Ku

nd

e

An

alyt

.

An

alyt

. A

rch

it.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Wenig verwandt mit Hierarchie und Validierung,:

Mit diesen Mustern gehört Architekt zu Enwickler zur selben


Sehr verwandt mit Interaktion, Kunde zu Analytiker und Analytiker zu

Architekt:[siehe Interaktion und Kunde zu Analytiker und Analytiker

zu Architekt]


Order]

Auftreten Vorausgesetzt die entsprechenden Rollen wurden in FLOW modelliert ist

Architekt zu Entwickler ein sehr wichtiges und häufig gesehenes Muster.

Wie das Muster Kunde zu Analytiker und Analytiker zu Architekt ist dieses

Muster ein fundamentales positives Muster, daher muss es in

Softwareprojekten identifiziert werden können. Wenn nicht, dann muss

man eine genaue Kommunikationsanalyse durchführen.

Beispiele [Siehe Beispiele in Kunde zu Analytiker und Analytiker zu Architekt]

Zuerst kommuniziert der Softwarearchitekt direkt mit dem

Softwarenentwickler, stellt ihm seinen Softwareentwurf vor und danach

erhält der Softwarearchitekt von dem Softwarenentwickler die

Implementierung in Form eines Dokumentes, wie zum Beispiel

Programmierungscode o. ä. zurück.

SoftwareentwicklerSoftwarearchitekt

Programmiercode

SoftwareArchitektur

140

5.2.22 Validierung

[Quelle: http://www.kubiss.de/bildung/projekte/schb_netz/b4_projekte/schueler/IK10C0405/02/kunde.gif]

Der Kunde ist der König. Alles muss nach seinen Anforderungen und Wünschen angepasst

werden.


Komplexität:

Mustergruppe:

Form:

Qualität:

rezessives Muster



zeitliches Muster

positives Muster

Metapher „Validierung“ ist die Prüfung einer These, eines Plans oder

Lösungsansatzes in Bezug auf das zu lösende Problem. Sie ist eine

Bestätigung durch Bereitstellung eines objektiven Nachweises, dass die

Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine

spezifische beabsichtigte Anwendung erfüllt worden sind. In der

Softwaretechnik ist „Validierung“ ein wichtiger Aspekt der

Qualitätssicherung, der sicherstellen soll, dass ein implementiertes

Programm den vorher aufgestellten Anforderungen genügt.

Beschreibung Validierung ist ein positives Muster in FLOW, das eine Bestätigung durch

ein erzeugtes Dokument von einem Akteur darstellt, so dass die

spezifischen Anforderungen eines anderen Akteurs mit der Rolle Kunde

erfüllt worden sind. Das heißt, ein Akteur erstellt ein Dokument, meistens

ist dies eine schriftliche Zusammenfassung der besprochenen

Anforderungen, wie z.B. das Lastenheft oder ein Review-Dokument.

Daraufhin wird dieses Dokument dem Akteur mit der Rolle Kunde

vorgelegt und der Kunde verifiziert und gibt dem Akteur ein Feedback.

Charakteristik

Struktur Ein Akteur und ein Akteur mit der Rolle Kunde müssen vorhanden

sein.

Der Kunde und der Akteur beteiligen sich gemeinsam an einer

Aktivität.

Der Akteur verfestigt seine Informationen aus dieser Aktivität in

+

4

P

141

einem Dokument und dieser wird vom Kunden gelesen bzw. genutzt.

Daraufhin kommuniziert der Kunde flüssig mit dem Akteur, d.h. er

gibt Feedback zu dem Dokument zurück.

Definition:

Variante 1:

Die strukturelle Voraussetzung ist zwar nicht sehr komplex, aber dadurch,

dass charakteristischen Informationsflüsse nebenläufig zu der Aktivität

verläuft, ist es häufig schwierig, das Muster in einem FLOW-Modell diese

komplexe Struktur mit unbekannten Anzahl an Informaitonsflüsse,

wiederzuerkennen. Daher ist Validierung ein rezessives Muster.


Validierung ist aufgrund der unbekannten Aktivität in der strukturellen

Definition ein kombinatorisches Muster. Denn es wird je nach Umfeld und

Kontext aus unbekannt vielen FLOW-Grundelementen bestehen.


Validierung ist eindeutig ein Muster der Mustergruppe Rollenbasiertes

Muster. Da in der strukturellen Definition ein Akteur mit der Rolle Kunde

nicht fehlen darf. Und Validierung gehört auch zu der Mustergruppe

Zyklus, da die charakteristischen Informationsflüsse vom Akteur zum

Kunde und wieder zurück zu ihm führen und somit einen Kreislauf bilden.

Auswirkung


Validierung ist ein zeitliches Muster. Es geht schließlich bei diesem Muster

darum, die vom Kunde gestellten Anforderung zu einem späteren

Zeitpunkt zu validieren bzw. durch den Kunden nochmals zu bestätigen.

Akteur1

Dokument

Kunde

Aktivität1

Analytiker

Anforderungs-spezifikation

Kunde

Anforderungenerheben

4

142

Variante 1: Die obere Variante unter Betrachtung des zeitlichen

Aspekts, d.h. abgerollt auf die Zeit:


Bereits in der Beschreibung schon erwähnt, ist Validierung sicherlich ein

Muster mit positiver Auswirkung. In der strukturellen Definition ist es

bereits festgelegt, unter welchen Umständen dieses Musters auftritt. Es

wirkt sich immer positiv auf das Projekt, wenn dieses Muster bei der

Kommunikation mit dem Kunden identifiziert wird.

Diskussion

Verweis auf

Muster


Solit

är

Hie

rarc

hie

Mis

s. E

xp.

Per

m. O

rd.

Inte

rakt

ion

Osm

ose

Syn

ergi

e

Still

e P

ost

Wie

der

h. I

nfo

rm.

Wri

te F

or

On

e

Per

son

a. S

enke

Dea

d D

ocu

m.

Ku

nd

e

An

al.

An

al.

Arc

hit

.

Arc

hit

. E

ntw

.

Bü

rokr

atie

Ligh

tw. D

ocu

m.

Skip

. Do

cum

.

Alle

inkä

mp

fer

Exp

. Exp

ert

Do

kum

ent

VID

Zeit t

Kunde Analytiker

Anforderungs-spezifikation

tOutput

Anforderungen erheben

PM

143

Wenig verwandt mit Interaktion, Hierarchie, Kunde zu Analytiker,

Analytiker zu Architekt und Architekt zu Entwickler:

Mit diesen Mustern gehört Validierung zur selben Mustergruppe.

Verwandt mit Write For One: [siehe Write For One]

Sehr verwandt mit Kunde zu Analytiker: [siehe Kunde zu Analytiker]

Gegensätzlich und disjunkt mit Permuted Order, Stille Post und

Wiederholte Information: [siehe Permuted Order, Stille Post und

Wiederholte Information]

Auftreten Validierung ist wohl ein sehr häufig auftretendes Muster in der

Softwareentwicklung. Denn jedes Softwareprojekt hat ein Kunde, der die

Anforderungen stellt und seine Wünsche äußert.

Beispiele Validierung kann als Lösung für Stille Post, in Bezug auf die Rolle Kunde,

verwendet werden. Zudem ist Kunde zu Analytiker eine Spezialisierung

von Validierung. [Siehe Beispiele in Stille Post und Kunde zu Analytiker]

144

6 Literaturverzeichnis

[Ge 2008] Ge, X.

FLOW-Patterns: Beschreibung und Diskussion der Informationsflussmustern

in der Softwareentwicklung

Masterarbeit am Fachgebiet Software Engineering der Leibniz Universität

Hannover (2008)

[Schneider 2007] Schneider, K.

Abenteuer Software Qualität

1.Auflage, dpunkt.verlag GmbH (2007), Heidelberg

[Schneider et al. 2007] Schneider, K. und Stapel K.

Informationsflussanalyse für angemessene Dokumentation und verbesserte

Kommunikation

[Stapel 2006] Stapel, K.

Informationsflussoptimierung eines Softwareentwicklungsprozesses aus der

Bankenbrache

Masterarbeit (2006), FG Software Engineering, Leibniz Universität Hannover

[VModellXT] Beispielprojekt

V-Modell XT: Eine Tour durch das V-Modell XT

http://www.v-modell-xt.de/ Letzter Seitenbesuch: 02.04.2008

http://www.v-modell-xt.de/

145

Dieser FLOW-Patterns-Katalog ist aus der Masterarbeit von Xiaoxuan Ge

am 08.April 2008 entstanden. Weitere Details und Vorgehensweise

siehe Masterarbeit. Aktualisierte Version des FLOW-Patterns-

Online-Katalogs ist auf der Internetseite des Instituts

zu finden.

FLOW-Patterns-Katalog -...

Documents

Transcript of FLOW-Patterns-Katalog -...