diff options
Diffstat (limited to 'Master/Seminar engl/Ausarbeitung/xml/article.xml')
| -rw-r--r-- | Master/Seminar engl/Ausarbeitung/xml/article.xml | 504 |
1 files changed, 504 insertions, 0 deletions
diff --git a/Master/Seminar engl/Ausarbeitung/xml/article.xml b/Master/Seminar engl/Ausarbeitung/xml/article.xml new file mode 100644 index 0000000..0ced6ad --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/xml/article.xml @@ -0,0 +1,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> |