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/Archetypes.pdf | Bin 0 -> 371176 bytes 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 ++++++++ Master/Seminar engl/Chap09tk.txt | 79 ++ Master/Seminar engl/Chap10.txt | 110 ++ .../Introduction to Systems Thinking.pdf | Bin 0 -> 149403 bytes .../Praesentation/complexity-engineering.pdf | Bin 0 -> 109404 bytes .../Praesentation/complexity-engineering.png | Bin 0 -> 82098 bytes .../Praesentation/complexity-engineering.svg | 385 +++++++ .../Seminar engl/Praesentation/dynamic-system.pdf | Bin 0 -> 79395 bytes .../Seminar engl/Praesentation/dynamic-system.png | Bin 0 -> 49970 bytes .../Seminar engl/Praesentation/dynamic-system.svg | 215 ++++ Master/Seminar engl/Praesentation/presentation.lyx | 1185 +++++++++++++++++++ .../Seminar engl/Syllabus_JIM-Seminar_WS_09_10.pdf | Bin 0 -> 68899 bytes .../Seminar engl/System dynamics - Wikipedia.pdf | Bin 0 -> 250114 bytes .../Systems - A Journey Along the Way.pdf | Bin 0 -> 104576 bytes ... An Operational Perspective of the Universe.pdf | Bin 0 -> 133725 bytes .../Seminar engl/Systems thinking - Wikipedia.pdf | Bin 0 -> 100949 bytes Master/Seminar engl/Systems_Thinking.pdf | Bin 0 -> 128317449 bytes Master/Seminar engl/rv03.zip | Bin 0 -> 3394 bytes .../Double Mental Capacity, no simplifications.vdf | Bin 0 -> 4459 bytes .../Normal Mental Capacity, no simplifications.vdf | Bin 0 -> 4459 bytes ...ormal Mental Capacity, with Simplifications.vdf | Bin 0 -> 4463 bytes Master/Seminar engl/rv03/ambition.wmf | Bin 0 -> 3254 bytes .../Seminar engl/rv03/complexity_of_solution.wmf | Bin 0 -> 3326 bytes Master/Seminar engl/rv03/export_graph.wmf | Bin 0 -> 2542 bytes Master/Seminar engl/rv03/model2.2mdl | 117 ++ Master/Seminar engl/rv03/model2.mdl | 117 ++ Master/Seminar engl/rv03/successrate.wmf | Bin 0 -> 3168 bytes Master/Seminar engl/shortpres/hdalogo.png | Bin 0 -> 24500 bytes Master/Seminar engl/shortpres/shortpres.lyx | 1199 ++++++++++++++++++++ Master/Seminar engl/shortpres/shortpres.pdf | Bin 0 -> 326642 bytes Master/Seminar engl/sum_chap09.txt | 13 + Master/Seminar engl/sum_chap11.txt | 44 + Master/Seminar engl/vensim/disk2.vip | Bin 0 -> 1082741 bytes Master/Seminar engl/vensim/disk3.vip | Bin 0 -> 3325725 bytes Master/Seminar engl/vensim/disk4.vip | Bin 0 -> 3379354 bytes Master/Seminar engl/vensim/disk5.vip | Bin 0 -> 3379354 bytes Master/Seminar engl/vensim/disk6.vip | Bin 0 -> 3154373 bytes Master/Seminar engl/vensim/venple32.exe | Bin 0 -> 1764811 bytes 62 files changed, 6391 insertions(+) create mode 100644 Master/Seminar engl/Archetypes.pdf 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 create mode 100644 Master/Seminar engl/Chap09tk.txt create mode 100644 Master/Seminar engl/Chap10.txt create mode 100644 Master/Seminar engl/Introduction to Systems Thinking.pdf create mode 100644 Master/Seminar engl/Praesentation/complexity-engineering.pdf create mode 100644 Master/Seminar engl/Praesentation/complexity-engineering.png create mode 100644 Master/Seminar engl/Praesentation/complexity-engineering.svg create mode 100644 Master/Seminar engl/Praesentation/dynamic-system.pdf create mode 100644 Master/Seminar engl/Praesentation/dynamic-system.png create mode 100644 Master/Seminar engl/Praesentation/dynamic-system.svg create mode 100644 Master/Seminar engl/Praesentation/presentation.lyx create mode 100644 Master/Seminar engl/Syllabus_JIM-Seminar_WS_09_10.pdf create mode 100644 Master/Seminar engl/System dynamics - Wikipedia.pdf create mode 100644 Master/Seminar engl/Systems - A Journey Along the Way.pdf create mode 100644 Master/Seminar engl/Systems Thinking - An Operational Perspective of the Universe.pdf create mode 100644 Master/Seminar engl/Systems thinking - Wikipedia.pdf create mode 100644 Master/Seminar engl/Systems_Thinking.pdf create mode 100644 Master/Seminar engl/rv03.zip create mode 100644 Master/Seminar engl/rv03/Double Mental Capacity, no simplifications.vdf create mode 100644 Master/Seminar engl/rv03/Normal Mental Capacity, no simplifications.vdf create mode 100644 Master/Seminar engl/rv03/Normal Mental Capacity, with Simplifications.vdf create mode 100644 Master/Seminar engl/rv03/ambition.wmf create mode 100644 Master/Seminar engl/rv03/complexity_of_solution.wmf create mode 100644 Master/Seminar engl/rv03/export_graph.wmf create mode 100644 Master/Seminar engl/rv03/model2.2mdl create mode 100644 Master/Seminar engl/rv03/model2.mdl create mode 100644 Master/Seminar engl/rv03/successrate.wmf create mode 100644 Master/Seminar engl/shortpres/hdalogo.png create mode 100644 Master/Seminar engl/shortpres/shortpres.lyx create mode 100644 Master/Seminar engl/shortpres/shortpres.pdf create mode 100644 Master/Seminar engl/sum_chap09.txt create mode 100644 Master/Seminar engl/sum_chap11.txt create mode 100644 Master/Seminar engl/vensim/disk2.vip create mode 100644 Master/Seminar engl/vensim/disk3.vip create mode 100644 Master/Seminar engl/vensim/disk4.vip create mode 100644 Master/Seminar engl/vensim/disk5.vip create mode 100644 Master/Seminar engl/vensim/disk6.vip create mode 100644 Master/Seminar engl/vensim/venple32.exe (limited to 'Master/Seminar engl') diff --git a/Master/Seminar engl/Archetypes.pdf b/Master/Seminar engl/Archetypes.pdf new file mode 100644 index 0000000..fe8c529 Binary files /dev/null and b/Master/Seminar engl/Archetypes.pdf differ 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 + + + +
diff --git a/Master/Seminar engl/Chap09tk.txt b/Master/Seminar engl/Chap09tk.txt new file mode 100644 index 0000000..fcd71ec --- /dev/null +++ b/Master/Seminar engl/Chap09tk.txt @@ -0,0 +1,79 @@ +(CHAPTER 09) + +*** + + Choice of management patterns is a result of pressure exercised by outside + demands. + + + +*** +Game of Control + + * Intervention dynamic + + => Largely affected by human decisions on how to regulate a process, serves + as a means to control or mitigate the effects of Natural Dynamics. + + => Example: Brook's Law - "Adding manpower to a late project makes it later." + + * Natural dynamic + + => Beyond direct human control. Human decisions in the form of Intervention + Dynamics are imposed by the circumstances. + + Example: A management pattern is an Intervention Dynamic, however, the choice + of using a pattern is imposed by Natural Dynamics. + + + +*** +Natural Dynamic + + * Example: Square Law of Computation + + * How can any organization handle growth in complexity? + + => Simplifications made by applying general principles. + + Chess: castle early, don't jeopardize your queen, ... + PM: keep team sizes small, break work down into modules, ... + + + +*** +Square Law of Computation + + """ + Unless some simplification can be made, the amount of computation to solve a + set of equations increases at least as fast as the square of the number of + equations. + """ + + + +*** +Size/Complexity Dynamic + + Square Law of Computation combined with the fact, that we cannot alter our + brain capacity quickly or indefinitely. + + With SW development being a very complex and non-deterministic process, the + fact that it is done by humans, whose intellectual capacity is limited, makes + it even more difficult. + + + +*** +Variations: + + * Fault Location Dynamic: + + As the system grows, the number of errors *and* the number of places to *look* + for errors increase, which makes bug-squashing a non-linear effort. + + * Human Interaction Dynamic: + + As the number of people (staff) increases, also the interactions per person + increase and the number of total interactions (in a team) grow immensely. + diff --git a/Master/Seminar engl/Chap10.txt b/Master/Seminar engl/Chap10.txt new file mode 100644 index 0000000..22b7b1b --- /dev/null +++ b/Master/Seminar engl/Chap10.txt @@ -0,0 +1,110 @@ +(CHAPTER 10) + +*** + + """ + Ambitious requirements can easily outstrip even the brightest developer's + mental capacity. + """ + + + +*** +Visualization + + [IMG: "Size/Effort Curve] + + + +*** +Problems + + * The large variability in productivity assessment - as a consequence of many + different contributing factors - can make it difficult to find the + Size/Complexity Dynamic withing raw data. + + * The common practice of using logarithmic scales may obscure the non-linear + nature of the data. + + + +*** +Visualization: Effectiveness of SW Engineering Methods + + [IMG: "Show Method1/Method2 Curve] + + => So it is clearly visible that choice of technologies, working style, etc. + may depend on the nature and complexity of the problem to be solved. + + + +*** +Compositing Engineering Methods + + * Because different methods may excel at different problems or problem sizes + some organizations try to combine methods. + + => Pattern 3 (Steering) managers will readily use a toolkit of engineering + methods. + + => Managers in a "blaming environment" will rather stick to one "standard" + way of doing things, so they cannot be blamed for making the wrong choice. + + + +*** +Considering Risk Management + + * Different methods will have different risk levels, meaning the probability + of success will differ depending on problem size. + + * The risk rate doesn't say anything about the cost. + + * Human beings learn: the success rate of a method will increase, when applied + multiple times. + + +*** +The Threat of Change + + * Managers may choose not to implement new methodologies in order to not + jeopardize their careers. + + Solutions: + + => Move decisions to a higher management level + + => Run a pilot project at minimal size + + => Try to reduce the criticality of the very first project + + + +*** +Helpful Interactions + + 1. Tackle variability by bringing all the dynamics that are part of the + engineering process under control one by one (using Intervention Dynamics). + + The Helpful Model + + 2. Realize that different people develop different models to measure and + control a situation, leading to potentially very different results. + + => "No matter how it looks, everybody is trying to be helpful." + + + +*** +Helpful Interactions + + 1. It's hard to erase existing ineffective behavioral patterns. + + => Try not to erase them, but instead add new patterns that are more + effective, ultimately overlaying the original patterns. + + Variation: + + 2. It's hard to change someone's perception of reality. + + => Propagate adoption of new models of thinking to open people's eyes. diff --git a/Master/Seminar engl/Introduction to Systems Thinking.pdf b/Master/Seminar engl/Introduction to Systems Thinking.pdf new file mode 100644 index 0000000..32323a7 Binary files /dev/null and b/Master/Seminar engl/Introduction to Systems Thinking.pdf differ diff --git a/Master/Seminar engl/Praesentation/complexity-engineering.pdf b/Master/Seminar engl/Praesentation/complexity-engineering.pdf new file mode 100644 index 0000000..747a183 Binary files /dev/null and b/Master/Seminar engl/Praesentation/complexity-engineering.pdf differ diff --git a/Master/Seminar engl/Praesentation/complexity-engineering.png b/Master/Seminar engl/Praesentation/complexity-engineering.png new file mode 100644 index 0000000..cb655a2 Binary files /dev/null and b/Master/Seminar engl/Praesentation/complexity-engineering.png differ diff --git a/Master/Seminar engl/Praesentation/complexity-engineering.svg b/Master/Seminar engl/Praesentation/complexity-engineering.svg new file mode 100644 index 0000000..807128a --- /dev/null +++ b/Master/Seminar engl/Praesentation/complexity-engineering.svg @@ -0,0 +1,385 @@ + + + + + + + + + + + image/svg+xml + + + + + + + + MentalCapacity + + + + SuccessRate + + + + Ambition + + + + Size of Problem + + + + Complexity of Solution + + + + + SoftwareEngineeringSimplifications + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Natural Negative Effect + + + + + + + Management actionwith open choice ofeffect + + + Source: Gerald M. Weinberg, Quality Software Management, Vol. 1 - Systems Thinking, page 136 + + diff --git a/Master/Seminar engl/Praesentation/dynamic-system.pdf b/Master/Seminar engl/Praesentation/dynamic-system.pdf new file mode 100644 index 0000000..583bcbb Binary files /dev/null and b/Master/Seminar engl/Praesentation/dynamic-system.pdf differ diff --git a/Master/Seminar engl/Praesentation/dynamic-system.png b/Master/Seminar engl/Praesentation/dynamic-system.png new file mode 100644 index 0000000..828bf9c Binary files /dev/null and b/Master/Seminar engl/Praesentation/dynamic-system.png differ diff --git a/Master/Seminar engl/Praesentation/dynamic-system.svg b/Master/Seminar engl/Praesentation/dynamic-system.svg new file mode 100644 index 0000000..16b3170 --- /dev/null +++ b/Master/Seminar engl/Praesentation/dynamic-system.svg @@ -0,0 +1,215 @@ + + + + + + + + + image/svg+xml + + + + + + + + Size ofDynamicSystem + + + + Number ofEquations + + + + TotalComputations + + + + Factors perEquation + + + + + + + + + + + + + + + + + + Source: Gerald M. Weinberg, Quality Software Management, Vol. 1 - Systems Thinking, page 131 + + diff --git a/Master/Seminar engl/Praesentation/presentation.lyx b/Master/Seminar engl/Praesentation/presentation.lyx new file mode 100644 index 0000000..9ccaa80 --- /dev/null +++ b/Master/Seminar engl/Praesentation/presentation.lyx @@ -0,0 +1,1185 @@ +#LyX 1.6.5 created this file. For more info see http://www.lyx.org/ +\lyxformat 345 +\begin_document +\begin_header +\textclass beamer +\begin_preamble +\usetheme{Warsaw} +% oder ... + +\setbeamercovered{transparent} +% oder auch nicht +\end_preamble +\use_default_options false +\language english +\inputencoding auto +\font_roman times +\font_sans default +\font_typewriter default +\font_default_family default +\font_sc false +\font_osf false +\font_sf_scale 100 +\font_tt_scale 100 + +\graphics default +\paperfontsize default +\spacing single +\use_hyperref false +\papersize default +\use_geometry true +\use_amsmath 2 +\use_esint 0 +\cite_engine basic +\use_bibtopic false +\paperorientation portrait +\secnumdepth 2 +\tocdepth 2 +\paragraph_separation indent +\defskip medskip +\quotes_language english +\papercolumns 1 +\papersides 1 +\paperpagestyle default +\tracking_changes false +\output_changes false +\author "" +\author "" +\end_header + +\begin_body + +\begin_layout Title +Demands That Stress Patterns +\end_layout + +\begin_layout Author +Tobias +\begin_inset space ~ +\end_inset + +Koch and Sven +\begin_inset space ~ +\end_inset + +Eisenhauer +\end_layout + +\begin_layout Institute +Fachbereich Informatik +\begin_inset Newline newline +\end_inset + +Hochschule Darmstadt +\end_layout + +\begin_layout Date +Seminar Systems Thinking, WS2009/2010 +\end_layout + +\begin_layout Standard +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +% +\backslash +pgfdeclareimage[height=0.5cm]{institution-logo}{hdalogo.png} +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +% +\backslash +logo{ +\backslash +pgfuseimage{institution-logo}} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +% +\backslash +beamerdefaultoverlayspecification{<+->} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout BeginFrame +Contents +\end_layout + +\begin_layout Standard +\begin_inset CommandInset toc +LatexCommand tableofcontents + +\end_inset + + +\end_layout + +\begin_layout Section +Why It's Always Hard To Steer +\end_layout + +\begin_layout Subsection +Terminology +\end_layout + +\begin_layout BeginFrame +Terminology +\end_layout + +\begin_layout Itemize +Intervention Dynamic: +\end_layout + +\begin_deeper +\begin_layout Standard + +\size small +Largely affected by human decisions on how to regulate a process, can serve + as a means to control or mitigate the effects of Natural Dynamics. +\end_layout + +\end_deeper +\begin_layout Itemize +Natural Dynamic: +\end_layout + +\begin_deeper +\begin_layout Standard + +\size small +Beyond direct human control, human decisions are largely imposed by the + circumstances and cannot alter the +\shape italic +form +\shape default + of the dynamic. +\end_layout + +\end_deeper +\begin_layout Subsection +Square Law of Computation +\end_layout + +\begin_layout BeginFrame +Square Law of Computation +\end_layout + +\begin_layout Definition +\begin_inset Quotes eld +\end_inset + +Unless some simplification can be made, the amount of computation to solve + a set of equations increases at least as fast as the square of the number + of equations. +\begin_inset Quotes erd +\end_inset + + +\end_layout + +\begin_layout Pause + +\end_layout + +\begin_layout Corollary +The +\begin_inset Quotes eld +\end_inset + +computer +\begin_inset Quotes erd +\end_inset + + needed to control a system has to become 4 times more mighty as the system + size doubles. +\end_layout + +\begin_layout Pause + +\end_layout + +\begin_layout Fact +The Square Law of Computation is a Natural Dynamic. +\end_layout + +\begin_layout BeginFrame +Square Law of Computation +\end_layout + +\begin_layout Standard +\begin_inset Graphics + filename dynamic-system.png + width 80page% + +\end_inset + + +\end_layout + +\begin_layout BeginFrame +Example +\end_layout + +\begin_layout Itemize +Even trained chicken can play perfect tic-tac-toe. +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +Rightarrow$ +\end_layout + +\end_inset + + The complete game tree can be computed in fractions of a second. +\end_layout + +\end_deeper +\begin_layout Itemize +Nobody can play perfect chess. +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +Rightarrow$ +\end_layout + +\end_inset + + Although chess is a perfect game with all information given and a fixed + board size, not even the largest super-computer can compute the complete + game tree in finite time. +\end_layout + +\end_deeper +\begin_layout BeginFrame +Game of Control +\end_layout + +\begin_layout Itemize +Management is similar to a +\begin_inset Quotes eld +\end_inset + +game of control +\begin_inset Quotes erd +\end_inset + +. +\end_layout + +\begin_layout Itemize +Like chess, management is a very complex game. +\end_layout + +\begin_layout Itemize +Unlike chess, management is not a perfect game: +\end_layout + +\begin_deeper +\begin_layout Itemize +Not all information is available. +\end_layout + +\begin_layout Itemize +Board size is not +\begin_inset Quotes eld +\end_inset + +fixed +\begin_inset Quotes erd +\end_inset + +. +\end_layout + +\end_deeper +\begin_layout Subsection +Size/Complexity Dynamic +\end_layout + +\begin_layout BeginFrame +Size/Complexity Dynamic +\end_layout + +\begin_layout Fact + +\end_layout + +\begin_deeper +\begin_layout Itemize +Human brain capacity is limited. +\end_layout + +\begin_layout Itemize +Complexity of a program grows by the square of its size. +\end_layout + +\begin_layout Itemize +Augmented ambitions after success lead to more complex products. +\end_layout + +\end_deeper +\begin_layout Corollary + +\end_layout + +\begin_deeper +\begin_layout Itemize +Sooner or later a program will become too big to be handled in its entirety + by a human brain. +\end_layout + +\begin_layout Itemize +Development of complex (software) products need to be +\begin_inset Quotes eld +\end_inset + +simplified +\begin_inset Quotes erd +\end_inset + + by methological (software) engineering. +\end_layout + +\end_deeper +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +Size/Complexity Dynamic +\end_layout + +\begin_layout Standard +\begin_inset Graphics + filename complexity-engineering.png + width 80page% + +\end_inset + + +\end_layout + +\begin_layout BeginFrame +Variations +\end_layout + +\begin_layout Itemize +Fault/Location Dynamic: +\end_layout + +\begin_deeper +\begin_layout Standard +As the system grows, the number of errors +\shape italic +and +\shape default + the number of places to +\shape italic +look +\shape default + for errors increase, which makes bug-squashing a non-linear effort. +\end_layout + +\end_deeper +\begin_layout Pause + +\end_layout + +\begin_layout Itemize +Human Interaction Dynamic: +\end_layout + +\begin_deeper +\begin_layout Standard +As the number of people (staff) increases, also the interactions per person + increase and the number of total interactions (in a team) grow immensely. + +\end_layout + +\end_deeper +\begin_layout Section +What Helps To Stay In Control +\end_layout + +\begin_layout Subsection +Methods +\end_layout + +\begin_layout BeginFrame +Fundamental Problem +\end_layout + +\begin_layout Standard + +\shape italic +Ambitious requirements can easily outstrip even the brightest developer's + mental capacity. +\end_layout + +\begin_layout BeginFrame +The Right Tool for the Job +\end_layout + +\begin_layout Itemize +To battle the Natural Dynamics of large projects, the right methods of human + intervention have to be applied. +\end_layout + +\begin_layout Itemize +The right choice of technologies, working styles, methodologies, ... + may depend on the nature and complexity of the problem at hand. +\end_layout + +\begin_layout BeginFrame +Compositing Engineering Methods +\end_layout + +\begin_layout Itemize +Because different methods may excel at different problems or problem sizes + some organizations try to combine methods. +\end_layout + +\begin_layout Itemize +Pattern 3 (Steering) managers will readily use a toolkit of engineering + methods. + +\end_layout + +\begin_layout Itemize +Managers in a +\begin_inset Quotes eld +\end_inset + +blaming environment +\begin_inset Quotes erd +\end_inset + + will rather stick to one +\begin_inset Quotes eld +\end_inset + +standard +\begin_inset Quotes erd +\end_inset + + way of doing things, so they cannot be blamed for making the wrong choice. + +\end_layout + +\begin_layout Subsection +Challenges +\end_layout + +\begin_layout BeginFrame +Taking Risk into Consideration +\end_layout + +\begin_layout Itemize +Different methods will have different risk levels, meaning the probability + of success will differ depending on problem size. +\end_layout + +\begin_layout Itemize +Important: The risk rate doesn't say anything about the cost. +\end_layout + +\begin_layout Itemize +Human beings learn: the success rate of a method will increase, when applied + multiple times. + +\end_layout + +\begin_layout BeginFrame +The Threat of Change +\end_layout + +\begin_layout Itemize +Managers may choose not to implement new methodologies in order to not jeopardiz +e their careers. +\end_layout + +\begin_layout Itemize +Solutions: +\end_layout + +\begin_deeper +\begin_layout Itemize +Move decisions to a higher management level (evasive action). +\end_layout + +\begin_layout Itemize +Run a pilot project at minimal size. +\end_layout + +\begin_layout Itemize +Try to reduce the criticality of the very first project. +\end_layout + +\end_deeper +\begin_layout Subsection +Helpful Interactions +\end_layout + +\begin_layout BeginFrame +Helpful Interactions +\end_layout + +\begin_layout Standard +\align center + +\series bold +1. + Being Systematic +\end_layout + +\begin_layout Itemize +Tackle variability by bringing all the dynamics that are part of the engineering + process under control one by one. +\end_layout + +\begin_layout Pause + +\end_layout + +\begin_layout Standard +\align center + +\series bold +2. + Being Tolerant +\end_layout + +\begin_layout Itemize +Realize that different people develop +\emph on + +\shape italic +\emph default +different models +\shape default + to measure and control a situation, leading to potentially very different + results. +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +Rightarrow$ +\end_layout + +\end_inset + + +\begin_inset Quotes eld +\end_inset + +No matter how it looks, everybody is trying to be helpful. +\begin_inset Quotes erd +\end_inset + + +\end_layout + +\end_deeper +\begin_layout BeginFrame +Helpful Interactions +\end_layout + +\begin_layout Standard +\align center + +\series bold +3. + Being Constructive +\end_layout + +\begin_layout Itemize +It's hard to erase existing ineffective behavioral patterns. +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +Rightarrow$ +\end_layout + +\end_inset + + Try not to erase them, but instead add new patterns that are more effective, + ultimately overlaying the original patterns. +\end_layout + +\end_deeper +\begin_layout Pause + +\end_layout + +\begin_layout Standard +\align center + +\series bold +4. + Being Open-Minded +\end_layout + +\begin_layout Itemize +It's hard to change someone's perception of reality. +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +Rightarrow$ +\end_layout + +\end_inset + + Propagate adoption of new models of thinking to open people's eyes. + +\end_layout + +\end_deeper +\begin_layout Section +Responses To Customer Demands +\end_layout + +\begin_layout BeginFrame +Outside Influence +\end_layout + +\begin_layout Fact +Outside influence contributes to the instability of a software development + process +\end_layout + +\begin_layout BeginFrame +More Customers Increase Development Load +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Greater number of requirements ==> more conflicting requirements +\end_layout + +\begin_layout Itemize +Greater system complexity +\end_layout + +\begin_layout Itemize +More labor to deal with conlicting requirements +\end_layout + +\begin_layout Itemize +Labor to deal with customers +\end_layout + +\end_deeper +\begin_layout Corollary +Nonlinear Size/Complexity Dynamic that can lead to the collpase of a cultural + pattern +\end_layout + +\begin_layout BeginFrame +Two-Way-Relationship +\end_layout + +\begin_layout FrameSubtitle +Between Software Organization and Customer +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +From Software Organization To Customer +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Software +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +From Customer To Software Organization +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Resources +\end_layout + +\begin_layout Itemize +Requirements +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Corollary +A controller is needed to control flow of requirements, resources, outputs + and randomness to Software Organization +\end_layout + +\begin_layout BeginFrame +User != Customer +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Difference between User and Customer +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +User is everyone affected by the system +\end_layout + +\begin_layout Itemize +Customer defines quality +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Effective Customers +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Interact with Software Development +\end_layout + +\begin_layout Itemize +Marketing function +\end_layout + +\end_deeper +\begin_layout BeginFrame +Marketing +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Functions of Marketing +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Reduces number of effective customers by standing between Software Development + and customers. +\end_layout + +\begin_layout Itemize +It filters inputs and outputs. +\end_layout + +\end_deeper +\begin_layout AlertBlock +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Can be dangerous +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Near the core of the Software Development system. +\end_layout + +\begin_layout Itemize +Uncontroled input +\end_layout + +\end_deeper +\begin_layout BeginFrame +Interruptions of Work +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +How much cost interruptions? +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +An increased number of customer also increases the number of interruptions + of work. +\end_layout + +\begin_layout Itemize +E-factor=Uninterrupted Hours / Body-present Hours +\end_layout + +\begin_layout Itemize +Total time = Interruption time + reimmersion time (phone call: 5+15 = 20) +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Meetings are even worse +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +More customers mean more meetings with more people. +\end_layout + +\begin_layout Itemize +More people increase number of interruptions. +\end_layout + +\begin_layout Itemize +Number of interruptions increase wasted time (depends on avg. + length of interruption). +\end_layout + +\end_deeper +\begin_layout BeginFrame +Hardware Configurations +\end_layout + +\begin_layout Itemize +More customers lead to more hardware configurations in production. +\end_layout + +\begin_layout Itemize +Number grows exponentially, so not every possible configuration can be tested, + tests become more complex. + +\end_layout + +\begin_layout Itemize +This leads to less coverage and more faults. +\end_layout + +\begin_layout Itemize +Result in more time needed for fault repairing. +\end_layout + +\begin_layout BeginFrame +Releases +\end_layout + +\begin_layout Itemize +More customer result in more releases and versions used by customers +\end_layout + +\begin_layout Itemize +Leads to more labor in maintaining the hole software product. +\end_layout + +\begin_layout Itemize +More reported faults balance the management tendendcy to increase releases + cycles. + So two releases per year are common to many software organizations. +\end_layout + +\begin_layout BeginFrame +Conclusion +\end_layout + +\begin_layout Block +\begin_inset ERT +status open + +\begin_layout Plain Layout + +<1-> +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Essence +\begin_inset ERT +status open + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Customers influence the demand of a certain cultural pattern in a software + organization. + +\end_layout + +\begin_layout Itemize +Customers influence the size of Software projects. +\end_layout + +\begin_layout Itemize +Management cannot handle projects beyond a specific size perfectly. +\end_layout + +\begin_layout Itemize +Reducing number of effective customers is a common strategy of software + organizations to reduce disturbances on the software organization. +\end_layout + +\end_deeper +\begin_layout EndFrame + +\end_layout + +\end_body +\end_document diff --git a/Master/Seminar engl/Syllabus_JIM-Seminar_WS_09_10.pdf b/Master/Seminar engl/Syllabus_JIM-Seminar_WS_09_10.pdf new file mode 100644 index 0000000..564688f Binary files /dev/null and b/Master/Seminar engl/Syllabus_JIM-Seminar_WS_09_10.pdf differ diff --git a/Master/Seminar engl/System dynamics - Wikipedia.pdf b/Master/Seminar engl/System dynamics - Wikipedia.pdf new file mode 100644 index 0000000..a6aabad Binary files /dev/null and b/Master/Seminar engl/System dynamics - Wikipedia.pdf differ diff --git a/Master/Seminar engl/Systems - A Journey Along the Way.pdf b/Master/Seminar engl/Systems - A Journey Along the Way.pdf new file mode 100644 index 0000000..c057cbe Binary files /dev/null and b/Master/Seminar engl/Systems - A Journey Along the Way.pdf differ diff --git a/Master/Seminar engl/Systems Thinking - An Operational Perspective of the Universe.pdf b/Master/Seminar engl/Systems Thinking - An Operational Perspective of the Universe.pdf new file mode 100644 index 0000000..e4db007 Binary files /dev/null and b/Master/Seminar engl/Systems Thinking - An Operational Perspective of the Universe.pdf differ diff --git a/Master/Seminar engl/Systems thinking - Wikipedia.pdf b/Master/Seminar engl/Systems thinking - Wikipedia.pdf new file mode 100644 index 0000000..8693053 Binary files /dev/null and b/Master/Seminar engl/Systems thinking - Wikipedia.pdf differ diff --git a/Master/Seminar engl/Systems_Thinking.pdf b/Master/Seminar engl/Systems_Thinking.pdf new file mode 100644 index 0000000..492438b Binary files /dev/null and b/Master/Seminar engl/Systems_Thinking.pdf differ diff --git a/Master/Seminar engl/rv03.zip b/Master/Seminar engl/rv03.zip new file mode 100644 index 0000000..840a23d Binary files /dev/null and b/Master/Seminar engl/rv03.zip differ diff --git a/Master/Seminar engl/rv03/Double Mental Capacity, no simplifications.vdf b/Master/Seminar engl/rv03/Double Mental Capacity, no simplifications.vdf new file mode 100644 index 0000000..714c9f5 Binary files /dev/null and b/Master/Seminar engl/rv03/Double Mental Capacity, no simplifications.vdf differ diff --git a/Master/Seminar engl/rv03/Normal Mental Capacity, no simplifications.vdf b/Master/Seminar engl/rv03/Normal Mental Capacity, no simplifications.vdf new file mode 100644 index 0000000..9c28a57 Binary files /dev/null and b/Master/Seminar engl/rv03/Normal Mental Capacity, no simplifications.vdf differ diff --git a/Master/Seminar engl/rv03/Normal Mental Capacity, with Simplifications.vdf b/Master/Seminar engl/rv03/Normal Mental Capacity, with Simplifications.vdf new file mode 100644 index 0000000..5f67a5b Binary files /dev/null and b/Master/Seminar engl/rv03/Normal Mental Capacity, with Simplifications.vdf differ diff --git a/Master/Seminar engl/rv03/ambition.wmf b/Master/Seminar engl/rv03/ambition.wmf new file mode 100644 index 0000000..a7c3e7d Binary files /dev/null and b/Master/Seminar engl/rv03/ambition.wmf differ diff --git a/Master/Seminar engl/rv03/complexity_of_solution.wmf b/Master/Seminar engl/rv03/complexity_of_solution.wmf new file mode 100644 index 0000000..1214ccf Binary files /dev/null and b/Master/Seminar engl/rv03/complexity_of_solution.wmf differ diff --git a/Master/Seminar engl/rv03/export_graph.wmf b/Master/Seminar engl/rv03/export_graph.wmf new file mode 100644 index 0000000..68929bd Binary files /dev/null and b/Master/Seminar engl/rv03/export_graph.wmf differ diff --git a/Master/Seminar engl/rv03/model2.2mdl b/Master/Seminar engl/rv03/model2.2mdl new file mode 100644 index 0000000..766ca53 --- /dev/null +++ b/Master/Seminar engl/rv03/model2.2mdl @@ -0,0 +1,117 @@ +{UTF-8} +success rate= + LN(Mental Capacity) / LN(Complexity of Solution) + ~ + ~ | + +Ambition= INTEG ( + success rate, + 1) + ~ + ~ | + +Complexity of Solution= INTEG ( + size of problem^2 / (LN(Software Engineering Simplifications) + 1), + 2) + ~ + ~ | + +Mental Capacity= + 250 + ~ + ~ | + +size of problem= + Ambition + ~ + ~ | + +Software Engineering Simplifications= + 10 + ~ + ~ | + +******************************************************** + .Control +********************************************************~ + Simulation Control Parameters + | + +FINAL TIME = 20 + ~ Month + ~ The final time for the simulation. + | + +INITIAL TIME = 0 + ~ Month + ~ The initial time for the simulation. + | + +SAVEPER = + TIME STEP + ~ Month [0,?] + ~ The frequency with which output is stored. + | + +TIME STEP = 1 + ~ Month [0,?] + ~ The time step for the simulation. + | + +\\\---/// Sketch information - do not modify anything except names +V300 Do not put anything below this section - it will be ignored +*View 1 +$192-192-192,0,Times New Roman|12||0-0-0|0-0-0|0-0-255|-1--1--1|-1--1--1|96,96,100,0 +10,1,Ambition,317,221,40,20,3,3,0,0,0,0,0,0 +12,2,48,118,217,10,8,0,3,0,0,-1,0,0,0 +1,3,5,1,4,0,0,22,0,0,0,-1--1--1,,1|(244,217)| +1,4,5,2,100,0,0,22,0,0,0,-1--1--1,,1|(164,217)| +11,5,48,206,217,6,8,34,3,0,0,1,0,0,0 +10,6,success rate,206,236,39,11,40,3,0,0,-1,0,0,0 +10,7,Complexity of Solution,320,348,40,20,3,3,0,0,0,0,0,0 +12,8,48,535,349,10,8,0,3,0,0,-1,0,0,0 +1,9,11,7,4,0,0,22,0,0,0,-1--1--1,,1|(396,349)| +1,10,11,8,100,0,0,22,0,0,0,-1--1--1,,1|(485,349)| +11,11,48,439,349,6,8,34,3,0,0,1,0,0,0 +10,12,size of problem,439,368,48,11,40,3,0,0,-1,0,0,0 +10,13,Mental Capacity,178,101,52,11,8,3,0,0,0,0,0,0 +1,14,13,5,1,0,0,0,0,64,0,-1--1--1,,1|(208,149)| +10,15,Software Engineering Simplifications,320,507,68,19,8,3,0,0,0,0,0,0 +1,16,15,7,1,0,0,0,0,64,0,-1--1--1,,1|(338,433)| +1,17,1,11,1,0,0,0,1,64,0,255-0-0,|12||0-0-0,1|(414,258)| +1,18,7,5,1,0,0,0,0,64,0,-1--1--1,,1|(218,295)| +12,19,0,829,104,137,92,3,188,0,0,2,0,0,0 +Complexity of Solution,Graph +12,20,0,762,406,205,193,3,188,0,0,2,0,0,0 +success rate,Graph +///---\\\ +:L<%^E!@ +1:Normal Mental Capacity, with Simplifications.vdf +1:Normal Mental Capacity, no simplifications.vdf +1:Double Mental Capacity, no simplifications.vdf +9:Normal Mental Capacity, with Simplifications +22:$,Dollar,Dollars,$s +22:Hour,Hours +22:Month,Months +22:Person,People,Persons +22:Unit,Units +22:Week,Weeks +22:Year,Years +22:Day,Days +23:0 +15:0,0,0,0,0,0 +19:100,0 +27:2, +34:0, +4:Time +5:success rate +35:Date +36:YYYY-MM-DD +37:2000 +38:1 +39:1 +40:2 +41:0 +24:0 +25:20 +26:20 diff --git a/Master/Seminar engl/rv03/model2.mdl b/Master/Seminar engl/rv03/model2.mdl new file mode 100644 index 0000000..2ea53de --- /dev/null +++ b/Master/Seminar engl/rv03/model2.mdl @@ -0,0 +1,117 @@ +{UTF-8} +success rate= + LN(Mental Capacity) / LN(Complexity of Solution) + ~ + ~ | + +Ambition= INTEG ( + success rate, + 1) + ~ + ~ | + +Complexity of Solution= INTEG ( + (size of problem^2) / (LN(Software Engineering Simplifications) + 1), + 2) + ~ + ~ | + +Mental Capacity= + 250 + ~ + ~ | + +size of problem= + Ambition + ~ + ~ | + +Software Engineering Simplifications= + 10 + ~ + ~ | + +******************************************************** + .Control +********************************************************~ + Simulation Control Parameters + | + +FINAL TIME = 20 + ~ Month + ~ The final time for the simulation. + | + +INITIAL TIME = 0 + ~ Month + ~ The initial time for the simulation. + | + +SAVEPER = + TIME STEP + ~ Month [0,?] + ~ The frequency with which output is stored. + | + +TIME STEP = 1 + ~ Month [0,?] + ~ The time step for the simulation. + | + +\\\---/// Sketch information - do not modify anything except names +V300 Do not put anything below this section - it will be ignored +*View 1 +$192-192-192,0,Times New Roman|12||0-0-0|0-0-0|0-0-255|-1--1--1|-1--1--1|96,96,100,0 +10,1,Ambition,317,221,40,20,3,3,0,0,0,0,0,0 +12,2,48,118,217,10,8,0,3,0,0,-1,0,0,0 +1,3,5,1,4,0,0,22,0,0,0,-1--1--1,,1|(244,217)| +1,4,5,2,100,0,0,22,0,0,0,-1--1--1,,1|(164,217)| +11,5,48,206,217,6,8,34,3,0,0,1,0,0,0 +10,6,success rate,206,236,39,11,40,3,0,0,-1,0,0,0 +10,7,Complexity of Solution,320,348,40,20,3,3,0,0,0,0,0,0 +12,8,48,535,349,10,8,0,3,0,0,-1,0,0,0 +1,9,11,7,4,0,0,22,0,0,0,-1--1--1,,1|(396,349)| +1,10,11,8,100,0,0,22,0,0,0,-1--1--1,,1|(485,349)| +11,11,48,439,349,6,8,34,3,0,0,1,0,0,0 +10,12,size of problem,439,368,48,11,40,3,0,0,-1,0,0,0 +10,13,Mental Capacity,178,101,52,11,8,3,0,0,0,0,0,0 +1,14,13,5,1,0,0,0,0,64,0,-1--1--1,,1|(208,149)| +10,15,Software Engineering Simplifications,320,507,68,19,8,3,0,0,0,0,0,0 +1,16,15,7,1,0,0,0,0,64,0,-1--1--1,,1|(338,433)| +1,17,1,11,1,0,0,0,1,64,0,255-0-0,|12||0-0-0,1|(414,258)| +1,18,7,5,1,0,0,0,0,64,0,-1--1--1,,1|(218,295)| +12,19,0,829,104,137,92,3,188,0,0,2,0,0,0 +Complexity of Solution,Graph +12,20,0,762,406,205,193,3,188,0,0,2,0,0,0 +success rate,Graph +///---\\\ +:L<%^E!@ +1:Normal Mental Capacity, with Simplifications.vdf +1:Normal Mental Capacity, no simplifications.vdf +1:Double Mental Capacity, no simplifications.vdf +9:Normal Mental Capacity, with Simplifications +22:$,Dollar,Dollars,$s +22:Hour,Hours +22:Month,Months +22:Person,People,Persons +22:Unit,Units +22:Week,Weeks +22:Year,Years +22:Day,Days +23:0 +15:0,0,0,0,0,0 +19:100,0 +27:2, +34:0, +4:Time +5:Complexity of Solution +35:Date +36:YYYY-MM-DD +37:2000 +38:1 +39:1 +40:2 +41:0 +24:0 +25:20 +26:20 diff --git a/Master/Seminar engl/rv03/successrate.wmf b/Master/Seminar engl/rv03/successrate.wmf new file mode 100644 index 0000000..290b102 Binary files /dev/null and b/Master/Seminar engl/rv03/successrate.wmf differ diff --git a/Master/Seminar engl/shortpres/hdalogo.png b/Master/Seminar engl/shortpres/hdalogo.png new file mode 100644 index 0000000..0b935c7 Binary files /dev/null and b/Master/Seminar engl/shortpres/hdalogo.png differ diff --git a/Master/Seminar engl/shortpres/shortpres.lyx b/Master/Seminar engl/shortpres/shortpres.lyx new file mode 100644 index 0000000..0da79ab --- /dev/null +++ b/Master/Seminar engl/shortpres/shortpres.lyx @@ -0,0 +1,1199 @@ +#LyX 1.6.4 created this file. For more info see http://www.lyx.org/ +\lyxformat 345 +\begin_document +\begin_header +\textclass beamer +\begin_preamble +\usetheme{Warsaw} +% oder ... + +\setbeamercovered{transparent} +% oder auch nicht +\end_preamble +\use_default_options false +\language english +\inputencoding auto +\font_roman times +\font_sans default +\font_typewriter default +\font_default_family default +\font_sc false +\font_osf false +\font_sf_scale 100 +\font_tt_scale 100 + +\graphics default +\paperfontsize default +\spacing single +\use_hyperref false +\papersize default +\use_geometry true +\use_amsmath 2 +\use_esint 0 +\cite_engine basic +\use_bibtopic false +\paperorientation portrait +\secnumdepth 2 +\tocdepth 2 +\paragraph_separation indent +\defskip medskip +\quotes_language english +\papercolumns 1 +\papersides 1 +\paperpagestyle default +\tracking_changes false +\output_changes false +\author "" +\author "" +\end_header + +\begin_body + +\begin_layout Title +Demands That Stress Patterns +\end_layout + +\begin_layout Author +Tobias +\begin_inset space ~ +\end_inset + +Koch and Sven +\begin_inset space ~ +\end_inset + +Eisenhauer +\end_layout + +\begin_layout Institute +Fachbereich Informatik +\begin_inset Newline newline +\end_inset + +Hochschule Darmstadt +\end_layout + +\begin_layout Date +Seminar Systems Thinking, WS2009/2010 +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +% +\backslash +pgfdeclareimage[height=0.5cm]{institution-logo}{hdalogo.png} +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +% +\backslash +logo{ +\backslash +pgfuseimage{institution-logo}} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + + +\backslash +AtBeginSubsection[]{ +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + + +\backslash +frame{ +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + + +\backslash +frametitle{Content} +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + + +\backslash +tableofcontents[currentsection,currentsubsection] +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + + } +\end_layout + +\begin_layout Plain Layout + +\end_layout + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +% +\backslash +beamerdefaultoverlayspecification{<+->} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout BeginFrame +Content +\end_layout + +\begin_layout Standard +\begin_inset CommandInset toc +LatexCommand tableofcontents + +\end_inset + + +\end_layout + +\begin_layout Section +Why It's Always Hard To Steer +\end_layout + +\begin_layout Subsection +Square law of computation +\end_layout + +\begin_layout BeginFrame +Square law of computation +\end_layout + +\begin_layout Definition +\begin_inset Quotes eld +\end_inset + +Unless some simplification can be made, the amount of computation to solve + a set of equations increases at least as fast as the square of the number + of equations. +\begin_inset Quotes erd +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Pause + +\end_layout + +\end_deeper +\begin_layout Corollary +The +\begin_inset Quotes eld +\end_inset + +computer +\begin_inset Quotes erd +\end_inset + + needed to control a system has to become 4 times more mighty as the system + size doubles. +\end_layout + +\begin_layout BeginFrame +Example +\end_layout + +\begin_layout Itemize +Even trained chicken can play perfect tic-tac-toe. +\end_layout + +\begin_layout Itemize +Nobody can play perfect chess. +\end_layout + +\begin_layout Itemize +Although chess is a perfect game with all information given and a fixed + board size it is too big for every existing computer, human or artifical. +\end_layout + +\begin_layout BeginFrame +What makes management difficult +\end_layout + +\begin_layout Itemize +Management is similar to controlling a game: Get from A to B. +\end_layout + +\begin_layout Pause + +\end_layout + +\begin_layout Itemize +Management is much more complex: Not a perfect game. +\end_layout + +\begin_layout Pause + +\end_layout + +\begin_layout Itemize +Not all information is available. +\end_layout + +\begin_layout Pause + +\end_layout + +\begin_layout Itemize +Board size is not +\begin_inset Quotes eld +\end_inset + +fixed +\begin_inset Quotes erd +\end_inset + +. +\end_layout + +\begin_layout Subsection +Size/Complexity dynamic +\end_layout + +\begin_layout BeginFrame +Size/Complexity Dynamic +\end_layout + +\begin_layout Fact + +\end_layout + +\begin_deeper +\begin_layout Itemize +Human brain capacity is limited. +\end_layout + +\begin_layout Itemize +Complexity of a program grows by the square of its size. +\end_layout + +\begin_layout Itemize +Augmented ambitions after success lead to more complex products. +\end_layout + +\end_deeper +\begin_layout Corollary + +\end_layout + +\begin_deeper +\begin_layout Itemize +Sooner or later a program will become too big to be handled by a human brain. +\end_layout + +\begin_layout Itemize +Development of more complex products need to be +\begin_inset Quotes eld +\end_inset + +simplified +\begin_inset Quotes erd +\end_inset + + by methological software engineering. +\end_layout + +\end_deeper +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +Other forms of this dynamic +\end_layout + +\begin_layout Itemize +Fault/Location Dynamic +\end_layout + +\begin_layout Itemize +People/Interaction Dynamic +\end_layout + +\begin_layout EndFrame + +\end_layout + +\begin_layout Section +What Helps To Stay In Control +\end_layout + +\begin_layout BeginFrame +Fundamental Problem +\end_layout + +\begin_layout Fact +Ambitious requirements can easily outstrip even the brightest developer's + mental capacity. +\end_layout + +\begin_layout BeginFrame +The Right Tool for the Job +\end_layout + +\begin_layout Itemize +To battle the Natural Dynamics of large projects, the right methods of human + intervention have to be applied. +\end_layout + +\begin_layout Itemize +The right choice of technologies, working styles, methodologies, ... + may depend on the nature and complexity of the problem at hand. +\end_layout + +\begin_layout BeginFrame +Compositing Engineering Methods +\end_layout + +\begin_layout Itemize +Because different methods may excel at different problems or problem sizes + some organizations try to combine methods. +\end_layout + +\begin_layout Itemize +Pattern 3 (Steering) managers will readily use a toolkit of engineering + methods. + +\end_layout + +\begin_layout Itemize +Managers in a +\begin_inset Quotes eld +\end_inset + +blaming environment +\begin_inset Quotes erd +\end_inset + + will rather stick to one +\begin_inset Quotes eld +\end_inset + +standard +\begin_inset Quotes erd +\end_inset + + way of doing things, so they cannot be blamed for making the wrong choice. + +\end_layout + +\begin_layout BeginFrame +Taking Risk into Consideration +\end_layout + +\begin_layout Itemize +Different methods will have different risk levels, meaning the probability + of success will differ depending on problem size. +\end_layout + +\begin_layout Itemize +Important: The risk rate doesn't say anything about the cost. +\end_layout + +\begin_layout Itemize +Human beings learn: the success rate of a method will increase, when applied + multiple times. + +\end_layout + +\begin_layout BeginFrame +The Threat of Change +\end_layout + +\begin_layout Itemize +Managers may choose not to implement new methodologies in order to not jeopardiz +e their careers. +\end_layout + +\begin_layout Itemize +Solutions: +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +rightarrow$ +\end_layout + +\end_inset + + Move decisions to a higher management level. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +rightarrow$ +\end_layout + +\end_inset + + Run a pilot project at minimal size. +\end_layout + +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +rightarrow$ +\end_layout + +\end_inset + + Try to reduce the criticality of the very first project. +\end_layout + +\end_deeper +\begin_layout BeginFrame +Helpful Interactions +\end_layout + +\begin_layout Enumerate +Tackle variability by bringing all the dynamics that are part of the engineering + process under control one by one (using Intervention Dynamics). +\end_layout + +\begin_deeper +\begin_layout Standard +\align center + +\series bold +\size large +The Helpful Model +\end_layout + +\end_deeper +\begin_layout Enumerate +Realize that different people develop +\emph on + +\shape italic +\emph default +different models +\shape default + to measure and control a situation, leading to potentially very different + results. +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +rightarrow$ +\end_layout + +\end_inset + + +\begin_inset Quotes eld +\end_inset + +No matter how it looks, everybody is trying to be helpful. +\begin_inset Quotes erd +\end_inset + + +\end_layout + +\end_deeper +\begin_layout BeginFrame +More Helpful Interactions +\end_layout + +\begin_layout Enumerate +It's hard to erase existing ineffective behavioral patterns. +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +rightarrow$ +\end_layout + +\end_inset + + Try not to erase them, but instead add new patterns that are more effective, + ultimately overlaying the original patterns. +\end_layout + +\end_deeper +\begin_layout Enumerate +Variation: It's hard to change someone's perception of reality. +\end_layout + +\begin_deeper +\begin_layout Standard +\begin_inset ERT +status open + +\begin_layout Plain Layout + +$ +\backslash +rightarrow$ +\end_layout + +\end_inset + + Propagate adoption of new models of thinking to open people's eyes. + +\end_layout + +\end_deeper +\begin_layout Section +Responses To Customer Demands +\end_layout + +\begin_layout BeginFrame +Outside Influence +\end_layout + +\begin_layout Fact +Outside influence contributes to the instability of a software development + process +\end_layout + +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +More customers increase development load +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Greater number of requirements ==> more conflicting requirements +\end_layout + +\begin_layout Itemize +Greater system complexity +\end_layout + +\begin_layout Itemize +More labor to deal with conlicting requirements +\end_layout + +\begin_layout Itemize +Labor to deal with customers +\end_layout + +\end_deeper +\begin_layout Corollary +Nonlinear Size/Complexity Dynamic that can lead to the collpase of a cultural + pattern +\end_layout + +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +Two-Way-Relationship +\end_layout + +\begin_layout FrameSubtitle +Between Software Organization and Customer +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +From Software Organization To Customer +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Software +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +From Customer To Software Organization +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Resources +\end_layout + +\begin_layout Itemize +Requirements +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Corollary +A controller is needed to control flow of requirements, resources, outputs + and randomness to Software Organization +\end_layout + +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +User != Customer +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Difference between User and Customer +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +User is everyone affected by the system +\end_layout + +\begin_layout Itemize +Customer defines quality +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Effective Customers +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Interact with Software Development +\end_layout + +\begin_layout Itemize +Marketing function +\end_layout + +\end_deeper +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +Marketing +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Functions of Marketing +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +reduces number of effective customers by standing between Software Development + and customers. +\end_layout + +\begin_layout Itemize +It filters inputs and outputs. +\end_layout + +\end_deeper +\begin_layout AlertBlock +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Can be dangerous +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Near the core of the Software Development system. +\end_layout + +\begin_layout Itemize +Uncontroled input +\end_layout + +\end_deeper +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +Interruptions of work +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +How much cost interruptions? +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +An increased number of customer also increases the number of interruptions + of work. +\end_layout + +\begin_layout Itemize +E-factor=Uninterrupted Hours / Body-present Hours +\end_layout + +\begin_layout Itemize +Total time = Interruption time + reimmersion time (phone call: 5+15 = 20) +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Block +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Meetings are even worse +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +more customers mean more meetings with more people +\end_layout + +\begin_layout Itemize +more people increase number of interruptions +\end_layout + +\begin_layout Itemize +number of interruptions increase wasted time (depends on avg. + length of interruption) +\end_layout + +\end_deeper +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +Hardware configurations +\end_layout + +\begin_layout Itemize +More customers lead to more hardware configurations in production. +\end_layout + +\begin_layout Itemize +Number grows exponentially, so not every possible configuration can be tested, + tests become more complex. + +\end_layout + +\begin_layout Itemize +This leads to less coverage and more faults +\end_layout + +\begin_layout Itemize +Result in more time needed for fault repairing. +\end_layout + +\begin_layout EndFrame + +\end_layout + +\begin_layout BeginFrame +Releases +\end_layout + +\begin_layout Itemize +More customer result in more releases and versions used by customers +\end_layout + +\begin_layout Itemize +Leads to more labor in maintaining the hole software product. +\end_layout + +\begin_layout Itemize +More reported faults balance the management tenendcy to increase releases + cycles. + So two releases per year are common to many software organizations. +\end_layout + +\begin_layout EndFrame + +\end_layout + +\begin_layout Section* +Summary +\end_layout + +\begin_layout BeginFrame +Conclusion +\end_layout + +\begin_layout Block +\begin_inset ERT +status open + +\begin_layout Plain Layout + +<1-> +\end_layout + +\end_inset + + +\begin_inset ERT +status open + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Essence +\begin_inset ERT +status open + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_deeper +\begin_layout Itemize +Customers influence the demand of a certain cultural pattern in a software + organization. + +\end_layout + +\begin_layout Itemize +Customers influence the size Software projects. +\end_layout + +\begin_layout Itemize +Management cannot handle projects beyond a specific size perfectly +\end_layout + +\begin_layout Itemize +Reducing number of effective customers is a common strategy of software + organizations to reduce disturbances on the software organization. +\end_layout + +\end_deeper +\begin_layout Separator + +\end_layout + +\begin_layout Block +\begin_inset ERT +status open + +\begin_layout Plain Layout + +<2-> +\end_layout + +\end_inset + + +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +{ +\end_layout + +\end_inset + +Thank you... +\begin_inset ERT +status collapsed + +\begin_layout Plain Layout + +} +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Block +... + for your attention! +\end_layout + +\begin_layout EndFrame + +\end_layout + +\begin_layout EndFrame + +\end_layout + +\end_body +\end_document diff --git a/Master/Seminar engl/shortpres/shortpres.pdf b/Master/Seminar engl/shortpres/shortpres.pdf new file mode 100644 index 0000000..828ee3e Binary files /dev/null and b/Master/Seminar engl/shortpres/shortpres.pdf differ diff --git a/Master/Seminar engl/sum_chap09.txt b/Master/Seminar engl/sum_chap09.txt new file mode 100644 index 0000000..6a06279 --- /dev/null +++ b/Master/Seminar engl/sum_chap09.txt @@ -0,0 +1,13 @@ +Square law of computation: Unless some simplification can be made, the amount of computation to solve a set +of equations increases at least as fast as the square of the number of equations. +The "computer" needed to control a system has to be 4 times more mighty as the system size doubles. +Example: Trained chicken can play perfect tic-tac-toe, but nobody can play perfect chess. +Chess is a perfect game because all information is known and the size is fixed. +Every management action is like controling a game. +Software engineering is harder to play, because not every thing is known and the board size is unlimited. + +Size/Complexity dynamic: Human brain capacity is fixed but complexity grows with the square of program size. +Ambitions after a success make products more complex. +More complex products need simplfications by software engineering. +Other forms of this dynamic: Fault location, people interaction + diff --git a/Master/Seminar engl/sum_chap11.txt b/Master/Seminar engl/sum_chap11.txt new file mode 100644 index 0000000..0293e76 --- /dev/null +++ b/Master/Seminar engl/sum_chap11.txt @@ -0,0 +1,44 @@ +Chapter 11 + +Outside influence contribute to the instability of a software development process + +11.1 +More customers increase development load: + More customers -> Number of requirements -> System complexity -> Labor to deal with customers + \ Number of conflicting requirements -> Labor to resolve or / + accommodate conflicts + +This is a nonlinear Size/Complexity Dynamic that can lead to the collpase of a cultural pattern + +Customer and software organization have a two-way relationship (C -> SO: requirements, ressources; SO -> C: software) + +A controller is needed to regulate flow of requirements, ressources, random events and outputs of SO + +11.2 +Users != customers (user: everyone affected by the system. customer: defines quality) + +Marketing function reduces number of effective customers by standing between SO and customers. It filters inputs and outputs. But it can become dangerous, because it is placed near to the core of the software development system. + +11.3 +An increased number of customer also increases the number of interruptions of work. +E-factor=Uninterrupted Hours / Body-present Hours +Total time = Interruption time + reimmersion time (phone call: 5+15 = 20) + +Meetings are even worse: more people -> number of interruptions -> wasted time (depends on avg. length of interruption) +More customers -> more meetings with more people -> more wasted time + +11.4 +More customers lead to more hardware configurations in production. +Number grows exponentially, so not every possible configuration can be tested, tests become more complex. +This leads to less coverage and more faults, which result in more time needed for fault repairing. + +11.5 +More customer result in more releases and versions used by customers, which leads to more labor +in maintaining the hole software product. +More reported faults balance the management tenendcy to increase releases cycles. So two releases per year are common +to many software organizations. + +Essence: +Customers influence the demand of a certain cultural pattern in a software organization. +Reducing number of effective customers is a common strategy of software organiztions to reduce +disturbances on the software organization. \ No newline at end of file diff --git a/Master/Seminar engl/vensim/disk2.vip b/Master/Seminar engl/vensim/disk2.vip new file mode 100644 index 0000000..23328fe Binary files /dev/null and b/Master/Seminar engl/vensim/disk2.vip differ diff --git a/Master/Seminar engl/vensim/disk3.vip b/Master/Seminar engl/vensim/disk3.vip new file mode 100644 index 0000000..a6d6e61 Binary files /dev/null and b/Master/Seminar engl/vensim/disk3.vip differ diff --git a/Master/Seminar engl/vensim/disk4.vip b/Master/Seminar engl/vensim/disk4.vip new file mode 100644 index 0000000..a8ba47f Binary files /dev/null and b/Master/Seminar engl/vensim/disk4.vip differ diff --git a/Master/Seminar engl/vensim/disk5.vip b/Master/Seminar engl/vensim/disk5.vip new file mode 100644 index 0000000..c1974b6 Binary files /dev/null and b/Master/Seminar engl/vensim/disk5.vip differ diff --git a/Master/Seminar engl/vensim/disk6.vip b/Master/Seminar engl/vensim/disk6.vip new file mode 100644 index 0000000..9825b6e Binary files /dev/null and b/Master/Seminar engl/vensim/disk6.vip differ diff --git a/Master/Seminar engl/vensim/venple32.exe b/Master/Seminar engl/vensim/venple32.exe new file mode 100644 index 0000000..12b8108 Binary files /dev/null and b/Master/Seminar engl/vensim/venple32.exe differ -- cgit v1.2.3