Emergenz in der Softwareentwicklung - bereits verwirklicht oder Chance?

INHALTSVERZEICHNIS 2

Inhaltsverzeichnis

Abbildungsverzeichnis 4

1  Einleitung  5

1.1  Motivation  5

1.2  Ansatz  5

1.3  Abgrenzung  6

2  Emergenz  7

2.1  Begriff und Definition Emergenz  7

2.2  Emergenz als Prozess  8

2.3  Historizismus und Reduktionismus  8

2.4  Zusammenfassung Begriff Emergenz  10

3  Transformationsprozess  11

3.1   

  Uberblick  11

3.2  Erkl arungsmodell Synergetik  11

3.3  Erkl arungsmodell Chaostheorie  14

3.4  Erkl arungsmodell Autopoiesis  17

3.5  Zusammenfassende Vereinheitlichung  19

4  Geschichtliche Entwicklung  21

4.1  Einleitung  21

4.2  Mechanisches Weltbild  21

4.3  Das neue Weltbild  22

4.4  Systematisierung  24

5  Anwendung von Emergenz  25

5.1  Einleitende Worte  25

5.2  Teilbereich Wirtschaft  25

5.2.1  Managementtheorien  25

5.2.2  Theorie steigender Ertr age  28

5.2.3  Markttheorie Transaktionskostentheorie und Markt-  

  wirtschaft im Unternehmen  30

5.3  Teilbereich Informatik  31

5.3.1  Sozionik  31

5.3.2  Organic Computing  32

5.3.3  Neuronale Netze  32

5.3.4  Genetische Algorithmen  34

5.4  Zuordnung zur Systematik  35

INHALTSVERZEICHNIS 3

6  Klassische Softwareentwicklung  37

6.1  Einleitung  37

6.2  Softwareentwicklung allgemein  37

6.3  Vorgehensmodelle der Klassischen Softwareentwicklung  38

6.3.1  Vorgehensmodell Code and Fix  39

6.3.2  Vorgehensmodell Wasserfallmodell und V-Modell  39

6.3.3  Iterativ inkrementelle und plangetriebene  Vorgehens-

  modelle  41

6.4  Softwareentwicklung als Ingenieurdisziplin  42

6.4.1  Determinismus in der klassischen Softwareentwicklung  45

6.4.2  Linearit at in der klassischen Softwareentwicklung  45

6.5  Zusammenfassung klassische Softwareentwicklung  46

7  Agile Softwareentwicklung  47

7.1  Einleitung  47

7.2  Agiler Vertreter: Extreme Programming  47

7.2.1  Einleitung  47

7.2.2  Grundwerte  47

7.2.3  Umkehrung der Kostenkurve  49

7.2.4  Die 12 Grundpraktiken  50

7.2.5  Planung und Anforderungsverwaltung  55

7.2.6  Zusammenfassung Extreme Programming  57

7.3  Agiler Vertreter: Methodikfamilie Crystal  58

7.4  Manifest agiler Softwareentwicklung  61

7.5  Begriff Agilit at  63

7.6  Emergent Design  65

7.7  Einordnung in die Systematik  66

7.8  Zusammenfassung agile Softwareentwicklung  66

8  Emergenz in der Softwareentwicklung  68

8.1  Einleitung  68

8.2  Bew altigung von Emergenz in der Softwareentwicklung  68

8.3  Gestaltung von Emergenz in der Softwareentwicklung  73

8.4  Zusammenfassung Emergenz in der Softwareentwicklung  75

9  Zusammenfassung  76

  Literatur  78

  Stichwortverzeichnis  83

ABBILDUNGSVERZEICHNIS 4

Abbildungsverzeichnis

1  Emergenz als Transformationsprozess  9

2  Synergetik am Beispiel Entstehung von Ordnung auf einer  

  Treppe  13

3  zweidimensionaler Phasenraum mit Trajektorien und Attraktor  15

4  Chaostheorie am Beispiel Wasserstr omung in Kanal  16

5  Neuronales Netz  33

6  Ablauf genetischer Algorithmus  34

7  Wasserfallmodell  40

8  Schichten des V-Modell  41

  zeitliche Abh angigkeit der Kosten f ur  

9  Anderungen nach Boehm  43

10  zeitliche Abh angigkeit der Kosten f ur  

  Anderungen nach Beck  49

11  globaler Ablauf eines Extreme Programming Projektes (nach  

  Wel99)  55

12  Ablauf einer Iteration in Extreme Programming (nach Wel99)  57

13  Crystal Projekteinordnung nach Anzahl Mitarbeiter Kriti-  

  zit at und Priorit aten  59

14  Anzahl Kommunikationswege bei direkter und bei gemischter  

  Kommunikation am Beispiel eines Teams mit sechs Mitgliedern  61

1 EINLEITUNG 5

1 Einleitung

1.1 Motivation

uber 35 Jahren 1 findet eine wissenschaftliche Auseinandersetzung mit Seit ¨ dem Gebiet der Softwareentwicklung statt. Seit den Anf¨ angen konnten be- reits bemerkenswerte Fortschritte in den drei Kernbereichen

• Qualit¨ at

• Produktivit¨ at

• Kosten

erzielt werden. Gleichzeitig stiegen die Anforderungen an die Softwareent- wicklung – Softwaresysteme werden immer komplexer. Diese Entwicklung geht zumindest genauso schnell vonstatten, wie die Verbesserungen in der Softwareentwicklung.

Heutzutage wird Softwareentwicklung als ein ingenieurtechnischer Pro- zess verstanden und teilweise als solcher umgesetzt. Trotz einer Erh¨ ohung der Komplexit¨ at und des Umfangs der Planungsmethoden und Vorgehens- modelle ist die resultierende Software in Hinblick auf Qualit¨ at, Einhaltung des Entwicklungsbudgets und termingerechter Auslieferung oft mangelhaft. Der durch immer komplexere Vorgehensmodelle ben¨ otigte Aufwand steht in keinem Verh¨ altnis zu den Verbesserungen durch diese Vorgehensmodelle.

1.2 Ansatz

Die vorliegende Arbeit unternimmt deshalb den Versuch, die Problematik der Softwareentwicklung aus einer anderen Perspektive darzustellen. Da- mit verbindet sich die Hoffnung, die grundlegenden Probleme der Softwa- reentwicklung identifizieren zu k¨ onnen. Durch die Betrachtung der Proble- matik aus dem Blickwinkel der Emergenz wird versucht, neue Ans¨ atze f¨ ur die Softwareentwicklung zu finden bzw. vorhandene Ans¨ atze zu vereinheit- lichen. Einschr¨ ankend muss erw¨ ahnt werden, dass diese Arbeit nicht den Versuch unternimmt einen ” Silver-Bullet“ (vgl. Bro01a) zu formulieren. Mit der neuen Sichtweise Emergenz in der Softwareentwicklung wird auch wei- terhin lediglich eine moderate Produktivit¨ ats- und Qualit¨ atssteigerung sowie Kostenreduzierung erreicht werden k¨ onnen.

Als Ausgangspunkt f¨ ur diese Arbeit bietet sich die Untersuchung des Be- griffs Emergenz an. Anhand der Definition wird untersucht, welche Modelle zur Erkl¨ arung von Emergenz existieren. Dies wird in der Endkonsequenz bis zur Frage der philosophischen Grundauffassung – dem Weltbild – f¨ uhren. 1 Als Ausgangspunkt wird die NATO Konferenz zum Thema Software Engineering im Jahr 1968 in Garmisch angesehen.

1 EINLEITUNG 6

Weiterhin ist von Interesse, ob und wie bereits Emergenz in anderen Be- reichen der Wirtschaftsinformatik eingesetzt wird. Bevor diese Erkenntnisse auf die Softwareentwicklung ¨ ubertragen werden k¨ onnen, muss zun¨ achst die aktuell praktizierte Softwareentwicklung nachgezeichnet werden, damit ein Vergleich m¨ oglich wird. Anschließend kann untersucht werden, ob Emergenz in der Softwareentwicklung anwendbar ist, vielleicht schon angewendet wird und ob eine Anwendung eine Chance bietet.

1.3 Abgrenzung

Diese Arbeit w¨ ahlt bewusst einen interdisziplin¨ aren Ansatz, ganz im Sin- ne der Wirtschaftsinformatik. Es wird versucht eine Br¨ ucke zwischen Na- turwissenschaft und Gesellschaftswissenschaft zu schlagen. Die Softwareent- wicklung konnte schon mehrfach von der Adaption von Konzepten aus an- deren Wissenschaften profitieren. Erw¨ ahnt sei an dieser Stelle z. B. die ur- spr¨ unglich aus der Architektur stammenden Entwurfsmuster nach Gamma. (Gam96) Da im Rahmen dieser Arbeit teils sehr unterschiedliche Theorien vorge- stellt werden, m¨ ussen entsprechende Vereinfachungen vorgenommen werden und die meisten erw¨ ahnten Anwendungen k¨ onnen nur relativ kurz diskutiert werden. Dies wird nicht als Nachteil angesehen, da oftmals in vielen Berei- chen ein hohes Detailwissen existiert, eine bereichs¨ ubergreifende Kombinati- on findet allerdings zu selten statt. Der Bezug zum Detailwissen wird mittels eines umfangreichen Literaturverzeichnis sowie Fußnoten zur Verf¨ ugung ge- stellt.

Weiterhin findet keine kritische Bewertung einer m¨ oglichen Anwendung von Emergenz in der Softwareentwicklung statt. Dies w¨ urde den Umfang dieser Arbeit sprengen und sollte in einer eigenen Arbeit n¨ aher untersucht werden.

2 EMERGENZ 7

2 Emergenz

2.1 Begriff und Definition Emergenz

Bevor auf den Begriff Emergenz n¨ aher eingegangen werden kann, muss der Systembegriff kurz charakterisiert werden, da Emergenz in Systemen auf- tritt. Ein System ist definiert als ” eine Menge von Elementen, die mitein- ander durch Beziehungen verbunden sind und gemeinsam einen bestimmten Zweck zu erf¨ ullen haben.“ (M¨ ul00, S. 48) Somit besteht ein System aus Systemelementen, Beziehungen zwischen den Elementen, den so genannten Relationen, und einer Systemgrenze. Mit der Systemgrenze kann klar zwi- schen System und seiner Umwelt unterschieden werden, die Systemgrenze grenzt das System von der Umwelt ab.

In dieser Arbeit steht der Begriff aktueller Systemzustand f¨ ur die Zusam- menfassung von allen Systembestandteilen sowie die sich daraus ergebende Systemstruktur und Systemordnung. Unter einer ¨ Anderung des Systemzu- standes wird somit die ¨ Anderung von Systemelementen, Relationen, Sys- temgrenze, Systemstruktur oder Systemordnung verstanden. In der Physik bezeichnet man ein System als offen, wenn ein Energie- austausch zwischen Umwelt und System stattfindet. In einem geschlossenen System hingegen findet kein Energieaustausch mit der Umwelt statt und des- halb gilt der zweite Hauptsatz der Thermodynamik. 2 Die in dieser Arbeit betrachteten Systeme k¨ onnen alle als offen bezeichnet werden. In sozialen Systemen entspricht der Energieaustausch dem Informationsaustausch mit der Umwelt.

Das Substantiv Emergenz kann auf das lateinische Verb emergo zur¨ uck- gef¨ uhrt werden. Das Verb emergo hat im Deutschen die Bedeutung ” auftau- chen“ und ” sich herausarbeiten“. (vgl. Men98) Die Verwendung des Wor- tes kann bis zum Anfang unserer Zeitrechnung zur¨ uckverfolgt werden (vgl. Geo13) 3 .

Aus der Bedeutung des lateinischen Verbes emergo l¨ asst sich die Bedeu- tung des Wortes Emergenz ableiten. Man versteht demzufolge unter Emer- genz das Auftauchen von Systemzust¨ anden, die nicht durch die Eigenschaf- ten der beteiligten Systemelemente erkl¨ art werden k¨ onnen. Im Duden fin- det man die Definition von Emergenz als das Ph¨ anomen ” wonach h¨ ohere Seinsstufen durch neu auftauchende Qualit¨ aten aus niederen entstehen“. (Dud00) Bei dieser Definition ist zu beachten, dass die ” neu auftauchenden Qualit¨ aten“ erst ” entstehen“ und nicht bereits vorhanden sind. Im Volks- mund wird diese Idee formuliert als: ” Das Ganze ist mehr als die Summe seiner Teile.“ F¨ ur dieses ” Mehr“ bzw. dessen Entstehung steht der Begriff Emergenz.

Das Ph¨ anomen der Emergenz l¨ asst sich am Beispiel Temperatur ver- 2 Erkl¨ arung zum zweiten Hauptsatz der Thermodynamik siehe Kapitel 3.2 auf Seite 11 3 z. B. bei Velleius Paterculus in ” Historia Romana“ ca. 29 n. Chr.

2 EMERGENZ 8

deutlichen. Betrachtet man ein einzelnes chemisches Molek¨ ul, wie z. B. das Wassermolek¨ ul, dann kann man f¨ ur dieses Molek¨ ul keine Temperatur be- stimmen. Hat man allerdings eine große Menge des einzelnen Molek¨ uls, dann ist es m¨ oglich eine Temperatur zu ermitteln. Die Temperatur entsteht erst, wenn viele Molek¨ ule aufeinander treffen. Somit kann die Temperatur als ei- ne emergente Eigenschaft vieler Molek¨ ule angesehen werden. Bei Wasser ist die Temperatur eine emergente Eigenschaft der Wassermolek¨ ule, aber es ist keine emergente Eigenschaft des Wassers.

2.2 Emergenz als Prozess

Ausgehend vom Systembegriff kann gesagt werden, dass ein System den aktuellen Systemzustand A besitzt. Wird dieses System in einen neuen Systemzustand B ¨ uberf¨ uhrt, findet eine Transformation (vgl. Ess00) von Systemzustand A nach Systemzustand B statt. Diese Transformation ist das Ergebnis eines Transformationsprozesses. Man bezeichnet den Trans- formationsprozess als Emergenz, wenn der Systemzustand B nicht direkt aus Systemzustand A gefolgert 4 werden kann. Eine andere Bezeichnung f¨ ur diesen Prozess liefert Fliedner (Fli99) mit dem Begriff Komplexionsprozess: Da dieser Prozeß eine Komplexit¨ atsebene verl¨ aßt und eine neue Komple- ” xit¨ atsebene anstrebt, nennen wir ihn Komplexionsprozeß.“ (Fli99, S. 12) 5 In dieser Arbeit wird der Begriff Transformationsprozess verwendet, da er im Rahmen der aus der Informatik bekannten Systemtheorie gel¨ aufiger ist. Durch die Betrachtung von Emergenz als Transformationsprozess (nach Ess00) kann der Emergenzbegriff entmystifiziert werden. Dies er¨ offnet die M¨ oglichkeit wissenschaftlicher Untersuchungen, welche ” Transformationsre- geln“ (Ess00, S. 13) konkret wirken. Der vollst¨ andige Zusammenhang l¨ asst sich wie in Abbildung 1 auf Seite 9 veranschaulichen. Tats¨ achlich ist es so, dass bei Transformationen, deren Regeln vollst¨ andig bekannt sind, nie- mand von Emergenz sprechen w¨ urde. Somit ist Emergenz keine feste Gr¨ oße, sondern immer vom aktuellen Kenntnisstand abh¨ angig. (Ess00, S. 4) Bei erh¨ ohtem Kenntnisstand spricht man dann unter Umst¨ anden nicht mehr von Emergenz.

2.3 Historizismus und Reduktionismus

W¨ ahrend des Transformationsprozesses treten neue Qualit¨ aten auf, die nicht auf die Aufsummierung der Einzeleigenschaften zur¨ uckgef¨ uhrt werden k¨ on- nen. Aus diesem Ansatz ergibt sich die Frage, ob das Emergenzph¨ anomen sich ¨ uberhaupt auf einfache Transformationsregeln reduzieren l¨ asst. Der His- torizismus verneint diese These und behauptet im Gegenteil, dass es Gesetze auf h¨ oheren Ebenen (Makroebene) gibt, die sich nicht auf die Naturgesetze 4 genaue Erl¨ auterung dazu in Kapitel 3.5 auf Seite 19 5 Hervorhebungen im Original

2 EMERGENZ

Abbildung 1: Emergenz als Transformationsprozess

reduzieren lassen. Zur Erkl¨ arung werden dann ” Vitalkr¨ afte und spirituelle Agentien“ (PJS94, S. 30) bem¨ uht, die die physikalischen Naturgesetze außer Kraft setzen. Solch ein Makrogesetz m¨ usste allerdings den Zustand aller Ele- mente genau beschreiben. Ein derart umfassendes Makrogesetz nimmt dem- nach keine Vereinfachung vor und ist somit selber die Realit¨ at. In diesem Zusammenhang von einem Gesetz oder einem Modell zu sprechen, erscheint sinnlos. Anhand dieser Argumentationslinie (nach Pop87) 6 wurde gezeigt, dass ein reiner Historizismus allgemein wenig sinnvoll ist. Die Gegenstr¨ omung zum Historizismus ist der Reduktionismus. Reduk- tionisten stellen die These auf, dass jedes Ph¨ anomen auf wenige Naturge- setze reduziert werden kann. Im oben genannten Beispiel von Temperatur als emergenter Eigenschaft von Molek¨ ulen scheint dies anhand von Bewe- gungsgesetzen und dem ersten Hauptsatz der Thermodynamik durchaus m¨ oglich. Allerdings ist fraglich, ob jemals eine Reduzierung von mensch- lichem Gruppenverhalten auf die Bewegung von Atomen m¨ oglich ist. Ei- ne Reduzierung aller Ph¨ anomene im Universum auf wenige Naturgesetze scheint sehr theoretisch. (vgl. St¨ o94) Der Ansatz ist in der Praxis wenig gangbar. Sinnvoller ist zu akzeptieren, dass eine Reduktion von Emergenz auf physikalische Naturgesetze (momentan) nicht m¨ oglich ist. Es m¨ ussen so- mit Erkl¨ arungsmodelle gefunden werden, die auf einer h¨ oheren Ebene anset- zen. Diese Erkl¨ arungsmodelle, wie im n¨ achsten Kapitel vorgestellt, m¨ ussen unter Beachtung der bekannten Naturgesetze aufgestellt werden, um Histo- rizismus zu vermeiden. (PJS94, S. 30ff) Aus dieser Forderung leitet sich das Anliegen dieser Arbeit ab. Es wird untersucht, wie die im n¨ achsten Kapitel vorgestellten Erkl¨ arungsmodelle praktisch in der Software Entwicklung an- gewendet werden bzw. angewendet werden k¨ onnen. Es wird allerdings nicht untersucht, weshalb die Erkl¨ arungsmodelle wirken - eine Reduzierung, z. B. auf soziologische Theorien, findet nicht statt.

6 speziell Kapitel 23: Kritik des Holismus

2 EMERGENZ 10

2.4 Zusammenfassung Begriff Emergenz

Die bisherigen Erl¨ auterungen lassen sich folgendermaßen zusammenfassen:

1. Ein System kann seinen Zustand qualitativ ¨ andern.

2. Die ¨

Anderung kann unter Umst¨ anden nicht auf die Eigenschaften der einzelnen Systemelemente und deren Relationen untereinander zur¨ uck- gef¨ uhrt werden.

3. Der neue Systemzustand ist somit mehr als eine reine Aufsummierung

der Einzeleigenschaften der Systemelemente und deren Beziehungen.

Dieses Ph¨ anomen wird als Emergenz bezeichnet.

Das System, bestehend aus den Systemelementen, den Relationen und der Systemgrenze, wird in einem Transformationsprozess bzw. Komplexi- onsprozess ver¨ andert. Im nun folgenden Abschnitt wird untersucht, wel- che Erkl¨ arungsmodelle f¨ ur diesen Transformationsprozess existieren. In die- sem Zusammenhang wird der Begriff Selbstorganisation eingef¨ uhrt, der von verschiedenen Autoren zur Erkl¨ arung des Emergenzph¨ anomens verwendet wird.

3 TRANSFORMATIONSPROZESS 11

3 Transformationsprozess

3.1 ¨

Uberblick

Im nun folgenden Abschnitt werden drei Erkl¨ arungsmodelle f¨ ur den Trans- formationsprozess vorgestellt:

• Synergetik nach Haken

• Chaostheorie

• Autopoiesis nach Maturana

Am Ende des Kapitels werden die drei Erkl¨ arungsmodelle auf die Begriffe Nicht-Linearit¨ at, Nicht-Determinismus und Selbstorganisation reduziert.

3.2 Erkl¨ arungsmodell Synergetik

Als erstes Erkl¨ arungsmodell wird die Wissenschaftsdisziplin Synergetik kurz umrissen. Synergetik ist die ” Lehre vom Zusammenwirken“ (Hak91, S. 17), entwickelt in den 60er Jahren von Hermann Haken. Zu dieser Zeit ent- deckte er die Lasertechnik. Dabei war von Interesse, warum sich die an einer diffusen Lichtquelle ausgestrahlten verschiedenen Lichtwellen zu einer Lichtwelle b¨ undeln und sich dadurch der Laserstrahl (monochromatisches Licht) bildet. Anders formuliert l¨ asst sich fragen, warum kommt es unter verschiedenen Lichtwellen zu einer Selbstorganisation mit dem Ergebnis ei- ner einzigen Lichtwelle? Anhand dieser Frage ergibt sich die Definition des Begriffes Selbstorganisation. In einem System spricht man von Selbstorgani- sation, wenn ein Systemzustand einzig von den Systemelementen und den Relationen hervorgerufen wird, ohne Einfluss der Umwelt auf das System. Die Synergetik versteht sich als eine fach¨ ubergreifende Wissenschaftsdis- ziplin (Hak91, S. 21) ¨ ahnlich der Mathematik und Statistik. Haken betont, dass die Synergetik nicht nur auf die Naturwissenschaft (z. B. Physik) ange- wendet werden kann, sondern eine Anwendung z. B. in Gesellschaftswissen- schaften wie der Soziologie ebenfalls m¨ oglich ist. F¨ ur die Synergetik wurde von Haken ein umfangreiches mathematisches Formelwerk (vgl. Hak90) ent- wickelt. Danach kann die Synergetik verstanden werden als ein ” Konzept zur Erkl¨ arung von Ordnungsbildung in stochastischen System mit vielen interagierenden Einheiten“. (Pas92, S. 3) An dieser Stelle wird auf eine ma- thematische Darstellung verzichtet und es folgt eine sprachliche Darstellung. Ausgangspunkt der Betrachtungen zur Synergetik ist die Frage, warum sich im Universum komplexe Strukturen entwickeln konnten, wenn allein der zweite Hauptsatz der Thermodynamik (Hak91, S. 25ff) gilt? Der zwei- te Hauptsatz besagt, dass in einem geschlossenem System die Unordnung stets zunimmt. So findet z. B. in einem beheiztem Wasserkessel solange ein W¨ armeaustausch statt, bis alle Wassermolek¨ ule gleichm¨ aßig verteilt sind

3 TRANSFORMATIONSPROZESS 12

und kein Temperaturunterschied innerhalb des Wasserkessels mehr besteht. Dieser Vorgang ist nicht umkehrbar, er ist irreversibel. Man wird nicht be- obachten, dass sich pl¨ otzlich wieder Temperaturunterschiede in einem Was- serkessel ergeben.

Trotz des zweiten Hauptsatzes der Thermodynamik hat sich aber im Universum eine Vielzahl von bemerkenswerten Strukturen herausgebildet, wie z. B. das Leben auf unserer Erde. Es ist sehr unwahrscheinlich, wenn dies lediglich Zufall sein sollte. Haken untersucht deshalb mit der Synerge- tik, wie sich eine große Anzahl von Einzelelementen zu h¨ oheren Strukturen selbstorganisieren.

Da in der Synergetik eine Reihe von neuen Begriffen eingef¨ uhrt werden, erfolgt die Darstellung an einem Beispiel (nach Pas92, S. 6). Dazu stelle man sich eine stark frequentierte Treppe in einem Geb¨ aude vor. Die Treppe wird von vielen Menschen in beiden Richtungen genutzt. Am Anfang er- wartet man, dass alle Menschen wild durcheinander gehen und sich dadurch gegenseitig behindern, wie in Abbildung 2 Teilbild a) auf Seite 13 gezeigt. Nun kann es passieren, dass einige Menschen der Spur ihres Vordermanns folgen. Aus diesem spontanen Verhalten kann eine Ordnung entstehen, wenn mehrere Menschen dem Beispiel folgen und ebenfalls die Spur f¨ ur ihre Rich- tung w¨ ahlen. Jetzt wird diese Spur f¨ ur die Bewegung der Menschen zu einer Art Vorgabe (Abbildung 2 Teilbild b)). Haken bezeichnet dies als Ordner. Der Ordner zwingt die Individuen sich dieser Ordnung anzupassen. In der Sprache der Synergetik versklavt der Ordner die Individuen. Durch diesen Vorgang ist aus einer vorher v¨ ollig zuf¨ alligen Bewegung der Menschen auf der Treppe eine geordnete Bewegung entstanden (Abbildung 2 Teilbild c)). Der Ordner existierte nicht von Anfang an, sondern hat sich spontan aus dem Verhalten der Individuen ergeben. Haken spricht hier von einem Pha- sen¨ ubergang. In der Folge hat der Ordner einen starken Einfluss auf das Verhalten der Individuen. Dadurch ergibt sich ein geschlossener Regelkreis, da der Ordner erst aus dem Verhalten der Individuen hervorgegangen ist, nun aber das Verhalten der Individuen entscheidend beeinflusst. Dies be- zeichnet man als Zirkularit¨ at.

Haken formuliert, dass sich durch die Versklavung der Individuen durch den Ordner ein Phasen¨ ubergang bildet. W¨ ahrend des Phasen¨ ubergangs zei- gen sich bereits Eigenschaften von beiden Phasen. Allerdings besteht keine Kausalit¨ at zwischen den Phasen. Es kann nicht vorhergesagt werden, welcher neue Zustand durch den Ordner hervorgerufen wird. Am Beispiel der Treppe ist es in Deutschland sehr wahrscheinlich, dass sich ” Rechtsverkehr“ ergibt.

Allerdings ist das nicht zwangsl¨ aufig. Schon wenige englische Touristen auf der Treppe reichen aus, um vielleicht einen Ordner f¨ ur ” Linksverkehr“ zu bilden. Haken versteht unter Nicht-Linearit¨ at, dass kleinste ¨ Anderungen der Systemstruktur – eine Fluktuation – riesige Auswirkungen auf den System- zustand haben k¨ onnen.

Durch die Ordner findet eine Komplexit¨ atsreduzierung statt. Es ist nicht

3 TRANSFORMATIONSPROZESS

Abbildung 2: Synergetik am Beispiel Entstehung von Ordnung auf einer Treppe

n¨ otig das genaue Verhalten der einzelnen Individuen zu kennen, es reicht zu wissen, welche Ordner f¨ ur die Individuen maßgebend sind. (Hak91, S. 23) Als Beispiel f¨ uhrt Haken die Erbsubstanz DNS (Desoxyribonukleins¨ aure) der Lebewesen an. (Hak91, S. 95ff) Trotz des riesigen Umfangs der DNS ist in dieser nicht die Information f¨ ur jede einzelne K¨ orperzelle abgelegt. Vielmehr enth¨ alt die DNS lediglich Informationen f¨ ur die verschiedenen Zelltypen so- wie die Information zur Bildung von Ordnern, die f¨ ur eine Strukturierung der Zellen sorgen.

W¨ ahrend der Selbstorganisation kann es passieren, dass mehrere Zust¨ an- de nach dem Phasen¨ ubergang gleich wahrscheinlich sind. In dieser Situati- on entscheidet der Zufall, welcher Zustand sich nach dem Phasen¨ ubergang ergibt. (Hak91, S. 109ff) Daraus folgt, dass eine Vorhersagbarkeit nicht m¨ oglich ist. Das System neigt zum Nicht-Determinismus. Damit es ¨ uberhaupt zu einem Phasen¨ ubergang kommt, muss dem Sys- tem Energie zugef¨ uhrt werden. In sozialen Systemen tritt an die Stelle der Energie die Information. Umgekehrt formuliert bedeutet dies, dass das Sys- tem Unordnung an seine Umwelt exportiert und von der Umwelt Struk- tur, in Form von Information, aufnimmt. Durch die Zuf¨ uhrung von Energie (Information) wird der zweite Hauptsatz der Thermodynamik außer Kraft gesetzt. Weiterhin muss das System aus einer gr¨ oßeren Anzahl von System- elementen bestehen, damit Ordnern entstehen k¨ onnen. Die konkrete Anzahl der ben¨ otigten Systemelemente h¨ angt vom System und der Vernetztheit der Elemente ab und kann mit dem mathematischen Modell von Haken ab- gesch¨ atzt werden. Elemente sind dann vernetzt, wenn die ¨ Anderung eines Elementes sich ¨ uber mehrere Stationen auf dieses Element wieder auswirkt. Dies bezeichnet man als R¨ uckkoppelung.

