Sie sind auf Seite 1von 150

Diplomarbeit vorgelegt im Rahmen der Diplomprüfung zum Diplom-

Informatiker (FH) an der Fachhochschule für Ökonomie und Management

Thema der Diplomarbeit

Der „Duct Tape Programmer― – Mentalität als Einflussgröße des Software-


Engineerings

Betreuer
Dr.-Ing. Torsten Finke

Autor
Jens Krahe
Ubierstr. 81
53173 Bonn

krahe@pixelized.de
http://twitter.com/krahe

Datum
Bonn,
Ehrenwörtliche Erklärung

Hiermit versichere ich, dass die vorliegende Arbeit von mir selbstständig und ohne
unerlaubte Hilfe angefertigt worden ist, insbesondere dass ich alle Stellen, die
wörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen sind, durch
Zitate als solche gekennzeichnet habe. Ich versichere auch, dass die von mir
eingereichte schriftliche Version mit der digitalen Version übereinstimmt. Weiterhin
erkläre ich, dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen
Prüfungsbehörde vorgelegen hat. Ich erkläre mich damit einverstanden, dass die
Arbeit der Öffentlichkeit zugänglich gemacht wird. Ich erkläre mich damit
einverstanden, dass die Digitalversion dieser Arbeit zwecks Plagiatsprüfung auf die
Server externer Anbieter hochgeladen werden darf. Die Plagiatsprüfung stellt keine
Zurverfügungstellung für die Öffentlichkeit dar.

Bonn,
I

Vorwort

Ich möchte mich bei der Firma triplesense GmbH für ihre Geduld bedanken und bei
Nils Hagemann, der mich als waschechter „Duct Taper“ zu diesem Thema inspiriert
hat. Zudem möchte ich auch meiner Frau danken, die mich in dieser Zeit unterstützt
hat.

(http://geekandpoke.typepad.com/)
II

Inhaltsverzeichnis

Vorwort ........................................................................................................................ I

Inhaltsverzeichnis ..................................................................................................... II

Abkürzungsverzeichnis ........................................................................................... IV

Abbildungsverzeichnis ............................................................................................ VI

Tabellenverzeichnis ................................................................................................VII

1 Einleitung .............................................................................................................1

1.1 Problemstellung ............................................................................................1

1.2 Ziel der Arbeit...............................................................................................2

1.3 Vorgehensweise ............................................................................................2

1.4 Leserkreis ......................................................................................................4

1.5 Buchempfehlungen .......................................................................................5

1.6 Hinweise zu Formatierungen und „Creative Commons“-Lizenz .................5

2 Softwaretechnik ...................................................................................................6

2.1 Grundlagen ...................................................................................................6

2.2 Vorgehensmodelle und Prozessmodelle .....................................................27

2.3 Softwarequalität ..........................................................................................63

3 Duct Tape Programmer ....................................................................................75

3.1 Begriffsherkunft ..........................................................................................76

3.2 Besondere Problemstellung ........................................................................78

3.3 Vorgehen.....................................................................................................78

3.4 Analyse der Fragestellungen in „Coders at Work“.....................................79

3.5 Charakteristiken ..........................................................................................81


III

3.6 Mentalität ..................................................................................................105

3.7 Kritische Würdigung ................................................................................107

4 Mentalität als Einflussgröße des Software-Engineerings ............................109

4.1 Interviewfragen mit Relevanz für das Software-Engineering ..................110

4.2 Aussagen, die Themenfelder des Software-Engineerings betreffen .........121

4.3 Einordnung in die Softwareentwicklung ..................................................126

4.4 Kritische Würdigung ................................................................................127

5 Zusammenfassung und Fazit..........................................................................128

Literaturverzeichnis ...............................................................................................130

Index ........................................................................................................................139
IV

Abkürzungsverzeichnis

ACM Association for Computing Machinery

ASD Adaptive Software Development

API Application Programming Interface

CASE Computer Aided Software Engineering

DSDM Dynamic System Development Method

FDD Feature Driven Development

GHC Glasgow Haskell Compiler

IEEE Institute of Electrical and Electronics Engineers

JSON JavaScript Object Notation

LOC Lines of Code

KLOC Kilo Lines of Code

Q&P Quality and Productivity

OTP Open Telecom Platform

RUP Rational Unified Process

SaaS Software as a Service

SEI Software Engineering Institute

SW Software

SWEBOK Guide to the Software Engineering Body of Knowledge

TDD Test Driven Development

UML Unified Modeling Language


V

UP Unified Process

V&V Verification and Validation

XP Extreme Programming
VI

Abbildungsverzeichnis

Abbildung 1: Hardware/software cost trends ...............................................................8

Abbildung 2: Proklamierte „Silver Bullets“ in der Informatik ...................................11

Abbildung 3: Manifesto for Agile Software Development ........................................13

Abbildung 4: Software-Engineering innerhalb der Informatik ..................................24

Abbildung 5: Annäherung durch iterative Entwicklung .............................................35

Abbildung 6: Vorgehensweise der inkrementellen Entwicklung ...............................36

Abbildung 7: Ausführung des Timeboxing-Modells..................................................40

Abbildung 8: V-Modell von 1979 nach Boehm .........................................................42

Abbildung 9: Vereinfachte Darstellung der Struktur des V-Modells XT...................44

Abbildung 10: Phasen, Iterationen und Arbeitsabläufe ..............................................47

Abbildung 11: XP-Prozess – Projektüberblick ...........................................................53

Abbildung 12: The five processes of FDD with their outputs ....................................56

Abbildung 13: Bedeutung verschiedener Qualitätsaspekte der Zeit...........................63

Abbildung 14: Qualitätsbaum von Ludewig, et al. .....................................................64

Abbildung 15: Gliederung der Softwarequalitätssicherung nach Ludewig, et al. ......66

Abbildung 16: Positionierungskreuz Scientist, Engineer, Artist, Craftsman ...........120


VII

Tabellenverzeichnis

Tabelle 1: Gegenüberstellung von Werkstatt und Atelier ..........................................26

Tabelle 2: Projekterfolge der Interview-Partner in „Coders at Work“ .....................104

Tabelle 3: Abgeleitete Mentalität des „Duct Tape Programmers“ ...........................107


1

1 Einleitung
Die vorliegende Arbeit beschäftigt sich mit dem „Duct Tape Programmer“ nach
Spolsky. Der Begriff des „Duct Tape Programmers“ wurde in Rahmen eines
Weblog-Artikels von Joel Spolsky geprägt (Spolsky, 2009). Dieser Artikel
beschreibt, abgeleitet aus einem Interview, das Peter Seibel im Buch „Coders at
Work“ (Seibel, 2009) mit Jamie Zawinski führt, einen bestimmten Stereotypen eines
Programmierers. Das Buch „Coders at Work“ beinhaltet insgesamt 15 Interviews mit
bekannten Persönlichkeiten aus der Programmierszene. Diese Arbeit untersucht
anhand der von Peter Seibel geführten Interviews, ob eine Mentalität, wie es Spolsky
in seinem Artikel beschreibt, festgestellt werden kann und ob sie einen Einfluss auf
das Software-Engineering haben könnte. Besonders erwähnt werden muss, dass diese
Arbeit zwar wissenschaftlich erarbeitet wurde, es jedoch aufgrund der geringen
Grundgesamtheit mit N = 15 davon ausgegangen wird, dass sie nicht repräsentativ
ist.

1.1 Problemstellung
Spolsky hat den Duct Tape Programmer auf Basis des ersten Interviews mit Jamie
Zawinski dargestellt. Zawinskis Aussagen repräsentieren nach Spolsky einen
bestimmten Stereotyp von Programmierer. Dieser besitzt eine besondere Mentalität
in Bezug auf die Entwicklung von Softwareprodukten. Inwieweit der Duct Tape
Programmer auch aus persönlichen Erfahrungen Spolskys entstanden ist, wird in dem
Artikel nicht erwähnt.

Die Mentalität des Duct Tape Programmer nach Spolsky kann am besten mit einer
Metapher beschrieben werden: Die zu lösende Aufgabe besteht darin einen Nagel mit
einem Hammer in die Wand zu schlagen. Ein Duct Tape Programmer nimmt den
Hammer in die Hand und versucht damit den Nagel in die Wand zu schlagen. Wenn
der Nagel sitzt, ist für ihn die Aufgabe erledigt. Ist der Nagel schief, versucht er, ihn
zu korrigieren. War die Wand zu stark, sucht er nach einem neuen, stärkeren Nagel.
Bei all seinem Schaffen versucht er, den Nagel in die Wand zu bekommen, und
korrigiert seine Fehler, nachdem er sie gemacht hat. Diese Mentalität ist in der
heutigen Softwareentwicklung einmalig. Je nach Ansatz des Software-Engineerings
2

würde ein Entwickler zunächst einmal einen Test in Form einer Trockenübung
machen, bevor er mit dem Hammer den Nagel in Wand schlägt. Er würde die Wand
dahingehend untersuchen, ob der Nagel überhaupt in die Wand geschlagen werden
kann. Der Hammer, der Nagel und die Wand würden vorher untersucht, ob alle drei
die richtige Beschaffenheit für die Aufgabe besitzen und, gegebenenfalls
ausgetauscht werden. Möglicherweise würde der Entwickler vorher mathematisch
berechnen, in welchem Winkel der Nagel am besten in die Wand geschlagen werden
sollte, und auf dieser Basis eine Maschine bauen, die einen Nagel korrekt in die
Wand schlägt. Eine Maschine wäre zudem dann sinnvoll, wenn plötzlich hundert
Nägel in die Wand geschlagen werden müssten. Diese Maschine würde vor der
Inbetriebnahme ausgiebig getestet, ob sie Nägel korrekt in die Wand schlagen kann.
Sie würde zudem auf Basis der ISO-Norm entwickelt und vom TÜV abgenommen
werden, damit sie auch in anderen Projekten, in denen zum Beispiel Baumstämme in
den Boden gerammt werden müssen, eingesetzt werden kann. Das Einzige, was nicht
gemacht wird, ist, den Nagel in die Wand zu schlagen.

Die Problemstellung kann deshalb in zwei Teilbereiche operationalisiert werden.


Erstens: Gibt es den von Joel Spolsky im Artikel erwähnten Duct Tape
Programmer? Zweitens: Welchen Einfluss könnte eine solche Mentalität auf das
Software-Engineering haben?

1.2 Ziel der Arbeit


Das Ziel der Arbeit ist es zum einen die Mentalität des Duct Tape Programmers auf
Basis der 15 Interviews aus dem Buch „Coders at Work“ von Peter Seibel abzuleiten.
Als Leitbild dient hierzu der Artikel „The Duct Tape Programmer“ von Joel Spolsky.
Zum anderen wird anhand der Mentalität und Aussagen aus den Interviews, die
direkt Themengebiete des Software-Engineerings ansprechen, qualitativ überprüft,
ob ein Einfluss auf das Software-Engineering festgestellt werden kann.

1.3 Vorgehensweise
Im ersten Teil der Arbeit werden die Problemstellung, das Ziel der Arbeit und der
Leserkreis festgelegt. Im zweiten Teil wird das Software-Engineering im
3

Allgemeinen betrachtet. Besonders wurden dabei die Vorgehens- und


Prozessmodelle des Softwareherstellungsprozesses betrachtet, weil diese seit Beginn
das Kernstück des Software-Engineerings darstellen (Hesse, et al., 1992 S. 28).
Copliens „A Generative Development – Process Pattern Language” (Coplien, 1998)
wurde bei den Vorgehens- und Prozessmodellen nicht betrachtet, weil es „Process
Patterns“ sind und zudem in der Basisliteratur keine Erwähnung finden. Auch wurde
kurz die Softwarequalität betrachtet, weil Spolsky im Artikel den Duct Tape
Programmer damit in Verbindung bringt. Weitere Bereiche des Software-
Engineerings, wie zum Beispiel Wartung und Reengineering, sind aus Platzgründen
nicht mit aufgenommen worden. Das Software-Engineering wurde dabei unabhängig
vom Thema des Duct Tape Programmers betrachtet, um eine neutrale Sicht zu
erhalten. Im dritten Teil wird die Mentalität des Duct Tape Programmers qualitativ
hergeleitet. Die Mentalität wird anhand von Charakteristiken festgestellt. Diese
Charakteristiken wurden aus den Interviews extrahiert und anschließend
kategorisiert. Die dargestellte Mentalität des Duct Tape Programmers in dieser
Arbeit ist deshalb zwar wissenschaftlich hergeleitet, aber aufgrund der geringen
Grundgesamtheit von N = 15 nicht repräsentativ. Im vierten Teil wird die
Einflussgröße auf Basis der im Buch vorliegenden Aussagen qualitativ festgestellt.
Dies betrifft zum einen Software-Engineering-relevante Fragestellungen von Peter
Seibel und inhaltliche Aussagen aus den Interviews, die für die
Charakterbestimmung nicht relevant waren. Zudem wird auf Basis der gewonnen
Erkenntnisse geschaut, wie der Duct Tape Programmer in das Software-Engineering
eingeordnet werden könnte. Das Kapitel besitzt viele Querverweise, die für Leser
gedacht sind, die nur das dritte und vierte Kapitel dieser Arbeit lesen möchten. Der
fünfte Teil stellt den Schluss der Arbeit mit einer Zusammenfassung und Fazit dar.

Es soll nicht unerwähnt bleiben, dass versucht wurde, diese Arbeit komplett digital
zu erstellen. Dies betrifft alle Arbeitsschritte, die für eine Arbeit in diesem Umfang
nötig sind. Dieses Vorgehen ist auch im Jahr 2010 und trotz des Internets nicht
möglich, vor allem bei der Recherche. So war es nicht möglich, für eine
wissenschaftliche Arbeit wissenschaftlich relevante Unterlagen digital zu erhalten,
ohne dafür bezahlen zu müssen. Dies trifft insbesondere auf die Standardwerke der
Informatik und des Software-Engineerings zu.
4

Das Buch „Coders at Work“ wurde ebenfalls digital für diese Arbeit benutzt. Dazu
diente die Kindle-Edition des Buches. Das Referenzieren der Zitate weicht deshalb
von der Seitenmetapher ab. Alle Quellenangaben, die zu „Coders at Work“ getätigt
wurden, sind „Kindle Locations“. Falls der Leser als Referenzwerk das gedruckte
Buch von „Coders at Work“ besitzt und Zitate nachschlagen möchte, möge er die in
dieser Arbeit aufgeführten Seiten durch 12,38 teilen, um die Papierseite als Referenz
zu erhalten.

Ich möchte dem Leser dieser Arbeit auch nicht die gesammelten Erfahrungen in
Bezug auf das wissenschaftliche Arbeiten mit dem Kindle-Buch „Coders at Work“
vorenthalten. Das Buch wurde auf dem iPad mit der Kindle-App gelesen. Die
relevanten Zitate wurden mit der Kindle-Funktion „Highlight“ markiert. Durch die
Kindle-Whispersync-Funktion wurden die markierten Stellen unter dem Account des
Autors gespeichert. Die markierten Stellen wurden anschließend auf einem Mac mit
der Kindle-Applikation in das Programm OmniOutliner übertragen. Dies musste
durch die Computer-(Kindle for Mac)/Mensch-(Autor dieser Arbeit)/Computer-
(OmniOutliner)-Schnittstelle mit der Methode des Abtippens geschehen. Amazon
stellt den Export der „Highlight“ Funktion, aus Gründen, die dem Autor dieser
Arbeit nicht bekannt sind, nicht zur Verfügung. In OmniOutliner wurden die
Aussagen anschließend einer inhaltlichen Analyse unterzogen und in Charakter- und
Software-Engineering-relevante Aussagen geclustert. Pro Cluster wurden die
Aussagen anschließend in Kategorien zusammengefasst. Das Ergebnis dieses
Vorgehens ist im dritten und vierten Kapitel niedergeschrieben.

1.4 Leserkreis
Der Leserkreis dieser Arbeit sind als Primärzielgruppe Programmierer, die in der
Informatik auch liebevoll „Coding Monkeys“ genannt werden.

Sollte sich der Leser in dem Kapitel 1.1 (S. 1) durch die Metapher des „Duct Tape
Programmers“ angesprochen fühlen, ist die Arbeit eine wertvolle Ressource für ihn.
In diesem Fall sollte der zweite Teil übersprungen werden, es sei denn, man ist an
einem komprimierten Überblick des Software-Engineerings interessiert. Zudem
kommt diese Arbeit für Personen in Frage, die entweder das Buch „Coders at Work“
5

gelesen haben und eine strukturierte Analyse im Kontext des Artikels von Joel
Spolskys „Duct Tape Progammers“ erhalten möchten, oder Personen, die das Buch
nicht gelesen haben und die wesentlichen Fakten des Buches zusammengefasst
präsentiert bekommen möchten. Für diejenigen, die das Buch „Coders at Work“
nicht gelesen haben, wird empfohlen, den zweiten Teil dieser Arbeit zu
überspringen. Diese Arbeit ist auch für Personen interessant, die einen neutralen,
schnellen und kompakten Einstieg in die Welt des Software-Engineerings erhalten
möchten, mit dem Schwerpunkt Vorgehen- und Prozessmodelle sowie
Softwarequalität.

1.5 Buchempfehlungen
Es können vier Bücher empfohlen werden. Das erste betrifft das Referenzwerk für
Software-Engineering von Ludewig et al. (Ludewig, et al., 2010). Es ist derzeit das
aktuellste Werk zu dem Thema und bietet einen guten Überblick über das Software-
Engineering. Es wurde deshalb auch als Referenz für diese Arbeit verwendet. Brooks
Buch (Brooks, 2003) stellt die zweite zeitlose Empfehlung dar und sollte von jedem
Informatiker gelesen werden. Das dritte Buch ist das „The Patterns Handbook“ von
Linda Rising (Rising, 1998) und ist wie Brocks Buch eine Sammlung von Essays
über das Software-Engineering. Copliens Essay „A Generative Development-Process
Pattern Language“ (Coplien, 1998) stellt in dem Buch das wichtigste Werk dar und
betrachtet den Softwareherstellungsprozess aus einer anderen Perspektive (im
Gegensatz zu den vorgestellten Vorgehens- und Prozessmodelle in dieser Arbeit).
Die letzte und vierte Empfehlung ist das Buch „Coders at Work“ (Seibel, 2009). Das
Buch sollte, genauso wie die Bücher „Programmers at Work“ (Lammers, 1986) und
„Masterminds of Programming“ (Biancuzzi, et al., 2009), in Universitäten Teil des
Lehrplans sein.

1.6 Hinweise zu Formatierungen und „Creative Commons―-Lizenz


In diesem Dokument sind aufgrund von englischen Begriffen und englischen Zitaten
die Formatierungen in der Maximalausprägung in Teilen nicht sehr leserfreundlich.
Dies bringt der Zwang der einheitlichen Formatierung bei einer wissenschaftlichen
Arbeit mit sich. Querverweise in dieser Arbeit dienen nur als Referenz. Der
6

aufmerksame Leser kann die Querverweise deshalb ignorieren. Zitiert wurde in


dieser Arbeit nach ISO 690 (erstes Element und Datum). Diese Arbeit unterliegt der
Creative-Commons-Lizenz „Attribution Non-Commercial Share Alike“ (cc by-nc-
sa).

2 Softwaretechnik
Das Kapitel Softwaretechnik soll dem Leser dieser Arbeit einen Überblick über das
Thema gewähren und teilt sich in drei Unterkapitel: Grundlagen, Vorgehens- und
Prozessmodelle und Softwarequalität. Die Grundlagen setzen den Leser in den
Kontext, was Inhalt und Umfang von Software-Engineering betrifft. Anschließend
werden bekannte Vorgehens- und Prozessmodelle des Software-Engineerings
vorgestellt, da diese einen wesentlichen Bestandteil eines Softwareherstellungs-
prozesses bilden. Softwarequalität wird nur kurz besprochen, weil in dem Artikel
„The Duct Tape Programmer“ von Joel Spolsky darauf Bezug genommen wird. Alle
drei Unterkapitel enden mit einer kritischen Würdigung.

2.1 Grundlagen
In diesem Kapitel werden die Grundlagen des Software-Engineering dargestellt. Es
wird mit der Historie des Begriffs „Software-Engineering“ begonnen. Die Historie
beginnt mit der noch anhaltenden Softwarekrise und endet mit der agilen Bewegung.
Anschließend werden Definitionen besprochen, die für diese Arbeit relevant sind.
Dabei werden zusammengesetzte Worte wie zum Beispiel „Software“ und
„Engineering“ von Software-Engineering separat voneinander definiert. Danach
werden die Ziele des Software-Engineerings aufgeführt. Daneben werden zum einen
die Eigenschaften und der Wirkungskontext von Software beschrieben. Das Kapitel
endet mit den Wissensgebieten des Software-Engineerings auf Basis des SWEBOK.

2.1.1 Einführung
Die Informatik ist nach wie vor eine junge Wissenschaft. Die ersten Computer
wurden Mitte 1940er Jahre gebaut. In den Jahren 1940 bis 1960 war die Anschaffung
und Nutzung von Computer-Hardware sehr teurer. Die Programmierung erfolgte fast
ausschließlich hardwarenah in Assembler, meist ohne ein Betriebssystem.
7

Applikationen, die zu diesem Zeitpunkt entwickelt wurden, waren vom Umfang sehr
gering und wurden meist von nur einer Person entwickelt. Die Software war von und
für Experten auf ein spezielles Problem zugeschnitten und wurden nach der Lösung
oft verworfen. Anwendungsgebiete erstreckten sich auf numerische-, technische-,
naturwissenschaftliche Probleme oder die Programmierung bekannter mathematisch
fundierter Algorithmen. Die Software und Hardware war zu dieser Zeit nur von
Experten bedienbar und nicht wie heute vom normalen Anwender (Grabowski,
2004), (Van Vliet, 2008 S. 2). Unabhängige Softwareentwicklungsunternehmen gab
es im Grunde nicht. Die Software wurde von den Hardware-Herstellern entwickelt
und kostenlos beigelegt. Software wurde zu diesem Zeitpunkt als Servicebestandteil
der Hardware angesehen (Van Vliet, 2008 S. 2). Durch die Ablösung der Röhren-
und Relaisrechner durch Computer mit Transistoren in den sechziger Jahren des 19.
Jahrhunderts wurde die Hardware wesentlich preiswerter und leistungsfähiger
(Schallehn, 2008). Gordon Moore formulierte 1965 in einem Artikel der Zeitschrift
Electronics (Moore, 1965) die Beobachtung, dass sich die Anzahl an Transistoren
auf einem handelsüblichen Prozessor alle achtzehn Monate verdoppelt 1. Computer
waren durch die Einführung der Transistoren und später durch den integrierten
Schaltkreis dem normalen Anwender, dem „Nicht-Informatiker“ zugänglich. Ab
diesem Zeitpunkt kam es zu einer explosionsartigen Ausweitung der
Anwendungsgebiete für Computer. Programme entstanden, bei denen das finanzielle
oder sogar personelle Risiko vom Menschen abhing.

2.1.1.1 Softwarekrise
Die Softwarekrise beschreibt ein in der Mitte der 1960er Jahre aufgetretenes
Problem: Erstmalig überstiegen die Kosten für die Software die der Hardware
(Sommerville, 2007 S. 30), (Van Vliet, 2008 S. 2-3). 2

1 Die Bezeichnung Moore„sches Gesetz wurde 1970 von „Carver Mead“ auf Basis Moores Beobachtung geprägt.
2
Als Beispiel wird hier in der Literatur die Entwicklung des IBM OS/360 Betriebssystems aufgeführt.
8

Abbildung 1: Hardware/software cost trends (Software and its impact: a quantitative assessment., 1973 S. 5)

Der Begriff Softwarekrise oder auch „Software Gap“ wurde auf der Nato-Konferenz
1968 von Dr. Edward E. David und Alexander G. Fraser in ihrem „Position Paper“
geprägt (Software Engineering: Report of a conference sponsored by the NATO
Science Committee, 1968 S. 70) .

Edsger W. Dijkstras führt in seiner Dankesrede „The Humble Programmer“ 1972


zum Turing Award auf: „Als es noch keine Rechner gab, war auch das
Programmieren noch kein Problem, als es dann ein paar leistungsschwache Rechner
gab, war das Programmieren ein kleines Problem und nun, wo wir gigantische
Rechner haben, ist auch das Programmieren zu einem gigantischen Problem
geworden. In diesem Sinne hat die elektronische Industrie kein einziges Problem
gelöst, sondern nur neue geschaffen. Sie hat das Problem geschaffen, ihre Produkte
zu nutzen.― (Dijkstras, 1972)3

Durch die preiswerte und leistungsfähige Hardware stiegen ab 1960 schnell der
Umfang und die Komplexität von Software. Vorher undenkbare Softwareprojekte

3
Eine der ersten gesicherten Erwähnungen der Softwarekrise findet sich in Edsger W. Dijkstras Dankesrede zum
Turing Award „The Humble Programmer“ (deutsch: „Der bescheidene Programmierer“, EWD340), die er 1972
hielt und die im „Communications of the ACM“-Magazin veröffentlicht wurde.
9

ließen sich jetzt umsetzen (Sommerville, 2004 S. 4) und erforderten mehr als einen
Entwickler. Programmieren galt zu diesem Zeitpunkt als Kunst (Art) und nicht als
Handwerk (Craft). Gleichzeitig gab es keinerlei formale Ausbildung in diesem
Berufszweig, das Programmieren wurde nur durch „Learning by Doing“ und „Try
and Error“ gelernt. Letztendlich wurden große Softwareprojekte organisatorisch
gelöst, indem einfach mehr Programmierer an einem Projekt arbeiteten, der
sogenannte „Million Monkey“-Ansatz (Van Vliet, 2008 S. 2). Große
Softwareprojekte waren hierdurch oft Jahre im Rückstand (Borchers, 2004). Die
daraus resultierende Software kostete oft mehr als vorgesehen, war unzuverlässig,
schwer zu pflegen und arbeitete mangelhaft. Dieses Problem der
Softwareentwicklung entwickelte sich 1960 zum Manifest des Jahrzehnts.

2.1.1.2 Nato-Konferenz
Anlässlich der „Softwarekrise“ fand eine Konferenz über die Probleme in der
Softwareentwicklung jeweils in 1968 und 1969 statt (Randell, 2001). Sponsor beider
Konferenzen war das NATO Science Comittee. In der ersten NATO-Konferenz
wurde erstmals der Begriff „Software-Engineering“ eingeführt. Der Begriff
„Software-Engineering“ wurde gewählt, um bewusst auf ein Defizit in der
Softwareentwicklung aufmerksam zu machen, das durch eine ingenieurmäßige
Durchführung des Softwareentwicklungsprozesses gelöst werden sollte (Bauer, 1975
S. 523).

Software-Engineering wurde auf der Nato-Konferenz 1969 von Friedrich L. Bauer


zum ersten Mal definiert: „The Establishment and use of sound engineering
principles in order to obtain economically software that is reliable and works
efficiently on real machines.― (Bauer, 1975 S. 524), (Van Vliet, 2008 S. 5).

Die Konferenz-Teilnehmer wollten mit dem Begriff „Software-Engineering“


absichtlich die damalige Fachwelt provozieren und Aufmerksamkeit erregen. „The
phrase ‗software engineering‘ was deliberately chosen as being provocative, in
implying the need for software manufacture to be based on the types of theoretical
foundations and practical disciplines, that are traditional in the established branches
10

of engineering.― (Software Engineering: Report of a conference sponsored by the


NATO Science Committee, 1968 S. 8).

Die Nato-Konferenz hatte keine Lösung für das Problem der Softwarekrise, doch es
war die Geburtsstunde des Software-Engineerings. Ergebnis war die Erkenntnis, dass
Software systematisch geplant und entwickelt werden muss (Zöller-Greer, 2002 S. 2-
3) . Seitdem hat sich Software-Engineering zu einer wissenschaftlichen Disziplin
entwickelt, die sich mit den praktischen Problemen der Herstellung von Software
beschäftigt und deren Prinzipien, Methoden und Techniken dokumentiert (Winter,
2005 S. 7).

2.1.1.3 No Silver Bullet


Im Zeitraum von 1970 bis 1990 gab es eine Vielzahl von Lösungsansätzen, um der
Softwarekrise entgegenzuwirken. Die meisten wurden aus einer
Managementperspektive verfasst und zielten darauf ab, durch einen industriellen
Produktionsprozess (Taylorismus) die Entwicklungskosten genauso wie bei der
Hardware zu senken. 4 Die objektorientierte Programmierung sollte in den 1980er
Jahren endgültig die „Kunst des Programmierens“ so weit reduzieren, dass sie in
einem industriellen Produktionsprozess abgebildet werden konnte und damit die
„industrielle Revolution“ in der Softwareentwicklung einleiten (Planning the
Software Industrial Revolution, 1990). Diese idealistische Sichtweise entsprach
jedoch nicht der Realität (No Silver Bullet Revisted, 1995). Mit dem Aufsatz „No
Silver Bullet – Essence and Accident in Software-Engineering“ (No Silver Bullet:
Essence and Accidents of Software Engineering, 1987) prägt 1987 Frederick P.
Brooks 5 in der Informatik den Begriff „No Silver Bullet“. Er nutzt dabei zur
Beschreibung eines Softwareprojekts die Metapher eines Werwolfs. Werwölfe

4
Als Lösung für die Softwarekrise wurden strukturierte- und objektorientierte Programmierung, CASE, ADA,
Dokumentation von Quellcodes und die Nutzung von Standards angepriesen. Für die Qualitätssicherung von
Software wurde auf formale Methoden zurückgegriffen. Das Capability-Maturity-Model sollte den „Reifegrad“
der Software ermitteln. Programmierer wurden diszipliniert und galten nicht mehr als „Künstler“. Das
Programmieren entwickelte sich in dieser Zeit zu einem professionellen Ausbildungsberuf.
5
Mit dem Aufsatz „The Mythical Man-Month“ vertrat Brooks bereits 1974 die Kernthese „Adding manpower to
a late software project makes it later“ und bezeichnete es selbst als „Brook‟s Law“ (The Mythical Man-Month,
1974).
11

transformieren sich vom Bekannten zum Monster und lassen sich nur durch die
magische Silberkugel bändigen. Softwareprojekte sind Anfangs oft unschuldig,
überschaubar und werden von Projektbeteiligten wie ein kleines Kind verhätschelt.
Im fortgeschrittenen Stadium entwickelt es sich dann oft mit überzogenen Terminen,
hohen Projektkosten und schlechter Softwarequalität zum Monster für alle
Projektbeteiligten. Die Suche nach Technologien und Management-Techniken, um
dem entgegenzuwirken, vergleicht Brooks mit der Suche nach der magischen
Silberkugel. Brooks vernichtete mit dem Aufsatz nachhaltig die Hoffnung auf eine
Lösung für die Softwarekrise. Brooks begründete dabei seine These, indem er als
Erster die Schwierigkeit der Softwareerstellung in zwei Klassen unterteilt. Erstens
„essential difficulties“ – Schwierigkeiten, die der Natur von Software selbst
innewohnen – und zweitens „accidental difficulties“ mit der Art, die mit der Lösung
des Problems zu tun haben. Letzteres umfasst die Probleme mit der verwendeten
Programmiersprache, Methodik oder dem Entwicklungsprozess. Brooks geht davon
aus, dass in Zukunft Verbesserungen zu erwarten sind. Nicht zu lösen sind allerdings
die Probleme, die aus den Softwareeigenschaften entstehen. Brooks benennt hier als
Erster die vier wichtigsten: Komplexität, Konformität, Veränderlichkeit und
Unsichtbarkeit (Balzert, 2009 S. 9-10).

Fagan Structured Turbo Pascal Cleanroom


Inspections Programming (IDE) Engineering
Synchronize
Structured Structured and Stabilize
Formal
Analysis Design
Methods Visual
Rapid Prototyping Modeling
Waterfall
Model Spiral Model UML TSP
RUP
Jackson Method Hatley-Pirbhai
Ward-Mellor PSP
CPT
O-O Programming
CMM
Egoless Programming O-O Design
4GL
SADT/IDEF V-Model O-O Analysis Agile Methods

1970 1980 1990 2000


Art of Computer SEI
Pascal Programming Agile
Smalltalk CASE Tools
Manifesto
Mythical Man-Month

Abbildung 2: Proklamierte „Silver Bullets“ in der Informatik (Hoffmann, 2010)


12

Jede der proklamierten „Silver Bullets“ hat die Produktivität der


Softwareentwicklung in seiner Akkumulation gesteigert. Allerdings nur durch die
Reduzierung der „accidential difficulties“, erfolglos waren alle, sobald sie mit den
„essential difficulties“ in Berührung kamen. Jede Reduzierung der „accential
difficulties“ erschwert zusätzliche Verbesserungen durch neue Ansätze, weil zum
Schluss nur essentielle Probleme übrig bleiben und die Berührungspunkte mit ihnen
zur Verbesserung ausgeschlossen werden müssen (Berry, 2003 S. 3).

2.1.1.4 Die agile Bewegung


Der Softwarelebenszyklus 6 und das daraus abgeleitete Wasserfallmodell hatten im
Rahmen der „Industrialisierung“ starre Prozessmodelle hervorgebracht – mit
Fachdisziplinen, die einer strikten Rangordnung 7 unterlagen. Die Modelle hatten
bürokratische Strukturen und Prozesse, die sich oft mehr selbst dienten und nicht
mehr dem Entwickler, der das Ziel verfolgte, mit wenig Aufwand in einem
festgelegten Zeitrahmen nach Ingenieursprinzipien qualitativ ausreichende Software
herzustellen (Gloger, 2008 S. 19). In den Neunzigern veränderten sich die
Marktbedingungen für Software grundlegend. Das Internet und die Software für
multifunktionale Geräte8 waren zu dieser Zeit zwei schnell wachsende Anwendungs-
gebietet der Informatik (Balzert, 2009 S. 12). Die Fähigkeit, schnell auf
Kundenwünsche oder den Markt reagieren zu können, hatte dabei ein höheres
Gewicht als die Existenz einer ausführlichen Dokumentation. Zudem verkürzten sich
die Lebenszeit der Software und ihre Release-Zyklen dramatisch. Die traditionellen
Entwicklungsprozesse waren dafür zu schwerfällig. Entwickler waren gezwungen,
flexiblere Methoden zu finden (Ludewig, et al., 2010 S. 218-219).

Das Agile-Manifesto ist das Ergebnis von Methoden, die flexiblere Entwicklungs-
prozesse ermöglichen. Populär wurde unter Entwicklern die agile Software-

6
Urheber des Softwarelebenszyklus ist Rosove (Rosove, 1967), Royce (Royce, 1970 S. 1-9) hat den
Softwarelebenszyklus in Form des Wasserfallmodells populär gemacht.
7
Am untersten Ende standen die Tester, dann kamen die Entwickler, über ihnen standen Software-Architekten,
über ihnen die Systemsoftware-Architekten, usw.
8
Dies betrifft „embedded systems“ wie zum Beispiel Mobilfunktelefone oder andere moderne Systeme der
Unterhaltungselektronik.
13

entwicklung im Jahr 1999 durch Kent Becks Buch „Extreme Programming“ (Beck,
1999) und mündete in der „agilen Bewegung“. Ähnlich wie bei der Nato-Konferenz
1968 trafen sich im Jahr 2001 die 17 Pioniere9 dieser Bewegung in Snowbird, Utah,
um die Essenz der agilen Methoden in einem Manifesto festzuhalten. Der Begriff
„agile“ zur Beschreibung der Softwareentwicklungsmethodik wurde bei dem Treffen
ebenfalls geboren (Beck, et al., 2001), (Gloger, 2008 S. 21).

We are uncovering better ways of developing


software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools


Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on


the right, we value the items on the left more.

Abbildung 3: Manifesto for Agile Software Development (Beck, et al., 2001)

Das Manifest formuliert dabei absichtlich übergeordnet vier Werte und zwölf
Prinzipien (Beck, et al., 2001), an denen sich unterschiedliche
Entwicklungsmethoden orientieren, wie zum Beispiel XP, Scrum, DSDM, ASD,
Crystal, FDD und weitere (Hazzan, et al., 2008 S. 5). Das agile Manifesto
repräsentiert damit erstmals einen alternativen Ansatz zu den früheren
„tayloristischen“ Softwareentwicklungsprozessen (Ludewig, et al., 2010 S. 219).

2.1.2 Definitionen
Nachfolgend werden die Definitionen für Software-Engineering und Softwarequalität
betrachtet. Die Begriffe Software, Ingenieur und Qualität werden separat definiert,
weil beide Hauptbegriffe sich aus diesen zusammensetzen.

9
Autoren des agilen Manifesto: Mike Beedle, Ari Van Bennekum, Alistar Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert Martin,
Steve Mellor, Ken Schwaber, Jeff Sutherland und Dave Thomas.
14

2.1.2.1 Software
Software ist ein allgemeiner, neutraler und unbestimmter Begriff. Es ist umstritten,
was genau Software ist und wie weitreichend der Begriff Software eingesetzt werden
kann (Ludewig, et al., 2010 S. 34). In der Literatur werden einheitlich die folgenden
zwei Definitionen für „Software“ zitiert. Erstens: „Software: Menge von
Programmen oder Daten zusammen mit begleitenden Dokumenten, die für ihre
Anwendung notwendig oder hilfreich sind― (Hesse, et al., 1984 S. 204) und
zweitens: „Software: Computer programs, Procedures and possibly associated
documentation and data pertaining the operation of a computer system‖ (IEEE,
1990 S. 66). Die beiden Definitionen zeigen, dass Software mehr als nur ein
Computer-Programm umfassen kann und immer eine entsprechende Dokumentation
sowie Daten enthält. Das Computer-Programm an sich stellt dabei die kleinste
Einheit dar und wird von der IEEE gegenüber Software technisch abgrenzt:
„Computer Program: A combination of computer instructions and data definitions
that enable computer hardware to perform computational or control functions.‖
(IEEE, 1990 S. 19).

Im Zusammenhang mit „Software“ sollten auch die Begriffe „Software-Produkt“,


„Software-System“ und „System-Software“ betrachtet werden. „Ein Produkt ist ein
in sich abgeschlossens, i.a. für einen Auftraggeber bestimmtes Ereignis eines
erfolgreich durchgeführten Projekts oder Herstellungsprozesses.― Ein „Software-
Produkt“ ist demnach ein Produkt, das aus Software besteht (Balzert, 2009 S. 3-4).
Dumke definiert genauer: „Ein Software-Produkt ist die Gesamtheit von Software-
Komponenten (Programmen, Dokumentationen, usw.), die als Ganzes entwickelt,
vertrieben, angewendet und gewartet werden.― (Dumke, 2003 S. 4).

„Unter einem System wird ein Ausschnitt aus der realen oder gedanklichen Welt,
bestehend aus Gegenständen […] und darauf vorhandene Strukturen […]
verstanden. Systemteile, die nicht weiter zerlegbar sind oder zerlegt werden sollen,
werden als Systemelemente bezeichnet.― Ein „Software-System“ ist somit ein
System, dessen Systemkomponenten und Systemelemente aus Software bestehen.
Das „Software-Produkt“ betrachtet dabei Software von außen – zum Beispiel aus
Sicht eines Anwenders-, während das „Software-System“ die innere Sichtweise
15

darstellt – zum Beispiel aus Sicht eines Entwicklers. „System-Software“ ist


Software, die für eine bestimmte Hardware-/Familie entwickelt wurde, um den
Betrieb und die Wartung der Hardware zu ermöglichen oder zu vereinfachen.
„Anwendungs-Software“ setzt auf „System-Software“ auf und ermöglicht es dem
Anwender, Aufgaben mit dem „Computer-System“ zu lösen. Das „Computer-
System“ besteht dabei immer aus „Anwendungs-Software“, „System-Software“ und
Hardware (Balzert, 2009 S. 3-4).

2.1.2.2 Engineering und Ingenieur


Obwohl Software-Engineering in „Software-Technik“ übersetzt wurde, ist die
Tätigkeit des Ingenieurs stark damit verknüpft und bestimmt maßgeblich die
Grundbedeutung.

Ein Ingenieur befasst sich vorwiegend mit technischen Neuerungen oder


Innovationen im weitesten Sinn. Die Wortwurzel kommt aus dem lateinischen
„ingenium“ und bedeutet Scharfsinn, Erfindergeist. Eine aus Frankreich stammende
Definition lautet: „Der Ingenieur ist ein Mensch, der Ideen, Material und Menschen
einsetzt, um Produkte oder Projekte zu realisieren.― (Nagel, et al., 2009 S. 1). Dabei
müssen Produkte oder Projekte nicht unbedingt „neu“ sein. Ein Ingenieur ist
insgesamt darum bemüht, Verbesserung zum bestehenden Zustand zu erzielen und ist
dabei kreativ.

Beim Software-Engineering wird in der Literatur immer wieder von der


ingenieursmäßigen Softwareentwicklung nach „Ingenieurs-Prinzipien“ gesprochen.
Software-Engineering übernimmt dabei die folgenden fünf Merkmale der alten
Ingenieursdisziplinen: erstens Kostendenken als Grundlage von Bewertungen,
zweitens praktischer Erfolg als einzige zulässige Beweisführung, drittens
Qualitätsbewusstsein als Grundfarbe des Denkens, viertens die Einführung und
Beachtung von Normen und fünftens das Denken in Baugruppen (Ludewig, et al.,
2010 S. 33-34).
16

2.1.2.3 Software-Engineering
Eine allgemeingültige und vor allem einheitliche Definition des Begriffs Software-
Engineering existiert nicht. Alle Definitionen sind sich jedoch einig, dass es sich bei
Software-Engineering um eine Ingenieursdisziplin handelt, die explizit das
Künstlertum ausschließt. Software Engineering grenzt sich in seinen
Grundlagendisziplinen gegenüber anderen Wissenschaften wie Kerninformatik,
Ingenieurwissenschaften, Mathematik, Psychologie, Soziologie und Betriebs-
wirtschaft ab, indem es sich vor allem auf Methoden konzentriert mit dem Anspruch
der praktischen Anwendbarkeit. Dabei wird weder bei den Grundlagen- noch den
Anwendungsfeldern eine scharfe Abgrenzung gezogen und ist dadurch „inhärent
transdisziplinär“ (Broy, et al., 2006 S. 211).

Die einzelnen Definitionen entwickeln sich zeitlich betrachtet vom Allgemeinen hin
zur Beschreibung der einzelnen Verfahrensweisen in der Ingenieursdisziplin.
Friedrich L. Bauer beschreibt als Erster den Begriff „Software-Engineering“ auf der
Nato-Konferenz 1969 sehr allgemein, während Boehm ihn bereits 1976 aufgrund
seiner empirischen Untersuchung eher technisch und wissenschaftlich definiert:
„Software Engineering – the practical application of scientific knowledge in the
design and construction of computer programs and the associated documentation
required to develop, operate and maintain them.― (Pomberger, et al., 2004 S. 4).

Die IEEE definiert 1983 noch Software-Engineering im Rahmen eines Produktzyklus


als „the systematic approach to the development, operation, maintenance and
retirement of software“ und erweitert 1990 die Definition um messbare Größen und
versucht über die Tugend der Disziplin das Künstlertum auszugrenzen: „[…]
systematic, disciplined, quantifiable approach […]“. Hesse et al. charakterisieren
Software-Engineering 1984 in ihrer Definition als Teil der Informatik und
konkretisieren sie, indem sie mit der Verwendung von Entwicklungswerkzeugen und
deren methodischer Anwendung verknüpfen: „Software-Technik ist das Fachgebiet
der Informatik, das sich mit der Bereitstellung und systematischen Verwendung von
Methoden und Werkzeugen für die Herstellung und Anwendung von Software
beschäftigt.― (Hesse, et al., 1984 S. 204). Schulz definiert 1988 ähnlich wie Hesse
Software-Engineering, stellt es aber als Ingenieurswissenschaft dar, in der Software
17

unter industriellen Bedingungen hergestellt wird. Er betrachtet dabei zudem


expliziert die Menschen, die im Rahmen des Lebenszyklus mit ihr in Berührung
kommen, und wurde damit von Peter Molzberger (Molzberger, 1981) beinflusst.
„Software Engineering ist eine Ingenieurswissenschaft, die sich mit den Prinzipien,
Methoden, Werkzeugen und Menschen befasst, die Software unter industriellen
Bedingungen planen, entwickeln, anwenden und warten.― (Schulz, 1988 S. 14).

Die jüngste Definition von Balzert konzentriert sich wie Hesse et al. und Schulz auf
die einzelnen Verfahrensweisen, grenzt sich aber in bestimmten Punkten ab. Für ihn
sind wesentliche Charakteristika der Softwaretechnik, dass umfangreiche Software
arbeitsteilig und ingenieursmäßig entwickelt wird, um die Ziele der „Software-
Kunden“ zu erfüllen. Er schließt damit Programmierer aus, die Software einzeln
entwickeln und selbst anwenden. „Zielorientierte Bereitstellung und systematische
Verwendung von Prinzipien, Methoden und Werkzeuge für die arbeitsteilige,
ingenieursmäßige Entwicklung und Anwendung von umfangreichen
Softwaresystemen. Zielorientiert bedeutet die Berücksichtigung z.B. von Kosten, Zeit,
Qualität.― (Balzert, 2009 S. 17). Diese Abgrenzung führen auch Jalote (Jalote, 2005
S. 9-10), Van Vliet (Van Vliet, 2008 S. 6), Ludewig et al. (Ludewig, et al., 2010 S.
49-50) und weitere auf. Sommerville definiert es hingegen sehr allgemein aus der
Ingenieurssicht: „Software engineering is an engineering discipline which is
concerned with all aspects of software production.― (Sommerville, 2007 S. 7).

Die Definitionen treffen trotz ihrer Unterschiedlichkeit den Sachverhalt hinreichend


genau. Besonders hervorzuheben ist, dass insgesamt die jüngsten Definitionen einen
besonderen Augenmerk auf die Qualitätssicherung und das Projektmanagement
haben (Winter, 2005 S. 7).

2.1.2.4 Qualität
Für Qualität gibt es in der Literatur eine Vielzahl von unterschiedlichen Definitionen.
Qualität unterscheidet sich in ihrem Grad, je nachdem, wie Begrifflichkeiten von
Personen verstanden werden und unter welchem Blickwinkel Qualität betrachtet
wird. Garvin unterteilt Qualität in fünf verschiedene Sichtweisen: produktbezoge,
kundenbezoge, herstellerorientierte, absolute und wertorientierte Qualität (Garvin,
18

1984 S. 25 ff.). Erst durch die Verknüpfung dieser unterschiedlichen


Betrachtungswinkel kann Qualität durch Erfahrungen (transzendente Sichtweise)
erfasst werden (Gundlach, 2007 S. 3-4). Im umgangssprachlichen Verständnis wird
Qualität als Grad der Übereinstimmung zwischen den
Anforderungen/Ansprüchen/Erwartungen (Soll) an ein Produkt und dessen
Eigenschaften/Merkmale (Ist) gesehen. Mit der ISO-Normfamilie hat man sich
international auf eine Definition geeinigt, die allerdings immer wieder anhand der
praktischen Erfahrung mehr oder weniger stark verändert wurde. In der Literatur
findet man deshalb oft noch die alte DIN EN ISO 8402:1995-08-Norm „Qualität ist
die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer
Dienstleistung, die sich auf deren Eignung zur Erfüllung festgelegter oder
vorausgesetzter Erfordernisse beziehen.― Diese wurde jedoch von der kompakteren
EN ISO 9000:2005 abgelöst und definiert international im Status quo Qualität:
„Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt.― Die Definition
EN ISO 9000:2005 betrachtet damit Qualität nicht isoliert, sondern die Gesamtheit
der „inhärenten Merkmale“ und deren Zusammenwirken als Ganzes, um
Anforderungen (transzendente Sichtweise) zu erfüllen.

2.1.2.5 Softwarequalität
Im Gegensatz zum allgemeinen Qualitätsbegriff ist Softwarequalität eindeutig in der
DIN-ISO-9126-Norm definiert: „Software-Qualität ist die Gesamtheit der Merkmale
und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen,
festgelegte Erfordernisse zu erfüllen.― Die Definition bezieht sich ausschließlich auf
die Produktqualität (obwohl in der DIN-ISO-9126-Norm zwischen interner, externer
und Benutzungsqualität unterschieden wird). Zudem ist Software-Qualität eine
multikausale Größe, in der es nicht nur das eine Kriterium gibt, mit dem sich
Softwarequalität qualitativ und quantitativ messen lässt. Der Begriff Softwarequalität
ist in der Praxis deshalb auch nicht direkt anwendbar (Balzert, 1998 S. 257). In der
Praxis wird Softwarequalität mit Modellen festgestellt, die durch Qualitätsmerkmale
operationalisiert werden. Diese Merkmale sind in der DIN-ISO-9126-Norm ebenfalls
als Standard definiert. Sie werden in interne sowie externe unterschieden und dabei
in sechs Charakteristika aufgeteilt. Sie können durch ihre Allgemeingültigkeit jedem
19

Softwareprodukt zugeordnet werden und lauten: Funktionalität, Zuverlässigkeit,


Benutzbarkeit, Effizienz, Änderbarkeit sowie Portabilität. Diese werden dann jeweils
noch in weitere Merkmale operationalisiert. Zusätzlich wird die Benutzungsqualität
als Charakteristik separat aufgeführt. Diese wird in Effizienz, Produktivität,
Sicherheit und Satisfaction operationalisiert (Liggesmeyer, 2009 S. 16-17).
Qualitätsmerkmale können nicht alle gleichzeitig gut in einem Produkt vorhanden
sein, weil sie unter Umständen negativ zueinander korrelieren (Hoffmann, 2008 S.
10-11).

2.1.3 Ziele
Die Ziele des Software-Engineerings werden in der Literatur aus der Definition des
Software-Engineerings hergeleitet. Wie bei den Definitionen gibt es auch hier
unterschiedliche Ansätze. Insgesamt kann aber festgestellt werden, dass alle bei der
Entwicklung von Software als Primärziel die Erfüllung der wirtschaftlichen Ziele
entweder im Rahmen des magischen Projektmanagementdreiecks (Qualität, Termine,
Kosten) (Keßler, et al., 2004 S. 55) oder dem Teufelsquadrat von Sneed (Qualität,
Umfang, Dauer, Kosten) (Sneed, 2005 S. 38) als vorrangigen Zweck sehen und nicht
die Entwicklung selbst. 10 Als Sekundärziel wird das Finden von geeigneten
Prinzipien, Methoden und Werkzeugen zur Erreichung des Primärziels gesehen
(Hesse, et al., 1992 S. 22).

2.1.4 Eigenschaften von Software


Software besitzt besondere Eigenschaften und unterscheidet sich fundamental von
anderen technischen Produkten (Balzert, 2009 S. 9). Die Eigenschaften von Software
stellen bis heute nach Brooks als „essential difficulties“ ein ungelöstes Problem der
Softwareindustrie dar und haben damit einen enormen Einfluss auf das Software-
Engineering. In der Literatur werden diese in unterschiedlicher Ausprägung mit
verschiedenen Merkmalen aufgeführt und oft mit den Charakteristika des Software-
Engineerings gleichgesetzt oder vermischt.

10
Balzert hat in seiner Definition von Software-Engineering explizit das magische Projektmanagement Dreieck
mit aufgenommen.
20

Erstens: Software ist immateriell digital. Brooks spricht hier auch von
Unsichtbarkeit. Man kann sie nicht „anfassen“ oder „sehen“ und sie wird nicht
gefertigt, sondern entwickelt sich aus diskreter Mathematik und Logik. Deshalb ist
der Entwicklungsfortschritt auch nicht objektiv messbar (Balzert, 2009 S. 9).
Zweitens: Software ist jederzeit veränderbar. Im Gegensatz zu physischen
Produkten kann Software unmittelbar verändert oder verformt und jederzeit aus den
Sourcen neu generiert werden (Winter, 2005 S. 8), (Balzert, 2009 S. 10). Deshalb
wird auch erwartet, dass Software einfach und schnell an Veränderungen angepasst
werden kann. Drittens: Software unterliegt keinem Verschleiß. Anders als bei
technischen Produkten kann Software beliebig oft genutzt werden, ohne dass ein
Verschleiß auftritt. Wartung von Software aufgrund von Abnutzungserscheinungen,
wie beim zum Beispiel beim Auto, ist nicht nötig. Für Software gibt es deshalb auch
keine Ersatzteile. Viertens: Software spiegelt die Realität wider. Software ist ein
Abbild der Arbeitsprozesse in der sie eingesetzt wird und verändert diese. Ändern
sich Arbeitsprozesse, muss die Software an diese angepasst werden. (Winter, 2005 S.
9), (Ludewig, et al., 2010 S. 38-39) Brooks spricht hier auch von Konformität. Bei
Einsatz von großer Standardsoftware werden unter Umständen die
Unternehmensprozesse auch an die Software angepasst (Balzert, 2009 S. 14).
Fünftens: Große Software hat eine lange Lebensdauer. Der Lebenszyklus von
Softwaresystemen geht oft über den der Ursprungshardware hinaus und muss damit
über Generationen an die veränderte Realität angepasst werden. Grund ist, dass
Softwarekosten über einen langen Zeitraum amortisiert werden müssen. Die
Anpassungen von Software führen zur Versionierung (Winter, 2005 S. 9), (Balzert,
2009 S. 14). Nach Balzert kann Software deshalb altern (Balzert, 2009 S. 9).
Sechstens: Software ist komplex. Software gehört zu den komplexesten Artefakten,
die Menschen bisher geschaffen haben. Software ist ein Abbild von vielen
Denkmodellen und besteht aus einer Vielzahl von Dokumenten, darunter auch
Quellcode (Ludewig, et al., 2010 S. 37). Quellcode kann einen enormen Umfang
annehmen, dieser reicht bei kleineren Projekten mit 10 KLOC bis zu sehr großen
Projekten mit mehreren 1000 KLOC (Jalote, 2008 S. 6). Siebtens: Software ist
schwer zu vermessen. Aufgrund der Komplexität und Unsichtbarkeit kann der
21

Fortschritt und die Größe von Software nur bedingt gemessen werden. Dies betrifft
auch die Messung der Softwarequalität (Balzert, 2009 S. 10).

2.1.5 Charakteristika des Wirkungskontextes


Die Erklärung, was Software-Engineering ist, erfolgt in der Literatur unabhängig von
der Definition sehr praktisch in seinem Wirkungskontext. Hierbei gibt es
verschiedene Herangehensweisen, um die Charakteristika von Software-Engineering
zu beschreiben: Balzert „Warum ist Software so schwer zu entwickeln?“ (Balzert,
2009 S. 11-15), Ludewig et al. „Grundideen des Software-Engineering (Ludewig, et
al., 2010 S. 47-55), Jalote „The Problem Domain“ (Jalote, 2005 S. 2-15), Pfleeger et
al. „What is Software-Engineerig“ (Pfleeger, et al., 2010 S. 14-39) und Van Vliet
leitet es ein mit „Essentials characteristics of the field“ (Van Vliet, 2008 S. 6-8). Alle
zeigen dabei im Grunde die gleichen Charakteristika des Umfelds auf, in dem sich
Software-Engineering bewegt. Die nachfolgenden acht Charakteristika orientieren
sich an Van Vliets Darstellung.

Erstens: Software-Engineering betrachtet die Entwicklung von großen Programmen.


In der Literatur wird generell in „Programming-in-the-large“ und „Programming-in-
the-small“ unterschieden (Programming-in-the-large versus programming-in-the-
small, 1975). Die Bestimmung der Grenze erfolgt hierbei nicht ausschließlich anhand
der LOC, sondern daran, wie viele Personen auf einem Projekt arbeiten und wie
lange die Projektdauer angesetzt ist. „Programming-in-the-small“ umfasst eine
Person, die in kurzer Zeit ein Programm entwickelt. Jalote spricht hier auch von
einem „Student System“. „Programming-in-the-large“ umfasst mehrere Personen
über einen größeren Zeitraum. Jalote spricht hier auch von dem „Industrial Strength
Software System“ (Balzert, 2009 S. 11-12), (Van Vliet, 2008 S. 6), (Jalote, 2005 S.
2-3 & 9-10), (Ludewig, et al., 2010 S. 49-51). Die These, warum Software-
Engineering in diesen Projekten essentiell ist, wird mit dem „Problem of Scale“
(Jalote, 2005 S. 10) begründet: Je größer und komplexer ein Softwareprojekt ist,
desto formaler müssen Projektmanagement und Entwicklungsmethoden sein.
Zweitens: Die Herausforderung liegt im Management von umfangreicher Software,
die eine hohe Komplexität im Detail aufweist. Softwareprojekte müssen in
Teilprojekte/Komponenten und in Projektphasen unterteilt werden. Die Aufteilung
22

soll bei den Projektbeteiligten erstens ein Verständnis für die Komplexität der
Software schaffen, zweitens den Umfang transparent machen und drittens
Projektziele festlegen. Die Komplexität kann dabei in Funktionen, Daten,
Algorithmen, zeitabhängiges Verhalten, Systemumgebung und Benutzeroberfläche
unterteilt werden (Balzert, 2009 S. 6-7). Die Aufgabe des Software-Engineerings ist
es dabei, die Komplexität des Details zu verwalten (Pfleeger, et al., 2010 S. 2-4),
(Ludewig, et al., 2010 S. 50), (Ludewig, et al., 2010 S. 6-7), (Jalote, 2005 S. 13).
Drittens: Software muss durch die permanente Veränderung ihrer Einsatzumgebung
ständig angepasst werden. Diese Eigenschaft von Software verursacht enorme
Kosten11. Die Veränderbarkeit muss deshalb durch das Software-Engineering bereits
bei der Entwicklung mit berücksichtigen werden (Balzert, 2009 S. 14), (Jalote, 2005
S. 6-7,15), (Van Vliet, 2008 S. 7), (Pfleeger, et al., 2010 S. 28-30). In diesem
Zusammenhang stellt Balzert fest: „die Softwareprodukte von heute sind die
Altlasten von morgen“ (Balzert, 2009 S. 14). Viertens: Software effizient zu
entwickeln besitzt eine enorme Relevanz. Die Kosten und der Zeitraum für die
Entwicklung und Pflege von Software sind sehr hoch. Im Kontrast dazu steht, dass
Time-to-Market in der Technologiebranche essentiell ist. Die Konsequenz sind kurze
Release-Zyklen. Software-Engineering muss deshalb permanent neue Prinzipien,
Methoden und Werkzeuge für die Entwicklung und Pflege von Software schaffen
und alte optimieren sowie auf die hohe Wiederverwendbarkeit von
Softwarekomponenten achten (Van Vliet, 2008 S. 7). Ludewig et al. sprechen
deshalb auch davon, „Software Engineering als globale Optimierung“ in einem
Softwareprojekt einzusetzen (Ludewig, et al., 2010 S. 51). Fünftens: Kooperatives
Arbeiten innerhalb von Teams ist integraler Bestandteil bei der Entwicklung von
umfangreicher und komplexer Software. Große Softwareprojekte werden immer in
Teamarbeit realisiert. Die einzelnen Personen des Teams arbeiten dabei oft nicht am
gleichen Ort. Software-Engineering definiert in den Softwareentwicklungsteams
Standardabläufe für das gemeinsame Arbeiten und fordert dabei die nötige Disziplin
ein. Neben den informellen Regeln werden hierzu auch Werkzeuge für das
kollaborative Arbeiten, wie zum Beispiel Bugtracker, vorgeschrieben (Van Vliet,
2008 S. 7). Sechstens: Software muss den Benutzer bei seiner Arbeit unterstützen.

11
Zwei Drittel der Softwarekosten entstehen nach Balzert durch nachträgliche Anpassung (Balzert, 2009 S. 14).
23

Software soll Benutzer bei der Arbeit entlasten. Dementsprechend müssen die zu
lösenden Aufgabenbereiche als Funktionalität in der Software bereitgestellt werden.
Software-Engineering soll dabei nicht nur das System richtig entwickeln, sondern
dem Benutzer das richtige System bereitstellen (Van Vliet, 2008 S. 7). Siebtens:
Software-Engineering ist ein Akt der Balance. Ein Softwareprojekt wird von internen
und externen Faktoren beeinflusst. Diese können Anforderungskataloge, Funktionen
oder das technische Fundament einer Software stark oder komplett verändern, so
dass eine erneute Iteration notwendig wird. Die Einflüsse können geschäftlicher,
politischer oder technischer Natur sein (Van Vliet, 2008 S. 8), (Jalote, 2005 S. 7).
Achtens: Die Qualität der Software ist der Motor für den Erfolg. Aufgrund der
Diskrepanz zwischen Sichtbarkeit und Fortschritt von Software, existiert in der
Softwareentwicklung das „90 % Syndrom“. Die letzten 10 % beeinflussen die
Qualität der Software maßgeblich und erfordern ein hohes Maß an Disziplin und
Ressourcen. Die Aufgabe von Software-Engineering ist es, diese Diskrepanz im
Projekt korrekt darzustellen und kontinuierliche Qualität der Software sicherzustellen
(Van Vliet, 2008 S. 9), (Balzert, 1999 S. 12), (Ludewig, et al., 2010 S. 50), (Jalote,
2005 S. 12-13).

2.1.6 Wissensgebiete des Software-Engineerings


Software-Engineering ist eine sehr facettenreiche Disziplin und umfasst eine
Vielzahl von Teilgebieten innerhalb und außerhalb der Informatik. Balzert ordnet
zum Beispiel Software-Engineering innerhalb der Kerninformatik der praktischen
Informatik zu und unterteilt es dort aus dem Blickwinkel der Informatik in die drei
übergeordneten Teilbereiche Softwareentwicklung, Softwaremanagement und
Softwarequalitätsmanagement.
24

Kerninformatik

Theoretische Praktische Technische


Informatik Informatik Informatik

Software
Engineering

Softwarequalitäts-
Softwareentwicklung Softwaremanagement
management

Abbildung 4: Software-Engineering innerhalb der Informatik (Balzert, 2009 S. 18)

Van Vliet trennt wiederum die Informatik vom Software-Engineering. Die


Abgrenzung erfolgt, indem er Software-Engineering inhaltlich dem Management
zuordnet und die Informatik der Softwareentwicklung, mit der Begründung:
„Software engineers must engineer software.― (Van Vliet, 2008 S. 10). Eine
unabhängige Sichtweise auf Software-Engineering versucht das SWEBOK, das aus
einer Initiative der IEEE und ACM entstanden ist. Im Gegensatz zu anderen oft
zitierten, umfangreichen Standardwerken in dieser Arbeit versucht es die
Teilbereiche des Software Engineerings in Wissensgebiete zu gliedern. Ziel ist dabei,
ein strukturiertes, einheitliches und umfassendes Gesamtwerk zu schaffen, das eine
Synthese von generell akzeptierten Erkenntnissen aufzeigt und referenziert. Das
SWEBOK dient damit als Rahmenwerk für einen Gesamtüberblick aller Themen, die
das Software-Engineering betrifft. Das SWEBOK umfasst insgesamt elf
Wissensgebiete. Die ersten zehn behandeln Software-Engineering, das letzte führt
verwandte Themengebiete auf (IEEE, 2004).

Erstens: Anforderungsanalyse befasst sich mit der Erarbeitung, Analyse,


Spezifikation und Verwaltung von Anforderungen an Software. Zweitens: Entwurf
ist der Prozess, bei dem die Anforderungen an die Software (was?) in eine
Beschreibung der Problemlösungsstrategie (wie?) transformiert wird. Drittens:
Realisierung befasst sich mit der Entwicklung des Programms. Das Ergebnis dieses
Prozesses ist die lauffähige Software. Viertens: Testen verifiziert, ob die entwickelte
Software tatsächlich das Problem löst. Die Software ist fehlerfrei, wenn das
Widerlegen der Fehlerfreiheit fehlgeschlagen ist. Fünftens: Wartung befasst sich mit
25

der Aufrechterhalten und Pflege des Betriebs von Software. Sechstens:


Konfigurationsmangement betrachtet die Menge aktuell installierter und im
laufenden Betrieb befindlicher Software- und Systemkomponenten und soll die
Integrität eines Softwaresystems über den gesamten Lebenszyklus der Software
wahren. Siebtens: Projektmanagement befasst sich mit Planung, Durchführung und
Bewertung von Softwareentwicklungsprozessen. Achtens: Vorgehensmodell
betrachtet die Definition, Implementation, Bewertung, das Management und die
Verbesserung von Softwareprozessen. Neuntens: Entwicklungswerkzeuge und
Methoden vereinigen streng genommen zwei Wissengebiete in sich: Werkzeuge und
Methoden. Werkzeuge befassen sich mit dem Design und Einsatz dieser für
Softwareentwicklungsprozesse. Methoden mit der Vorgehensweise in den Prozessen.
Zehntens: Software Qualität betrachtet nicht die Techniken des Testens, sondern den
Prozess des Testens und die allgemeine Softwarequalitätssicherung. Elftens:
Themengebiete, die mit Software-Engineering korrelieren. Darunter fallen:
technische Informatik, Informatik, Unternehmensführung, Mathematik,
Projektmanagement, Qualitätsmanagement, Softwareergonomie und System-
Ingenieurswesen (Calamé, 2003 S. 5-6).

2.1.7 Kritische Würdigung


Bei der Betrachtung der Grundlagen ist erschreckend, wie viele der elementaren
Fragen innerhalb des Software-Engineerings noch unbeantwortet sind. Verstärkt wird
dies durch Glaubensrichtungen innerhalb der Literatur, die Denkansätze
proklamieren und dadurch starken Einfluss auf die Softwareentwicklung haben. So
sind bis heute viele Methoden auf Basis der „Industriellen Revolution“ mit dem
Glauben an die ingenieursmäßige Entwicklung von Software entstanden. Aber ist
Software-Engineering eine Ingenieurswissenschaft? Wie wir wissen, ist Software-
Engineering aus einer Provokation heraus entstanden, Softwareentwicklung mit dem
positiven Begriff des Ingenieurs zu besetzten und sich von der „Kunst des
Programmierens“ abzuwenden. Alistair Cockburn bezweifelt, dass die Analogie des
Ingenieurs richtig gewählt wurde, und stellt damit das Ideal der ingenieursmäßigen
Softwareentwicklung in Frage (Cockburn, 2004). Trotzdem hat sich Software-
Engineering zu einer „Wissenschaft“ entwickelt – aufgrund der empirischen
26

Untersuchungen 12 , der daraus abgeleiteten Prinzipien, Methoden und Werkzeuge


(Balzert, 2009 S. 17) sowie einer festen Terminologie 13 (Balzert, 2009 S. 20-22).
Allerdings werden bis heute „Kunst“ und „Handwerk“ zur Beschreibung der
Profession in der Literatur nach wie vor gleichermaßen benutzt (Pfleeger, et al., 2010
S. Xiii, 21).

Werkstatt (technisches Produkt) Atelier (Kunstwerk)

1 Geistige Das vorhandene und verfügbare Ist unter anderem die Inspiration des
Voraussetzung technische Knowhow Künsters

2 Termine Sind in der Regel mit genügender Sind wegen der Abhängigkeit von
Genauigkeit planbar Inspiration nicht planbar

3 Preis Ist an den Kosten orientiert und Ist nur durch den Marktwert, nicht
darum kalkulierbar durch die Kosten bestimmt

4 Normen und Existieren, sind bekannt und Sind rar und werden, wenn sie
Standards werden in aller Regel respektiert bekannt sind, nicht respektiert

5 Bewertung, Kann nach objektiven, Ist nur subjektiv möglich, das


Vergleich quantifizierten Kriterien Ergebnis ist umstritten
durchgeführt werden

6 Urheber Bleibt meist anonym, hat keine Betrachtet das Kunstwerk als Teil
emotionale Bindung zum Produkt seiner selbst

7 Gewährleistung Sind klar geregelt, können nicht Sind undefiniert und praktisch kaum
und Haftung ausgeschlossen werden durchsetzbar

Tabelle 1: Gegenüberstellung von Werkstatt und Atelier (Ludewig, et al., 2010 S. 48)

Betrachtet man die Gegenüberstellung von Werkstatt (Handwerk) und Atelier


(Kunst) (Ludewig, et al. S. 48), wird klar, dass die Trennung ein Wunschdenken ist.
Unverständlich ist, warum Software-Engineering dies sich nicht eingesteht und diese
Ambivalenz bzw. den dualen Charakter (Dumke, 2003 S. 11) einfach akzeptiert.
Denn bis heute werden Termine und Kosten für ein Softwareprojekt geschätzt und
im laufenden Projekt überschritten (The Standish Group, 1995), (Winter, 2005 S. 5).
Regeln sind existent/bekannt, werden aber nach wie vor in der Masse von
Programmierern ignoriert, genauso wie die Einhaltung von Normen. Programmtest

12
Die Sammlung empirischer Daten beginnt mit „Software and its impact: a quantitative assessment“ ,1973.
13
Dies betrifft die Begriffssammlung des Arbeitskreises der Gesellschaft für Informatik und das IEEE Standard
Glossary of Software Engineering Terminology.
27

liefern begrenzte Aussagen über die Funktionalität und andere Eigenschaften von
Software können nur subjektiv bewertet werden. Für die Vergleichbarkeit von
Software gibt es kaum Kriterien. Programmierer bauen trotz des Anspruchs des
„Egoless Programming“ (Weinberg, 1971) ihre Persönlichkeit in die Software ein
(auch wenn Normen eingehalten werden), die dadurch für andere Menschen
unverständlich wird. Kritik an ihrem „Werk“ können Programmierer selten ertragen.
Die Verantwortung für die Qualität der Produkte wollen Programmierer sowie
Firmen nicht übernehmen, obwohl sie es mittlerweile gesetzlich müssen. In der
Praxis hat sich das Leitbild des Ingenieurs deshalb faktisch nicht durchgesetzt, weil
der damit verbundene Anspruch von Balzert – „Ingenieurmäßig bedeutet hier auch
kein Künstlertum“ (Balzert, 2009 S. 17) – bisher nicht eingelöst wurde (Ludewig, et
al., 2010 S. 47-48). Beim Studium der Literatur irritiert besonders, dass
fundamentale Probleme, die über Jahrzehnte bekannt sind, nicht gelöst werden. Das
beste Beispiel ist hier Brooks „konstante“ Gesetzmäßigkeit der „No Silver Bullet“.
Die agile Bewegung versucht erstmals beide Seiten der „essencial und accidential
difficultes“ zu betrachten und verlässt damit als Erste ernsthaft und konsequent den
Weg der „industriellen Revolution“ (Van Vliet, 2008 S. 27).

2.2 Vorgehensmodelle und Prozessmodelle


Die methodische Auseinandersetzung mit dem Softwareherstellungsprozess ist seit
Beginn des Software-Engineerings das Kernstück. In den frühen Zeiten wurde die
Beschäftigung mit den Modellen und Prozessen sogar dem Software-Engineering
gleichgesetzt (Hesse, et al., 1992 S. 28). Nach Jalote sind drei Faktoren relevant, um
qualitativ hochwertige Software produktiv zu entwickeln: Menschen, Prozesse und
Technologie (Werkzeuge). Menschen entwickeln und liefern die Software ab.
Prozesse sollen den Menschen helfen, welche Aufgaben sie zu erledigen haben und
in welcher Reihenfolge. Technologie (Werkzeuge) soll Arbeitsschritte effizienter
gestalten und Fehler reduzieren. Das größte Potenzial liegt nach Jalote in der
Optimierung der Prozesse. Deshalb konzentriert sich Software-Engineering im
Gegensatz zu anderen Disziplinen der Informatik nicht auf Verbesserungen der
Produktbestandteile, sondern auf das systematische Vorgehen innerhalb des
28

Prozesses, um qualitativ hochwertige Software produktiv zu produzieren (Jalote,


2008 S. 9-10) .

2.2.1 Abgrenzung der Begriffe: Vorgehen, Prozess, Projekt


In der Literatur verwenden die meisten Autoren die Begriffe wie Vorgehensmodell
oder Prozessmodell als Synonyme. Ludewig et al. entzerren die Begriffe und grenzen
damit bewusst das Vorgehensmodell vom Prozessmodell (Hesse, et al., 1992 S. 46,
69-70) ab.

Betrachtet man das IEEE Standard Glossary of Software Engineering Terminology,


findet man folgende zwei Definitionen: Erstens, „process. (1) A sequence of steps
performed for a given purpose; for example, the software development process.
[…]― (IEEE, 1990 S. 57) und zweitens „software development process. The process
by which user needs are translated into a software product. The process involves
translating user needs into software requirements, transforming the software
requirements into design, implementing the design in code, testing the code, and
sometimes, installing and checking out the software for operational use. Note: These
activities may overlap or be performed iteratively.― (IEEE, 1990 S. 67)

Ein Prozess ist auf Basis beider Begriffsdefinitionen erstes die konkrete Abfolge von
Schritten, die ein konkretes Ergebnis haben. Man kann hier auch von einem Projekt
sprechen. Zweitens eine abstrakte Folge von Schritten, die beliebig vielen Projekten
zu Grunde liegen kann und als Muster beziehungsweise Modell dient.

Ein Prozess schließt demnach mehr Aspekte ein als das Vorgehen innerhalb eines
Projekts. Der Kern des Prozessmodells bildet immer ein Vorgehensmodell. Darüber
hinaus beinhalten Prozessmodelle im Gegensatz zum Vorgehensmodell auch
Organisationsstrukturen, Vorgaben für das Projektmanagement, Qualitätssicherung,
Dokumentation, Konfigurationsverwaltung, Werkzeuge, Notationen und Sprachen
(Ludewig, et al., 2010 S. 182). Historisch gesehen trifft die Unterscheidung ebenfalls
zu. In den siebzigern und frühen achtziger Jahren des letzten Jahrhunderts sind erst
die Vorgehensmodelle entstanden. Danach wurden innerhalb der Vorgehensmodelle
die Prozesse verbessert, woraus Prozessmodelle wie zum Beispiel der Unified
29

Process oder auch Extreme Programming entstanden sind (Ludewig, et al., 2010 S.
89-92).

2.2.2 Ausgewählte Vorgehensmodelle


Die ausgewählten Vorgehensmodelle erfolgen erst aus der historischen Sicht mit
„Code and Fix“, dem „Software Life Cycle“ und dem daraus abgeleiteten
Wasserfallmodell. Das Rapid Prototyping als Modell überführt anschließend in nicht
lineare Vorgehensmodelle mit der evolutionären, iterativen und inkrementellen
Softwareentwicklung. Das Spiralmodell als Weiterentwicklung des
Wasserfallmodells bildet den Schluss. Nicht berücksichtigt wurde das V-Modell als
Vorgehensmodell. Es wird zwar oft als solches bezeichnet, ist jedoch aufgrund der
Integration von projektbegleitender Tätigkeiten ein Prozessmodell. Die Darstellung
der Modelle beschränkt sich auf die wesentlichen Kernaussagen, da sie in der
Literatur sehr ausführlich dargestellt werden.

2.2.2.1 Code and Fix


Bei dem Vorgehensmodell „Code and Fix“ oder auch „Build and Fix“ wird ohne
Analyse, Spezifikation und ohne Entwurf Programmcode direkt vom Entwickler
implementiert, getestet und korrigiert, bis das System den Vorstellungen des
Entwicklers entspricht.

Die Vorteile des Modells sind, dass erstens Probleme relativ schnell gelöst werden
können und zweitens in kurzer Zeit ein lauffähiges Programm entsteht. Die
Nachteile sind, dass erstens das Projekt nicht planbar ist, zweitens Arbeit nicht auf
mehrere Personen verteilt werden kann, drittens die Soll-Anforderungen fehlen und
damit das Programm nicht geprüft werden kann, viertens Programme nur durch den
Entwickler gewartet werden können, fünftens wichtige Konzepte und
Entscheidungen nicht dokumentiert sind und deshalb nicht transferiert werden
können, sechstens der Aufwand für Korrekturen erst im Einsatz entdeckt und
korrigiert werden können.

Obwohl das Modell in den 1960er Jahren dazu geführt hat, dass Software-
Engineering entstanden ist, wird es bis heute vielerorts angewendet – und besitzt in
30

Managementkreisen eine hohe Beliebtheit, um schnelle Ergebnisse zu erhalten. Es


wird allerdings in der professionellen Softwareentwicklung strikt abgelehnt
(Ludewig, et al., 2010 S. 153-154).

2.2.2.2 Software Life Cycle


Jede Software durchlebt als Produkt verschiedene Stadien. Als Softwarelebenszyklus
wird der Prozess mit alle Phasen und Stadien von der Entwicklung, Einführung,
Wartung bis zur Ablösung oder Auslaufen eines Softwareprodukts verstanden.
(Dumke, 2003 S. 18-19) Das Modell des Lebenszyklus ist universell und wird in der
Literatur oft variiert durch überlappende Phasen, Meilensteine oder Iterationen
(Winter, 2005 S. 27). Als Urheber des Modells des Softwarelebenszyklus gilt Rosove
(Rosove, 1967 S. 67-93). Den Softwarelebenszyklus hat später Royce mit seinem
Wasserfallmodell populär gemacht. Der Softwarelebenszyklus war neben dem „Code
and Fix“ das erste Modell, das die Sichtweise in der Softwareentwicklung nach der
Softwarekrise maßgeblich veränderte.

Der Softwarelebenszyklus beschreibt acht Phasen, die eine Software durchlaufen


kann, und umfasst erstens Analyse (concept phasen), zweitens Spezifikation der
Anfordeung (requirements phase), drittens Entwurf (design phase), viertens
Implementierung (implementation phase), fünftens Test (test phase), sechstens
Integration und Abnahme (installation and test phase), siebtens Betrieb und Wartung
(operation and maintaince phase) und achtens Auslaufphase (retirement phase)
(IEEE, 1990 S. 68).

Der Zeitaufwand innerhalb des Lebenszyklus bis zur Fertigstellung (ohne Integration
und Abnahmen) einer Software unterliegt den sog. 40-20-40 Regeln. Nur 20 % der
Zeit wird mit der Implementierung (Programmierung) des Systems verbracht,
während 40 % für Analyse, Spezifikation und Entwurf und die restlichen 40 % für
das Testen verbraucht werden. Erfolgreiche Projekte unterliegen gemäß Boehm einer
60-15-25 Regel: 60 % Analyse, Spezifikation und Entwurf, 15 % Implementierung
und 25 % Testen. Der Betrieb und die Wartung nehmen 50-75 % der gesamten
Softwarekosten ein (Van Vliet, 2008 S. 14-15).
31

2.2.2.3 Wasserfallmodell
Das Wasserfallmodell wird auch als sequenzielles oder lineares Modell bezeichnet
(Dumke, 2003 S. 112). Es basiert auf dem Softwarelebenszyklus, wobei es die
Auslaufphase nicht betrachtet. Das Modell unterteilt die Tätigkeiten der
Softwareentwicklung in klar abgegrenzte, aufeinander folgende Aktivitäten. Jede
dieser Aktivitäten produziert ein Ergebnis oder mehrere Teilergebnisse in Form von
Dokumenten (Ludewig, et al., 2010 S. 156-157). Van Vliet bezeichnet es deshalb
auch als „dokumentengetriebenes“ oder „planungsbetriebenes“, schwergewichtiges
Modell (Van Vliet, 2008 S. 46-47). Damit das Ende jeder Aktivität und der Anfang
der nächsten identifiziert werden können, muss eine Überprüfung der Dokumente
erfolgen und wird als „Verification und Validation“ bezeichnet. Dieses Vorgehen
soll sicherstellen, dass der Output der Aktivität erstens mit dem Input aus der
vorherigen Aktivität übereinstimmt und zweitens mit den allgemeinen
Anforderungen übereinstimmt. Stimmen diese nicht überein, gilt die Aktivität als
nicht abgeschlossen, bis die Anforderungen erfüllt sind (Jalote, 2008 S. 14-15). Diese
Zyklen, die einen Rücksprung in vorherige Aktivitäten erlauben (Wirbel), erzeugen
das Bild eines Wasserfalls. Rücksprünge in weiter zurückliegende Aktivitäten sind
nicht vorgesehen. In der Literatur gibt es Darstellungen des Modells, bei denen bei
einer Fehlerfindung nicht in eine frühere Aktivität zurückgekehrt werden darf, wenn
die nächste bereits gestartet wurde. Diese Sichtweise bezieht sich auf das strenge
Wasserfallmodell oder auch Einbahnstraßenmodell, welches das Projektmanagement
Ende der 1970er Jahre prägte (Ludewig, et al., 2010 S. 159-160).

Die größten Kritikpunkte am Wasserfallmodell sind, dass erstens davon


ausgegangen wird, dass die Anforderungen des Kunden bereits beim Start vorhanden
sind und sich im laufenden Projekt nicht mehr ändern werden. Damit geht das
Modell von einer vollständigen und fehlerfreien Anforderungsspezifikation in der
ersten Aktivität aus. Zweitens: Benutzer und Stakeholder werden dazu ermutigt, in
der Spezifikation so viele Funktionen wie möglich anzufordern, weil diese
nachträglich nicht mehr änderbar sind. Drittens: Ein lauffähiges System wird erst am
Ende des Projekts geliefert (sog. „Big Bang“ oder auch „all or nothing approach“).
Der Auftraggeber bekommt damit erst am Schluss ein lauffähiges System. Viertens:
Bei Überschreiten der Projektdauer wird das Testen verkürzt und bewusst fehlerhafte
32

Software in Betrieb genommen. Die Fehlerbeseitigung erfolgt anschließend in der


Wartung.

2.2.2.4 Prototyping/Rapid Protoyping


Das Prototyping ist aus dem wesentlichen Kritikpunkt des Wasserfallmodells
entstanden. Die Grundidee ist dabei, die Anforderungen anhand eines lauffähigen
Prototyps zu evaluieren, der anschließend verworfen wird (Jalote, 2005 S. 41). Das
Vorgehen ist Prototypauswahl, entwerfen, konstruieren, benutzen, bewerten,
revidieren. 14 Der Prototyp wird immer auf Basis von bekannten Anforderungen
entwickelt und realisiert ausgewählte Aspekte des Ursprungssystems. Durch die
Interaktion mit den Prototypen erhalten alle Projektbeteiligten sehr früh ein Gefühl
für das System. Neue Anforderungen an das System können dabei erkannt und
bestehende überprüft werden. Ein Prototyp ist immer Bestandteil einer Spezifikation
(Ludewig, et al., 2010 S. 163-164), (Jalote, 2005 S. 41-42), (Van Vliet, 2008 S. 56-
58). Das Prototyping gilt als nicht lineares Vorgehensmodell, weil es als
Vorgehensmodell spezielle Zyklen in speziellen Sequenzen zulässt, und ist
Bestandteile vieler Prozessmodelle (Ludewig, et al., 2010 S. 163), (Hesse, et al.,
1992 S. 63).

Wie ein Prototyp in einem Entwicklungsprozess eingesetzt werden kann, hat Kieback
et al. in vier Arten unterschieden. Erstes: ein Demonstrationsprototyp, der die
prinzipiellen Einsatzmöglichkeiten und die Handhabung des Systems zeigt. Sie sind
Wegwerfprodukte, besitzen keine fachliche Detailtreue und unterliegen keinem
softwaretechnischen Standard. Zweitens: funktionale Prototypen, die Ausschnitte
der Bedienoberfläche und Teile der Funktionalität modellieren. Der Prototyp kann
bereits der Architektur des Zielsystems entsprechen. Drittens: ein Labormuster, das
technische Aspekte des Zielsystems modelliert und damit die Architektur oder
Funktionalitäten verifiziert. Labormuster stellen aus Entwicklersicht ein
Experimentalsystem in Form einer Machbarkeitsstudie dar. Viertens: Das
Pilotsystem als Prototyp ist in seiner Qualität und Funktionalität für einen zeitlich

14
Eigene Darstellung, basierend auf Hesse (Hesse, et al., 1992 S. 66) und Ludewig et al (Ludewig, et al., 2010 S.
167).
33

beschränkten echten Einsatz ausreichend weit entwickelt. Ein Pilotsystem beinhaltet


einen abgeschlossenen Teil des Zielsystems (Kieback, et al., 1992), (Ludewig, et al.,
2010 S. 167-168).

Floyd hingegen klassifiziert Prototypen in drei Arten nach dem angestrebten Ziel.
Erstens: exploratives Prototyping, das die Analyse unterstützen und ergänzen soll.
Als Prototypen werden meistens Demonstrations- und funktionale Prototypen gebaut,
die sich für konventionelle Vorgehensmodelle eignen. In der Literatur wird das
Vorgehen auch als „Rapid Prototyping“ bezeichnet. Zweitens: Experimentelles
Prototyping betrachtet die technische Umsetzung von Funktionalitäten und
Ergonomie. Hierzu werden funktionale Prototypen und Labormuster konstruiert.
Drittens: Beim evolutionären Prototyping wird dieser nicht nur als Hilfsmittel im
Entwicklungsprozess eingesetzt, sondern kann auch als Vorgehen dienen, um ein
System permanent an verändernde Rahmenbedingungen anzupassen.
Charakteristisch sind hierbei kurze Entwicklungs- und Release-Zyklen (Floyd, 1984
S. 6-12).

Bei dem vertikalen (funktionalen) Prototyping wird ein ausgewählter Teil des
Systems durchimplementiert mit dem Ziel, ein Teil des Programms anzufertigen.
Von horizontal (schichtenweise) wird gesprochen, wenn eine Ebene des
Gesamtsystems realisiert wird (Hesse, et al., 1992 S. 66), (Pomberger, et al., 2004 S.
29).

Die Gefahren beim Prototypenmodell sind: Erstens, dass Prototypergebnisse zu spät


in die Entwicklung einfließen können, zweites, dass die Prototypenentwicklung die
Entwickler von der eigentlichen Entwicklung des Systems ablenken können,
drittens, dass der Unterschied zwischen Prototyp und Produkt aus den Augen
verloren wird, viertens, dass der Prototyp ein dauerhaftes Provisorium wird und die
Entwicklung am eigentlichen Produkt verhindert, fünftens, dass der Prototyp
verführt, die Anforderung nicht sauber zu dokumentieren, weil sie im Prototyp
implementiert zu sein scheint (Hesse, et al., 1992 S. 67). Aus diesem Grund sollten
nur erfahrene Projektteams das Prototypenmodell nutzen.
34

2.2.2.5 Evolutionäre Entwicklung


Die evolutionäre Entwicklung ist dem Prototyping sehr ähnlich und wird deshalb in
der Literatur oft mit dem evolutionären Prototyping gleichgesetzt. Ähnlich wie beim
Prototyping hat die evolutionäre Entwicklung die gleiche Ausgangslage, dass die
Anforderungen an ein System nicht oder kaum bekannt sind. Der wesentliche
Unterschied besteht darin, die Software strategisch bewusst durch Zyklen aus
Erprobung und Verbesserungen so zu verändern und zu erweitern, dass sie den
gewünschten Funktionsumfang besitzt. „Evolutionäre Software-Entwicklung –
Vorgehensweise, die eine Evolution der Software unter dem Einfluss ihrer
praktischen Erprobung einschließt. Neue und veränderte Anforderungen werden
dadurch berücksichtigt, dass die Software in sequenziellen Evolutionsstufen
entwickelt wird― (Ludewig, et al., 2010 S. 171).

Die Endprodukte in Ihrer ersten Version sind typischerweise in einem strukturell


schlechten Zustand, weil die Architektur auf Basis der ersten Anforderung entworfen
wurde. Brooks führt deshalb die Regel auf: „Plan to throw one away, you have to do
it anyway―. Deshalb sollte nach erfolgreicher Einführung die Software durch eine
Neuimplementierung ersetzt werden. Als Alternative hierzu kann das von agilen
Prozessen bekannte Refactoring als Methode während der Entwicklung eingesetzt
werden (Ludewig, et al., 2010 S. 171-172), (Winter, 2005 S. 32).

2.2.2.6 Iterative Softwareentwicklung


Bei der iterativen Softwareentwicklung wird die Software in mehreren geplanten und
kontrollierten wiederholenden Schritten realisiert. Jede Wiederholung wird als eine
Iteration beschrieben, wobei bereits der erste Schritt als eine Iteration betrachtet
wird. In der zweiten Iteration wird die realisierte Software auf Basis der gewonnen
Erfahrungen mit dem System und der bekannten Mängel der ersten Iteration
korrigiert und verbessert. Markt und- Technologieentwicklung können bei jedem
Durchgang zudem mit in die Entwicklung einfließen. Dabei werden in jeder Iteration
die Tätigkeiten Analysieren, Entwerfen, Codieren und Testen durchgeführt.
35

Abbildung 5: Annäherung durch iterative Entwicklung (Ludewig, et al., 2010 S. 173)

Die iterative Entwicklung unterscheidet sich maßgeblich von der inkrementellen


durch die Zielbestimmung, die bei der iterativen gleich bleibt. Das System wird nicht
in jeder Iteration erweitert, sondern verbessert (Ludewig, et al., 2010 S. 172-174).

2.2.2.7 Inkrementelle Softwareentwicklung


Bei der inkrementellen Entwicklung wird die Software nicht in einem Projekt
realisiert, sondern in einer Reihe von aufeinander aufbauenden Ausbaustufen, welche
Software funktional erweitern. Die Software wird nach jeder Ausbaustufe
ausgeliefert und in Betrieb genommen. In der ersten Stufe wird das Kernsystem
implementiert und in den weiteren Ausbaustufen funktional erweitert. Neben dem
Kernsystem werden nach Van Vliet und Winter zudem oft auch
Softwarekomponenten mit dem höchsten Risiko („build the hardest things first“)
(Winter, 2005 S. 31) im ersten Inkrement implementiert (Van Vliet, 2008 S. 61). Im
Gegensatz zur iterativen Entwicklung besitzt die Software bei der inkrementellen
Entwicklung keinen Endzustand. Bei jedem Inkrement wird das Ziel weiter gesteckt
und dementsprechend funktional erweitert. Bei diesem Vorgehen muss
Abwärtskompatibilität zu vorherigen Systemen gewährleistet werden. Die
Vorgehensweise ist ein Kreislauf. Ist das Kernsystem im ersten Inkrement realisiert,
wird die Software im Anwendungsbereich eingesetzt. Die weiteren Inkremente
werden anschließend schrittweise nacheinander als ein jeweils eigenes Projekt
entwickelt, in die Software integriert, ausgeliefert, benutzt und bewertet.
36

Abbildung 6: Vorgehensweise der inkrementellen Entwicklung (Ludewig, et al., 2010 S. 175)

Die Vorteile dieser Vorgehensweise sind erstens, dass Schwachstellen in der


Software vom Anwender bei jedem Inkrement identifiziert und behoben werden
können. Zweitens: Einwicklungszeiten sind pro Inkrement in Vergleich zur
Gesamtentwicklungszeit sehr kurz. Fehler können zudem kostengünstiger korrigiert
werden. Drittens: Durch die schrittweise Entwicklung der Software ist ein schneller
Markteintritt mit dem Kernsystem möglich. Viertens: „Overfunctionality“ wird
durch die schrittweise Entwicklung eingegrenzt, weil das Kernsystem nur die
Grundfunktionen besitzt (Van Vliet, 2008 S. 60) und das System auf Basis von
Benutzerfeedback um spezielle Funktionalitäten erweitert wird (Ludewig, et al.,
2010 S. 174-175).

2.2.2.8 Spiralmodell
Das Spiralmodell wurde von Boehm als Antwort auf die Kritik des
Wasserfallmodells und auf die Vorschläge des Prototyping entwickelt. Als
wesentliches Unterscheidungsmerkmal gegenüber den „Document-driven“-Modellen
stellt Boehm den Risikobezug, „Risk-driven-modell“, seines Spiralmodells in den
Mittelpunkt. Beim Vorgehen soll folgender Zyklus bis zum erfolgreichen oder bis
zum Scheitern des Projekts wiederholt werden. Erstens: Es sollen alle Risiken des
Projekts gesucht werden, wenn es keine Risiken mehr gibt, gilt das Projekt als
abgeschlossen. Zweitens: Zur Identifizierung des größten Risikos eines Projekts
müssen alle Risiken des Projekts bewertet werden. Drittens: Es soll immer der Weg
genommen werden, der das nächstgrößte Risiko beseitigt. Wenn sich das Risiko
nicht beseitigen lässt, ist das Projekt gescheitert. Boehm grenzt die Art der Risiken
37

nicht ein. Risiken können auch außerhalb eines Projekts berücksichtigt werden, wie
zum Beispiel Human Ressources oder Zeitpunkte des Markteintritts.

Die Betrachtung des Risikos hat zwei Vorteile. Erstens: Wenn ein schwieriges
Problem unlösbar ist, fällt dies sehr früh im Projekt auf. Zweitens: Sind die größten
Risiken in einem Projekt gelöst, ist dies ein positives Signal für alle
Projektbeteiligten, weil anschließend nur noch kleine Risiken folgen (Ludewig, et
al., 2010 S. 178).

Das Spiralmodell ist ein generisches Modell, weil darin alle Vorgehensmodelle
enthalten sind und genutzt werden können. Es können pro Zyklus unterschiedliche
Vorgehensmodelle angewendet werden, abhängig vom zu lösenden Problem
(Sommerville, 2007 S. 73). Die Zyklen des Spiralmodells werden als Schnecke
dargestellt. Jeder Zyklus unterteilt sich in vier Aktivitäten: erstens Zielbestimmung,
einschließlich der Betrachtung von Alternativen, zweitens Risikoanalyse und ggf.
Prototypenentwicklung, drittens Konzeptentwicklung und Prüfen des nächsten
Teilprodukts, viertens weitere Projektplanung. Ein Projekt wird beim Spiralmodell
nur pro Zyklus geplant, was gleichzeitig auch die größte Kritik hervorruft. Ein
vollständiger Projektplan ist beim Spiralmodell nicht vorgesehen (Ludewig, et al.,
2010 S. 179). Das Spiralmodell unterscheidet sich in seiner Produktivität nach
Boehm nicht wesentlich von anderen, wenn die Risiken im Projekt gering sind
(Boehm, 1988 S. 69).

2.2.2.9 Einsatz der Vorgehensmodelle


In der Literatur wird keine Kategorisierung vorgenommen, welches Modell in
welcher Projektart eingesetzt werden soll – und das, obwohl es die Klassifikationen
von Programmen nach Lehman gibt (Ludewig, et al., 2010 S. 161-162). In der
heutigen Zeit leben Vorgehensmodelle in Prozessmodellen und sind deshalb als
Softwareentwicklungsprozess isoliert betrachtet in ihrer Anwendung nicht mehr zu
empfehlen. Dennoch muss innerhalb von Prozessmodellen entschieden werden,
welches Vorgehen genutzt werden soll. In der Literatur wird immer wieder
angedeutet, dass gute Entwicklerteams durch ihre Erfahrungswerte mit jedem
Vorgehen erfolgreich sind.
38

Das Prototyping sollte als Vorgehen eingesetzt werden, wenn wichtige


Anforderungen fehlen oder nur unzureichend formuliert werden können. Die
evolutionäre Vorgehensweise sollte genutzt werden, wenn eine Anforderung faktisch
nicht möglich ist, weil maßgebliche (meist externe) Einflussgrößen, die hohen
Einfluss auf die Entwicklung haben, nicht bekannt sind. Die iterative Entwicklung ist
für Projekte sinnvoll, wenn ein Problem das erste Mal gelöst wird und von Beginn an
klar ist, dass der erste Wurf den Anforderungen nicht gerecht wird, dies aber durch
Iterationen gelöst werden kann. Die inkrementelle Softwareentwicklung hingegen
sollte bei Produkten eingesetzt werden bei denen „Time to Market“ einen hohen
Stellenwert besitzt und es ausreicht, im ersten Release nur das Kernsystem zu
realisieren, welches später um zusätzliche Funktionen erweitert werden soll. Das
Spiralmodell kann bei Projekten eingesetzt werden, die im Projekt bekannte,
technische Projektrisiken besitzen.15

2.2.3 Ausgewählte Prozessmodelle


Die Literatur bietet eine Vielzahl sehr unterschiedlicher Prozessmodelle an. Im
Allgemeinen wird geraten, die derzeitigen internen Prozesse zu analysieren, um
festzustellen wie diese gelebt und angewendet werden. Das Einführen eines neuen
Prozesses ist langwierig, schwierig, riskant und unterliegt einem „Change
Management“. Aus diesem Grund müssen Prozessmodelle in ihrem konkreten
Umfeld nach unterschiedlichen Bedingungen innerhalb eines Projekts angepasst
(Tailoring) werden können. Prozessmodelle lassen deshalb entweder mehr oder
weniger viel Spielraum bei ihrer Anwendung und in ihrer Ausgestaltung zu
(Ludewig, et al., 2010 S. 181-182). Im Zusammenhang mit den agilen Prozessen, die
aus der agilen Bewegung entstanden sind, werden Prozessmodelle in leicht- und
schwergewichtige Prozesse unterteilt (Van Vliet, 2008 S. 51). Der Unterscheid
zwischen „schwer“ und „leicht“ wird dabei anhand des Grades der Formalisierung
des Prozesses und an der Anzahl der verbundenen (Zwischen-)Ergebnisse/-Produkte
gemacht (Pomberger, et al., 2004 S. 45). Schwergewichtige Prozesse sind sehr
planungsgetrieben und legen viel Wert auf die Einhaltung des Prozessablaufs.
Leichtgewichte Prozesse dagegen sehen Änderungen als Gegenstand des

15
Eigene Darstellung in Anlehnung an Ludewig, et al, 2010.
39

Prozessablaufs und versuchen, so wenig Zeit wie möglich, so viel wie nötig für die
Planung zu verbringen. Im Zentrum leichtgewichtiger Prozesse stehen nicht der
Prozess an sich und die konsequente Einhaltung dessen, sondern das Liefern von
lauffähiger Software (Van Vliet, 2008 S. 51). Aufgrund des fehlenden
Kriterienkatalogs für leichte und schwere Prozesse in der Literatur erfolgt in dieser
Arbeit keine Einteilung (Ludewig, et al., 2010 S. 183). Insgesamt kann aber
festgestellt werden, dass alle agilen Prozesse wie XP, FDD und Scrum den
leichtgewichtigen Prozessen zugeordnet werden können.

2.2.3.1 Phasenmodell
Beim Phasenmodell wird die die Softwareentwicklung in Phasen (Etappen)
gegliedert, die streng sequenziell durchlaufen werden. Das Ende einer Phase
symbolisiert einen Meilenstein. Jede neue Phase startet erst nach Erreichen des
Meilensteins der vorherigen Phase und hat ein zugewiesenes Budget. Das Budget
jeder Phase wird erst bereitgestellt, wenn der vorherige Meilenstein erreicht wurde.
Durch die Verknüpfung der Phasen mit Budgets wird es auch Kostenmodell genannt.
In dem Phasenmodell sind Rücksprünge in bereits abgeschlossene Phasen nicht
vorgesehen. Sollten Rücksprünge in vorherige Phasen notwendig sein, finden die
Tätigkeiten im Budget unter den Bedingungen der gerade laufenden Phase statt. Als
Vorgehensmodell wird das (strenge) Wasserfallmodell genutzt. Das Phasenmodell
bringt erheblichen Aufwand für die Organisation mit und ist stark von den Methoden
des Projektmanagements geprägt.

Die Vorteile sind, dass erstens Abweichungen von der Planung schnell erkannt
werden, spätestens nach nicht erreichen eines Meilensteins. Zweitens: Der
Personalbedarf ist pro Phase geklärt und sichergestellt. Drittens: Durch die
Prüfungen am Ende jedes Meilensteins ist das Risiko gering, dass im Projekt in die
falsche Richtung gearbeitet wurde oder dass Teile des Projekts zu spät fertig werden.
Viertens: Das „90 % Syndrom“ kann ausgeschlossen, bzw. auf bestimmte Phase
begrenzt werden, weil pro Meilenstein die Projektdauer genau festgelegt wurde.
Größter Kritikpunkt ist die strenge Aufteilung in sequenzielle Phasen, die sich nicht
überlappen dürfen (Ludewig, et al., 2010 S. 184-187).
40

2.2.3.2 Timeboxing-Modell
Das Timeboxing-Modell von Jalote parallelisiert einzelne Inkremente innerhalb des
Softwareentwicklungsprozesses. Jedes Inkrement repräsentiert eine Timebox. Eine
Timebox umreißt einen fixen Zeitraum, in der ein Inkrement der Software
fertiggestellt werden muss. Im Gegensatz zu anderen Modellen – in denen erst nach
den Anforderungen festgestellt wird, wie lange die Entwicklung dauert –, wird der
Umfang eines Inkrements anhand dessen bestimmt, was in der zur Verfügung
stehenden Zeit pro Timebox realisiert werden kann. Jede Timebox als Inkrement
nutzt ein sequenzielles Vorgehensmodell (Jalote empfiehlt das strenge
Wasserfallmodell). Die Parallelisierung erfolgt, indem ein oder mehrere Teams die
Sequenzen zeitversetzt pro Timebox nacheinander abarbeiten. Die Realisierung des
ersten Inkrements besitzt eine Projektdauer der ersten Timebox, danach werden die
weiteren Inkremente in einem festgelegten Zeitintervall, das jeweils die Dauer einer
Sequenz besitzt, geliefert. Wenn eine Timebox die drei Sequenzen Requirement,
Code und Deploy besitzt und eine Größe von T-Tagen besitzt, würde das erste
Inkrement nach T Tagen geliefert werden. Alle weiteren würden nach T/3 erfolgen.

Abbildung 7: Ausführung des Timeboxing-Modells (Jalote, et al., 2004)

Nach Jalote ist der Vorteil des Timeboxing-Modells, dass durch die Parallelisierung
der Timeboxen mehrere Teams an einem Projekt gleichzeitig arbeiten können, was
es für den Offshore-Bereich sehr interessant macht. Im Gegensatz zu anderen
Prozessmodellen kann damit die Realisierungszeit aufgrund eines höheren
Personeneinsatz verkürzt werden. Eingesetzt werden sollte das Timeboxing-Modell
bei Projekten, bei denen eine hohe Anzahl an Funktionen implementiert werden
41

muss und die Software in benutzbare Inkremente aus Nutzersicht aufgeteilt werden
kann. Voraussetzung bei dem Timeboxing-Modell ist nach Jalote erstens ein
Projektmanagement, das die Komplexität der Parallelität im Projekt beherrscht, und
zweitens muss die Software auf eine stabile Architektur aufsetzen. Nachteile des
Modells sind erstens, dass Change Requests nach einer abgeschlossenen Timebox in
einer darauf folgenden Timebox geändert werden müssen, und dass zweitens
Refactoring von Code nicht innerhalb einer Timebox geschieht, sondern
nachgelagert in einer Timebox erfolgt (Jalote, 2008 S. 25-27), (Jalote, et al., 2004).

2.2.3.3 V-Modell (XT)


In seiner Arbeit über V&V von Software hat Boehm 1979 seinem Wasserfallmodell
ein V-förmiges Phasenmodell gegenübergestellt (Boehm, 1979). Erste
Entwicklungen zum V-Modell begannen 1986. In der Folge wurde es im Auftrag des
Bundesministeriums für Verteidigung entwickelt und ist dort seit 1992 verbindlich
vorgeschrieben. 1996 wurde es auch für den zivilen Verwaltungsbereich Pflicht.
1997 wurde es erneut überarbeitet und unter der Bezeichnung V-Modell 97
publiziert. Enthalten waren in dieser Version die Unterstützung der inkrementellen
Entwicklung, koordinierte Entwicklung von Hard- und Software und die
objektorientierte Entwicklung. 2004 wurde in einer erneuten Revision das V-Modell
XT vorgestellt. Das „XT“ steht in diesem Fall für „Extreme Tailoring“ (Ludewig, et
al., 2010 S. 190).
42

Abbildung 8: V-Modell von 1979 nach Boehm (Boehm, 1979)

Das V-Modell in seiner ursprünglichen Version von Boehm betrachtet die


Softwareentwicklung als symmetrischen Prozess und stellt neben den Rückbezügen
auf vorausgegangene Entwicklungsschritte auch Querbezüge zwischen den
Entwürfen/Aktivitäten und daraus entstehenden Produkten her. Sollten sich bei den
Querbezügen Unstimmigkeiten ergeben, muss zur überprüften Phase zurückgekehrt
werden (Hesse, et al., 1992 S. 37-38). Die entwerfenden Aktivitäten stehen dabei am
linken Ast des V-Modells. Dem stehen rechts realisierende und überprüfende
Tätigkeiten (Produkte) gegenüber. Boehm trennt durch die waagerechte Linie
„requirements baseline“ den fachlichen (Auftraggeber und Nutzer) vom technischen
(Entwickler-)Teilbereich. Oberhalb der Linie ist zudem nur Validation möglich,
welche die Frage „Haben wir das richtige Produkt gebaut?“ beantwortet. Verification
unterhalb beantwortet dagegen die Frage: „Haben wir das Produkt richtig gebaut?“
(Höhn, et al., 2008 S. 575).

Folgende wesentliche Merkmale charakterisieren das V-Modell 97/XT des Bundes:


Erstens: Das V-Modell teilt ein Projekt in Projektabschnitte, an deren Ende ein
Meilenstein geknüpft ist, der Entscheidungspunkt genannt wird. Zweitens: Das V-
Modell kann für Software- und Hardwareprojekte genutzt werden sowie als Meta-
Projekt zur Einführung eines Vorgehensmodells in eine Organisation. Drittens: Das
43

V-Modell integriert im Gegensatz zum Wasserfallmodell projektbegleitende


Tätigkeiten wie Qualitätssicherung, Konfigurationsverwaltung und
Projektmanagement. Deshalb wird es in dieser Arbeit auch als Prozessmodell
verstanden und nicht als Vorgehensmodell. Viertens: Das V-Modell unterstützt
inkrementelle, komponentenbasierte und prototypische Entwicklung. Fünftens: Das
V-Modell lässt sich insbesondere in der XT-Variante anpassen und erweitern.

Die Elemente des Modells bestehen aus Aktivitäten, Produkten, Rollen,


Vorgehensbausteinen, Entscheidungspunkten, Projektdurchführungsstrategien und
Entwicklungsstrategien. Ein Produkt wird in Aktivitäten erstellt oder bearbeitet,
wobei eine Aktivität in Arbeitsschritte gegliedert sein kann. Als Produkte werden die
(Zwischen-)Ergebnisse eines Projekts bezeichnet. Produkte können wie Aktivitäten
gegliedert werden und heißen dann Thema. Inhaltlich zusammengehörende Produkte
und Aktivitäten werden gruppiert und als Disziplin bezeichnet. Im V-Modell sind 13
Disziplinen definiert. Rollen beschreiben zusammengehörende Aufgaben und
Verantwortlichkeiten sowie die dazugehörenden Fähigkeiten. Einem Produkt ist
immer eine Rolle zugewiesen sowie ggf. zusätzliche Rollen, die das Produkt
unterstützen. Insgesamt sind 30 Rollen im V-Modell XT definiert.
Vorgehensbausteine fassen Disziplinen zusammen, die für eine Aufgabe relevant
sind. Dabei werden für alle Projekte mindestens vier Vorgehensbausteine definiert:
Projektmanagement, Qualitätssicherung, Problem- und Änderungsmanagement und
Konfigurationsmanagement. Neben diesen Vorgehensbausteinen können im
„Tailoring“ weitere hinzukommen. Entscheidungspunkte besitzen drei Funktionen.
Erstens übernehmen sie die Funktion eines Meilensteins und definieren damit, wann
der nächste Projektabschnitt begonnen werden kann. Zweitens definieren sie, welche
Produkte am Ende jedes Entscheidungspunktes fertiggestellt sein müssen und
drittens deren Bewertung. Die Projektdurchführungsstrategie schafft den Rahmen,
in der das Projekt geordnet und nachvollziehbar durchgeführt werden kann. Sie legt
die Entscheidungspunkte fest und deren zeitliche Reihenfolge. Jedes
Entwicklungsprojekt wird immer in Iterationen durchgeführt, für jede Iteration muss
entschieden werden, welche der drei Entwicklungsstrategien (inkrementiell, iterativ,
Prototyp) angewendet werden soll. Entwicklungsstrategien geben, wie auch die
Projektdurchführungsstrategien, Entscheidungspunkte vor.
44

Abbildung 9: Vereinfachte Darstellung der Struktur des V-Modells XT (Ludewig, et al., 2010 S. 196)

Die Struktur des V-Modells XT kann sehr vereinfacht wie folgt erläutert werden.
Erstens: Für jeden Projekttyp sind Vorgehensbausteine und
Projektdurchführungsstrategien festgelegt. Zweitens: Die Projektdurchführungs-
strategie gibt zu erreichende Entscheidungspunkte vor. Produkte müssen an jedem
Entscheidungspunkt fertiggestellt sein. Drittens: Pro Vorgehensbaustein werden alle
Rollen und Disziplinen (Produkte und Aktivitäten) zusammengefasst, um eine
Projektaufgabe zu lösen. Die Vorgehensbausteine bauen aufeinander auf. Viertes:
Produkte und Aktivitäten sind in Disziplinen unterteilt. Produkte werden durch genau
eine Aktivität fertiggestellt. Produkte hängen voneinander ab. Fünftens: Die Rollen
sind für Produkte verantwortlich und wirken an deren Erstellung mit.

Das Tailoring unterscheidet sich im Vorgehen beim V-Modell 97 gegenüber dem V-


Modell XT. Beim V-Modell 97 wird die Gesamtmenge der Aktivitäten durch
Streichungen eingeschränkt. Das V-Modell XT geht dagegen von Aktivitäten, die
minimal erforderlich sind, aus. Pro Projekttyp gibt es im V-Modell XT
verpflichtende und optionale Vorgehensbausteine – die beim Tailoring hinzugezogen
oder weggelassen werden können.

Mit dem V-Modell (XT) wird nicht nur die reine Softwareentwicklung abgedeckt,
sondern das komplette Projekt. Es besitzt sehr ausgefeilte und detaillierte Vorgaben,
45

wie ein Projekt abläuft, und kann sehr gut als Ausgangspunkt genutzt werden, um
einen Entwicklungsprozess zu definieren. Es ist ein generisches Modell und kann
durch Tailoring an Prozesse und Projekte angepasst werden. Durch die Komplexität
des Modells ergibt sich ein enormer Umfang von Produkten, Aktivitäten und Rollen,
die es für kleinere Projekte unbrauchbar macht. Anpassungen an das Modell sind
sehr aufwändig und ohne Anpassungen wird es aufgrund der Größe sehr schwerfällig
und endet in Bürokratie. Durch die Komplexität entsteht zudem ein hoher
Schulungsaufwand für die Mitarbeiter des Projekts (Ludewig, et al., 2010 S. 190-
201).

2.2.3.4 (Rational-)Unified Process


Der „Unified Process“ entstand aus der Notwendigkeit heraus, dass die Methoden für
Analyse und Entwurf, Qualitätssicherung und Test nur auf imperative und nicht
objektorientierte Sprachen zugeschnitten waren. Die konventionellen Prozessmodelle
waren zudem wenig geeignet für die objektorientierte Programmierung. Der „Unified
Process“ ist historisch gesehen aus der Entwurfsmethode Objectory entstanden, die
später um Prozesskomponenten wie zum Beispiel dem des „Use Cases“ erweitert und
dann in „Objectory-Process“ umbenannt wurde. Durch den Zusammenschluss der
Firmen Objectory AB und Rational Software Corp. flossen die von Rational
entwickelten Ansätzen zur Softwareentwicklung in den Objectory Process ein.
Daraus entstanden zunächst der Rational Objectory Process und später der Rational
Unified Process (RUP). Der Unified Process wurde anschließend von RUP
abstrahiert. Der RUP stellt damit eine konkrete Ausprägung des Unified Process
(UP) dar.

Der Unified Process soll die Vorteile von Phasenmodellen und nicht linearen
Prozessmodellen vereinen. Dabei sollen Phasen die Planung und das Management
von Entwicklungsprojekten erleichtern und durch Iterationen sowie inkrementelles
Entwickeln helfen, Risiken früh zu erkennen. Die vier folgenden Merkmale sind
charakteristisch: Erstens: Der UP ist ein Phasenmodell mit vier Phasen
(Interception, Elaboration, Construction, Transition), an deren Ende jeweils ein
Meilenstein passiert werden muss (LO = Lifecycle Objective, LA = Lifecycle
Architecture, OC = Initial Operational Capability, PR = Product Release). In jeder
46

Phase werden alle definierten Arbeitsabläufe in unterschiedlicher Intensität


durchgeführt. Ein Durchlauf durch alle vier Phasen wird als Zyklus bezeichnet. Das
Ergebnis ist ein internes oder an den Kunden auslieferbares Release. Zweitens: Der
UP ist iterativ. Jede Phase kann mehrere Iterationen beinhalten. Das Ergebnis einer
Iteration ist immer eine ausführbare Systemkonfiguration oder ein Prototyp. In jeder
Iteration und allen Phasen wird getestet. Ein Release entsteht über alle Phasen
hinweg indem Arbeitsergebnisse inkrementell weiterentwickelt werden. Drittens:
Ein Produkt wird inkrementell entwickelt, indem es mehrere Zyklen durchläuft. Am
Ende des letzten Zyklus ist das Produkt fertiggestellt. Viertens: UP basiert auf „Use
Cases“. Die Identifikation und Modellierung der „Use Cases“ zur Beschreibung der
funktionalen Anforderung ist zentraler Bestandteil des Ansatzes.

Die Struktur des UP setzt sich aus Rollen (Worker), Aktivitäten, Artefakten,
Arbeitsabläufen (Workflows) und Phasen zusammen. Als Rolle (Worker) werden
zusammenhängende Aufgaben, Verantwortlichkeiten und Fähigkeiten bezeichnet.
Ein Worker kann in unterschiedlichen Arbeitsaufläufen verschiedene Rollen
besetzen. Eine Aktivität ist eine Tätigkeit, die von einer Rolle in einem Arbeitsablauf
getätigt wird, und liefert immer ein definiertes Ergebnis. Ein Artefakt ist eine
„formulierte“ Information. Diese wird in Dokumente und Modelle unterschieden.
Artefakte sind der Input einer Aktivität und werden durch Worker in einem
Arbeitsablauf erstellt, verändert oder benutzt. Ein Arbeitsablauf fasst
zusammengehörige Worker, Aktivitäten und Artefakte zusammen. Dabei werden
vier Kernabläufe (Core Workflows) definiert: Requirements, Analysis,
Implementation und Test. Das Phasenmodell wird in vier Phasen unterteilt. Erstens:
Interception, in der die Produktidee und die Anforderung auf Basis einer
wirtschaftlichen Betrachtung soweit verstanden wird, dass ein Projekt zustande
kommt. Use Cases werden identifiziert und modelliert, Risikobewertungen, erste
Fassung der Architektur und des Projektplans werden erstellt. Wenn nötig werden
erste Prototypen entwickelt, um Risiken abzuschätzen. Zweitens: In der Elaboration
werden alle fehlenden Anforderungen und die größten Risiken identifiziert, bewertet
und Gegenmaßnahmen geplant sowie Pläne für die zwei folgenden Phasen erstellt.
Der Bau eines Protoypen zeigt den ersten Architekturkern und Funktionalitäten des
Systems. Drittens: In der Construction Phase wird das System auf Basis der
47

vorhandenen Systemarchitektur implementiert, integriert und getestet.


Unvollständige Dokumentationen werden fertiggestellt. Am Ende der Phase ist das
System in der Qualität einer Beta-Version. Viertens: In der Transition wird das
Produkt so lange auf Basis von Rückmeldungen und Erfahrungen von Anwendern
verbessert, bis es stabil ist. Ziel ist, das Produkt soweit zu verbessern, dass es
Produktqualität erreicht. Die Phase endet, wenn der Kunde mit dem Ergebnis
zufrieden ist. Wird das Produkt in mehreren Ausbaustufen entwickelt, werden die
Phasen erneut durchlaufen.

Abbildung 10: Phasen, Iterationen und Arbeitsabläufe (Ludewig, et al., 2010 S. 206)

Der Rational Unified Prozess (RUP) passt den generischen Unified Process durch
Erweiterungen (Tailoring) an. Im RUP wird der Arbeitsablauf (Workflow) durch
„Discipline“ ersetzt. Ein Workflow in RUP beschreibt die Anordnung und den
Ablauf der Aktivitäten einer Disziplin. RUP erweitert zudem neben neuen Rollen,
Aktivitäten und Artefakten die fünf Kern-Arbeitsabläufe vom UP um weitere fünf.
Jede Disziplin wird in Form eines UML-Diagramms detailliert beschrieben, um die
Reihenfolge und Abhängigkeiten der Aktivitäten eines Arbeitsablaufs zu
visualisieren. Daneben wird jede Aktivität detailliert durch einen Text beschrieben,
und bei Artefakten wird die Gliederung vorgegeben und der Inhalt umrissen.

Um RUP einsetzen zu können, sollten eine ausgezeichnete Konfigurations- und


Änderungsverwaltung, Projektmanagementfertigkeiten und Kenntnisse in
objektorientierter Konzeption und Notation vorliegen. Vorteile von RUP sind gute
48

Darstellung und detaillierte Dokumentation der Prozesse in Form von


Arbeitsanleitungen, inhaltliche Beschreibung und Musterdokumente. Zudem vereint
RUP das Phasenmodell mit iterativer sowie inkrementeller Entwicklung und schließt
das Prototyping mit ein. Durch den hohen Detaillierungsgrad muss das Projekt an
den RUP-Prozess angepasst werden. Projektspezifisches Tailoring ist deshalb
schwierig. Zudem ist RUP ein Produkt, das vermarktet und stetig weiterentwickelt
wird. Die Prozessdefinition ist deshalb relativ unstabil, da bei Updates veränderte
Fassungen des Prozesses entstehen und im Change Management berücksichtigt
werden müssen. Des Weiteren vermittelt RUP den Eindruck, dass bei der Einhaltung
des Prozesses garantiert ein gutes Ergebnis entsteht und Software industriell zu
fertigen ist. Die reine Formalität des Prozesses reicht hier nicht aus, vielmehr ist es
relevant, brauchbare Arbeitsergebnisse aus den einzelnen Aktivitäten zu erhalten
(Ludewig, et al., 2010 S. 207-211), (Van Vliet, 2008 S. 68-71), (Winter, 2005 S. 32-
35).

2.2.3.5 Extreme Programming


Extreme Programming gehört zu den agilen Prozessen und ist von Kent Beck, Ward
Cunningham und Ron Jeffries im Rahmen der Arbeit des Comprehensive
Compensation System bei Chrysler entstanden. Kent Beck hat zu Extreme
Programming zwei Bücher veröffentlicht. Das erste, „Extreme Programming
Explained. Embrace Change“, erschien 1999 und hat den Stellenwert eines
Manifests. Die zweite Auflage erschien 2004 und wurde von Grund auf
überarbeitet16. In dieser Arbeit wird die erste Auflage behandelt und lediglich auf die
Änderungen der 2. Auflage hingewiesen, wenn dies sinnvoll erscheint.

Die zentralen Elemente von Extreme Programming sind die XP-Werte (values), XP-
Prinzipien (basic principles) und XP-Konzepte (practices). Das aus den drei
Elementen entstehende XP-Prozessmodell stellt die Menschen (alle
Projektbeteiligten) und deren Kommunikation in den Mittelpunkt und nicht

16
Kent Beck hat die Prinzipien komplett überarbeitet. Die Techniken sind in der neuen Auflage in
Primärtechniken und Sekundärtechniken unterteilt. Als neue Techniken sind „Pay per Use“, das SaaS als
Geschäftsmodell schon im Entwicklungsprozess integriert sowie die „Root-Cause Analysis“ und „Shrinking
Teams“.
49

Dokumente, Werkzeuge oder Prozesse. Zudem sind die Entwicklerteams in Extreme


Programming schlank und besitzen eine Größe von ca. 10-20 Entwicklern.

Extreme Programming beruht auf vier Werten: Einfachheit, Feedback,


Kommunikation und Mut. Es sollen möglichst einfache Lösungen erstellt und
Prozesse genutzt werden, weil diese leicht zu erstellen und schneller zu verstehen
sind als komplexe. Das Projektteam soll so schnell und oft Feedback über Ergebnisse
vom Anwender oder den Kollegen im Team bekommen. Rückmeldungen sind Teil
der Qualitätssicherung. Die persönliche und direkte Kommunikation steht im
Vordergrund. Teams arbeiten nicht räumlich getrennt voneinander und sehen eine
hohe Verfügbarkeit des Kunden und Anwenders vor. Dokumente sind als
Kommunikationsmittel zweitrangig und dienen nur als Ergänzung. Mut wird
benötigt, um die ersten drei Werte in einem Projekt zu leben. In der neuen Auflage
wird als fünfter Wert „Respekt“ hinzugefügt. Jeder Projektbeteiligte respektiert die
anderen. Dies soll den menschenzentrierten Ansatz explizit hervorheben. Tailoring
der Werte ist seit der zweiten Auflage zudem projektspezifisch erlaubt (Wolf, et al.,
2005 S. 4-6), (Ludewig, et al., 2010 S. 222).

Die 15 XP-Prinzipien leiten sich aus den Werten ab. Die fünf zentralen Prinzipien
sind: unmittelbares Feedback, Einfachheit anstreben, inkrementelle Veränderung,
Veränderung wollen und Qualitätsarbeit. Die weiteren zehn Prinzipien sind: Lernen
lehren, geringe Anfangsinvestition, auf Sieg spielen, gezielte Experimente, offene
und aufrichtige Kommunikation, Instinkte des Teams nutzen nicht – dagegen
arbeiten, Verantwortung übernehmen, an örtliche Gegebenheiten anpassen, mit
leichtem Gepäck reisen und ehrliches Messen. Besonders hervorzuheben sind
erstens, dass komplexe Software inkrementell verändert werden soll, weil nur bei
schrittweise kleinen Änderungen unerwartete Effekte beherrschbar bleiben.
Zweitens: Extreme Programming Projekte spielen, um zu gewinnen und nicht, um
zu verlieren. Extreme Programming Projekte gehen davon aus, Fehler zu machen,
um daraus zu lernen, und versuchen nicht von Anfang an, Fehler zu verhindern.
Drittens: Es sollen gezielt Experimente im Projekt gestartet werden, um Risiken in
der Software oder im Entwicklungsprozess aufzudecken oder die eigenen
Entscheidungen überprüfen zu können (Wolf, et al., 2005 S. 6-10).
50

Die XP-Konzepte – auch oft als Techniken deklariert – helfen, die Werte und
Prinzipien in der konkreten Projektarbeit umzusetzen. Extreme Programming
definiert 14 Konzepte, die in Management-, Team- und Programmierkonzepte
gruppiert werden können (Wolf, et al., 2005). Die Konzepte bedingen teilweise
einander und können deshalb im Rahmen von Extreme Programming nicht isoliert
eingesetzt werden. Die XP-Programmierkonzepte wie Paar-Programmierung,
testgetriebene Entwicklung und Refactoring sind generisch und werden auch ohne
Extreme Programming in der Praxis, zum Beispiel in Scrum, genutzt. Die Konzepte
sind wie eine Zwiebel aufgebaut, wobei Management die äußere und
Programmierkonzepte die innere Schale abdecken.

Die Managementkonzepte vereinen 5 Disziplinen. Erstens: Das integrale Team,


das zwingend den Kunden im Projekt verlangt, weil nur er die tatsächlichen
Anforderungen kennt und priorisieren kann. Der Kunde muss jederzeit dem Team für
Fragen und Diskussionen zur Verfügung stehen. Zweitens: Im Planungsspiel wird
der Aufwand jedes Inkrements, das iterativ entwickelt wird, mit dem Kunden
zusammen geschätzt. Der Kunde nennt die Anforderungen, die Entwickler schätzen
den Aufwand. Planungssitzungen werden so lange durchgeführt, bis eine Basis für
das nächste Inkrement gefunden wurde. Drittens: kurze Relase-Zyklen im Bereich
von mehreren Wochen, damit der Anwender schnell und oft Feedback geben kann.
Viertens: Täglich kurze, 15-minütige „Standup Meetings“, die keine ausgeprägte
Hierarchie aufweisen, finden im Stehen statt und dienen dazu, Aufgaben zu verteilen
und sich über Projektfortschritt und Probleme auszutauschen. Fünftens: In längeren
Abständen werden Sitzungen mit ausgewählten Personen durchgeführt, in denen das
Projekt im Rückblick bewertet wird, um Schwächen sowie Fehler zu identifizieren
und daraus zu lernen.

Die Teamkonzepte bestehen ebenfalls aus fünf Disziplinen. Erstens: Die


gemeinsame Verantwortung für den Code entspricht inhaltlich dem Egoless
Programming und wird über Paar-Programmieren praktisch gelöst. Zweitens:
Coderichtlinien gelten verbindlich für das Projekt. Drittens: erträgliche
Arbeitsbelastung, keine Überstunden einplanen, damit die Leute nicht verschlissen
werden. Viertens: zentrale Methapern, die helfen, einen gleichen Blickwinkel auf
51

das Projekt zu bekommen und dem fachlichen Entwurf zu Grunde liegt. Fünftens:
Bei der laufenden Integration werden Ergebnisse in einer speziellen Umgebung
integriert und allen Entwicklern zur Verfügung gestellt. Nach der Integration müssen
alle Tests fehlerfrei durchlaufen, erst dann bleibt der Code im Gesamtsystem
vorhanden.

Die Programmierkonzepte umfassen vier Disziplinen, die in der Literatur auch als
einzelne Techniken separat betrachtet werden und deshalb generisch in anderen
Prozessmodellen eingesetzt werden. Erstens: Die testgetriebene Entwicklung (Test
Driven Development) sieht vor, dass Tests („Unit Tests“) vor dem Implementieren
erfolgen müssen. Das Schreiben der „Unit Tests“ vor der Implementierung soll
Entwicklern helfen, die Anforderungen einzuhalten und nur die Funktionen zu
implementieren, die notwendig sind, um den „Unit Test“ zu bestehen. Akzeptanztests
dienen dazu, die implementierten Funktionen fachlich abzunehmen. Zweitens:
Strukturverbesserungen (Refactoring) ist der Prozess, ein Softwaresystem
kontinuierlich intern so zu optimieren, dass sich das externe Verhalten nicht ändert.
Durch Refactoring werden die Struktur und das Design des Codes vereinfacht,
verbessert und die Komplexität des Codes reduziert, nachdem dieser geschrieben
wurde. Ziel ist, die Fehlerquote durch fehlerhaften Code oder schlechte Architektur
zu senken (Ludewig, et al., 2010 S. 593). Drittens: Bei der Paar-Programmierung
wird grundsätzlich das Programmieren von zwei Entwicklern durchgeführt. Einer
codiert und einer schaut zu, prüft und hinterfragt den Code. Die Rollen wechseln
ständig und die Paare können variieren. Durch Paar-Programmierung wird die
Qualität des Codes erhöht und das Wissen auf mehrere Person verteilt. Viertens: Das
Softwaresystem sollte die Anforderungen möglichst durch einen einfachen Entwurf
abbilden und mit Hilfe des Refactoring die Architektur inkrementell erweitern (Wolf,
et al., 2005 S. 10-15), (Ludewig, et al., 2010 S. 223-225).

Ausgehend von den Werten (values), XP-Prinzipien (basic principles) und XP-
Konzepten (practices) umfasst der Entwicklungsprozess drei Teilprozesse: erstens
Release Planung, zweitens iterative Release-Erstellung und drittens Akzeptanztests
und Release-Veröffentlichung (Pomberger, et al., 2004 S. 46). Ein Release-Zyklus
beginnt mit der Release-Planung, der auf Basis von vorher festgelegten „User
52

Stories“ 17 erstellt wird. Jede „User Story“ muss für einen Entwickler in wenigen
Tagen umgesetzt werden können. In jedem Release werden die wichtigsten User
Stories implementiert, die der Kunde festlegt und priorisiert. Jedes Release wird
anhand der User Stories in einem Planungsspiel geschätzt und nach der Realisation
gegengerechnet, um aus Fehleinschätzungen zu lernen. Die Entwicklung erfolgt
anschließend in aufeinanderfolgenden Iterationsschritten, in der jede Iteration
abhängig vom Release-Plan geplant wird. Der Teilprozess der Release-Planung wird
immer angestoßen, wenn sich Änderungen oder Erweiterungen der User Stories
ergeben, sich die Systemarchitektur oder die Rahmenbedingungen im Projekt ändern.
Änderungen werden in der nächsten Iteration implementiert. Im Teilprozess der
Iteration findet die eigentliche Release-Entwicklung statt. Pro Iteration wird ein
Realisationszeitraum von zwei bis vier Wochen festgelegt, die im Planspiel
berücksichtigt werden müssen. Der Entwicklungsprozess beginnt mit „Unit Tests“,
mit denen Entwicklerpaare später überprüfen, ob die Anforderungen eines „User
Tasks“ korrekt implementiert wurden. Danach erfolgen der Entwurf und die
Implementierung durch die Entwicklerpaare. Ab einem bestimmten Reifegrad
werden „Unit Tests“ so lange ausgeführt, bis diese keine Fehler mehr aufweisen.
Anschließend wird die entwickelte Systemkomponente ins Gesamtsystem integriert.
Eine Überarbeitung erfolgt bei fehlgeschlagender Integration ins Gesamtsystem. Ist
ein User Task erfolgreich integriert worden, werden der Teilprozess des
Akzeptanztests und die Release-Veröffentlichung angestoßen. Wenn alle User
Stories erfolgreich den Akzeptanztest durchlaufen haben, wird ein System-Release
zur Veröffentlichung freigegeben. Sind in dem Release nicht alle Funktionen
implementiert, wird ein neuer Release-Zyklus angestoßen (Pomberger, et al., 2004 S.
47-48).

17
User Stories sind vergleichbar mit „Use Cases“ aus dem Unified Process. In XP wird zunächst vom Kunden die
User Story in Prosa geschrieben, welche die Fragen „wer“, „was“, „warum“ beantworten müssen. Der Entwickler
definiert auf Basis der „User Story“ den „User Task“, der die Funktionen für das zu entwickelnde System
definiert.
53

Abbildung 11: XP-Prozess – Projektüberblick (Wells, 2000)

Die Vorteile des XP-Prozessmodells liegen in seiner Flexibilität, bei sich ständig
ändernden Rahmenbedingungen Anpassungen vornehmen zu können, und der
Möglichkeit, sich auf wesentliche Kernfunktionen in den ersten Releases zu
beschränken, die anschließend inkrementell in darauf folgende Releases erweitert
werden können. Durch die Einbindung des Auftraggebers und Anwenders wird die
Software sehr Nutzer-zentriert entwickelt. Extreme Programming eignet sich deshalb
für Produktentwicklungen, in denen Anforderungen nur in informeller, vager Form
vorliegen und sich häufig ändern können (Pomberger, et al., 2004 S. 50). Die
Kritiken an Extreme Programming sind vielseitig. Die einzelnen Elemente von
Extreme Programming bedingen so stark einander, dass ein dogmatisches Vorgehen
innerhalb des Prozessmodells Pflicht ist. Des Weiteren geht Extreme Programming
davon aus, dass Änderungen grundsätzlich günstig sind, wenn man sie kontinuierlich
durchführt. Warum klare Spezifikationen, die bis zu Projektende Bestand haben,
nicht in einer „Spezifikation“ festgehalten werden sollen, wird ebenfalls nicht klar.
Besonders kritisch ist allerdings die Annahme des idealen Kunden und
Programmierers. Kunden sind in der Regel nicht experimentierfreudig und müssen
aus Werkvertrags- und Unternehmenssicht eine Spezifikation und ausführliche
Dokumentation für die spätere Programmpflege durch andere Dienstleister bei
Festpreisprojekten vorlegen. Zudem kann die „When it‟s done“-Mentalität beim
Kunden auf Widerstand stoßen, genauso wie der doppelte Aufwand durch das
Programmieren in Paaren. Entwickler sind zudem selten kommunikationsstark,
außergewöhnlich teamorientiert, kundentauglich, offen für Kritik und ohne
Besitzdenken an ihrem Werk. Entwicklerteams sind zudem selten gleich gut
54

qualifiziert, sodass Paar-Programmierung nicht auf gleicher Augenhöhe stattfinden


und das Refactoring nicht durch einen anderen Entwickler erfolgen kann.

2.2.3.6 Feature Driven Development


Feature Driven Development wurde von Jeff DeLuca im Rahmen eines großen
Bankenprojekts in Singapur entwickelt. In diesem Projekt wurde auch das
Modellieren in Java in Farbe mit UML (Java Modeling in Color with UML)
entwickelt (Palmer, et al., 2002 S. xxi) entwickelt. Beide Techniken können
zusammen angewendet werden, bedingen aber nicht einander. Im Kern versucht
Feature Driven Development, aus komplexen UML-Modellen gekapselte Funktionen
(Features) aus Kundensicht zu identifizieren, die dann anschließend priorisiert
realisiert werden. Aufgrund der geringen Formalität gilt Feature Driven
Development als agile Entwicklungsmethode und nutzt als Vorgehensmodell das
sequenzielle Vorgehen und die Iteration. Das Projekt kann dabei aber auch
inkrementell entwickelt werden.

Die Softwareentwicklung wird bei Feature Driven Development anhand eines


Feature-Plans organisiert. Den gesamten Prozess überwacht der Chefarchitekt, der
die Aufgabe hat, den Überblick über die Gesamtarchitektur und fachlichen
Kernmodelle zu behalten. Bei größeren Teams werden die einzelnen
Entwicklerteams von jeweils mehreren Chefprogrammierern angeleitet (Wolf, et al.,
2005 S. 137).

Zur Beschreibung von Features gibt es Namenskonvention. Es gibt drei Arten von
Features. Die kleinste Einheit ist ein Feature. Mehrere Features können in ein
Feature Set gruppiert werden. Die nächste Abstraktionsstufe über dem Feature Set ist
ein Major Feature Set. Ein Feature darf maximal zwei Wochen für seine
Realisierung benötigen (Gyger, 2003 S. 4-5).

Namenkonvention eines Features (Schritte)


<action>the<result><by|for|of|to>a(n)<object>

Zum Beispiel
 Calculate the total of Sale
 Asses the fullfillment timelines of a sale
55

 Calculate the total purchases by a customer

Namenskonvention eines Feature Sets (Geschäftstätigkeit)


<action><-ing>a(n)<object>

Zum Beispiel
 Making a product sale

Namenskonvention eines Major Feature Sets (Fachgebiet)


<object>management

Zum Beispiel
 product-sales management

Der Prozess unterteilt sich in fünf Prozessstufen:

1. Entwickeln eines Gesamtmodells (alle Projektbeteiligten)


2. Erstellen einer Feature-Liste (Chefprogrammierer)
3. Planung pro Feature (Projektleiter, Entwicklungsleiter, Chefprogrammierer)
4. Entwurf pro Feature (Chefprogrammierer, Entwickler)
5. Implementierung pro Feature (Entwickler)

Die ersten drei laufen sequenziell ab, die letzten beiden werden pro Feature
wiederholt. Jeder Prozessschritt wird nach dem ETVX-Template beschrieben: Entry,
Task, Verification und Exit.18

18
Entry: Vorbedingungen des Prozesses; Tasks: Liste der Aufgaben, die im Prozess ausgeführt werden;
Verification: Beschreibung der Mittel wie die Erfüllung des Prozesses ermittelt werden kann; Exit:
Schlussbedingungen und Output.
56

Abbildung 12: The five processes of FDD with their outputs (Palmer, et al., 2002 S. 58)

Im ersten Prozessschritt definieren Fachexperten und Entwickler unter der Leitung


des Chefarchitekten den Inhalt und Umfang des Systems. Der Kunde benötigt in
diesem Schritt nur eine grobe Vorstellung davon was das System leisten soll. Das
Gesamtmodell wird in kleinen Gruppen über Teilmodelle erstellt. Dies geschieht
über eine objektorientierte Modellierungstechnik. Die Teilmodelle werden
anschließend diskutiert und zu einem Gesamtmodell zusammengefügt. Im zweiten
Prozessschritt transformieren die Chefprogrammierer die Methoden der
Klassendiagramme in Features gemäß der Namenskonvention und gruppieren sie in
Fachgebiete, Geschäftstätigkeit und Schritte. Die Priorisierung der Features erfolgt
danach, ob ein Feature die Kundenzufriedenheit erhöht oder erniedrigt. Es gibt vier
Prioritätsstufen: „must have“, „nice to have“, „add it if we can“ und „future“ (Gyger,
2003 S. 7). Ein Feature darf den Implementierungszeitraum von zwei Wochen nicht
überschreiten. Ist ein Feature zu umfangreich, muss es in Teil-Features aufgebrochen
werden. Im dritten Prozessschritt planen Projektleiter, Entwicklungsleiter und
Chefprogrammierer die Reihenfolge sowie das Enddatum der „Majore Feature Sets“.
Die Reihenfolge der Features wird auf Basis der Abhängigkeiten zwischen den
Features, Auslastung der Entwicklerteams und Komplexität des Features festgelegt.
Jedes Feature Set bekommt einen Chefprogrammierer als Besitzer zugeordnet. Jede
Klasse wird einem klassenverantwortlichen Entwickler (Class Owner) zugewiesen.
Der vierte und fünfte Prozessschritt wird mehrmals, pro Feature einmal, ausgeführt.
Im vierten Prozessschritt bestimmt der Chefprogrammierer, welche Klassen
voraussichtlich für die Realisierung des Features betroffen sind und bildet mit den
57

Klassenverantwortlichen ein „Feature-Team“. Die Feature-Teams können sich in


jeder Iteration verändern. Ein Klassenverantwortlicher kann auch in mehreren
Feature-Teams Mitglied sein. Die Entwickler erstellen ein oder mehrere
Sequenzdiagramme, und die Chefprogrammierer verfeinern die Klassenmodelle auf
Basis der Sequenzdiagramme. Danach werden erste Klassen und Methodenrümpfe
entwickelt. Bei fachlichen Unklarheiten werden Fachexperten aus dem ersten
Prozessschritt hinzugezogen. Im fünften Prozessschritt werden die im vierten Schritt
vorbereiteten Features implementiert. Bei der Entwicklung werden Unit Tests und
Code Inspektionen zur Qualitätssicherung eingesetzt (Roden, 2010), (Wolf, et al.,
2005 S. 137-139), (Gyger, 2003), (De Luca).

Im Gegensatz zu extreme Programming können bei Feature Driven Development


heterogen qualifizierte Entwickler innerhalb eines Teams arbeiten. Die
Wahrscheinlichkeit ist hoch, dass erfahrende Entwickler in Feature Driven
Development Chefprogrammierer sind. Feature Driven Development gibt keine
Praktiken vor, wie die Entwicklungsabteilung organisiert wird, und kann sich hier bei
den XP-Programmierkonzepten bedienen. Allerdings widerspricht die „Individual
Class Ownership“ dem „Collective Code Ownership”. Durch die Aufteilung des
Projekts in Features ist eine verteilte Entwicklung innerhalb von heterogenen
Projektteams sehr gut möglich. Dadurch können Entwicklerteams gut skaliert
werden. Es erlaubt durch die interne Hierarchie, die Feature-Teams klein zu halten,
auch wenn das Projekt groß ist. Zudem ist Feature Driven Development als agile
Entwicklungsmethode gut für Projekte geeignet die relativ stabile Anforderungen im
Projekt haben. Allerdings kann „Feature Driven Development“ nicht eingesetzt
werden, wenn ein Projekt nur technische Verbesserungen als Projektziel vorsieht,
weil diese nicht als Features beschrieben werden können. Feature Driven
Development eignet sich für die Softwareproduktentwicklung besser als für
Individualsoftware, weil innerhalb einer Produktentwicklung die Features relativ früh
festgelegt werden (Khramtchenko, 2004 S. 18-19), (Wolf, et al., 2005 S. 138-139),
(Gyger, 2003 S. 11), (Roden, 2010 S. 48-49).
58

2.2.3.7 Scrum
Scrum ist ein agiler Ansatz zum Management von Softwareentwicklungsprojekten
und wurde von Jeff Sutherland, Ken Schwaber und Mike Beedle in den 1990er
Jahren entwickelt. Scrum basiert auf den Ideen des „Lean Production“ von Nonaka
und Takeuchi. Kernidee des „Lean Production“ ist das selbstorganisierende Team,
das aus Spezialisten besteht und kooperativ die Entwicklung vorantreibt (Ludewig, et
al., 2010 S. 228-229), (Gloger, 2008 S. 10-11). Es verantwortet dabei kollektiv den
Erfolg oder Misserfolg des Projekts. Scrum ist ein rollenbasierter, iterativer und
inkrementeller Prozess und beschränkt sich auf das Management agiler Projekt.
(Ludewig, et al., 2010 S. 229). Wie in Feature Driven Development schreibt Scrum
keine Programmierkonzepte vor und bedient sich deshalb oft der Konzepte/Praktiken
des Extreme Programmings.

Scrum unterteilt sich in sechs Rollen, sechs Meetings und neun Artefakte, die
innerhalb des iterativen Prozesses eingesetzt werden (Gloger, 2008 S. 14-17). Der
Product Owner, das Team und der Scrum Master sind wesentliche Rollen, die für den
Erfolg eines Scrum-Projekts verantwortlich sind (Ludewig, et al., 2010 S. 229-230).

Das Produkt entsteht in Scrum inkrementell. Bei jedem Inkrement wird der Scrum-
Prozess erneut durchlaufen. Das Prozessmodell beginnt mit der strategischen
Planungsphase, bevor die iterative Entwicklung im Scrum Flow erfolgt. Product
Owner ist der, der die Produktidee hat und diese soweit ausarbeitet, bis daraus eine
Produktvision wird. Die Produktfunktionen werden entweder vom Produkt Owner
oder mit den Teammitgliedern zusammen erarbeitet. Die einzelnen Funktionalitäten
sind sogenannte Backlog Items. Alle Backlog Items werden in eine Liste
geschrieben, dem Product Backlog. Der Product Owner priorisiert die Backlog Items
im Product Backlog anhand des „finanziellen Gewinns“ der Funktion. Jedes Backlog
Item wird im Umfang von den Teammitgliedern geschätzt, welche die Items in
Usable Software wandeln. Die Schätzung erfolgt in Story Points, die später in
Personentage umgerechnet werden. Die Schätzung für den Umfang (Story Points)
des gesamten Product Backlog wird dem Produkt Owner mitgeteilt. Aus dem
Product Backlog wird ein Release-Plan erstellt, der festlegt, in wie vielen zeitlich
abgegrenzten Intervallen das Projekt abgearbeitet wird – den sogenannten Sprints.
59

Ein Sprint sollte nicht länger als 30 Tage dauern. Am Ende jedes Sprints muss ein
ausführbares und auslieferbares Produktinkrement vorliegen (Usable Software). Hier
wird in Explorations-, Standard- und Releasesprints unterschieden. Explorations-
sprints dienen dazu, problematische oder riskante Bereiche zu untersuchen und
Lösungen zu erproben (ähnlich dem explorativen Prototyping). Standardsprints sind
Produktinkremente, die nicht unbedingt ausgeliefert oder freigeben werden. Am
Ende eines Releasesprints entsteht immer ein auslieferbares Produktinkrement
(Ludewig, et al., 2010 S. 232). Jeder Sprint beginnt mit einer taktischen Planung. Das
erste Planungsmeeting (Sprint Planning Meeting 1) findet mit dem Product Owner,
Team, Management und Anwender statt und ist vergleichbar mit einem
Briefing/Anforderungsmeeting. Hier wird besprochen, wie viele und welche Backlog
Items das Team als Sprint Goal am Ende des Sprints zu liefern hat. Die Summe der
zu liefernden Backlog Items wird in einem Selected Product Backlog festgehalten.
Das Selected Product Backlog ist das gemeinsame Versprechen aller Beteiligten,
welche Funktionen in dem Sprint geliefert werden sollen. In dem darauf folgenden
Meeting (Sprint Planning Meeting 2) bespricht das Realisationsteam, wie die
Backlog Items aus dem Selected Product Backlog realisiert werden sollen. Ergebnis
des Meetings ist eine Liste der Aufgaben, das Sprint Backlog. Das Team beginnt mit
der Realisierung des Produkts. Scrum definiert nicht, wie die Entwicklung
organisiert wird. Stattdessen sollen die Entwickler sich selbst eine Organisationsform
geben, die ihnen hilft, das Sprint Goal zu erreichen. Die Entwickler stimmen ihre
Aufgaben täglich mit dem Scrum Master und dem Product Owner in einem kurzen
Meeting, dem Daily Scrum ab. In dem Meeting wird besprochen, was der einzelne
Entwickler seit dem letzten Meeting geschafft hat, was er bis zum nächsten Meeting
erreichen möchte und welche Hindernisse er bei der Realisierung erwartet. Zudem
bestimmen die Entwickler in dem Daily Scrum selbst, welche Aufgaben sie von der
Liste im Sprint Backlog abarbeiten wollen. Im Sprint Backlog wird der tägliche
Projektfortschritt von den Entwicklern in einem Feature Burndown Chart
festgehalten. Feature Burndown Charts zeigen eine Prognose an, wann alle Backlog
Items im Sprint Backlog abgearbeitet sind. Wird das Projekt früher als geplant fertig,
wählt der Product Owner zusätzlich Backlog Items aus dem Product Backlog aus.
Wird das Projekt später als geplant fertig, werden noch zu erstellende niedrig
60

priorisierte Backlog Items aus dem Sprint Backlog gestrichen (Ludewig, et al., 2010
S. 231). Während des Sprints, werden in Estimation Meetings mit dem Product
Owner die nächsten Sprints vorbereitet und der Release-Plan aktualisiert. Am Ende
eines Sprints werden die fertiggestellten Funktionen in einem Sprint Review
präsentiert und zeigen den Fortschritt der Produktentwicklung auf Basis von
benutzbarer Software an. Zudem wird ein Sprint Endbericht erstellt, in dem
festgehalten ist, welche Backlog Items aus dem Sprint Backlog realisiert wurden und
welche nicht. Nach dem Sprint Review führen die Teammitglieder eine Sprint
Retroperspektive durch, in der die eigenen Arbeitsprozesse optimiert und hinterfragt
werden sollen (Gloger, 2008 S. 11-14), (Wolf, et al., 2005 S. 133-136), (Ludewig, et
al., 2010 S. 228-232).

Die optimale Teamgröße für ein Scrum-Projekt besteht aus fünf bis zehn Personen,
die wie beim Extreme Programming am selben Ort arbeiten sollten. Scrum stellt, wie
oft dargestellt, keinen Management-Rahmen für Extreme Programming bereit.
Extreme Programming besitzt genug eigene Konkurrenztechniken, wie zum Beispiel
das Planungsspiel und die Standup-Meetings. Allerdings kann Scrum genutzt
werden, wenn Extreme-Programming-Entwickler in ihrem Arbeitsablauf zu sehr
einschränkt werden. Mit Scrum kann sehr schnell Erfolg in Projekten herbeigeführt
werden, die ständig Schwierigkeiten bei der Termintreue haben. In der Literatur wird
dabei von 30 bis 60 Tagen gesprochen (Wolf, et al., 2005 S. 136). Im Gegensatz zu
anderen agilen Prozessmodellen kann deshalb Scrum als Quick Win eingesetzt
werden und ggf. später durch ein anderes ersetzt werden.

2.2.3.8 Einsatz der Prozessmodelle


Jedes Prozessmodell hat seine Schwerpunkte und verfolgt eine bestimmte
Philosophie. Das Phasenmodell bietet sich bei einem sehr kaufmännisch getriebenen
Projekt an, in dem der Vertrag auf Basis von Meilensteinen erfolgt und der
Auftraggeber wenig Erfahrung mit Softwareprojekten besitzt. Das Phasenmodell lebt
von Zwischen- und Endabnahmen. Aus diesem Grund muss vor der Beauftragung
entweder eine hinreichend genaue Anforderung vorliegen oder sie muss als
Projektbestandteil erstellt werden. Das Timeboxing-Modell ist relevant, wenn ein
Projekt komplett inkrementell in einem großen, räumlich getrennten Projektteam
61

entwickelt werden muss und auf einer stabilen Architektur aufsetzt. Für Software-
oder Hardwareprojekte, die sehr komplex sowie umfangreich sind und in einem sehr
bürokratischen (behördlichen) Umfeld realisiert werden müssen, bietet sich das V-
Modell XT an. Das Gleiche trifft bei Softwareprojekten für RUP im
Unternehmensumfeld zu. RUP ist zwar flexibler als das V-Modell XT, besitzt aber
trotzdem eine gewisse Formalität und Komplexität im Prozessmodell und muss in
Form einer Lizenz erworben werden. In großen Organisationen kann RUP durch die
gute Dokumentation und Vorlagen den Projektbeteiligten Arbeit abnehmen. Feature
Driven Development kann bei stark design-/modellgetriebenen Projekten eingesetzt
werden sowie bei Projekten, in denen ein Produkt realisiert werden soll. Durch die
Aufteilung in Klassenverantwortliche kann Feature Driven Development auch bei
großen Entwicklerteams eingesetzt werden. Bei Extreme Programming und Scrum
muss der Kunde maßgeblich mitspielen und selbst beide Prozessmodelle kennen.
Insgesamt können beide grundsätzlich für jede Art von Projekt empfohlen werden.
Beide kommen ausgezeichnet mit Projekten zurecht, bei denen die Anforderung erst
im Projekt entsteht. Extreme Programming beinhaltet im Gegensatz zu Scrum
erfolgreich eingesetzte Programmierkonzepte, derer sich auch gerne andere
Prozessmodelle bedienen. Welches der beiden eingesetzt werden soll, muss
bestenfalls von der Entwicklungsabteilung entschieden werden. Aus
Projektmanagementsicht sind beide im Kern sehr ähnlich.

2.2.4 Kritische Würdigung


Beim Studieren der Literatur ist besonders aufgefallen, dass die Autoren der
Prozessmodelle keine Varianz der Modelle dem Anwender zugestehen möchten. Um
dies zu erreichen, wird mit Angst gearbeitet. Projekte sind in jedem Fall zum
Scheitern verurteilt, wenn vom gewählten Prozessmodell abgewichen wird.
Trotzdem hat jedes aufgeführte Vorgehens- und Prozessmodell seine Berechtigung.
Das Modell „Code and Fix“ sollte dabei nicht ausgeschlossen werden. Auch wenn es
vom Software-Engineering insgesamt abgelehnt wird, kann es in einem bestimmten
Projektkontext Sinn machen.

Vorgehens- und Prozessmodelle sind abhängig von ihrem Umfeld, in dem sie
eingesetzt werden, und nicht nur vom Projekt, so viel steht fest. Obwohl eigentlich
62

das Projekt bestimmen müsste, mit welchen Modell es umgesetzt werden sollte.
Allerdings ist dies in Matrix-Projektmanagementorganisationen sehr schwierig
umzusetzen. Ist eine Person in mehreren Projekten aktiv, besitzt diese beim Einsatz
verschiedener Modelle unterschiedliche Rollen in der Organisation und muss im
Extremfall mehrmals täglich den Arbeitsablauf und die Denkweise ändern. Aus
diesem Grund werden sehr wahrscheinlich Prozessmodelle einheitlich auf eine ganze
Projektorganisation angewendet. Die Betrachtung pro Projekt ist damit theoretisch
richtig, praktisch aber kaum durchführbar. Deshalb ist es auch nicht verwunderlich,
dass viele Projekte scheitern.

In der Basisliteratur wurde während der Recherche dieser Arbeit keine verbindliche
Aufstellung gefunden, für welches Projekt welches Vorgehens- und Prozessmodell
sinnvoll ist. Eine einheitliche Auflistung, in der eine Projektklassifizierung mit dem
empfohlenen Modell erfolgt, fehlt. Aus Sicht des Autors unverständlich, da eine
Klassifikation von Projektarten im Industrieumfeld heutzutage möglich ist. Deshalb
wurde auch jeweils am Ende der Kapitel „Vorgehensmodelle“ und „Prozessmodelle“
der mögliche Einsatz nur kurz aufgezeigt, weil es nicht den Kern dieser Arbeit
darstellt.

Besonders zu erwähnen ist das Timeboxing-Modell von Jalote. Nicht wegen des
Parallelisierens der Arbeitspakete, sondern wegen der Mentalität, dass Zeit ein
19
wesentlicher Hive-Faktor eines Prozessmodells sein kann. Alle anderen
Prozessmodelle machen den Prozessablauf unabhängig von der verfügbaren Zeit.
Scrum versucht dies zwar auf Basis des „Feature Burndown Charts“ durch das
Streichen von Backlog Items zu umgehen, verpflichtet sich in letzter Konsequenz
aber nicht darauf.

In der Literatur wird inkrementelles und iteratives Vorgehen von verschiedenen


Autoren nicht klar definiert. Jalote beschreibt zum Beispiel das Timeboxing-Modell
als iterativ, dabei wird Software darin in Inkrementen entwickelt. Iteration und
inkrementelles Entwickeln ist im konkreten Fall nicht immer klar abzugrenzen.

19
Hive-Faktoren sind bei der Spiele-Entwicklung globale Größen, wie zum Beispiel der Faktor Zeit. Hive als
Begriff ist eine Analogie zum kollektiven Bewusstsein (Hive Mind) der Borg.
63

Dennoch sollte es in der Literatur übergreifend möglich sein, ein gemeinsames


Verständnis für beide Begriffe und das damit beschriebene Vorgehen zu entwickeln.

Insgesamt kann aber festgestellt werden, dass die agile Bewegung einen richtigen
und wichtigen Schritt in die richtige Richtung gemacht hat. Die Modelle lösen sich
von der „industriellen Revolution“ und versuchen, die „essential difficulties“ im
Prozess nicht zu ignorieren, sondern als Fakt zu akzeptieren. Allerdings darf auch
hier nicht vergessen werden, dass die agile Bewegung auch erst durch den
technologischen Fortschritt, was die Werkzeuge betrifft, möglich wurde
(Miniaturisierung, Netzwerke, Versionierungssysteme …).

2.3 Softwarequalität
Software-Engineering befasst sich sowohl mit der Produktqualität als auch mit der
Projektqualität, in der das Produkt hergestellt wird. Ein Prozess kann verschiedenen
Projekten zugrundeliegen. Deshalb wird Prozessqualität oft mit der Projektqualität
gleichgesetzt. Eine hohe Prozessqualität ist keine Garantie für hohe Projektqualität,
sondern schafft nur günstige Voraussetzungen.

Abbildung 13: Bedeutung verschiedener Qualitätsaspekte der Zeit (Ludewig, et al., 2010 S. 67)

Die Produktqualität kann nach Ludewig et al. operationalisiert werden in Gebrauchs-


und Wartungsqualität. Die Gebrauchsqualität beschreibt die Sicht des Benutzers,
während die Wartungsqualität die Sicht des Entwicklers einnimmt. Wartungsqualität
betrifft den Benutzer auch dann, wenn es sich um „Shrinkware“ handelt, weil das
64

Produkt durch bessere Wartungsfähigkeit langfristig besser wird (Ludewig, et al.,


2010 S. 66-67).

Abbildung 14: Qualitätsbaum von Ludewig, et al. in Anlehnung an Boehm, Brown und Liptow

Für die Taxonomien von Softwarequalität gibt es verschiedene Modelle, die sich im
Wesentlichem bezüglich Detailgrad, Kategorisierung und Sichtweisen unterscheiden.
McCall nennt insgesamt elf Attribute und ordnet sie drei Gruppen zu: Product
Operation (Benutzerungsqualität), Product Revision (Wartungsfähigkeit) und
Product Transition (Tranformationsqualität). Die DIN ISO 9126 ordnet in der
internen-/externen Qualität die Unterattribute einem der sechs Hauptattribute zu und
besitzt vier Attribute für Benutzungsqualität. Dabei betrachtet sie nur die
Produktsicht und nicht die Prozesssicht (Van Vliet, 2008 S. 124-130). Ludewig et al.,
in Anlehnung an Boehm, Brown und Lipow, unterteilen den Qualitätsbegriff in einen
65

Qualitätsbaum und unterscheiden in Produkt- und Prozessqualität (Ludewig, et al.,


2010 S. 68).

Unabhängig von der Wahl einer bestimmten Taxonomie ist das differenzierte und
priorisierte Betrachten von Qualitätsattributen in einem Softwareprojekt
ausschlaggebend für die Qualität. Durch die konkurrierenden Attribute kann der
Fokus auf ein unwichtiges Attribut andere wichtigere negativ beeinflussen. Für einen
Buttom-up-Ansatz als Mittel zur Priorisierung ist der Qualitätsbaum deshalb am
besten geeignet (Ludewig, et al., 2010 S. 68).

2.3.1 Produktqualität
Produktqualität wird über Softwarequalitätssicherung erreicht. Betrachtet man die
IEEE-Definition zur Softwarequalitätssicherung (IEEE, 1990 S. 60), stellt man fest,
dass sie noch Prozessbewertung beinhaltet. Diese ist allerdings zu einem von der
Qualitätssicherung getrennten Thema geworden (Ludewig, et al., 2010 S. 269).

2.3.1.1 Softwarequalitätssicherung
Die Softwarequalitätssicherung hat das Ziel, das Vertrauen in eine Software zu
erhöhen. Um Vertrauen in ein Produkt zu schaffen, kann man es gemäß der IEEE-
Definition von Softwarequalitätssicherung gut machen oder nachweisen, dass es gut
ist (IEEE, 1990 S. 60). Beides zählt zur Qualitätssicherung.
66

Abbildung 15: Gliederung der Softwarequalitätssicherung nach Ludewig, et al. (2010)

Softwarequalitätssicherung kann in drei übergeordnete Teilbereiche unterteilt


werden. Erstens: Organisatorische Maßnahmen die darauf abzielen, die Entwicklung
und Qualitätssicherung systematisch durchzuführen. Zweitens: Konstruktive
Maßnahmen, mit denen Softwaremängel durch den Einsatz geeigneter Methoden,
Sprachen und Werkzeuge vermieden werden sollen. Zu diesen Maßnahmen gehört
auch die Verwendung eines geeigneten Prozessmodells. Drittens: Analytische
Maßnahmen, unter die alle Arten der Softwareprüfung fallen. Letzeres wird oft mit
Softwarequalitätssicherung gleichgesetzt und wird in dieser Arbeit näher betrachtet
(Ludewig, et al., 2010 S. 272).

2.3.1.1.1 Prüfungen (analytische Maßnahmen)


Prüfungen sollen feststellen, ob die Software aus Sicht der Anforderungen fehlerfrei
ist und keinen Mangel aufweist. Dabei wird eine systematische Suche nach Fehler
und Mängeln in der Software durchgeführt. Ein Fehler liegt vor, wenn die Software
eine Anforderung, die an das Produkt gestellt wird, nicht erfüllt. Im Gegensatz dazu
liegt ein Mangel vor, wenn die Anforderung den beabsichtigten oder festgelegten
Gebrauch nicht erfüllt. Unterscheidung zwischen Fehler und Mangel einer Software
liegt demnach in der Perspektive. Wenn ein Fehler die Verwendung der Software
nicht beeinträchtigt, liegt kein Mangel vor (DIN EN ISO 8402: 08.95). Prüfungen
67

müssen zudem im Arbeitsablauf von der Korrektur getrennt werden. Beim Finden
eines Fehlers wird dabei die Prüfung nicht sofort abgebrochen, um diesen zu
beheben. Die Korrektur der Fehler erfolgt also erst, nachdem die Prüfung der
Software vollständig abgeschlossen wurde (Ludewig, et al., 2010 S. 280).

Boehm unterscheidet zudem zwei Arten von Prüfungen. Erstens: Verifikation


kontrolliert, ob ein Verfahrensschritt richtig ausgeführt wurde. Dies trifft
insbesondere dann zu, wenn über formale Techniken bewiesen wird, dass ein
Programm die Spezifikation korrekt implementiert hat. Zweitens: Bei der
Validierung wird überprüft, ob das Ergebnis den Erwartungen des Kunden
entspricht. Die Validierung ist allerdings erst dann möglich, wenn ein Teilprodukt
oder Prototyp fertig ist, vorher kann nur verifiziert werden (Boehm, 1979 S. 3).

Die Möglichkeiten, eine Software zu prüfen, kann entweder mit oder ohne Hilfe
eines Rechners erfolgen. Die Prüfung ohne Rechner wird auch als nicht mechanische
Prüfung bezeichnet. Dabei werden die Arbeitsergebnisse von einem Experten
geprüft. Verfahren, die in Praxis eingesetzt werden, sind Durchsicht, Inspektion
(Review) oder Walktrough. Nicht mechanische Prüfungen sind der einfachste und
billigste Weg, Prüfverfahren einzuführen, und helfen dem Team, Wissen zu teilen
und ein gemeinsames Qualitätsverständnis zu erhalten. Die Prüfung mit Rechner
wird auch als mechanische Prüfung bezeichnet. Dazu zählen alle Testverfahren
(ausführen) sowie die statische Analyse (Ludewig, et al., 2010 S. 279-280).

Liggesmeyer (Liggesmeyer, 2009) unterteilt insgesamt in statische und dynamische


Prüfverfahren. Die statischen entsprechen der nicht mechanischen Prüfung, die
dynamischen der mechanischen Prüfung von Ludewig et al. In dieser Arbeit wird die
die Sichtweise von Ludewig & Lichter vertreten, weil sie besser operationalisiert ist.
Die dynamsichen Tests sind bei Liggesmeyer jedoch umfangreicher und detaillierter
dargestellt.
68

2.3.1.1.2 Nicht mechanische Prüfungen


Es gibt eine Vielzahl von Verfahren um Software zu inspizieren. Aus diesem Grund
werden hier die in der Praxis oft eingesetzten fünf Softwareinspektionen dargestellt
(Ludewig, et al., 2010 S. 281-294).

Bei der Durchsicht/Schreibtischtest führt der Entwickler die Prüfung seines


eigenen Quellcodes durch. Die Durchsicht wird durch Refactoring begünstigt.
Prinzipiell sollte jeder Autor einen Prüfling erst dann weitergeben, wenn er ihn nicht
selbst kritisch betrachtet hat.

Der Entwickler gibt bei der Stellungnahme den Quellcode einem oder mehreren
Kollegen zum Lesen und wertet deren Feedback aus, um den Prüfling zu
überarbeiten. Bei dieser Prüfung ist der Organisationsaufwand gering, erfordert aber,
dass der Entwickler die Fähigkeit eines Moderators besitzt und die Anmerkungen der
Gutachter nicht ignoriert. Paar-Programmierung nutzt das Prinzip der Stellungnahme
direkt bei der Entwicklung.

Beim Structured Walkthrough stellt der Entwickler sein Arbeitsergebnis einer


kleinen Gruppe von bis zu fünf Personen vor und führt sie durch das Dokument. Die
Gutachter versuchen, Probleme zu identifizieren, indem sie spontan oder vorbereitete
Fragen stellen.

Beim Review wird Quellcode, ein Prototyp oder ein Produkt einer bestimmten
Anzahl von Gutachtern vorgestellt. Die Gutachter können Manager, Kunden,
Benutzer oder Dritte sein. Während der Reviewsitzungen kann der Prüfling von den
Gutachtern kommentiert werden oder es wird auf mögliche Fehler hingewiesen. Je
nach Ausgang einer Reviewsitzung wird entscheiden, ob die nächste Phase oder
Iteration angestoßen wird. Reviews können in Anforderungsreview, vorläufiger
Entwurfsreview, kritischer Entwurfsreview, technischer Review und
Abnahmetestreview unterschieden werden. Im Gegensatz zum Structured
Walkthrough ist die Personenanzahl des Teams im Review umfangreicher, die
beteiligten Akteure definiert und der Ablauf formalisiert.
69

Die „Design and Code Inspection“ ist identisch mit dem technischen Review und
unterscheidet sich im Wesentlichen darin, dass die Gutachter dem Moderator ihre
Notizen vor der Sitzung geben, dass es in der Sitzung einen Vorleser gibt, der den
Prüfling vorließt, sowie anschließend die Befunde vorgelesen werden und der
Prüfungsprozess mit einer Einführungssitzung beginnt. Die Design and Code
Inspection gilt als die umfangreichte Review-Methode.

2.3.1.1.3 Mechanische Prüfungen


Bei der mechanischen Prüfung werden in dieser Arbeit nur die dynamischen
Maßnahmen betrachtet, der Programmtest. Diese Arbeit hat nur den Anspruch, einen
Überblick zu dem Thema zu gewähren. Eine ausführliche Betrachtung findet man in
Spillner und Linz (2005) oder in Liggesmeyer (2009).

2.3.1.1.3.1 Begriff und Abgrenzung des Tests


Die Definition, was Testen bedeutet, kann je nach Perspektive unterschiedlich
ausgelegt werden 20. In dieser Arbeit wird Myers Definition vertreten: „Testen ist die
Ausführung eines Programms mit dem Ziel Fehler zu entdecken.“ (Myers, 2004 S. 5).
Wobei hierzu ergänzt werden muss, dass die Ausführung des Programms auch
mehrfach erfolgen kann. Testen ist demnach nicht erstens die Inspektion eines
Programms, zweitens die Vorführung eines Programms, drittens die Analyse eines
Programms durch Softwarewerkzeuge und viertens die Untersuchung des
Programms mit einem Debugger. Bei einem systematischen Test müssen die
Randbedingungen definiert oder erfasst sein, die Eingaben systematisch ausgewählt
worden sein und die Ergebnisse dokumentiert und nach Kriterien beurteilt werden,
die vor dem Test festgelegt wurden. Es liegt ein Fehler vor, wenn beim Soll-Ist-
Vergleich eine Abweichung festgestellt wurde. Ist ein Fehler entdeckt worden, so ist
ein Test erfolgreich. Ist keiner entdeckt worden, dann war der Test erfolglos. Die
Situation des Einsatzes sollte beim Test so simuliert werden, dass ein erfolgreicher
Test auch auf einen erfolgreichen Einsatz schließt (Ludewig, et al., 2010 S. 480-481).

20
Vergleiche hierzu Myers Herleitung zu seiner Definition. (Myers, 2004 S. 4-5)
70

2.3.1.1.3.2 Klassifikationen von Tests


Eine Klassifikation von Test kann einmal im Allgemeinen und im speziellen
erfolgen. Bei der allgemeinen Klassifikation kann in zwei grundsätzliche Richtungen
unterschieden werden, erstens nach dem Umfang der Angemessenheit und zweitens
nach Herkunft der Informationen. Beim Umfang der Angemessenheit kann in drei
Typen unterscheiden werden. Erstens: Das Coverage-Based Testing spezifiziert, in
welchen Umfang das Produkt getestet werden soll. Zweitens: Beim Fault-Based
Testing wird gezeigt, dass durch Testdaten vordefinierte Fehler nicht mehr
auftauchen. Und drittens: Beim Error-Based Testing wird nach typischen
fehleranfälligen Punkten gesucht (Van Vliet, 2008 S. 409). Bei Herkunft der
Information unterscheidet man in zwei Arten. Erstens: Wenn die Testfälle anhand
der Spezifikation ausgewählt werden, spricht man von einem Black-Box-Test oder
auch Funktionstests. Bei einem Black-Box-Test wird das Programm so betrachtet, als
ob man nichts über seine innere Beschaffenheit wüsste, sondern es wird nur so
betrachtet, wie es die Spezifikation vorgibt. Zweitens: Werden innere Strukturen
oder Aufzeichnungen von früheren Programmabläufen bei der Wahl der Testfälle
berücksichtigt, spricht man von einem Glass-Box-Test oder Strukturtest. Dabei wird
versucht, auf den Quellcode bezogene Deckungen zu erreichen (Coverage-Based
Testing), wie zum Beispiel, dass 80 % der Anweisungen im Programm mindestens
einmal ausgeführt wurden (Van Vliet, 2008 S. 409), (Ludewig, et al., 2010 S. 489).

Test können neben den beiden allgemeinen übergeordneten Arten im Speziellen in


vier Klassifikationen eingeteilt werden: Aufwand, Komplexität, Eigenschaften und
Rollen.

Die Tests nach Aufwand für die Vorbereitung und Archivierung lassen sich in drei
Typen einteilen. Erstens: Der Laufversuch, bei dem der Entwickler versucht, das
Programm zu übersetzten, zu binden, zu starten und in ganzer Länge auszuführen.
Zweitens: Beim Wegwerftest werden vom Gutachter spontan nach kurzer
Überlegung Daten eingegeben und das Resultat überprüft. Drittens: Der bereits
beschriebene systematische Test.

Betrachtet man die Komplexität des Prüflings kann in vier Testarten unterschieden
werden. Erstens: Der Einzeltest, auch als „Unit Test“ bezeichnet, bei dem einzelne
71

überschaubare Programmeinheiten getestet werden (Funktionen, Unterprogramme


oder Klassen). Zweitens: Beim Modultest werden mehrere
Programmeinheiten/Komponenten getestet. Drittens: Im Integrationstest wird
geprüft, ob Fehler in den Schnittstellen und der Kommunikation zwischen
Programmeinheiten vorliegen. Viertens: Der Systemtest, in dem
Kommunikationsprobleme zwischen Subsystemen aufgedeckt werden können.
Zudem kann geprüft werden, ob alle Funktionalitäten implementiert wurden.

Die Klassifikation nach der getesteten Eigenschaft kann in sechs Testtypen


unterschienden werden. Erstens: Beim Funktionstest werden die Funktionen auf
Basis der Anforderung/Spezifikation überprüft. Zweitens: Beim Installationstest
muss die Software auf Basis der Anleitungen und gemäß der beschriebenen
Systemvoraussetzungen installiert und in Betrieb genommen werden können.
Drittens: Der Wiederinbetriebnahmetest überprüft, ob nach unterbrochenem Betrieb
die Software wieder in Betrieb genommen werden kann. Viertens: Beim
Verfügbarkeitstest wird geprüft, ob die Software ohne Störungen über eine
festgelegte Dauer läuft. Fünftest: Beim Last- und Stresstest wird getestet, ob das
System sich unter hoher, unter höchster Belastung oder Überlastung so verhält, wie
es gefordert war. Sechstens: Der Regressionstest prüft, ob ein Programm
nach/aufgrund einer Korrektur oder Veränderung keine neuen Fehler enthält.

Betrachtet man den Test nach den beteiligten Rollen, wird erstens in Alpha- und
Beta Test unterschieden. Beim Alpha-Test hat das Produkt noch wesentliche Mängel
und wird beim Hersteller getestet. Im Gegensatz dazu steht der Beta-Test, der
speziellen Kunden zum Testen zur Verfügung gestellt wird. Zweites: Beim
Akzeptanz oder Abnahmetest wird eine Vorführung der Software beim Kunden
durchgeführt, bei der geprüft wird, ob alle Anforderungen an die Software erfüllt
wurden (Ludewig, et al., 2010 S. 489-492).

2.3.1.1.4 Vor- und Nachteile von Prüfungen


Prüfungen im Allgemeinen liefern per se eine einfache Anforderung, was die
Qualitätskriterien eines Produkts betrifft. Prüfungen erzwingen deshalb, bei einer
unvollständigen Spezifikation, Entwicklern konkrete Qualitätsanforderungen zu
72

benennen. Darüber hinaus erhält der Entwickler ein konstruktives Feedback zur
Qualität seiner Arbeit. Durch Prüfungen können zudem gute und schlechte
Prüflingen identifiziert werden und ermöglichen damit das Verwerfen von
aussichtlosen Varianten oder Lösungswegen. Tests sind zudem reproduzierbar und
objektiv und hängen nicht von der Qualifikation oder Tagesform des jeweiligen
Gutachters ab. Aufgrund der Reproduzierbarkeit von Tests können diese auch für die
Qualitätssicherung in der Wartung eingesetzt werden. Im Gegensatz dazu können
Reviews und Tests keinen Korrektheitsnachweis der Software erbringen und zeigen
in der Regel nicht die Fehlerursache (Ludewig, et al., 2010 S. 274, 488-489).

2.3.2 Prozessqualität
Die Betrachtung der Prozessqualität wird in dieser Arbeit nur der Vollständigkeit
halber aufgenommen. Wichtig ist, dass der Entwicklungsprozess von Software nicht
vergleichbar mit dem Fertigungsprozess der Industrie ist. Ein Fertigungsprozess hat
unmittelbare Auswirkungen auf das Produkt. Ein Softwareprodukt kann jedoch ohne
einen Entwicklungsprozess in einem Projekt entwickelt werden. Ein perfekter
Prozess muss deshalb keine Garantie für hohe Softwarequalität sein (Ludewig, et al.,
2010 S. 135-136). Vorgestellt werden CMMI und SPICE. Bootstrap wird in dieser
Arbeit nicht betrachtet, weil es in Spice aufgegangen ist (Liggesmeyer, 2009 S. 26).

2.3.2.1 CMMI
1991 hat das Software Engineering Institute (SEI) an der Carnegie Mellon University
das Capability Maturity Model (CMM) vorgestellt. CMM bewertet anhand eines Best
Practice Modells die Softwareentwicklungsprozesse eines Unternehmens. CMM ist
ein Kriterienkatalog, der wie eine Checkliste aufgebaut ist und fünf Stufen beinhaltet.
Für die Eintrittsstufe gibt es keine Kriterien. Damit wird jedes Unternehmen, das
nicht die Kriterien für Stufe 2 erfüllt, auf die Eintrittsstufe zurückgestuft. Ein
Unternehmen, das alle Kriterien erfüllt, erreicht die höchste Stufe fünf. Bei CMM
werden in der Prozessbewertung keine technischen Aspekte und keine Kompetenzen
von Mitarbeitern berücksichtigt. CMMI ist aus der Zusammenlegung von CMM-
Varianten entstanden (Hardware, Systemprojekte) und im August 2006 in der
Version 1.2 veröffentlicht worden. Es ist modular aufgebaut, in sogenannten
73

„Konstellationen“. Die Version 1.2 beschreibt drei Konstellationen:


Produktentwicklung (CMMI-DEV), Akquisition (CMMI-ACQ) und
Dienstleistungen (CMMI-SVC). CMMI-DEV in Version 1.2 unterscheidet 22
Prozessgebiete, die in die vier Gruppen 21 aufgeteilt werden. Jedes Prozessgebiet
beschreibt das zu erreichende Ziel und die Aufgaben, diese zu erreichen. Bei den
Zielen werden zum einen in spezifische auf das Prozessgebiet bezogene und zum
anderen generische Ziele, die jedes Prozessgebiet betreffen, unterschieden. Inwieweit
eine Organisation nach einem (abgeschlossenen) Projekt die generischen Ziele
erreicht hat, wird anhand eines Reifegrades gemessen. CMMI bietet dazu zwei
Varianten an, die stufenförmige und die kontinuierliche. Die stufenförmige stammt
aus CMM und besitzt fünf Reifegradstufen 22 . Bis auf die erste Stufe werden alle
Stufen durch Prozessgebiete beschrieben und sind einem Reifegrad zugeordnet. Um
den Reifegrad einer Stufe zu erreichen, muss sie alle Anforderungen der Stufe und
der darunterliegenden erfüllen. Dabei können Schwächen eines Prozessgebiets nicht
durch andere Stärken ausgeglichen werden. Bei der kontinuierlichen Variante wird
jedes Prozessgebiet einzeln betrachtet und bewertet. Dies wird erreicht, indem fünf23
generische Ziele pro Prozessgebiet festgelegt werden, die aufeinander aufbauen und
einen Fähigkeitsgrad pro Prozessgebiet definieren. Das Ergebnis ist ein kammartiges
Prozessprofil (Liggesmeyer, 2009 S. 20-23), (Ludewig, et al., 2010 S. 235-250).

2.3.2.2 Spice
Basierend auf Erfahrungen mit CMM, Bootstrap und anderen Ansätzen wurde durch
ISO auf internationaler Ebene das Bewertungsverfahren SPICE (Software Process
Improvement and Capability dEtermination) zu Bewertung und Verbesserung der
Softwareprozesse einer Organisation entwickelt. SPICE definiert wie CMMI den
24
Prozess durch Fähigkeitsgrade mit sechs Stufen. Die Bewertung wird in
Prozessreferenzmodellen festgelegt, die auch branchenspezifisch sein können. Das

21
Project Management, Engineering, Process Management und Support
22
ML1: Initial, ML2: Managed, ML3: Defined, ML4: Quantitatively Managed, ML5 Optimized
23
CL0: Incomplete, CL1: Performed, CL2 Managed, CL3: Defined, CL4 Quantitatively Managed, CL5
Optimzing. CL0 wird nicht mitgezählt, weil es keine generischen Ziele enthält.
24
Level 0: Incomplete, Level 1: Performed, Level 2: Managed, Level 3: Established, Level 4: Predictable,
Level 5: Optimizing
74

Referenzmodell besteht aus drei Prozesskategorien (Primary-, Organisational- und


Supporting Lifecycle Processes) mit neun Gruppen die 49 Prozesse zur Erstellung
und Akquise von Softwareprodukten und Services beinhalten (Liggesmeyer, 2009 S.
24). Aus dem Prozessreferenzmodell können einzelne Prozesse für eine
Begutachtung ausgewählt werden, woraus das Prozessbegutachtungsmodell entsteht.
Jeder Prozess wird einzeln über Prozessattribute bewertet, die sich je nach
Fähigkeitsgrad (1 bis 5) unterscheiden. SPICE besitzt darüber hinaus verschiedene
Begutachtungsarten und -durchführungen und enthält ein generisches Modell zur
Prozessbewertung (Liggesmeyer, 2009 S. 23-26), (Ludewig, et al., 2010 S. 250-255).

2.3.3 Kritische Würdigung


Die Gewichtung der Qualitätsmerkmale eines Softwareprodukts ist durch die
negative Korrelation der Taxonomien zueinander das Produktdesign der Informatik.
Qualitätsmerkmale sollten deshalb in einem Projekt zu Beginn operationalisiert,
gewichtet und definiert werden. Der daraus entstehende Qualitätsmix bildet
anschließend den Rahmen für das Softwareprodukt. Das Besondere daran ist, dass
Benutzer der Software diesen Mix später im Produkt als Produktdesign wahrnehmen.
Softwarequalität sollte deshalb nicht nur während des Projekts erfolgen, sondern
schon vor dem Start des Projekts.

Nicht mechanische Prüfungen in Form von Inspektionen sind wichtig für die
Codequalität und sollten deshalb permanent im Projekt angewendet werden.
Inspektionen erfordern allerdings eine offene Kommunikationskultur in dem Team.
Ansonsten können gerade Code Reviews sich insgesamt negativ auf den Teamgeist
auswirken. Bei Code Reviews kommt es zudem auf das Vertragsverhältnis an, weil
diese bei Auftragsarbeit oft als Druckmittel benutzt werden, um den Preis
nachträglich zu reduzieren. Die mechanischen Prüfungen, insbesondere das Testen,
können sehr umfangreich sein und bis zur Perfektion getrieben werden. Ob deshalb
unbedingt ein absolut fehlerfreies Produkt „in time, in budget“ entsteht ist fraglich.
Der Mix von Prüfungen sollte deshalb immer in Abhängigkeit mit den
Rahmenbedingungen, die das Projekt vorgibt, erfolgen.
75

Prozessqualität sollte insgesamt in einem Projekt nicht überbewertet werden. Die


Formalität, in der die Fähigkeitsgrade festgestellt werden, lassen vermuten, dass der
Grad der Prozessqualität lediglich ein Ausschreibungskriterium ist, ohne dem Projekt
an sich wirklich zu helfen.

3 Duct Tape Programmer


Peter Seibel veröffentlichte das Buch „Coders at Work“ (Seibel, 2009) im September
2009. In dem Buch wurden 15 Interviews mit anerkannten und sehr einflussreichen
Entwickler abgedruckt. Dabei wurden 80 Stunden Material aus Interviews im
Frage/Antwort-Stil verdichtet zusammengefasst. Interview-Partner waren Entwickler
wie Donald Knuth, Jamie Zawinski, Brendon Eich, Ken Thompson, Peter Norwig
oder Brad Fritzpatrick. Der Älteste war dabei Donald Knuth (geboren 1938) und der
Jüngste Brad Fritzpatrick (geboren 1980).

Peter Seibel war allerdings nicht der Erste, der in diesem Stil ein Buch verfasste.
Susan Lammers veröffentlichte bereits 1986 das Buch „Programmers at Work“
(Lammers, 1986). Das Buch unterscheidet sich in zwei wesentlichen Punkten von
„Coders at Work“: Erstens werden in ihren Interviews 19 Helden der
Microcomputer und PC-Revolution wie Bill Gates (Microsoft), John Warnock
(Adobe), Gary Kildall (CP/M), Wayne Ratcliff (dBase) oder Andy Herzfeld (MAC
OS) interviewt – viele von ihnen wurde Entrepreneure. Zweitens: Das Buch zeigt
pro Interviewer eine Seite Beispielcode oder Zeichnungen.

Im März 2009 ist zudem das Buch „Masterminds of Programming: Conversations


with the Creators of Major Programming Languages“ (Biancuzzi, et al., 2009)
erschienen, das ausschließlich Interviews von den Erschaffer bekannter
Programmiersprachen wie Bjarne Stroustrup (C++), James Gosling (Java) oder Brad
Cox und Tom Love (Objective-C) beinhaltet.
76

3.1 Begriffsherkunft
Der Begriff des „Duct Tape Programmers“ wurde von Joel Spolsky25 geprägt. In
seinem Weblog hat Spolsky einen Artikel zum ersten Interview mit Jamie Zawinski
in „Coders at Work“ verfasst (Spolsky, 2009). In dem Artikel nimmt er Bezug auf
Aussagen von Zawinskis Arbeiten am Netscape Browser (Version 2) und leitet
daraus einen bestimmten Typus von Programmierer ab. Er charakterisiert ihn als
pragmatisch, wenn es darum geht, ein lauffähiges Produkt zu entwickeln. Die
Mentalität entspricht Richard Gabriels „Worse is Better“ (Gabriel). Er favorisiert
dabei die 50 %-Lösung, mit der Probleme beim Kunden gelöst werden, gegenüber
einer 99 %-Lösung, die permanent optimiert wird und dadurch das Labor nicht
verlässt – sein Motto: „Shipping is a feature, your product must have it“.
Komplizierte, designgetriebene Programmiertechniken oder -sprachen werden von
ihm vermieden, es wird immer die einfachste Lösung genutzt. Dies gilt auch für die
testgetriebe Entwicklung. Die Fehlerquote wird von ihm durch den Einsatz von
einfachen und beherrschbaren Werkzeugen und Programmiersprachen gering
gehalten. Die dadurch gewonnene Zeit wird von ihm in die Fertigstellung des
Produkts investiert.

Spolsky beschreibt diese Mentalität eines Programmierers durch die Metapher eines
„Duct Tape“, ein Klebeband, das dem Militär, im Motorsport, der Bühnentechnik
oder Bastlern zur provisorischen schnellen Reparatur dient. Er wählte deshalb „The
Duct Tape Programmer“ als Titel seines Artikels und als Beschreibung für den
Charakter eines solchen Programmierers.

Der kontroverse Artikel von Joel Spolsky löste in der Netzgemeinde anschließend
eine Diskussion über „software quality versus delivery times“ aus.

Führend in der Diskussion mit 276 Kommentaren war der Blog Post (Martin, 2009)
von Robert Martin (CEO von Object Mentor). Er stimmt Spolskys Artikel
grundsätzlich zu, rät aber zur differenzierter Betrachtung in Bezug auf „Over-
Engineering“. Seine Kernthese des Artikels ist: „I want you to ship, but I don‘t want
you to ship shit.” (Martin, 2009). Rob Martin relativiert zudem die extreme Sicht

25
Joel Spolsky ist CEO von Fog Creek Software und Mitgründer von Stackoverflow.
77

Zawinskis: „The programmer who spends weeks building the perfect structure does
just as much harm to the project as the programmer who hacks a bunch of crap
together.“ (Martin, 2009). Dennoch sieht er es als notwendig an, das „Duct Tape“ in
Maßen einzusetzen: „In short, it‘s bad to use too much duct tape. But I‘d be
suspicious if I didn‘t see some duct tape!“ (Martin, 2009). Zawinskis Aussage, dass
„Unit Tests“ die Entwicklung verlangsamen, steht Martin kritisch gegenüber. Seiner
Meinung nach beschleunigen sie den Entwicklungsprozess, allerdings ohne Beispiele
zu nennen. Seine zentrale Aussage hierzu ist: „Programmers who say they don‘t have
time to write tests are living in the stone age.“ (Martin, 2009). Jeffrey Palermo (CTO
Headspring Systems) hingegen betrachtet in der Diskussion die „Duct Tape“-
Mentalität aus der Projekt-Perspektive und vergleicht es mit einem Projekt für einen
Wahlkampfkandidaten (Palermo, 2009). Erstens: Wirf die Software weg, wenn der
Kandidat verliert! Zweitens: Gewinnt der Kandidat, greift Brooks Regel „Plan to
throw one away, you have to do it anyway―.

James Zawinski distanzierte sich in seinen Blog von Spolskys Duct Tape
Programmer (Zawinski, 2009). Gleichzeitig mahnt er an, dass technische Aussagen
im Kontext der Zeit betrachtet werden müssen. Dies betrifft insbesondere seine
Aussagen zu technologischen Entscheidungen nicht auf C++, Threads und Templates
zu setzen. Desweiteren führte er auf, dass sein Quellcode erst in dem Mozilla-Projekt
einen kompletten Rewrite erhalten hat und dass die Code-Basis von Netscape 4 der
Rewrite des niemals veröffentlichten C++-Collabra-Codes für Netscape 3 war. Damit
beseitigte er die Vermutungen der Netzgemeinde, dass Netscape 4 so fehlerhaft war,
weil es auf Zawinskis „Duct Tape“-Code aufbaute.

Peter Seibel nahm in seinem Blog ebenfalls Stellung. Einmal zu den Netscape-
Rewrites (Seibel, 2009) und zum anderen zu Robert Martins nicht belegter
Behauptung, dass Unit Tests den Entwicklungsprozess beschleunigen (Seibel, 2009).
Die letzte Aussage überprüfte er aufgrund der Interviews. Dabei stellte er Folgendes
fest: Erstens, dass im ersten Schritt Test Driven Development die Entwicklung
verlangsamt (Zawinski, Knuth). Zweitens, dass Unit Tests langfristig den
Entwicklungsprozess beschleunigen (Fritzpatrick). Drittens, dass Test Driven
78

Development kein Ersatz für eine technische Spezifikation ist (Bloch). Viertens,
dass ein Unit Test keine Hilfe bietet, das eigentliche Problem zu lösen (Norvig).

3.2 Besondere Problemstellung


Joel Spolsky betrachtet in seinem Artikel „The Duct Tape Progammer“ nur Jamie
Zawinskis Aussagen aus dem Buch „Coders at Work“. Der abgeleitete Charakter in
dem Artikel des „Duct Tape Programmers“ betrachtet demnach nicht alle Interview-
Partner. Deshalb ist es notwendig, alle weiteren Interviews auf Basis von Joel
Spolskys beschriebenen Charakter und Mentalität des „Duct Tape Programmers“ zu
untersuchen26.

3.3 Vorgehen
Das Vorgehen kann in drei Schritte unterteilt werden. Erstens: Feststellen von
Gemeinsamkeiten in den Fragestellungen bei allen 15 Interview-Partnern und
Interpretation, worauf sie abzielen. Dies soll dem Leser helfen, welche Fragen über
alle Interviews hinweg gestellt wurden. Zweitens: Finden von Gemeinsamkeiten in
den Aussagen der Interview-Partner über alle gestellten Fragen hinweg, die auf eine
Charakteristik des „Duct Tape Programmers“ nach Joel Spolsky hinweisen.
Drittens: Kategorisieren der Charakteristiken in Themenkomplexe, die mit Zitaten
belegt werden, aus denen anschließend eine Mentalität abgeleitet werden kann.

Nicht betrachtet werden Meinungen, die sich auf die Sprachwahl der
Programmiersprachen beziehen, weil sie in erster Linie eine persönliche Meinung
darstellen. In diesem Zusammenhang argumentiert Bloch auf Seibels Frage „Why do
people get so religious about their computer languages?“ – Blochs Antwort: „[…]
Yes, you want to go to a bar that serves good drinks, but that‘s not the most
important thing. It‘s who hangs out there and what they talk about. And that‘s the
way you choose computer languages. Over time the community builds up around the
language – not only the people, but the software artifacts: tools, libraries, and so
forth.“ (Seibel, 2009 S. 2190)

26
Dies impliziert nicht, dass der anschließend festgestellte Charakter aus der Untersuchung repräsentativ ist.
79

3.4 Analyse der Fragestellungen in „Coders at Work―


In den Interviews von Peter Seibel lässt sich ein Raster in der Reihenfolge und Inhalt
der von ihm gestellten Fragen erkennen. Es gibt zudem eine Minimalausprägung von
Fragen in jedem einzelnen Interview. Die nachfolgenden Fragen von Seibel weichen
in den einzelnen Interviews im Wortlaut ab, sind aber sinngemäß identisch.

Seibel beginnt alle Interviews mit den Eröffnungsfragen „How did you become a
programmer?― oder „How did you learn to program?― und „Do you remember the
first interesting program you wrote?―. Diese Fragen werden für den
Gesprächseinstieg genutzt und sollen den Interview-Partner in einen zeitlichen
Kontext setzen, in denen sie keine bekannten Programmier-Persönlichkeiten waren.
Anschließend werden die Interviews in zwei übergeordnete Themenblöcke unterteilt.
Der erste bezieht sich auf das Handwerk des Programmierens. Der zweite erörtert
Erfahrungen und persönliche Meinungen in der Funktion eines Softwareentwicklers.

Der erste Themenblock startet mit Fragen zum Softwaredesign. „How do you design
software?― und erfragt, ob der jeweilige Interview-Partner ein favorisiertes
Vorgehensmodell bei der Entwicklung besitzt und wie er in der Vergangenheit bei
der Entwicklung vorgegangen ist. Als grobe Richtung gibt Peter Seibel dabei „Top-
Down“, „Bottom-Up“ oder „Middle-Out“ vor. Die Überleitung zum Vorgehen und
Erlebnissen mit Softwarefehlern, die entweder selbst oder von anderen verschuldet
wurden, erfolgt mit „What‘s the worst bug you ever track down?“. Das Vorgehen bei
der Fehlersuche wird mit „What are your debugging tools? Debuggers? Printlns?
Something else?― erfragt. „Do you ever do any pair programming?―, erfragt zum
einen inwieweit Methoden zur Fehlerreduzierung innerhalb des
Entwicklungsprozesses von den Interview-Partnern genutzt werden, und zum
anderen, wie diese zu agilen Konzepten stehen. Die Frage „What about code
ownership? It is important for people to own code individually or is it better for a
team to share ownership?“ soll die persönliche Meinung und Projekterfahrung zu der
Thematik erörtern. Anschließend wird Bezug auf die Themen „Clean Code“ und
„Literal Programming“ genommen. Hierzu werden zwei Fragen gestellt, die jeweils
eine der zwei möglichen Perspektive betrachten. Die erste betrachtet das Lesen des
Quellcodes von Dritten mit „When you read a big piece of code, how do you get into
80

it? Do you read code you‘re not working on?“ und die zweite betrifft das Verfassen
des eigenen Quellcodes für Dritte mit „Have you ever done literate programming a
la Knuth?“.

Der zweite Themenblock beginnt mit der Frage „How do you recognize a great
programmer?“ aus der Perspektive, wenn der Interview-Partner einen Entwickler
einstellen soll. Die Frage wird vertieft mit „Google has a bit of a reputation, as
Microsoft also does, of interviewers using puzzle questions?“ und soll herausfinden,
ob die Interview-Partner selbst Einstellungstest praktiziert und welche Erfahrungen
sie damit gemacht haben. Erörtert wird Dijkstras These, dass Informatik (Computer
Science) Teil der Mathematik ist, mit der Frage „How much mathematics do you
think is required to be a competent programmer?“. Die Frage soll zudem Dijkstras
These beim Interview-Partner abfragen, ob Studenten im Studium erst theoretische
Grundlagen erlernen sollten, bevor sie an den Computer herangeführt werden.
Welche Autoren und Bücher die Interview-Partner gelesen haben, wird mit „Are
there any books that every programmer should read?“ erfragt. Seibel zielt
insbesondere darauf ab, ob die Entwickler „The Art of Computer Programming“ von
Donald Knuth gelesen und ihrer Meinung nach empfehlen können. Mit „Do you still
enjoy programming?“ wird erfragt, ob die Interview-Partner immer noch
Begeisterung für das Entwickeln empfinden. Mit „Do you consider yourself a
scientist, an engineer, an artist, or a craftsman?“ stellt er zum Schluss die
entscheidende Frage, wie sie sich selbst und in Bezug auf ihre Arbeit sehen.

3.4.1 Interviewfragen mit Relevanz für das Software-Engineering


Aus dem Standard-Fragenkatalog von Peter Seibel können vier Fragen als relevant
festgestellt werden, die konkrete Themen des Software-Engineerings erfragen.
Erstens: „How do you design software?“, was neue oder bestehende
Vorgehensmodelle aufzeigen kann. Zweitens: „Do you ever do any pair
programming?“ kann als Experten-Meinung zu der Methodik dienen. Drittens:
„What about code ownership? It is important for people to own code individually or
is it better for a team to share ownership?“ besitzt als Experten-Meinung ebenfalls
Relevanz. Viertens: „Do you consider yourself a scientist, an engineer, an artist, or
a craftsman?“ kann einen Einblick gewähren, aus welchem Blickwinkel
81

ausgezeichnete Programmierer ihren Beruf sehen. Die Auswertung der


Fragestellungen erfolgt im Kapitel 4.1 (S. 110).

3.5 Charakteristiken
Die Feststellung der Charakteristiken erfolgte nach dem „Bottom Up“-Verfahren. Es
wurden die einzelnen Interviews aus der Sichtweise von Joels Spolskys Duct Tape
Programmer gelesen und Zitate extrahiert. Anschließend wurde diese in folgende
Hauptkategorien unterteilt: Thesen, Haltung, Methoden, Vorgehensweise, Ziele und
Projekterfolg.27

Keiner der Interview-Partner besitzt alle Charakteristiken. Zitate sind deshalb in


großen Teilen nur von einer Person vertreten. Die nachfolgenden
Charaktereigenschaften können deshalb als Maximalausprägung verstanden werden.

3.5.1 Thesen
Als Thesen werden die Aussagen aus den Interviews verstanden, die wesentlichen
Einfluss auf den ganzen Softwareentwicklungsprozess besitzen, ihn maßgeblich
beeinflussen und zu Spolskys Bild des Duct Tape Programmer passen. Diese sind
wissenschaftlich nicht belegbar und werden lediglich aus den Erfahrungen einzelner
Interview-Partner abgeleitet. Mit einbezogen wurden die Inhalte der Netzdiskussion
zu Spolskys Ursprungsartikel. Die Thesen sind priorisiert, in der Reihenfolge ihrer
Erwähnung.

3.5.1.1 These 1: Shipping is a feature, your product must have it


In den Interviews vertritt diese These Jamie Zawinski eindeutig und wird deshalb
auch vom Joel Spolsky in seinem Artikel plakativ aufgegriffen. Zawinskis Zitat:
„Yeah,‖ he says, ―At the end of the day, ship the fucking thing! It‘s great to rewrite
your code and make it cleaner and by the third time it‘ll actually be pretty. But that‘s
not the point—you‘re not here to write code; you‘re here to ship products.― (Seibel,
2009 S. 329). Diese These basiert auf Steve Jobs (CEO von Apple) Aussage „Real
artists ship“. Der Slogan wurde im Rahmen des Macintosh-Projekts 1983 von Jobs

27
Das Vorgehen wurde bereits beim Beginn der Arbeit dargelegt (siehe Kapitel 1.3, S. 3).
82

getätigt. Die Softwareentwickler waren bereits einen Monat überfällig (Levy, 1995 S.
165), weil sie sich von ihrem Code nicht trennen konnten. In Linchpin nimmt Seth
Godin ebenfalls zu dem Slogan Stellung, allerdings im Kontext zu „Worse is better“ ,
indem er argumentiert: „Shipping isn‘t focused on Producing a masterpiece (but all
master-pieces get shipped)“ (Godin, 2010 S. 1885). Norvig unterstreicht die Aussage
im Kontext der Code-Optimierung: „You have to think how much is it going to
benefit the customer if I go from 95 % to 100 % on this feature vs. working on these
ten other features that are at 0 %― (Seibel, 2009 S. 3867). Besonders hervorzuheben
ist Fritzpatricks Aussage, dass ihn ein fester Fertigstellungstermin mehr reizt als die
von Google „When it‘s done, it‘s done“-Mentalität (Seibel, 2009 S. 996). Norvig
nimmt zudem Stellung zum „Launch early and often“-Ansatz (Seibel, 2009 S. 3871),
der die „Real artists ship“-Mentalität unterstützt – allerdings im Kontext von Googles
Kostenlosstrategie. Seine These: Fehler in kostenlosen Web-Produkten stellen kein
Desaster dar, weil der Kunde dafür nicht zahlt und Updates sofort sichtbar sind, weil
sie nicht installiert werden müssen. „We‘re just going to launch things and get some
feedback from users and fix the stuff that needs to be fixed and don‘t worry about the
other stuff.“ (Seibel, 2009 S. 3875) Diese Sicht teilt ebenso Zuckerberg in seiner
Releasestrategie: „It‘s just better to just launch and have something cool that you can
fix over time.“ (Cutler, et al., 2009).

In Bezug auf Softwarequalität trifft Zawinski folgende Aussage „We're absolutly 100
% committed to quality. We're going to ship the highest Product we can on March
31.“ (Seibel, 2009 S. 474). Diese Aussage ließ Robert Martin zu der Aussage
hinreißen „I want you to ship, but I don't want you to ship shit.“ (Martin, 2009).
Zawinski stimmt in seiner Aussage auch mit Martins These überein. Der wesentliche
Unterschied zwischen beiden ist, dass Zawinksi unter „committed to quality“
fehlerhafte, aber benutzbare Software als Endprodukt versteht, die keinen Mangel
aufweist und im weitesten Sinne einen „Black-Box-Test“ (siehe Kapitel 2.3.1.1.3.2,
S. 70) besteht. Martins Zitat bezieht sich jedoch auf den Softwareprozess. Die
Aussage „[…] I don't want you to ship shit― ist für ihn gleichbedeutend, wenn
Software nicht nach Test Driven Development entwickelt wurde und keine 100 %
„Test Coverage“ bei den Unit Tests besitzt. Norwig nimmt zu Zawinskis Sicht
indirekt Stellung, indem er Fehler gegenüber einen Mangel in Software relativiert,
83

die das System nicht abstürzen lassen: „[…] Look at all the software bugs on your
computer. There are millions of them. But most of the time it doesn‘t crash.― (Seibel,
2009 S. 3954) Zawinski beschreibt zudem indirekt, dass sie den
Fertigstellungstermin auf Kosten der Features gehalten haben, wenn er in einem
Nebensatz erwähnt „[…] this is the one with all the stuff that we couldn‘t ship the
first time around.― (Seibel, 2009 S. 290). Zum Einhalten des Termins wurden
Features gestrichen.

Zusammenfassend können fünf Dinge festgestellt werden. Erstes, dass der


Fertigstellungstermin der zentrale Mittelpunkt für alle Entscheidungen im Software-
entwicklungsprozess ist. Zweitens, dass die Auslieferung der ersten Version einen
gewünschten Feedbackprozess durch die Nutzung der Software in Gang setzt, der in
einen inkrementellem kreativen Verbesserungsprozess endet. Drittens, dass die
Softwarequalität der ersten Generation nicht in der Code-Qualität gemessen wird,
sondern, ob die Software aus Benutzersicht fehlerfrei und benutzbar ist. Viertens,
dass Funktionen und Umfang der Software abhängig vom Fertigstellungstermin ist.
Fünftens, das es im ersten Schritt ausreicht, die relevanten 80 % eines Problems zu
lösen.

3.5.1.2 These 2: Die Komplexität eines Problems offenbart sich erst in der
Implementierung
Zawinksi beschreibt in seinem Interview einen interessanten Konflikt zwischen
Design und Implementierung. In einer Selbstreflektion erläutert er anschaulich, wie
er glaubt, dass ein Problem aus der Perspektive des Softwaredesigns gelöst werden
sollte und wie er das Problem letztendlich in der Implementierung gelöst hat. „[…]
Once you start writing code, you‘re gonna realize, ‗No, that was a dumb idea. Why
did I think that this module was going to be really easy when actually it‘s way more
complicated than I thought?‗ Which is something you‘re not going to clue into you
actually start writing code and you feel it getting away from you.“ (Seibel, 2009 S.
406). Eich differenziert bei Design und Implementierung zwischen Theoretikern und
Praktikern und kommt zu Schluss „[…] They‘re not really practical people. They
have amazing insights, which can sometimes be very productive, but when you have
to actually write programs and ship them to users and have them usable and have
84

them win some sort of market contest, you‘re far removed from theory.“ (Seibel,
2009 S. 2038). Zawinksi sieht das Softwaredesign als permanenten Designprozess
während der Entwicklung des Programms: „The design process is definitely an
ongoing thing; you never know what the design is until the program is done.“
(Seibel, 2009 S. 407). Im Zusammenhang, wie Design Reviews durchgeführt
wurden, erwähnt Cosell, dass sie vor der Implementierung das Design erstellt hatten.
Er fügt allerdings auf Seibels Nachfrage hinzu „Probably some of the coding had
been done because a lot of people, including me, have to start blocking up little bits
of code to see how a thing is actually going to work out“ (Seibel, 2009 S. 6727). In
diesem Fall hatten sie mit der Implementierung von Teilbereichen während des
Designprozesses gestartet, um Ihr eignes Design zu überprüfen. Fritzpatricks
Erfahrung mit designgetriebenen Entwicklern beschreibt er folgendermaßen: „They
would just do abstraction on abstraction on abstractions. They would go really
slowly and are very religious about their style. They‘re like. ‗I‘m an artisan
programmer.‗ And I was like: Your Code doesn‘t run. It‘s not efficient and it doesn‘t
look like any of the other code that you‘re interacting with.“ (Seibel, 2009 S. 1000).
Im Gegensatz dazu erzählt Fritzpatrick auch die Anekdote, wie ein Entwickler es
geschafft hat, das komplexe „Voice Bridge“-System für Livejournal lauffähig zu
machen. Er hat dabei sehr komplexe Probleme mit den einfachsten Mitteln gelöst,
indem er Komponenten aus den unterschiedlichsten Sprachen „irgendwie“
zusammengesetzt hat. Sie mussten zwar seine Version komplett neu implementieren,
das lauffähige System gab ihnen aber die entscheidende Idee, wie die Lösung aussah
(Seibel, 2009 S. 1000ff.).

Warum Komplexität erst in der Implementierung festgestellt werden kann, begründet


Deutsch mit Hilfe einer Metapher. In der „echten“ Welt ist es möglich, etwas zu
erschaffen, ohne sich Gedanken über die Details auf der atomaren Ebene zu machen,
und kommt dabei zur Schlussfolgerung „To a great extent, that is not true in the
world of software“. Er fügt hinzu: „Software is a discipline of detail, and that is a
deep, horrendous fundamental problem with software. Until we understand how to
conceptualize and organize software in a way that we don‘t have to think about how
every little piece interacts with every other piece, things are not going to get a whole
lot better. And we‘re very far from being there.“ (Seibel, 2009 S. 5336).
85

3.5.1.3 These 3: An hour code reading is worth two weeks of QA


Die Methode des „Code Readings“, insbesondere in Bezug auf „Code Reviews“ ,
wird in allen Interviews besprochen. Crockford und Allen bewerten darin, wie
effizient diese Methode ihrer Meinung nach ist. Crockford sieht es als enorme
Zeitersparnis: „I think an hour of code reading is worth two weeks of QA. It‘s just a
really effective way of removing errors.― (Seibel, 2009 S. 1313). Allens Meinung ist,
dass diese unter Termindruck zwar anstrengend, aber wirksam sind: „[…] and been
in the situation where one has week-by-week code reviews right up against
deadlines. […] It can be very painful to sit there every Friday and do code reads
with people explaining why they‘re doing what they‘re doing and finding other
people‘s errors. Seibel: Painful, but worthwhile? Allen: Absolutly worthwhile. […]―
(Seibel, 2009 S. 6230).

Crockford führt zudem auf, dass „Code Readings“ im Projekt davor schützen, dass
Programmierer erst zum Schluss merken, dass sie mit einer Aufgabe überfordert
sind, und die Möglichkeit bieten, den Projektfortschritt zeitnah zu sehen: „One of the
consequences of that is that if you have weak or confused programmers you‘re not
aware of their actual situation until much too late. […] ‗Yeah. I‘m almost done‗, and
then you get the code, and there‘s nothing there, or it‘s crap, or whatever, and
they‘re nowhere close to done.― (Seibel, 2009 S. 1314).

3.5.1.4 These 4: „Unit Tests― lösen das Kernproblem nicht


Norvig beschreibt in seinem Interview ein Erlebnis mit Ron Jeffries28. Beide wollten
einen „Sudoko Solver“ schreiben. Ron Jeffries versuchte, das Problem zu lösen,
indem er als Erstes „Unit Tests“ schrieb. Norvig Aussage hierzu: „[…] He had five
different blog posts and in each one he wrote a little bit more and wrotes lots of tests
but he never got anything working because he didn‘t know how to solve the
problem.― Norvig nennt auch das Kernproblem, welches Ron Jeffries hatte: „[...] He
didn‘t know that so he was sort of blundering in the dark even though all his code
‗worked‗ because he had all these test cases.― Deshalb kommt er zu der

28
Ron Jeffris ist neben Kent Beck und Ward Cunningham einer der drei Gründer von Extreme Programming.
86

Schlussfolgerung: „But you can test all you want and if you don‘t know how to
approach the problem, you‘re not going to get a solution.― (Seibel, 2009 S. 3773 ff.).

3.5.1.5 These 5: The smartest people in the organization shouldn’t design


APIs or GUIs or languages
Bloch antwortet auf Seibels Frage „Is there something intrinsic in programming
that‘s always going to draw people with that kind of mentality?―, indem den Konflikt
zwischen der technischen und benutzbaren Lösung anspricht. Bei der technischen
Lösung steht die Denksportaufgabe so stark im Mittelpunkt, dass beim
Programmieren vergessen wird, für wen diese eigentlich gelöst werden soll. Er führt
hierzu aus: „We love Brainteasers. But we have to temper this lover with the
knowledge that we‘re solving real problems for real people. […] The moment you
lose sight of that and who your customers are, you‘re dead meat. But I think it tends
to conflict with the sort of people who are attracted to programming, who are the
people who love brainteasers.― (Seibel, 2009 S. 2556). Damit beide Ziele erreicht
werden können, gibt er folgende Ratschlag im Vorgehensmodell: „Keep that
empathy gene on when you‘re designen your API, but then, in order to make them
run bloddy fast you can freely decend into the puzzle palace.― (Seibel, 2009 S.
2560). In diesem Zusammenhang kommt er zur Schlussfolgerung, dass
Programmierer zwar die intelligentesten Personen in einer Organisation sind, aber es
oft nicht schaffen, den „Context Switch“ zwischen Empathie/Denksport
durchzuführen. Aus diesem Grund sollten sie bei APIs, GUIs und Sprachen nicht die
Entscheidungsgewalt besitzen, weil im Zweifelsfall diese für Dritte nicht mehr
benutzbar sind. „But merely the fact that they‘re the smartest people in the
organization doesn‘t mean they should be making all the decisions, because
intelligence is not a scalar quantity; it‘s a vector quantity. And if you lack empathy
or emotional intelligence then you shouldn‘t be designing APIs or GUIs or
languages.― (Seibel, 2009 S. 2572). Die Problematik wird auch in Jones Interview
im Zusammenhang mit Microsoft Research aufgegriffen. Microsoft überprüft neue
APIs in Usability Tests. Die Situation, in denen die API-Designer das ungefilterte
Feedback der Benutzer (in diesem Fall Probanden) erhalten, beschreibt er wie folgt:
„Steven Clarke and his colleagues at Redmond have made systematic attempts to
87

watch programmers, given a new API, talk though what they‘re trying to do. And
they get the people who designed the API to sit behind a glass Screen and watch
them. And the guys sitting there behind the glass screen say, ‗No, no, don‘t do that!
That‘s not the right way!‗ But it‘s soundproof. That turns out often to be very
instructive. They go and change their API.― (Seibel, 2009 S. 3171). Bloch nennt
auch den Grund. Seiner Meinung spielt es keine Rolle, wie exzellent der API-
Designer ist. Eine API entwickelt sich im Entwicklungsprozess organisch und das
Design entsteht aus praktischen Anforderungen während der Entwicklung. Deshalb
sollte Test Driven Development und Refactoring im ersten Schritt bei der API
durchgeführt werden und nicht am Quellcode, der die API nutzt. „It doesn‘t matter
how good you are; you can‘t get an API right until you‘ve tried to code to it. You
design something; try to use it; […] So what I‘m talking about is test-first
programming and refactoring the APIs, rather than refactoring the implementation
code underneath the APIs.― (Seibel, 2009 S. 2276).

3.5.2 Haltung
In den Interviews kann eine Haltung zu bestimmten Themenkomplexen extrahiert
werden. Eindeutig negativ ist die Haltung zum Wasserfallmodell. Es werden von den
Interview-Partnern die typischen Kritikpunkte aufgeführt, die bereits im ersten Teil
dieser Arbeit genannt wurden. Grundsätzlich wird UML als Kommunikations-
instrument für gut befunden, aber selbst nicht angewendet. Die Personen geben auch
zu, die UML-Notation nicht zu kennen. Eine Wiederverwendung von Software findet
ausschließlich auf Quellcode-Ebene statt, wobei die Wiederverwendung von
Objekten vermieden wird. Das Einführen von unnötigen Abstraktionsebenen wird als
Over-Engineering angesehen. Die Optimierung von Code wird sehr differenziert
betrachtet. Grundsätzlich sind die Interview-Partner der Meinung, dass Entwickler in
der Regel den interessantesten, aber nicht relevantesten Code optimieren. Das
„Literate Programming“ wird als sinnvolles Konzept angesehen, aber von den
Interview-Partnern kaum durchgeführt. Trotzdem wird der lesbare Code als eines der
wichtigsten Bestandteile beim Schreiben von Quellcode gesehen. Crockford erwähnt
zudem, dass sich Standards in der Informatik evolutionär entwickeln und nicht durch
88

ein Komitee verabschiedet werden sollte. Den Standardisierungsprozess sollten


Entwickler selbst aktiv mitgestalten.

3.5.2.1 Wasserfallmodell
Allen, Eich und Bloch beschreiben in den Interviews sehr deutlich ihre negative
Haltung zum Wasserfallmodell. Dabei werden mehrere Punkte angesprochen. Allen
kritisiert drei wesentliche Punkte. Erstes, die mangelnde Interaktionsmöglichkeiten
zwischen den Fachdisziplinen: „[…] And found it frustrating because in its early
stages, a designer and the programmer could not interact―, zweitens die Annahme,
dass die Anforderungen sich im laufenden Projekt nicht ändern werden, und
drittens, dass erst am Projektende eine lauffähige Software entsteht („all or nothing
approach“). „One of the problems was- probably still is – that the life cycle of a
piece of software is very long. […] it took months and months or years. And the
environment changed and the requirements changed. And the customers really did
have the say in what they wanted in the end.― (Seibel, 2009 S. 6164). Eich und Bloch
nehmen beide Bezug auf das Problem, dass die Spezifikation und Implementierung
zwei getrennte Aktivitäten sind. Eich nimmt Bezug auf die zweite These (Die
Komplexität eines Problems offenbart sich erst in der Implementierung): „You spend
all this time writing documents and then you go to write the code and often you
realize that it‘s really stupid and you totally change the code and put the documents
down the memory hole.― (Seibel, 2009 S. 2000) Bloch kritisiert das Vorgehen des
realitätsfremden theoretischen Spezifizierens ohne die Integration des Kunden: „[…]
you get a bunch of smart guys into a room to work for six months and write a 247-
page system specification before they really understand what it is they‘re trying to
build. Because after six months, they‘ll have a very precisely specified system that
may well be useless. And often they say, ‗We‘ve invested so much in the spec that we
have to build it.‗ So they build the useless system and it never gets used.― (Seibel,
2009 S. 2249) Norvigs These ist, dass das Wasserfallmodell in den frühen Zeiten des
„Batch Processing“ durch das einfachere Interface auch seine Berechtigung hatte. Es
konnten damals Arbeitsabläufe besser sequenziell durchgeführt werden als heute.
Trotzdem kritisiert er die fehlende Interaktion mit dem Kunden: „It was possible to
do this kind of waterfall design where you said, – The input is going to be this deck of
89

cards, and the output is going to be a report that has this number in this column.―
(Seibel, 2009 S. 1998). Dabei kommt er zum Schluss, dass die heutigen Werkzeuge
eine höhere Interaktion mit dem Kunden zulassen und deshalb die agile
Herangehensweise zeitgemäß ist. „Rather than have a complete specification from
the start, just get customers in the room an start brainstorming.― (Seibel, 2009 S.
3675).

3.5.2.2 UML
Bloch und Norvig haben zwei unterschiedliche Sichtweisen auf den Einsatz von
UML. Bloch sieht UML als nützlich, aber nicht notwendig an und bestärkt dies,
indem er zugibt, die UML-Notation nicht zu kennen: „No, I think it's nice to be able
to make diagrams that other people can understand. But honestly I can't even
remember which components are supposed to be round or square.― (Seibel, 2009 S.
2286). Norvig hingegen sieht UML als Hilfsmittel für Sprachen, die in der
Modellierung Schwächen besitzen: „I never liked any of these UML-type tools. I
always thought – If you can't do it in the language itself that‘s a weakness of the
language.― (Seibel, 2009 S. 3876). Aus beiden Zitaten kann festgestellt werden, dass
beide keine UML-Diagramme als Hilfsmittel für eine Problemlösung nutzen würden.

3.5.2.3 Wiederverwendung
Obwohl Deutsch an das Prinzip der Wiederverwendung bei Objekten nach wie vor
glaubt, sieht er es kritisch. Wenn Software wiederverwendet werden kann, ist es eine
Kapitalanlage, die gewartet und gepflegt werden muss. Es entstehen Kosten für den
Aufbau einer Objekt-Bibliothek. Die Kosten für die Erstellung von Objekten können
nicht ausschließlich einem Kundenprojekt zugeordnet werden, sondern müssen wie
Anlagevermögen (zum Beispiel der Bau einer neuen Fabrik zur Produktion)
betrachtet werden. Ob sich die Investition für ein wiederverwendbares Objekt
finanziell lohnt, ist ungewiss. Er führt dabei auf, „all things that I see getting reused
these days are either very large or very small. The scale of reuse […] when we were
promoting objects was classes and groups of classes. Except in situations where you
have a collection of classes that embody some kind of real domain knowledge, I don't
see that happening much.―. Was er mit sehr klein und sehr groß meint, führt er
90

ebenfalls auf: „What I see getting reused is either very small things – individual
icons, individual web page designs – or very big things like entire languages or large
applications with extension architectures like Apache or Mozilla.― (Seibel, 2009 S.
5470 ff.) Objekte sind seiner Meinung nach genau in der Mitte. Die Gründe, aus der
Perspektive eines Entwicklers, Objekte nicht zu nutzen, führen Armstrong, Knuth
und Norvig auf. Armstrong ist der Meinung, dass objektorientierte Sprachen eine
geringere Wiederverwendbarkeit besitzen als imperative Sprachen, „because the
problem with object-oriented languages is they‘ve got all this implicit environment
that they carry around with them. You want a banana but what you got was a gorilla
holding the banana and the entire jungle.―. Im Gegensatz dazu führt er imperative
Sprachen auf: „If you have referentially transparent code, if you have pure functions
– all the data comes in its input arguments and everything goes out and leaves no
state behind – it‘s incredible reuseable.― (Seibel, 2009 S. 2680 ff.) In dieser These
unterstützt ihn Knuth, indem er sich gegen Kapselung ausspricht und der Meinung
ist, das letztendlich das eigentliche Programmieren in den Hintergrund gerückt wird:
„There's this overemphasis on reusable software where you never get to open up the
box and see what's inside the box. It's nice to have these black boxes but, almost
always, if you can look inside the box you can improve it and make it work better
once you know what's inside the box. […] All they're able to do is assemble the
parts.― (Seibel, 2009 S. 7259). Norvig sieht in der Wiederbenutzung die Gefahr, dass
fehlerhafte Software entsteht. Durch die Nutzung gleicher Komponenten in anderen
Nutzungskontexten muss die wiederverwendete Software wie alle anderen
Komponenten auf Lauffähigkeit und Fehler überprüft werden. „They have extremely
good checks for the stuff that‘s mission critical, and in the previous mission the stuff
that was recorded in foot-pounds was non-mission-critical – it was just a log that
wasn‘t used for navigation. So it had been classified as non-mission-critical. In the
new mission they reused most of the stuff but they changed the navigation so that
what was formerly a log file now became an input to the navigation.― (Seibel, 2009
S. 3944). Das Problem war, dass die Navigationssoftware davon ausging, dass ihr die
Daten in Newton und nicht in Pfund übergeben wurden. Die Mission scheiterte
aufgrund der Wiederverwendung von Software.
91

3.5.2.4 Over-Engineering
Die Haltung gegenüber „Over-Engineering“ ist eindeutig negativ. Die Interview-
Partner sehen keinen Mehrwehrt durch die Einführung von Abstraktionsebenen. Ihrer
Meinung nach werden durch Abstraktionsebene die eigentlichen Probleme nicht
gelöst, sondern weiterdelegiert. Deshalb sind sie der Meinung, dass dies nichts mit
Programmieren zu tun hat und das heute viele Entwickler sich im Grunde nicht mit
dem System auskennen, auf dem sie programmieren. Thompson äußert sich in
diesem Zusammenhang: „Modern programming scares me in many respects, where
they will just build layer after layer that does nothing except translate. […] It‘s just
relegating the problem to a deeper and deeper level.― (Seibel, 2009 S. 5765).
Zawinski ist der gleichen Meinung: „We need to do is add another abstraction layer
here and have a delegate for this delegate for this delegate.― (Seibel, 2009 S. 322).
Fritzpatrick vertritt die Meinung, dass Programmierer sich zu stark fokussieren –
ohne das Interesse, den Rest des Systems verstehen zu wollen. Dies macht sich seiner
Meinung nach bemerkbar, indem sie sich gedankenlos auf die Arbeit Dritter
verlassen. „Your virtual machine may be hiding that from you and giving you some
abstraction that makes it look like that's efficient, but it's only efficient when you're
running it on this kernel […] it helps to actually know what's going on under the
covers and not trust everyone else's libraries, and code, and interfaces.― (Seibel,
2009 S. 853). Eich sieht es differenzierter und macht Abstraktion abhängig vom
Anwendungsfall: „Abstraction is powerful. What I‘m really allergic to […] was the
CORBA, COM, DCOM, object-oriented nonsense. Every startup of the day had some
crazy thing that could take 200,000 method calls to start up and print ―hello, world‖.
That‘s travesty; you don‘t want to be a programmer associated with that sort of
thing.― (Seibel, 2009 S. 1771ff.). Er sieht zudem einen Evolutionsprozess, welche
Abstraktion gut und sinnvoll ist und dass Entwickler in dem Umfeld trotzdem guten
Quellcode produzieren können, ohne das System komplett verstehen zu müssen.
„Staying close to the metal was my way of keeping honest and avoiding the bullshit,
but now, you know, with time and better, faster hardware and an evolutionary
winnowing process of good abstractions versus bad. I think people can operate
above that level and not know assembly and still be good programmers and write
tight code.― (Seibel, 2009 S. 1771ff.). In diesem Zusammenhang kommt er zur
92

Erkenntnis, dass trotz Abstraktionen das Programm vom Compiler in Maschinencode


übersetzt werden muss, und er damit die Aufgabe hat, die Abstraktionen wieder
aufzulösen: „But there‘s something still that bothers me if over time we lose the
ability to write to the metal. Somebody‘s doing it; the compiler is generating the
code. The compiler writers have to be doing a better job over time.― (Seibel, 2009 S.
1771 ff.).

3.5.2.5 Code-Optimierung
Der Reiz der Code-Optimierung ist für Entwickler sehr groß. Trotzdem sehen die
Interview-Partner darin eine Gefahr. Ihrer Meinung nach optimieren Entwickler
Code-Teile nach persönlichen Vorlieben und nicht nach Projektrelevanz. Cosell
spricht sogar davon, dass Programmierer die schlechteste Wahl für die Optimierung
von Quellcode sind, weil sie nur den interessantesten und nicht den relevantesten
Code optimieren: „Programmers are the worst optimizers in the world. They always
optimize the part of the code that's most interesting to optimize, an almost never get
these part of the code that actually needs optimization.― (Seibel, 2009 S. 6958).
Steele spricht in diesem Zusammenhang auch von dem Entwicklerphänomen
„Because we can“: „It's easy to become too fixated on optimizing something just
because you can, even though it's not what you need to work on.‖ (Seibel, 2009 S.
4667). Fritzpatrick sieht die Optimierung als Belohnung für das Erreichen von
lauffähigen Code an: „Optimization is fun because it's not necessary. If you're doing
that, you've got your thing working and nothing else is more important […].―
(Seibel, 2009 S. 1051). Crockfords Argument spricht das Relevanzkriterium an und
kommt zum Ergebnis, dass die Codequalität dadurch sinkt: „I also see a lot of folks
struggling to try to make stuff fast in situations where it absolutely doesn't need to go
fast. They're unaware of how their own program is spending its time and so they're
optimizing things which don't require optimization and which will never be big
enough going though that path to ever make any difference so there's no reward, no
benefit at all, for having done that optimization. All the optimization did was
introduced cruft.― (Seibel, 2009 S. 1376). Dieser Meinung ist auch Thompson: „I'll
do it as simply as possible the first time. […] Building a very complex algorithm for
something that's never run is just stupid. […] It's a bug generator.― (Seibel, 2009 S.
93

5891). Zudem macht er darauf aufmerksam, dass die Optimierung von Code auch
anders erfolgen kann. Er führt hier „Moore‟s Law“ und den Einsatz von „Cache“ an.
Diese Kriterien sollten in die Entscheidung der Relevanz mit einbezogen werden.
„You can pick up 10 percent but while you're picking up that 10 percent, computers
have gotten twice as fast and maybe with some other stuff that matters more for
optimization, like caches. I think it's largely a waste of time to do really well. It's
really hard; you generate as many bugs as you fix. You should stop, not take that
extra 100 percent of time to do 10 percent of the work.― (Seibel, 2009 S. 5805).
Armstrong rät deshalb Programmierern: „Don't tell people how fast something is
going to be before you've implemented it.― (Seibel, 2009 S. 2794).

3.5.2.6 Literate Programming


Das „Literate Programming” à la Knuth wird von den Interview-Partnern als
sinnvolles Konzept angesehen, aber kaum durchgeführt. Allerdings hat es alle
beeinflusst, wie sie Programme schreiben. Am besten fasst es Thompson zusammen:
„It's a great idea, but almost impossible to do in practice.― (Seibel, 2009 S. 5975).
Ingalls nennt auch den Grund: Die Methode nimmt zu viel Zeit in Anspruch. „I like
to work that way with something when I've got the time to finish it off.― (Seibel, 2009
S. 5139). Armstrong zeigt den Konflikt auf, den er beim Literate Programming hat.
In seinen Augen lenkt ihn die Dokumentation vom Programmieren ab: „I'm not
against the idea but I'm sort of impatient and wanted to write the code and not the
documentation.― (Seibel, 2009 S. 2936). Crockford sieht das Problem in der Masse
und der fehlenden Kultur. Es gibt zu wenig Entwickler, die Literate Programming
derzeit anwenden: „I'm not against it in principle. I just haven't had occasion to do it.
[…] There are a lot of great ideas in literate programming, but it's not the right bar:
there aren't enough other programmers hanging out there.― (Seibel, 2009 S. 2288).
Besonders interessant ist seine Haltung. Ein Programm, das lesbar ist, hat seiner
Meinung nach einen enormen Mehrwert: „The thing I like about the literate style is
that you're designing the program specifically for reading and I think that provides
tremendous value to the program.― (Seibel, 2009 S. 1466) Obwohl er die Methodik
beim Entwickeln selbst nicht anwendet: „[…] but I'm currently not doing any literate
programming.― (Seibel, 2009 S. 1438). Bloch bestätigt Knuths These, dass ein
94

Programm lesbar sein muss und im Wesentlichen ein Literaturwerk ist. „As Knuth
would say, a Program is essentially a work of literature. For whatever reason, I
realized even back then that a program has to be readable.― (Seibel, 2009 S. 2134).
Steele bestätigt, dass es seinen Stil beeinflusst hat, ein Programm lesbar zu
schreiben: „[…] It has influenced my style in that I think about those issues.― (Seibel,
2009 S. 4237). Knuth sieht es ebenfalls sehr praktisch und naiv. Die Methode hat
ihm geholfen und er hofft, dass es auch anderen hilft. Er schreibt allerdings anderen
nicht vor, dass lesbarer Code nur durch seine Methode entsteht. „I can't prove that
this is the best thing, but it sure works for me. Then you hope that other people will
try it and come to the same conclusion. But I don't like going out and telling people
what they ought to believe.― (Seibel, 2009 S. 7151).

3.5.2.7 Lesbarer Quellcode


Auch wenn Donald Knuths Literate Programming von den Interview-Partnern selbst
nicht angewendet wird, sind fast alle der Meinung, dass Entwickler für sich selbst
und Dritte lesbaren Code produzieren müssen. Zawinski beschreibt es treffend: „[…]
certainly one of the most important things is writing code you can come back to
later.― (Seibel, 2009 S. 105). Für Cosell gehört lesbarer Code zu den wichtigsten
Faktoren, wenn in Programmierteams gemeinsam gearbeitet wird. Das lauffähige
Programm allein ist nicht ausreichend. „Writing a program that work is a skilled
craft – now you have to program. Working programs are given.― (Seibel, 2009 S.
6770). Bloch schließt sich dem an: „[…] I realize it isn‘t just about making it work;
It‘s about producing an artifact that is readable, maintainable, and efficient.― Er
merkt zudem an, dass lesbarer Code schneller ausgeführt wird und wenn nicht, dass
lesbarer Code einfacher optimiert werden kann. „It's easier to optimize correct code,
than to correct optimized code.― (Seibel, 2009 S. 2177ff.). Norvig sieht das ähnlich,
wenn er die Leistung eines Entwicklers in der Gesamtheit betrachtet: „One of our
best search people is by no means our best programmer, in terms of how the code
looks.― (Seibel, 2009 S. 3913). Cosell differenziert dabei den Quellcode anhand
dessen, für wen er bestimmt ist. „The binary bits are what computers want and the
text file is for me.― (Seibel, 2009 S. 6767). Die Form des Quellcodes muss dabei für
das Team nachvollziehbar sein. Der Computer als Maschine benötigt nur die
95

Anweisungen. „[…] to the belief that computer-program source code is for people,
not for computers. computers don't care.― (Seibel, 2009 S. 6765).

3.5.2.8 Standards und Historie


Crockford nimmt als Einziger Stellung zu den Themen Standards und Historie. Er ist
der Meinung, dass Standards nicht durch ein Komitee verabschiedet werden, sondern
sich evolutionär entwickeln sollen. „[…] in that maybe the right approach to take to
standardization is to figure out which of those are the best though out, which are the
most maintainable, which are the most growable, and pick that. Rather than a
standards comittee trying to guess the best way to do it, we pick from examples in the
marketplace that is actually demonstrably the best way to do it.― (Seibel, 2009 S.
1612ff.). Desweiteren kritisiert er Entwickler, die sich nicht für die Herkunft von
Standards interessieren oder selbst welche schaffen wollen. Seiner Meinung nach
sollten Entwickler den Standardisierungsprozess aktiv mitgestalten und sich nicht auf
Komitees verlassen. „I Think we're tragically unaware of our history, and I'm often
really disappointed to see that people who are now practicing this craft have no
intellectual curiosity about where this stuff came from and just assume that some
committee got it right and presented them with a set of tools or languages, and all
they have to do is use properly.― (Seibel, 2009 S. 1612ff.). In Bezug auf die Historie
sieht Crockford den PC als Rückschritt. Seiner Meinung nach wurden viele heutige
Probleme der Vernetzung in der Timesharing Era bereits vor 20 Jahren gelöst. Der
größte Rückschritt ist für ihn, dass PCs von Grund auf nicht in ihrem Ursprung als
Multiuser-Systeme konzipiert wurden. „Progress isn't always forward. When we
leaped to the PC, we lost a whole lot of stuff. In the timesharing era, we had social
systems online. A timesharing system was a marketplace. It was a community and
everybody who was part of that could exchange email […] they were doing all this
stuff and all that got lost when went to PC. It took another 20 years or so to get back.
We also took a huge step backwards in terms backwards of security. Timesharing
systems were starting to understand how to defend the system from each other. We
went to PC, you owned your machine and everything had the same privileges, the
same rights to do whatever it had to do, and it turned out that not all the software
running in your machine is acting in your interest.― (Seibel, 2009 S. 1612ff.).
96

3.5.3 Methode
Das methodische Vorgehen wird ihm Rahmen der Dokumentation und Lesbarkeit
von Quellcode sowie dem Lesen von Quellcode in den Interviews angesprochen.
Dokumentiert wird dabei nur das Nötigste, außer der Quellcode wird von Dritten
benutzt. Lesbarer Code wird nicht nach bestimmten Regeln produziert, sondern
erfolgt, indem sich der Entwickler in Dritte hineinversetzt. Code Reading wird als
Methode des Voneinanderlernens gesehen, und um Fehler zu reduzieren.

3.5.3.1 Dokumentation
Armstrong unterscheidet die Art der Dokumentation als Einziger inhaltlich in den
Interviews. Für ihn ist der Quellcode die Antwort auf das zu lösende Problem. Eine
Dokumentation beschreibt hingegen das Problem. Beide Sichtweisen müssen zum
Verständnis des Quellcodes vorhanden sein. „The code shows me, what it does. It
doesn't show me what it's supposed to do. I think the code is the answer to a problem.
If you don't have the spec or you don't have any documentation, you have to guess
what the problem is from the answer.― (Seibel, 2009 S. 2925). Für Crockford ist ein
Programm erst dann fertig, wenn es dazu eine Dokumentation gibt, und grenzt sich
damit gegenüber der agilen Softwareentwicklung ab: „[…] I don't think a program is
finished until you've written some reasonable documentation. And I quite like a
specification. I think its unprofessional these people who say, – What does it do?
Read the code.― (Seibel, 2009 S. 2924). Thompson dokumentiert den Quellcode
knapp. Seine Methode ist es, „Usage Lines“ einzusetzen, falls er „Argumente“
vergisst, und er dokumentiert die Datei im Kopfbereich. Allerdings schreibt er auch
eine ausführliche Dokumentation, wenn sein Werk woanders eingesetzt wird oder
von jemand anders genutzt werden muss. „I'll put in a usage line if I forget the
arguments. And I'll put in a comment at the header about what the whole thing does.
But very, very brief. If it's part of a system or a library or something that's meant to
be published, then I'll take the time to document it. But otherwise, no.― (Seibel, 2009
S. 5787). Cosell hingegen ist der Meinung, dass Quellcode so geschrieben werden
sollte, dass er lesbar ist. Allerdings gibt sie zu, dass sie auch schwierige
Codebereiche zum besseren Verständnis dokumentiert: „I don't put a lot of
comments in my code because I think you should be writing your code so that it is
97

readable and your algorithms and thoughts are clear in the code. … The only place I
tend to put comments in my code is when my instinct says, – This particular piece of
code, […] doesn't clearly state what I'm trying to accomplish― (Seibel, 2009 S.
6797).

3.5.3.2 Readable Code


Die Interview-Partner verzichten auf Vorgaben bei der Erstellung von lesbarem
Quellcode, wie sie in Clean Code (Martin, 2008) aufgezeigt werden. Ihre Methode,
lesbaren Code zu verfassen, ist, sich beim Schreiben in die dritte Person
hineinzuversetzen und einen durchgängigen, eigenen Stil einzuhalten. Crockford
merkt im Kontext des Code Reviews an, dass Quellcode ordentlich, lesbar und im
einheitlichen Stil geschrieben werden sollte, damit er begutachtet werden kann.
„Another aspect is writing your code such that it can be read. Neatness counts, as it
turns out, and style is important. And all of those things will increase the quality of
the code base […].― (Seibel, 2009 S. 1333). Grundsätzlich sollte der Code dabei
einheitlich eingerückt sein und er empfiehlt Variablen nicht mit nur einem Wort zu
benennen. „The simplest is just being consistent in the presentation so you always
indent everything properly; you have white space in all the right places […] I tend to
use too many one-letter variable names, which I believe is a bad thing.― (Seibel,
2009 S. 1333). Cosell Methode, lesbaren Code zu schreiben, ist einfach, den Code
aus der Perspektive eines Dritten zu sehen: „You have to look at the program
through the eyes of a new programmer.‖ (Seibel, 2009 S. 6950). Gleiches rät auch
Knuth :”I don't have to present it in the form that the compiler wants to see it. I
present it in a form that I think is easiest for a reader to understand.― (Seibel, 2009
S. 7163).

3.5.3.3 Code Reading


Crockford sieht das „Code Reading“ als wichtige Methode an, damit Programmierer
voneinander lernen können. Zudem ist er der Meinung, dass hierdurch die Qualität
des Quellcodes maßgeblich erhöht wird (siehe auch These 3, S. 85). „One of the
things I‘ve been pushing is code reading. I think that is the most useful thing that a
community of programmers can do for each other – spending time on regular basis
98

reading each other‘s code.― (Seibel, 2009 S. 1311). Dem stimmt auch Steele zu, der
als Schüler beim MIT Zugriff auf den Quellcode von verschiedenen Projekten hatte
(zum Beispiel ITS, TECO oder Lisp) und deshalb Lisp für die IBM 1130
implementieren konnte. Gleichzeitig kritisiert er, dass Entwickler heute selten guten
Quellcode von anderen Entwicklern sehen und sich deshalb nicht weiterentwickeln:
„Part of the problem that we face nowadays, now that software has become valuable
and most software of any size is commercial, is that we don‘t have a lot of examples
of good code to read. The open source movement has helped to rectify that to some
extent.― (Seibel, 2009 S. 4223). Fritzpatrick sieht es ebenfalls als Methode, um
außerordentliche Entwickler besser einschätzen zu können, und zum Lernen. „[…] if
you really respect some programmer, go read some of their code. Maybe that‘ll make
you realize that they‘re mortal […]. Or you learn something about their code.―
(Seibel, 2009 S. 913).

3.5.4 Vorgehen
Das charakteristische Vorgehen setzt sich aus drei Teilbereichen zusammen. Erstens
werden die Programme typischerweise inkrementell entwickelt, wobei dabei nach
Van Vlient und Winter zuerst die Softwarekomponenten mit dem höchsten Risiko als
Erstes implementiert werden („build the hardest things first“). Zweitens, das
Vorgehen der Realisierung erfolgt in kleinen Teams. Die Kommunikation zwischen
den Teams wird über Schnittstellenbeschreibungen gelöst. Drittens, das Vorgehen
beim Refactoring Dritter erfolgt durch einen Rewrite des Codeabschnitts.

3.5.4.1 Inkrementelle Entwicklung


Die Software der Interview-Partner wurde inkrementell entwickelt. Das Design des
Programms entstand schrittweise während des Schreibens des Quellcodes. Ingalls
hatte für die erste Implementierung von Smalltalk als Spezifikation nur ein paar
Notizzettel von Alan Kay. Die erste Smalltalk-Implementierung begann er, indem er
angefangen hat, diese in Basic zu schreiben: „I just started typing in code.― Das
gleiche Vorgehen nutzte Crockford: „When I started working with Javascript, I
didn‘t read anything about it. I just started.― (Seibel, 2009 S. 1521) Thompson
schreibt vorher Datenstrukturen auf, beginnt aber auch sofort mit dem Schreiben –
99

bei falschen Designentscheidungen schreibt er die Codeabschnitte komplett neu. „I


usually write down data structures before I write down code. I don‘t write down
algorithms – no flowcharts, or stuff like that. […] I don‘t stick to code. […] I‘ll just
hack and go over it.― (Seibel, 2009 S. 5772). Zawinski beschreibt sein Vorgehen,
indem er in kleinen Schritten die Probleme löst. „Just figuring out how to get from
point A to point B – how to make the machine do what you want.― (Seibel, 2009 S.
366). Fritzpatrick gibt den Rat, Code inkrementell zu entwickeln, damit man in jeder
Stufe seinen Quellcode verifizieren kann. „[…]Try to figure out what‘s going on.
Learn how to write things incrementally so that at each stage you could verify it.―
(Seibel, 2009 S. 1128). Dabei werden die schwierigsten und risikoreichsten
Komponenten als Erstes implementiert. Die Mentalität entspricht dabei dem des
„Risk-driven-Modell“, des Spiralmodells oder dem Ansatz der inkrementellen
Entwicklung „Build the hardest thing first“. „But I've started with the hard bits or
the parts I was unsure of it and tried to implement those parts first. I try not to put off
anything hard or surprising to the end.― (Seibel, 2009 S. 910). Welche der
Komponenten oder Funktionen eines Programms als schwer oder leicht einzustufen
sind, hängt nach Crockford von der Erfahrung des Entwicklers ab. „Identify the hard
problems and then solve them. And then the easy problems, […] So threre‘s a bit of
experience there in classifying them as easy and hard.― (Seibel, 2009 S. 2918).

Thomspon, Fritzpatrick und Ingalls beschreiben das Vorgehen in ihren Projekten


sehr detailliert. Thompson schrieb ein Betriebssystem, um sein Dateisystem für die
PDP-7 testen zu können. Aus dem Betriebssystem ist Unix entstanden. „Halfway
through there that I realized it was a real time-sharing system. I was writing the shell
to drive the file system. And then I was writing a couple other programs that drove
the file system. And right about there I said, ‗All I need is an editor and I've got an
operating system.‗― (Seibel, 2009 S. 5829). Fritzpatrick hat Livejournal aus dem
Nutzungskontext heraus entwickelt. Die Funktionen des Systems sind dabei
inkrementell aus „Use Cases“ entstanden. Das Kernsystem wurde schrittweise um
Funktionen erweitert. „Commenting on LiveJournal was a practical joke. I was
checking my LiveJournal right before I ran into class. We had just introduced friend
pages and I saw something my friend wrote and it was really stupid and wanted to
make fun of him. ‗Oh, but I can‘t reply.‗ […] The whole security thing, like friends-
100

only posts and private posts, was because a friend wrote that he went to a party and
woke up drunk in a ditch the next day. His parents read it […].― (Seibel, 2009 S.
969). Ingalls beschreibt, dass er bei der Smalltalk-Implementierung zuerst mit einem
„Rapid Prototyp“ in Basic und danach inkrementell vorgegangen ist: „I remember
the first thing we got to run was six factorial. It‘s a really simple example but it
involves the process of dynamic lookup and creating new stack frames. And the once
you‘ve got that working, you come to understand how things are going to go and you
find out what‘s difficult. […] ‗OK, I see how this work, I‘m going to write it in
assembly code,‗ or whatever else. Then you suddenly realize, ‗Oh yeah, we need
automatic storage management […].‗ It‘s one thing after another.‖ (Seibel, 2009 S.
4817).

3.5.4.2 Vorgehensmodell
In den Interviews wurden verschiedene Arten des Vorgehens angesprochen, wie die
Interview-Partner die Software in ihren Projekten entwickelt haben. Insgesamt kann
festgestellt werden, dass die Aufteilung der Arbeitspakete sehr praktisch durch
Module in den Teams erfolgte. Die Kommunikation der Module erfolgt durch
Schnittstellen, die zwischen den Entwicklern vorher definiert wurden. Die
Teamgröße betrug in etwa zwei bis drei Personen.

Ingalls Zusammenarbeit mit seinen Kollegen erfolgte über definierte Schnittstellen.


Für die Arbeiten im Detail gab es keine Spezifikation. Die Probleme wurden in den
Augenblicken gelöst, in denen sie auftraten. „Either you agree on some interface, or
often I'll build some framework that's incomplete but that works for one example and
then it's obvious to someone else where their stuff would fit in. Or they've done that
and it's obvious to me where my stuff fits in. It's usually been in that concrete way,
rather than any kind of spec because we've usually been working on something that
nobody wrote down. It's all kind of been following the needs of the moment.― (Seibel,
2009 S. 4974). Zawinksi beschreibt, wie er jeden Tag mit seinen Kollegen die
Features des „Mail Readers“ aufteilte, die anschließend sofort implementiert wurden.
„I had a basic design down and I'd starting doing a little coding and every day or
every couple of days we'd look at the list of feature and I'd go " […] maybe I'll work
on that […] and he‘d go ‗OK, I‘ll work on that‗ and then we‘d go away. […] and we
101

just sort of divides up the pieces― (Seibel, 2009 S. 278). Das Design der OTP wurde
von drei Personen entwickelt. Armstrong beschreibt, dass sie morgens mit drei
Personen zwei bis drei Stunden lang die Anforderungen für den Tag spezifizierten
und anschließend das Arbeitspaket in zwei bis drei Stunden umgesetzt hatten. Eine
Person schrieb die Dokumentation, zwei Personen implementierten die Funktionen.
Die erste Version des Frameworks hatten sie in zehn bis zwölf Wochen fertiggestellt.
Das Team wurde erst dann um weitere vier Entwickler erweitert (Seibel, 2009 S.
2906ff.). Zawinski beschreibt eine für ihn optimale Entwicklungsabteilung ähnlich.
Er würde eine Entwicklungsabteilung in kleine Teams von drei Personen
organisieren. Das Projekt würde in Module aufgeteilt werden und jedes Team würde
ein Modul entwickeln. Damit beschreibt er ein Prozessmodell ähnlich dem Feature
Driven Development, allerdings ohne ein Rollenmodell: „I think you want to
arrange for there to be no more than three or four people working really closely
together on a day-today basis. Than that can scale up a lot. Say you've got a project
where you can divide it up into twenty-five really distinct modules. Well, you can
have tewnty-five tiny teams – maybe that's a little much. Say ten. And as long as they
can coordinate with each other, I don't think there's a whole lot of limit to how big
you can scale that. Eventually it just starts looking like multiple projects instead of
like one project.― (Seibel, 2009 S. 513). Wie bei Ingalls würde die Kommunikation
der einzelnen Module über definierte Schnittstellen erfolgen, auf die sich die Teams
einigen müssten. „There's got to be agreement about what the interface between
modules is. For that very modular approach to work at all, the interface between
modules has to clear and simple.‖ (Seibel, 2009 S. 524). Bloch gibt an, dass Code
vor der eigentlichen Implementierung der API geschrieben werden sollte. Ansonsten
verschwendet man Zeit für die Implementierung einer API, die nicht genutzt wird.
„But the fundamental rule is, write the code that uses the API before you write the
code that implements it. Because otherwise you may be wasting your time writing
implementation code that won‘t get used.― Zudem empfiehlt er, erst dann die
Dokumentation für die API zu erstellen, nachdem sie benutzt wurden. Ansonsten
dokumentiert man eine fehlerhafte API. „In fact, write the code that uses the API
before you even flesh out the spec, because otherwise you may be wasting your time
writing detailed specs for something, that‘s fundamentally broken.― (Seibel, 2009 S.
102

2260). Deutsch beschreibt das Vorgehen, wie er APIs während der Entwicklung
definiert. Dabei ist er wie Bloch sehr praktisch. Er schaut, welche Funktionen in
welchem Umfeld welchen Input/Output benötigen, und welche Funktionen hierdurch
ausgelöst werden. „[…] I found that when sitting down to write any piece of code,
more and more the question I would ask myself first is, ‗Ok, what's the interface
between this and everything around it going to look like? What gets passed in? What
gets passed out? How much of a task should be on which side on an interface?‗―
(Seibel, 2009 S. 5372).

3.5.4.3 Refactoring
Das Refactoring des eigenen Quellcodes oder den eines von Fremden erstellten
erfolgt durch einen kompletten „Rewrite“. Zawinski bezieht dies nicht nur auf das
Refactoring an sich, sondern auch auf die Verwendung von Quellcode dritter. Dabei
führt er zwei Argumente auf: Erstens, das Schreiben des Quellcodes erfolgt
schneller, als den Quellcode von Dritten zu verstehen, und zweitens werden nur die
Funktionen implementiert, die er wirklich benötigt. „[…] but when you inherit code
from someone else, sometimes it's faster to write your own than to reuse theirs.
Because it's going to take a certain amount of time to understand their code and
learn how to use it and understand it well enough to be able to debug it. Where if you
started from scratch it would take less time. And it might do 80 percent of what you
need, but maybe that's the 80 percent you actually need.― (Seibel, 2009 S. 339).
Cosell beschreibt ein ähnliches Vorgehen beim Fixen von Fehlern im Code von
Dritten. Er implementiert die fehlerhafte Funktion komplett neu, weil er den Code
von Dritten in der Regel nicht versteht. „How did you fix the bug? – my Answer
would have been, – I couldn‘t understand the code well enough to figure out what it
was doing, so I rewrote it.― (Seibel, 2009 S. 6535). Crockford liest Code von Dritten,
indem er ihn „refactored“. „I'll throw it in a text editor and I'll start fixing it. […]
Morningstar taught me to do this. He's brilliant at refactoring other people's code
and that's the approach he takes and I find it works.― (Seibel, 2009 S. 1365).
103

3.5.5 Ziele
Peter Seibel hat in den Interviews keine konkrete Frage zu den Zielen gestellt. Ingalls
hat als Einziger konkret in den Interviews ein Ziel genannt. Sein Ziel ist, es zeitnah
ein lauffähiges Programm zu erschaffen. Das Programm muss im erstem Schritt nicht
fehlerfrei sein, sondern lauffähig, damit er sieht, wie es sich verhält. „In the spectrum
of implementers, I probably err on the side of just making things happen. A lot of that
is because I get so much of a thrill bringing things to life that it doesn't even matter if
it's wrong at first. The point is, that as soon as it comes to life it starts telling you
what it is.― (Seibel, 2009 S. 4824). Ähnlich beschreibt es Zawinski, der versucht, so
früh wie möglich ein lauffähiges Programm zu erhalten, damit er sich auf ein
Problem konzentrieren und dieses gegenüber anderen priorisieren kann. „I find that
getting something on the screen as soon as possible really helps focus the problem
for me. It helps me decide what to work on next. Because if you‘re just looking at that
big to-do list it‘s like, eh, I don‘t know which one I should do-does it matter which
one I do? But if there‘s something you can actually look at […], it‘s like OK, there!―
(Seibel, 2009 S. 399).

Ein weiteres Ziel wird zwischen den Zeilen vermittelt. Es wird immer die einfachste
aller möglichen Lösungen favorisiert, die schnell zum Ziel führt. Bloch führt hierzu
auf „[…] when in doubt, leave it out […]― (Seibel, 2009 S. 2279). Thompson nutzt
den einfachsten Lösungsweg, um Fehler zu vermeiden: „I'll do it as simply as
possible the first time. […] Building a very complex algorithm for something that's
never run is just stupid. […] It's a bug generator.― (Seibel, 2009 S. 5891). Die
Einfachheit seiner Problemlösung zieht sich bis zum Quellcode durch. „And if
there‘s one thing that characterizes my code, it‘s that it‘s simple choppy, and little.
Nothing fancy. Anybody can read it.― (Seibel, 2009 S. 5898). Cosell sieht dies
ähnlich und empfiehlt, immer erst die einfachste Lösung zu nehmen, um ein
Ergebnis zu erhalten: „Code it as lucidly, as easy to read, as crystal-clear as you
can. Do it the simple way. And then, if it needs to be sped up, we‘ll deal with it
later.― (Seibel, 2009 S. 6960).
104

3.5.6 Projekterfolg
Die Interview-Partner blicken auf einem enormen Erfolg der Softwareentwicklung
zurück. Die aufgeführten Personen in der Tabelle haben maßgeblich an der Software-
Entwicklung teilgehabt. Die Projekte fallen unter das Softwareengineering und
gelten nicht als „Programming-in-the-small“ oder „Student System“, weil sie in einer
Projektorganisation entstanden sind und alle, ohne Ausnahme, „Industrial Strength
Software Systems“ sind. Die von den Interview-Partnern entwickelte Software hat
nachhaltig die Informatik und die gesamte Software-Industrie weltweit beeinflusst
und gestaltet.

Programmierer Programme

Jamie Zawinski Netscape Browser, Mail Reader

Brad Fritzpatrick LiveJournal, memcached

Douglas Crockford JSON

Brendan Eich JavaScript

Joshua Bloch Java Collections Framework

Joe Armstrong Erlang, OTP

Simon Pyton Jones Haskell, GHC

Dan Ingalls Smalltak, Bitblt

Peter Deutsch Lisp (PDP-1), Genie, Ghostscript

Ken Thompson Unix, B

Donald Knuth TeX, METAFONT

Tabelle 2: Projekterfolge der Interview-Partner in „Coders at Work“ (Seibel, 2009)


105

3.6 Mentalität
Verdichtet man die Charakteristika zu einem übergeordneten Denk- und
Verhaltensmuster, lässt sich ein Stereotyp im positiven Sinne ableiten.

Aufgeführte Charakteristika Abgeleitete Mentalität

Thesen

Shipping is a feature, your product must have it. Die Fertigstellung des Produkts steht im
Mittelpunkt aller Entscheidungen. Eine
fehlerfreie 80 % Lösung aus Benutzersicht ist für
die Fertigstellung des Programms ausreichend.

Die Komplexität eines Problems offenbart sich Das Softwaredesign entsteht erst während der
erst in der Implementierung. Entwicklung des Programms. Die Komplexität
des Details einer Software ist ansonsten nur
schwer beherrschbar.

An hour code reading is worth two weeks of QA. Eine effiziente Qualitätssicherung des
Quellcodes kann während des Projekts durch
interne Code Reviews erfolgen.

„Unit Tests“ lösen das Kernproblem nicht. Ein „Unit Test“ hilft nicht weiter, wenn die
Lösung eines Problems nicht bekannt ist.

The smartest people in the organization Eine API entsteht organisch während der
shouldn‟t design APIs or GUIs or languages. Entwicklung eines Programms.

Haltung

Wasserfallmodell Ein agiles Vorgehen ist, mit den heute zur


Verfügung stehenden Entwickler-Werkzeugen,
zeitgemäß.

UML UML zur Problembeschreibung ist nützlich, aber


nicht notwendig. Ein Problem muss direkt in der
Programmiersprache abbildbar sein.

Wiederverwendung Objektorientierte Sprachen besitzen eine


geringere Wiederverwendbarkeit als imperative
Sprachen.

Over Engineering Abstraktionsebenen delegieren Probleme nur


weiter und lösen sie nicht. Credo: „Staying close
to the metal“.

Code-Optimierung Programmierer optimieren immer nur den


interessantesten und nicht den relevantesten
Code. Credo: „Don't tell people how fast
something is going to be before you've
implemented it.“
106

Aufgeführte Charakteristika Abgeleitete Mentalität

Haltung (Fortsetzung)

Literate Programming Literate Programming besitzt eine enorme


Relevanz, wird in der Praxis aber nicht
angewendet.

Readable Code Der Quellcode gehört dem Entwickler, der


Binärcode dem Computer. Die ausführbare Datei
ist nichts wert, wenn der Quellcode nicht lesbar
ist.

Standards und Historie Standards in der Informatik sollten sich


evolutionär entwickeln und nicht über ein
Komitee verabschiedet werden. Programmierer
sollten aktiv den Standardisierungsprozess
mitgestalten. Die Informatik hat sich seit der
Timesharing-Ära nicht weiterentwickelt.

Methode

Dokumentation Der Quellcode ist die Antwort, die


Dokumentation ist die die Beschreibung des
Problems.

Readable Code Quellcode sollte ordentlich, lesbar und im


einheitlichen Stil geschrieben werden. Code
sollte immer aus der Perspektive eines Dritten
verfasst werden.

Code Reading Code Reading im Team erhöht die Qualität des


Quellcodes. Das Lernen von anderen
Entwicklern beginnt mit dem Lesen dessen
Quellcodes.

Vorgehen

Inkrementelle Entwicklung Programme entstehen inkrementell. Die


schwierigsten und risikoreichsten Komponenten
werden als Erstes entwickelt. Starte mit dem
Schreiben des Quellcodes.

Vorgehensmodell Das Programm wird in Modulen aufgeteilt. Jedes


Modul entwickelt ein Entwickler oder -team. Die
Kommunikation findet über Schnittstellen statt.
Module sollten nicht länger als zwei bis drei
Tage für die Realisation benötigen.

Refactoring Der Quellcode erhält beim Refactoring einen


Rewrite. Dies bezieht sich auch auf die
Wiederverwendung von Quellcode Dritter. Bei
der Wiederverwendung werden nur die
Funktionen implementiert, die im Kontext der
Wiederverwendung benötigt werden.
107

Aufgeführte Charakteristika Abgeleitete Mentalität

Ziele

Lauffähigkeit Die Entwicklung sollte immer an einem


lauffähigen Programm erfolgen, um zu sehen,
wie es sich verhält. Die Priorisierung der
Aufgaben erfolgt auf Basis des lauffähigen
Programms.

Einfachheit Es wird immer die einfachste aller möglichen


Lösungen favorisiert, um schnell ein Ergebnis zu
erhalten. Komplexere Lösungen werden erst
implementiert, wenn die einfache Lösung
funktioniert.

Tabelle 3: Abgeleitete Mentalität des „Duct Tape Programmers“ auf Basis der aufgeführten Charakteristika

Crockford benennt in seinem Interview auch die mögliche Ursache, warum es den
„Duct Tape Programmer“ als Typus gibt. Programmieren ist schwierig. Der Grund:
Entwickler müssen in den meisten Fällen als Erste eine Lösung zu einem Problem
finden. Wenn es das Problem schon einmal gab und der Quellcode verfügbar ist,
wird versucht, den Quellcode wiederzuverwenden. Wenn es nichts Vergleichbares
gibt, muss der Programmierer dem Problem allein oder zu zweit („Pair
Programming“) entgegentreten. Die Mentalität hilft dem Entwickler dies täglich zu
bewältigen. „Part of what makes programming difficult is most of the time we're
doing stuff we've never done before. If it was stuff that had been done before we'd be
reusing something else. For most of what we do, we're doing something that we
haven't done before. And doing things you haven't done before is hard.― (Seibel,
2009 S. 1406)

3.7 Kritische Würdigung


Festzustellen ist, das Spolsky den Duct Tape Programmer in seinem Artikel sehr
passend und erstaunlich genau beschrieben hat, obwohl er nur das erste Interview
gelesen hatte. Spolskys Artikel wurde zudem beeinflusst durch Duct Tape
Programmer die er aus seinem persönlichen und professionellen Umfeld kannte.
108

„Well, I wrote that article after reading Zawinski's interview, but I have certainly
known many duct tape programmers in my career and know many by reputation.―29

Ob Peter Seibel ein Remake von Lammers „Programmers at Work“ gewollt hat, ist
nicht zu erkennen. Konzeptionell sind sich beide Bücher ähnlicher als Biancuzzis
„Masterminds of Programming“. Insgesamt sind die Bücher mit Interviews von
außergewöhnlichen Informatikern eine Pflichtlektüre für Programmierer und
Personen, die in Softwareprojekten wirken. Zudem dient das Buch sehr gut als
Lehrmaterial. Viele Aussagen in den Interviews besitzen enorme Praxisrelevanz. Es
darf auch nicht vergessen werden, dass die erste Generation von Programmierern in
den nächsten Jahren wegfallen wird. Für die Weitergabe von Wissen und um ein
Gefühl für die Mentalität der Leute zu erhalten (welche die Informatik maßgeblich
geprägt haben), ist das von den Autoren der Bücher gewählte Interviewformat sehr
gut geeignet.

Insgesamt sind Duct Tape Programmer sehr praktische Entwickler, die im Kern ein
lauffähiges Programm erschaffen wollen. Daneben besitzen die Personen eine hohe
Selbstreflektion. Eich beschreibt sehr gut den Konflikt, den ein Programmierer bei
seiner täglichen Arbeit durchläuft. Dabei spricht er von dem Spannungsfeld zwischen
dem Optimisten und dem Paranoiden. Beide Charaktertypen sind seiner Meinung
nach notwendig, um ein guter Entwickler zu sein. „I‘ll have made some kind of
happy pony land in my head, where I forgot some important problem. That‘s always
a challenge because programmers have to be optimists. We‘re supposed to be
paranoid, neurotic, Woody Allen types who are always worried about things, but
really you wouldn‘t get anywhere in programming if you were truly paranoid―
(Seibel, 2009 S. 2087). Bloch beschreibt selbstreflektierend, dass Entwickler
Denksportaufgaben lieben, aber im Grunde nicht daran interessiert sind, dass jemand
ihre Lösung versteht. Er spricht hier von dem Empathie-Gen, das Entwickler für sich
entdecken und entwickeln müssen. „Keep that empathy gene on when you‘re
designing your APIs, but then, in order to make them run bloddy fast, you can freely
descend into the puzzle place.― (Seibel, 2009 S. 2555). Knuth nimmt Managern

29
Der Autor dieser Arbeit hat Joel Spolsky persönlich per E-Mail gefragt, inwieweit der Artikel von seinem
persönlichen und professionellen Umfeld beeinflusst wurde. Das Zitat ist die Antwort auf die Frage.
109

nachhaltig die Hoffnung das Schätzungen von Programmierern ernst genommen


werden sollten und der Realität entsprechen. „I think it is always going to be true
that a person who manages programmers should not expect it to be predictable.―
(Seibel, 2009 S. 7147). Knuth begründet dies mit der Komplexität, die sich oft erst
während der Implementierung offenbart, und nimmt damit Bezug auf These 2 (siehe
Kapitel 3.5.1.2, S. 83). Desweiteren äußert Donald Knuth in seinem Interview eine
generelle Systemkritik. „Today we don't do anything new, we just plug existing
things together.‖ (Seibel, 2009 S. 7430). Ein Duct Tape Programmer würde sich mit
diesem Zitat nicht identifizieren. Der „Ingenieur“ oder ein „Industrieprogrammierer“
hingegen schon, weil Software damit ingenieursmäßig entwickelt werden kann.
Betrachtet man die Aussage mit Hilfe einer Methaper, wird der Unterschied beider
Welten deutlicher. Duct Tape Programmer bauen keine Brücken, sondern erfinden
sie. Softwareentwickler bauen Brücken mit Hilfe von Kapselung, Frameworks oder
Libraries, weil sie ihnen die Sicherheit geben, dass jemand die Brücke schon einmal
gebaut haben könnte.

Besonders interessant ist die Sichtweise von „Duct-TapeProgrammer“ auf die


Qualitätssicherung von Softwareprodukten. Ein Mangel darf in der Software eines
„Duct Tape Programmers“ nicht auftreten, Fehler allerdings schon. Letzteres wird
mit der „Worse is Better“-Perspektive gerechtfertigt. Insgesamt haben Duct Tape
Programmer ein gutes Gespür, welcher Mix an Qualitätssicherungsinstrumenten
eingesetzt werden sollte. Dies betrifft insbesondere die Auswahl von Inspektionen
und Prüfungen. Anders wie Zawinski es in seinem Interview darstellt, haben Duct
Tape Programmer im Grunde nichts gegen den Einsatz von Test Driven
Development. Sie sehen es einfach als Hilfsmittel, um Software ohne Mangel
herstellen zu können, und nicht als den heiligen Gral für fehlerfreie Software.

4 Mentalität als Einflussgröße des Software-Engineerings


Damit eine Einflussgröße im Allgemeinen festgestellt werden kann, muss vorher eine
Messung erfolgt sein. Für eine wissenschaftliche Messung müssen bestimmte
Voraussetzungen und ein bestimmtes Vorgehen erfüllt werden, die in diesem Fall
soziologischer Natur und damit nicht Gegenstand dieser Arbeit sind. Erschwerend
ist, dass bisher keine Messung stattgefunden hat. Die Arbeit wird deshalb die
110

Einflussgröße nur qualitativ aufgrund der inhaltlichen Aussagen aus den Interviews
feststellen können. Hierbei wird die herrschende wissenschaftliche Meinung mit den
Aussagen aus den Interviews verglichen, um mögliche Abweichungen aufzuzeigen.
Eine Einflussgröße aufgrund der abgeleiteten Mentalität kann bei dem derzeitigen
Wissensstand nicht erfolgen, sondern nur vermutet werden.

Die inhaltlichen Aussagen aus den Interviews werden hierzu in zwei Themenblöcke
unterteilt. Erstens: Die Antworten aus Peter Seibels Fragen, die Relevanz auf das
Software-Engineering besitzen (siehe Kapitel 3.4.1, S. 80). Hier wird ein besonderer
Fokus auf die Vorgehens- und Prozessmodelle gelegt. Zweitens: Aussagen aus den
Interviews, die in dem dritten Kapitel keiner Charakteristik zugeordnet werden
konnten, aber Themenfelder des Software-Engineerings betreffen. Diese wurden
nicht explizit von Peter Seibel erfragt und stammen deshalb aus dem Kontext anderer
Antworten.

Unabhängig von den Aussagen aus den Interviews wird zudem betrachtet, wie der
Stereotyp des „Duct Tape Programmers“ die Softwareentwicklung eingeordnet
werden könnte.

4.1 Interviewfragen mit Relevanz für das Software-Engineering


Wie bereits in Kapitel 3.4.1 (S. 80) aufgeführt, hat Peter Seibel in den Interviews vier
Fragen gestellt, mit direktem Bezug auf Themenfelder des Software-Engineerings.
Diese Fragen werden in diesem Kapitel untersucht. Besonders betrachtet wird die
erste Frage „How do you design software?“, da sie Hinweise auf neue Vorgehens-
und Prozessmodelle geben könnte.

4.1.1 How do you design software?


Die Antworten auf diese Frage sind bereits in vorherigen Kapiteln aufgeführt
worden, wie zum Beispiel in Kapitel 3.5 (S. 81 ff.) „Charakteristiken“. Es wurden
deshalb viele Querverweise in diesem Kapitel verwendet. Diese sind für das
Verständnis nicht relevant, sondern dienen nur als zusätzliche Information.
111

Das Kapitel konzentriert sich auf den Abgleich der Aussagen aus den Interviews mit
den im Software Engineering herrschenden Vorgehens- und Prozessmodellen. Wie
bereits in Kapitel 2.2 (S. 27) erwähnt, bildet die methodische Auseinandersetzung
mit dem Softwareherstellungsprozess das Kernstück des Software-Engineering oder
wird dem sogar gleichgesetzt. Deshalb findet in dieser Arbeit auch ein ausführlicher
Abgleich statt.

Als Vorgehensmodell wird Rapid Protoping (siehe auch Kapitel 2.2.2.4, S. 32) und
inkrementelle Entwicklung (siehe auch Kapitel 2.2.2.7, S. 35) benutzt. Zum
Fertigstellen jedes Inkrements wird das Vorgehen der Iteration benutzt.

Das Rapid Prototyping dient in erster Linie als Ziel, zeitnah ein lauffähiges
Programm zu schaffen (siehe auch Kapitel 3.5.5, S. 103). Bei der Klassifizierung
nach Floyd würde dies dem evolutionären Prototyping entsprechen, weil die
Codebasis kontinuierlich weiterentwickelt wird. Ein Duct Tape Programmer tendiert
dabei eher vertikal den Prototypen zu entwickeln als horizontal, weil er die Software
in Schritten funktional und nicht in Schichten erweitert. Das Vorgehen hängt in dies
Fall aber davon ab, welche der beiden Varianten die einfachste und schnellste ist.

Das Vorgehen der inkrementellen Entwicklung lässt sich an drei typischen Punkten
feststellen. Erstens wird bei der Entwicklung im ersten Schritt versucht, ein
Kernsystem zu entwickeln und dieses schrittweise funktional zu erweitern. Das
Kriterium der Auslieferung und Inbetriebnahme jedes Inkrements muss unter der
Perspektive des evolutionären Prototyping gesehen werden. Duct Tape Programmer
tendieren durch die erste These (siehe Kapitel 3.5.1.1, S. 81) dazu, ein Produkt
zeitnah fertig zu stellen und mittels Benutzerfeedback weitere Inkremente zu
entwickeln. Zweitens: Es wird versucht, die schwierigsten Komponenten mit dem
höchsten Risiko als Erstes zu implementieren (siehe Kapitel 3.5.4.1, S. 98). Drittens:
Aus den Interviews ist nicht zu erkennen, dass die Software-Projekte, an denen die
Interview-Partner gearbeitet haben, einen definierten Endzustand hatten. Dies kann
damit begründet werden, dass die Projekte, in denen die Interview-Partner gearbeitet
hatten, Innovationsprojekte innerhalb der Informatik darstellten (siehe Kapitel 3.5.6,
S. 104). Zum Beispiel herrschte bei der ersten Smalltalk-Implementierung in Basic
bei den Programmierern keine Klarheit darüber, wie umfangreich das Projekt ist und
112

ob die Idee von Alan Kay sich überhaupt umsetzen ließe (Seibel, 2009 S. 4811 ff).
Die einzelnen Inkremente werden iterativ entwickelt. Die Iteration bezieht sich dabei
immer auf das lauffähige Programm und dient zudem der Priorisierung für die
Entwicklung weiterer Inkremente (siehe Kapitel 3.5.5, S. 103).

Insgesamt ähnelt das Vorgehensmodell sehr stark dem des Spiralmodells, wobei das
Vorgehen der vier Aktivitäten nicht formal abläuft. Identisch ist die Planung pro
Zyklus (siehe Kapitel 3.5.4.1, S. 98).

Das Prozessmodell nutzt Prinzipien und Methoden aus dem Timeboxing-Modell von
Jalote (siehe Kapitel 2.2.3.2, S. 40), Extreme Programming (siehe auch Kapitel
2.2.3.5, S. 48) und Feature Driven Development (siehe Kapitel 2.2.3.6, S. 54).

Das Timeboxing-Modell nutzt Prinzipien der ersten These (siehe Kapitel 3.5.1.1, S.
81). Dabei wird der Umfang eines Inkrements aufgrund der verfügbaren Zeit
definiert. Das Timeboxing-Modell ist damit das einzige Modell, in dem Zeit als ein
wesentlicher Faktor für die Projektorganisation und den Projektumfang gilt. Selbst
agile Prozessmodelle wie Scrum oder Extreme Programming richten die
Projektorganisation nicht an der verfügbaren Zeit aus, sondern an den zu
realisierenden Funktionen. Die Betrachtungsweise, Funktionen an
Fertigstellungszeitpunkte zu knüpfen, ist bei dem Timeboxing-Modell einzigartig.

Desweiteren finden sich Übereinstimmungen bei Extreme Programming. Die


Extreme Programming-Werte werden gelebt, besonders der Wert Einfachheit (siehe
auch Kapitel 3.5.5, S. 103). Allerdings wird die Kommunikation mit Hilfe von
Dokumenten nicht als zweitrangig angesehen (siehe Kapitel 3.5.3.1, S. 96). Duct
Tape Programmer dokumentieren durchaus, wenn das Werk woanders eingesetzt
wird. Betrachtet man die Extreme Programming-Prinzipien, so werden diese im Kern
gelebt. Hier sind insbesondere die Prinzipien inkrementeller Veränderung, um die
Komplexität zu beherrschen (siehe Kapitel 3.5.1.2, S. 83), und gezielte Experimente
durchzuführen (siehe Kapitel 3.5.4.1, S. 98). Bei den Managementkonzepten besteht
der wesentliche Unterschied darin, dass der Kunde nicht im Mittelpunkt steht
(Seibel, 2009 S. 2238). Dies trifft auch auf das Planungsspiel zu. Das Programm in
kurzen Release-Zyklen zu entwickeln, ist Teil des Vorgehensmodells eines „Duct
113

Tape Programmers“. Bei den Teamkonzepten finden sich kaum Übereinstimmungen,


weil diese aus Sicht eines „Duct Tape Programmers“ individuell abhängig vom
Projekt und vom Team sind. Dies betrifft insbesondere „Code Ownership“ (siehe
Kapitel 4.1.3, S. 117) und die laufende Integration, wenn Unit Test nicht genutzt
werden (siehe auch Kapitel 4.2.3, S. 123). Bei den Programmierkonzepten wird
testgetriebene Entwicklung und Pair Programming abhängig davon genutzt, ob es im
Projekt sinnvoll ist (siehe Kapitel 4.2.2, S. 122 und 4.2.3, S. 123). Das Refactoring
wird als Konzept genutzt. Allerdings gibt es hierzu ergänzende Ansichten, was
Zeitraum, Umfang und Dokumentation betrifft (siehe auch Kapitel 4.2.4, S. 124).

Der Entwicklungsprozess entspricht eher dem Feature Driven Development. Ingalls,


Zawinski und Armstrong beschreiben die Organisation des Entwicklungsprozesses,
indem sie das Programm in Module aufteilen und an Entwickler verteilen. Die
Kommunikation der realisierten Module erfolgt über vorher definierte Schnittstellen.
Dieses Prinzip verfolgt Feature Driven Development ebenso (siehe auch Kapitel
3.5.4.2, S. 100). Der wesentliche Unterschied ist erneut die Kundensicht. Duct Tape
Programmer definieren die Module nicht aus Kunden-, sondern Entwickler-
perspektive. Das Ergebnis der Modulaufteilung kann aber durch das Vorgehen des
Prototypisierens ähnlich sein, weil die Lauffähigkeit der einzelner Module im
Mittelpunkt steht (Seibel, 2009 S. 245). Gekapselte Funktionen des Feature Driven
Development werden nach einem formaleren, aber ähnlichen Prinzip identifiziert und
in Prototypen realisiert. Aufgrund der ersten These priorisieren Duct Tape
Programmer Module vom Denkmodell eher aus der Sichtweise von Feature Driven
Development, also „must have“, „nice to have“, „add it if we can“ und „future“. Die
Realisierungszeiträume werden in den Interviews von Zawinksi, Ingalls und
Armstrong auf ein bis drei Tage beschränkt und orientieren sich damit an Extreme
Programming oder Scrum (siehe Kapitel 3.5.4.2, S. 100). Die in Feature Driven
Development beschriebene „Class Ownership“ ist abhängig vom Projekt und Team
(siehe Kapitel 4.1.3, S. 117). Grund für den Feature Driven Development ähnlichen
Entwicklungsprozess kann der Umstand sein, dass die Interview-Partner in der Regel
in der Softwareproduktentwicklung tätig waren (siehe auch Kapitel 3.5.5, S. 103).
Ob ein Rollenmodell in dem Entwicklungsprozess bei den Interview-Partnern
existiert hat, ist aus den Interviews nicht zu erkennen und damit unklar.
114

Festzustellen ist, dass Duct Tape Programmer zwar ein eigenes Vorgehens- und
Prozessmodell besitzen, Facetten dessen aber bereits in anderen Vorgehens- und
Prozessmodellen vorkommen. Wesentlicher Unterschied zu allen anderen Modellen
ist, dass Duct Tape Programmer mit Menschenverstand Prinzipien, Methoden und
Werkzeuge projekt- und teamabhängig wählen und einsetzen. Zudem kommen sie
mit jedem Modell aus. Die Ausnahme bildet hier das Wasserfallmodell (siehe
Kapitel 3.5.2.1, S. 88).

Zawinskis beschriebenes Modell (siehe Kapitel 3.5.4.2, S. 100) ist im Kontext zu


James Coplien „The Pattern language“ (Coplien, 1998) besonders interessant.
Zawinski zeigt hier ein mögliches Vorgehensmodell für das in „Pattern 3“
beispielhaft beschriebene „Solo Virtuoso“ und die in „Pattern 6“ beschriebenen
„Domain Expertise in Roles“ auf. Beide gehen in „Pattern 9: Developer Controls
Process“ auf (Coplien, 1998 S. 253 ff.). Zudem beschreibt Zawinski in seinem
Interview, dass die Kommunikation zwischen den einzelnen Programmierern mittels
definierter Schnittstellen erfolgen müsste (Seibel, 2009 S. 277). Diese Art von
Entwicklungsprozess fördert das in „Pattern 17“ beschriebene Code Ownership und
entspricht dem „Conway‟s-law-in-the-small“30 (Coplien, 1998 S. 267 ff.).

Desweiteren kann festgestellt werden, dass keines der bekannten Software-


Engineering-Modelle eine standardisierte Kommunikation von Modulen über
Schnittstellen als Kommunikationsinstrument erwähnt.

4.1.2 Do you ever do any pair programming?


Armstrong macht den Einsatz der Paar-Programmierung abhängig von der
Qualifikation der Entwickler. Dabei stellt er drei unterschiedliche Szenarien auf.

Erstens: Wenn zwei gleichwertig qualifizierte Entwickler Pair Programming als


Methode nutzen, um ein Problem zu lösen, für das beide keinen Lösungsansatz
besitzen. In diesem Szenario hält Armstrong die Methode für hilfreich. „So if you

30
Nach Coplien ist “Code Ownership” das Resultat hervorgerufen durch Schnittstellen innerhalb einer
Architektur („to have ownership, there must be interfaces“) und beschreibt es als “Conway‟s-law-in-the-small”.
Nach Tim Born gibt es zudem eine Gemeinsamkeit zwischen „Code Ownership“ und Objekt-Orientierter-
Programmierung, aufgrund der Kapselung von Software-Komponenten. (Coplien, 1998 S. 267ff)
115

don‘t know what you‘re doing then I think it can be very helpful with someone who
also doesn‘t know what they‘re doing.― (Seibel, 2009 S. 2884). Eine weitere
Methode, die im Zusammenhang des Pair Programming bei Entwicklern auf gleicher
Augenhöhe genannt wird, sind „Pair Debugging Sessions“. Die Methode sieht vor,
dass Entwickler eigenständig und separat voneinander Quellcode/Systemmodule
schreiben und diesen anschließend zusammen debuggen. Hierbei werden in den
Interviews zwei Arten genannt. Ingalls führt das Debugging mit dem Programmier-
kollegen durch. Ingalls: „Usually I‘ve been on my own or working on a separate
part. There are lots of projects on which I‘ve worked with others, and many intense
pair debugging sessions.― (Seibel, 2009 S. 4972). Während Bloch und Norvig
angeben, dass der jeweils andere Entwickler den Quellcode des anderen debugged.
Im Gegensatz zum Refactoring passt der Kollege den Code an seine Bedürfnisse an
(Schnittstellen, Funktionen) und überprüft dabei die Lauffähigkeit. Bloch: „I love
Buddy Programming where you‘re working with someone Else but not on the same
keyboard. You‘re writing different parts of the system – you trade the code back and
forth.‖ (Seibel, 2009 S. 2525) Norvig: ―If you have two good programmers, it‘s
better for them to work independently and then debug each others work afterwards
[…].― (Seibel, 2009 S. 3697).

Zweitens: Wenn die Qualifikationen der Entwickler leicht unterschiedlich sind, kann
der schwächere Entwickler beim Paar-Programmieren durch Beobachtung von dem
Besseren lernen. Thompson führt hierzu aus: „If you have one programmer who‘s
better than the other one, then there‘s probably benefit for the weaker programmer
or the less experienced programmer to observe the other one.― (Seibel, 2009 S.
2885).

Drittens: Wenn die Qualifikation beider Entwickler zu weit auseinander liegen,


sollte Pair Programming nur unter bestimmten Bedingungen erfolgen, weil sich sonst
der schwächere Programmierer dumm fühlt. „[…] But if the gap is too great then
they won‘t learn, they‘ll just sit there feeling stupid.― (Seibel, 2009 S. 2886),
argumentiert Armstrong. Bloch und Norvig relativieren dies allerdings, indem sie
bestimmte Rahmenbedingungen aufzeigen, in denen Paar-Programmierung bei stark
unterschiedlichen Qualifikationen funktionieren kann. Zum einen sollten bei stark
116

unterschiedlichen Qualifikationen die Rollen beider Entwickler vorher definiert


werden. Das Verhältnis, welches Norvig hier aufführt, ist das Lehrer/Schüler-Modell.
Wenn von Anfang an Klarheit über die Rollen herrscht, kann der Schwächere von
dem Stärken durch Beobachten lernen. „I think the best part of the apprentice
approach is that you get to watch the master, and I would like see more of that. So I
guess that‘s another use of pair programming.― (Seibel, 2009 S. 3707). Zum anderen
kann laut Bloch Pair Programming auch im Rahmen eines Code Reviews stattfinden.
In diesem Szenario werden die Änderungen am Code von einem höher Qualifizierten
durchgeführt und der schwächere Entwickler schaut zu. „Typically it‘s in the context
of a code review […] there‘ll be a lot of changes and I‘ll say – Why don‘t we just sit
together at a maschine and bash it into shape? […] I think it‘s a great way to teach,
to pass knowledge down from one generation of hacker to the next.― (Seibel, 2009 S.
2532). Diese Methodik wird auch von Martin Fowler als ein Zeitpunkt aufgegriffen,
in dem das Refactoring praktiziert werden sollte (Refactor as you do a code review).
Allerdings nicht im Kontext der Paar-Programmierung, sondern im Rahmen einer
Software-Inspektion in Form der Durchsicht oder Stellungnahme (Fowler, et al.,
2004 S. 59). Zudem ist Paar-Programmierung abhängig von der Persönlichkeit des
Entwicklers. Armstrong kann zum Beispiel bei schwierigen Problemen besser allein
arbeiten (Seibel, 2009 S. 2887), während Fritzpatrick einen Dritten benötigt, um
nicht abgelenkt zu werden (Seibel, 2009 S. 947).

Zusammenfassend kann festgestellt werden, dass Paar-Programmierung abhängig


von der Qualifikation der Entwickler eingesetzt werden sollte. Als grundsätzliche
Bedingung müssen allerdings beide Entwickler die Methode für sich selbst als
hilfreich einschätzen und nicht als störend empfinden. Norvig und Thompson
schätzen den Effizienzgewinn bei der Paar-Programmierung allerdings als gering ein.
Norvig empfiehlt Pair Programming dosiert einzusetzen: „Ten percent of the time it
is a really good idea to sit down together because you want that shared
understanding. I think most of the time you‘re not going to be as effective.― (Seibel,
2009 S. 3696). Thompson sieht es als Methode an, um die Fehlerquote insgesamt zu
reduzieren. Besserer Quellcode entsteht durch den Einsatz der Methode allerdings
nicht. „The result isn‘t better. Probably debugging is faster – a you‘re typing,
someone can catch a bug over your shoulder.― (Seibel, 2009 S. 6026).
117

Das sequenzielle Debuggen des Quellcodes des jeweils anderen Entwicklers kann
eine neue Methodik der Paar-Programmierung sein. Obwohl dies eher der Software-
Inspektion in Form der Stellungnahme zugeordnet werden müsste. Das gleichzeitige
Arbeiten am Quellcode, welches die Paar-Programmierung charakterisiert, fehlt bei
dieser Methodik. Anerkannte Varianten von der Paar-Programmierung sind derzeit
„Distributed Pair Programming“ (Schümmer, et al., 2009) und „Ping Pong Pair
Programming“ (Cunningham & Cunningham, 2003).

4.1.3 What about code ownership? It is important for people to own code
individually or is it better for a team to share ownership?
Im Kern werden beide Perspektiven „Code Ownership“ und „Collective Code
Ownership“ gleichberechtigt behandelt. Es wird als wichtig erachtet, im Projektteam
den Code untereinander zu kennen. Andererseits wird es nicht abgestritten, dass
Code Ownership existiert. In Blochs Interview wird der Konflikt sehr deutlich.
Rational ist es ihm bewusst, dass Quellcode dem Team gehören soll – emotional
streitet er dies jedoch ab. Seine rationale Antwort auf die Frage lautet: „[…] So it‘s
really important that multiple people learn about each piece of code and are able to
work on it. But I think it‘s unrealistic to expect everyone to own all the code.― Die
emotionale hingegen: „I believe code ownership can‘t be denied. In a way, it‘s like
motherhood – you give birth to the code that you write and especially it‘s large,
complex, or original, it is yours. […] If you break someone else‘s code, that‘s not
nice.― (Seibel, 2009 S. 2537). Fritzpatrick sieht es aus dem Projektteam-Gedanken.
Er kann sich nicht vorstellen, dass Code Ownership in der heutigen Zeit noch
existiert. „I don‘t think code should be owned. I don‘t think anyone really thinks
that.― (Seibel, 2009 S. 958), Sein Statement steht für die Open-Source-Generation.
Thompson sieht es sehr praktisch aus Entwicklersicht: „The catchphrase is, – you
touched it last – you own it.― (Seibel, 2009 S. 6018). Auch Zawinski sieht beide
Perspektiven als wichtig an, stellt jedoch besonders heraus, dass Entwickler
Verantwortung für ihren Quellcode übernehmen müssen und nicht das gesamte
Projektteam. „[…] It‘s certainly good for other people to have their hands in it, if
only because you‘re not going to be maintaining it yourself forever. It‘s going to
have to be handed off to someone else for one reason or another. But it‘s also good
118

to have someone to blame. If everybody is responsible for it then there‘s no one to


put their foot down.― (Seibel, 2009 S. 539). Bloch nennt zudem einen Grund, warum
Code Ownership in Projektteams durchaus Sinn machen kann. Softwareentwickler
sind in der Regel Spezialisten auf einem Fachgebiet und keine austauschbaren
Generalisten. Wenn Entwickler gezwungen werden, an Lösungen zu arbeiten, für die
sie nicht spezialisiert sind, kann die Softwarequalität sinken. „Engineers have things
that they‘re good at and things they‘re not so good at. There are people who would
like to pretend that this isn‘t so, that engineers are interchangeable, and that anyone
can and should be a total generalist. […] If you force them all to do everything,
you‘ll probably make mediocre products.‖ (Seibel, 2009 S. 2358).

Zusammenfassend kann man feststellen, dass die Interview-Partner eine gesunde


Einstellung zum Code Ownership besitzen. Code Ownership wird nicht geleugnet.
Collective Code Ownership wird akzeptiert. Besonders interessant ist Fritzpatricks
Einstellung zum Code Ownership. Die Open-Source-Bewegung hat offensichtlich
besonderen Einfluss auf Entwickler, die seit der Bewegung und in diesem Umfeld
aufgewachsen sind. Das dogmatische Durchsetzen des Code Ownership hilft in
Projekten nicht. Insbesondere dann, wenn Code Ownership im Projekt aufgrund des
hohe Spezialisierungsgrad der Entwickler Sinn macht.

Nach Copliens entsteht in Großprojekten aufgrund der Organisationsform und


Architektur der Software automatisch Code Ownership. Dies begründet er damit,
dass komplexe Software nur durch Spezialwissen beherrscht werden kann. Coplien
nennt auch die Rahmenbedingungen hierzu: Erstens: Code Ownership muss in Form
von „Domain Experise in Roles“ (Coplien, 1998 S. 256) im Projekt vorhanden sein.
Und zweitens: Ein Architekt muss die Architektur als Gesamtes im Überblick
behalten, um einen Tunnelblick zu verhindern (Coplien, 1999 S. 5-14).

4.1.4 Do you consider yourself a scientist, an engineer, an artist, or a


craftsman?
Peter Seibel hat diese Frage nicht Armstrong, Steele, Deutsch und Knuth gestellt.
Jones beantwortet die Frage nicht eindeutig. Die Grundgesamtheit ist demnach elf.
Die Antworten fallen unterschiedlich aus. Besonders auffällig ist, dass nur Norvig
119

und Allen eine eindeutige Zuordnung machen. Norvig sieht es als „Craft“ und
begründet es mit der Funktionalität, die Programme besitzen (müssen). „But I don't
think of as art. I think craft is really the right word for it. You can make a chair, and
it's good looking, but it's mostly functional – it‘s a chair.― (Seibel, 2009 S. 4034).
Allen sieht sich eindeutig als „Scientist“: „I think of myself as a computer scientist.―
(Seibel, 2009 S. 6311). Zawinski, Thompson und Cosell beschreiben es als seine
Kombination von „Artist“ und „Craftsman“, wobei der Schwerpunkt unterschiedlich
ist. Zawinski macht den Anteil abhängig vom Projekt: „Somewhere between
craftsman and artist, depending on what the project is― (Seibel, 2009 S. 561),
während Thompson den Anteil „Artist“ als geringer einschätzt: „I believe a
craftsman but with certain amount of artistry to keep it alive.― (Seibel, 2009 S.
5923). Cosell hingegen sieht beides als neutral an: „The way I do engineering is as a
combination of art and craft.― (Seibel, 2009 S. 6944). Fritzpatrick sieht sich als
„Engineer“ in Bezug auf das Softwaredesign. An zweiter Stelle kommt „Scientist“
für die Methodik und die Herangehensweise an Problemstellungen: „I would say,
scientist are second, but only in the sense of scientific method of changing one thing
at a time and how you diagnostic problems. Engineer for the design aspect of
things.― (Seibel, 2009 S. 1143). Ingalls setzt alle vier in eine Reihenfolge. Als Erstes
steht die Kombination zwischen „Scientist“ und „Artist“, danach folgt „Craft“ und
zum Schluß „Engineer“ (Seibel, 2009 S. 5145). Eich und Bloch sehen es als
Kombination von „Scientist“, „Engineer“ und „Craftsman“. Eich sieht die
Schwerpunkte wie Zawinski ähnlich abhängig vom Projekt und der Aufgabe.
„Programming is partly engineering; there's maybe some math on a good day. and
then there's a lot of practical stuff that doesn't even rise to the level of engineering.
Maybe it'll be formalized more over time.― (Seibel, 2009 S. 2026). Bloch beschreibt
es sehr philosophisch und versucht, sich von dem Schubladendenken zu entfernen.
Eine Priorisierung führt er nicht durch. „What we're doing is an aesthetic pursuit. It
involves craftsmanship as well as mathematics and it involves people skills and prose
skills – all of these things that we don't necessarily think of as engineering but
without which I don't think you'll ever be a really good engineer.― (Seibel, 2009 S.
2575). Crockford ist der Einzige, der die Kategorisierung in Frage stellt, indem er
sich als Schriftsteller bezeichnet, der in Englisch oder in Javascript schreibt. „I think
120

myself as writer. Sometimes I write in English and sometimes I write in javascript.―


(Seibel, 2009 S. 1578).

Insgesamt kann festgestellt werden, das „Craft“ am häufigsten von den Interview-
Partnern genannt wird, gefolgt von „Scientist“ – „Artist“ und „Engineer“ sind
gleichauf. Zudem werden die Begriffe nicht einzeln genannt, sondern in den meisten
Fällen als Paar. Die Begriffe besitzen inhaltlich jedoch deutliche Unterschiede.
Offensichtlich ist Engineering als Begriff in Software-Engineering zu
eindimensional, um die Entwickler-Tätigkeit zu beschreiben. Aus dem
Positionierungskreuz ist zu erkennen, dass bis auf Ingalls niemand „Artist“ und
„Engineer“ als Beschreibung genutzt hat.

Abbildung 16: Positionierungskreuz Scientist, Engineer, Artist, Craftsman (eigene Darstellung)

Der Vergleich mit „Scientist“, „Engineer“, „Artist“ und „Craft“ dient nur als
mentales Denkmodell, um eine mögliche Zuordnung der eigenen
121

Programmiertätigkeit für Dritte verständlich zu machen. In diesem Fall, müsste ein


neuer Begriff als „Engineering“ gefunden werden. Diese Ansicht vertritt Alistair
Cockburn (Cockburn, 2004) und Ludewig et al. (Ludewig, et al., 2010 S. 48) ebenso.

4.2 Aussagen, die Themenfelder des Software-Engineerings betreffen


Neben den direkten Fragen, die Peter Seibel zum Software-Engineering gestellt hat,
sind innerhalb der Interviews auch inhaltliche Aussagen zu Software-Engineering im
Allgemeinen und zu speziellen Themen wie Test Driven Development, Unit Tests
und Refactoring gefallen.

4.2.1 Allgemeine Aussagen zum Software-Engineering


Bloch, Deutsch und Knuth führen drei wesentliche Punkte auf, die im Software-
Engineering seit Beginn diskutiert werden. Brooks These „Adding people to a late
software project makes it later“ entspricht nach Bloch der Wahrheit und hat bis heute
Bestand (Seibel, 2009 S. 2165). Deutsch führt auf, dass das Software-Engineering bis
heute keine guten Werkzeuge besitzt, um ein System zu beherrschen, wenn es wächst
und groß wird. Er klassifiziert dabei in zwei Arten des Wachstums. Wenn ein kleines
zum mittelgroßen anwächst und wenn ein mittelgroßes zu einem großen anwächst.
Letztes ist nach Deutsch mit unseren derzeitigen Werkzeugen nur schwer
beherrschbar (Seibel, 2009 S. 5306). Knuth betrachtet die „Silver Bullet“-Diskussion
aus einer interessanten Perspektive: In der Informatik steigt die Komplexität
kontinuierlich an und erreicht immer wieder die Grenzen von dem, was die
Informatik und Menschen leisten können. Diese Mentalität führt zwangsweise zu
fehlerhafter Software, es sei denn, man gibt das Komplexitätsbestreben in der
Informatik auf. Damit der Hunger nach steigender Komplexität beherrscht werden
kann, kommen immer wieder neue Vorgehens- und Prozessmodelle auf. Diese sollen
die Komplexität reduzieren und die Softwareentwicklung vereinfachen, bis
festgestellt wird, dass dies nicht möglich ist. Deutsch nennt sich deshalb auch nicht
Wissenschaftler, weil er seit 50 Jahren in der praktischen Informatik tätig ist und seit
30 Jahren keine signifikante Verbesserung festgestellt hat. Als Beispiel nennt er die
Nutzung von „Pointer“ in verbreiteten Programmiersprachen (Seibel, 2009 S. 7420).
122

Bloch stellt im Interview fest „Programming is fundamentally different to the way


we construct things in the real world― (Seibel, 2009 S. 2691) und bezieht sich damit
auf die Eigenschaften von Software. In der realen Welt werden Sachen konstruiert,
indem man Objekte zusammensetzt. Als Beispiel nennt er den Hausbau und
Computer-Chips. Dabei kommt er zur Schlussfolgerung: „And that‘s how you make
hardware. But we don‘t make software like that. We should make software like that
and we don‘t.― (Seibel, 2009 S. 2691).

4.2.2 Test Driven Development


Norvig vertritt die Ansicht, dass Test Driven Development in erster Linie zur
Fehlerkorrektur eingesetzt wird und keinen Einfluss auf das Software-Design
besitzen sollte. Er begründet es damit, dass ein fehlerhafter Test keine Aussage über
das Softwaredesign gibt. Die Bestandteile eines Designs können erst dann getestet
werden, wenn sie vorhanden sind. Tests können dann eine Aussage darüber geben,
wie gut einzelne Bestandteile miteinander interagieren und wo die Grenzen sind. Ein
Design sollte allerdings nicht daran ausgerichtet werden, weil ein Test
fehlgeschlagen ist (Seibel, 2009 S. 3829).

Betrachtet man Norvigs Aussage aus Kent Becks Sicht des Test Driven
Developments, stellt man fest, dass beide in ihrer Aussage nicht weit auseinander
liegen. Beck geht davon aus, dass sich Softwaredesign in einer Projektorganisation
auf Basis von ausführbarem Code organisch entwickelt. „We must design
organically, with running code providing feedback between decisions.‖ (Beck, 2004
S. ix). Nach Beck ist der Grundgedanke beim Test Driven Development zu wissen,
dass eine Lücke zwischen der Entscheidung und dem Feedback während der
Programmierung vorherrscht, sowie zu wissen, mit welchen Techniken diese Lücke
geschlossen werden kann. Softwaredesign vor den Tests zu erstellen, zeigt, dass
Klarheit über Entscheidung und Feedback herrscht und widerspricht nach Beck Test
Driven Development nicht (Beck, 2004 S. xii). Im Gegensatz dazu steht Robert
Martins Sichtweise „[…] The act of writing a unit test is more an act of design than
of verification […]―, der Unit Test als Mittel zum Design sieht (Martin, 2003 S. 23).
Deshalb kann davon ausgegangen werden, dass sich Norvig auf Martins Sicht im
Interview bezieht.
123

In den Interviews berichten Eich und Armstrong, dass Test Driven Development
ihnen beim Programmieren enorm geholfen hat. Eich erwähnt dies im Rahmen der
Entwicklung bei Mozilla mit Firefox (Seibel, 2009 S. 1742). Armstrong nutzt selbst
die Technik beim Entwickeln (Seibel, 2009 S. 2779). Auch Norvig nutzt Test Driven
Development im Rahmen des Softwaredesigns „I think test-driven design is great. I
do that a lot more than I used to do.― (Seibel, 2009 S. 3772). Das Design aufgrund
eines fehlerhaften Tests zu ändern oder darauf auszurichten, sollte während der
Entwicklung trotzdem kritisch hinterfragt werden (siehe auch 3.5.1.4, S. 85).

4.2.3 Unit Tests


Fritzpatrick missbraucht Unit Test für zwei sinnvolle Zwecke. Erstens: zum
Debuggen von Quellcode. Er unterteilt dabei eine große Funktion in mehrere
kleinere und testet diese dann einzeln mit Unit Test. Im Rahmen des Refactoring
setzt er danach die einzelnen Funktion wieder zu einer gesamten zusammen (Seibel,
2009 S. 1038). Zweitens: wenn er eine Bibliothek von Dritten benutzen möchte,
prüft er vorher mit Unit Tests die Funktionen die er benutzen möchte. „I figure
sicnce I‘m going to have to write something to learn the library anyway, my first
Hello World program might as well be a unit test against it.― Damit prüft er, ob die
Bibliothek den Funktionsumfang bietet, den er benötigt, und ob die Funktionen, die
er nutzt, frei von Fehlern sind (Seibel, 2009 S. 1098). Fritzpatrick nutzt damit Unit
Test in einem interessanten Kontext, einmal zum Code Review sowie für das
Refactoring und zum anderen zum Testen von Bibliotheken. Er befolgt damit Blochs
Methodik, dass Test Driven Development und Refactoring im ersten Schritt bei der
Benutzung einer API durchgeführt werden sollte (siehe auch Kapitel 3.5.1.5, S. 86).

Norvig rät Programmierern zum einen viele Unit Tests zu schreiben, und zum
andern, nicht boolisch, sondern in qualitativen Aussagen zu denken. Ein Test muss
nicht immer wahr oder falsch sein. Wenn in einem Suchergebnis 80 % richtige
Antworten vorkommen sollen, ist dies nicht gleichbedeutend damit, dass die
restlichen 20 % ein Fehler sein müssen. Desweiteren rät er, sich Gedanken über
alternative Fehlermodi in Programmen zu machen. Als Beispiel gibt er ein
persönliches Erlebnis an. Am Flughafen war der Strom ausgefallen. Die Flugzeuge
sind aber trotzdem pünktlich geflogen, weil der Flugplan als Ausdruck vorlag.
124

Zudem lassen sich vier zentrale Aussagen aus den Interviews ableiten. Erstens: Unit
Tests verlangsamen die Entwicklung im ersten Schritt. Zawinski (Seibel, 2009 S.
461) und Knuth (Seibel, 2009 S. 7131) beschreiben dies im Kontext des ersten
Softwarerelease von Netscape und TeX (siehe auch Kapitel 3.5.1.1, S. 81).
Zweitens: Unit Tests beschleunigen langfristig den Entwicklungsprozess.
Fritzpatrick beschreibt dies aus der Maintenance-Perspektive eines Live Services.
(Seibel, 2009 S. 727) „It's always easier to do something right the first time than to
do a migration with a live service. That's the biggest pain in the ass ever.― (Seibel,
2009 S. 798). Drittens: Unit Tests sind kein Ersatz für eine technische Spezifikation.
Unit Tests stellen lediglich sicher, dass der Code die Spezifikationen einhält. Bloch
führt hierzu auf: „I don‘t think tests are even remotely an acceptable substitute for
documentation. Once you‘re trying to write something that other people can code to,
you need precise specs, and the tests should test that the code conforms to those
specs.― (Seibel, 2009 S. 2284). Damit stellt sich Bloch gegen Robert Martins Sicht,
dass Test Driven Development der Spezifikation dient und nicht der Validierung
(Martin, 2003 S. 23). Viertens: Norvigs These, dass Unit Tests keine Hilfe sind, um
das eigentliche Problem zu lösen (siehe hierzu auch Kapitel 3.5.1.4, S. 85) (Seibel,
2009).

4.2.4 Refactoring
In den Interviews werden zum Refactoring drei Methoden angesprochen die sich in
Zeitpunkt, Umfang und Dokumentation aufteilen lassen.

Zeitpunkt – Crockfords These ist, dass ein Refactoring des kompletten Quellcodes
alle sechs Entwicklungszyklen geschehen sollte. Der Zeitrahmen der Zyklen ist dabei
unerheblich und sollte abhängig vom Projekt sein. Wird Scrum als Prozessmodell
genutzt, sollte jeder siebte Sprint ein Refactoring Sprint sein. Besitzt ein Projekt
einen monatlichen Lieferzyklus, sollte nach sechs Monaten ein Monat für das
Refactoring der Codebasis genutzt werden. Die Abgrenzung, wann ein Refactoring
oder ein Rewrite stattfinden sollte, macht Crockford abhängig von den
Programmierern im Projekt. Diese würden aufgrund der Codebasis wissen, wann ein
Rewrite notwendig sei, und nicht das Management (Seibel, 2009 S. 1396).
125

Umfang – Cosell unterteilt den Umfang und Dauer der Änderungen des Bugfixing in
drei Stufen. Bei zwei von drei Stufen nutzt sie die Möglichkeit, beim Bugfixing den
Code zu refactoren (Fowler, et al., 2004 S. 58). Die erste Stufe ist die schnellste und
vom Umfang am geringsten. In ihr wird nur die fehlerhafte Zeile ausgetauscht. In der
zweiten Stufe wird der betroffene Codeabschnitt komplett neugeschrieben (siehe
Kapitel 3.5.4.3, S. 102). Die dritte Stufe hat zum Ziel eine bessere Version des
Programms zu erstellen, indem auch abhängige Codeabschnitte ein Rewrite erhalten
oder durch Refactoring verbessert werden (Seibel, 2009 S. 6876).

Dokumentation – Knuth beschreibt einen Refactoring-Ansatz zur Vermeidung von


„Premature Optimization“31. Damit der Quellcode beim nachträglichen Optimieren
lesbar bleibt, sollte der alte Quellcode auskommentiert und damit in Form einer
Versionierung stehen bleiben. Er empfiehlt dabei eine Optimierung des Quellcodes
in Stufen, wobei jede neue eine Verbesserung der vorherigen darstellt. „Section one
– here‘s a naive implementation of this algorithm; section two – here‘s a slightly
souped-up version of section one; and section three, here‘s the one we actually use
which you would never understand if you hadn‘t read the first two sections.― (Seibel,
2009 S. 7223). Durch diese Vorgehensweise bleibt die Historie des
Optimierungsvorgangs im Quellcode erhalten. Der Ansatz wird gemäß Knuth dem
Literate Programming zugerechnet.

Alle drei Ausführungen besitzen praktische Relevanz und haben ihre Berechtigung.
Die Methoden werden als solche in der Form nicht in Literatur aufgeführt. Besonders
hervorzuheben ist, dass Cosell in dem Interview zugibt, Refactoring nicht zu kennen
(Seibel, 2009 S. 6876).

31
Der Satz „We should forget about small efficiencies, say about 97% of the time: premature optimization is the
root of all evil“ wird oft mit Donald Knuth in Verbindung gebracht, der es in seinem Aufsatz „Structured
Programming with go to Statements“ inhaltlich beschrieben hat (Knuth, 1974 S. 294). Der Aufsatz ist die
Widerlegung von Knuth zu Dijkstras Aufsatz „Go To Statement Considered Harmful“ (Dijkstra, 1968 S. 147-
148). Als Urheber gilt Tony Hoare, der wiederum auf Edsger Dijkstra verweist mit dem Hinweis, dass er dieses
Zitat für „common culture or folklore“ hält (Gerwitz, 2004). „Premature Optimization“ soll Entwickler hindern,
bereits bei der Entwicklung klassische Code-Optimierung zu betreiben, und soll sie gleichzeitig ermutigen, gute
Algorithmen zu entwickeln und diese vernünftig zu implementieren. (Hyde, 2004 S. xviii)
126

4.3 Einordnung in die Softwareentwicklung


Betrachtet man den Charakter, die abgeleitete Mentalität und die Aussagen aus
diesem Kapitel, stellt sich die Frage, wie der Duct Tape Programmer in die
Softwareentwicklung eingeordnet werden kann. Wird die abgeleitete Mentalität aus
dem Kapitel 3.6 (S. 105) betrachtet, erkennt man, dass diese im Wesentlichen aus
Charakteristika abgeleitet worden ist, die im Kontext von Softwareprojekten genannt
wurden. Auf Basis des Wissens über den Stereotypen kann deshalb derzeit nur
festgestellt werden, welche Rahmenbedingungen ein Softwareprojekt besitzen sollte,
um die Anforderungen, die ein Duct Tape Programmer an ein Projekt stellt, zu
erfüllen.

Wie bereits in Kapitel 4.1.1 (S. 110) festgestellt, kommt ein Duct Tape Programmer
mit jedem Vorgehens- und Prozessmodell zurecht, mit Ausnahme des
Wasserfallmodells. Daneben gibt es individuelle Abneigungen, mit denen ein
Softwareprojekt oder das Unternehmen rechnen muss. Thompson berichtet zum
Beispiel in den Interviews, dass es ihm nicht erlaubt sei, bei Google Code
einzuchecken, weil er sich weigert, in C++ zu entwickeln (Seibel, 2009 S. 5951).
Allerdings hat Google sehr genau erkannt, in welchem Projektumfeld Thompson
wirken kann. „But I‘m not actually production either. I‘m in projects that will be
become production. […] would be just to find something to make life better. Or have
some new idea of new stuff that replaces old stuff. Try to make it better.― (Seibel,
2009 S. 5940). Thompson beschreibt damit Projekte, die Innovationscharakter
besitzen. Eine Innovation definiert Hausschildt wie folgt: „Innovationen sind im
Ergebnis qualitativ neuartige Produkte oder Verfahren, die sich gegenüber dem
vorangehenden Zustand merklich – wie auch immer das zu bestimmen ist –
unterscheiden. […]― (Hausschildt, 1993 S. 4-6). Demnach sind Duct Tape
Programmer Entwickler, die in Projekten wirken, die neue Produkte oder Verfahren
entwickeln. Betrachtet man die Projekterfolge in Kapitel 3.5.6 (S. 104), erkennt man,
dass alle die Projekte Innovationscharakter besessen haben oder noch besitzen und
dabei die Informatik maßgeblich beeinflusst haben.

Die Rahmenbedingungen, die in einem Projekt vorherrschen sollten, können


ebenfalls anhand der Kenntnis, die wir bisher über den Duct Tape Programmer
127

haben, festgestellt werden. Erstens muss das Projekt etwas Neues entwickeln oder
Bestehendes signifikant verbessern, das vorher noch nicht existiert hat (Seibel, 2009
S. 1411). Zweitens: Die technische Umgebung, in der entwickelt wird, muss frei von
Abstraktionsebenen sein und dem Entwickler die Möglichkeit der systemnahen
Programmierung geben (Prinzip „close to the metal“, siehe Kapitel 3.5.2.4, S. 91).
Die Werkzeuge sollte im besten Fall der Programmierer selbst bestimmen können.
Drittens: Das Projekt benötigt keine ausführliche Spezifikation, sondern es reicht
eine Metapher aus, wie es in Extreme Programming zu finden ist (Seibel, 2009 S.
4813). Viertens: Die Projektorganisation muss den Entwicklern die Möglichkeit
einräumen, sofort in ausführbarem Code Lösungsansätze zu entwickeln (siehe
Kapitel 3.5.2.2, S. 89 und Kapitel 3.5.1.2, S. 83). Fünftens: Das Projektteam sollte
beim Projektstart eine Größe von nicht mehr als drei bis vier Programmierern mit
vergleichbarer Qualifikation besitzen (siehe Kapitel 3.5.4.2, S. 100). Sechstens: Ist
das Projekt an eine Deadline gebunden, müssen Funktionen zugunsten des
Abgabezeitpunkts gestrichen werden dürfen (siehe Kapitel 3.5.1.1, S. 81).

Betrachtet man die Gegenperspektive, ist der Duct Tape Programmer kein
Programmierer, der in die Metapher des „industriellen Produktionsprozesses“ passt.
Die industriellen Entwicklungsprozesse und festgefahrenen technischen
Infrastrukturen der Industrie betrachtet er aufgrund seiner Mentalität kritisch oder
lehnt sie ab (siehe auch Kapitel 3.6, S. 105).

4.4 Kritische Würdigung


Ob die Mentalität des Duct Tape Programmers eine Einflussgröße auf das Software-
Engineering hat, kann im Rahmen dieser Arbeit nicht festgestellt werden. Das Buch
„Coders at Work“ und der Artikel „The Duct Tape Programmer“ von Joel Spolsky
können nur als Grundlage dienen, um eine Charakter- und Mentalitätsbestimmung
durchzuführen. Um ein wissenschaftlich repräsentatives Ergebnis zu erhalten,
müssen mehr Programmierer befragt werden. Dies müsste über eine empirische
Studie in Form eines Fragebogens und Auswertung erfolgen. Zudem stellt sich bei
der Charakterbestimmung auch die Frage, ob es noch weitere Stereotypen von
Programmierern gibt. So wurde in dieser Arbeit als Gegenpol zum Duct Tape
Programmer der „Industrieprogrammierer“ als Metapher zur Abgrenzung benutzt.
128

Ob es diesen gibt und ob er wirklich aus wissenschaftlicher Sicht einen adäquaten


Gegenpol darstellt, ist unbekannt. Eines lässt jedoch mit Sicherheit sagen: Ein Duct
Tape Programmer ist für Innovationsprojekte prädestiniert. In diesen Projekten
entfaltet er einen enormen Wirkungsradius und hat nachhaltigen Einfluss auf das
Projektergebnis und auf die Informatik. Ob die in diesem Kapitel aufgeführten neuen
Methoden und Modelle letztendlich einen Weg in die wissenschaftliche Literatur
finden werden, ist fraglich. Software-Engineering ist eine Wissenschaft, die stark von
Evangelisten beeinflusst wird. Ohne sie wäre die agile Bewegung nicht entstanden.
Auch wenn Crockford anmahnt, dass Programmierer sich mehr für den
Gestaltungsprozess einsetzen sollten, besitzen Duct Tape Progammer als „Coding
Monkeys“ in der Praxis wenig Einfluss auf Softwareherstellungsprozesse. Trotzdem
muss man feststellen, dass Zawinskis Modell ein sehr hohes Potenzial hat, neben
Extreme Programming, Feature Driven Development und Scrum genannt zu werden,
wenn es denn weiter ausgearbeitet werden würde.

5 Zusammenfassung und Fazit


Vorgehens- und Prozessmodelle wurden von sehr intelligenten Informatikern
entwickelt, mit einer sehr technischen Sicht auf unsere Welt. Zum Lösen der
„accidential problems“ ist dies die richtige Perspektive und hat Software-Engineering
sehr weit gebracht. Betrachtet man die „essential difficulties“, kommen sehr schnell
die menschlichen Schwächen zum Vorschein. Wir sind keine Maschinen, auch wenn
die Informatik dies glaubt. Unsere Vorstellungskraft ist zum Beispiel im Gegensatz
zu unserer Fantasie begrenzt, und es fällt uns sehr schwer, immaterielle Erzeugnisse
in ihrer Größe und Komplexität abzuschätzen. Dazu kommt noch, dass nicht jeder
Informatiker ein Genie ist und beliebig komplexe Algorithmen oder komplexen
Programmcode versteht. Diese menschliche Schwäche lässt sich nicht durch unsere
Ratio ausgleichen. Hier stellt sich die Frage, ob die Klügsten und Besten der
Informatik für das Gestalten von Werkzeugen, Prinzipien oder Methoden in der
letzten Instanz zum Lösen der „essential difficulties“ überhaupt geeignet sind. Bloch
beschreibt in seinem Interview sehr deutlich seine Sichtweise zu dieser Thematik.
Seine Aussage bezieht sich zwar auf APIs und wie er seine Arbeit beschreiben
würde, die Kernaussage von ihm ist aber allgemein gültig: „But merely the fact that
129

they‘re the smartest people in the organization doesn‘t mean they should be making
all the decisions, because intelligence is not a scalar quantity; it‘s a vector quantity.
And if you lack empathy or emotional intelligence then you shouldn‘t be designing
APIs or GUIs or languages. What we're doing is an aesthetic pursuit. It involves
craftsmanship as well as mathematics and it involves people skills and prose skills –
all of these things that we don't necessarily think of as engineering but without which
I don't think you'll ever be a really good engineer.― (Seibel, 2009 S. 2572 ff.)
Betrachtet man Bloch Aussage, können möglicherweise die „essential difficulties“
nicht von Spitzeninformatikern gelöst werden. Ihnen fehlt schlichtweg die
emotionale Intelligenz. Jedenfalls ist es an der Zeit, ernsthaft darüber nachzudenken,
ob das Denkmodell des ingenieurmäßigen Entwickelns überhaupt noch zeitgemäß
ist. Die Metapher war in den 1960er Jahren richtig und wichtig, um zu beginnen.
Heute ist von ihr nur eine Worthülse übrig.

Der Autor dieser Arbeit sieht diese Ausarbeitung als Impuls, um weitere Arbeiten auf
diesem Gebiet zu initiieren. Beim genauen Hinschauen erkennt man, dass diese
Arbeit ein unentdecktes Land offenlegt. Besonders interessant dabei ist, dass dies
nicht aus der technischen Perspektive erfolgt, sondern aus soziologischer. Vielleicht
ist die Schnittstelle zwischen den „accidential difficulties“ und „essential difficulties“
der Mensch selbst. Damit würde man sich von der Sichtweise Balzert und andere
Wissenschaftler abwenden, die der Meinung sind, Werkzeuge, Methoden und
Prinzipien seien der Mittelpunkt der ingenieursmäßigen Softwareentwicklung. In
diesem Fall würde die Definition von Schulz, der den Mensch berücksichtigt, am
besten das Software-Engineering beschreiben. Was in diesem Zusammenhang nicht
vergessen werden darf, ist, dass die agile Bewegung unbewusst oder bewusst den
ersten Schritt in die richtige Richtung gegangen ist. Allerdings steht sie sich aufgrund
ihrer zunehmenden fundamentalen-dogmatischen Haltung immer mehr selbst im
Weg.

Fakt ist, dass diese Arbeit der Anstoß für eine Doktorarbeit ist. Dass der Duct Tape
Programmer existiert, ist unbestritten. Was fehlt ist eine repräsentative empirische
Untersuchung, deren Ergebnis den Charakter und Mentalität des Stereotypen
beschreibt.
130

Literaturverzeichnis

Balzert, Helmut. 1998. Lehrbuch der Softwaretechnik, Teil 2: Softwaremanagement,


Software-Qualitätssicherung, Unternehmensmodellierung. s.l. : Spektrum-
Akademischer Verlag, 1998.

—. 2009. Lehrbuch der Softwaretechnik: Basiskonzepte und requirements


Engineering. Heidelberg : Springer, 2009.

—. 1999. Lehrbuch Grundlagen der Informatik. Heidelberg, Berlin : Spektrum


Akademischer Verlag, 1999.

Bauer, Friedricht Ludwig. 1975. Software Engineering. Berlin : Springer Verlag,


1975.

Beck, Kent. 1999. Extreme Programming Explained: Embrace Change.


Amsterdam : Addison-Wesley Longman, 1999.

—. 2004. Test-Driven Development by Example. Boston : Pearson Education, 2004.

Beck, Kent, et al. 2001. Manifesto for Agile Software Development. [Online] 2001.
[Zitat vom: 16. September 2010.] http://www.agilemanifesto.org/history.html.

Berry, Daniel. 2003. The Inevitable Pain of Software Development: Why There Is
No Silver Bullet. Canada : University of Waterloo, 2003.

Biancuzzi, Federico und Warden, Shane. 2009. Masterminds of Programming:


Conversations with the Creators of Major Programming Languages. Sebastopol :
O'Reilly Media, 2009.

Boehm, Barry. 1988. A Spiral model of Software of Software Development and


Enhancement. Computer. Mai 1988, Bd. Vol. 2, 5, S. 61-72.

—. 1979. Guidelines for Verifying and Validating Software Requirements and


Design Specifications. Applied Information Technology 1979: I.F.I.P. Conference
Proceedings. s.l. : North-Holland Pub. Co., 1979, S. 711-719.
131

Borchers, Detlef. 2004. Heise. [Online] 07. April 2004. [Zitat vom: 8. September
2010.] http://www.heise.de/newsticker/meldung/Vor-40-Jahren-der-perfekte-
Computer-96683.html.

Brooks, Frederick. 2003. Vom Mythos des Mann-Monats. Essays zum Software-
Engineering. Frechen : MiTP Verlag, 2003.

Broy, Manfred, et al. 2006. Manifest*: Strategische Bedeutung des Software


Engineering in Deutschland. Informatik-Spektrum. Juni 2006, S. 210-221.

Calamé, Jens. 2003. Didaktische Grundfragen der Informatik: Software


Engineering. [PDF] Uni Potsdam : s.n., 2003.

Cockburn, Alistair. 2004. The End of Software Engineering and the Start of
Economic-Cooperative Gaming. The international journal published by ComSIS
Consortium. Februar 2004, Bd. 1, 1.

Coplien, James. 1998. A generative development - Process Pattern Language.


[Buchverf.] Linda Rising. The patterns handbook: techniques, strategies, and
applications. s.l. : Combridge University Press, 1998.

—. 1999. Organization and Architecture. 1999 CHOOSE Forum on Object-Oriented


Software Architecture. [Online] 11. März 1999. [Zitat vom: 18. Oktober 2010.]
http://dirkriehle.com/community-service/choose/1999-forum/coplien2.pdf.

Cunningham & Cunningham. 2003. Pair Programming Ping Pong Pattern.


Portland Pattern Repository's Wiki. [Online] Cunningham & Cunningham, Inc., 01.
Mai 2003. [Zitat vom: 25. Oktober 2010.]
http://c2.com/cgi/wiki?PairProgrammingPingPongPattern.

Cutler und Cuttler, Kim-Mai. 2009. Mark Zuckerberg on how to build hacker
culture inside a company. SocialBeat. [Online] 24. Oktober 2009. [Zitat vom: 14.
September 2010.] http://digital.venturebeat.com/2009/10/24/live-blogging-mark-
zuckerbergs-talk-at-startup-school/.
132

De Luca, Jeff. The Latest FDD Processes. Nebulon.com. [Online] [Zitat vom: 02.
September 2010.]
http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf.

Dijkstra, Edsger. 1968. Go To Statement Considered Harmful. Communications of


the ACM. 1968, Bd. 11, 3.

Dijkstras, Edsger. 1972. The humble programmer. Communications of the ACM


(CACM), Volume 15. 1972, S. 859-866.

Dumke, Reiner. 2003. Software Engineering, Eine Einführung für Informatiker und
Ingenieure: Systeme, Erfahrungen, Methoden, Tools. Wiesbaden : Vieweg & Sohn
Verlag, 2003.

Floyd, Christiane. 1984. A Systemtic look at prototyping. Berlin : Institut für


Angewandte Informatik, 1984.

Fowler, Martin und Beck, Kent. 2004. Refactoring: Improving the Design of
Existing Code. s.l. : Addison Wesley Longman, 2004.

Gabriel, Richard. Jamie Zawinski: jwz.org. The Rise of "Worse is Better''. [Online]
[Zitat vom: 11. September 2010.] http://www.jwz.org/doc/worse-is-better.html.

Garvin, David. 1984. What dows "Product Quality" Really Mean. Sloan
Management Review Vol. 25, No. 1. 1984, S. 25-43.

Gerwitz, Hans. 2004. Hans Gerwitz. Premature optimization is the root of all evil.
[Online] 12. August 2004. [Zitat vom: 15. Oktober 2010.]
http://hans.gerwitz.com/2004/08/12/premature-optimization-is-the-root-of-all-
evil.html.

Gloger, Boris. 2008. Scrum: Produkte zuverlässig und schnell entwickeln. München,
Wien : Hanser, 2008.

Godin, Seth. 2010. Linchpin. London : Hachette Digital, 2010.


133

Grabowski, Prof. Dr. Jens. 2004. Vorlesung Software Engineering, Universität


Göttingen. [Online] 2004. [Zitat vom: 7. September 2010.]
http://www.swe.informatik.uni-goettingen.de/notes/SS2004/Grabowski/I-
Einfuehrung-6-auf-1.pdf.

Gundlach, Valerie. 2007. Die DIN EN ISO 9000ff. im Überblick. Norderstedt :


GRIN Verlag, 2007.

Gyger, Daniel. 2003. Agile vs. klassische Methoden der Software-Entwicklung:


Feature-Driven Development. Institut für Informatik: Universität Zürich. [Online]
2003. [Zitat vom: 02. September 2010.]
http://www.ifi.uzh.ch/rerg/fileadmin/downloads/teaching/seminars/seminar_ws0304/
08_Gyger_Fdd_Ausarbeitung.pdf.

Hausschildt, Jürgen. 1993. Innovationsmanagement. München : s.n., 1993.

Hazzan, Orit und Dubinsky, Yael. 2008. Agile Software Engineering. München :
Springer, 2008.

Hesse, Wolfgang, et al. 1984. Ein Begriffsystem für die Softwaretechnik. Vorschlag
zur Terminologie. Informatik Spektrum. 1984, S. 200 - 213.

Hesse, Wolfgang, Merbeth, Günter und Frölich, Rainer. 1992. Software-


Entwicklung: Vorgehensmodelle, Projektführung, Produktverwaltung. München,
Wien : Oldenbourg Verlag, 1992.

Hoffmann, Dirk. 2008. Software-Qualität. Berlin Heidelberg : Springer-Verlag,


2008.

Hoffmann, Ulrich. 2010. FH-Wedel: Software-Engineering. [Online] 2010. [Zitat


vom: 13. August 2010.] http://www.fh-
wedel.de/fileadmin/mitarbeiter/uh/WS200910/SWE345_01_Einleitung.pdf.

Höhn, Reinhard und Höppner, Stephan. 2008. Das V-Modell XT: Anwendungen,
Werkzeuge, Standards. Berlin, Heidelberg, New York : Springer Verlag, 2008.
134

Hyde, Randall. 2004. Write Great Code: Understanding the machine. San
Francisco : No Starch Press, 2004.

IEEE. 2004. Guide to the Software Engineering Body of Knowledge (SWEBOK).


IEEE computer society. [Online] 2004. [Zitat vom: 8. November 2010.]
http://www.computer.org/portal/web/swebok/html/contents.

—. 1990. IEEE Std. 610.12-1990, IEEE Standard Glossary of Software Engineering


Terminology. New York : The Institute of Electrical und Electronic Engineers, 1990.

Jalote, Pankaj. 2008. A Concise Introduction to Software Engineering. London :


Springer Verlag, 2008.

—. 2005. An Integrated Approach to Software Engineering. New York : Springer


Science+Business Media, Inc., 2005.

Jalote, Pankaj, Palit, Aveejeet und Kurien, Priya. 2004. Timeboxing: A Process
Model for Iterative Software Development. Advances in Computers. 2004, 62, S. 67-
103.

Keßler, Heinrich und Winkelhofer, Georg. 2004. Projektmanagement: Leitfaden


zur Steuerung und Führung von Projekten. Berlin Heidelberg : Springer-Verlag,
2004.

Khramtchenko, Serguei. 2004. Comparing eXtreme Programming and Feature


Driven Development in academic and regulated environments. Feature Driven
Development. [Online] 17. Mai 2004. [Zitat vom: 02. September 2010.]
http://www.featuredrivendevelopment.com/files/FDD_vs_XP.pdf.

Kieback, Antoinette, et al. 1992. Prototyping in industriellen Software-Projekten -


Erfahrungen und Analysen. Informatik Spektrum. 1992, Bd. 15, S. 65-77.

Knuth, Donald. 1974. Structured Programming with go to Statements. ACM


Computing Surveys. 1974, Bd. 6, 4.

Lammers, Susan. 1986. Programmers at Work. s.l. : Tempus Books, 1986.


135

Levy, Steven. 1995. Insanely great: the life and time of Macintosh, the computer
that changed everything. s.l. : Penguin Books, 1995.

Liggesmeyer, Peter. 2009. Software-Qualität: Testen, Analysieren und Verfizieren


von Software. Heidelberg : Spektrum Akademischer Verlag, 2009.

Ludewig, Jochen und Lichter, Horst. 2010. Software Engineering: Grundlagen,


Menschen, Prozesse, Techniken. Heidelberg : dpunkt.verlag, 2010.

Martin, Robert. 2003. Agile software development: principles, patterns, and


practices. University of California : Prentice Hall, 2003.

—. 2008. Clean Code: A Handbook of Agile Software Craftsmanship. New York :


Prentice Hall, 2008.

—. 2009. The Duct Tape Programmer. Object Mentor. [Online] 24. September 2009.
[Zitat vom: 11. September 2010.]
http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer.

Molzberger, Peter. 1981. Einführung: Von der Doppelnatur der Software.


[Buchverf.] Heinz Schelle. Software: Moderne Methoden zur Planung, Realisierung
und Kontrolle der Entwicklung. München-Wien : Oldenbourg, 1981, S. 11-19.

Moore, Gordon. 1965. Cramming more components onto integrated circuits.


Electronics. 19. April 1965, S. 114-117.

Myers, Glenford. 2004. The Art of Software Testing. Hoboken, New Jersey : John
Wiley & Sons, 2004.

Nagel, Manfred, et al. 2009. Zukunft Ingenieurwissenschaften - Zunkunft


Deutschland. Berlin Heidelberg : Springer-Verlag, 2009.

No Silver Bullet Revisted. Cox, Brad. 1995. 1995, American Programmer Journal.

No Silver Bullet: Essence and Accidents of Software Engineering. Brooks,


Frederick. 1987. 1987, Computer Magazine, S. 10-19.
136

Palermo, Jeffrey. 2009. Debunking the duct tape programmer. jeffreypalermo.com.


[Online] 25. September 2009. [Zitat vom: 11. September 2010.]
http://jeffreypalermo.com/blog/debunking-the-duct-tape-programmer/.

Palmer, Stephen und Felsing, John. 2002. A Practical Guide to Feature Driven
Development. Upper Saddle River, Nj : Prentice Hall, 2002.

Pfleeger, Sahri Lawrence und Atlee, Joanne. 2010. Software Engineering: Theory
and Practice. New Jersey : Pearson Higher Education, 2010.

Planning the Software Industrial Revolution. Cox, Brad. 1990. 1990, IEEE Software
magazine, Vol. 7, (6), S. 25-33.

Pomberger, Gustav und Pree, Wolfgang. 2004. Software Engineering, Architektur-


Design und Prozessorientierung. München : Carl Hanser Verlag, 2004.

Programming-in-the-large versus programming-in-the-small. DeRemer, Frank und


Kron, Hans. 1975. New York : ACM, 1975. Proceedings of the international
Conference on Reliable Software (Los Angeles, California, April 21 - 23, 1975). S.
114-121.

Randell, Brian. 2001. The NATO Software Engineering Conferences. [Online] 13.
August 2001. [Zitat vom: 8. September 2010.]
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html.

Rising, Linda. 1998. The Patterns Handbook: Techniques, Strategies, and


Applications. Cambridge : Cambridge University Press, 1998.

Roden, Golo. 2010. Feature Driven Development. Visualstudio1.de. 2010, 04, S. 46-
49.

Rosove, Perry. 1967. Developing computer-based information systems. New York :


John Wiley & Sons, 1967.

Royce, Winston. 1970. Managing the Development of large software systems. Los
Angeles : IEEE Wescon, 1970.
137

Schallehn, Elke. 2008. Einführung in die Geschichte der Informatik. [Online] 2008.
[Zitat vom: 7. September 2010.] http://wwwiti.cs.uni-
magdeburg.de/iti_db/lehre/gif/gif_2.pdf.

Schulz, Arno. 1988. Software-Entwurf: Methoden und Werkzeuge. München-Wien :


Oldenbourg, 1988.

Schümmer, Till und Lukosch, Stephan. 2009. Understanding Tools and Practices
for Distributed Pair Programming. Journal of Universal Computer Science. 2009,
Bd. 15, 16.

Seibel, Peter. 2009. Coders at Work. NY : Springer-Verlag New York, 2009.

—. 2009. Duct tape context: A tale of two rewrites. gigamonkeys.wordpress.com.


[Online] 28. September 2009. [Zitat vom: 11. September 2010.]
http://gigamonkeys.wordpress.com/2009/09/28/a-tale-of-two-rewrites/.

—. 2009. Unit testing in Coders at Work. gigamonkeys.wordpress.com. [Online] 5.


Oktober 2009. [Zitat vom: 11. September 2010.]
http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-testing/.

Sneed, Harry. 2005. Software-projektkalkulation: Praxiserprobte Methoden der


Aufwandsschätzung für verschiedene Projektarten. München Wien : Hanser Verlag,
2005.

Software and its impact: a quantitative assessment. Boehm, Barry. 1973. 1973,
DATAMATION, Vol. 19 (5), S. 48-59.

Software Engineering: Report of a conference sponsored by the NATO Science


Committee. Naur, Peter und Randell, Brian. 1968. Garmisch : Scientific Affairs
Division, 1968. The NATO Software Engineering Conferences. S. 231.

Sommerville, Ian. 2007. Software Engineering. München : Pearson Studium Verlag,


2007.

—. 2004. Software Engineering. München : Pearson Studium Verlag, 2004.


138

Spolsky, Joel. 2009. The Duct Tape Programmer. Joel on Software. [Online] 23.
September 2009. [Zitat vom: 10. September 2010.]
http://www.joelonsoftware.com/items/2009/09/23.html.

The Mythical Man-Month. Brooks, Frederick. 1974. 1974, Datamation, S. 44-52.

The Standish Group. 1995. The Chaos Report. Boston : The Standish Group, 1995.

Van Vliet, Hans. 2008. Software Engineering: Principle and Practice. West
Sussex : Wiley, 2008.

Weinberg, Gerald. 1971. The psychology of computer programming. University of


Michigan : Van Nostrand Reinhold, 1971.

Wells, Don. 2000. XP Flow Chart: Project. Extreme Programming. [Online] 2000.
[Zitat vom: 29. August 2010.]
http://www.extremeprogramming.org/map/project.html.

Winter, Mario. 2005. Methodische objektorientierte Softwareentwicklung.


Heidelberg : dpunkt.verlag, 2005.

Wolf, Henning, Rook, Stefan und Lippert, Martin. 2005. extreme Programming:
Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis. Heidelberg :
dpunkt.verlag GmbH, 2005.

Zawinski, Jamie. 2009. That "duct tape" silliness. jwz.livejournal.com. [Online] 28.
September 2009. [Zitat vom: 11. September 2010.]
http://jwz.livejournal.com/1096593.html.

Zöller-Greer, Peter. 2002. Softwareengineering für Ingenieure und Informatiker.


s.l. : Wiesbaden, 2002.
139

Index

90 % Syndrom 23, 39 Evolutionäres Prototyping 33, 111


Accidental difficulties 11 Experimentelles Prototyping 33
Accidential difficulties 129 Exploratives Prototyping 33
Alan Kay 98 Extreme Programming 13, 29, 48, 61
Alistair Cockburn 25, 121 Fault-Based Testing 70
Anwendungs-Software 15 Feature Driven Development 54, 61,
API 86, 101, 128 101, 112
Black-Box-Test 70, 82 Funktionale Prototypen 32
Change Management 38 Garvin 17
CMMI 72 Glass-Box-Test 70
Code and Fix 29, 61 Gordon Moore 7
Code Reading 97 Hive-Faktor 62
Code Review 74, 85, 97 IEEE Standard Glossary 28
Code-Optimierung 92 Industrial Strength Software System
Coding Monkey 4, 128 21, 104
Collective Code Ownership 57, 117 Industrieprogrammierer 127
Computer-System 15 Ingenieur 15
Conway‟s-law-in-the-small 114 Ingenieurs-Prinzipien 15
Coverage-Based Testing 70 Inkrementelle Softwareentwicklung
Creative-Commons 6 35, 98
Demonstrationsprototyp 32 Innovation 126
Duct Tape 76 Iterative Softwareentwicklung 34
Duct Tape Programmer 1, 76 James Coplien 114
Egoless Programming 27 Kernsystem 35
Eigenschaften von Software 19 Kindle 4
Einbahnstraßenmodell Siehe strenge Labormuster 32
Wasserfallmodell Lebenszyklus 17, 20
Error-Based Testing 70 Leichtgewichtiger Prozesse 39
Essential difficulties 11, 19, 128, 129 Literate Programming 93
ETVX-Template 55 Mangel 66, 109
Evolutionäre Entwicklung 34 Mechanische Prüfung 67
140

Million Monkey Ansatz 9 Software Gap 8


Nicht mechanische Prüfungen 67 Software Inspektionen 68
No Silver Bullet 10, 27 Software-Engineering 9, 16
OmniOutliner 4 Softwarekrise 7, 9, 30
Over-Engineering 91 Softwarelebenszyklus 12, 30
Paar-Programmierung 51, 114 Software-Produkt 14
Phasenmodell 39, 60 Softwarequalität 18, 64, 82
Pilotsystem 32 Softwarequalitätssicherung 65
Premature Optimization 125 Software-System 14
Problem of Scale 21 Software-Technik 15
Produktqualität 63 SPICE 73
Produktzyklus 16 Spiralmodell 36, 99, 112
Programming-in-the-large 21 Stereotyp 105, 126
Programming-in-the-small 21, 104 Strenge Wasserfallmodell 31, 40
Projektqualität 63 Sudoko Solver 85
Protoping 111 SWEBOK 24
Prototyping 32 System-Software 14
Prozessmodell 28 Tailoring 38, 44
Prozessmodelle 38 Taylorismus 10
Prozessqualität 72 Test Driven Development 51, 77, 87,
Qualität 17 109, 122
Rational Objectory Process Siehe The Humble Programmer 8
Rational Unified Process The Mythical Man-Month 10
Rational Unified Process 45, 61 Timeboxing-Modell 40, 112
Real artists ship 81 UML 89
Refactoring 34, 51, 87, 102, 124 Unified Process 29, 45
Robert Martin 76, 122, 124 Unit Test 70, 77, 123
Schwergewichtige Prozesse 38 Unit Tests 51
Scrum 58, 61 V-Modell 41
Shrinkware 63 V-Modell XT 41, 61
Smalltalk 98 Vorgehensmodell 28
Software 14 Wasserfallmodell 12, 30, 31, 88, 114
141

Wiederverwendbarkeit 22 Worse is better 82


Wiederverwendung 89 Ziele 19, 103
Wirkungskontext 21