\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}