flow-patterns-katalog -...
TRANSCRIPT
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
Analytiker zu Architekt
Architekt zu Entwickler
Validierung
Interaktion
Osmose
Lightweight Documentation
Wichtiges Dokument (VID)
Experienced Expert
kontext-
abhängig
Übersprunges Dokument
Hierarchie
Write For One
Wiederholte Information
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)
<Bez. des Dokuments>
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.
Definition: Ein Werkzeug bezeichnet die für die Informationsweitergabe bzw.
-übertragung eingesetzte Methoden oder Tools. Diese Angabe ist optional.
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
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 DokuM Akteur2
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>
Ein einzelner Akteur:
<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}
<Bez. des Dokuments>
Ein einzelner Akteur:
{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)
Definition: Ein Werkzeug bezeichnet die für die Informationsweitergabe bzw.
-übertragung eingesetzte Methoden oder Tools. Diese Angabe ist optional.
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
wahrgenom- mene 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
Gilt ebenfalls für Erfahrungsflüsse:
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
Gilt ebenfalls für Erfahrungsflüsse:
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
Wiederholte Information
Lightweight Documentation
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.
Kategorie Flussbasierte Muster
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.
Allgemeine Definition:
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.
Kategorie Flussbasierte Muster
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.
Allgemeine Definition:
Verweis auf
Muster
Zur Mustergruppe Zyklus gehören folgende Muster:
Interaktion
Validierung
Kunde zu Analytiker
Analytiker zu Architekt
Architekt zu Entwickler
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.
Kategorie Flussbasierte Muster
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.
Allgemeine Definition:
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.
Kategorie Flussbasierte Muster
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.
Allgemeine Definition:
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.
Kategorie Flussbasierte Muster
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.
Struktur Allgemeine Definition:
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.
Struktur Allgemeine Definition:
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
Analytiker zu Architekt
Architekt zu Entwickler
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.
Struktur Allgemeine Definition:
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
Verwandtschaftsintensität:
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.“
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
mehrdimensionales Muster
Talking Only
quantitatives Muster
kontextabhängiges Muster
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
Struktur Dominantes Muster
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.
Komplexität Mehrdimensionales Muster
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
Form Quantitatives Muster
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
Qualität Kontextabhängiges Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
lineares Muster
Talking Only, Sequenz
quantitatives Muster
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
Struktur Dominantes Muster
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
Form Quantitatives Muster
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
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.
Akteur1 Akteur2 Akteur3
Akteur1 Akteur2 Akteur3
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
unitäres Muster
Unterbrechung
quantitatives Muster
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
Struktur Dominantes Muster
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.
Komplexität Unitäres Muster
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
Form Quantitatives Muster
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.
Qualität Negatives Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
rezessives Muster
kombinatorisches Muster
Talking Only
quantitatives Muster
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
Form Quantitatives Muster
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.
Qualität Positives Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
lineares Muster
Rollenbasierte Muster, Sequenz
zeitliches Muster
kontextabhängiges 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
Struktur Dominantes Muster
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.
Komplexität Lineares Muster
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
Form Zeitliches Muster
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.
Qualität Kontextabhängiges Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
mehrdimensionales Muster
Unterbrechung
quantitatives Muster
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
Struktur Dominantes Muster
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.
Komplexität Mehrdimensionales 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.
Mustergruppe Unterbrechung
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
Form Quantitatives Muster
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
Qualität Negatives Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
mehrdimensionales Muster
Mainly Writing
zeitliches Muster
kontextabhängiges 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
Struktur Dominantes Muster
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.
Komplexität Mehrdimensionales 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
Form Zeitliches Muster
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.
Qualität Kontextabhängiges Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
rezessives Muster
lineares Muster
Parallele Flüsse, Talking Only
zeitliches Muster
kontextabhängiges 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.
Komplexität Lineares Muster
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
Form Zeitliches Muster
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>
StartAkteur ZielAkteur
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.
Qualität Kontextabhängiges Muster
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
StartAkteur ZielAkteur
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
mehrdimensionales Muster
Unterbrechung
quantitatives Muster
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.
Komplexität Mehrdimensionales Muster
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.
Mustergruppe Unterbrechung
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
Form Quantitatives Muster
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.
Qualität Negatives Muster
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
Verwandtschaftsintensität:
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
Spezialist zu einem nicht vorankommenden Softwareprojekt eingestellt
werden. Dieser Experte ist auf Personalorganisation spezialisiert und soll
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
unitäres Muster
Abweichung Ist-Soll
quantitatives Muster
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.
Komplexität Unitäres Muster
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
Form Quantitatives Muster
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
Qualität Negatives Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
rezessives Muster
Kombinatorisches Muster
Abweichung Ist-Soll
zeitliches Muster
kontextabhängiges 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.
Komplexität Kombinatorisches Muster
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
Form Zeitliches Muster
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
Qualität Kontextabhängiges Muster
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
Verwandtschaftsintensität:
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
Übersprungenes Dokument]
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
rezessives Muster
kombinatorisches Muster
Mainly Writing, Parallele Flüsse
quantitatives Muster
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.
Komplexität Kombinatorisches Muster
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
Form Quantitatives Muster
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.
Qualität Positives Muster
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
Verwandtschaftsintensität:
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
Lightweight Documentation
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
mehrdimensionales Muster
Sequenz, Mainly Writing
zeitliches Muster
kontextabhängiges 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.
Komplexität Mehrdimensionales Muster
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
Form Zeitliches Muster
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.
Qualität Kontextabhängiges Muster
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
Verwandtschaftsintensität:
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
Übersprungenes Dokument]
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
mehrdimensionales Muster
Hub
quantitatives Muster
kontextabhängiges Muster
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
Form Quantitatives Muster
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
Qualität Kontextabhängiges Muster
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
Verwandtschaftsintensität:
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
Spezialist zu einem nicht vorankommenden Softwareprojekt eingestellt
werden. Dieser Experte ist auf Personalorganisation spezialisiert und soll
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
mehrdimensionales Muster
Hub
quantitatives Muster
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.
Komplexität Mehrdimensionales Muster
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
Form Quantitatives Muster
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.
Qualität Positives Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
mehrdimensionales Muster
Hub
quantitatives Muster
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
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.
Komplexität Mehrdimensionales 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
Form Quantitatives Muster
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.
Qualität Positives Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
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.
Komplexität Unitäres Muster
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
Form Zeitliches Muster
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:
Qualität Positives Muster
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
Verwandtschaftsintensität:
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
unitäres Muster
Rollenbasiertes Muster, Zyklus
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.
Diese beiden Akteure kommunizieren interaktiv miteinander
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]
Komplexität Unitäres Muster
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.
Mustergruppe Rollenbasiertes Muster, Zyklus
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
Form Zeitliches Muster
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:
Qualität Positives Muster
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
Verwandtschaftsintensität:
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
Mustergruppe Rollenbasiertes Muster.
Sehr verwandt mit Interaktion, Kunde zu Analytiker und Architekt zu
Entwickler: [siehe Interaktion, Kunde zu Analytiker]
Gegensätzlich und disjunkt mit Permuted Order: [siehe Permuted
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.
Softwareanalytiker Softwarearchitekt
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
dominantes Muster
unitäres Muster
Rollenbasiertes Muster, Zyklus
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.
Diese beiden Akteure kommunizieren interaktiv miteinander
Zwischen dem Softwarenanalytiker und dem Softwarearchitekt
fließen in beider Richtung direkte flüssiger Informationen.
Definition:
Softwareanalytiker Softwarearchitekt
+
1
P
+
138
Architekt zu Entwickler ist ein dominantes Muster. [Siehe Kunde zu
Analytiker und Analytiker zu Entwickler]
Komplexität Unitäres Muster
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.
Mustergruppe Rollenbasiertes Muster, Zyklus
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
Form Zeitliches Muster
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]
Qualität Positives Muster
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
Verwandtschaftsintensität:
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
Mustergruppe Rollenbasiertes Muster.
Sehr verwandt mit Interaktion, Kunde zu Analytiker und Analytiker zu
Architekt:[siehe Interaktion und Kunde zu Analytiker und Analytiker
zu Architekt]
Gegensätzlich und disjunkt mit Permuted Order: [siehe Permuted
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.
Klassifikation Struktur:
Komplexität:
Mustergruppe:
Form:
Qualität:
rezessives Muster
kombinatorisches Muster
Rollenbasiertes Muster, Zyklus
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.
Komplexität Kombinatorisches 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.
Mustergruppe Rollenbasiertes Muster, Zyklus
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
Form Zeitliches Muster
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:
Qualität Positives Muster
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
Verwandtschaftsintensität:
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
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.