Da die Synergetik im Umfeld der Naturwissenschaften entstanden ist, f¨ allt eine ¨ Ubertragung auf gesellschaftliche Emergenzph¨ anomene schwer und wird von vielen Autoren kritisch hinterfragt. So lassen sich mit der Syner- getik z. B. Diktaturen rechtfertigen. Trotzdem unterst¨ utzt die Synergetik durch ihre klare sprachliche Formulierung das Verst¨ andnis von Emergenz.

3 TRANSFORMATIONSPROZESS 14

3.3 Erkl¨ arungsmodell Chaostheorie

Haken formuliert, dass die Chaostheorie als eine Untermenge der Synergetik verstanden werden kann. (Hak91, S. 58) Da sich die Chaostheorie jedoch relativ unabh¨ angig von der Synergetik entwickelt hat, erfolgt hier ein kurzer ¨ Uberblick. Auf eine mathematische Darstellung wird verzichtet und statt- dessen eine topologische Darstellung (nach Fl¨ a98, S. 127ff) gew¨ ahlt. Der Begriff Chaos mag irref¨ uhrend sein, da es sich nicht um die Bedeu- tung von Chaos im allgemeinen Sprachgebrauch handelt. Die Chaostheorie betrachtet kein v¨ ollig zuf¨ alliges Verhalten, wie z. B. die Brownsche Bewe- gung 7 . Um diesen Unterschied hervorzuheben, sprechen manche Autoren von deterministischem Chaos 8 .

Ausgangspunkt der Chaostheorie waren Untersuchungen durch den Me- teorologen Lorenz in der 60er Jahren. Er versuchte die Wetterentwicklung mit einem Gleichungssystem vorherzusagen, welches lediglich auf drei Va- riablen (Temperatur, Luftdruck und Windrichtung) und drei Gleichungen basiert. Dieser Versuch scheiterte, da schon kleine Messfehler bei der Er- hebung der aktuellen Wetterdaten zu sehr unterschiedlichen Vorhersagen f¨ uhrten. Obwohl eine mathematische Gleichung zugrunde lag, entwickelten sich die Ergebnisse unvorhersagbar. In diesem Zusammenhang wurde der Begriff deterministisches Chaos gebildet. Von Lorenz stammt das Sinnbild, wonach ein Schmetterlingsschlag 9 einen Sturm irgendwo anders auf der Welt ausl¨ osen kann.

Der Zustand eines Systems bildet in einem beliebig dimensionalen Raum, bezeichnet als Phasenraum, einen Punkt. Der Phasenraum kann z. B. durch die Dimensionen Ort, Zeit und Geschwindigkeit gekennzeichnet werden. Zwi- schen den verschiedenen Zustandspunkten im Phasenraum ergibt sich eine Kurve. Diese Kurve wird als Trajektorie bezeichnet. Streben nun alle Trajek- torien eines Systems, ausgehend von verschiedenen Startpunkten, auf einen bestimmten Bereich im Phasenraum asymptotisch zu, wird dieser Bereich als Attraktor bezeichnet. Der Attraktor bildet im Phasenraum einen Bereich, in dem sich das System relativ stabil verh¨ alt. Es ergibt sich das in Abbil- dung 3 auf Seite 15 dargestellte Diagramm. Interessant ist weiterhin, dass 7 Bereits im 19. Jahrhundert beobachtete Robert Brown unter dem Mikroskop eine scheinbar v¨ ollig zuf¨ allige Bewegung von Pollen. Erst gut 100 Jahre sp¨ ater konnte gezeigt werden, dass die Pollen durch viel kleinere ” unsichtbare“ Teilchen (z. B. Molek¨ ule) ge- stoßen werden und sich deshalb die zuf¨ allige Bewegung ergibt. Die Bewegung der Pollen (oder anderer Partikel) ist ein stochastischer Prozess und wird als Brownsche Bewegung bezeichnet.

8 Der Begriff deterministisches Chaos besagt, dass obwohl es einen Algorithmus zur Be- rechnung gibt, keine Vorhersage getroffen werden kann, ohne den Algorithmus vollst¨ andig auszuf¨ uhren. Dies l¨ asst sich am Beispiel der Zahl π nachvollziehen. Es ist unm¨ oglich z. B. die tausendste Stelle von π genau vorher zu sagen, ohne dass man die Berechnungsvor- schrift f¨ ur π durchf¨ uhrt. (vgl. PJS94, S. 11ff) 9 Lorenz hat wohl von dem Fl¨ ugelschlag einer Taube gesprochen, aber der Schmetter- lingsschlag hat sich als Metapher durchgesetzt.

3 TRANSFORMATIONSPROZESS

Abbildung 3: zweidimensionaler Phasenraum mit Trajektorien und Attrak- tor

der Bereich des Attraktors eine niedrigere Dimension als der Phasenraum besitzt und somit eine bessere Untersuchung des Systems m¨ oglich ist, da eine Vereinfachung vorliegt. Zum Verst¨ andnis soll erw¨ ahnt werden, dass im Rahmen der mathematischen Darstellung der Chaostheorie nicht ganzzah- lige Dimensionen zul¨ assig sind.

In der Chaostheorie ist ein Attraktor von besonderem Interesse. Dieser wird als seltsamer Attraktor bezeichnet und zeigt einige spezielle Eigenschaf- ten. Die sich dem seltsamen Attraktor asymptotisch n¨ ahernden Trajektori- en erreichen jeden Punkt des seltsamen Attraktors ohne sich gegenseitig zu schneiden. Hier spricht man von Struktur. Auf der anderen Seite ist das Ver- halten der Trajektorien v¨ ollig chaotisch, da die Trajektorien zwischen den einzelnen Punkten des seltsamen Attraktors ohne erkennbare Logik sprin- gen. Benachbarte Punkte liegen demnach auf unterschiedlichen Trajektorien und dadurch l¨ asst sich begr¨ unden, warum kleinste ¨ Anderungen, Fluktuatio- nen, zu sehr unterschiedlichen Ergebnissen f¨ uhren.

Vom Phasenraum zu unterscheiden ist der Parameterraum. In diesem Raum wird das Verhalten verschiedener Systeme dargestellt. Die Systeme sind sich ¨ ahnlich, weichen lediglich durch die Werte der Parameter ab. Prinzi- piell verlaufen die Kurven im Parameterraum kontinuierlich, allerdings kann es passieren, dass sich an einem Punkt das Verhalten des Systems grund- legend ¨ andert und somit eine ¨ Anderung der Systemparameter stattfindet.

Diese Punkte werden als Bifurkationspunkte bezeichnet. W¨ ahrend der Verlauf im Phasenraum mittels der Trajektorien nachvoll-

3 TRANSFORMATIONSPROZESS

Abbildung 4: Chaostheorie am Beispiel Wasserstr¨ omung in Kanal

zogen werden kann, scheint der Verlauf im Parameterraum v¨ ollig willk¨ urlich. Deshalb spricht man von deterministischem Chaos. Der Verlauf im Para- meterraum kann als Emergenz betrachtet werden. Eine Vorhersage scheint prinzipiell nicht m¨ oglich.

An dieser Stelle wird an einem kurzen Beispiel die Chaostheorie verdeut- licht. Das Beispiel geht zur¨ uck auf Haken (Hak91, S. 59), wurde aber f¨ ur diese Arbeit abgewandelt. Man stelle sich einen idealen geradlinigen Wasserkanal vor, wie in Abbildung 4 auf Seite 16 gezeigt. In dessen Mitte befindet sich ein Zylinder, um den das Wasser herumstr¨ omt. Bei niedriger Fließgeschwin- digkeit wird keine Auff¨ alligkeit zu beobachten sein (Abbildung 4 Teilbild a)). Das Wasser str¨ omt gleichm¨ aßig um den Zylinder. Erh¨ oht man die Fließ- geschwindigkeit kontinuierlich, werden sich ab einer bestimmten Geschwin- digkeit Wirbel im Wasser hinter dem Zylinder bilden, wie in Abbildung 4 Teilbild b) gezeigt. Die Wirbelbildung ist ein Attraktor . Das Umschlagen des Verhaltens des fließenden Wassers stellt eine Bifurkation dar. Durch ei- ne weitere Erh¨ ohung der Fließgeschwindigkeit nehmen die Wirbel zu und das Verhalten des Wassers hinter dem Zylinder wird dadurch zunehmend komplizierter zu beschreiben. Bei der weiteren Erh¨ ohung der Fließgeschwin- digkeit wird ein weiterer Bifurkationspunkt erreicht. Danach bewegt sich das Wasser hinter dem Zylinder v¨ ollig chaotisch (Abbildung 4 Teilbild c)) und es l¨ asst sich kein klares Verhalten, wie z. B. Wirbel, erkennen. Somit streben die Trajektorien, die den Zustand des Wassers hinter dem Zylinder beschreiben, auf den seltsamen Attraktor zu. In diesem Gedankenexperiment wurde lediglich die Fließgeschwindigkeit des Wassers erh¨ oht. Trotzdem er- gab sich daraus v¨ ollig unerwartetes (nicht-deterministisches) und spontanes (nicht-lineares) Verhalten. Dies entspricht dem Gedanken der Emergenz.

3 TRANSFORMATIONSPROZESS 17

3.4 Erkl¨ arungsmodell Autopoiesis

Abschließend wird die Autopoiesis nach Maturana betrachtet. Aus der Au- topoiesis entwickelte Luhmann sp¨ ater seine soziologische Systemtheorie (vgl. z. B. Sta94), die hier nicht betrachtet wird, da sie unter heftiger Kritik 10 steht. (z. B. bei B¨ uh87) Prinzipiell lassen sich zwei Ausgangspunkte (Fis93, S. 9) f¨ ur die Auto- poiesis erkennen. Auf der einen Seite versuchte Maturana, zusammen mit seinen Kollegen (speziell Varela), die nach dem zweiten Weltkrieg entstan- dene Kybernetik 11 auf die Biologie zu ¨ ubertragen. Auf der anderen Seite soll die Autopoiesis als ein naturwissenschaftliches Erkl¨ arungsmodell der Erkenntnis fungieren. (vgl. Fis93) In diesem Rahmen soll sie kl¨ aren, wie der Mensch zur Erkenntnis (Wissen) gelangen kann. Nach Maturana sind leben- de Systeme stets autopoietisch. Dieser Aspekt der Autopoiesis ist an dieser Stelle nicht von Interesse.

Der Begriff Autopoiesis bedeutet soviel wie ” Selbsttun“ oder ” Selbstge- staltung“. Damit wird ein wesentlicher Aspekt der Autopoiesis angespro- chen. Demnach d¨ urfen nur Systeme als autopoietisch bezeichnet werden, die ihre Systemelemente selbst erzeugen. Alle Systemelemente m¨ ussen aus den vorhandenen Systemelementen entstehen. In diesem Zusammenhang spricht man von Zirkularit¨ at. Es werden keine Systemelemente aus der Umwelt in das System ¨ ubernommen. Weiterhin m¨ ussen autopoietische Systeme abge- schlossen gegen¨ uber der Umwelt sein. Damit ist gemeint, dass eine Struk- turver¨ anderung nur aus dem System selbst heraus entstehen kann. Nicht ge- meint ist damit eine energetische oder informationelle Abgeschlossenheit ge- gen¨ uber der Umwelt, denn Struktur¨ anderungen ausl¨ osende Systemst¨ orungen k¨ onnen durchaus durch Umwelteinfl¨ usse erfolgen. Man bezeichnet diese Ei- genschaft, dass eigene Zust¨ ande nur im System intern bestimmt werden, als Selbstreferentialit¨ at. Das System w¨ ahlt durch die Festlegung der System- grenze den Umfang und die Art des Kontakts zur Umwelt. Diese Eigenschaft wird als strukturelle Koppelung bezeichnet und ersetzt die Input/Output Be- ziehung der Kybernetik. Aufgrund dieser Interpretation der Systemgrenze ist das System nicht f¨ ahig Zustands¨ anderungen der Umwelt wahrzunehmen. Auf der anderen Seite kann ein externer Beobachter keine Aussagen ¨ uber die interne Organisation des autopoietischen Systems treffen. Man bezeichnet dies als operative Geschlossenheit. Von Außen kann lediglich eine Betrach- tung der Input/Output Beziehung erfolgen. Welche internen Vorg¨ ange f¨ ur die Erzeugung eines Outputs bei einem bestimmten Input verantwortlich 10 Luhmann formulierte seine Systemtheorie f¨ ur die Soziologie mit dem Anspruch allge- meiner G¨ ultigkeit. Dadurch scheint seine Theorie dem Historizismus (vgl. 2.3 auf Seite 8) sehr nahe. Ob diese Kritik berechtigt ist, kann an dieser Stelle nicht beurteilt werden. 11 Hier ist die urspr¨ ungliche Kybernetik nach Wiener (vgl. Wie71) in den 40er und 50er Jahren gemeint und nicht die sp¨ ater etablierte Kybernetik h¨ oherer Ordnung z. B. nach von Foerster.

3 TRANSFORMATIONSPROZESS 18

sind, ist nicht analysierbar. Das System entspricht damit einer Blackbox 12 . Durch die operative Geschlossenheit und Selbstreferentialit¨ at autopoie- tischer Systeme ist eine gezielte Beeinflussung des Systems unm¨ oglich. Da die Umwelt den Zustand des autopoietischen Systems nicht erkennen kann, kann die Umwelt nicht beurteilen, wie das System auf einen Umweltein- fluss, eine St¨ orung, reagiert. Obwohl das System intern v¨ ollig determinis- tisch abl¨ auft, verh¨ alt es sich nach Außen (scheinbar) nicht-deterministisch. (Fl¨ a98, S. 169ff) Ein autopoietisches System kann deshalb als ” selbstorganisierend, selbst- erzeugend, selbsterhaltend und selbstreferentiell“ (vgl. Fl¨ a98, S. 163) 13 be- schrieben werden, obwohl mit der Kybernetik eine mechanische Sichtweise 14 die Basis bildete. Man spricht in der Autopoiesis von Selbstorganisation, da das autopoietische System spontan seinen eigenen Zustand an Randbedin- gungen (strukturelle Koppelung) anpassen kann.

Selbst die Autopoiesis nach Maturana steht unter Kritik, da das grund- legende biologische Experiment 15 niemals vollst¨ andig nachvollzogen werden konnte. Auch erscheint die M¨ oglichkeit von Selbstreferentialit¨ at bei gleichzei- tiger struktureller Koppelung als eine willk¨ urliche Festlegung. Dennoch hat die Autopoiesis im Bereich der Biologie und der Soziologie den Gedanken der Selbstorganisation etabliert. Eine Vielzahl von Managementpraktiken wurde von der Autopoiesis inspiriert. 16 Der Bezug zur Emergenz ergibt sich, wenn man betrachtet, dass in einem autopoietischen System durch Selbsterzeugung und Selbstreferenz eine Viel- zahl von Systemelementen organisiert werden und dabei in ihrer Gesamtheit h¨ ohere Eigenschaften hervorbringen. In der Theorie der Autopoiesis wird be- tont, dass in einem autopoietischen System neben den Systemelementen ei- ne systemspezifische Organisation herrscht. Dabei geht man davon aus, dass einzelne Systemelemente austauschbar sind, solange die spezifische Organi- sation erhalten bleibt. Darin zeigt sich, dass das Systemverhalten nicht auf das Verhalten der einzelnen Elemente zur¨ uckgef¨ uhrt wird, sondern dass ne- ben den Systemelementen eine spezifische Organisation entsteht, die f¨ ur das 12 Eine Blackbox bedeutet, dass die Analyse der im System ablaufenden Vorg¨ ange nicht m¨ oglich ist. Somit kann eine Untersuchung des Systems lediglich anhand der Eingaben und Ausgaben erfolgen.

13 Hervorhebungen durch Verfasser 14 zum mechanischen Weltbild siehe Kapitel 4.2 auf Seite 21 15 Maturana hat f¨ ur dieses Experiment Elektroden in die Ganglienzellen der Netzhaut von Tauben eingepflanzt. Er zeigte den Tauben unterschiedliche Farbtafeln. Es wurde erwartet, dass die unterschiedlichen Farben zu einer jeweils eigenen Stimulation der Gan- glienzellen f¨ uhren w¨ urden. Dem war aber nicht so. Daraus schloss Maturana in sp¨ ateren Arbeiten, dass das Nervensystem nicht von ¨ außeren Reizen gesteuert wird, sondern die- se Reize lediglich Ausl¨ oser von Ver¨ anderungen im Nervensystem sind. Diese Gedanken m¨ undeten letztendlich in der Autopoiesis.

16 Dies kann man durch die Suche nach den Begriffen Autopoiesis und Management im Internet nachvollziehen. In Kapitel 5.2 auf Seite 25 werden einige Anwendungen kurz vorgestellt.

3 TRANSFORMATIONSPROZESS 19

Systemverhalten genauso entscheidend ist. (Fl¨ a98, S. 173ff) Man kann des- halb davon ausgehen, dass autopoietische Systeme emergente Eigenschaften zeigen.

3.5 Zusammenfassende Vereinheitlichung

Die in diesem Abschnitt vorgestellten Theorien sind eine kleine Auswahl von verf¨ ugbaren Erkl¨ arungsmodellen f¨ ur Emergenz. Dennoch kann man bei allen Theorien Parallelen erkennen. Chaostheorie und Synergetik scheinen sehr nah verwandt, eine Zuordnung der Begriffe Ordner und Attraktor sowie Phasen¨ ubergang und Bifurkation erscheint prinzipiell m¨ oglich. Fl¨ amig (Fl¨ a98, S. 56ff) reduziert die Theorien auf Nicht-Linearit¨ at und Nicht-Determinismus. Die Nutzung des Begriffs Selbstorganisation lehnt er ab, (vgl. Fl¨ a98, S. 61) da durch eine zu breite Nutzung des Begriffs dieser an Aussagekraft verloren hat. (vgl. auch Kra96) Trotzdem wird in dieser Arbeit der Begriff Selbstorganisation weiterhin benutzt als begriffliche Zusammen- fassung f¨ ur Anpassung bzw. Struktur¨ anderung durch kollektive Effekte, da im Gegensatz zu den Begriffen Nicht-Linearit¨ at und Nicht-Determinismus der Begriff Selbstorganisation weniger abstrakt ist. Weiterhin erfolgt in die- ser Arbeit eine ¨ Ubernahme und Anwendung der von Fl¨ amig vorgeschlagenen Begriffe Nicht-Linearit¨ at und Nicht-Determinismus.

Unter Nicht-Linearit¨ at wird in dieser Arbeit verstanden, dass trotz in- tensiver Analyse (noch) keine schl¨ ussige Erkl¨ arung f¨ ur die Abfolge von Sys- temzust¨ anden gefunden werden kann. Das System scheint wahllos zwischen teils entgegengesetzten Systemzust¨ anden zu springen. Bereits kleinste ¨ An- derungen im Anfangszustand k¨ onnen vollkommen verschiedene Endzust¨ ande hervorrufen.

Unter Nicht-Determinismus wird verstanden, dass trotz genauester Mes- sung des Systemzustandes und der Kenntnis aller wirkenden Systemgesetze eine Vorhersage des Systemverhaltens ¨ uber einen l¨ angeren Zeitraum unm¨ og- lich ist. Die Kenntnis aller Einzelschritte zwischen Anfangszustand und Fol- gezustand reicht nicht aus, um die Transformation vollst¨ andig zu beschrei- ben.

Als Grund f¨ ur Nicht-Linearit¨ at wird die Vernetzung, und damit die Erm¨ oglichung von R¨ uckkoppelung, gesehen. Eine mathematische Beschrei- bung, z. B. mithilfe der Synergetik, f¨ uhrt zu nicht-linearen mathematischen Modellen. Der Nicht-Determinismus ist prinzipiell darauf zur¨ uckzuf¨ uhren, dass der Eintritt mancher Systemzust¨ ande auf Zufall beruht. Zufall ist per Definition nicht vorhersagbar und somit kein darauf aufbauendes System. In einem System, welches Nicht-Linearit¨ at und Nicht-Determinismus zu- l¨ asst, kann Selbstorganisation auftreten. Um Emergenz in der Softwareent- wicklung umsetzen zu k¨ onnen, muss Nicht-Linearit¨ at und Nicht-Determi- nismus in der Softwareentwicklung erm¨ oglicht werden. Dazu ist es sinnvoll zu untersuchen, wie bereits in anderen Bereichen diese Forderung umge-

3 TRANSFORMATIONSPROZESS 20

setzt wird, um dann die Anwendung im Bereich Softwareentwicklung ge- nauer studieren zu k¨ onnen. Da die Begriffe Nicht-Linearit¨ at und Nicht-De- terminismus so fundamental sind, wird zun¨ achst betrachtet, welches Bild bei einer aus nicht-linearen nicht-deterministischen Systemen zusammengesetz- ten Welt sich ergibt. Deshalb wird im n¨ achsten Abschnitt untersucht, wie es zur Entwicklung eines Weltbildes basierend auf Nicht-Linearit¨ at und Nicht- Determinismus kam.

4 GESCHICHTLICHE ENTWICKLUNG 21

4 Geschichtliche Entwicklung

4.1 Einleitung

Begriffe wie Chaostheorie, Synergetik, Autopoiesis, Selbstorganisation und Emergenz erfreuen sich heutzutage großer Beliebtheit. Allerdings haben sich diese Begriffe und die dahinter stehenden Ansichten erst in den letzten 50 bis 70 Jahren entwickelt. Dabei sprechen eine Vielzahl von Autoren (vgl. z. B. KK92; Fl¨ a98; Hei86; PJS94) von einer Abl¨ osung des mechanischen Weltbildes nach Newton. In diesem Abschnitt wird zuerst das mechanische Weltbild dargestellt und anschließend das sich neu entwickelnde Weltbild nachgezeichnet. Besondere Beachtung findet dabei die Entwicklung der fun- damentalen Begriffe Nicht-Linearit¨ at und Nicht-Determinismus. Abschließend findet eine Systematisierung statt, die die Aufgabenstel- lung dieser Arbeit anhand des bereits dargestellten Wissens pr¨ azisiert.

4.2 Mechanisches Weltbild

Mit seinem Werk ” Philosophiae naturalis principia mathematica“ legte Isaac Newton im Jahr 1687 den Grundstein des mechanischen Weltbildes. Aus den Keplerschen Gesetzen leitete er das Gravitationsgesetz ab, mit dem die theoretische Basis f¨ ur die Himmelsbewegungen gefunden war. Mit seiner Vereinheitlichung k¨ onnen die grundlegenden physikalischen Begriffe Masse, Impuls und Kraft beschrieben werden. Weiterhin ist die Beschreibung von Schwingungen durch dieses Werk m¨ oglich geworden.

Die Newton-Mechanik hat seitdem einen enormen Einfluss auf alle an- deren Wissenschaftsdisziplinen. Grundgedanke ist die Maschine, deren Ver- halten genau bestimmbar ist. Verf¨ ugt man ¨ uber die Kenntnis des genauen Zustandes der Maschine zu einem Zeitpunkt und den Regeln des Maschinen- verhaltens, kann daraus jeder Zustand in der Zukunft bzw. Vergangenheit bestimmt werden. Da sich die Bewegung der Planeten und Sterne mit der Newton-Mechanik genau beschreiben l¨ asst, erscheint es durchaus sinnvoll, die Gesetze auf den Mikrokosmos zu ¨ ubertragen und die Bewegung von Kernteilchen mit den Gesetzen der Mechanik zu beschreiben. Die Newton-Mechanik wurde auf viele Bereiche ¨ ubertragen. So stellte beispielsweise Julien Offray de La Mettrie in seinem Werk ” L’homme ma- chine“ den Menschen als eine Maschine dar. (vgl. PJS94, S. 3) 17 Diese Ab- straktion hat viele Erkenntnisse in der Medizin erm¨ oglicht, allerdings besteht dadurch auch die Gefahr einer Entmenschlichung der Medizin. Am Anfang des 20. Jahrhunderts entwickelte der amerikanische Inge- nieur und Unternehmer F. W. Taylor (vgl. Sta99, S. 23ff) eine Theorie zur Betriebsf¨ uhrung. Der so genannte Taylorismus sieht genaue Arbeitsbe- 17 Beitrag ” schneider

4 GESCHICHTLICHE ENTWICKLUNG 22

schreibungen und Zeitvorgaben f¨ ur die Verrichtung von Arbeitst¨ atigkeiten vor. Der Mensch wird in diesem Arbeitssystem zu einem ” Zahnrad“ in ei- ner riesigen Fertigungsmaschine. F¨ allt das ” Zahnrad“ aus, kann es durch einen anderen Menschen ersetzt werden. Dies f¨ uhrte zum Teil zu einer Ent- menschlichung der Arbeit, wie Fritz Lang in seinem Film ” Metropolis“ zeigt.

Andererseits erm¨ oglichten die klaren Aufgabenbeschreibungen, dass selbst ungelernte Kr¨ afte die T¨ atigkeiten ausf¨ uhren konnten. Weiterhin kann die Arbeit von Taylor als die Begr¨ undung der Arbeitswissenschaften angesehen werden.

Eine weitere Anwendung fand die Newton-Mechanik in der Kybernetik nach Wiener (vgl. Wie71). In der Kybernetik wird Systemverhalten unter- sucht und anhand von Regelkreisen mit positiver oder negativer R¨ uckkoppe- lung beschrieben. Die Kybernetik entwickelte sich zur Basis einer umfassen- den Steuerungstechnik und war letztlich eine Grundlage der entstehenden Rechentechnik nach dem zweiten Weltkrieg. Auch in der Kybernetik finden sich die Grundideen der Newton-Mechanik wieder. Ein System ist durch seinen Zustand und seine Ver¨ anderungsgesetze vollst¨ andig beschrieben und es kann prinzipiell das zuk¨ unftige Verhalten bei der Kenntnis des System vorhergesagt werden (Determinismus). Weiterhin f¨ uhren kleine ¨ Anderungen der Eingangswerte zu kleinen ¨ Anderungen der Ausgangswerte (Linearit¨ at), was eine gezielte Steuerung des Systems erm¨ oglicht.

4.3 Das neue Weltbild

W¨ ahrend das alte Weltbild konkret benannt werden kann, ist dies f¨ ur das neue Weltbild nicht m¨ oglich, da es sich noch in der Entstehung befindet. Eine Reihe von Entwicklungen haben zu einer ¨ Anderung der grundlegenden Ansichten gef¨ uhrt, es ist allerdings schwer den Ausl¨ oser auf eine einzelne Person oder eine einzelne Theorie zu reduzieren.

Bereits bei Kant finden sich Anzeichen des Selbstorganisationsgedanken. (vgl. KK92) So akzeptierte Kant durchaus die Idee, dass die Entstehung des Kosmos durch die Newton-Mechanik beschreibbar ist, f¨ ur die Entstehung von Leben hingegen konnte er dieser Idee nicht zustimmen. Im 19. Jahrhundert deutete sich z. B. bei den Arbeiten von Boltzmann und Maxwell an, dass die Newton-Mechanik nicht allgemeing¨ ultig war. Aller- dings wurde die Newton-Mechanik zu diesem Zeitpunkt noch nicht in Frage gestellt. (PJS94, S. 5) Albert Einstein gelang mit seiner Allgemeinen Relati- vit¨ atstheorie 18 am Anfang des 20. Jahrhunderts eine Darstellung der Begriffe Zeit und Raum. Weiterhin konnte durch die Allgemeinen Relativit¨ atstheorie die Newton-Mechanik auf den Makrokosmos ¨ ubertragen werden. Wiederum

18 Die Allgemeine Relativit¨ atstheorie kann als bewiesen betrachtet werden. So stellt sie z. B. die These auf, dass große Massen, wie die Sonne unseres Sonnensystems, Licht ab- lenken. Dies konnte mehrfach bei totalen Sonnenfinsternissen experimentell nachgewiesen werden.

4 GESCHICHTLICHE ENTWICKLUNG 23

schien die Newton-Mechanik prinzipiell best¨ atigt.

