From 33613a85afc4b1481367fbe92a17ee59c240250b Mon Sep 17 00:00:00 2001 From: Sven Eisenhauer Date: Fri, 10 Nov 2023 15:11:48 +0100 Subject: add new repo --- Master/Seminar engl/Ausarbeitung/draft_ch11.txt | 20 + Master/Seminar engl/Ausarbeitung/draft_ch11b.txt | 28 + Master/Seminar engl/Ausarbeitung/fig11-1.svg | 488 ++++++++++++++++ .../Seminar engl/Ausarbeitung/pdf/ausarbeitung.pdf | Bin 0 -> 3616304 bytes .../Ausarbeitung/pics/complexity_of_solution.png | Bin 0 -> 15096 bytes .../Seminar engl/Ausarbeitung/pics/figure10-5.svg | 101 ++++ .../Seminar engl/Ausarbeitung/pics/figure11-1.svg | 190 ++++++ .../Seminar engl/Ausarbeitung/pics/figure11-7.svg | 264 +++++++++ .../Seminar engl/Ausarbeitung/pics/figure11-9.svg | 280 +++++++++ .../Seminar engl/Ausarbeitung/pics/figure9-1.svg | 128 +++++ .../Seminar engl/Ausarbeitung/pics/figure9-5.svg | 289 ++++++++++ .../Seminar engl/Ausarbeitung/pics/successrate.png | Bin 0 -> 17726 bytes .../Seminar engl/Ausarbeitung/pics/vensimmodel.pdf | Bin 0 -> 4222 bytes Master/Seminar engl/Ausarbeitung/tex/article.tex | 635 +++++++++++++++++++++ Master/Seminar engl/Ausarbeitung/tex/img000001.pdf | Bin 0 -> 225210 bytes Master/Seminar engl/Ausarbeitung/tex/img000002.pdf | Bin 0 -> 880166 bytes Master/Seminar engl/Ausarbeitung/tex/img000003.pdf | Bin 0 -> 632784 bytes Master/Seminar engl/Ausarbeitung/tex/img000004.pdf | Bin 0 -> 338545 bytes Master/Seminar engl/Ausarbeitung/tex/img000005.pdf | Bin 0 -> 867025 bytes Master/Seminar engl/Ausarbeitung/tex/img000006.pdf | Bin 0 -> 383155 bytes Master/Seminar engl/Ausarbeitung/tex/img000007.pdf | Bin 0 -> 4222 bytes Master/Seminar engl/Ausarbeitung/tex/img000008.pdf | Bin 0 -> 10152 bytes Master/Seminar engl/Ausarbeitung/tex/img000009.pdf | Bin 0 -> 9826 bytes Master/Seminar engl/Ausarbeitung/xml/article.xml | 504 ++++++++++++++++ 24 files changed, 2927 insertions(+) create mode 100644 Master/Seminar engl/Ausarbeitung/draft_ch11.txt create mode 100644 Master/Seminar engl/Ausarbeitung/draft_ch11b.txt create mode 100644 Master/Seminar engl/Ausarbeitung/fig11-1.svg create mode 100644 Master/Seminar engl/Ausarbeitung/pdf/ausarbeitung.pdf create mode 100755 Master/Seminar engl/Ausarbeitung/pics/complexity_of_solution.png create mode 100644 Master/Seminar engl/Ausarbeitung/pics/figure10-5.svg create mode 100644 Master/Seminar engl/Ausarbeitung/pics/figure11-1.svg create mode 100644 Master/Seminar engl/Ausarbeitung/pics/figure11-7.svg create mode 100644 Master/Seminar engl/Ausarbeitung/pics/figure11-9.svg create mode 100644 Master/Seminar engl/Ausarbeitung/pics/figure9-1.svg create mode 100644 Master/Seminar engl/Ausarbeitung/pics/figure9-5.svg create mode 100755 Master/Seminar engl/Ausarbeitung/pics/successrate.png create mode 100755 Master/Seminar engl/Ausarbeitung/pics/vensimmodel.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/article.tex create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000001.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000002.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000003.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000004.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000005.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000006.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000007.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000008.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/tex/img000009.pdf create mode 100644 Master/Seminar engl/Ausarbeitung/xml/article.xml (limited to 'Master/Seminar engl/Ausarbeitung') diff --git a/Master/Seminar engl/Ausarbeitung/draft_ch11.txt b/Master/Seminar engl/Ausarbeitung/draft_ch11.txt new file mode 100644 index 0000000..0b62415 --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/draft_ch11.txt @@ -0,0 +1,20 @@ +Kapitel 11 + +Organisationen sind keine abgeschlossenen Gebilde sondern erhalten ihre Daseinsberechtigung oftmals erst durch ihre Interaktion mit der Außenwelt. Einer der wichtigesten 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. 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. + +[Nachbau Figure 11-1] + +Der vergrößerte Arbeitsaufwand durch komplexere Systeme und mehr Kundenanforderungen können es erfordern, dass sich eine Organisation auf ein cultural pattern höherer Ebene umstellt. Dies liegt darin begründet, dass mit einem cultural pattern höherer Stufe mehr Arbeit bewältigen lässt. Ohne diese Anpassung des cultural patterns könnte eine Organisation irgendwann den Arbeitsaufwand nicht mehr bewältigen und scheitert. 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. 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. + +[Nachbau Figure 11-7] + +Diese Filterung durch Stellvertreter erlangt ihre Bedeutung durch die oftmals unterschätzte Auswirkung von Arbeitsbrechungen. 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. +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. + +[Nachbau Figure 11-9] + +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. 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. + +Ä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. \ No newline at end of file diff --git a/Master/Seminar engl/Ausarbeitung/draft_ch11b.txt b/Master/Seminar engl/Ausarbeitung/draft_ch11b.txt new file mode 100644 index 0000000..761622f --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/draft_ch11b.txt @@ -0,0 +1,28 @@ +Kapitel 11 + +Organisationen sind keine abgeschlossenen Gebilde, sondern erhalten ihre Daseinsberechtigung oftmals erst durch ihre Interaktion mit der Außenwelt. Einer der wichtigesten 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. 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. + +[Nachbau Figure 11-1] + +Der vergrößerte Arbeitsaufwand durch komplexere Systeme und mehr Kundenanforderungen können es erfordern, dass sich eine Organisation auf ein cultural pattern höherer Ebene umstellt. Dies liegt darin begründet, dass mit einem cultural pattern höherer Stufe mehr Arbeit bewältigen lässt. Ohne diese Anpassung des cultural patterns könnte eine Organisation irgendwann den Arbeitsaufwand nicht mehr bewältigen und scheitert. 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. 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. + +[Nachbau Figure 11-7] + +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. +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 mehr als linear zur Anzahl der Kunden an. + +[Nachbau Figure 11-9] + +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. 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. + +Ä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 Managements ausbalanciert. + +Um zu den oben genannten Erkenntnissen über die Auswirkungen der steigenden Kundenanzahl zu gelangen, bedarf es der Betrachtung des Gesamtsystems. Wie gezeigt stellen sich die Zusammenhänge wesentlich komplexer dar, als es sich mit einer einfachen Ursache- / Wirkungsbetrachtungsweise erschließen ließe. Diese einfachen Betrachtungsweisen liefern nur unzureichende Ergebnisse, die Weinberg in Sätzen wie "Wir haben zu viele Kunden" oder "Wir könnten ein großartiges System haben, wenn uns unsere Kunden nur nicht immer belästigen würden" anführt. Wer solche Sätze äußert sieht nur die steigende Kundenanzahl bzw. steigenden Kundenanfragen und das Resultat, nämlich Mehrarbeit. Erst das Systemdenken erschließt die tieferen Zusammenhänge. Auf Basis dieser weitergehenden Erkenntnisse lassen sich nun Maßnahmen entwickeln, wie man den genannten negativen Effekten entgegen wirken kann. + +Das Systemdenken stellt dem Manager die nötigen Werkzeuge zur Verfügung, um die Wirkungszusammenhänge wie in Diagramm 11-1 zu erkennen und darzustellen. Dieses Diagramm beinhaltet ausschließlich verstärkende Faktoren auf die zu erledigende Arbeit. Daraus ergibt sich der Bedarf eines negativen Faktors auf die zu erledigende Arbeit. Somit bildet Diagramm 11-7 einen Lösungsansatz für diese Problemstellung. Es führt effektive Stellvertreter als negativen Faktor auf die Anzahl der effektiven Kunden ein. Diese effektiven Kunden wirken somit wesentlich schwächer auf die zu erledigende Arbeit ein als die Anzahl der direkten Kunden. Erst das Systemdenken ermöglicht das Erkennen der ganzheitlichen Zusammenhänge und die Entwicklung von wirksamen Lösungsstrategien für Probleme. + +Allerdings zeigen diese Betrachtungen auch, dass es immer eine Grenze des Machbaren gibt. Die Einführung von Stellvertretern als reduzierenden Faktor auf die Anzahl der effektiven Kunden kann die Mehrarbeit nicht auf Null drücken. Somit besteht immer eine Obergrenze für die Anzahl der Kunden, die eine Organisation bewältigen kann. Das Systemdenken versetzt das Management jedoch in die Lage, diese Grenze etwas hinaus zu schieben. +Ebenso kann die Nutzung von Methoden der Softwaretechnik eine Organisation in die Lage versetzen, ein Problem zu lösen, das ohne die Softwaretechnik zu komplex für die Organisation wäre. Aus dem Systemmodell zum Einsatz von Softwaretechnikmethoden erschließt sich allerdings auch, dass sich dadurch nicht unendlich komplexe Probleme lösen lassen. Auch hierbei besteht eine Grenze des Machbaren, die sich durch gutes Management etwas nach oben verschieben lässt. +Demnach müssen Organisationen beispielsweise neue Softwaretechnikmethoden einsetzen oder ihre Struktur ändern, um wachsende Problem- und Kundenanforderungen beherrschen zu können. Dies bedeutet, dass sowohl die Problemkomplexität aus gestiegenen Ambitionen als auch die Kundenanzahl sich störend auf eine Organisation auswirken. Beide Störfaktoren resultieren aus dem Erfolg einer Organisation, wonach eine Organisation auf ihren eigenen Erfolg reagieren muss, um weiter erfolgreich zu sein. Weinberg schließt auch hier den Kreis zu den cultural patterns. Erst eine Organisation auf Stufe drei oder höher ist in der Lage, ihren eigenen Erfolg zu bewerten. Ebenso sind diese Organisationen in der Lage, ihr Vorgehen an die jeweilige Situation anzupassen. Eine situationsorientierte Anpassung des Vorgehens kann beispielsweise im Einsatz einer neuen Softwarentwicklungstechnik liegen, um ein Projekt zu bewältigen, das ohne diese neue Technik nicht beherrschbar wäre. Wie oben aufgezeigt stellt diese Anpassungsfähigkeit den Schlüssel zur Bewältigung komplexerer Probleme und größerer Kundenanzahl dar. Aufgrund dieser Anpassungsfähigkeit befindet sich eine Organisation auf höherer Stufe in der Lage mehr Kunden und größere Probleme zu bewältigen als eine Organisation auf niedrigerer Stufe. Das Systemdenken hilft ihr, die richtigen Ansatzpunkte für erfolgversprechende Managementmaßnahmen zu finden und somit weiter erfolgreich zu sein. \ No newline at end of file diff --git a/Master/Seminar engl/Ausarbeitung/fig11-1.svg b/Master/Seminar engl/Ausarbeitung/fig11-1.svg new file mode 100644 index 0000000..6d2c30a --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/fig11-1.svg @@ -0,0 +1,488 @@ + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + NUMBER OFCUSTOMERS + + + + + NUMBER OFCUSTOMERS + + + + + NUMBER OFREQUIREMENTS + + + + + SYSTEMCOMPLEXITY + + + + + + LABOR TO DEALWITH CUSTOMERS + + + + + + NUMBER OFCONFLICTINGREQUIREMENTS + + + + + + LABOR TORESOLVE ORACCOMMODATECONFLICTS + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Master/Seminar engl/Ausarbeitung/pdf/ausarbeitung.pdf b/Master/Seminar engl/Ausarbeitung/pdf/ausarbeitung.pdf new file mode 100644 index 0000000..c3e2a1d Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/pdf/ausarbeitung.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/pics/complexity_of_solution.png b/Master/Seminar engl/Ausarbeitung/pics/complexity_of_solution.png new file mode 100755 index 0000000..6775440 Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/pics/complexity_of_solution.png differ diff --git a/Master/Seminar engl/Ausarbeitung/pics/figure10-5.svg b/Master/Seminar engl/Ausarbeitung/pics/figure10-5.svg new file mode 100644 index 0000000..d4bc2fd --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/pics/figure10-5.svg @@ -0,0 +1,101 @@ + + + + + + + + + + + Method 1Method 2 + Limit ofMethod1 + Limit ofMethod2 + Problem Size + Computation Required to Control + + + + diff --git a/Master/Seminar engl/Ausarbeitung/pics/figure11-1.svg b/Master/Seminar engl/Ausarbeitung/pics/figure11-1.svg new file mode 100644 index 0000000..cfb9122 --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/pics/figure11-1.svg @@ -0,0 +1,190 @@ + + + + + + + + Number ofCustomers + + + + Number ofConflictingRequirements + + + + Number ofRequirements + + + + SystemComplexity + + + + Labor to Solve orAccomodateConflicts + + + + Labor to Deal withCustomers + + + + + + + + + + + + + + + diff --git a/Master/Seminar engl/Ausarbeitung/pics/figure11-7.svg b/Master/Seminar engl/Ausarbeitung/pics/figure11-7.svg new file mode 100644 index 0000000..99e5ef0 --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/pics/figure11-7.svg @@ -0,0 +1,264 @@ + + + + + + + + Number ofCustomers + + + + Effectiveness ofSurrogates + + + + EffectiveNumber ofCustomers + + + + Number ofRequirements + + + + Number ofConflictingRequirements + + + + System Complexity + + + + Labor to Solve orAccomodateConflicts + + + + Labor to Deal withCustomers + + + + + + + + + + + + + + + + + + + + Natural Negative Effect + + + diff --git a/Master/Seminar engl/Ausarbeitung/pics/figure11-9.svg b/Master/Seminar engl/Ausarbeitung/pics/figure11-9.svg new file mode 100644 index 0000000..ebc20e9 --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/pics/figure11-9.svg @@ -0,0 +1,280 @@ + + + + + + + + image/svg+xml + + + + + + + + + + + + + Number ofCustomers + + + + Number ofPeople in eachMeeting + + + + Number of Meetings + + + + Total Wasted MeetingTime + + + + Wasted Time perMeeting + + + + Average Lengthper Interruption + + + + Number ofInterrutptionsper Meeting + + + + + + + + + + + + + + + + + + + diff --git a/Master/Seminar engl/Ausarbeitung/pics/figure9-1.svg b/Master/Seminar engl/Ausarbeitung/pics/figure9-1.svg new file mode 100644 index 0000000..d797c0f --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/pics/figure9-1.svg @@ -0,0 +1,128 @@ + + + + + + + + Size of DynamicSystem + + + + Number ofEquations + + + + TotalComputations + + + + Factorsper Equation + + + + + + + + + + + diff --git a/Master/Seminar engl/Ausarbeitung/pics/figure9-5.svg b/Master/Seminar engl/Ausarbeitung/pics/figure9-5.svg new file mode 100644 index 0000000..64c6d80 --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/pics/figure9-5.svg @@ -0,0 +1,289 @@ + + + + + + + + MentalCapacity + + + + SuccessRate + + + + Ambition + + + + Size of Problem + + + + Complexity of Solution + + + + + SoftwareEngineeringSimplifications + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Natural Negative Effect + + + + + + + Management actionwith open choice ofeffect + + + + diff --git a/Master/Seminar engl/Ausarbeitung/pics/successrate.png b/Master/Seminar engl/Ausarbeitung/pics/successrate.png new file mode 100755 index 0000000..7e19b52 Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/pics/successrate.png differ diff --git a/Master/Seminar engl/Ausarbeitung/pics/vensimmodel.pdf b/Master/Seminar engl/Ausarbeitung/pics/vensimmodel.pdf new file mode 100755 index 0000000..4a5067a Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/pics/vensimmodel.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/article.tex b/Master/Seminar engl/Ausarbeitung/tex/article.tex new file mode 100644 index 0000000..16fe6d4 --- /dev/null +++ b/Master/Seminar engl/Ausarbeitung/tex/article.tex @@ -0,0 +1,635 @@ +\documentclass[tableabovecaptionskip,pdftex,12pt,a4paper,halfparskip,pointednumbers,automark,pagesize,abstracton,headinclude,footexclude,bibtotoc]{scrartcl} + +% Set input- and fontencoding +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} + +% Use postscript fonts +\usepackage{pifont} +\usepackage{textcomp} +\usepackage{courier} +\usepackage{helvet} +\usepackage{lmodern} + +% Color and verbatim environment +\usepackage{color} +\usepackage{framed} +\usepackage{colortbl} +\usepackage{alltt} +\newcommand{\rgbshadecolor}[3]{\definecolor{shadecolor}{rgb}{#1,#2,#3}} +\newcommand{\rgbcolor}[4]{\textcolor[rgb]{#1,#2,#3}{#4}} + +% Make euro symbol available +\usepackage[gen]{eurosym} + +% Load math environment +\usepackage{amsmath} +\usepackage{amsthm} + +% Disable extra space after fullstops +\frenchspacing{} + +% Allows disabling hyphenation on demand +\usepackage{hyphenat} + +% Redefine footnotes' appearance +\renewcommand{\thefootnote}{(\arabic{footnote})} + +% Floating environment +\usepackage{float} +\usepackage{flafter} + +% Table stuff +\usepackage{longtable} +\usepackage{hhline} +\usepackage{array} +\usepackage{calc} +\doublerulesepcolor{white} +\newlength{\ecmdstablewidth} +\newlength{\ecmdscolsep} +\usepackage{multirow} + +% Environment for nested block elements +\newenvironment{blockelement}{% +\noindent\begin{trivlist}\item% +}{% +\end{trivlist}}% + +\newlength{\ecmdstmplength} + +\usepackage{multicol} + +% Redefine paragraph +\makeatletter +\renewcommand{\paragraph}{\@startsection{paragraph}{4}{\z@}% + {-0ex\@plus -0.5ex \@minus -.2ex}% + {-1.5ex}% + {\normalsize\rmfamily\bfseries}} +\makeatother + +% Minimal listing environment +\usepackage{listing} +\renewcommand{\listingname}{Listing} +\renewcommand{\listlistingname}{Listingsverzeichnis} + +% Unify the look of caption labels +\usepackage[font=small,font=rm,labelfont=bf,format=hang,labelformat=simple]{caption} +% Enable hyphenation of underlined text +\usepackage[normalem]{ulem} + +% Graphics environment +\usepackage{graphicx} + +% Inline objects +\usepackage{wrapfig} + +% Enable custom page headers +\usepackage{scrpage2} +\setlength{\parskip}{1ex plus 0.2ex minus 0.1ex}\setlength{\parindent}{0em}% For per chapter overviews +\usepackage[checkfiles,tight]{minitoc} + +\definecolor{ecmdslinkcolor}{rgb}{0.11,0.11,0.44} + +%Bookmarks, Links and URLs in PDF +\usepackage[hyperindex=false,colorlinks=true,breaklinks=true,unicode=true, +linkcolor=ecmdslinkcolor,anchorcolor=ecmdslinkcolor,citecolor=ecmdslinkcolor, +bookmarksopen=true,bookmarksnumbered=true,filecolor=ecmdslinkcolor, +menucolor=ecmdslinkcolor,urlcolor=ecmdslinkcolor,pdfcreator={ecromedos Document Preparation System V2.0.1}]{hyperref} + +% Recalculate layout +\typearea[0cm]{12} + +% Turn on lazy typesetting. +\sloppy + +\clubpenalty=9999 +\widowpenalty=9999 + +% Select babel language +\usepackage[ngerman]{babel} + +\setcounter{secnumdepth}{3} + +\setcounter{tocdepth}{3} + +\begin{document} + +\renewcommand{\familydefault}{\rmdefault} + +\renewcommand*{\partpagestyle}{} +\renewcommand*{\indexpagestyle}{scrheadings} +\renewcommand*{\titlepagestyle}{scrplain} + + + \ihead[]{} + \chead[]{\headmark} + \ohead[]{} + \ifoot[]{} + \cfoot[\pagemark]{\pagemark} + \ofoot[]{} + \setkomafont{sectioning}{\normalsize\sffamily\bfseries} +\setkomafont{section}{\Large\sffamily\bfseries} +\setkomafont{subsection}{\large\sffamily\bfseries} +\setkomafont{subsubsection}{\normalsize\sffamily\bfseries} +\setkomafont{paragraph}{\normalsize\rmfamily\bfseries} + +\setkomafont{title}{\large\sffamily\bfseries} + +\setkomafont{pagehead}{\normalsize\slshape} + +\setkomafont{descriptionlabel}{\normalsize\rmfamily\bfseries} +\setkomafont{footnote}{\footnotesize\rmfamily} +\setkomafont{footnotelabel}{\footnotesize\rmfamily} +\setkomafont{footnotereference}{\footnotesize\rmfamily} + +\setkomafont{pagenumber}{\normalsize\upshape\rmfamily} +\mtcsettitlefont{secttoc}{\large\sffamily\bfseries} +\setlength{\stcindent}{1em} +\pagestyle{scrheadings} +\selectlanguage{ngerman} + +\mtcselectlanguage{ngerman} + +\title{Demands that Stress Patterns\\{}\normalsize{}Wie Anforderungen Unternehmenskulturen auf die Probe stellen} +\author{Sven Eisenhauer\and Tobias Koch} +\date{8. Januar 2010} +\publishers{Seminar Systems Thinking, Wintersemester 2009/2010\\{} + Hochschule Darmstadt\\{} + Referent{}{\string:}{} Herr Prof. Dr. Andelfinger\\{}} +\maketitle + +\tableofcontents{} +\begin{abstract} Im ersten Band -- \textit{Systems Thinking} -- seiner Reihe von Büchern + zum Qualitätsmanagement in der Software{}{\string-}{}Entwicklung, schildert Gerald M. + Weinberg wie typische kulturelle Muster in Software{}{\string-}{}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äge für Methoden, die dabei helfen können, besagte Firmenkulturen + in positiver Weise zu beeinflußen und zu verändern. + + + Dieser Artikel fasst die Kerngedanken aus dem dritten Teil -- + \textit{Demands that Stress Patterns} -- des Buches zusammen + und erläutert anhand konkreter Beispiele aus dem Buch, warum Software{}{\string-}{}Entwicklung + an sich eine hoch{}{\string-}{}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.% + + \end{abstract}\section{Reifegradstufen von Entwicklungsprozessen} + +In \cite{bib:WEINBERG92} befaßt sich Gerald M. Weinberg mit den Problemen und +Heraus\-forder\-ungen, denen sich Software produzierende Organisationen früher oder +später stellen müssen. Seinen Analysen legt er {„}kulturelle Muster{“} zugrunde, die +in ihrer Beschreibung in etwa dem Reifegrad von Entwicklungsprozessen nach dem Capability Maturity +Modell (CMM) \cite{bib:CMMI06} entsprechen. Für die weiteren Ausführungen in +diesem Artikel sind davon die Stufen 1 bis 3 von Bedeutung{}{\string:}{} + +\begin{description} +\item[{\parbox[b]{\linewidth}{Stufe 1 {}{\string-}{} initial{}{\string:}{}}}]{\hfill{}\mbox{}\newline{}Nach Weinberg, der das entsprechende kulturelle Muster {„}variabel{“} nennt, + gibt es auf dieser Stufe {„}kein Konzept von Management als + Entwicklungswerkzeug{“}. 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.% +} +\item[{\parbox[b]{\linewidth}{Stufe 2 {}{\string-}{} geregelt{}{\string:}{}}}]{\hfill{}\mbox{}\newline{}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 {„}routiniert{“}, 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.% +} +\item[{\parbox[b]{\linewidth}{Stufe 3 {}{\string-}{} definiert{}{\string:}{}}}]{\hfill{}\mbox{}\newline{}Weinberg nennt das kulturelle Muster, das dieser Entwicklungsstufe + entspricht, {„}steuernd{“}, 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 {„}genau {[}...{]} + verstanden und werden anhand von Standards, Arbeitsverfahren, Werkzeugen + und Methoden beschrieben{“}, mit der Zielsetzung diese in der gesamten + Organisation zu verheinheitlichen.% +} +\item[{\parbox[b]{\linewidth}{Stufe 4 {}{\string-}{} quantitiv geregelt{}{\string:}{}}}]{\hfill{}\mbox{}\newline{}Laut CCM sind Prozesse auf Stufe 4 definerte Prozesse (Stufe 3), die + {„}mit Hilfe statistischer und anderer quantitativer Methoden kontrolliert + werden{“}. Weinberg nennt das kulturelle Muster, das dieser Reifegradstufe + entspricht, {„}voraussschauend{“}, was bedeuten soll, dass die Wahl und + Konzeption neuer Prozesse und Methoden unter Berücksichtigung vorausgehender + Erfahrungen erfolgt.% +} +\item[{\parbox[b]{\linewidth}{Stufe 5 {}{\string-}{} optimierend{}{\string:}{}}}]{\hfill{}\mbox{}\newline{}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.% +} +\end{description}% + + +Nach Weinbergs eigenen Beobachtungen befinden sich die meisten Unternehmen im +Software{}{\string-}{}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.% +\section{Komplexität dynamischer Systeme} + +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{}{\string-}{}linear an. Dieser Zusammenhang wird in Abbildung \ref{fig:sizecomplexity} +veranschaulicht{}{\string:}{} 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. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\includegraphics[width=0.45\linewidth]{img000001.pdf}% +\end{minipage}% +\caption{\label{fig:sizecomplexity}Zusammenhang zwischen der Komplexität eines dynamischen Systems + und dem benötigten Berechnungsaufwand zur Kontrolle des Systems.\mbox{}\newline{} + Quelle{}{\string:}{} \cite{bib:WEINBERG92}, Seite 131.} +\end{figure} +Weinberg nennt diesen Sachverhalt {„}The Square Law of Computation{“}. Nach +Weinberg handelt es sich dabei um eine sogenannte {„}natürliche Dynamik{“}, +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 {„}Interventionsdynamik{“}. + +Zieht man als Beispiele für dynamische Systeme die Spiele Tic{}{\string-}{}Tac{}{\string-}{}Toe und +Schach heran, dann kann man folgende Feststellungen treffen{}{\string:}{} + +\begin{itemize} + \item{Bei beiden Spielen handelt es sich um abgeschlossene Systeme mit exakt + definierten möglichen Zustandsübergängen.% +} + + \item{Tic{}{\string-}{}Tac{}{\string-}{}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{}{\string-}{}Tac{}{\string-}{}Toe + zu spielen.% +} + + \item{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.% +} + + \end{itemize}% + + +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 + +{\renewcommand{\labelenumi}{\alph{enumi})}% +\begin{enumerate} + \item{um kein abgeschlossenes System handelt,% +} + + \item{die Zustandsübergänge nicht genau definierbar sind und% +} + + \item{die Anzahl der Wahlmöglichkeiten pro Zug unermesslich groß ist.% +} + + \end{enumerate}}% + + +Da es Menschen gibt, die trotz der Komplexität des Spiels sehr erfolgreich +Schach spielen, äußert sich Weinberg optimistisch, dass auch Management als {„}Game of +Control{“} beherrschbar ist, wenn man sich der richtigen Denkweisen und Arbeitsmethoden +bedient.% +\section{Rückkopplungseffekt zwischen Erfolg und Ambition} + +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. + +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{fig:erfolgambition} +dargestellt{}{\string:}{} + 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{}{\string-}{}Entwicklung schlägt Weinberg +vor, dass dieser Rückkopplungseffekt mit den Methoden des Software{}{\string-}{}Engineerings beherrschbar +gemacht werden kann. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\includegraphics[width=0.8\linewidth]{img000002.pdf}% +\end{minipage}% +\caption{\label{fig:erfolgambition}Software{}{\string-}{}Engineering zur Beherrschung des Rückkopplungseffektes zwischen + Erfolg und Ambition.\mbox{}\newline{} + Quelle{}{\string:}{} \cite{bib:WEINBERG92}, Seite 136.} +\end{figure} +Die Tatsache, dass unsere intellektuelle Kapazität begrenzt ist, wir dazu +tendieren, uns immer schwierigere Aufgaben zu suchen, Problemstellungen aber aufgrund +des {„}Square Law of Computation{“} schnell Dimensionen annehmen, die diese Kapazität +übersteigen, nennt Weinberg {„}Size/Complexity{}{\string-}{}Dynamic{“}. + +Diese natürliche Dynamik tritt noch in anderen Facetten zum Vorschein, z.B. +in Form der Fault/Location{}{\string-}{}Dynamic{}{\string:}{} Mit zunehmendem Unfang eines Software{}{\string-}{}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{}{\string-}{}Projekten +ein nicht{}{\string-}{}linearer wachsender Arbeitsaufwand. + +Eine weitere Variante ist die People/Interaction{}{\string-}{}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{}{\string-}{}linear zunimmt.% +\section{Was dabei hilft, die Kontrolle zu behalten} + +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{}{\string-}{}Dynamic. + +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{}{\string-}{}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. + +Abbildung \ref{fig:combiningmethods} zeigt, wie unterschiedlich +verschiedene Arbeits{}{\string-}{} und Entwicklungsmethoden bei zunehmender Problemgröße +skalieren könnten. Die Graphik zeigt aber auch, dass jede Methode irgendwann an +ihre Grenzen stößt. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\includegraphics[width=0.8\linewidth]{img000003.pdf}% +\end{minipage}% +\caption{\label{fig:combiningmethods}Skalierbarkeit und Limitierung verschiedener Arbeitsmethoden bei + zunehmendem Problemumfang.\mbox{}\newline{} + Quelle{}{\string:}{} \cite{bib:WEINBERG92}, Seite 148.} +\end{figure} +Bei der Auswahl der Arbeitswerkzeuge sollten deswegen folgende Faktoren + berücksichtigt werden{}{\string:}{} + +\begin{itemize} + \item{die Art der Aufgabenstellung (z.B. Datamining{}{\string-}{} oder Datenbankprojekt),% +} + + \item{der Projektumfang,% +} + + \item{und das geschätzte Risiko.% +} + + \end{itemize}% + + +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. + +\minisec{Positive Grundhaltung} +Für einen Außenstehenden mag dieses Verhalten dann absurd erscheinen, +weil sich ihm die sozio{}{\string-}{}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{}{\string:}{} + +\begin{quote} \textit{Egal wie es erscheint, jeder versucht hilfreich zu sein.}% + + \end{quote}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.% +\section{Rolle und Einfluss des Kunden} + +Organisationen sind keine abgeschlossenen Gebilde sondern erhalten ihre +Daseinsberechtigung oftmals erst durch ihre Interaktion mit der Außenwelt. +Einer der wichtigesten 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. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\includegraphics[width=0.5\linewidth]{img000004.pdf}% +\end{minipage}% +\caption{\label{fig:customerinfluence}Bei zunehmender Anzahl der Kunden, nimmt der nötige Arbeitsaufwand + zur Berücksichtigung aller Kundenanforderungen nicht{}{\string-}{}linear zu.\mbox{}\newline{} + Quelle{}{\string:}{} \cite{bib:WEINBERG92}, Seite 161.} +\end{figure} +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. + +Der vergrößerte Arbeitsaufwand durch komplexere Systeme und mehr +Kundenanforderungen können 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. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\includegraphics[width=0.45\linewidth]{img000005.pdf}% +\end{minipage}% +\caption{\label{fig:conflictrequirements}Wie der Einsatz eines Surrogates die effektive Anzahl der Kunden + und den mit den Kunden verknüpften Arbeitsaufwand reduzieren kann.\mbox{}\newline{} + Quelle{}{\string:}{} \cite{bib:WEINBERG92}, Seite 167.} +\end{figure} +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. + +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. + +Diese Filterung durch Stellvertreter erlangt ihre Bedeutung durch die oftmals +unterschätzte Auswirkung von Arbeitsbrechungen. 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. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\includegraphics[width=0.5\linewidth]{img000006.pdf}% +\end{minipage}% +\caption{\label{fig:losttime}Zusammenhang zwischen Anzahl der Kunden und verlorener Zeit + durch Unterbrechungen in Meetings.\mbox{}\newline{} + Quelle{}{\string:}{} \cite{bib:WEINBERG92}, Seite 172.} +\end{figure} +Besonders deutlich wird die Wichtigkeit effektiver Stellvertreter bei der +Betrachtung von Besprechungen. Dort multipliziert sich die Summe aus +Unterbrechungs{}{\string-}{} 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. + +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. + +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. + +Ä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{}{\string-}{}Zyklus von sechs Monaten, also zwei Releases +pro Jahr, etabliert hat. Dies resultiert aus dem Versuch des Managements durch +längere Release{}{\string-}{}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. + +All diese Beobachtungen stellen unterschiedliche Varianten der +Size/Complexity{}{\string-}{}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 einfache Ursache{}{\string-}{}Wirkung{}{\string-}{}Zusammenhang beschreiben. Eine Ursache wirkt +sich an vielen Stellen aus, ein Wirkungssymptom kann von verschiedenen Ursachen +oder deren Kombination hervorgerufen werden.% +\section{Systems Thinking} + +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. + +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. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\fbox{\includegraphics[width=0.8\linewidth]{img000007.pdf}}% +\end{minipage}% +\caption{\label{fig:vensim}Einfaches Vensim{}{\string-}{}Modell zur Veranschaulichung der Rückkopplung + zwischen Ambition, Lösungskomplexität und Projekterfolg.} +\end{figure} +Das entwickelte Vensim Modell (siehe Abbildung \ref{fig:vensim} +basiert auf diesen Variablen, die wie folgt pro +Simulationsschritt berechnet werden{}{\string:}{} 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% +\begin{displaymath}\frac{ \log{ (\text{Mental Capacity}) } }{ \log{ (\text{Complexity of Solution}) } }\end{displaymath}% +Die Verwendung einer bi{}{\string-}{}logarithmischen Skala dient hier in erster Linie +zur besseren Darstellung beim Plottten. Ansonsten wären die Unterschiede bei +unterschiedlichen Parametereinstellungen kaum sichtbar gewesen. + +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% +\begin{displaymath}\frac{ (\text{size of problem})^2 }{ \log{ (\text{Software Engineering Simplifications + 1}) } }\end{displaymath}% +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{}{\string-}{}Engineerings. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\fbox{\includegraphics[width=1\linewidth]{img000008.pdf}}% +\end{minipage}% +\caption{\label{fig:successrate}Simulation der Erfolgsrate mit verschiedenen Parametern.} +\end{figure} +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. + +\begin{figure}[h!]% +\begin{minipage}{\linewidth}% +\centering\fbox{\includegraphics[width=0.8\linewidth]{img000009.pdf}}% +\end{minipage}% +\caption{\label{fig:complexitysolution}Simulation der Lösungskomplexität mit verschiedenden Parametern.} +\end{figure} +Die Graphen zur Erfolgsquote (siehe Abbildung \ref{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. + +Somit haben wir ein Indiz für die Annahme, dass allein 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. + +Im Gegensatz dazu liefern die Graphen zur Komplexität (siehe Abbildung \ref{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.% +\setcounter{footnote}{0} +\begin{thebibliography}{9WEINBERG929} +\bibitem[WEINBERG92]{bib:WEINBERG92}{ Gerald M. Weinberg. \textit{Quality Software Management{}{\string:}{} Volume 1, Systems + Thinking.} Dorset House Publishing, 1992. + } +\bibitem[CMMI06]{bib:CMMI06}{ CMMI Product Team. \textit{CMMI for Development, Version 1.2.} Carnegie + Mellon Software Engineering Institute, August 2006.\\{} + \href{http://www.sei.cmu.edu/reports/06tr008.pdf}{\nohyphens{\texttt{URL{}{\string:}{} http{}{\string:}{}//\hspace{0pt}www.\hspace{0pt}sei.\hspace{0pt}cmu.\hspace{0pt}edu/\hspace{0pt}reports/\hspace{0pt}06tr008.pdf}}} + } +\end{thebibliography} + + + +\end{document} \ No newline at end of file diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000001.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000001.pdf new file mode 100644 index 0000000..959037b Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000001.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000002.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000002.pdf new file mode 100644 index 0000000..09e334f Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000002.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000003.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000003.pdf new file mode 100644 index 0000000..b4f11b7 Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000003.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000004.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000004.pdf new file mode 100644 index 0000000..0701ff7 Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000004.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000005.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000005.pdf new file mode 100644 index 0000000..24d6d96 Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000005.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000006.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000006.pdf new file mode 100644 index 0000000..32b7057 Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000006.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000007.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000007.pdf new file mode 100644 index 0000000..4a5067a Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000007.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000008.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000008.pdf new file mode 100644 index 0000000..e69c90c Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000008.pdf differ diff --git a/Master/Seminar engl/Ausarbeitung/tex/img000009.pdf b/Master/Seminar engl/Ausarbeitung/tex/img000009.pdf new file mode 100644 index 0000000..6a3478e Binary files /dev/null and b/Master/Seminar engl/Ausarbeitung/tex/img000009.pdf differ 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 @@ + + +
+ + + Demands that Stress Patterns + Wie Anforderungen Unternehmenskulturen auf die Probe stellen + Sven Eisenhauer + Tobias Koch + 8. Januar 2010 + + Seminar Systems Thinking, Wintersemester 2009/2010
+ Hochschule Darmstadt
+ Referent: Herr Prof. Dr. Andelfinger
+ + + + + + +

+ Im ersten Band &endash; Systems Thinking &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.

+

+ Dieser Artikel fasst die Kerngedanken aus dem dritten Teil &endash; + Demands that Stress Patterns &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. +

+ + +
+ Reifegradstufen von Entwicklungsprozessen + +

In befaßt sich Gerald M. Weinberg mit den Problemen und +Herausforderungen, denen sich Software produzierende Organisationen früher oder +später stellen müssen. Seinen Analysen legt er kulturelle Muster zugrunde, die +in ihrer Beschreibung in etwa dem Reifegrad von Entwicklungsprozessen nach dem Capability Maturity +Modell (CMM) entsprechen. Für die weiteren Ausführungen in +diesem Artikel sind davon die Stufen 1 bis 3 von Bedeutung:

+ +
+
Stufe 1 - initial:
+

Nach Weinberg, der das entsprechende kulturelle Muster variabel nennt, + gibt es auf dieser Stufe kein Konzept von Management als + Entwicklungswerkzeug. 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.

+ +
Stufe 2 - geregelt:
+

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 routiniert, 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.

+ +
Stufe 3 - definiert:
+

Weinberg nennt das kulturelle Muster, das dieser Entwicklungsstufe + entspricht, steuernd, 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 genau [...] + verstanden und werden anhand von Standards, Arbeitsverfahren, Werkzeugen + und Methoden beschrieben, mit der Zielsetzung diese in der gesamten + Organisation zu verheinheitlichen.

+ +
Stufe 4 - quantitiv geregelt:
+

Laut CCM sind Prozesse auf Stufe 4 definerte Prozesse (Stufe 3), die + mit Hilfe statistischer und anderer quantitativer Methoden kontrolliert + werden. Weinberg nennt das kulturelle Muster, das dieser Reifegradstufe + entspricht, voraussschauend, was bedeuten soll, dass die Wahl und + Konzeption neuer Prozesse und Methoden unter Berücksichtigung vorausgehender + Erfahrungen erfolgt.

+ +
Stufe 5 - optimierend:
+

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.

+
+ +

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.

+
+ +
+ Komplexität dynamischer Systeme + +

+ 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 +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. +

+
+ + Zusammenhang zwischen der Komplexität eines dynamischen Systems + und dem benötigten Berechnungsaufwand zur Kontrolle des Systems.
+ Quelle: , Seite 131. + + +
+ +

+Weinberg nennt diesen Sachverhalt The Square Law of Computation. Nach +Weinberg handelt es sich dabei um eine sogenannte natürliche Dynamik, +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 Interventionsdynamik.

+ +

Zieht man als Beispiele für dynamische Systeme die Spiele Tic-Tac-Toe und +Schach heran, dann kann man folgende Feststellungen treffen:

+ +
    +

  • Bei beiden Spielen handelt es sich um abgeschlossene Systeme mit exakt + definierten möglichen Zustandsübergängen.

    • +

  • 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.

    • +

  • 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.

    • +
+ +

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

+ +
    +

  1. um kein abgeschlossenes System handelt,

    2. +

  2. die Zustandsübergänge nicht genau definierbar sind und

    3. +

  3. die Anzahl der Wahlmöglichkeiten pro Zug unermesslich groß ist.

    4. +
+ +

Da es Menschen gibt, die trotz der Komplexität des Spiels sehr erfolgreich +Schach spielen, äußert sich Weinberg optimistisch, dass auch Management als Game of +Control beherrschbar ist, wenn man sich der richtigen Denkweisen und Arbeitsmethoden +bedient.

+
+ +
+ Rückkopplungseffekt zwischen Erfolg und Ambition + +

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.

+

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 +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.

+ +
+ Software-Engineering zur Beherrschung des Rückkopplungseffektes zwischen + Erfolg und Ambition.
+ Quelle: , Seite 136. + +
+ +

Die Tatsache, dass unsere intellektuelle Kapazität begrenzt ist, wir dazu +tendieren, uns immer schwierigere Aufgaben zu suchen, Problemstellungen aber aufgrund +des Square Law of Computation schnell Dimensionen annehmen, die diese Kapazität +übersteigen, nennt Weinberg Size/Complexity-Dynamic.

+ +

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.

+ +

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.

+
+ +
+ Was dabei hilft, die Kontrolle zu behalten + +

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.

+

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.

+

Abbildung 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.

+ +
+ Skalierbarkeit und Limitierung verschiedener Arbeitsmethoden bei + zunehmendem Problemumfang.
+ Quelle: , Seite 148. + +
+ +

Bei der Auswahl der Arbeitswerkzeuge sollten deswegen folgende Faktoren + berücksichtigt werden:

+ +
    +

  • die Art der Aufgabenstellung (z.B. Datamining- oder Datenbankprojekt),

    • +

  • der Projektumfang,

    • +

  • und das geschätzte Risiko.

    • +
+ +

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.

+ + + Positive Grundhaltung + +

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:

+ +
+

Egal wie es erscheint, jeder versucht hilfreich zu sein.

+
+ +

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.

+ + +
+ +
+ Rolle und Einfluss des Kunden + +

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.

+ +
+ Bei zunehmender Anzahl der Kunden, nimmt der nötige Arbeitsaufwand + zur Berücksichtigung aller Kundenanforderungen nicht-linear zu.
+ Quelle: , Seite 161. + +
+ +

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.

+ +

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.

+ +
+ Wie der Einsatz eines Surrogates die effektive Anzahl der Kunden + und den mit den Kunden verknüpften Arbeitsaufwand reduzieren kann.
+ Quelle: , Seite 167. + +
+ +

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.

+ +

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.

+ +

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.

+ +
+ Zusammenhang zwischen Anzahl der Kunden und verlorener Zeit + durch Unterbrechungen in Meetings.
+ Quelle: , Seite 172. + +
+ +

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.

+ +

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.

+ +

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.

+ +

Ä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.

+ +

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.

+ +
+ +
+ Systems Thinking + +

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.

+ +

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.

+ +
+ Einfaches Vensim-Modell zur Veranschaulichung der Rückkopplung + zwischen Ambition, Lösungskomplexität und Projekterfolg. + +
+ +

Das entwickelte Vensim Modell (siehe Abbildung ) +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

+ + +\frac{ \log{ (\text{Mental Capacity}) } }{ \log{ (\text{Complexity of Solution}) } } + + +

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.

+ +

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

+ + +\frac{ (\text{size of problem})^2 }{ \log{ (\text{Software Engineering Simplifications + 1}) } } + + +

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.

+ +
+ Simulation der Erfolgsrate mit verschiedenen Parametern. + +
+ +

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.

+ +
+ Simulation der Lösungskomplexität mit verschiedenden Parametern. + +
+ +

+Die Graphen zur Erfolgsquote (siehe Abbildung ) +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.

+ +

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.

+ +

Im Gegensatz dazu liefern die Graphen zur Komplexität (siehe Abbildung ) 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.

+ +
+ + + + Gerald M. Weinberg. Quality Software Management: Volume 1, Systems + Thinking. Dorset House Publishing, 1992. + + + CMMI Product Team. CMMI for Development, Version 1.2. Carnegie + Mellon Software Engineering Institute, August 2006.
+ URL: http://&zwsp;www.&zwsp;sei.&zwsp;cmu.&zwsp;edu/&zwsp;reports/&zwsp;06tr008.pdf + + + +
-- cgit v1.2.3