1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article SYSTEM "http://www.ecromedos.net/dtd/2.0/ecromedos.dtd">
<article lang="de_DE" fontsize="12pt" papersize="a4paper" div="12" bcor="0cm"
secnumdepth="3" secsplitdepth="0">
<head>
<title>Demands that Stress Patterns</title>
<subtitle>Wie Anforderungen Unternehmenskulturen auf die Probe stellen</subtitle>
<author>Sven Eisenhauer</author>
<author>Tobias Koch</author>
<date>8. Januar 2010</date>
<publisher>
Seminar Systems Thinking, Wintersemester 2009/2010<br/>
Hochschule Darmstadt<br/>
Referent: Herr Prof. Dr. Andelfinger<br/>
</publisher>
</head>
<make-toc depth="3" lof="no" lot="no" lol="no"/>
<abstract>
<p>
Im ersten Band &endash; <i>Systems Thinking</i> &endash; seiner Reihe von Büchern
zum Qualitätsmanagement in der Software-Entwicklung, schildert Gerald M.
Weinberg wie typische kulturelle Muster in Software-Firmen die Qualität der
Entwicklungsprozesse und des Managements widerspiegeln. Unter Betrachtung
der inneren und äußeren Anforderungen an Software entwickelnde Organisationen
veranschaulicht er, wie das Verharren in einem solchen Muster die
Entwicklung einer Organisation hemmen oder sogar deren Fortbestehen
gefährden kann. Gleichzeitig liefert er eine Fülle von Denkanstößen und
Vorschlägen für Methoden, die dabei helfen können, besagte Firmenkulturen
in positiver Weise zu beeinflußen und zu verändern.</p>
<p>
Dieser Artikel fasst die Kerngedanken aus dem dritten Teil &endash;
<i>Demands that Stress Patterns</i> &endash; des Buches zusammen
und erläutert anhand konkreter Beispiele aus dem Buch, warum Software-Entwicklung
an sich eine hoch-komplexe Angelegenheit ist, wie man der Komplexität Herr werden
kann, und welche zusätzlichen äußeren Anforderungen sich beim Projektgeschäft mit
Kunden ergeben.
</p>
</abstract>
<section>
<title>Reifegradstufen von Entwicklungsprozessen</title>
<p>In <cite idref="bib:WEINBERG92"/> befaßt sich Gerald M. Weinberg mit den Problemen und
Heraus<y/>forder<y/>ungen, denen sich Software produzierende Organisationen früher oder
später stellen müssen. Seinen Analysen legt er <qq>kulturelle Muster</qq> zugrunde, die
in ihrer Beschreibung in etwa dem Reifegrad von Entwicklungsprozessen nach dem Capability Maturity
Modell (CMM) <cite idref="bib:CMMI06"/> entsprechen. Für die weiteren Ausführungen in
diesem Artikel sind davon die Stufen 1 bis 3 von Bedeutung:</p>
<dl>
<dt>Stufe 1 - initial:</dt>
<dd><p>Nach Weinberg, der das entsprechende kulturelle Muster <qq>variabel</qq> nennt,
gibt es auf dieser Stufe <qq>kein Konzept von Management als
Entwicklungswerkzeug</qq>. Nach dem CMM sind Prozesse auf dieser Reifegradsstufe
zufällig und chaotisch und die beherbergende Organisation trifft keine
Maßnahmen, um die Entstehung stabiler Prozesse zu fördern. Der Erfolg von
Projekten auf dieser Stufe hängt in erster Linie vom Engagement und den
Fähigkeiten der beteiligten Personen ab.</p></dd>
<dt>Stufe 2 - geregelt:</dt>
<dd><p>Auf dieser Stufe werden Prozesse laut CMM nach gefestigten Richtlinien
durchgeführt. Qualität und Performanz werden ansatzweise messbar gemacht.
Weinberg nennt das entsprechende kulturelle Muster <qq>routiniert</qq>, weil seiner
Beobachtung nach Prozesse in diesem Muster nicht hinterfragt, sondern blind
angewendet werden. Als charakteristisch für dieses Muster nennt er das
Konzept des Supermanagers, dem der gesamte Projekterfolg zugeschrieben wird.</p></dd>
<dt>Stufe 3 - definiert:</dt>
<dd><p>Weinberg nennt das kulturelle Muster, das dieser Entwicklungsstufe
entspricht, <qq>steuernd</qq>, weil die Manager auf dieser Stufe vorausschauend und
unter Berücksichtigung der ihnen bekannten, aktuellen Entwicklungen
entscheiden. Nach CMM sind die Prozesse auf dieser Stufe <qq>genau [...]
verstanden und werden anhand von Standards, Arbeitsverfahren, Werkzeugen
und Methoden beschrieben</qq>, mit der Zielsetzung diese in der gesamten
Organisation zu verheinheitlichen.</p></dd>
<dt>Stufe 4 - quantitiv geregelt:</dt>
<dd><p>Laut CCM sind Prozesse auf Stufe 4 definerte Prozesse (Stufe 3), die
<qq>mit Hilfe statistischer und anderer quantitativer Methoden kontrolliert
werden</qq>. Weinberg nennt das kulturelle Muster, das dieser Reifegradstufe
entspricht, <qq>voraussschauend</qq>, was bedeuten soll, dass die Wahl und
Konzeption neuer Prozesse und Methoden unter Berücksichtigung vorausgehender
Erfahrungen erfolgt.</p></dd>
<dt>Stufe 5 - optimierend:</dt>
<dd><p>Wie der Name schon sagt, sind Prozesse auf dieser Stufe nach CMM
quantitativ geregelte Prozesse, deren Performanz ständig verbessert wird.
Weinberg beruft sich bei der Beschreibung dieser Stufe auf Watt S.
Humphrey, nach dessen Aussage auf dieser Stufe die Qualität des
Managements an sich eine zentrale Rolle spielen soll.</p></dd>
</dl>
<p>Nach Weinbergs eigenen Beobachtungen befinden sich die meisten Unternehmen im
Software-Geschäft auf den Stufen 1 oder 2, wenige auf Stufe 3. Die Stufen 4 und 5
sind dagegen selten und auch nur ansatzweise anzutreffen.</p>
</section>
<section>
<title>Komplexität dynamischer Systeme</title>
<p>
Wenn man dynamische Systeme mit Hilfe mathematischer Gleichungssysteme
modelliert, dann steigt der benötigte Rechenaufwand zur Simulation eines
solchen Systems in Abhängkeit von der Größe oder Komplexität des Systems
nicht-linear an. Dieser Zusammenhang wird in Abbildung <ref idref="fig:sizecomplexity"/>
veranschaulicht: Steigt die Komplexität des Systems, dann nimmt sowohl die
Anzahl der Gleichungen, die man benötigt, um das System zu modellieren, als auch
die Anzahl der Parameter zu, wodurch der Berechnungsaufwand insgesamt
exponentiell ansteigt.
</p>
<figure id="fig:sizecomplexity" float="yes">
<caption>
Zusammenhang zwischen der Komplexität eines dynamischen Systems
und dem benötigten Berechnungsaufwand zur Kontrolle des Systems.<br/>
Quelle: <cite idref="bib:WEINBERG92"/>, Seite 131.
</caption>
<img src="../pics/figure9-1.svg" print-width="45%" screen-width="400px"/>
</figure>
<p>
Weinberg nennt diesen Sachverhalt <qq>The Square Law of Computation</qq>. Nach
Weinberg handelt es sich dabei um eine sogenannte <qq>natürliche Dynamik</qq>,
die sich wie das Gravitationsgesetz jedem menschlichen Einfluss entzieht. Im
Gegensatz dazu nennt Weinberg eine Dynamik, die sich aus menschlichen Entscheidungen
und Handlungen entwickelt, eine <qq>Interventionsdynamik</qq>.</p>
<p>Zieht man als Beispiele für dynamische Systeme die Spiele Tic-Tac-Toe und
Schach heran, dann kann man folgende Feststellungen treffen:</p>
<ul>
<li><p>Bei beiden Spielen handelt es sich um abgeschlossene Systeme mit exakt
definierten möglichen Zustandsübergängen.</p></li>
<li><p>Tic-Tac-Toe hat aufgrund des kleinen Spielfelds eine so geringe Komplexität,
dass der gesamte Spielbaum innerhalb von Sekundenbruchteilen berechnet
werden kann. Sogar Hühner können darauf trainiert werden, fehlerfrei Tic-Tac-Toe
zu spielen.</p></li>
<li><p>Schach ist aufgrund des größeren Feldes und der durchschnittlich mehr als 30
Entscheidungsmöglichkeiten pro Zug derart komplex, dass selbst ein
Supercomputer den vollständigen Spielbaum nicht in endlicher Zeit berechnen
kann.</p></li>
</ul>
<p>Wenn man Management als Spiel betrachtet, bei dem es darum geht, die
Kontrolle nicht zu verlieren, dann ist sofort klar, dass dieses Spiel noch
weitaus komplexer ist als Schach, weil es sich</p>
<ol type="a">
<li><p>um kein abgeschlossenes System handelt,</p></li>
<li><p>die Zustandsübergänge nicht genau definierbar sind und</p></li>
<li><p>die Anzahl der Wahlmöglichkeiten pro Zug unermesslich groß ist.</p></li>
</ol>
<p>Da es Menschen gibt, die trotz der Komplexität des Spiels sehr erfolgreich
Schach spielen, äußert sich Weinberg optimistisch, dass auch Management als <qq>Game of
Control</qq> beherrschbar ist, wenn man sich der richtigen Denkweisen und Arbeitsmethoden
bedient.</p>
</section>
<section>
<title>Rückkopplungseffekt zwischen Erfolg und Ambition</title>
<p>Da unsere intellektuellen Kapazitäten von Natur aus begrenzt sind, stößt
ab einer gewissen Komplexität der Problemstellung jeder Mensch an seine
Grenzen, insofern dass sich Anforderungen und mögliche Lösungsansätze ohne
besondere Methodik nicht mehr direkt erschließen.</p>
<p>Da der Mensch aber von Natur aus ehrgeizig ist und dazu tendiert, sich
immer höhere Ziele zu stecken, ist es nur eine Frage der Zeit, bis das zu
lösende Problem einen Umfang annimmt, der ohne besondere Maßnahmen nicht mehr
zu bewältigen ist. Dieser Zusammenhang ist in Abbildung <ref idref="fig:erfolgambition"/>
dargestellt:
Der initiale Erfolg wird zunächst von der intellektuellen Kapazität des Leistungserbringers
bestimmt. Mit zunehmender Erfolgsrate steigen aber auch die Ambitionen, sich komplizierteren
Problemen zu nähern, die Komplexität der Lösung steigt an und wirkt sich schließlich
negativ auf die Erfolgsrate aus. Im Zusammenhang mit Software-Entwicklung schlägt Weinberg
vor, dass dieser Rückkopplungseffekt mit den Methoden des Software-Engineerings beherrschbar
gemacht werden kann.</p>
<figure float="yes" id="fig:erfolgambition">
<caption>Software-Engineering zur Beherrschung des Rückkopplungseffektes zwischen
Erfolg und Ambition.<br/>
Quelle: <cite idref="bib:WEINBERG92"/>, Seite 136.</caption>
<img src="../pics/figure9-5.svg" print-width="80%" screen-width="640px"/>
</figure>
<p>Die Tatsache, dass unsere intellektuelle Kapazität begrenzt ist, wir dazu
tendieren, uns immer schwierigere Aufgaben zu suchen, Problemstellungen aber aufgrund
des <qq>Square Law of Computation</qq> schnell Dimensionen annehmen, die diese Kapazität
übersteigen, nennt Weinberg <qq>Size/Complexity-Dynamic</qq>.</p>
<p>Diese natürliche Dynamik tritt noch in anderen Facetten zum Vorschein, z.B.
in Form der Fault/Location-Dynamic: Mit zunehmendem Unfang eines Software-Quelltextes
nimmt sowohl die Anzahl der Fehler als auch die Anzahl der Zeilen, wo man nach
den Fehlern suchen muss, zu. Damit ist die Fehlerbehebung in Software-Projekten
ein nicht-linearer wachsender Arbeitsaufwand.</p>
<p>Eine weitere Variante ist die People/Interaction-Dynamic, auf die später
noch einmal in einem anderen Zusammenhang näher eingegangen wird. Diese Dynamik
beschreibt die Tatsache, dass bei zunehmender Anzahl der an einem Projekt
beteilgten Personen, die Zahl der Interaktionen zwischen diesen Personen
ebenfalls nicht-linear zunimmt.</p>
</section>
<section>
<title>Was dabei hilft, die Kontrolle zu behalten</title>
<p>Zwar können wir durch Training unsere mentalen Fähigkeiten verbessern,
allerdings nur sehr marginal. Ohne besondere Methodik können selbst die klügsten
Menschen Probleme ab einer gewissen Komplexität nicht mehr lösen, und dass
dieser Fall eher früher als später eintritt, dafür sorgen das Square Law of
Computation und die Size/Complexity-Dynamic.</p>
<p>Wir benötigen deswegen Methoden und Werkzeuge, die uns dabei helfen,
unsere Aufgaben in kleinere Teile herunterzubrechen z.B. durch objektorientierte
Modellierung, Verwendung von Mindmapping-Tools und anderer Hilfsmittel. Für die
Lösung spezifischer Aufgaben kann die Verwendung einer bestimmten Programmiersprache
hilfreich sein. So bietet es sich z.B. an, für das Datamining in Texten Perl zu
verwenden, wohingegen die hardwarenahe Programmierung in einem embedded Projekt
die Verwendung von C oder C++ nahelegt.</p>
<p>Abbildung <ref idref="fig:combiningmethods"/> zeigt, wie unterschiedlich
verschiedene Arbeits- und Entwicklungsmethoden bei zunehmender Problemgröße
skalieren könnten. Die Graphik zeigt aber auch, dass jede Methode irgendwann an
ihre Grenzen stößt.</p>
<figure float="yes" id="fig:combiningmethods">
<caption>Skalierbarkeit und Limitierung verschiedener Arbeitsmethoden bei
zunehmendem Problemumfang.<br/>
Quelle: <cite idref="bib:WEINBERG92"/>, Seite 148.</caption>
<img src="../pics/figure10-5.svg" print-width="80%" screen-width="520px"/>
</figure>
<p>Bei der Auswahl der Arbeitswerkzeuge sollten deswegen folgende Faktoren
berücksichtigt werden:</p>
<ul>
<li><p>die Art der Aufgabenstellung (z.B. Datamining- oder Datenbankprojekt),</p></li>
<li><p>der Projektumfang,</p></li>
<li><p>und das geschätzte Risiko.</p></li>
</ul>
<p>Weinberg erwähnt, dass Manager auf Stufe 3 (definiert) gerne bereit sind,
Werkzeuge und Methoden nach unterschiedlichen Kriterien auszuwählen, wohingegen
Manager auf den Stufen darunter lieber alle Projekte nach dem selben Schema
abwickeln, aus Angst man könne ihnen sonst später eine Fehlentscheidung
anlasten. Dass sich gerade dieses Verhalten in vielen Fällen nachteilig auf den
Projekterfolg auswirken kann, ist für sie dabei ohne Belang. Sie sehen sich
firmenpolitischen Zwängen ausgesetzt, denen sie sich ergeben, z.B. aus Sorge ihre
Position oder gar ihre Arbeitsstelle zu verlieren.</p>
<minisection>
<title>Positive Grundhaltung</title>
<p>Für einen Außenstehenden mag dieses Verhalten dann absurd erscheinen,
weil sich ihm die sozio-politischen Zusammenhänge nicht direkt erschließen.
Aus der Sicht des Betroffenen ist es aber durchaus plausibel. Weinberg plädiert
deswegen allgemein für einen verständnisvollen Umgang mit Personen in einem
solchen Umfeld. Denn prinzipiell sei davon auszugehen, dass jeder Mensch
zunächst einmal gute Absichten hat und positiv auf sein Umfeld einwirken möchte.
Da jeder die Welt ein bisschen anders sieht, und deshalb zu einer Einschätzung
der Lage kommen kann, die von der eigenen divergiert, postuliert Weinberg:</p>
<blockquote>
<p><i>Egal wie es erscheint, jeder versucht hilfreich zu sein.</i></p>
</blockquote>
<p>Weiterhin solle man nicht versuchen, den Mitarbeitern alte Gewohnheiten zu
verbieten, sondern ihnen neue, effektivere anzutrainieren, bzw. sie zu ermutigen
sich neue Denkweisen zu erschließen, um Konditionierungen auf alte
Verhaltensmuster zu überwinden.</p>
</minisection>
</section>
<section>
<title>Rolle und Einfluss des Kunden</title>
<p>Organisationen sind keine abgeschlossenen Gebilde sondern erhalten ihre
Daseinsberechtigung oftmals erst durch ihre Interaktion mit der Außenwelt.
Einer der wichtigsten Außenkontakte von Organisationen sind ihre Kunden, denn
diese generieren den Umsatz, der für jedes Unternehmen wichtig ist.
Mit zunehmendem Erfolg eines Unternehmens steigt die Anzahl der Kunden.</p>
<figure id="fig:customerinfluence" float="yes">
<caption>Bei zunehmender Anzahl der Kunden, nimmt der nötige Arbeitsaufwand
zur Berücksichtigung aller Kundenanforderungen nicht-linear zu.<br/>
Quelle: <cite idref="bib:WEINBERG92"/>, Seite 161.</caption>
<img src="../pics/figure11-1.svg" print-width="50%" screen-width="420px"/>
</figure>
<p>Dieser
Umstand kann eine Organisation aber auch sehr schnell an die Grenzen ihrer
Leistungsfähigkeit bringen. Mit der steigenden Zahl von Kunden steigen auch
deren Anforderungen, was wiederum zu komplexeren Systemen führt. Diese steigende
Anzahl von Kunden führt außerdem noch zu Konflikten unter den Anforderungen. Zur
Lösung der Konflikte ist ein zusätzlicher Arbeitsaufwand nötig. Dieser und die
gestiegene Systemkomplexität steigern den Gesamtaufwand zur Bearbeitung der
Kundenbeziehungen.</p>
<p>Der vergrößerte Arbeitsaufwand durch komplexere Systeme und mehr
Kundenanforderungen kann es erfordern, dass sich eine Organisation auf ein
kulturelles Muster höherer Ebene umstellt. Dies liegt darin begründet, dass mit
einem kulturellen Muster höherer Stufe mehr Arbeit bewältigen lässt. Ohne diese
Anpassung des Musters könnte eine Organisation irgendwann den
Arbeitsaufwand nicht mehr bewältigen und würde scheitern.</p>
<figure id="fig:conflictrequirements" float="yes">
<caption>Wie der Einsatz eines Surrogates die effektive Anzahl der Kunden
und den mit den Kunden verknüpften Arbeitsaufwand reduzieren kann.<br/>
Quelle: <cite idref="bib:WEINBERG92"/>, Seite 167.</caption>
<img src="../pics/figure11-7.svg" print-width="45%" screen-width="420px"/>
</figure>
<p>Ebenso stellt die Verringerung der Anzahl der bestehenden Kunden keine Option
dar. Stattdessen versuchen Organisationen höherer Ebene den Umgang mit Kunden besser zu
organisieren. Weinberg beschreibt dazu die Etablierung von Stellvertretern
(Surrogates). Diese sollen zwischen den Kunden und der Entwicklungsorganisation
platziert werden, wodurch sie in der Lage sind, den Informationsfluss zwischen
diesen beiden zu filtern und zu regulieren. Dadurch verringert sich aus Sicht
der Entwicklungsorganisation die Anzahl der effektiven Kunden, mit der sie
interagiert.</p>
<p>Somit bilden diese Stellvertreter einen natürlichen negativen
Effekt auf die Anzahl der effektiven Kunden. Dabei spielt allerdings die
Effektivität dieser Stellvertreter eine entscheidende Rolle, da sie sehr großen
Einfluss auf die Entwicklungsorganisation besitzen.</p>
<p>Diese Filterung durch Stellvertreter erlangt ihre Bedeutung durch die oftmals
unterschätzte Auswirkung von Arbeitsunterbrechungen. Weinberg bedient sich zum Beleg
einiger Zahlen von DeMarco und Lister. Danach beträgt der Arbeitsausfall eines
Entwicklers für ein Telefonat von 5 Minuten insgesamt 20 Minuten. Zu der reinen
Gesprächszeit muss noch eine Wiedereinarbeitungszeit von 15 Minuten addiert
werden. Kann nun durch den effektiven Einsatz von Stellvertretern die Anzahl der
Arbeitsunterbrechungen eines Entwicklers reduziert werden, so führt dies zu
einer Steigerung seiner Produktivität, womit er mehr Arbeit bewältigen kann.</p>
<figure id="fig:losttime" float="yes">
<caption>Zusammenhang zwischen Anzahl der Kunden und verlorener Zeit
durch Unterbrechungen in Meetings.<br/>
Quelle: <cite idref="bib:WEINBERG92"/>, Seite 172.</caption>
<img src="../pics/figure11-9.svg" print-width="50%" screen-width="440px"/>
</figure>
<p>Besonders deutlich wird die Wichtigkeit effektiver Stellvertreter bei der
Betrachtung von Besprechungen. Dort multipliziert sich die Summe aus
Unterbrechungs- und Wiedereinarbeitungszeit noch mit der Anzahl der Teilnehmer.
Diese Zeit ist verschwendete Arbeitszeit. Mit einer steigenden Anzahl von Kunden
steigt die Anzahl von Besprechungen und die Anzahl der Unterbrechungen dieser.
Somit steigt die verschwendete Arbeitszeit nicht linear an.</p>
<p>Mehr Kunden resultieren auch noch in einer anderen Form in Mehrarbeit für
eine Softwareentwicklungsorganisation. Je mehr Kunden diese besitzt, desto mehr
Kunden setzen ihre Software in unterschiedlichen Konfigurationen ein. Dies
verlängert die Reparaturdauer und erhöht die Anzahl der Fehler, die nicht durch
Tests gefunden wurden. Dies führt zu mehr Fehlern, die repariert werden müssen.</p>
<p>Dieser Zuwachs an zu reparierenden Fehlern und die längere Reparaturdauer erhöhen
den Gesamtarbeitsaufwand zur Fehlerbeseitigung. Organisationen ab Stufe 3 aufwärts,
die sich selbst die nötigen Werkzeuge zur Bewältigung ihrer Aufgaben suchen,
können hier ihren Aufwand durch den Einsatz von geeigneten Werkzeugen reduzieren.
Zum einen kann durch Konfigurationsverwaltung die Zeit pro Reparatur verringert
werden, zum anderen reduzieren automatisierte Tests nicht gefundene Fehler.</p>
<p>Ähnlich wächst die Anzahl von unterschiedlichen Versionen einer Software, die
eine Organisation unterstützen muss, mit der Anzahl der Kunden. Auch dies
resultiert in mehr Arbeitsaufwand für die Organisation bei der Unterstützung und
Wartung der vielen Versionen. Stufe 3 Organisationen bedienen sich hier Werkzeuge
zur Verwaltung von Versionen. Interessant ist hierbei die Tatsache, dass sich bei
vielen Organisationen ein Release-Zyklus von sechs Monaten, also zwei Releases
pro Jahr, etabliert hat. Dies resultiert aus dem Versuch des Managements durch
längere Release-Zyklen den Aufwand dafür zu drosseln. Andererseits steigt mit
der Anzahl der Kunden der Bedarf an Reparaturen, was die längeren Releaseabsichten
des Managments ausbalanciert.</p>
<p>All diese Beobachtungen stellen unterschiedliche Varianten der
Size/Complexity-Dynamic dar. Ebenso zeigen sie, wie komplex die
Wirkungszusammenhänge in einer Organisation sind. Selbst bei einer Beschränkung
der Betrachtung auf die Interna einer Organisation, lassen sich die Vorgänge
nicht als einfacher Ursache-Wirkung-Zusammenhang beschreiben. Eine Ursache wirkt
sich an vielen Stellen aus, ein Wirkungssymptom kann von verschiedenen Ursachen
oder deren Kombination hervorgerufen werden.</p>
</section>
<section>
<title>Systems Thinking</title>
<p>An dieser Stelle entsteht der
Bedarf für ein besseres Mittel zur Analyse und Darstellung der Zusammenhänge.
Weinberg bedient sich hierfür des Systemdenkens, engl. Systems Thinking. Damit
lassen sich komplexe Wirkungszusammenhänge analysieren und mittels entsprechender
Diagramme veranschaulichen. Desweiteren ermöglichen die so gennanten System
Dynamics die Simulation von Wirkungszusammenhängen auf Basis verschiedener
Ausgangswerte. Mittels geeigneter Software, wie in unserem Falle Vensim, lassen
sich Diagramme erstellen, verschiedene Simualtionen durchführen und die
Ergebnisse vergleichen. Dafür stehen Graphen oder auch tabellarische Daten zur
Verfügung. Die Herausforderung hierbei besteht in der mathematischen Abbildung
der Realität. D.h. die Qualität der Simulation liegt in der möglichst genauen
mathematischen Formulierung der Auswirkungen eines Faktors auf die anderen im
System.</p>
<p>Im folgenden möchten wir dies an dem von Weinberg vorgestellten Systemdiagramm
zu Softwareentwicklungsmethoden ausführen. Wie bereits zuvor dargestellt geht es
hierbei um die Erfolgsquote einer Softwareorganisation und welche Rolle dabei
die verschiedenen Faktoren wie die begrenzte Kapazität des menschlichen Gehirns,
die Ambitionen, die Größe des Problems, die Komplexität der Lösung und die
Effektivität von Vereinfachungen durch Softwaretechnik spielen.</p>
<figure id="fig:vensim" border="yes" float="yes">
<caption>Einfaches Vensim-Modell zur Veranschaulichung der Rückkopplung
zwischen Ambition, Lösungskomplexität und Projekterfolg.</caption>
<img src="../pics/vensimmodel.pdf" print-width="80%" screen-width="400px"/>
</figure>
<p>Das entwickelte Vensim Modell (siehe Abbildung <ref idref="fig:vensim"/>)
basiert auf diesen Variablen, die wie folgt pro
Simulationsschritt berechnet werden: Die Kapazität des menschlichen Gehirns ist
naturgegeben begrenzt und somit im Modell eine Konstante. Die Erfolgsquote hängt
davon ab und wird allerdings negativ von der Lösungskomplexität beeinflusst. Diesen
Umstand berücksichtigt die Formel</p>
<equation>
<m>\frac{ \log{ (\text{Mental Capacity}) } }{ \log{ (\text{Complexity of Solution}) } }</m>
</equation>
<p>Die Verwendung einer bi-logarithmischen Skala dient hier in erster Linie
zur besseren Darstellung beim Plottten. Ansonsten wären die Unterschiede bei
unterschiedlichen Parametereinstellungen kaum sichtbar gewesen.</p>
<p>Die Ambitionen einer Organisation wachsen mit der Erfolgsquote. Je
ambitionierter eine Organisation ist, desto größer sind die Probleme, an die sie
sich wagt. Die Komplexität der Lösung eines solchen Problems errechnen wir nach
der Formel</p>
<equation>
<m>\frac{ (\text{size of problem})^2 }{ \log{ (\text{Software Engineering Simplifications + 1}) } }</m>
</equation>
<p>Die Software Engineering Simplifications stellen hier auch einen konstanten Wert
dar, der pro Simulationslauf verändert wird, um die Auswirkungen vergleichen zu können.
Die Verwendung des Logarithmus steht an dieser Stelle für die limitierte Skalierbarkeit
jeglicher Methoden des Software-Engineerings.</p>
<figure float="yes" border="yes" id="fig:successrate">
<caption>Simulation der Erfolgsrate mit verschiedenen Parametern.</caption>
<img src="../pics/successrate.png" print-width="100%" screen-width="600px"/>
</figure>
<p>Wir betrachten drei Simulationsdurchläufe. Der erste stellt die Referenz
mit Standardwerten dar. Beim Zweiten nehmen wir einen höheren Wert für Software
Engineering Simplifications an. Der dritte Durchlauf dient zur theoretischen
Veranschaulichung der Auswirkungen, wenn es möglich wäre, die Kapazität des
menschlichen Gehirns zu verdoppeln. Hierfür greifen wir einen Gedanken von Weinberg
auf, der aussagt, dass eine Steigerung der menschlichen Geistesleistung kaum
Auswirkungen auf die Erfolgsquote hätte.</p>
<figure float="yes" border="yes" id="fig:complexitysolution">
<caption>Simulation der Lösungskomplexität mit verschiedenden Parametern.</caption>
<img src="../pics/complexity_of_solution.png" print-width="80%" screen-width="500px"/>
</figure>
<p>
Die Graphen zur Erfolgsquote (siehe Abbildung <ref idref="fig:successrate"/>)
belegen diese Aussage nach unserer Simulation. Selbst unter Annahme einer
verdoppelten Geistesleistung fällt die Kurve nach etwas höherem Beginn sehr
schnell ab und nähert sich der Kurve der normalen
Geistesleistung. Einzig der Graph in dessen Berechnung die Software Engineering
Simplifications verstärkt eingingen fällt zu Beginn deutlich flacher. Er liegt
sogar sehr schnell über dem Graphen der doppelten Geistesleistung.</p>
<p>Somit haben wir ein Indiz für die Annahme, dass allein die Suche nach immer klügeren
Entwicklern eine Organisation nicht voran bringen kann. Selbst, wenn es immer
klügere Entwickler gäbe. Einzig die Softwaretechnik kann hier helfen. Dies
allerdings auch nur begrenzt, da dieser Graph ebenfalls gegen einen konstanten
Wert konvergiert. Diese Beobachtung belegt die Aussage, dass auch die Software
keine unendlich großen Probleme lösbar macht. Je besser und effektiver die
Softwaretechnik ist, desto weiter kann sie den Abfall der Erfolgsquote nach
hinten verschieben. Allerdings wird es immer zu einem Abfallen der Erfolgsquote
kommen. Aufgrund unserer Berechnungsformeln für die Variablen ist der Graph zur
Erfolgsquote erst bei genauerem hinsehen aussagekräftig.</p>
<p>Im Gegensatz dazu liefern die Graphen zur Komplexität (siehe Abbildung <ref idref="fig:complexitysolution"/>) des Problems ein
eindeutiges Bild. Alle drei Graphen steigen stetig, wobei der Graph mit
effektiveren Software Engineering Simplifications deutlich unterhalb der anderen
beiden liegt. Dies belegt die Vermutung, dass durch den Einsatz von Methoden der
Softwaretechnik, die Komplexität eines Problems deutlich verringert werden kann.
Demzufolge ließen sich komplexere Probleme bewältigen, die selbst mit doppelter
Gehirnkapazität nicht lösbar wären.</p>
</section>
<biblio number="no">
<bibitem id="bib:WEINBERG92" label="WEINBERG92">
Gerald M. Weinberg. <i>Quality Software Management: Volume 1, Systems
Thinking.</i> Dorset House Publishing, 1992.
</bibitem>
<bibitem id="bib:CMMI06" label="CMMI06">
CMMI Product Team. <i>CMMI for Development, Version 1.2.</i> Carnegie
Mellon Software Engineering Institute, August 2006.<br/>
<link url="http://www.sei.cmu.edu/reports/06tr008.pdf"><tt>URL: http://&zwsp;www.&zwsp;sei.&zwsp;cmu.&zwsp;edu/&zwsp;reports/&zwsp;06tr008.pdf</tt></link>
</bibitem>
</biblio>
</article>
|