Max Planck legte im Jahr 1900 mit der Quantenhypothese 19 die Grund- lage der Quantentheorie. Nach der Quantenhypothese kann Energie nicht in beliebig kleine Mengen zerlegt werden. (Fl¨ a98, S. 90) Einige Jahre sp¨ ater bauten Nils Bohr und insbesondere Werner Heisenberg (Hei86) die Theorie weiter aus zur Quantenmechanik. Dabei formulierten sie die Unsch¨ arferela- tion, wonach Ort und Impuls eines Elementarteilchens niemals gleichzeitig genau bestimmt werden k¨ onnen. Die Unsch¨ arferelation konnte experimen- tell best¨ atigt werden. Wenn allerdings keine genaue Messung von Ort und Impuls m¨ oglich ist, kann der aktuelle Zustand eines Systems nicht umfas- send bestimmt werden. Von dieser unvollst¨ andigen Datenlage kann dann allerdings ebenfalls die Zukunft des Systems nicht genau vorherbestimmt werden. Hier zeigt sich deutlich die Abkehr von der Newton-Mechanik. Die- ses Problem l¨ asst sich z. B. am Zerfall radioaktiver Teilchen nachvollziehen. F¨ ur eine große Menge radioaktiven Materials kann eine Halbwertszeit f¨ ur den radioaktiven Zerfall angegeben werden. Es ist allerdings unm¨ oglich, ge- nau vorherzusagen, wann ein einzelnes radioaktives Teilchen zerfallen wird. Selbst Einstein akzeptierte die Vorstellung von Zufall als Basis der Quanten- mechanik nicht, was sich an seinem Ausspruch ” Gott w¨ urfelt nicht!“ zeigt.

Man kann sagen, Einstein relativierte die Begriffe Zeit und Raum, Heisen- berg ging einen Schritt weiter und relativierte den Begriff Kausalit¨ at (Ursa- che und Wirkung).

Eine Reihe von Wissenschaftlern suchte nach Gr¨ unden, warum sich die Welt zu stets komplexeren Ordnungen hin entwickelt, obwohl dies dem zwei- ten Hauptsatz der Thermodynamik widerspricht. W¨ urden lediglich die phy- sikalischen Naturgesetze wirken, w¨ urde im Laufe der Zeit jegliche Ener- gie und Materie im Universum verbraucht und das Universum w¨ urde dem W¨ armetod“ zusteuern. In diesem Zusammenhang entstanden dann ab den ” 60er Jahren die bereits vorgestellten Erkl¨ arungsmodelle f¨ ur Selbstorganisa- tion, wie Synergetik und Autopoiesis.

Das neue Weltbild befindet sich noch immer in der Entstehung und es ist noch nicht absehbar, wie es weitergestaltet wird. Dennoch finden die Ideen von Selbstorganisation, Nicht-Determinismus und Nicht-Linearit¨ at bereits heute ihre Anwendung, was im folgenden Kapitel genauer gezeigt wird. 19 Die Quantenhypothese besagt, dass Licht nicht in beliebig großen Energieportionen abgegeben werden kann, sondern dass die Energieportion immer ein ganzzahliges Viel- faches des Energiequants ist. Das Energiequant ist das Produkt von Lichtfrequenz und einer Naturkonstante (sp¨ ater als Plancksches Wirkungsquantum bezeichnet). Aufbauend auf dieser Hypothese entstand die Quantentheorie. Die Quantentheorie sagt aus, dass Vorg¨ ange in der Natur auf mikroskopischer Ebene (auf Ebene der Elementarteilchen) nicht kontinuierlich, sondern sprunghaft ablaufen. Weiterhin besagt die Quantentheorie, dass Vorg¨ ange nicht genau vorhersagbar sind, sondern lediglich eine Aussage ¨ uber die

Wahrscheinlichkeit des Eintretens bestimmter Ereignisse getroffen werden kann. Die Quan- tenmechanik untermauert dies und sagt, dass ¨ uber Ort, Impuls, Energie und Zeit eines Teilchens keine unendlich genauen Aussagen getroffen werden k¨ onnen.

4 GESCHICHTLICHE ENTWICKLUNG 24

4.4 Systematisierung

Nach der Akzeptanz des im vorherigen Unterabschnitt vorgestellten neuen Weltbildes ergibt sich die Aufgabenstellung, Mittel und Wege f¨ ur die Orien- tierung in dieser spontanen und nicht vorherbestimmbaren Welt zu finden. Dies ist die erste sich ergebende Aufgabenstellung – eine Reaktion auf das herrschende Weltbild und somit eine Bew¨ altigung von Nicht-Linearit¨ at und Nicht-Determinismus.

Neben der Reaktion gibt es die Aktion, also die bewusste Gestaltung eines dem Weltbild entsprechenden Systems. Man muss fragen, wie man ein emergentes System gestalten und nutzen kann. Es geht somit um die Erzeugung von Nicht-Linearit¨ at und Nicht-Determinismus zur L¨ osung von Problemen. Dies ist die zweite Fragestellung.

proaktiven“ 20 Die Kombination beider Fragestellung f¨ uhrt zu einem ” Ansatz. Dieser Ansatz liefert Mittel und Wege f¨ ur

1. die Bew¨ altigung der Anforderungen gestellt durch eine emergente Welt

2. und f¨ ur die Gestaltung einer emergenten Welt.

W¨ ahrend die Bew¨ altigung einer emergenten Welt lediglich eine notwendige Bedingung darstellt, ist die Gestaltung einer emergenten Welt eine Chance. Jeder, der in der emergenten Welt ” uberleben“ will, muss mit Emergenz um- ¨ gehen k¨ onnen. Aber derjenige, der selbst Emergenz erzeugen und gestalten kann, kontrolliert diese Welt. Ziel muss deshalb die Gestaltung und Nutzung von Emergenz sein.

Im nun folgenden Abschnitt wird untersucht, wie das neue Weltbild in der Wirtschaftsinformatik bewusst oder unbewusst zugrunde gelegt wird. Am Ende findet eine Zuordnung der einzelnen vorgestellten Verfahren und Theorien zu den beiden Kategorien Bew¨ altigung und Gestaltung statt. 20 Der Begriff proaktiv taucht sp¨ ater bei der Untersuchung von Agenten im Abschnitt 5.3.1 auf Seite 31 nochmals auf.

5 ANWENDUNG VON EMERGENZ 25

5 Anwendung von Emergenz

5.1 Einleitende Worte

In diesem Abschnitt wird gezeigt, wie bereits heute eine Anwendung von Emergenz in der Wirtschaftsinformatik stattfindet. Dabei wurden Anwen- dungen aufgenommen, die zumindest ein identifiziertes Merkmal (Nicht-Li- nearit¨ at, Nicht-Determinismus, Selbstorganisation) aufweisen. Der hier dar- gestellte ¨ Uberblick erhebt keinen Anspruch auf Vollst¨ andigkeit, sondern ver- mittelt lediglich ein Bild, wie Emergenz bereits praktisch umgesetzt wird.

5.2 Teilbereich Wirtschaft

5.2.1 Managementtheorien

In der Managementtheorie ist allgemein ein Wandel festzustellen. Es wird von einer ” steigenden Komplexit¨ at, Diskontinuit¨ at und Dynamik“ (Wei01, S. 255) als Kernmerkmale der neuen Unternehmensumwelt gesprochen, wo- bei die ¨ Uberlebensf¨ ahigkeit des Unternehmens von seiner permanenten F¨ a- higkeit zur Weiterentwicklung abh¨ angt, um sich der Umwelt anzupassen und diese aktiv zu gestalten. (vgl. Wei01, S. 255) Diese Sicht kann mit einer Bevorzugung des Konstruktivismus gegen¨ uber dem (kritischen) Rationalismus begr¨ undet werden. Der Rationalismus geht prinzipiell davon aus, dass es dem Menschen m¨ oglich ist, die Welt zu er- kennen und zwischen Wahrheit und Unwahrheit zu unterscheiden. Dar- aus k¨ onnen Theorien abgeleitet werden, die dann zu falsifizieren sind. (vgl. Wei01, S. 3ff) Der Konstruktivismus geht hingegen davon aus, dass jegliche Erkenntnis ¨ uber die Umwelt lediglich eine Konstruktion des Menschen ist – der Mensch konstruiert Wahrheiten. Eine objektive ¨ Uberpr¨ ufung von Wahr- heiten ist nicht m¨ oglich, da wir dazu die Umwelt, wahrgenommen ¨ uber die menschlichen Sinne, mit der Theorie vergleichen m¨ ussen. Es konnte in bio- logischen Experimenten 21 gezeigt werden, dass Wahrnehmungen stets einer Verarbeitung durch das menschliche Gehirn unterliegen und somit subjek- tiv gepr¨ agt sind. Aus diesem Grund l¨ asst sich keine objektive Wahrheit ableiten. (vgl. Wei01, S. 31ff) Trotzdem ist es nach Meinung der Konstruk- tivisten sinnvoll, Theorien aufzustellen. Eine Theorie ist dann von hoher Qualit¨ at, wenn sie sich in der praktischen Anwendung allgemein bew¨ ahrt. Das bedeutet aber auch, dass Theorien immer nur unter bestimmten Rand- bedingungen g¨ ultig sind und somit f¨ ur unterschiedliche Randbedingungen verschiedene Theorien existieren m¨ ussen. Dadurch entsteht eine Vielzahl von Theorien und die Existenz einer allgemeinen in jeder Situation g¨ ultigen Theorie wird verneint. Somit ist eine Vorhersage von Verhalten aufgrund einer Theorie nur unter engen Randbedingungen m¨ oglich, da schon leicht 21 Es gab eine Reihe von Experimenten, wie z. B. das in Kapitel 3.4 auf Seite 17 in einer Fußnote beschriebene Experiment von Maturana.

5 ANWENDUNG VON EMERGENZ 26

ge¨ anderte Randbedingungen eine eventuell neue Theorie erfordern (Nicht- Linearit¨ at).

F¨ ur die Praxis bedeutet dies, dass sich z. B. das Unternehmen st¨ andig auf eine wechselnde Umwelt einstellen muss, indem es fortw¨ ahrend seine Pro- zesse (seine internen Theorien) anpasst. Zur Bew¨ altigung dieses Problems kann die Theorie der lernenden Organisation genutzt werden. Der eigentli- che Lernprozess findet auf der Mikroebene statt. Die Mitarbeiter erkennen und bew¨ altigen Probleme w¨ ahrend der t¨ aglichen Arbeit. Aus der Sicht des Unternehmens ist nun sicherzustellen, dass diese neuen Erkenntnisse in das Wissen der Gesamtorganisation eingehen. Es sollen somit kleine ¨ Anderungen (Fluktuationen) im Wissen der Mitarbeiter zu einer Ver¨ anderung auf der Makroebene der Organisation f¨ uhren. ” Es ist nicht die Organisation, die bei der Betreuung von Projekten lernt. Vielmehr erweitern einzelne Mit- arbeiter (. . . ) ihren Wissensvorrat“. (Wei01, S. 255) Dies entspricht dem Gedanken der Emergenz. In diesem Zusammenhang kommt der Verwaltung des vorhandenen und gewonnenen Wissens im Rahmen des Wissensmanage- ment eine hohe Bedeutung zu. (vgl. GF03) Zahlreiche Autoren stellen dabei den Mitarbeiter als Wissenstr¨ ager in den Mittelpunkt ihrer Betrachtungen. (z. B. GF03, S. 167f) Indirekt vollzieht sich damit die Entwicklung hin zu ei- ner menschlicheren Arbeitsperspektive im Gegensatz zum Taylorismus. (vgl. Sta99, S. 23ff) Dabei wird das Individuum als entscheidender Erfolgsfaktor f¨ ur das Unternehmen begriffen.

Einen weiteren L¨ osungsvorschlag f¨ ur ein dynamisches und sich diskonti- nuierlich ver¨ anderndes Unternehmensumfeld ist das virtuelle Unternehmen. Ein virtuelles Unternehmen ist der lose Zusammenschluss von verschiede- nen Leistungserbringern, wobei f¨ ur den Kunden dieser Zusammenschluss als Einheit auftritt. Diese Zusammenschl¨ usse sind meist kurz- oder mittelfristig ausgelegt sowie inhaltlich begrenzt. Zwischen den Partnern des virtuellen Unternehmens besteht kein juristischer Zusammenschluss im Sinne einer ju- ristischen Gesellschaft. Dabei geht ein Unternehmen mit einer Vielzahl von anderen Unternehmen eine Kooperation ein, es entsteht ein virtuelles Un- ternehmensnetzwerk. Dem virtuellen Unternehmen ist es dadurch m¨ oglich, verschiedenste Kundenw¨ unsche durch R¨ uckgriff auf die Ressourcen im Un- ternehmensnetzwerk zu realisieren und somit im dynamischen Markt zu be- stehen. Auch hier steht wiederum die Vorstellung, dass durch ein Koope- rationsnetzwerk von Einzelindividuen eine Gesamtleistung hervorgebracht werden kann, die sich nicht auf die Einzelleistungen reduzieren l¨ asst. (vgl. z. B. Bul96, S. 52ff) Neben einer Vernetzung von externen Spezialanbietern im virtuellen Un- ternehmen, kann dieses Prinzip ebenfalls auf ein Unternehmen selber ange- wendet werden. Dazu bildet man im Unternehmen eine Vielzahl von Spe- zialteams mit großen Handlungsspielr¨ aumen, die jeweils auf wenige Aufga- benbereiche fokussieren. Zur Bew¨ altigung eines komplexen Problems werden mehrere Spezialteams miteinander vernetzt. Dieser Ansatz wird als fraktales

5 ANWENDUNG VON EMERGENZ 27

Unternehmen bezeichnet. (vgl. z. B. Bul96, S. 49ff) Der Begriff Fraktal steht dabei f¨ ur die Selbst¨ ahnlichkeit, ” d. h. jedes Bruchst¨ uck (Fraktal) eines Gan- zen enth¨ alt wiederum die Gesamtstruktur des Ganzen“. (Bul96, S. 49) 22 Dabei wird bewusst auf eine Selbstorganisation der Fraktale gesetzt (vgl. War02, S. 270ff), indem sich die einzelnen Fraktale zur L¨ osung des komple- xen Problems selbst¨ andig gruppieren sollen. (Bul96, S. 50) Ein weiteres Konzept, das Ende der 80er Jahre in Erscheinung trat (vgl. WJR94), ist die schlanke Produktion (Lean Production). Dieses Konzept wurde sp¨ ater zum schlanken Management (Lean Management) weiterent- wickelt. Die Urspr¨ unge liegen in der Untersuchung der weltweiten Automo- bilproduktion und den teilweise gravierenden Produktivit¨ atsunterschieden zwischen den einzelnen Produzenten. In der Untersuchung wurde festge- stellt, dass die japanischen Automobilhersteller wesentlich effizienter produ- zieren, indem sie sich von einer reinen Massenfertigung abgewandt haben. Tats¨ achlich fand eine Kombination aus Massenfertigung und Individualferti- gung statt, um die Vorz¨ uge beider Produktionsmethoden zu nutzen. Im Lean Production findet eine Verlagerung der Verantwortung hin zu denen statt, die die eigentliche Wertsch¨ opfung erbringen. In der Automobilproduktion sind dies die Techniker am Fließband bzw. den Fertigungsstationen. Damit diese Mitarbeiter ihrer Verantwortung gerecht werden k¨ onnen, findet ein aktiver Ausbau der Mitarbeiterf¨ ahigkeiten, z. B. durch Ausbildung, statt. Die Arbeit erfolgt in Teams. Innerhalb der Teams findet eine weitgehende Selbstorganisation in Hinblick auf die zu erledigende Arbeitsaufgabe statt. Zur Absicherung wird ein dichtes Netz aus Qualit¨ atskontrollen und ” proak- tiven Qualit¨ atszirkeln“ 23 gebildet. Die Teams arbeiten m¨ oglichst auf engem Raum, damit alle Teams Probleme bei anderen Teams bemerken und bei der L¨ osung aktiv unterst¨ utzen k¨ onnen. Weiterhin wird der Kunde partnerschaft- lich in den Produktionsprozess mit einbezogen. Erst auf seinen Auftrag hin findet die Fertigung statt. Das Management sorgt f¨ ur die n¨ otigen Rahmenbe- dingungen, es greift selten direkt ein. Die mittleren F¨ uhrungsebenen k¨ onnen wesentlich reduziert werden, da die Entscheidungen direkt auf den unteren Ebenen getroffen werden. Im Lean Production bzw. Lean Management wird somit versucht, Selbstorganisation zu initiieren und anzuwenden. Alle genannten neuen Betrachtungsweisen zur F¨ uhrung und Gestaltung eines Unternehmens k¨ onnen mit den Begriffen agil, antizipativ und adaptiv (nach Mil02, S. 9f) zusammengefasst werden. Dabei versteht man unter Agi- lit¨ at ” Schnelligkeit, Beweglichkeit und Flexibilit¨ at - f¨ ur kurze Reaktionszei- ten auch bei unerwarteten Hindernissen.“ (Mil02, S. 9) 24 Unter antizipativ wird das Erkennen der aktuellen Situation und deren wahrscheinliche Wei- terentwicklung verstanden. Dies bedeutet eine Abkehr von umfangreicher 22 Hervorhebungen im Original 23 In diesen Zirkeln versuchen die Mitarbeiter aus begangenen Fehlern zu lernen, aber auch zuk¨ unftige Fehler zu vermeiden.

24 Der Begriff Agilit¨ at wird im Kapitel 7.5 auf Seite 63 nochmals ausf¨ uhrlich aufgegriffen.

5 ANWENDUNG VON EMERGENZ 28

Planung hin zu einer Beurteilung der n¨ otigen Mittel anhand der aktuellen Situation. (vgl. Mil02, S. 10) Die mit dem Begriff adaptiv angesprochene Anpassungsf¨ ahigkeit des Un- ternehmens an eine sich ¨ andernde Umwelt, kann prinzipiell ¨ uber zwei Maß- nahmen erfolgen. Zum einen kann sich die interne Struktur des Unternehmen ¨ andern, eine ¨ Anderung nach Außen ist nicht sichtbar. Dem entgegengesetzt ist die ¨ Anderung der Schnittstellen des Unternehmen zur Umwelt unter Bei- behaltung der inneren Struktur des Unternehmens. Die Stabilit¨ at beider Bereiche w¨ ahrend einer Anpassung ist nicht m¨ oglich. Deshalb kann nur eine Anpassung durch die ¨ Anderung der inneren Struktur erfolgen, da das Unter- nehmen nach Außen stabile Schnittstellen anbieten sollte. Um eine st¨ andige Anpassung, beispielsweise realisiert ¨ uber die weiter oben diskutierte lernen- de Organisation, des Unternehmens zu erm¨ oglichen, bedarf es deshalb der Lernf¨ ahigkeit aber auch der Lernbereitschaft im Unternehmen. Zusammenfassend kann gesagt werden, dass eine Vielzahl von neuen Ide- en in der Managementlehre entstanden ist. Den meisten liegt eine Abkehr von dem mechanischen Weltbild nach Newton zugrunde, hin zu einer Sicht- weise zwischen Nicht-Linearit¨ at, Nicht-Determinismus und Selbstorganisa- tion. Dies ist im Ansatz Umsetzung von Emergenz.

5.2.2 Theorie steigender Ertr¨ age

Die Betriebswirtschaftslehre geht davon aus, dass ein Produzent im Laufe der Zeit mit sinkenden Ertr¨ agen rechnen muss. Dies wird begr¨ undet durch eine Zunahme der Konkurrenz auf dem Markt, den der Produzent bedient. Weiterhin bestehen nat¨ urliche Beschr¨ ankungen, wie Rohstoffe, Boden und die Anzahl der Kunden. Durch diese Randbedingungen soll es keinem Pro- duzenten m¨ oglich sein, sich langfristig in einem Markt festzusetzen und die- sen zu dominieren, da ein neuer Konkurrent ihm die Marktposition immer wieder streitig machen wird.

Die Realit¨ at zeigt, dass dies nicht immer so ist. In der Weltwirtschaft haben sich eine Reihe von Großkonzernen gebildet, die in bestimmten Teil- bereichen, wie z. B. bei Standardsoftwaresystemen, ein Quasi-Monopol in- nehaben.

Der amerikanische Wissenschaftler W. Brian Arthur entwickelte die The- orie der steigenden Ertr¨ age zur Kl¨ arung dieser Ph¨ anomene. (vgl. Art96) Er geht davon aus, dass im Bereich der Verarbeitung nichtmaterieller G¨ uter die Gesetze der sinkenden Ertr¨ age nicht zwangsl¨ aufig gelten. Er bezieht seine Theorie speziell auf die informationsverarbeitende Wirtschaft. Dazu z¨ ahlt nicht die Bewirtschaftung materieller G¨ uter und die Bereitstellung von Dienstleistungen. Erreicht ein Anbieter in solch einem Markt die Vorherr- schaft, kann diese nicht durch Konkurrenten einfach gebrochen werden. Aus der Vorherrschaft ergeben sich Vorteile, die die Marktposition des Anbieters sichern und weiter ausbauen. So kann der Anbieter z. B. eigene Standards

5 ANWENDUNG VON EMERGENZ 29

vorschreiben oder durch B¨ undelung von verschiedenen Produkten f¨ ur eine Migration der Kunden zwischen den Produkten sorgen. Weiterhin entstehen eine Vielzahl von kleinen Anbietern, die die zugrunde liegende Technologie des Marktf¨ uhrers st¨ utzen, da sie Synergieeffekte erwarten. Dadurch wird die vom Anbieter bereitgestellte Technologie attraktiver und zieht wieder- um mehr Kunden an. Es entsteht eine positive R¨ uckkoppelung im Sinne des Regelkreises. Durch die Beherrschung des Marktes durch den Anbieter kann er mit steigenden Ertr¨ agen rechnen, da im Bereich der Informations- wirtschaft die Produktionskosten meist gegen Null streben und somit durch jede zus¨ atzlich abgesetzte Einheit die Entwicklungskosten refinanziert wer- den k¨ onnen.

Arthur betont (Art96, S. 103f), dass die Marktbeherrschung des Anbie- ters durch neue Technologien gebrochen werden kann. Jeder Anbieter ist deshalb bestrebt, die n¨ achste Technologiewelle fr¨ uhzeitig zu identifizieren und m¨ oglichst zu besetzen. Allerdings hat der Marktf¨ uhrer den Vorteil, dass er einen entscheidenden Einfluss darauf hat, welche Technologie sich durch- setzen wird. Er kann die Technologie bei seinen Kunden einf¨ uhren und somit bereits f¨ ur eine breite Anwenderbasis sorgen, was den Erfolg der Technologie wesentlich erh¨ oht.

Als Beispiel f¨ uhrt Arthur (Art96, S. 102) die Entwicklung auf dem Markt der Computer Betriebssysteme in den 80er Jahren an. Zu dieser Zeit gab es drei konkurrierende Technologien (CP/M, MS DOS, Mac OS). Bekannter- maßen setzte sich MS DOS durch, da es von IBM als Betriebssystem f¨ ur den PC gew¨ ahlt wurde. Da die IBM-Plattform fr¨ uhzeitig einen großen Kunden- kreis erreichte und dadurch sehr attraktiv f¨ ur Entwickler wurde, konnte sich MS DOS durchsetzen, obwohl es technisch nicht die Beste der drei Tech- nologien war. Sp¨ ater nutzte Microsoft, der Hersteller von MS DOS, seine Marktmacht, um seine Kunden auf MS Windows und MS Office zu mi- grieren. Durch die riesigen Absatzmengen von MS DOS und sp¨ ateren Pro- dukten, konnte Microsoft seine Entwicklungskosten unter einer Vielzahl von Kunden aufteilen und das gewonnene Kapital zur Entwicklung und Durch- setzung weiterer Technologien nutzen.

Die Theorie der steigenden Ertr¨ age hat aus Sicht der Informatik einen besonderen Reiz. Sie beachtet die besonderen Eigenschaften des Produk- tes und Produktionsmittels Information. Dadurch erscheint sie ein besseres Erkl¨ arungsmodell zu liefern, als die ¨ Ubernahme von Theorien, die f¨ ur die Bewirtschaftung materieller G¨ uter mit materiellen Produktionsmitteln ent- worfen wurden.

Es f¨ allt nicht schwer, die Begriffe der Synergetik 25 auf die Theorie der steigenden Ertr¨ age anzuwenden. Die sich durchsetzende Technologie, und der zugeh¨ orige Anbieter, bilden einen ” Ordner“. Eine Vielzahl von Kunden wird ” versklavt“, diese und darauf aufbauende Technologien einzusetzen. 25 vgl. Kapitel 3.2 auf Seite 11

5 ANWENDUNG VON EMERGENZ 30

5.2.3 Markttheorie, Transaktionskostentheorie und Marktwirt-

schaft im Unternehmen

Seit den Anf¨ angen der freien Marktwirtschaft mit Adam Smith und John Locke hat sich das Konzept bis heute als einzig global g¨ angiges Vorgehen erwiesen. Dies zeigt z. B. der Niedergang der Planwirtschaft in vielen ehe- maligen sozialistischen Staaten. Allerdings existiert eine bunte Vielfalt von Umsetzungen der freien Marktwirtschaft. Das Spektrum reicht von sehr li- beralen Implementierungen wie in den USA oder Großbritannien bis hin zu st¨ arker geregelten Ans¨ atzen, wie die soziale Marktwirtschaft in Deutschland. Auf dem in der Marktwirtschaft beschriebenen Markt existieren eine Rei- he von Anbietern bestimmter Leistungen. Ihnen gegen¨ uber stehen die Nach- frager nach den Leistungen. Dabei geht die Lehre der freien Marktwirtschaft davon aus, dass eine unbegrenzte Nachfrage auf der Seite der Nachfrager existiert und somit Leistungen immer knapp sind. Aus dem Verh¨ altnis von Angebot und Nachfrage ergibt sich der konkrete Preis f¨ ur die Transaktion von Anbieter zu Nachfrager.

Prinzipiell findet keine Lenkung der Preisfindung von Außen statt. Die Preisfindung erfolgt selbstorganisiert durch die Individuen auf dem Markt. Allerdings muss jedes Individuum abw¨ agen, ob es eine Leistung vom An- bieter beziehen soll oder ob es die Leistung selber erbringt. Eine interne Erstellung einer Leistung erfolgt immer dann, wenn die Kosten f¨ ur Eigen- fertigung niedriger sind als die externen Beschaffungskosten. (vgl. Sta99, S. 420ff) Bei einer genaueren Betrachtung der externen Beschaffung ergibt sich, dass neben den Produktionskosten die Koordinationskosten 26 anfallen. Die Koordinationskosten beinhalten z. B. die Kosten, um sich auf dem frei- en Markt, aus der Sicht des Nachfragers, ¨ uber das Angebot zu informieren und den Vertrag mit dem Anbieter abzuschließen. (Sta99, S. 422) Bei einer Eigenfertigung treten neben den reinen Produktionskosten die Transakti- onskosten 27 auf. In den letzten Jahren konnten die externen Koordinati- onskosten beispielsweise durch den Einsatz des Internet (E-Commerce) und Standardsoftware entscheidend gesenkt werden, was zu einer Verlagerung von interner Produktion an externe Anbieter (Outsourcing) f¨ uhrte. Aller- dings wurde das Outsourcing am Anfang der 90er Jahre stark ¨ ubertrieben angewendet, so dass heute eine r¨ uckl¨ aufige Entwicklung zu beobachten ist. Durch die Eigenfertigung einer Leistung im Unternehmen werden die Marktmechanismen f¨ ur diese Leistung außer Kraft gesetzt. Im Unterneh- men selber findet kein Ausgleich zwischen Angebot und Nachfrage statt. In diesem Zusammenhang dr¨ angt sich die Frage auf, warum ganze Staatswirt- schaften ¨ uber Selbstorganisation gelenkt werden k¨ onnen, dies aber f¨ ur kleine- re Organisationen (die Unternehmen) nicht m¨ oglich sein soll? Eine m¨ ogliche 26 Der hier vorgestellte Transaktionskostenansatz geht auf Coase um 1937 zur¨ uck. Coase erhielt f¨ ur diese Arbeit 1991 den Nobelpreis.

27 genauer dazu online unter http://www.olev.de/t/transaktionskost.htm

5 ANWENDUNG VON EMERGENZ 31

Antwort kann lauten, dass im Unternehmen zu wenig Individuen vernetzt sind und sich somit keine Selbstorganisation einstellt. Trotzdem existiert ei- ne Reihe von Ans¨ atzen, die versuchen, Marktverhalten im Unternehmen zu etablieren. Ein erster Schritt in dieser Richtung ist das Profit-Center (vgl. Sta99, S. 743). Dabei werden einzelne Unternehmensbereiche als autonome eigenverantwortliche Einheiten gef¨ uhrt. Diese Idee kann bis zur Unterneh- mensholding und strategischen Netzwerken ausgebaut werden. Durch die Etablierung interner Kunden und der Nachbildung von Netzwerkstrukturen wird unter anderem versucht, Selbstorganisationseffekte zu stimulieren.

5.3 Teilbereich Informatik

5.3.1 Sozionik

Als erste Anwendung im Teilbereich Informatik wird die Sozionik vorge- stellt. Die Sozionik begreift sich als ” ein neues Forschungsfeld zwischen (Ver- teilter) K¨ unstlicher Intelligenz und Soziologie, in welchem die M¨ oglichkeiten eines wechselseitigen Konzepttransfers ausgelotet (. . . ) werden“. (Mal01) Die Sozionik wird im Rahmen eines Schwerpunktes 28 der Deutschen For- schungsgemeinschaft untersucht und betrachtet sich dabei selbst als Grund- lagenforschung.

Eine m¨ ogliche Umsetzung der Sozionik sind die Multi-Agenten-Systeme. Unter Agent versteht man ” ein l¨ angerfristig arbeitendes Programm, dessen Arbeit als eigenst¨ andiges Erledigen von Auftr¨ agen oder Verfolgen von Zie- len in Interaktion mit einer Umwelt beschrieben werden kann“. (vgl. G¨ or00, S. 949) Aus dieser Definition lassen sich einige Eigenschaften ableiten. (nach G¨ or00; Pit00) Agenten besitzen Autonomie, da sie ” keiner (unmittelbaren) Steuerung und Kontrolle durch einen Nutzer“ (G¨ or00, S. 949) unterliegen. Agenten kooperieren und kommunizieren mit anderen Agenten ” zur Kon- struktion kollektiver Probleml¨ osungsstrategien“. (Pit00, S. 19) 29 Diese Ei- genschaft wird als soziales Verhalten (G¨ or00, S. 950) bezeichnet. Agenten reagieren auf Ver¨ anderungen ihrer Umgebung, bezeichnet als Reaktivit¨ at. (G¨ or00, S. 949) Allerdings findet nicht nur eine passive Reaktion auf Um- welt¨ anderungen statt, sondern der Agent handelt aus eigenem Antrieb her- aus, was als Proaktivit¨ at (G¨ or00, S. 950) bezeichnet wird. Unter einem Multi-Agenten-System versteht man ” eine Menge von inter- agierenden Agenten“. (G¨ or00, S. 996) 30 Durch die Kooperation und Kom- munikation der einzelnen Agenten kann man davon ausgehen, dass diese ein kollektives Verhalten zeigen, das nicht auf die individuellen Eigenschaf- ten zur¨ uckgef¨ uhrt werden kann. Die Beobachtung von Emergenz ist somit m¨ oglich. Die Idee l¨ asst sich anhand von zellul¨ aren Automaten sehr gut nach- 29 Hervorhebungen durch Verfasser 30 Hervorhebungen durch Verfasser

5 ANWENDUNG VON EMERGENZ 32

vollziehen. 31 Zellul¨ are Automaten stellen das dynamische Verhalten dis- kreter Systeme dar. Zwischen den Einheiten findet keine Kommunikation oder Kooperation statt. Meist besitzen die Einheiten lediglich den Zustand an/aus. Der neue Zustand ergibt sich aus dem aktuellen Zustand und den ak- tuellen Zust¨ anden anderer Einheiten in der n¨ aheren Umgebung. Trotz dieser einfachen Architektur kann hoch komplexes Verhalten wie Schwarmverhal- ten (¨ ahnlich bei Zugv¨ ogeln) beobachtet werden. Eine leicht verst¨ andliche Einf¨ uhrung findet man bei Braitenberg (Bra93).

In der Sozionik werden Theorien aus der Soziologie ¨ ubernommen, die auf Selbstorganisation basieren. Deshalb zeigen die Ergebnisse, z. B. in Form der Multi-Agenten-Systeme, ebenfalls selbstorganisiertes Verhalten.

5.3.2 Organic Computing

Einen relativ aktuellen Ansatz stellt das Organic Computing dar. Es be- zieht sich haupts¨ achlich auf Hardware. Hauptziel des Organic Computing ist der organische Computer, definiert als ” ein selbstorganisierendes Sys- tem, das sich den jeweiligen Umgebungsbed¨ urfnissen dynamisch anpasst“. (GI03, S. 1) Ein organischer Computer muss ” selbst-konfigurierend, selbst- optimierend, selbst-heilend und selbst-sch¨ utzend“ (GI03, S. 1) sein. Als Anwendungsbereich wird z. B. das Automobil (Rad04) angef¨ uhrt. Man geht davon aus, dass die in einem Automobil integrierten Embedded Controller in ihrer Anzahl weiter zunehmen werden und immer wichtigere – teils lebenswichtige – Funktionen, wie Steuerung und Bremsen, ¨ uberneh- men. Da eine fehlerfreie Funktionsweise nicht garantiert werden kann, wird uber den Weg des Organic Computing versucht, eventuell lebensbedrohliche ¨ Situationen f¨ ur den Nutzer zu vermeiden.

Ein weiteres Beispiel (nach GI03, S. 2) ist die Smart Factory. Dabei bilden autonome Roboter spontane F¨ oderationen zur Erledigung anstehen- der Aufgaben. Beim Ausfall oder ¨ Uberlastung von Teilsystemen findet eine selbstorganisierte Neuverteilung der Aufgaben statt.

Die Vertreter des Organic Computing weisen darauf hin, dass die n¨ otige Software und Hardware flexibel und adaptiv sein muss. Wie bei der Sozionik wird nicht versucht die Planungs- und Koordinationsaufgaben zentral zu l¨ osen, sondern eine Vielzahl kleinerer hoch spezialisierter Einheiten sollen im Verbund die anstehenden Aufgaben selbstorganisiert bew¨ altigen.

5.3.3 Neuronale Netze

Eine weitere Anwendung, die hier betrachtet wird, sind die k¨ unstlichen neu- ronalen Netze. An dieser Stelle wird das Konzept kurz vorgestellt. (vgl. G¨ or00, S. 73ff) Im Zentrum steht eine Menge von k¨ unstlichen Neuronen, die 31 Unter http://llk.media.mit.edu/projects/emergence/index.html findet sich eine sehr sch¨ one grafische Darstellung.

5 ANWENDUNG VON EMERGENZ

Abbildung 5: Neuronales Netz

untereinander verbunden sind. Jedes Neuron besitzt eine Vielzahl von Ein- gangsleitungen, die gewichtet werden, d. h. jede Eingangsleitung hat einen unterschiedlich starken Einfluss auf das Neuron. Jedes Neuron ermittelt an- hand seiner Aktivierungsfunktion und den Eingangswerten seinen eigenen Zustand und gibt die entsprechende Information an seine Ausgangsleitung weiter. Diese Ausgangsleitung kann nun wiederum als Eingangsleitung f¨ ur verschiedene Neuronen dienen. Dadurch entsteht das in Abbildung 5 auf Seite 33 dargestellte Netz.

Einige Neuronen bilden die Eingangsschicht. ¨ Uber die Eingangsleitungen dieser Neuronen erfolgt die Eingabe. Weiterhin bilden einige Neuronen die Ausgangsschicht. ¨ Uber die Ausgangsleitungen dieser Neuronen erfolgt die vom neuronalen Netz ermittelte Ausgabe. In der einfachsten Architektur besteht ein neuronales Netz aus lediglich einem Neuron mit einer Vielzahl von Eingangsleitungen. Dieses neuronale Netz kann, da nur eine Ausgangs- leitung vorhanden ist, lediglich ja/nein Ergebnisse liefern. Dar¨ uber hinaus kann in solch einem neuronalen Netz keine XOR-Verkn¨ upfung abgebildet werden. Deshalb ist man wesentlich sp¨ ater zu mehrschichtigen neuronalen Netzen ¨ ubergegangen, wie in Abbildung 5 gezeigt. Zwischen Ein- und Aus- gabeschicht befindet sich eine Vielzahl von (versteckten) Schichten. Bevor ein neuronales Netz eine Aufgabe l¨ osen kann, muss es trainiert werden. Durch das Training werden die Gewichte an den Eingangsleitungen festgelegt. Bei einigen Varianten von neuronalen Netzen erfolgt weiterhin eine Festlegung des Schwellenwertes der Aktivierungsfunktion. Das neuro- nale Netz lernt anhand von Beispieldaten. Nach der Lernphase kann das neuronale Netz f¨ ur die eigentliche Aufgabe verwendet werden. Neuronale Netze sind eine sehr eindrucksvolle Anwendung von Emer- genz. W¨ ahrend der Trainingsphase findet eine Selbstorganisation der Netz-

5 ANWENDUNG VON EMERGENZ

Abbildung 6: Ablauf genetischer Algorithmus

struktur statt. Als Ergebnis k¨ onnen komplexe Aufgaben wie Muster- und Spracherkennung gel¨ ost werden. Ein interessanter Beitrag in diesem Zusam- menhang ist der synergetische Computer von Haken. (z. B. bei HW90) Er formuliert damit ein sehr ¨ ahnliches Vorgehen, allerdings geht Haken bei der Betrachtung von der Makroebene (Gesamtverhalten) und nicht vom einzel- nen Individuum (Neuronen) aus.

5.3.4 Genetische Algorithmen

Abschließend werden die genetischen Algorithmen vorgestellt. (z. B. nach GS02, S. 243ff) Den genetischen Algorithmen liegt die evolution¨ are Ent- wicklungstheorie nach Darwin als Modellvorstellung zugrunde. Es wird da- bei versucht, dass sich eine L¨ osung f¨ ur ein Problem mit der Zeit entwickelt und verbessert. Dazu werden am Anfang zuf¨ allig eine Reihe von L¨ osungen, die Individuen, ermittelt, die das Problem bereits l¨ osen (siehe dazu Abbil- dung 6 auf Seite 34). Es erfolgt eine Bewertung der einzelnen Individuen mithilfe der Fitnessfunktion. Aus den besten Individuen werden Nachfolger erzeugt, indem die Individuen Teile ihrer Gene an die Kinder vererben. Da- bei kommt z. B. die Kreuzung zum Einsatz. Um den Genpool der Individu- en aufzufrischen, werden spontane Mutationen zugelassen. Die entstandenen

5 ANWENDUNG VON EMERGENZ 35

Kinder werden wiederum bewertet. Damit beginnt der Prozess erneut und wird solange iterativ fortgesetzt, bis sich eine akzeptable L¨ osung ergibt. Von besonderem Interesse im Hinblick auf diese Arbeit ist, dass be- wusst der Zufall in Form von Mutationen genutzt wird, um eine L¨ osung zu erhalten. Weiterhin liegt bei den genetischen Algorithmen ein nicht- deterministisches Vorgehen vor. Es ist prinzipiell vorher nicht genau be- stimmbar, wie viel Generationen von Individuen ben¨ otigt werden, um eine akzeptable L¨ osung hervorzubringen und wie diese L¨ osung am Ende aussieht. Das Hauptproblem bei der Implementierung von genetischen Algorithmen besteht in einer effizienten Kodierung der L¨ osungen als Individuen. 32 Neben der Anwendung von genetischen Algorithmen bei Such- und Op- timierungsproblemen werden diese zur Bestimmung der Gewichte von neu- ronalen Netzen benutzt. An diesem Vorgehen kann man erkennen, dass in der Praxis oftmals mehrere Verfahren kombiniert werden, die auf Selbstor- ganisation, Nicht-Linearit¨ at und Nicht-Determinismus basieren.

5.4 Zuordnung zur Systematik

Wie bereits in Kapitel 4.4 auf Seite 24 angedeutet, wird nun versucht, die in diesem Kapitel vorgestellten Verfahren und Theorien zu systematisieren. Dabei erfolgt immer eine Zuordnung zu genau einer Kategorie, selbst wenn dies teilweise nicht immer eindeutig m¨ oglich ist.

Bew¨ altigung der Anforderungen einer emergenten Welt: Die ler- nende Organisation sowie das Wissensmanagement dienen der Bew¨ altigung einer sich st¨ andig ¨ andernden Welt. Es erfolgt somit eine Anpassung an die Welt, aber keine bewusste Gestaltung. Die Theorie steigender Ertr¨ age liefert ein Erkl¨ arungsmodell f¨ ur das Marktgeschehen einer emergenten Wirtschafts- welt. Aus dieser Theorie k¨ onnen konkrete Handlungsanweisungen abgeleitet werden, die eine Ausnutzung bewirken. In diesem Fall m¨ usste die Theorie in die zweite Kategorie, die Gestaltung einer emergenten Welt, eingeord- net werden. Das virtuelles Unternehmen ist ebenfalls ein Grenzg¨ anger. Es erm¨ oglicht gerade dem Mittelstand in einem sehr dynamischen Umfeld kom- plexe Leistungen zu erbringen und damit in der Wirtschaftswelt zu bestehen. Andererseits ist das virtuelle Unternehmen ein Gestaltungsmittel, mit dem Emergenz hervorgerufen werden kann.

Gestaltung einer emergenten Welt: Das fraktale Unternehmen, al- so die Nutzung von Marktmechanismen und kleinen autonomen Einheiten im Unternehmen, ist der Versuch, emergente Systeme zu schaffen. Es fin- det eine Vernetzung verschiedener relativ autonomer Individuen statt, zur 32 D. h., wie kann man die L¨ osung eines Problems als eine Kette von einzelnen Bits so kodieren, dass Selektion und Mutation sinnvoll angewendet werden k¨ onnen.

5 ANWENDUNG VON EMERGENZ 36

Erbringung einer gemeinsamen Gesamtleistung. Die freie Marktwirtschaft setzt dieses Prinzip auf der Makroebene um. Die konkretesten Gestaltungen emergenter Systeme sind die Sozionik , das Organic Computing, die neurona- len Netze und die genetischen Algorithmen. Hier findet sich eine vollst¨ andige Abkehr vom mechanischen Weltbild. Es wird versucht, Probleme durch Her- vorrufung von Nicht-Linearit¨ at und Nicht-Determinismus zu l¨ osen.

6 KLASSISCHE SOFTWAREENTWICKLUNG 37

6 Klassische Softwareentwicklung

6.1 Einleitung

Nach der Analyse von Emergenz und der Darstellung von Emergenzanwen- dungen in den vorherigen Abschnitten dieser Arbeit, wird in den folgen- den Kapiteln eine eventuell m¨ ogliche Anwendung von Emergenz im Bereich Softwareentwicklung untersucht. Dazu ist es sinnvoll, zun¨ achst die Softwa- reentwicklung allgemein zu charakterisieren. Darauf aufbauend wird darge- stellt, welche Grundannahmen und L¨ osungsvorschl¨ age bisher f¨ ur die Soft- wareentwicklung angewendet werden. Diese Darstellung erfolgt in diesem Kapitel kritiklos. Im folgenden Kapitel wird dann die agile Softwareentwick- lung n¨ aher untersucht. Dabei ist von Interesse, ob die agilen Methoden f¨ ur eine Umsetzung von Emergenz in der Softwareentwicklung sorgen k¨ onnen.

6.2 Softwareentwicklung allgemein

Software ist das Produkt des Softwareherstellers. (f¨ ur diesen Abschnitt vgl. z. B. ZBGK01, S. 17ff) An den Hersteller tritt ein Kunde heran bzw. der Hersteller spricht einen potenziellen Kunden an. Dabei spielt es im Rahmen dieser Arbeit keine Rolle, ob es sich um einen externen oder internen Kun- den handelt. Der Kunde hat ein konkretes Problem, dessen L¨ osung der Her- steller als Probleml¨ osung zu erarbeiten hat. Die Probleml¨ osung kann neben dem eigentlichen Softwareprodukt weiterhin Hardware und Dienstleistungen wie Beratung und Schulung umfassen. Der Hersteller muss das Problem des Kunden analysieren und eine m¨ ogliche L¨ osung beschreiben. Da es bis heu- te nicht m¨ oglich ist Software automatisiert in Serienfertigung herzustellen, muss die Softwareentwicklung als Einzelfertigung betrachtet werden. Selbst bei der Entwicklung von Standardsoftware wie B¨ urosoftware, Finanzsoftwa- re und Betriebssystemen ist die erstmalige Entwicklung dieser Software eine Einzelfertigung gegen¨ uber einem internen Kunden. F¨ ur die Bew¨ altigung der Einzelfertigung hat sich das Vorgehen im Rahmen eines Projektes als Ma- nagementform in vielen verschiedenen Disziplinen bew¨ ahrt. Deshalb wird Softwareentwicklung ebenfalls als Projekt durchgef¨ uhrt. Ein Projekt ist da- bei gekennzeichnet durch folgende Eigenschaften (nach ZBGK01, S. 27f):

1. einmaliges Vorhaben

2. zeitlich begrenzt

3. klare Ziele zu Beginn

4. neuartige und unbekannte Probleme werden gel¨ ost

5. unterschiedliche Methoden bei verschiedenen Projekten

6. Zusammenarbeit von Personen aus unterschiedlichen Fachgebieten

6 KLASSISCHE SOFTWAREENTWICKLUNG 38

7. besonderes Risiko (z. B. finanzielle Folgen beim Scheitern des Projektes

f¨ ur das Unternehmen)

8. eigenes Budget

Der in Eigenschaft 6 angesprochene Zusammenschluss wird als Projektteam bezeichnet. Jedem Mitarbeiter des Projektteams werden verschiedene Rollen zugeordnet, wie z. B. die Rolle des Projektleiters. Der Projektleiter vertritt das Projekt nach Außen und stellt somit die Schnittstelle zwischen Projekt und Kunde aber auch zwischen Projekt und Management des Herstellers dar. Damit der Projektleiter seiner Verantwortung gegen¨ uber Kunde und Management gerecht werden kann, erh¨ alt er im Projektteam eine Sonder- stellung, indem ihm Entscheidungsbefugnis zugeordnet wird. Je nach Gr¨ oße des Projektteams werden unterschiedliche Organisationsmodelle angewen- det.

Kunde und Management des Herstellers vereinbaren bei Vertragsab- schluss meist den Produktpreis, den Auslieferungstermin, den Funktions- umfang sowie die Qualit¨ atsanforderungen des Produktes. Damit f¨ ur den Hersteller das Projekt ein wirtschaftlicher Erfolg wird, muss der Projektlei- ter versuchen das Projekt unter Erf¨ ullung von Auslieferungstermin, Funkti- onsumfang und Qualit¨ at zu niedrigeren Kosten, als mit dem Produktpreis vereinbart, abzuschließen.

Um das Projekt erfolgreich durchf¨ uhren zu k¨ onnen, wird ein Softwareent- wicklungsprozess angewendet. Darunter versteht man ” die Summe aus einem Vorgehensmodell, den T¨ atigkeiten und Aktivit¨ aten sowie den angewandten Methoden.“ (ZBGK01, S. 25) Das Vorgehensmodell ” ist eine Beschreibung einer koordinierten Vorgehensweise bei der Abwicklung eines Vorhabens.“ (Ver02, S. 29) Dabei legt das Vorgehensmodell eine Reihe von Aktivit¨ aten fest sowie deren Input und Output (Artefakte). Weiterhin erfolgt eine ” feste Zuordnung von Rollen (. . . ), die die jeweilige Aktivit¨ at aus¨ uben.“ (Ver02, S. 29) Die Rollen, und somit die Verantwortung f¨ ur die Aktivit¨ aten, werden den einzelnen Mitgliedern des Projektteams zugeordnet. Es existiert eine Vielzahl von Vorgehensmodellen. Im n¨ achsten Abschnitt werden nun die ” klassischen“ Vorgehensmodelle und die dahinter liegende Metapher vorgestellt.

6.3 Vorgehensmodelle der Klassischen Softwareentwicklung

In der Softwareentwicklung sind eine Reihe von Vorgehensmodellen zur An- wendung gekommen. Diese entstanden oft aus der Erfahrung von Projekten und wurden dann allgemeing¨ ultig formuliert. Vereinfachend lassen sich drei Klassen von Vorgehensmodellen erkennen:

• ” Code and Fix“

• Wasserfallmodell und V-Modell

6 KLASSISCHE SOFTWAREENTWICKLUNG 39

• Iterativ inkrementelles und plangetriebenes (plan driven) Vorgehen

Die Aufz¨ ahlung erfolgte in chronologischer Reihenfolge der Entstehung. Es werden nun kurz die einzelnen Klassen beschrieben.

6.3.1 Vorgehensmodell ” Code and Fix“

Code and Fix“ steht f¨ ur ” Programmierung und Fehlerbehebung“, teilweise ” auch bekannt als ” Build-and-Fix“ Zyklus. Darunter wird ein v¨ ollig unstruk- turiertes Vorgehen verstanden. Entstanden ist dieses Vorgehensmodell in der Anfangszeit der Rechentechnik, als Software meist von einem einzigen Entwickler produziert wurde.

Der Entwickler beginnt direkt mit der Implementierung des Systems. Die Entwicklung wird solange fortgesetzt, bis das System den Vorstellungen des Programmierers entspricht. Fehler werden beim Auftreten durch den Pro- grammierer behoben. Dieser Ansatz ist unstrukturiert, es wird kaum Doku- mentation erstellt und Analyse und Entwurf werden ebenfalls fast komplett ausgespart. (vgl. ZBGK01, S. 45) Das Vorgehensmodell ” Code and Fix“ ist dann erfolgsversprechend, wenn Entwickler und sp¨ aterer Nutzer Rollen einer einzigen Person sind. Auch wenn dieses Vorgehensmodell durchaus qualitativ hochwertige Software hervorbringen kann, ist das Vorgehen in der professionellen Softwareentwicklung abzulehnen, da eine Wartung oder Wei- terentwicklung der Software meist nur durch den urspr¨ unglichen Entwickler m¨ oglich ist.

6.3.2 Vorgehensmodell Wasserfallmodell und V-Modell

Das Wasserfallmodell, und die in Deutschland Anfang der 90er Jahre erfolgte Weiterentwicklung hin zum V-Modell, versuchen den Software-Lebenszyklus umzusetzen. Der Software-Lebenszyklus wird definiert als Abfolge folgender Phasen:

1. Anforderungen

2. Analyse

3. Entwurf (Design)

4. Implementierung

5. Test

6. Inbetriebnahme

7. Wartung

6 KLASSISCHE SOFTWAREENTWICKLUNG

Abbildung 7: Wasserfallmodell

Treten neue oder ge¨ anderte Anforderungen an die Software auf, m¨ ussen diese in einem komplett neuen Zyklus umgesetzt werden. Dies ist ein sehr starres Vorgehen, welches wenig Flexibilit¨ at bietet. Kritisch wird dieses Vorgehen, wenn in einer Phase erkannt wird, dass die vorherige Phase unvollst¨ andige Ergebnisse geliefert hat. (vgl. ZBGK01, S. 45f) Im Wasserfallmodell ist deshalb eine R¨ uckkoppelung zur vorherigen Pha- se vorgesehen. Damit ergibt sich das klassische Bild wie in Abbildung 7 auf Seite 40 gezeigt. Das V-Modell wurde aus dem Wasserfallmodell abgelei- tet. Prinzipiell ist es sowohl zur Bearbeitung von Softwareprojekten aber auch f¨ ur die Bearbeitung anderer Projekte ausgelegt. Das V-Modell ent- stand im Bereich der R¨ ustungsindustrie und die Anwendung des V-Modell war zeitweise Voraussetzung bei der Vergabe von R¨ ustungsauftr¨ agen. Aller- dings wird das V-Modell heute nicht mehr weiterentwickelt. 33 Das V-Modell, an dieser Stelle wird nur das Submodell Systementwick- lung betrachtet, gliedert die Entwicklung in folgende sechs Phasen:

1. Analyse (der Anforderungen)

2. Systementwurf

3. Feinentwurf und Implementierung

4. Modultest

5. Systemintegration

6. Systemabnahme

Die Phasen 1 bis 3 stehen auf der linken Seite des imagin¨ aren Buchstabens V“, die Phasen 4 bis 6 auf der rechten Seite. Es ergibt sich das in Abbildung ”

8 auf Seite 41 gezeigte Bild. Phase 4 (Modultest) ¨ uberpr¨ uft das Artefakt der Phase 3 (Feinentwurf und Implementierung), Phase 5 (Systemintegration) 33 Die wohl aktuellste Variante steht auf der Seite http://www.cocoo.de/ zur Verf¨ ugung.

6 KLASSISCHE SOFTWAREENTWICKLUNG

Abbildung 8: Schichten des V-Modell

uberpr¨ uft das Artefakt der Phase 2 (Systementwurf) und Phase 6 (Sys- ¨ temabnahme) ¨ uberpr¨ uft das Artefakt der Phase 1 (Anforderungsanalyse). Sollte sich bei diesen ¨ Uberpr¨ ufungen eine Unstimmigkeit ergeben, muss zur uberpr¨ uften Phase zur¨ uckgekehrt werden. Bei einem gescheiterten Modul- ¨ test ist der R¨ uckschritt zu Phase 3 kein gr¨ oßeres Problem. Wird allerdings in Phase 6 bei der Abnahmepr¨ ufung festgestellt, dass die Anforderungen in Phase 1 unzureichend verstanden wurden, d¨ urfte dies in den meisten F¨ allen zum Projektabbruch und damit zum Scheitern des Projektes f¨ uhren. Es ist dabei zu beachten, dass in großen Projekten zwischen Analyse (Phase 1) und Systemabnahme (Phase 6) durchaus mehrere Jahre liegen k¨ onnen. Wasserfallmodell und V-Modell stellen einen entscheidenden Vorteil ge- gen¨ uber dem ” Code and Fix“ Vorgehen dar. Die klare Strukturierung in Phasen sowie die Festlegung der von den Phasen zu erzeugenden Outputs (Artefakte) sorgt z. B. f¨ ur eine Dokumentation des Vorgehens. Weiterhin ist eine Koordinierung mehrerer Entwickler und Projektanten m¨ oglich. Als Nachteil ist die mangelnde Flexibilit¨ at anzusehen. Auf ¨ andernde Anforde- rungen kann nur schlecht reagiert werden, was hohe Kosten verursacht. (vlg. ZBGK01, S. 47)

6.3.3 Iterativ inkrementelle und plangetriebene Vorgehensmo-

delle

Um den Hauptkritikpunkt einer unzureichenden Flexibilit¨ at von Wasser- fallmodell und V-Modell zu umgehen, wurde die iterativ inkrementelle Soft- wareentwicklung entwickelt. Diese wird h¨ aufig auch als evolution¨ are Soft- wareentwicklung bezeichnet. Das Spiralmodell (vgl. z. B. ZBGK01, S. 47ff) gilt als Vorl¨ aufer, da es zwar einen iterativen Ansatz umsetzt, aber nicht

6 KLASSISCHE SOFTWAREENTWICKLUNG 42

inkrementell vorgeht. Im Spiralmodell werden die folgenden vier Phasen bis zum Projektabschluss wiederholt:

1. Zielbestimmung f¨ ur diese Iteration

2. Risikoanalyse, m¨ ogliche Alternativen finden und bewerten

3. Ausf¨ uhrung der besten Alternative

4. Planung der n¨ achsten Iteration, Begutachtung (Review) der Ergebnis-

se dieser Iteration

Die Liste der Phasen verdeutlicht, dass es sich um ein wesentlich abstrakteres Vorgehensmodell handelt. Speziell die Phase 3 jeder Iteration kann stark unterschiedlich ausgepr¨ agt sein. Zur Durchf¨ uhrung der Phase 3 kann das V-Modell oder Wasserfallmodell verwendet werden.

Bei einer inkrementellen Softwareentwicklung erfolgt die Entwicklung der Software schrittweise. Der komplette Entwicklungszyklus wird dazu mehr- fach wiederholt (iterativ). Somit wird das Softwareprodukt w¨ ahrend der Ent- wicklung schrittweise umfangreicher. Der Gedanke der evolution¨ aren bzw. iterativ inkrementellen Softwareentwicklung wurde in einer Vielzahl von wei- teren Vorgehensmodellen umgesetzt. In diesem Zusammenhang sei z. B. der Rational Unified Process erw¨ ahnt. Heutzutage aktuell angewendete Vorge- hensmodelle, wie der Rational Unified Process, werden als plangetrieben (plan-driven) bezeichnet. Dies ist auf die umfangreichen Regelwerke dieser Vorgehensmodelle zur¨ uckzuf¨ uhren. Dabei wird vom Anwender des Vorge- hensmodells gefordert, dieses an die unternehmensspezifische Situation und Prozesse anzupassen. 34 Zur Umsetzung dieser Vorgehensmodelle stehen um- fangreiche Werkzeugsammlungen und Beratungsleistungen zur Verf¨ ugung. Aber auch die Anwendung dieser Vorgehensmodelle ist keine Garantie f¨ ur erfolgreiche Softwareprojekte.

Bevor im n¨ achsten Kapitel die Kritik an diesen Vorgehensmodellen aus der Sicht der agilen Softwareentwicklung genannt wird, erfolgt nun die Her- ausarbeitung der den hier vorgestellten Vorgehensmodellen zugrunde liegen- de Basismetapher.

6.4 Softwareentwicklung als Ingenieurdisziplin

Prinzipiell wird Software nach den klassischen Vorgehensmodellen in folgen- den sechs Phasen im Rahmen eines Projekts entwickelt:

1. Analyse

2. Entwurf (Design)

3. Implementierung

34 Innerhalb des Rational Unified Process wird dies als Tailoring bezeichnet.

6 KLASSISCHE SOFTWAREENTWICKLUNG

Abbildung 9: zeitliche Abh¨ angigkeit der Kosten f¨ ur ¨

4. Test

5. Inbetriebnahme

6. Wartung

W¨ ahrend im Wasserfallmodell und V-Modell diese Phasen mit kurzen R¨ uck- koppelungen im Idealfall nur einmal durchlaufen werden, erfolgt eine itera- tive Wiederholung der Phasen in der evolution¨ aren Softwareentwicklung. Entscheidend dabei ist, dass w¨ ahrend der Analyse m¨ oglichst alle Anforde- rungen an die zu entwickelnde Software erkannt werden. Sp¨ ater auftretende ¨ Anderungen k¨ onnen nach dem Entwurf der Software oft nur schlecht oder unter hohem Kostenaufwand ber¨ ucksichtigt werden. Aus dieser Darstellung ergibt sich die auf Barry Boehm (vgl. z. B. Col03) zur¨ uckgehende Kosten- kurve, wie in Abbildung 9 auf Seite 43 zu sehen. Diese zeigt, dass sp¨ ater auftretende Anforderungen wesentlich h¨ ohere Kosten (exponentieller An- stieg) verursachen, als fr¨ uhzeitig erkannte Anforderungen. Deshalb wird in der klassischen Softwareentwicklung der Schwerpunkt auf die Analyse ge- legt, um m¨ oglichst alle Anforderungen zu erkennen. Darin inbegriffen ist die These, dass die Softwarearchitektur nur schwer ¨ anderbar ist und somit nur unter hohen Kosten ¨ Anderungen der Anforderungen ber¨ ucksichtigt werden k¨ onnen.

Dieses Vorgehen findet sich in einer Reihe von Ingenieurdisziplinen wie- der. F¨ ur die Softwareentwicklung wird oftmals die Metapher des Hausbaus benutzt. Bevor mit dem eigentlichen Bau begonnen werden kann, muss zu- erst eine Architektur (Entwurf) anhand der Anforderungen der sp¨ ateren Be- wohner erarbeitet werden. Diese Architektur kann dann durch eine Baufirma

6 KLASSISCHE SOFTWAREENTWICKLUNG 44

realisiert werden. Sollten sich w¨ ahrend der Bauausf¨ uhrung ¨

Anderungen erge-

ben, k¨ onnen diese nur schwer ber¨ ucksichtigt werden, da gr¨ oßere ¨ eine ¨ Uberarbeitung der Architektur erfordern w¨ urden.

Die Baumetapher hat sich als sehr wertvoll f¨ ur die Softwareentwicklung erwiesen. Kein Architekt bzw. Konstrukteur entwickelt heute jedes Haus oder jede Br¨ ucke komplett neu. Vielmehr wird auf einen reichen Erfahrungs- schatz zur¨ uckgegriffen und bekannte Elemente werden kombiniert. In diesem Zusammenhang entstand der Gedanke wieder verwendbarer Softwarekom- ponenten. So k¨ onnen heute enorme Produktivit¨ atssteigerungen durch den Einsatz von Frameworks wie Microsoft .NET, Suns Java Klassen oder der Qt Bibliothek von Trolltech erreicht werden. Weiterhin wurde ein Katalog mit m¨ oglichen Software Architekturen und Entwurfsmustern erstellt. (vgl. Gam96) Als Vorbild f¨ ur die Entwurfsmuster werden die Architekturmuster des Architekturprofessors Christopher Alexander zitiert.

Jede Phase in der klassischen Softwareentwicklung erzeugt definierte Ar- tefakte. Diese Artefakte dokumentieren den kompletten Prozess und das Produkt. Anhand dieser Dokumentation kann das Projekt nachvollzogen und kontrolliert werden. Eine Einarbeitung eines neuen Mitarbeiters ist mit dieser Dokumentation m¨ oglich. Dar¨ uber hinaus dienen die bereits produ- zierten Artefakte als Arbeitsgrundlage der folgenden Phasen. Im Idealfall ben¨ otigt ein Mitarbeiter kein Vorwissen aus den vergangenen Phasen um seine Arbeit fortzusetzen. In der Endkonsequenz werden Mitarbeiter da- durch theoretisch leichter austauschbar. Dies f¨ uhrt zu einer Geringsch¨ atzung des Mitarbeiters und es wird somit eher in Werkzeuge und Prozesse als in Mitarbeiter und deren Qualifikation investiert.

Aufgrund der klar definierten Ergebnisse einer Phase kann objektiv ent- schieden werden, ob eine Phase in der Softwareentwicklung erfolgreich be- endet ist. Ein umfangreiches Controlling ist m¨ oglich. Es wurden eine Viel- zahl von Softwaremetriken zur Beurteilung der Qualit¨ at der produzierten Software, aber auch zur Beurteilung der Qualit¨ at des Projektes insgesamt, entwickelt. Diese Metriken unterst¨ utzen zuk¨ unftige Projekte z. B. bei Auf- wandssch¨ atzungen. Insgesamt gesehen findet eine st¨ andige Optimierung der Softwareentwicklung statt. Diese Optimierung ist notwendig, um die stetig komplexer werdenden Anforderungen bew¨ altigen zu k¨ onnen.

Weiterhin existiert die Tendenz eine m¨ oglichst hohe Automatisierung, z. B. im Rahmen der Model Driven Architectur 35 , w¨ ahrend der Software- 35 Im Rahmen der Model Driven Architectur wird die Gesch¨ aftslogik in einem platt- formunabh¨ angigen Modell (PIM) beschrieben. Dieses Modell kann in ein Modell f¨ ur eine konkrete Plattform (PSM) transformiert werden. F¨ ur diese Transformation m¨ ussen teils weitere Informationen dem Modell hinzugef¨ ugt werden, ansonsten erfolgt die Transfor- mation weitestgehend automatisiert. Diese Informationen k¨ onnen wiederum verwendet werden, falls das plattformunabh¨ angige Modell f¨ ur eine weitere Plattform transformiert werden soll. Die Modellierung der Gesch¨ aftslogik wird somit komplett von der Modellie- rung der tats¨ achlichen Anwendung getrennt. F¨ ur die Modellierung wird z. B. der Einsatz der Unified Modelling Language (UML) und entsprechender Modellierungswerkzeuge vor-

6 KLASSISCHE SOFTWAREENTWICKLUNG 45

entwicklung zu erreichen. Neben einer Kostenreduktion durch Einsparung von Mitarbeitern wird eine Qualit¨ atssteigerung angestrebt. Dazu sind ho- he Investitionen in Werkzeuge notwendig, vergleichbar dem Aufbau von vollst¨ andig automatisierten Fertigungsstraßen in der G¨ uterindustrie. Auch hier sind die Parallelen zu anderen Ingenieurdisziplinen unverkennbar. All diesen verschiedenen Auspr¨ agungen der klassischen Softwareentwick- lung liegen letztendlich zwei Grundannahmen zugrunde, die mit dem Begriff mechanisches Weltbild 36 nach Newton zusammengefasst werden k¨ onnen. Die zwei Grundannahmen lauten:

1. Determinismus

2. Linearit¨ at

Es wird jetzt gezeigt, worin sich diese Grundannahmen konkret manifestie- ren.

6.4.1 Determinismus in der klassischen Softwareentwicklung

Wendet man den Begriff Determinismus 37 auf die Softwareentwicklung an, dann geht man von einem prinzipiell genau vorherbestimmbaren Projekt- verlauf aus. Man spricht in diesem Zusammenhang von konzeptioneller Si- cherheit. Nur unter dieser Annahme ist eine Analyse sinnvoll durchf¨ uhrbar. Denn k¨ onnen die Anforderungen genau vorherbestimmt werden, dann kann das Risiko von sp¨ ater auftretenden Anforderungs¨ anderungen eliminiert wer- den. Somit ist eine Konzentration auf die stetige Verbesserung der Analyse sinnvoll.

Der Determinismus zeigt sich weiterhin im Projektmanagement der Soft- wareentwicklung. Es werden eine Reihe von Terminen festgelegt, zu de- nen ein bestimmter Funktionsumfang f¨ ur das Produkt erwartet wird. Die- se Punkte im Projektplan werden als Meilensteine bezeichnet. Eine solch genaue Planung ist nur m¨ oglich, wenn man davon ausgeht, dass sich die sorgf¨ altig erarbeiteten Pl¨ ane in die Realit¨ at umsetzen lassen und man somit die Zukunft durch Planung mit einer absch¨ atzbaren Erfolgswahrscheinlich- keit gestalten kann.

6.4.2 Linearit¨ at in der klassischen Softwareentwicklung

Wendet man den Begriff Linearit¨ at 38 auf die Softwareentwicklung an, dann f¨ uhren kleine Abweichungen vom Plan zu ¨ uberschaubaren Konsequenzen f¨ ur

geschlagen.

36 vgl. Kapitel 4.2 auf Seite 21 37 inhaltlich als Umkehrung der Definition in Kapitel 3.5 auf Seite 19 38 inhaltlich als Umkehrung der Definition in Kapitel 3.5 auf Seite 19

6 KLASSISCHE SOFTWAREENTWICKLUNG 46

das Gesamtprojekt. Linearit¨ at bildet ebenfalls die Grundlage f¨ ur die Pro- grammierung und Fehlerbehebung. Danach haben kleine ¨ Anderungen eben- falls keine großen Auswirkungen. Weiterhin liegt die Annahme von Linea- rit¨ at einer sp¨ aten Integration zugrunde. In der Softwareentwicklung wird die Integration der Teilsysteme erst meist kurz vor der Auslieferung bzw. Inbe- triebnahme durchgef¨ uhrt. Nichtlineare R¨ uckkoppelungseffekte werden dabei meist nicht betrachtet.

Wenn Linearit¨ at f¨ ur die Softwareentwicklung gilt, dann entwickeln sich ¨ ahnliche Projekte ¨ ahnlich. Man kann somit auf den Erfahrungen aus anderen Projekten aufbauen und diese Erfahrungen als Vorlage f¨ ur neue Projekte verwenden.

6.5 Zusammenfassung klassische Softwareentwicklung

Es konnte gezeigt werden, dass der klassischen Softwareentwicklung das me- chanische Weltbild zugrunde liegt. Eine Anwendung der Begriffe Linearit¨ at und Determinismus ist zwingend. Linearit¨ at und Determinismus verhindern allerdings das Auftreten von Emergenz und f¨ uhren somit nicht zu Selbstor- ganisation. Im nun folgendem Kapitel wird untersucht, ob die agile Softwa- reentwicklung Emergenz erm¨ oglichen kann.

7 AGILE SOFTWAREENTWICKLUNG 47

7 Agile Softwareentwicklung

7.1 Einleitung

In diesem Kapitel wird die agile Softwareentwicklung diskutiert. Dazu wer- den am Anfang zwei Vertreter (Extreme Programming und Methodikfamilie Crystal ) n¨ aher vorgestellt. Anschließend wird das Manifest der agilen Soft- wareentwicklung vorgestellt und der Begriff Agilit¨ at wird n¨ aher untersucht. Dabei wird das zugrunde liegende Weltbild identifiziert. Abschließend wird Emergent Design n¨ aher betrachtet und die vorgestellten agilen Verfahren werden in die Systematik eingeordnet.

7.2 Agiler Vertreter: Extreme Programming

7.2.1 Einleitung

Extreme Programming 39 ist der bekannteste agile Softwareentwicklungspro- zess. Auf den ersten Blick r¨ uckt Extreme Programming die eigentliche Imple- mentierung in den Mittelpunkt. Dadurch erscheint Extreme Programming f¨ ur viele Programmierer sehr interessant, da er den Programmierer von den oft als l¨ astig empfundenen Formalien wie Dokumentationserstellung befreit. Extreme Programming wirkt sehr radikal, da es mit einer Reihe von bishe- rigen Grundannahmen bricht. Dabei gibt Extreme Programming konkrete Handlungsanweisung zur Gestaltung der einzelnen Arbeitsschritte vor. Die Autoren 40 betonen, dass nur eine vollst¨ andige Umsetzung aller von Extreme Programming vorgegebenen Prinzipien zu einer erfolgreichen Anwendung von Extreme Programming f¨ uhren wird. (vgl. Bec00, S. 63) Extreme Pro- gramming ist es durch seine Popularit¨ at gelungen, die Aufmerksamkeit des Fachpublikums auf die agilen Methodiken zu lenken. Im Rahmen der agilen Softwareentwicklung wird in der Literatur von Methodiken anstatt Vorge- hensmodellen gesprochen. Eine Methodik ist danach eine begriffliche Zusam- menfassung f¨ ur Prozesse und Methoden. In dieser Arbeit wird Methodik als Synonym f¨ ur Vorgehensmodell verwendet. Im nun folgenden Abschnitt wird Extreme Programming umfassend dargestellt.

7.2.2 Grundwerte

Extreme Programming formuliert vier Grundwerte (vgl. Bec00, S. 29ff), aus denen die 12 Grundpraktiken abgeleitet werden. Die vier Grundwerte die- nen als Basis f¨ ur eine Unternehmenskultur, in der Extreme Programming erfolgreich umgesetzt werden kann. Die vier Grundwerte lauten:

• Kommunikation 39 Extreme Programming verf¨ ugt ¨ uber eine große Gemeinde von Anh¨ angern. Zahlreiche Internetseiten stellen die Thematik dar, wie z. B. http://www.extremeprogramming.org/. 40 haupts¨ achlich Kent Beck, Ward Cunningham und Ron Jeffries

7 AGILE SOFTWAREENTWICKLUNG 48

• Einfachheit

• R¨ uckmeldung (Feedback)

• Mut

Extreme Programming versucht durch eine Vielzahl von Praktiken die Kom- munikation zwischen Entwickler, Kunde und Management zu sichern. Kom- munikation wird als essentiell angesehen, damit ¨ uberhaupt eine Zusammen- arbeit gelingen kann. Dabei muss st¨ andig versucht werden, die Kommuni- kation aufrecht zu halten, denn Kommunikation ist st¨ oranf¨ allig. Damit die Kommunikation gew¨ ahrleistet werden kann, schl¨ agt Extreme Programming den Einsatz eines Coaches vor, der bei Kommunikationsst¨ orungen aktiv ein- greift.

Extreme Programming fordert Einfachheit. Es soll stets die einfachste L¨ osung f¨ ur ein Problem angestrebt werden. Ein Vorausdenken ¨ uber even- tuell zuk¨ unftig notwendige Programmdetails w¨ ahrend der Programmierung ist nicht erw¨ unscht, da Extreme Programming davon ausgeht, dass diese Vorwegnahme in vielen F¨ allen falsch ist und damit unn¨ otige Kosten verur- sacht. Durch st¨ andige Kommunikation erkennen die Entwickler die einfachs- te L¨ osung f¨ ur ein Problem. Weiterhin soll die Architektur m¨ oglichst einfach gestaltet werden, denn ” je einfacher ein System ist, desto weniger muss dar¨ uber mitgeteilt werden“. (Bec00, S. 31) Extreme Programming selbst lehnt komplexe Vorgehensmodelle wie den Rational Unified Process ab und fordert stattdessen ein einfaches Regelwerk. Diese Forderung wird auf Extre- me Programming selbst angewandt, weshalb die Darstellung der Prinzipien und Grundwerte von Extreme Programming auf wenigen Seiten m¨ oglich ist. Weiterhin fordert Extreme Programming Feedback. Feedback z. B. durch Tests soll dem Programmierer ¨ uber den aktuellen Systemzustand informie- ren. So k¨ onnen Defekte sofort erkannt und behoben werden. Weiterhin soll der Kunde ebenfalls ¨ uber den aktuellen Stand des Projektes informiert sein, damit er eingreifen kann. Auf der anderen Seite erh¨ alt der Kunde Feedback uber seine Anforderungen, inwieweit diese f¨ ur die Entwickler verst¨ andlich ¨ sind und mit welchem Aufwand f¨ ur die Umsetzung zu rechnen ist. Dem Kun- den wird fr¨ uhzeitig die Umsetzung seiner Anforderungen als laufendes Sys- tem vorgef¨ uhrt, damit er unmittelbar Feedback zur implementierten L¨ osung geben kann.

Mut bedarf es, um diese Grundwerte konsequent umzusetzen. Man wird bei der Umsetzung mit einer Reihe von Regeln der eigenen Organisation brechen m¨ ussen. So fordert Extreme Programming z. B. nicht funktionie- renden Code 41 zu verwerfen. Weiterhin muss zum Kunden eine ehrliche und 41 Unter dem Begriff Code wird in dieser Arbeit der Quelltext in einer Programmier- sprache sowie Datenbankskripte, Schnittstellenbeschreibungen f¨ ur Web Services usw. ver- standen.

7 AGILE SOFTWAREENTWICKLUNG

Abbildung 10: zeitliche Abh¨ angigkeit der Kosten f¨ ur ¨

vertrauensvolle Beziehung aufgebaut werden. Der Kunde ist davon zu un- terrichten, wenn w¨ ahrend der Entwicklung z. B. Verz¨ ogerungen auftreten. Dieses Vorgehen erfordert Mut.

Diese vier Grundwerte arbeiten zusammen und unterst¨ utzen sich ge- genseitig. Mit Sicherheit w¨ are es m¨ oglich, die Grundwerte mit anderen Be- griffen zu formulieren. Neben den Grundwerten existiert die These, dass sp¨ ate ¨ Anderungen der Anforderungen nicht wesentlich h¨ ohere Kosten verur- sachen, als fr¨ uhzeitig bekannte ¨ Anderungen. Diese These wird im folgenden Abschnitt dargestellt.

7.2.3 Umkehrung der Kostenkurve

Extreme Programming stellt die These auf, dass die Kostenkurve 42 nach Barry Boehm nicht (mehr) g¨ ultig ist. Durch den Einsatz von modernen Technologien und Programmierverfahren kann die Kostenkurve quasi um- gekehrt werden. (vgl. Bec00, S. 21ff) Es ergibt sich der in Abbildung 10 auf Seite 49 gezeigte Graph.

Die Schlussfolgerung aus dieser These lautet, dass eine st¨ andige ¨ Ande- rung der Software jederzeit m¨ oglich ist und prinzipiell Kosten auf ¨ ahnlichem Niveau verursacht. Deshalb m¨ ussen nicht alle Anforderungen vor Beginn des Entwurfs und der Implementierung feststehen. Es k¨ onnen jederzeit neue Anforderungen durch den Kunden aufgestellt werden, alte Anforderungen ge¨ andert werden oder noch nicht implementierte Anforderungen gestrichen werden.

42 siehe Kapitel 6.4 auf Seite 43

7 AGILE SOFTWAREENTWICKLUNG 50

Da jederzeit ¨

Anderungen an den Anforderungen ber¨ ucksichtigt werden k¨ onnen, fordert Extreme Programming den Kunden auf, Anforderungen im- mer dann zu ¨ andern, wenn die ¨ Anderung einen h¨ oheren Gesch¨ aftswert ver- spricht. Extreme Programming formuliert, dass dies zu einem v¨ ollig anderen Verhalten w¨ ahrend der Entwicklung f¨ uhrt. Es gilt ” wichtige Entscheidungen so sp¨ at wie m¨ oglich im Entwicklungsprozess [zu] 43 treffen, um die Kosten aufzuschieben, die durch diese Entscheidungen bedingt sind, und um die Wahrscheinlichkeit zu erh¨ ohen, dass die richtigen Entscheidungen getroffen werden.“ (Bec00, S. 23) Dabei geht es nicht darum, sich um Entscheidun- gen zu dr¨ ucken. Der Teilsatz ” so sp¨ at wie m¨ oglich“ umfasst auch, dass die Entscheidung nicht zu sp¨ at gef¨ allt werden darf. Extreme Programming stellt eine Reihe von Techniken zur Verf¨ ugung um abzusichern, dass die These von ¨ anderbarer Software tats¨ achlich erf¨ ullt werden kann.

Durch die Softwarearchitektur, erarbeitet w¨ ahrend des Entwurfs, wird die zu entwickelnde Software strukturiert und geordnet. Eine nachtr¨ agliche ¨ Anderung kann diese Ordnung zerst¨ oren, wenn die ¨ Anderung sich mit der Softwarearchitektur nicht vollst¨ andig erf¨ ullen l¨ asst. Durch jede ¨ Anderung wird somit die interne Struktur der Software ungeordneter. Nur durch die bewusste Zuf¨ uhrung von Aufwand kann das Streben zur Unordnung verhin- dert werden. Extreme Programming beschreibt, welche Maßnahmen konkret ergriffen werden m¨ ussen.

7.2.4 Die 12 Grundpraktiken

Aufbauend auf den vier Grundwerten definiert Extreme Programming 12 Grundpraktiken (vgl. Bec00, S. 53ff), die alle umgesetzt werden m¨ ussen. Die Grundpraktiken sind sehr konkret im Vergleich zu anderen Vorgehensmodel- len. Beck (vgl. Bec00) betont mehrfach, dass die Grundpraktiken bereits seit vielen Jahren bekannt sind. Allerdings ist die Kombination und konsequente (extreme) Anwendung einmalig. Die 12 Grundpraktiken lauten:

• Versionsplanung

• Kurze Releasezyklen

• Metapher f¨ ur das System

• Einfaches Design

• Testen

• Refaktorisierung

• Programmieren in Paaren 43 Anmerkung des Verfassers

7 AGILE SOFTWAREENTWICKLUNG 51

• Gemeinsame Verantwortlichkeit

• Fortlaufende Integration

• 40-Stunden-Woche

• Kunde vor Ort

• Programmierstandards

Es werden nun die einzelnen Grundpraktiken n¨ aher erl¨ autert. Dies erfolgt in einer anderen Reihenfolge als sonst in der Extreme Programming Literatur ublich, da so leichter Zusammenh¨ ange verdeutlicht werden k¨ onnen. ¨

Kurze Releasezyklen: Damit der Kunde m¨ oglichst schnell realisierte Funktionen einsetzen kann, werden kurze Releasezyklen angestrebt. Da- bei wird von ein bis zwei Monaten als Richtwert f¨ ur die Zyklusl¨ ange im Rahmen von Extreme Programming ausgegangen. Ein Release soll dabei sinnvoll sein, d. h. es k¨ onnen mit dem Release ein bestimmter Teil der Gesch¨ aftsanforderungen vollst¨ andig erf¨ ullt werden. Mit sp¨ ateren Releases steigt somit der Teil der erf¨ ullten Gesch¨ aftsanforderungen. Dabei sind immer zuerst die Gesch¨ aftsanforderungen zu erf¨ ullen, die dem Kunden den gr¨ oßten wirtschaftlichen Wert versprechen. Die Priorit¨ at der Gesch¨ aftsanforderungen legt der Kunde mit Unterst¨ utzung der Entwickler fest.

Versionsplanung: Gesch¨ aftsanforderungen werden als so genannte Ge- schichten durch den Kunden formuliert. Die Formulierung erfolgt w¨ ahrend der Versionsplanung. Man findet f¨ ur den Begriff Versionsplanung noch die Bezeichnungen Planungsspiel und Releaseplanung. Das Ergebnis der Versi- onsplanung ist der Versionsplan. Der Versionsplan legt die Zeitpunkte der einzelnen Versionen (Releases) fest. Weiterhin beschreibt der Versionsplan grob, welche Geschichten f¨ ur die einzelnen Versionen erf¨ ullt sein m¨ ussen. Da der Kunde jederzeit seine Anforderungen ¨ andern darf, muss eine Versions- planung bei gr¨ oßeren ¨ Anderungen der Anforderungen erneut durchgef¨ uhrt werden. Auf den Prozess der Versionsplanung und Anforderungsverwaltung wird im Abschnitt 7.2.5 auf Seite 55 genauer eingegangen.

Metapher f¨ ur das System: In Extreme Programming findet keine ex- plizite Phase zur Planung der Softwarearchitektur statt. Trotzdem wird ei- ne Metapher f¨ ur das zu entwickelnde System gesucht. Diese Metapher soll zur besseren Kommunikation zwischen Entwickler und Kunde dienen. Wei- terhin unterst¨ utzt die Systemmetapher die Entwicklung. Es werden z. B. Klassen entsprechend der Metapher benannt. Wahrscheinlich wurde der Be- griff Metapher gew¨ ahlt, um sich gegen den Begriff Architektur abzugrenzen.

7 AGILE SOFTWAREENTWICKLUNG 52

Die Metapher ist eine abstrakte Beschreibung der Architektur. Sie soll al- len Beteiligten ” ein schl¨ ussiges Modell zur Verf¨ ugung (. . . ) stellen, mit dem sie arbeiten k¨ onnen und das sowohl f¨ ur die Gesch¨ aftsleute als auch f¨ ur die Techniker brauchbar ist.“ (Bec00, S. 56)

Testen: Der Kunde formuliert die Geschichten w¨ ahrend der Versionspla- nung und sp¨ ater bei Bedarf. Die Geschichten bilden die Anforderungen an das zu entwickelnde System. Zur ¨ Uberpr¨ ufung, ob das System eine konkrete Anforderung erf¨ ullt, muss der Kunde entsprechende Tests formulieren. Dies kann mit der Unterst¨ utzung der Entwickler geschehen. Diese Funktionstests sind das Pr¨ ufkriterium f¨ ur die Erf¨ ullung der einzelnen Geschichten. Neben diesen Funktionstests existieren die Komponententests. Diese tes- ten einzelne Klassen oder Methoden im Sinne eines Blackbox-Tests 44 . Die Komponententests werden von den Entwicklern erstellt, bevor sie mit der Programmierung der Klasse oder Methoden beginnen. Diese Herangehens- weise wird in der Softwareentwicklung als test-driven (durch Test getrieben) bezeichnet. Dabei ist wichtig, dass die Tests vor der Programmierung ge- schrieben werden. Weiterhin sollte ein Werkzeug f¨ ur die Verwaltung der Tests genutzt werden. Idealerweise f¨ uhrt dieses Werkzeug bei Bedarf eine Pr¨ ufung aller Tests vollautomatisch aus und gibt dem Entwickler damit ei- ne konkrete R¨ uckmeldung, ob alle Tests erf¨ ullt sind. Die Tests geben dem Entwickler somit eine unmittelbare R¨ uckmeldung, ob seine durchgef¨ uhrten ¨ Anderungen unbeabsichtigte Auswirkungen haben.

Das vollautomatische Testen nach jeder Codeintegration stellt ein Mittel zur Verf¨ ugung, um die ¨ Anderbarkeit der Software zu garantieren.

Einfaches Design: Der Grundwert Einfachheit fordert, dass stets die ein- fachste L¨ osung umgesetzt werden soll. Ein einfaches Design zeichnet sich durch folgende vier Eigenschaften aus (vgl. Bec00, S. 57):

1. Es besteht alle Tests.

2. Es enth¨ alt keine Redundanzen.

3. Es setzt die Metapher um.

4. Es besteht aus der geringst m¨ oglichen Anzahl von Klassen und Me-

thoden.

Das Design darf die Realisierung zuk¨ unftiger Anforderungen nicht vorweg- nehmen, da nicht vorhergesagt werden kann, ob diese zuk¨ unftigen Anfor- derungen tats¨ achlich umgesetzt werden m¨ ussen. Der Kunde k¨ onnte z. B. 44 Im Blackbox-Test von Klassen werden lediglich die Schnittstellen getestet. Dazu wird von der Klasse eine bestimmte Ausgabe erwartet, wenn eine bestimmte Eingabe erfolgt. Stimmt die tats¨ achliche Ausgabe nicht mit der erwarteten Ausgabe ¨ uberein, dann ist der Test gescheitert.

7 AGILE SOFTWAREENTWICKLUNG 53

eine der bereits ber¨ ucksichtigten Anforderungen komplett streichen. Der bis dahin vorweggenommene Entwicklungsaufwand ist dann umsonst und hat unn¨ otige Kosten verursacht.

Es ist zu beachten, dass es keinen expliziten Entwurfsschritt in Extre- me Programming gibt. Tats¨ achlich legt das Schreiben von Tests vor der Programmierung das Design der zu programmierenden Klassen bzw. Me- thoden fest. Ein Test wird stets ¨ uber die von der Klasse oder Methode zur Verf¨ ugung gestellte Schnittstelle durchgef¨ uhrt. Die Beschreibung dieser Schnittstelle stellt somit den eigentlichen Entwurf der Klasse dar.

Refaktorisierung Jede ¨

Anderung am Code kann einen Teil der inne- ren Struktur zerst¨ oren. Mit dem st¨ andigen ¨ Uberarbeiten wird dem ent- gegengewirkt. Bei dieser ¨ Uberarbeitung darf die Funktionalit¨ at des Sys- tems nicht ge¨ andert werden. Um dies zu sichern, muss das System mit den Komponenten- und Funktionstest nach der Refaktorisierung gepr¨ uft wer- eine ¨ den. Refaktorisierung l¨ asst sich somit definieren als ” Anderung an der internen Struktur einer Software, um sie leichter verst¨ andlich zu machen und einfacher zu ver¨ andern, ohne ihr beobachtbares Verhalten zu ¨ andern.“ (Fow00, S. 41) Die Refaktorisierung muss immer dann durch die Entwickler ausgef¨ uhrt werden, wenn durch eine ¨ Anderung das aktuelle Design, und damit die in- nere Struktur des Systems, verschlechtert wird. Mit Refaktorisierung wird die Grundlage f¨ ur ¨ anderbare Software geschaffen. Durch Refaktorisierung k¨ onnen im wesentlichen folgende drei Ergebnisse erzielt werden (vgl. Fow00, S. 43ff):

1. Verbesserung des Design, hinsichtlich der oben genannten vier Krite-

rien f¨ ur einfaches Design

2. Leichtere Verst¨ andlichkeit der Software

3. Erkennung von Fehlern

Programmieren in Paaren: Die Programmierung erfolgt in Extreme Programming paarweise. Jeder Code, der in eine Version (Release) eingeht, muss durch ein Paar erstellt werden, ansonsten muss der Code verworfen werden. Bei der Programmierung in Paaren sitzen zwei Mitarbeiter gemein- sam vor einem Rechner. Ein Mitarbeiter bedient den Rechner, indem er z. B. den Code eingibt. Der zweite Mitarbeiter ¨ uberpr¨ uft zum einen den Co- de, analysiert auf der anderen Seite aber auch m¨ ogliche Auswirkungen der aktuellen ¨ Anderungen. Die beiden Mitarbeiter k¨ onnen jederzeit ihre Rolle tauschen. Die Paarbildung erfolgt durch die Mitarbeiter. Paare sollten nach der Fertigstellung einer Aufgabe gewechselt werden. Es findet somit eine st¨ andige Fluktuation statt.

7 AGILE SOFTWAREENTWICKLUNG 54

Das Programmieren in Paaren verfolgt mehrere Anliegen. So soll die Kommunikation zwischen den einzelnen Teammitgliedern gef¨ ordert werden. Weiterhin erh¨ oht die Programmierung in Paaren die Qualit¨ at des produzier- ten Codes wesentlich. Durch den st¨ andigen Austausch zwischen den Entwick- lern wird ein Lernen w¨ ahrend der Arbeitst¨ atigkeit erm¨ oglicht. Ein weiterer Effekt des Programmieren in Paaren ist, dass alle Mitarbeiter grob den ge- samten Code kennen. Dadurch wird verhindert, dass bestimmte Codeberei- che nur von einzelnen Mitarbeitern verstanden werden und deren Ausfall, z. B. bei Krankheit aber auch bei K¨ undigung, die Wartung bzw. ¨ Anderung dieser Codebereiche unm¨ oglich macht. Abschließend f¨ uhrt die Programmie- rung in Paaren zu einer gegenseitigen Kontrolle sowohl inhaltlich als auch organisatorisch. Die Mitarbeiter unterlassen deshalb teilweise unproduktive T¨ atigkeiten wie w¨ ahrend der Arbeitszeit im Internet zu surfen.

Fortlaufende Integration: Sobald ein Programmierpaar eine Aufgabe umgesetzt hat, muss es die Testf¨ alle sowie die ¨ Anderungen am Code in die zentrale Codeverwaltung (Repository 45 ) einspielen. Danach wird das Pro- gramm erneut ¨ ubersetzt (kompiliert) und alle Tests werden ausgef¨ uhrt. Erst wenn alle Tests vollst¨ andig bestanden sind, ist die Integration abgeschlos- sen und das n¨ achste Programmierpaar darf mit der Integration beginnen. Sollte es dem Programmierpaar nicht gelingen, alle Tests zu erf¨ ullen, muss es den Code wegwerfen und von vorne beginnen. Extreme Programming schl¨ agt vor, dass nur ein Integrationsrechner zur Verf¨ ugung steht. Nicht in- tegrierter Code muss am Ende des Arbeitstages verworfen werden. Durch die fortlaufende Integration soll erreicht werden, dass jederzeit eine ausliefer- bare Version zur Verf¨ ugung steht, die der Kunde testen kann. Als Werkzeug bietet sich hier der Einsatz einer Versionsverwaltung an.

Gemeinsame Verantwortlichkeit: In Extreme Programming gibt es keinen Besitz bestimmter Codebereiche. Jeder Entwickler darf an allen Stel- len im Code ¨ andern. Gleichzeitig ist jeder Entwickler f¨ ur die Qualit¨ at des gesamten Codes verantwortlich. Entdeckt er in einem Bereich Schw¨ achen, muss er diese mittels Refaktorisierung ¨ uberarbeiten.

Programmierstandards: Damit eine gemeinsame Verantwortlichkeit re- alisiert werden kann, m¨ ussen sich die Entwickler auf gemeinsame Program- mierstandards einigen. Dadurch wird eine gemeinsame Kommunikationsba- sis geschaffen. Weiterhin soll dies verhindern, dass die Programmierer die Formatierung des Codes ¨ andern, wenn sie an einem Bereich arbeiten. 45 In solch einem System werden die unterschiedlichen Versionen des Codes verwaltet. Dabei k¨ onnen mehrere Versionen einer Datei parallel, z. B. f¨ ur unterschiedliche Kundenver- sionen, verwaltet werden. Weiterhin kann nachvollzogen werden, wer welche ¨ Anderungen wann am Code durchgef¨ uhrt hat.

7 AGILE SOFTWAREENTWICKLUNG

Abbildung 11: globaler Ablauf eines Extreme Programming Projektes (nach

Wel99)

Kunde vor Ort: Der Kunde nimmt in Extreme Programming eine zen-

trale Rolle ein. Der Kunde wird als positiv wirkender Partner angesehen.

Dabei hat der Kunde zum einen die Rolle des Auftraggebers und zum ande-

ren die Rolle des zuk¨ unftigen Nutzers zu erf¨ ullen. Damit der Kunde jederzeit

f¨ ur R¨ uckfragen bei Problemen, Streitpunkten und f¨ ur die Setzung von Prio-

rit¨ aten zur Verf¨ ugung steht, muss er sich m¨ oglichst im gleichen Raum wie

die Entwickler befinden. Der Kunde wird dabei meist von einem zuk¨ unftigen

Nutzer der Software vertreten. Diese Person muss ¨ uber Entscheidungsbefug-

niss verf¨ ugen, damit er die oben genannten Punkte verbindlich kl¨ aren kann.

40-Stunden-Woche: Extreme Programming legt Wert auf einen vern¨ unf-

tigen Umgang mit den Mitarbeitern. Diese sollen keine geplanten ¨ Uberstun-

den leisten. ¨

Uberstunden werden als Ausdruck schlechter Managementt¨ at-

igkeit angesehen. Extreme Programming geht davon aus, dass ¨ Uberstunden

unproduktiv sind und langfristig die Produktivit¨ at der Mitarbeiter durch

Demotivierung und Ersch¨ opfung (Burnout) sinkt.

7.2.5 Planung und Anforderungsverwaltung

Extreme Programming wird oft vorgeworfen, dass es lediglich eine Legitima-

tion f¨ ur planloses Hacken darstellt und somit dem ” Code and Fix“ Vorgehen

entspricht. Es wird nun dargestellt, wie der Ablauf eines Extreme Program-

ming Projektes gestaltet wird und wie die 12 Grundpraktiken zur Anwen-

dung kommen. Eine grafische Veranschaulichung findet sich in Abbildung

11 auf Seite 55.

Zu Beginn eines Projektes muss dessen Umfang bestimmt werden. Da-

zu wird zun¨ achst die Metapher gebildet und eine Vision f¨ ur das Projekt

aufgestellt. (vgl. BF01, S. 33ff) In dieser Phase, bezeichnet auch als Erfor-

schung (Bec00, S. 131ff), wird untersucht, welche Technologien zur Umset-

zung der Vision verwendet werden k¨ onnen. Es muss das Budget und die

großen Aufgabenbereiche festgelegt werden. Es erfolgt eine Grobsch¨ atzung

des Aufwandes f¨ ur die Realisierung der großen Aufgabenbereiche. Weiterhin

7 AGILE SOFTWAREENTWICKLUNG 56

wird die zur Realisierung notwendige Infrastruktur, wie Testwerkzeug und Codeverwaltung, aufgebaut.

Im n¨ achsten Schritt findet die Versionsplanung (vgl. BF01, S. 39ff) erst- malig statt. Aus den groben Aufgabenbereichen entwickelt der Kunde kon- krete Anforderungen in Form von Geschichten. Der Umfang der Geschichten wird von den Entwicklern gesch¨ atzt. Eine Geschichte darf dabei zwischen ein bis drei Wochen Entwicklungszeit in Anspruch nehmen. L¨ asst sich eine Geschichte nicht in diesem Zeitraum realisieren, muss sie aufgeteilt werden bzw. mehrere kleinere Geschichten m¨ ussen zu einer großen Geschichte zu- sammengezogen werden. Die Formulierung der Geschichten erfolgt in der Sprache des Kunden. Es werden alle technischen Details ausgespart. Eine Geschichte sollte aus wenigen S¨ atzen bestehen. Weiterhin muss der Kun- de f¨ ur jede Geschichte einen Test beschreiben (Funktionstest), mit dem die Erf¨ ullung der Geschichte gepr¨ uft werden kann.

Die Geschichten werden durch den Kunden nach deren Gesch¨ aftswert geordnet. Es findet somit das Setzen von Priorit¨ aten statt. Dabei spielen technische Abh¨ angigkeiten eine untergeordnete Rolle. Weiterhin werden die Termine f¨ ur die Versionen bestimmt. Die Entwickler legen aus Erfahrungs- werten fest, wie viel Entwicklungsarbeit zwischen zwei Versionen geleistet werden kann. Anhand dieser Zahl wird festgelegt, welche Geschichten bis zu welchen Versionen zu realisieren sind. Als Ergebnis der Versionsplanung steht am Ende der Versionsplan sowie die zu realisierenden Geschichten ge- ordnet nach deren Priorit¨ at.

W¨ ahrend eine Produktversion (Release) aller ein bis zwei Monate ver- ¨ offentlicht werden soll, erfolgt die Arbeit in Iterationen. Eine Iteration hat dabei eine L¨ ange von ein bis drei Wochen. Zur Erreichung einer Produkt- version sind mehrere Iterationen n¨ otig. Am Anfang jeder Iteration steht die Iterationsplanung. (vgl. BF01, S. 85ff) W¨ ahrend der Iterationsplanung wer- den die Geschichten in Aufgaben aufgeteilt. Die Aufgaben stellen eine tech- nische Spezifikation dar, die in Zusammenarbeit mit dem Kunden erarbeitet wird. Die Entwickler ¨ ubernehmen die einzelnen Aufgaben und verteilen so- mit die Aufgaben unter sich. Jeder Entwickler sch¨ atzt, wie lange er f¨ ur die Realisierung der einzelnen ¨ ubernommenen Aufgaben ben¨ otigt. Die Summe der gesch¨ atzten Aufgaben stimmt nicht zwangsl¨ aufig mit der Grobsch¨ atzung uberein. Bei einer sich abzeichnenden ¨ f¨ ur die Geschichten ¨ Uberlastung der aktuellen Iteration, erfolgt eine R¨ ucksprache mit dem Kunden. Dieser ent- scheidet, welche Geschichten in eine sp¨ atere Iteration verschoben werden. Die Iterationsplanung erfolgt jeweils nur f¨ ur die aktuelle Iteration. Sie stellt die Feinplanung im Rahmen von Extreme Programming dar. Nun beginnt die eigentliche Iteration, dargestellt in Abbildung 12 auf Seite 57. Dazu sucht sich ein Programmierer f¨ ur die Realisierung einer ¨ uber- nommenen Aufgabe einen Partner. Die Koordinierung erfolgt selbstorgani- siert und nicht durch den Projektleiter. Das Programmierpaar formuliert zuerst die Tests f¨ ur diese Aufgabe und bei Unklarheiten bez¨ uglich der Auf-

7 AGILE SOFTWAREENTWICKLUNG

Abbildung 12: Ablauf einer Iteration in Extreme Programming (nach Wel99)

gabe findet eine R¨ ucksprache mit dem Kunden statt. Erst dann wird der eigentliche Code durch das Programmierpaar implementiert. Dabei kann ei- ne ¨ Uberarbeitung des vorhandenen Codes n¨ otig sein. In diesem Fall kommt die Refaktorisierung zur Anwendung. Nach wenigen Stunden wird dann der getestete Code in das Gesamtsystem integriert. Dabei wird die Erf¨ ullung aller Tests nach der Integration sichergestellt. W¨ ahrend der Iteration wird der aktuelle Fortschritt gemessen. Dadurch kann festgestellt werden, mit welcher Wahrscheinlichkeit die f¨ ur die Iteration geplanten Geschichten realisiert werden k¨ onnen. Bei gr¨ oßeren Abweichungen wird eine neue Iterationsplanung durchgef¨ uhrt. Wie bereits mehrfach betont wurde, kann der Kunde jederzeit Geschich- ten ¨ andern bzw. hinzuf¨ ugen. Die Entwickler sch¨ atzen den Umfang der neuen bzw. ge¨ anderten Geschichte. Unter Umst¨ anden muss der Kunde entscheiden, welche Geschichten anstatt der neuen bzw. ge¨ anderten Geschichte nicht rea- lisiert werden sollen.

7.2.6 Zusammenfassung Extreme Programming

Die Darstellung von Extreme Programming erfolgte sehr ausf¨ uhrlich um zu zeigen, dass es sich nicht um ein v¨ ollig unkontrolliertes Programmieren han- delt. Es lassen sich alle Schritte der klassischen Softwareentwicklung identi- fizieren. Die Analyse erfolgt zum einen mit der Aufstellung der Geschichten durch den Kunden. Weiterhin werden diese Geschichten w¨ ahrend der Iterati- onsplanung genauer untersucht und in konkrete Aufgaben aufgespalten. Der Entwurf erfolgt w¨ ahrend der Programmierung. Die Architektur wird durch die Refaktorisierung schrittweise angepasst. Implementierung und Test wer- den eng verzahnt durchgef¨ uhrt. Die Integration erfolgt t¨ aglich, die Inbetrieb- nahme durch den Kunden erfolgt in kurzen Zeitr¨ aumen. Die Kommunikation unter den Entwicklern wird durch das Programmieren in Paaren sowie die gemeinsame Verantwortlichkeit unterst¨ utzt. Die Kommunikation zwischen Kunde und Entwicklern wird durch die st¨ andige Einbeziehung des Kunden, z. B. w¨ ahrend der Versionsplanung und Iterationsplanung, gef¨ ordert. Die 12

7 AGILE SOFTWAREENTWICKLUNG 58

Grundpraktiken unterst¨ utzen sich gegenseitig. (vgl. dazu Bec00, S. 63) So ist eine Refaktorisierung ohne automatische Tests nicht m¨ oglich. Eine fort- laufende Integration setzt ebenfalls die Unterst¨ utzung durch automatische Tests voraus.

Als nachteilig bei Extreme Programming ist zu bewerten, dass im Pro- jekt gewonnenes Wissen ausschließlich intern existiert und nicht dokumen- tiert wird. Extreme Programming gilt als nur in kleinen Teams von etwa zehn Entwicklern umsetzbar. F¨ ur die Bew¨ altigung gr¨ oßerer Projekte stehen andere agile Methodiken zur Verf¨ ugung. An dieser Stelle soll die Methodik- familie Crystal als Beispiel vorgestellt werden.

7.3 Agiler Vertreter: Methodikfamilie Crystal

W¨ ahrend Extreme Programming konkrete Aktivit¨ aten vorgibt, sind die Me- thodiken der Methodikfamilie Crystal wesentlich abstrakter. Crystal, ent- wickelt von Alistair Cockburn (vgl. Coc02; Coc03), versteht sich als eine Familie von Methodiken. Zentraler Ansatzpunkt lautet, dass Menschen und Projekte unterschiedlich sind und dass es deshalb unterschiedlicher Metho- diken bedarf. Deshalb nimmt Crystal eine Klassifizierung von Projekten vor (siehe Abbildung 13 46 auf Seite 59) und bietet entsprechende Methodiken f¨ ur die einzelnen Klassen an. Laut Crystal wird ein Projekt von folgenden drei Variablen charakterisiert (Coc03, S. 218):

1. Anzahl der Mitarbeiter, die koordiniert werden sollen

2. Kritizit¨ at des Projektes (Auswirkungen beim Scheitern)

3. Priorit¨ aten des Projektes (z. B. fr¨ uhzeitige Auslieferung)

Der Zusammenhang der drei Variablen l¨ asst sich, wie in Abbildung 13 ge- zeigt, darstellen. Bevor f¨ ur ein Projekt ein Vorgehen bestimmt werden kann, m¨ ussen zuerst die drei Variablen bestimmt werden. Weiterhin muss w¨ ahrend des Projekt ¨ uberpr¨ uft werden, ob sich die Variablen ver¨ andert haben und somit die Einstufung des Projektes ver¨ andert werden muss.

Die Begr¨ undung f¨ ur dieses Vorgehen liegt in mehreren Punkten. Eine Steigerung der Mitarbeiterzahl erh¨ oht den Kommunikationsaufwand. Auf dieses Problem hat bereits Brooks (vgl. Bro01b) aufmerksam gemacht. Dabei ubersteigt ab einer bestimmten Teamgr¨ oße der Kommunikationsaufwand, ¨ verursacht durch einen weiteren Mitarbeiter, den Gewinn an Arbeitskraft durch diesen Mitarbeiter. Eine Verdoppelung der Mitarbeiter f¨ uhrt nicht zu einer Verdoppelung der Arbeitskraft. Cockburn (Coc03, S. 107ff) zeigt weiterhin, dass direkte Kommunikation von Mensch zu Mensch wesentlich effektiver ist, als indirekte Kommunikation. Tats¨ achlich ist eine direkte Kom- munikation nur bei bis zu zehn Mitarbeitern im Projektteam m¨ oglich. Da 46 Die Buchstaben (C, D, E und L) f¨ ur die einzelnen Zellen stammen aus der englisch- sprachigen Originalliteratur.

7 AGILE SOFTWAREENTWICKLUNG

Abbildung 13: Crystal Projekteinordnung nach Anzahl Mitarbeiter, Kriti-

zit¨ at und Priorit¨ aten

Extreme Programming ausschließlich auf direkter Kommunikation basiert,

kann es kaum in Teams gr¨ oßer als zehn Mitarbeiter umgesetzt werden.

Ist das Ergebnis eines Projektes kritisch f¨ ur das Fortbestehen des Unter-

nehmens, m¨ ussen andere Verfahren verwendet werden, als wenn das Projekt

weniger kritisch ist. Unter Priorit¨ aten versteht Cockburn z. B. gesetzliche

Auflagen. So kann es sein, dass bestimmte Artefakte durch den Auftraggeber

oder durch Randbedingungen erforderlich sind. Dann muss die verwendete

Methodik die Erstellung der Artefakte sicherstellen.

In der Methodikfamilie Crystal wird davon ausgegangen, dass die Kon-

zentration auf F¨ ahigkeiten der Mitarbeiter, Kommunikation und Gemein-

schaft in einem Projekt effektiver ist, als die Konzentration auf vorgeschrie-

bene Prozesse. Daraus leiten sich folgende Grundwerte ab (Coc03, S. 267):

1. mensch- und kommunikationszentrisch

2. M¨ oglichkeit zur Anpassung bei Bedarf

3. Toleranz

Punkt 1 bedeutet, dass Werkzeuge, Artefakte und Verfahren lediglich als

Unterst¨ utzung f¨ ur die menschlichen Komponente dienen. Punkt 2 stellt klar,

dass die Methodik w¨ ahrend des Projekts ¨ uberarbeitet werden muss, um sich

¨ andernden Anforderungen anzupassen. Punkt 3 hebt hervor, dass das Team

anhand seiner Erfahrung entscheidet, welche Artefakte und Prozesse sinnvoll

sind und damit letztendlich umgesetzt werden.

Anhand dieser Darstellung wird ersichtlich, dass die Methodikfamilie

Crystal sehr abstrakt ist. F¨ ur die konkrete Umsetzung wurden je nach Ein-

stufung des Projektes verschiedene konkrete Auspr¨ agungen entwickelt. Die

einfachste Auspr¨ agung f¨ ur kleine nicht kritische Projekte (die Zellen C6, D6

7 AGILE SOFTWAREENTWICKLUNG 60

und E6 in Abbildung 13) ist Crystal Clear. (vgl. Coc02) F¨ ur Crystal Clear ist erforderlich (Coc02, S. 258):

• ein erfahrender Chefentwickler und zwei bis sieben weitere Entwickler

• ein großer Raum, ausgestattet mit Wandtafeln und Flipcharts

• direkte Einbeziehung des Nutzers

• regelm¨ aßige Auslieferung von getestetem und nutzbarem Code an den Nutzer aller ein bis zwei Monate

• periodische Reflexion und ¨ Uberarbeitung des Vorgehens

Dabei wird im Gegensatz zu Extreme Programming nicht auf Dokumen- tation verzichtet. Das Team muss allerdings selbst entscheiden, welche Ar- tefakte sinnvoll zur Speicherung des im Projekt gewonnenen Wissens sind. Als wichtiges Werkzeug wird ein System f¨ ur das Konfigurations- und Versi- onsmanagement angesehen. Auf den Wandtafeln und Flipcharts wird z. B. das Design und andere Entscheidungen kommuniziert. Weiterhin dienen sie w¨ ahrend einer Diskussion im Projektteam als Zeichenfl¨ ache. Im Vergleich zu Extreme Programming f¨ allt auf, dass Crystal Clear we- niger konkrete Forderungen stellt. Lediglich die Forderung von Dokumenta- tion geht ¨ uber den Umfang von Extreme Programming hinaus. Es werden keine Aussagen ¨ uber die Programmierung (Technologie, Programmierspra- che, Standards, Programmieren in Paaren, usw.) oder den Umfang von Tests getroffen. Dies liegt im Ermessen des Teams.

F¨ ur komplexere Projekte stehen eine Vielzahl von weiteren Auspr¨ agung- en der Methodikfamilie Crystal zur Verf¨ ugung. Diese sind wesentlich um- fangreicher, da eine gr¨ oßere Anzahl von Mitarbeitern koordiniert werden muss. Auch in diesen Auspr¨ agungen werden die drei oben genannten Grund- werte umgesetzt. Cockburn betont, dass mit zunehmender Projektgr¨ oße die Formalien zunehmen m¨ ussen, da eine direkte Kommunikation im ganzen Projektteam aufgrund des exponentiell steigenden Kommunikationsaufwan- des nicht m¨ oglich ist. So bestehen z. B. bei rein direkter Kommunikation in einem Team mit sechs Mitgliedern 15 Kommunikationswege, wie in Abbil- dung 14 Teilbild a) auf Seite 61 nachvollzogen werden kann. In Abbildung

14 Teilbild b) wurde das Projektteam in zwei Teilteams untergliedert. Eine

Kommunikation zwischen beiden Teilteams findet ¨ uber jeweils eine Person aus den Teilteams statt. Durch diese Maßnahme k¨ onnen die Kommunikati- onswege mehr als halbiert werden. Allerdings wird die Kommunikation f¨ ur die einzelnen Teammitglieder, wenn sie mit einem Mitglied aus dem ande- ren Teilteam kommunizieren m¨ ussen, erschwert, da eine Vermittlung ¨ uber die Verbindungspersonen notwendig ist.

Trotzdem bleiben große formalisierte Projekte laut Cockburn agil, wenn sie die auf Seite 59 genannten drei Grundwerte umsetzen. Allgemein kann

7 AGILE SOFTWAREENTWICKLUNG

Abbildung 14: Anzahl Kommunikationswege bei direkter und bei gemischter Kommunikation am Beispiel eines Teams mit sechs Mitgliedern

davon ausgegangen werden, dass die Einf¨ uhrung von Formalien nicht Agi- lit¨ at verhindert.

7.4 Manifest agiler Softwareentwicklung

Es existiert eine Vielzahl von Vertretern der agilen Softwareentwicklung. In den vorherigen Abschnitten wurden

• Extreme Programming

• und Methodikfamilie Crystal vorgestellt. Die weiteren Vertreter der agilen Softwareentwicklung sollen hier lediglich genannt werden (nach Hig02):

• Scrum

• Dynamic Systems Development Method (DSDM)

• Feature-Driven Development (FDD)

• Lean Development (LD)

• Adaptive Software Development (ASD)

7 AGILE SOFTWAREENTWICKLUNG 62

Die verschiedenen Vertreter und Autoren der einzelnen Methodiken haben versucht, die Gemeinsamkeiten zu formulieren. Die entsprechend gemeinsam ver¨ offentlichte und unterzeichnete Erkl¨ arung wird als das Manifest agiler Software Entwicklung (Agi01) 47 bezeichnet und lautet auszugsweise:

. . . Durch das Entwickeln von Software und indem wir ande- ” ren bei der Entwicklung helfen, erschließen wir bessere Wege der Softwareentwicklung. Durch diese Arbeit haben wir folgende Werte zu sch¨ atzen gelernt:

• Individuen und Interaktion [zwischen den Individuen] 48 sind wichtiger als Prozesse und Werkzeuge.

• Funktionierende Software ist wichtiger als umfassende Do- kumentation.

• Kundenzusammenarbeit ist wichtiger als Vertragsverhand- lungen.

• Auf ¨ Anderungen reagieren ist wichtiger als einem Plan zu folgen.

Wir sch¨ atzen die Punkte auf der rechten Seite, aber wir bewerten die Punkte auf der linken Seite h¨ oher. . . .“

Diese vier Punkte werden durch 12 weitere Prinzipien unterst¨ utzt, auf die hier aber nicht n¨ aher eingegangen wird. Aus dem Manifest ergeben sich einige zu diskutierende Punkte. Zun¨ achst weisen die Unterzeichner darauf hin, dass sie selber in der Softwareentwicklung t¨ atig sind und sich ihre An- sichten daher prim¨ ar aus praktischer Erfahrung ergeben haben. Weiterhin muss betont werden, dass es sich bei den vier Grundwerten nicht um ein Entweder-Oder“ handelt. Die Unterzeichner legen lediglich eine Priorit¨ at ” auf die links stehenden Werte.

Die vier Punkte des Manifest lassen sich anhand der beiden in dieser Arbeit vorgestellten Vertreter der agilen Softwareentwicklung nachvollzie- hen. So steht die Zusammenarbeit und Kommunikation zwischen Individu- en bei Crystal im Mittelpunkt des Interesses. Je nach Projektgr¨ oße werden unterschiedliche Kommunikationsformen vorgeschlagen, um die Interaktion zwischen den Projektmitgliedern zu sichern. Extreme Programming fordert die st¨ andige Verf¨ ugbarkeit einer funktionierenden Software und verzichtet gr¨ oßtenteils auf Dokumentation. Sowohl bei Crystal als auch bei Extreme Programming wird eine partnerschaftliche Zusammenarbeit mit dem Kun- den betont. Der Kunde sollte m¨ oglichst ins Projektteam integriert werden. Durch die iterative ¨ Uberarbeitung der Planung bei Extreme Programming, 47 Hervorhebung im Original; ¨ Ubersetzung entnommen bei (Coc03, S. 281).

48 Anmerkung des Verfassers

7 AGILE SOFTWAREENTWICKLUNG 63

wird auf sich ¨ andernde Anforderungen reagiert. Crystal schl¨ agt die konse- quente Anwendung von Reflexion w¨ ahrend des Projektes vor und sorgt somit ebenfalls f¨ ur eine Anpassung an ge¨ anderte oder neue Anforderungen. Das Manifest agiler Softwareentwicklung ist somit eine Zusammenfas- sung der gemeinsamen zugrunde liegenden Prinzipien. Es kl¨ art aber nicht das gemeinsame Weltbild 49 , sondern wendet dieses konkret an. Auch wenn es sicher einer enormen Kraftanstrengung bedurfte das Manifest zu formulie- ren, so ist es nicht ausreichend. Das Manifest kommuniziert zwar die Grund- prinzipien, benennt aber nicht direkt das gemeinsame Weltbild der agilen Softwareentwicklung. Im nun folgenden Abschnitt wird diese Grundvision der agilen Softwareentwicklung herausgearbeitet. Dabei wird zun¨ achst der Begriff Agilit¨ at untersucht.

7.5 Begriff Agilit¨ at

Neben dem Manifest der agilen Softwareentwicklung muss der Begriff Agi- lit¨ at zum Verst¨ andnis der agilen Softwareentwicklung betrachtet werden. Dabei wird von einer Welt ausgegangen, die einem st¨ andigen Wandel un- terliegt. Im Rahmen der Softwareentwicklung k¨ onnte sich die Welt z. B. wandeln durch:

• ¨ Anderung im Projektteam (z. B. wechselnde Teamzusammensetzung)

• ¨ Anderung im technologischen Umfeld (z. B. Wegfall der Unterst¨ utzung f¨ ur bestimmte verwendete Technologien)

• ¨ Anderung der Anforderungen durch den Kunden

• ¨ Anderung durch Konkurrenz (z. B. Ver¨ offentlichung einer neuen Ver- sion eines Konkurrenzproduktes)

• ¨ Anderung im Markt (z. B. Fusion eines einstigen Partners mit einem Konkurrenten)

• . . .

Sowohl klassische als auch agile Softwareentwicklung beschreiben Mittel, um diesen Wandel zu bew¨ altigen. So existiert in der klassischen Softwareent- wicklung z. B. das Change Management und Risikomanagement. Der agile Vertreter Extreme Programming nimmt lediglich eine kurzfristige Planung vor, um auf ¨ Anderungen in den Anforderungen reagieren zu k¨ onnen. W¨ ahrend die klassische Softwareentwicklung Wandel als ein erfolgreich zu verwaltendes Risiko betrachtet, sieht die agile Softwareentwicklung Wan- del als eine Chance. Daraus leitet sich f¨ ur die klassische Softwareentwicklung die Forderung ab, Wandel m¨ oglichst zu vermeiden bzw. die Auswirkungen 49 siehe dazu Kapitel 4 auf Seite 21

7 AGILE SOFTWAREENTWICKLUNG 64

auf das Projekt so gering als m¨ oglich zu halten. F¨ ur die agile Softwareent- wicklung hingegen bedeutet dies, Wandel als integralen Bestandteil eines Projektes zu akzeptieren. Dies sind zwei vollst¨ andig entgegengesetzte Posi- tionen in Bezug auf Wandel der Welt.

Akzeptiert man eine sich wandelnde Welt, dann bedeutet dies nicht, dass jede Planung sinnlos ist. Man ist sich vielmehr bewusst, dass Pl¨ ane keine Vorwegnahme der Zukunft sind, sondern lediglich eine Hypothese der zuk¨ unftigen Entwicklung darstellen. Deshalb kann man Pl¨ ane nicht reali- sieren, sondern man kann lediglich nachtr¨ aglich die Qualit¨ at der Hypothese pr¨ ufen. Die Zukunft einer Welt ist dann nicht vorhersagbar, wenn die Welt auf Nicht-Linearit¨ at und Nicht-Determinismus beruht. Da die agile Softwa- reentwicklung von solch einer sich wandelnden Welt ausgeht, bildet das neue Weltbild 50 die philosophische Grundlage der agilen Softwareentwicklung. Agilit¨ at bedeutet aber nicht nur Wandel zu akzeptieren. Agilit¨ at geht einen Schritt weiter und fordert Wandel, wenn dies sinnvoll erscheint. Dies kann vorteilhaft sein, z. B. wenn man einen Wandel ausl¨ ost, dem die Konkur- renz nicht oder nur unter hohem Aufwand folgen kann. Wandel der Anfor- derungen kann sinnvoll sein, wenn sich durch die ge¨ anderten Anforderungen und die entsprechend realisierte Software h¨ ohere Gesch¨ aftswerte realisieren lassen.

Demnach m¨ ussen zwei Bedingungen erf¨ ullt sein, damit eine Organisation (z. B. ein Unternehmen) als agil bezeichnet werden kann (nach Hig02, S. 5f und S. XXIII):

1. Die Organisation akzeptiert und bew¨ altigt Wandel.

2. Die Organisation nutzt und l¨ ost Wandel zum eigenen Vorteil aus.

Das ist die Bedeutung von Agilit¨ at. Damit eine Organisation agil sein kann, muss sie gewandt sein (Hig02, S. 30f), d. h. sich schnell neuen Situationen anpassen k¨ onnen, teilweise auch durch Improvisation. Bevor man aber im- provisieren kann, muss man zuerst das Gebiet beherrschen und die Grenzen kennen. Neben umfangreichen theoretischem Wissen setzt dies praktische Erfahrung voraus. 51 Dar¨ uber hinaus muss eine agile Organisation flexibel sein (Hig02, S. 33f), d. h. die Bereitschaft zur ¨ Uberarbeitung bew¨ ahrter Vorgehen muss existieren. Das bedeutet nicht, dass sich die Organisation mit jedem Wandel selbst ¨ andern muss, denn eine sich st¨ andig ver¨ andernde Struktur ist keine Organisation. Es gilt somit eine Organisationsstruktur zu finden, die situationsabh¨ angige Anpassungen zul¨ asst.

F¨ ur die Softwareentwicklung bedeutet dies, den durch Wandel zus¨ atzlich verursachten Arbeitsaufwand m¨ oglichst gering zu halten. Ein Mittel ist die Reduzierung der zu ¨ andernden Dokumentation. Weiterhin kann der Einsatz 50 siehe dazu Kapitel 4.3 auf Seite 22 51 So muss der Jazzmusiker zuerst sein Instrument und ein breites Repertoire an St¨ ucken beherrschen, bevor er improvisieren kann.

7 AGILE SOFTWAREENTWICKLUNG 65

von Werkzeugen helfen, Wandel effektiv zu bew¨ altigen. Dabei darf aber kein Wandel ausgel¨ ost werden, um das Vorhandensein der Werkzeuge zu recht- fertigen. Weitere konkrete Umsetzungen von Agilit¨ at finden sich bei den einzelnen Vertretern der agilen Softwareentwicklung und werden an dieser Stelle nicht diskutiert.

Vor der Formulierung des Manifest agiler Softwareentwicklung wurden die heute als agil bezeichneten Methodiken als ” leicht“ charakterisiert. Der Begriff ” leicht“ ist allerdings nicht treffend, da man in diesem Zusammen- hang annehmen k¨ onnte, dass klassische Vorgehensmodelle von bestimmten Aktivit¨ aten und Artefakten bereinigt werden und somit die agilen Metho- diken lediglich eine Teilmenge der klassischen Vorgehensmodelle sind. Wie bereits an den beiden vorgestellten Vertretern der agilen Softwareentwick- lung deutlich gezeigt wurde, ist dem nicht so. ” Leicht“ bezieht sich somit auf die Gestaltung der Softwareentwicklung. Gemeint sind damit wenig for- malisierte Methodiken, die ” leicht aber ausreichend“ (Coc03, S. 233) sind.

Tats¨ achlich k¨ onnen aber auch sehr stark formalisierte Projekte agil sein, wenn sie Wandel akzeptieren und Wandel bewusst gestalten und damit das neue Weltbild als philosophische Basis w¨ ahlen.

7.6 Emergent Design

Im Umfeld der agilen Methodiken taucht der Begriff Emergent Design seit etwa Ende 2000 auf. Darunter versteht man das ohne bewusste Steuerung gestaltete Design einer Software. Emergent Design bezeichnet somit das De- sign als Artefakt und nicht die Designphase.

Bei Emergent Design existiert keine abgrenzbare Designphase, es findet keine bewusste Gestaltung statt. Im Rahmen von Extreme Programming werden die folgenden drei Grundpraktiken f¨ ur die unbewusste Entstehung des Designs verantwortlich gemacht:

• Einfaches Design

• Refaktorisierung

• Komponententests

Mit der Konzentration auf ein einfaches Design w¨ ahrend der Program- mierung wird die Basis gelegt. Das einfache Design entspricht nicht dem endg¨ ultigen Design der Software, da Refaktorisierung f¨ ur eine stetige ¨ Uber- arbeitung und Weiterentwicklung des Design sorgt. Dabei stellen die Kom- ponententests sicher, dass das Design immer noch die volle Funktionalit¨ at unterst¨ utzt.

Der Begriff Emergent Design (vgl. z. B. Cav00) stammt nicht aus der Softwareentwicklung. Tats¨ achlich wird das Wort Emergenz in englischspra- chigen Ver¨ offentlichungen sehr h¨ aufig verwendet. In allen Bereichen des Le- bens und Zusammenlebens finden t¨ aglich Gestaltungsentscheidungen statt.

7 AGILE SOFTWAREENTWICKLUNG 66

So legt z. B. der Architekt das Design eines Geb¨ audes fest, Experten entwer- fen die Grundlage einer gesellschaftlichen Institution (wie Hochschulpolitik) und Unternehmen ¨ andern ihre interne Struktur und damit ihr Design. Soll Emergent Design tats¨ achlich emergente Ph¨ anomene hervorrufen, dann muss es Nicht-Linearit¨ at und Nicht-Determinismus erm¨ oglichen und einsetzen. Das oben beschriebene Vorgehen innerhalb von Extreme Pro- gramming ist nicht-deterministisch, da keine Vorherbestimmung der Er- gebnisse (des Design) stattfindet. Es wird auf eine schrittweise Entwick- lung gesetzt und eine globale Planung der Ergebnisse vermieden. Weiterhin sorgen Refaktorisierung und Programmierung f¨ ur Nicht-Linearit¨ at. Es fin- det eine st¨ andige ¨ Uberarbeitung des aktuellen Designs der Software statt.

Da es unendlich viele M¨ oglichkeiten f¨ ur das Design einer Software gibt, ist nicht vorhersehbar, welcher Entwicklungsweg eingeschlagen wird. Dies h¨ angt, bei gleichbleibenden Projektziel, sehr stark von den F¨ ahigkeiten und pers¨ onlichen Vorlieben der Entwickler ab. Diese vielen kleinen ¨ Anderungen f¨ uhren zu einer Entwicklung, die weder vorhersehbar noch steuerbar ist. Da scheinbar im Rahmen von Emergent Design Nicht-Linearit¨ at und Nicht-Determinismus vorliegen, kann davon ausgegangen werden, dass durch Emergent Design tats¨ achlich ein emergentes System gestaltet wird.

7.7 Einordnung in die Systematik

Die meisten der vorgestellten Techniken dienen der Bew¨ altigung eines emer- genten Systems. Sie helfen den Wandel und die sich ¨ andernden Anforderun- gen zu bew¨ altigen. Durch kurze Releasezyklen und die Iterationsplanung k¨ onnen neue Anforderungen beachtet werden und die automatisierten Tests und die fortlaufende Integration stellen die Funktionalit¨ at der Software nach ¨ Anderungen sicher. Hier findet ein Umgang mit den beiden Prinzipien Nicht- Linearit¨ at und Nicht-Determinismus statt.

Die enge Vernetzung der Mitarbeiter sowie das Emergent Design stellen eine m¨ ogliche Gestaltung eines emergenten Systems dar. In der Zukunft werden sich mit Sicherheit weitere Anwendungen ergeben. Hier findet eine Nutzung der beiden Prinzipien Nicht-Linearit¨ at und Nicht-Determinismus statt.

7.8 Zusammenfassung agile Softwareentwicklung

In diesem Abschnitt wurden zwei Vertreter der agilen Softwareentwicklung vorgestellt. Anhand dieser Beispiele wurden die Gemeinsamkeiten der agilen Methodiken herausgearbeitet. Diese Gemeinsamkeiten wurden im Manifest der agilen Softwareentwicklung zusammengefasst. Mit der Diskussion des Begriffs Agilit¨ at konnte gezeigt werden, dass das neue Weltbild die philoso- phische Grundlage der agilen Softwareentwicklung ist. Weiterhin wurde das Ph¨ anomen Emergent Design als eine m¨ ogliche Gestaltung eines emergen-

7 AGILE SOFTWAREENTWICKLUNG 67

ten Systems vorgestellt. Abschließend wurden einzelne Verfahren der agilen Softwareentwicklung in die entwickelte Systematik eingeordnet. Im nun folgendem Abschnitt wird die eigentliche Fragestellung dieser Arbeit beantwortet.

8 EMERGENZ IN DER SOFTWAREENTWICKLUNG 68

8 Emergenz in der Softwareentwicklung

8.1 Einleitung

Der Gegenstand dieser Arbeit ist die Fragestellung, ob in der Softwareent- wicklung Emergenz angewendet werden kann und ob dies bereits geschieht. In diesem Kapitel wird eine umfassende Antwort, aufbauend auf die in den vorhergehenden Kapiteln entwickelten Darstellungen, gegeben. Entspre- chend der in Kapitel 4.4 auf Seite 24 entwickelten Systematik, findet eine Unterscheidung in Bew¨ altigung und Gestaltung einer emergenten Welt statt. Aus dieser Betrachtung kann die Antwort auf die Fragestellung dieser Arbeit formuliert werden.

8.2 Bew¨ altigung von Emergenz in der Softwareentwicklung

Unter Bew¨ altigung von Emergenz versteht diese Arbeit den Umgang mit einer Welt gepr¨ agt durch Nicht-Linearit¨ at und Nicht-Determinismus. Bevor mit einer Bew¨ altigung begonnen werden kann, muss allerdings zun¨ achst die Einsicht in die Notwendigkeit existieren. Dies bedeutet eine Abkehr von der These, wonach Softwareentwicklung eine reine Ingenieurdisziplin ist – eine Abkehr vom mechanischen Weltbild. Diese Abkehr vom mechanischen Weltbild hin zum neuen Weltbild m¨ undet in der Kritik an der Baumetapher der klassischen Softwareentwicklung:

• Software ist leichter ¨ anderbar

• Software ist Teil einer Probleml¨ osung und kein reines Produkt

• Software kann nicht endg¨ ultig fertig gestellt werden, sondern es erfolgt eine stetige Weiterentwicklung

• Software ist abstrakt und damit schlecht vermittelbar

• Entwicklung ist nicht langfristig planbar, da Anforderungen und Um- welt sich w¨ ahrend des Projektes ¨ andern

• Parallelit¨ at der Phasen Analyse, Entwurf, Implementierung, Test und Inbetriebnahme ist w¨ ahrend Softwareentwicklung m¨ oglich

• . . .

Mit Sicherheit ließen sich noch weitere Kritikpunkte finden, aber schon diese wenigen Punkte sind ausreichend um zu erkennen, dass eine Baumetapher f¨ ur die Softwareentwicklung nicht ausreichend ist. Zentraler Kritikpunkt an der Baumetapher ist, dass Software im Vergleich zu einem Ingenieurpro- dukt wie einer Br¨ ucke oder einem Haus jederzeit ¨ anderbar ist. Ein Haus kann nur unter hohem Kostenaufwand ge¨ andert werden, wenn es sich be- reits im Rohbau oder sogar im Innenausbau befindet. Daraus leitet sich die

8 EMERGENZ IN DER SOFTWAREENTWICKLUNG 69

Forderung ab, dass vor Baubeginn alle zuk¨ unftigen Anforderungen ermittelt und ber¨ ucksichtigt sein m¨ ussen. Software hingegen kann jederzeit ge¨ andert werden. Der daf¨ ur notwendige Kostenaufwand kann durch die vorgestellten Techniken wie automatisierte Tests, Refaktorisierung und h¨ aufige Integrati- on wesentlich reduziert werden. Es gibt somit keinen Grund, warum man das Mittel der Software¨ anderung nicht einsetzen sollte. Tats¨ achlich ist es das Mittel, um in einer dynamischen Welt erfolgreich Software zu entwi- ckeln. Denn Anforderungen ¨ andern sich. Es ist unm¨ oglich alle Anforderun- gen in einem komplexen Projekt am Projektanfang in einer Analysephase vollst¨ andig zu bestimmen. Bereits kleinste ¨ Anderungen der Anforderungen k¨ onnen große Auswirkungen auf die zu entwickelnde Software haben. Der typische Einsatz von Software erfordert eine h¨ aufige ¨ Uberarbeitung und Weiterentwicklung. Im Gegensatz zu dem Produkt eines Ingenieurpro- zesses wird Software oft erweitert oder Kernfunktionen m¨ ussen an neue Rah- menbedingungen angepasst werden. All dies erfordert eine ¨ Anderung der Software nach deren urspr¨ unglicher Fertigstellung.

Es ist bekannt, dass Anforderungen nur schwer ermittelt werden k¨ onnen. Software ist letztendlich der abstrakte Teil einer komplexen Probleml¨ osung. Dem Nutzer f¨ allt es dementsprechend schwer, die Anforderungen an diese abstrakte Komponente genau zu spezifizieren. Dem wurde in der Vergangen- heit durch die Entwicklung von Prototypen und neuen Analysetechniken ent- gegengewirkt. Die beste M¨ oglichkeit die w¨ ahrend der Analyse gewonnenen Anforderungen zu ¨ uberpr¨ ufen, ist der Einsatz des Produktes in der sp¨ ateren Produktionsumgebung. Dies bedeutet eine h¨ aufige Auslieferung von Softwa- reversionen, die der Nutzer pr¨ uft, damit er seine Anforderungen ¨ uberarbeiten und pr¨ azisieren kann. Es handelt sich hierbei um eine iterativ inkrementel- le Entwicklung mit stark verk¨ urzten Zyklen von wenigen Monaten. Dabei ergeben sich mehrere Vorteile. So bringt jede neue Version lediglich eine ge- ringe Anzahl von Neuerungen. Damit wird der Nutzer zum stetigen Lernen aufgefordert, aber es findet keine ¨ Uberforderung der Lernf¨ ahigkeit statt.

Eine ¨ Uberforderung kann dann eintreten, wenn zu einem Zeitpunkt z. B. eine komplette Software eingef¨ uhrt werden soll und wesentliche Teile der Arbeitsprozesse davon betroffen sind und neu erlernt werden m¨ ussen. Wei- terhin ist es zum Vorteil des Kunden, wenn er w¨ ahrend des Projektes seine Anforderungen ¨ uberarbeiten kann. Dadurch erh¨ alt er eine Software, die sei- nen tats¨ achlichen aktuellen Anforderungen, und nicht den Anforderungen zu Projektbeginn, entspricht. Der Kunde ist somit an der Gestaltung der zu entwickelnden Software direkt beteiligt.

Im Gegensatz zum Produkt eines Ingenieurprozesses, wie ein Automo- bil oder ein Haus, ist Software meist Bestandteil einer umfassenden Pro- bleml¨ osung. Diese Probleml¨ osung umfasst neben dem Softwareprodukt wei- terhin Hardware, Beratung, Schulung und sogar eine ¨ Uberarbeitung der Gesch¨ aftsprozesse des Kunden (Business Reengineering).

8 EMERGENZ IN DER SOFTWAREENTWICKLUNG 70

Durch den Wandel der Anforderungen und eingesetzten Technologien wird eine langfristige Projektplanung erschwert. Sinnvoller ist deshalb eine zuverl¨ assige Planung in kurzen Zeitr¨ aumen.

Verzichtet man in der Softwareentwicklung auf einen starren Ablauf der einzelnen Phasen, kann man die Entwicklung durch Parallelisierung der Pha- sen wesentlich beschleunigen. W¨ ahrend bereits Funktionen als Code imple- mentiert werden, findet die Analyse sp¨ ater ben¨ otigter Funktionalit¨ at statt. Dies f¨ uhrt zu einer gleichm¨ aßigeren Auslastung der einzelnen Mitglieder des Projektteams. Weiterhin k¨ onnen wichtige Programmfunktionen bereits sehr fr¨ uhzeitig durch den Kunden eingesetzt werden.

Man erkennt, dass die Softwareentwicklung, verstanden als reine Inge- nieurdisziplin, nicht alle Fragen beantworten kann. Tats¨ achlich versucht die klassische Softwareentwicklung Probleme wie sich ¨ andernde Anforderungen zum Beispiel mit dem Change Management zu behandeln. Es muss dabei allerdings gefragt werden, ob mit solchen Verfahren letztendlich nicht nur die Symptome bek¨ ampft werden, ohne die eigentliche Ursache zu erkennen. Denn die Ursache ist eine Welt gepr¨ agt von Nicht-Linearit¨ at und Nicht-De- terminismus. Einige Gr¨ unde f¨ ur Nicht-Linearit¨ at in der Softwareentwicklung sind:

• Menschen handeln nicht-linear, sie sind keine Maschinen

• Software ist das Produkt eines Teams von Individuen

• Code ist immer stark vernetzt und r¨ uckgekoppelt

• Softwareprodukt wird in eine komplexe Umgebung integriert

• . . .

Software wird von Menschen entwickelt. Menschen handeln nicht vollst¨ andig rational, sondern sind gepr¨ agt durch eine Vielzahl von Konflikten. Das Ver- halten eines Menschen ist situationsabh¨ angig. Der Mensch denkt assoziativ und nicht rein logisch wie ein Digitalrechner. Dies f¨ uhrt zu einer gewissen Sprunghaftigkeit, die einzig durch den zentralen Charakter des Individuums gegl¨ attet wird. Tats¨ achlich ist eine vollst¨ andige Unterdr¨ uckung der Sprung- haftigkeit nicht erw¨ unscht, da die Sprunghaftigkeit im Verhalten die Vor- aussetzung f¨ ur Kreativit¨ at ist. Weiterhin steht der Mitarbeiter in st¨ andiger Interaktion mit den Mitarbeitern, dem Kunden und dem Management. Die- se Gruppen haben oft widersprechende Anforderungen. Die Vernetzung der Individuen f¨ uhrt zu einer nicht-linearen Gruppendynamik.

Jeder Codebereich, wie eine Klasse oder Methode, steht mit einer Viel- zahl anderer Codebereiche in Verbindung. Eine gute Softwarearchitektur kann dieses Problem einschr¨ anken, dennoch kann sie die entstehenden R¨ uck- koppelungseffekte durch die Vernetzung des Codes nicht vollst¨ andig verhin- dern, da der Code zur Erf¨ ullung der Softwarefunktionalit¨ at zu einem Min-

8 EMERGENZ IN DER SOFTWAREENTWICKLUNG 71

destmaß vernetzt sein muss. Deshalb k¨ onnen bereits kleinste ¨ Anderungen

Auswirkungen auf das Gesamtverhalten des Systems haben. Software wird bei der Auslieferung in eine komplexe Umgebung ¨ uber eine Vielzahl von Schnittstellen integriert. Durch diese enge Koppelung der Soft- ware an die Umwelt wird die Software ein Bestandteil eines gr¨ oßeren Systems und verliert dadurch ihre Autonomie. Die Software ist danach abh¨ angig von einer Vielzahl von Elementen, die nicht kontrolliert werden k¨ onnen. Sie ist Bestandteil eines Netzwerkes.

Weiterhin ist die Softwareentwicklung bestimmt von Nicht-Determinis- mus. Dies ¨ außert sich z. B. in folgenden Punkten:

• es existiert nicht die ideale Softwarearchitektur

• zuk¨ unftige Anforderungen und Umweltbedingungen sind nicht vorher- sehbar

• Technologie- und Umweltentwicklung k¨ onnen nicht gesteuert werden

• Planung liefert eine Hypothese ¨ uber die Zukunft

• Sch¨ atzungen sind Sch¨ atzungen und keine Vorwegnahme der Zukunft

• Projekte erbringen individuelle nur bedingt vergleichbare L¨ osungen

• Projekte beinhalten Risiken (z. B. zu Scheitern)

• Organisationsstrukturen und Strategien sind einzigartig

• . . .

Die Gestaltungsm¨ oglichkeiten von Software sind vielf¨ altig. Dies belegt allein die un¨ uberschaubare Anzahl von Programmiersprachen. Weiterhin existiert eine Vielzahl von Entwicklungsparadigmen 52 . Aus dem verwendeten Para- digma leitet sich die Architektur ab. Diese Architektur kann im Konkreten ebenfalls vielf¨ altig erfolgen. Wird z. B. eine Software in Hinblick auf Er- weiterungsf¨ ahigkeit entwickelt, dann kann dies ¨ uber mehrere Wege erfolgen.

Denkbar ist beispielsweise eine Plugin-Architektur mit ¨ offentlichen Schnitt- stellen, die das dynamische Nachladen von Funktionalit¨ at erlaubt. Eine an- dere L¨ osung ist die Integration einer Skriptsprache mit einer entsprechenden Laufzeitumgebung, damit Erweiterung direkt die internen Daten manipulie- ren k¨ onnen.

In der Softwareentwicklung sind zuk¨ unftige Anforderungen und Umwelt- bedingungen nicht absehbar. So k¨ onnen sich die Anforderung des Kunden z. B. durch Marktverschiebungen drastisch ¨ andern. Einen ¨ ahnlich starken Einfluss haben ¨ Anderungen der verwendeten Technologie. In beiden F¨ allen 52 z. B. Objektorientierung, Strukturierung, logische Programmierung, Aspektorientie- rung, usw.

8 EMERGENZ IN DER SOFTWAREENTWICKLUNG 72

ist der Einfluss und die Steuerungsm¨ oglichkeit durch das Projektteam re- lativ gering. Durch diese Unf¨ ahigkeit die Zukunft vorherzusagen oder so- gar vorherzubestimmen, ist jede Planung lediglich eine Hypothese ¨ uber die Zukunft. Pl¨ ane k¨ onnen nicht realisiert werden, sondern es kann lediglich uberpr¨ uft werden, ob die Planung der tats¨ achlichen Entwicklung entsprach. ¨ Es muss dabei daran erinnert werden, dass Sch¨ atzungen immer nur mit ei- ner bestimmten Wahrscheinlichkeit richtig sind. Umso k¨ urzer und zeitlich nah der von einer Sch¨ atzung abgedeckte Zeitraum ist, umso h¨ oher ist die Wahrscheinlichkeit einer richtigen Sch¨ atzung.

Der Vergleich mit anderen Projekten ist oft wenig hilfreich. Schon kleine ¨ Anderungen der Bedingungen, z. B. in der Zusammensetzung des Projekt- teams, k¨ onnen durch die Vernetzung und R¨ uckkoppelung riesige Auswirkun- gen auf den Projektverlauf haben, was einen Vergleich unm¨ oglich macht. Letztendlich sind Organisationen immer einzigartig. Formal gesehen k¨ on- nen Organisationen die selbe Struktur aufweisen, dennoch besteht eine Or- ganisation nicht nur aus Struktur, sondern auch aus einzigartigen Indi- viduen. Dadurch bildet jede Organisation eine eigene Kultur, die es zu ber¨ ucksichtigen gilt.

Das prim¨ are Ziel der Softwareentwicklung ist es, unter den oben ge- nannten Bedingungen Software mit entsprechender Qualit¨ at, im gegebe- nen Zeitrahmen und unter Einhaltung des Projektbudgets zu entwickeln. Das sekund¨ are Ziel lautet, zuk¨ unftige Entwicklungen vorzubereiten (vgl. Coc03, S. 51ff). Dies kann z. B. durch Wiederverwendung bereits entwi- ckelter Komponenten, wartungsfreundliche Gestaltung der Software usw. geschehen. Trotzdem ist eine gut wartbare Software nutzlos, wenn sie vom Kunden als nicht ausreichend betrachtet wird und somit das prim¨ are Ziel eine die Anforderungen erf¨ ullenden Software verfehlt wurde. Die meisten heute bekannten Mittel zur Erreichung der beiden Ziele in einer emergenten Welt wurden bereits im letzten Kapitel und im Kapitel 5 auf Seite 25 aufgezeigt. Deshalb seien sie lediglich auszugsweise an dieser Stelle kurz genannt:

• Management gibt Rahmen vor und sorgt f¨ ur die n¨ otigen Ressourcen

• Entscheidungen werden prim¨ ar auf der Ebene der Wertsch¨ opfung ge- troffen

• Abflachung der Hierarchie

• R¨ uckkoppelung im Projektteam durch direkte Kommunikation und Kommunikationsmittel

• Kunde wird als Partner verstanden

• Kunde gestaltet Produkt aktiv mit

8 EMERGENZ IN DER SOFTWAREENTWICKLUNG 73

• partnerschaftliches Verh¨ altnis zu externen Anbietern (z. B. f¨ ur Soft- warekomponenten oder Beratung)

• inkrementelle Entwicklung mit kurzen Releasezyklen zur Sicherstel- lung von R¨ uckmeldung durch Kunden

• Aufwandssch¨ atzungen und Planung f¨ ur kurze Zeitr¨ aume

• Optimierung von F¨ ahigkeiten und nicht von Prozessen

• Anpassung des Vorgehensmodell an das Projekt und nicht umgekehrt

• breite Nutzung von Werkzeugen zur Unterst¨ utzung, aber nicht Werk- zeug im Zentrum der Aufmerksamkeit

• h¨ aufige Integration, automatisierte Tests, Refaktorisierung, Program- mierung in Paaren, Programmierstandards, usw.

• Implementierung einer lernenden Organisation, z. B. ¨ uber Reflexion und Paarprogrammierung

• Messung Projekterfolg an ausgeliefertem Produkt und nicht an Ein- haltung von formalen Prozessen

• Mitarbeiter sind zu einem Zeitpunkt lediglich an einem Projekt betei- ligt, damit sie den gr¨ oßtm¨ oglichen Anteil am Projektwissen erlangen k¨ onnen

Es existieren Berichte von Unternehmen wie Microsoft (vgl. CS96), die ent- sprechende Verfahren in der Softwareentwicklung bereits seit Jahren erfolg- reich einsetzen. Ein weiteres praktisches Beispiel f¨ ur erfolgreiche Bew¨ alti- gung von Emergenz ist die ” OpenSource“ Bewegung, die Software vollst¨ an- dig selbstorganisiert entwickelt.

Im Hinblick auf die Fragestellung dieser Arbeit kann davon ausgegangen werden, dass bereits heute eine bewusste Bew¨ altigung von Emergenz statt- findet. Ob dies allerdings mit der Kenntnis des neuen Weltbildes stattfindet, erscheint fraglich. Eine Verbesserung und Erweiterung der verwendeten Mit- tel in Zukunft ist sehr wahrscheinlich. Gerade im Wirtschaftsbereich wurden bereits einige Mittel langfristig erprobt und kommen erst jetzt in der Soft- wareentwicklung zum Einsatz. Interessant ist z. B. die Fragestellung, wie das Projektwissen m¨ oglichst ohne aufwendige Dokumentationserstellung ge- sichert werden kann.

8.3 Gestaltung von Emergenz in der Softwareentwicklung

Ebenso interessant wie die Frage nach Bew¨ altigung von Emergenz ist die Aufgabe Emergenz bewusst zu gestalten. W¨ ahrend im vorherigen Punkt eine lange Liste von Mittel aufgef¨ uhrt werden konnte, ist dies f¨ ur die Gestaltung

8 EMERGENZ IN DER SOFTWAREENTWICKLUNG 74

von Emergenz in der Softwareentwicklung (noch) nicht m¨ oglich. Die Gestal- tung setzt voraus, dass ein System geschaffen wird, in dem Nicht-Linearit¨ at und Nicht-Determinismus m¨ oglich sind, damit Selbstorganisation auftreten kann. Eine direkte Anwendung findet momentan lediglich durch Emergent Design 53 statt. Hier erfolgt die Entstehung einer Softwarearchitektur durch die Anwendung eines dynamischen Prozesses. Es findet keine pr¨ azise Pla- nung statt. ¨ Uberarbeitungen sind erlaubt und werden direkt gefordert. Es kann davon ausgegangen werden, dass die Mittel zur Bew¨ altigung von Emergenz selbst in ihrer Gesamtheit Emergenz hervorrufen. ” Die Verfahren und Prinzipien [von Extreme Programming] 54 arbeiten zusammen und un- terst¨ utzen einander gegenseitig, um eine Synergie zu erzeugen, die gr¨ oßer als die Summe der einzelnen Teile ist.“ (Bec00, S. 149) Dieser Punkt bedarf zuk¨ unftig weiterer Untersuchungen.

Wahrscheinlich existieren viele weitere Verfahren und M¨ oglichkeiten zur Gestaltung von Emergenz in der Softwareentwicklung. So ist es durchaus denkbar das in der Sozionik entwickelte Agentenkonzept in der Softwareent- wicklung umzusetzen. In dieser Vision sind autonome Agenten f¨ ur das De- sign, die Implementierung, den Test und die Dokumentation einer Software verantwortlich. Lediglich die Analyse ist durch den Menschen durchzuf¨ uhren und die daraus abgeleiteten Anforderungen den Agenten mitzuteilen. Da- bei ist es vorstellbar, dass f¨ ur verschiedene Teilbereiche der zu erstellenden Software verschiedene spezialisierte Agenten eingesetzt werden. Anhand der den Agenten ¨ ubergebenen Anforderungen stellen diese Hypothesen f¨ ur die zu entwickelnde Software auf. Eine ¨ Uberpr¨ ufung der Hypothesen durch den Entwickler oder – idealerweise – durch den zuk¨ unftigen Nutzer, ist sinnvoll. Dieser Ansatz der Softwareentwicklung beruht somit auf der Verarbei- tung von Wissen. Dabei geht der Ansatz aber ¨ uber die Nutzung einer lo- gischen Programmiersprache wie Prolog oder Lisp hinaus, da explizit keine Programmierung durch den Menschen erfolgt. Auf der anderen Seite kann dieser Ansatz gegen Verfahren wie Model Driven Architecture abgegrenzt werden, da bei dieser Vision kein Design durch den Nutzer erfolgt, sondern lediglich die Analyse der Nutzeranforderungen. Das Design und die darauf folgenden Arbeitsergebnisse entstehen durch sich selbstorganisierende Agen- ten. Diese lassen sich somit nicht auf ” intelligente Quelltextgeneratoren“ in ihrer Funktion reduzieren, da sie vor der eigentlichen Quelltextgenerie- rung zun¨ achst ein Design entwickeln. Bereits heute existieren einige grund- legende Forschungsarbeiten zu dieser Vision, wie z. B. das Tropos Projekt (vgl. z. B. GPS02) 55 . Neben der Sozionik k¨ onnten die Erfahrungen aus der K¨ unstlichen Intelligenz Forschung im Bereich Wissensrepr¨ asentation (vgl. G¨ or00, S. 153ff) genutzt werden.

53 ausf¨ uhrlich dazu in Kapitel 7.6 auf Seite 65 54 Anmerkung des Verfassers 55 weitere Informationen auch online verf¨ ugbar unter http://www.troposproject.org/

8 EMERGENZ IN DER SOFTWAREENTWICKLUNG 75

Im Bereich Gestaltung von Emergenz in der Softwareentwicklung sollten deshalb zuk¨ unftige Forschungsarbeiten ansetzen. F¨ ur die Beantwortung der Fragestellung dieser Arbeit bedeutet dies, dass im Bereich bewusster Gestal- tung und Nutzung von Emergenz in der Softwareentwicklung noch gewaltige Chancen stecken und erst eine kleine Anwendung dieser M¨ oglichkeit statt- findet.

8.4 Zusammenfassung Emergenz in der Softwareentwicklung

In diesem Kapitel konnte die Fragestellung dieser Arbeit beantwortet wer- den. Dazu erfolgte die Beantwortung jeweils getrennt f¨ ur die beiden in der Systematik entwickelten Teilbereiche. 56 Im nun abschließenden Kapitel wird die Argumentation dieser Arbeit kompakt zusammengefasst. 56 Die Systematik wurde in Kapitel 4.4 auf Seite 24 eingef¨ uhrt.

9 ZUSAMMENFASSUNG 76

9 Zusammenfassung

Diese Arbeit beantwortet die Frage, ob Emergenz in der Softwareentwicklung bereits eingesetzt wird oder ob der zuk¨ unftige Einsatz ein Potenzial zur Produktivit¨ ats- und Qualit¨ atssteigerung darstellt.

Deshalb wurde zun¨ achst die Bedeutung des Begriffes Emergenz ermittelt und ein Modell zum Verst¨ andnis von Emergenz als Transformationsprozess erarbeitet. Darauf aufbauend wurde untersucht, welche Erkl¨ arungsmodelle bereits heute f¨ ur Emergenz existieren. Dabei konnte festgestellt werden, dass die verschiedenen Erkl¨ arungsmodelle Nicht-Linearit¨ at und Nicht-Determi- nismus beschreiben. Es wurde eine Arbeitsdefinition f¨ ur die Begriffe gefun- den. Das Zusammenspiel von Nicht-Linearit¨ at und Nicht-Determinismus ist die Grundlage von Selbstorganisation. Selbstorganisation wird im allgemei- nen Sprachgebrauch als die Erscheinungsform von Emergenz betrachtet. Bei der genaueren Untersuchung der beiden Begriffe Nicht-Linearit¨ at und Nicht-Determinismus zeigte sich, dass diese die philosophische Basis eines Weltbildes sind, das sich vom allgemein anerkannten mechanischen Weltbild nach Newton unterscheidet. Durch den Vergleich des mechanischen Weltbil- des und des neuen Weltbildes, konnten die unterschiedlichen Grundansichten verdeutlicht werden. Demnach steht das mechanische Weltbild f¨ ur eine prin- zipiell berechenbare Welt, gepr¨ agt von Linearit¨ at und Determinismus. F¨ ur die weitere Untersuchungen im Rahmen dieser Arbeit wurde die G¨ ultigkeit des neuen Weltbild als philosophische Grundlage gew¨ ahlt. Da- bei wurde eine Welt nach dem neuen Weltbild als emergente Welt bzw. als Emergenz in der Softwareentwicklung bezeichnet. Um die weiteren Betrach- tungen zu systematisieren, wurde zwischen einer reinen Bew¨ altigung und einer bewussten Gestaltung der emergenten Welt unterschieden.

Anschließend wurde untersucht, welche Konzepte und Theorien zur Be- w¨ altigung und Gestaltung einer emergenten Welt in der Wirtschaftsinforma- tik existieren. Die identifizierten Vertreter wurden der Systematik entspre- chend eingeordnet.

Bevor eine Betrachtung von Emergenz in der Softwareentwicklung erfol- gen konnte, wurde zun¨ achst die klassische Softwareentwicklung dargestellt. Dabei konnte gezeigt werden, dass die klassische Softwareentwicklung vom mechanischen Weltbild nach Newton gepr¨ agt ist. Dies ¨ außert sich in der Betrachtung von Softwareentwicklung als Ingenieurdisziplin.

Als Gegenvorschlag zur klassischen Softwareentwicklung wurde die agile Softwareentwicklung mit zwei konkreten Vertretern vorgestellt. Dabei wur- den die Gemeinsamkeiten der agilen Vertreter untersucht. Die philosophi- sche Basis der agilen Softwareentwicklung ist das neue Weltbild. Dement- sprechend erfolgte eine Einordnung der in der agilen Softwareentwicklung aufgezeigten Mittel und Verfahren in die Systematik. Die meisten Mittel und Verfahren dienen aber lediglich einer Bew¨ altigung von Emergenz in der Softwareentwicklung.

9 ZUSAMMENFASSUNG 77

Abschließend erfolgte die Beantwortung der Fragestellung dieser Arbeit. Dabei war eine Differenzierung der Antwort gem¨ aß der entwickelten Syste- matik notwendig. Demnach findet bereits heute eine Bew¨ altigung von Emer- genz in der Softwareentwicklung statt. Hierbei handelt es sich prim¨ ar um eine Optimierung und Weiterentwicklung der bereits bekannten Verfahren und Mittel. Im zweiten Bereich Gestaltung von Emergenz in der Softwareent- wicklung ließen sich kaum angewandte Konzepte identifizieren. Hier besteht großer Forschungsbedarf und es bieten sich große Chancen f¨ ur die Software- entwicklung.

LITERATUR 78

Literatur

[Agi01] AgileAlliance: Das Manifest der agilen Softwareentwicklung, 2001. – online verf¨ ugbar unter http://www.agilemanifesto.org/

[Art96] Arthur, W. B.: Increasing Returns and the New World of Business. In: Harvard Business Review (1996),

Nr. July-August, S. 100–109. – http://www.santafe.edu/arthur/

[Bec00] Beck, Kent: Extreme Programming: Das Manifest. M¨ unchen : Addison Wesley Longman Inc., 2000

[BF01] Beck, Kent ; Fowler, Martin: Extreme Programming planen. M¨ unchen : Addison Wesley Longman Inc., 2001

[Bra93] Braitenberg, Valentin: Vehikel - Experimente mit kyberne- tischen Wesen. Reinbek bei Hamburg : Rowohlt Taschenbuch Verlag GmbH, 1993

[Bro01a] Kap. No Silver Bullet - Essence and Accident in Software En- gineering In: Brooks, Frederick P.: The Mythical Man-Month. 15., Aufl. New York : Addison Wesley Longman Inc., 2001, S. 177–203

[Bro01b] Kap. The Mythical Man-Month In: Brooks, Frederick P.: The Mythical Man-Month. 15., Aufl. New York : Addison Wesley Longman Inc., 2001, S. 13–28

[Bul96] Bullinger, Hans-J¨ org ; Warnecke, Hans-J¨ urgen (Hrsg.): Neue Organisationsformen im Unternehmen: ein Handbuch f¨ ur das moderne Management. Berlin : Springer, 1996

[B¨ uh87] B¨ uhl, Walter L.: Grenzen der Autopoiesis. In:

K¨ olner Zeitschrift f¨ ur Soziologie und Sozialpsychologie (1987), Nr. 39, S. 225–254. – online verf¨ ugbar unter

http://www.vordenker.de/buehl/wlb grenzen-autopoiesis.pdf

[Cav00] Cavallo, David P.: Technological Fluency and the Art of Motor- cycle Maintenance: Emergent Design of Learning Environments, Massachusetts Institute of Technology, Diss., 2000. – online verf¨ ugbar unter http://web.media.mit.edu/∼cavallo/

[Coc02] Cockburn, Alistair: Crystal Cle- ar. 2002. – auch online verf¨ ugbar unter http://alistair.cockburn.us/crystal/books/cc/crystalclear.zip

LITERATUR 79

[Coc03] Cockburn, Alistair: Agile Software-Entwicklung. Bonn : mitp- Verlag, 2003

[Col03] Coldewey, Jens: ¨

Anderbare Software: Was Softwareentwick- lung mit der Thermodynamik verbindet. In: Objekt Spek- trum (2003), Nr. 1, S. 26–30. – online verf¨ ugbar unter http://www.coldewey.com/publikationen/Kolumne.html

[CS96] Cusumano, Michael A. ; Selby, Richard W.: Die Microsoft- Methode: sieben Prinzipien, wie man ein Unternehmen an die Weltspitze bringt. Freiburg i. Br. : Rudolf Haufe Verlag, 1996

[Dud00] Duden: Duden, Das große Fremdw¨ orterbuch. 2., neu bearb., erw. u. aktualisierte Aufl. Hannover : Bibliographisches Institut & F. A. Brockhaus AG, 2000

[Ess00] Esser, Hartmut: Soziologie Spezielle Grundlagen. Bd. 2: Die Konstruktion der Gesellschaft. 1. Aufl. Frankfurt/Main : Cam- pus Verlag GmbH, 2000

[Fis93] Fischer, Hans R.: Murphys Geist oder die gl¨ ucklich abhanden gekommene Welt. Zur Einf¨ uhrung in die Theorie autopoietischer Systeme. In: Autopoiesis. 2., korr. Aufl. Heidelberg : Carl-Auer- Systeme Verlag, 1993, S. 9–37

[Fli99] Fliedner, Dietrich: Komplexit¨ at und Emergenz in Gesellschaft und Natur. Frankfurt/Main; Berlin; Bern; Br¨ ussel; New York : Europ¨ aischer Verlag der Wissenschaften Peter Lang GmbH, 1999

[Fl¨ a98] Fl¨ amig, Michael: Naturwissenschaftliche Weltbilder in Mana- gementtheorien. Frankfurt/Main; New York : Campus Verlag,

1998

[Fow00] Fowler, Martin: Refactoring: Wie Sie das Design vorhandener Software verbessern. New York : Addison Wesley Longman Inc.,

2000

[Gam96] Gamma, Erich: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. New York : Addison Wesley Long- man Inc., 1996

[Geo13] Georges, Karl E.: Lateinisch-Deutsches Handw¨ orterbuch. Han- nover und Leipzig : Hahnsche Buchhandlung, 1913

[GF03] Gehle, Michael ; Feldhoff, Ellen: Quo vadis Knowledge Ma- nagement? In: Zukunft des Managements: Perspektiven f¨ ur die Unternehmensf¨ uhrung. Z¨ urich : vdf Hochschulverlag AG, 2003, S. 165–176

LITERATUR 80

[GI03] GI: Organic Computing / VDE, ITG, GI. 2003.

– Positionspapier.

ev.de/informatik/presse/presse 030710.shtml

[GPS02] Giunchiglia, Fausto ; Perini, Anna ; Sannicol` o, Fabrizio: Knowledge Level Software Engineering. In: Meyer, John- Jules C. (Hrsg.) ; Tambe, Milind (Hrsg.): Intelligent agents VIII: agent theories, architectures, and languages Bd. LNAI 2333. Ber- lin : Springer, 2002, S. 6–20

[GS02] Gorges-Schleuter, Martina: Evolution¨ are Algorithmen - Vor- bild Natur. In: Keller, Hubert B. (Hrsg.): Maschinelle Intelli- genz. Braunschweig; Wiesbaden : Vieweg & Sohn Verlagsgesell- schaft mbH, 2002, S. 243–280

[G¨ or00] G¨ orz, G¨ unther (Hrsg.): Handbuch der K¨ unstlichen Intelligenz. 3., vollst. ¨ uberarb. Aufl. M¨ unchen : Oldenbourg Wissenschafts- verlag GmbH, 2000

[Hak90] Haken, Hermann: Synergetik: eine Einf¨ uhrung. 3., erw. Aufl. Berlin : Springer, 1990

[Hak91] Haken, Hermann: Synergetik: Die Lehre vom Zusammenwirken.

2. Aufl. Frankfurt/Main; Berlin : Verlag Ullstein GmbH, 1991

[Hei86] Heisenberg, Werner: Der Teil und das Ganze. 6., unv. Aufl. M¨ unchen : R. Piper & Co. Verlag, 1986

[Hig02] Highsmith, Jim: Agile Software Development Ecosystems. Bo- ston : Addison Wesley Longman Inc., 2002

[HW90] Haken, Hermann ; Wunderlin, Arne: Die Anwendung der Syn- ergetik auf Musterbildung und Mustererkennung. In: Kratky, Karl W. (Hrsg.) ; Wallner, Friedrich (Hrsg.): Grundprinzipien der Selbstorganisation. Darmstadt : Wissenschaftliche Buchge- sellschaft, 1990, S. 18–30

[KK92] Kohn, Wolfgang ; K¨ uppers, G¨ unter: Die nat¨ urlichen Ursachen der Zwecke. In: Selbstorganisation - Jahrbuch f¨ ur Komplexit¨ at in der Natur-, Sozial- und Geisteswissenschaften (1992), Nr. 3, S. 31–50

[Kra96] Kramer, Ulrich: Vom Elend des Fort-

schritts. 1996. – online verf¨ ugbar unter http://www.vordenker.de/daselend/daselend.htm

[Mal01] Malsch, Thomas: Zur Sozionik. In: Sozionik Aktuell (2001), Nr. 1. – online verf¨ ugbar unter http://www.sozionik-aktuell.de/

LITERATUR 81

[Men98] Menge, Hermann: Langenscheidts Taschenw¨ orterbuch Latein. 48., Aufl. Berlin und M¨ unchen : Langenscheidts KG, 1998

[Mil02] Milberg, Joachim: Erfolg in Netzwerken. In: Milberg, Joa- chim (Hrsg.) ; Schuh, G¨ unther (Hrsg.): Erfolg in Netzwerken. Berlin : Springer, 2002, S. 3–16

[M¨ ul00] M¨ uller, Johann-Adolf: Systems Engineering. Wien : Manz- Verlag Schulbuch (Fortis), 2000

[Pas92] Pasche, Markus: Synergetik und Evolutorische ¨ Okonomik / Universit¨ at Hannover Fachbereich Wirtschaftswissenschaften. 1992 ( 179). – Diskussionspapier

[Pit00] Pitz, Thomas: Anwendung Genetischer Algorithmen auf Hand- lungsb¨ aume in Multiagentensystemen zur Simulation sozialen Handelns. Frankfurt am Main : Europ¨ aische Hochschulschriften,

2000

[PJS94] Peitgen, Heinz-Otto ; J¨ urgens, Hartmut ; Saupe, Dietmar: Chaos: Bausteine der Ordnung. Berlin : Klett-Cotta/Springer- Verlag, 1994

[Pop87] Popper, Karl R.: Das Elend des Historizismus. 6., durchges. Aufl. T¨ ubingen : J. C. B. Mohr (Paul Siebeck), 1987

[Rad04] Rademacher, Rochus: Organic-Computing wird Generaltech- nik. In: Computer Zeitung (2004), Nr. 10, S. 1. – siehe auch weitere Artikel in dieser Ausgabe auf S. 6

[Sta94] Stark, Carsten: Eine kritische Einf¨ uhrung in die Luhmannsche Systemtheorie. Hamburg : Verlag Dr. Kova˘ c, 1994

[Sta99] Staehle, Wolfgang H.: Management: eine verhaltenswissen- schaftliche Perspektive. 8., ueberarb. Aufl. M¨ unchen : Franz Vahlens Verlag, 1999

[St¨ o94] St¨ ockler, Manfred: Selbstorganisation und Reduktionismus. In: Selbstorganisation - Jahrbuch f¨ ur Komplexit¨ at in der Natur-, Sozial- und Geisteswissenschaften (1994), Nr. 5, S. 149–160

[Ver02] Versteegen, Gerhard (Hrsg.): Software-Management: Beherr- schung des Lifecycles. Berlin : Springer, 2002

[War02] Warnecke, Hans-J¨ urgen: Agilit¨ at im Wettbewerb erreichen

- das Fraktale Unternehmen. In: Milberg, Joachim (Hrsg.) ; Schuh, G¨ unther (Hrsg.): Erfolg in Netzwerken. Berlin : Sprin- ger, 2002, S. 263–274

LITERATUR 82

[Wei01] Weik, Elke ; Lang, Rainhart (Hrsg.): Moderne Organisations- theorien. Wiesbaden : Verlag Dr. Th. Gabler GmbH, 2001

[Wel99] Wells, Don: Homepage ExtremeProgramming.org.

1999. – einige Grafiken in Anlehnung an Grafiken bei http://www.extremeprogramming.org/

[Wie71] Wiener, Norbert: Kybernetik: Regelung und Nachrich- ten¨ ubertragung in Lebewesen und Maschine. 34. – 40. Aufl. Rein- bek bei Hamburg : Rowohlt-Taschenbuch-Verlag, 1971

[WJR94] Womack, James P. ; Jones, Daniel T. ; Roos, Daniel: Die zweite Revolution in der Autoindustrie: Konsequenzen aus der weltweiten Studie aus dem Massachusetts Institute of Technology. 8., durchges. Aufl. Frankfurt/Main; New York : Campus Verlag,

1994

[ZBGK01] Zuser, Wolfgang ; Biffl, Stefan ; Grechenig, Thomas ; K¨ ohle, Monika: Software Engineering: mit UML und dem Uni- fied Process. M¨ unchen : Pearson Studium, 2001

STICHWORTVERZEICHNIS 83

Stichwortverzeichnis

A E

Agent . . . . . . . . . . . . . . . . . . . . . . . . . 74 Definition . . . . . . . . . . . . . . . . . 31 Eigenschaften . . . . . . . . . . . . . 31 Multi-Agent-System . . . . . . 31 f Agilit¨ at . . . . . . . . . . . . . . . . . . . . 61, 64 Begriff . . . . . . . . . . . . . . . . . . . . 63 Definition . . . . . . . . . . . . . . . . . 27 Anforderung ¨ Anderbarkeit . . . 43, 64, 69, 71 Anpassung F¨ ahigkeit . . . . . . . . . . . . . . . . . 28 Autopoiesis . . . . . . . . . . . . . . . . . . 17 f operative Geschlossenheit . 17 Selbstreferentialit¨ at . . . . . . 17 f strukturelle Koppelung . . . 17 f Zirkularit¨ at . . . . . . . . . . . . . . . 17 B Blackbox . . . . . . . . . . . . . . . . . . 18, 52 C Chaos . . . . . . . . . . . . . . . . . . . . . . . . . 14 Attraktor . . . . . . . . . . 14, 16, 19 seltsamer . . . . . . . . . . . . . . 15 f Bifurkation . . . . . . . . . . . 15 f, 19 deterministisches . . . . . . 14, 16 Fluktuation . . . . . . . . . . . . . . . 15 Parameterraum . . . . . . . . . . 15 f Phasenraum . . . . . . . . . . . . . 14 f Theorie. . . . . . . . . . . . . . . .14, 19 Trajektorie . . . . . . . . . . . . . . 14 ff Crystal . . . . . . . . . . . . . . . . . . . . . . . . 58 Charakterisierung Projekt . 58 Clear . . . . . . . . . . . . . . . . . . . . . 60 Grundwerte . . . . . . . . . . . . . . . 59 Methodikfamilie . . . . . . . . . . . 58

D

Determinismus . . . . . . . . . . . . 22, 45

STICHWORTVERZEICHNIS 84

H Definition . . . . . . . . . . . . . . . . . 19

Hauptsatz Thermodynamik erster . . . . . . . . . . . . . . . . . . . . . . 9 zweiter . . . . . . . . . . . . 7, 11 ff, 23 Hersteller . . . . . . . . . . . . . . . . . . . . 37 f Historizismus . . . . . . . . . . . . . . . 8, 17

I

Information. . . . . . . . . . . . . . . .13, 29

K Kommunikation direkt . . . . . . . . . . . . . . . . . 58, 60 gemischt . . . . . . . . . . . . . . . . . . 60 indirekt . . . . . . . . . . . . . . . . . . . 58 Komplexionsprozess . . . . . . . . . . . . 8 Konstruktivismus . . . . . . . . . . . . . 25 Kostenkurve klassisch . . . . . . . . . . . . . . . . . . 43 modern . . . . . . . . . . . . . . . . . . . 49 Kunde . . . . . . . . . . . . . . . . . . . . . . . 37 f Kybernetik . . . . . . . . . . . . . . . 17 f, 22 L Lean Management . . . . . . . . . . . . . . 27 Production . . . . . . . . . . . . . . . . 27 Linearit¨ at . . . . . . . . . . . . . . . . 22, 45 f M Markttheorie . . . . . . . . . . . . . . 30, 35 Model Driven Architectur . . . . . 44 N Neuronales Netz . . . . . . . . . . 32 f, 36 Nicht-Determinismus . . 13, 16, 19, 23, 36, 66 Definition . . . . . . . . . . . . . . . . . 19 Gr¨ unde . . . . . . . . . . . . . . . . . . . 71 Nicht-Linearit¨ at12, 16, 19, 23, 26, Ziel 36, 66

STICHWORTVERZEICHNIS 85

prim¨ ar . . . . . . . . . . . . . . . . . . 72 Rational Unified Process . . 42

sekund¨ ar . . . . . . . . . . . . . . . . 72 Sozionik . . . . . . . . . . . . . . 31 f, 36, 74 Synergetik . . . . . . . . . . . . 11 – 14, 19 Fluktuation . . . . . . . . . . . . . . . 12 Ordner . . . . . . . . . . . 12 f, 19, 29 Phasen¨ ubergang . . . . . . . 12, 19 synergetischer Computer . . 34 Versklavung . . . . . . . . . . . 12, 29 Zirkularit¨ at . . . . . . . . . . . . . . . 12 System . . . . . . . . . . . . . . . . . . . . . . . . . 7 Element . . . . . . . . . . . . . . . . 7, 11 Grenze . . . . . . . . . . . . . . . . . . . . . 7 Wissensmanagement . . . . . . . 26, 35 geschlossen . . . . . . . . . . . 7, 17 offen . . . . . . . . . . . . . . . . . . . . . 7 Ordnung . . . . . . . . . . . . . . . . . . . 7 Relationen . . . . . . . . . . . . . . 7, 11 Struktur . . . . . . . . . . . . . . . . . . . 7 Zustand . . . . . . . . . . . . . . . . 8, 11 aktueller . . . . . . . . . . . . . . . . . 7 Systematisierung . . . . . . . . . . 35, 66 Einf¨ uhrung . . . . . . . . . . . . . . . . 24 Kategorie Bew¨ altigung 24, 35, 66, 68, 73 Kategorie Gestaltung . 24, 35, 66, 73 f

T

Theorie steigender Ertr¨ age28 f, 35 Transaktionskostentheorie . . . . . 30 Transformation . . . . . . . . . . . . . 8, 19 Prozess . . . . . . . . . . . . . . . . . 8, 11 Regeln . . . . . . . . . . . . . . . . . . . . . 8

V

Vernetzung . . . . . . . . . . . . 13, 19, 70 virtuelles Unternehmen . . . . 26, 35 Vorgehensmodell . . . . . . . . . . . . . . 38 Code and Fix“ . . . . . . . 39, 41 ” Aktivit¨ at . . . . . . . . . . . . . . . . . . 38 Artefakt . . . . . . . . . . . . . . . . . . 38 Definition . . . . . . . . . . . . . . . . . 38 iterativ inkrementell . . 41 f, 69

Ehrenw¨ ortliche Erkl¨ arung

Hiermit erkl¨ are ich, dass ich die vorliegende Diplomarbeit selbst¨ andig durch- gef¨ uhrt und alle mir zuteil gewordenen Hilfen sowie das benutzte Schrifttum am Ende der Arbeit angegeben habe.

. . . . . . . . . . . . . . . . . .

Sebastian Stein