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

Brooks5 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).

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

1970 1980 1990 2000

Formal

Methods

Fagan

Inspections

Structured

Analysis

Waterfall

Model

Jackson Method

CPT

Egoless Programming

SADT/IDEF

Structured

Programming

Turbo Pascal

(IDE)

Structured

Design

Rapid Prototyping

Spiral Model

Hatley-Pirbhai

Ward-Mellor

O-O Programming

O-O Design

O-O Analysis

4GL

V-Model

Cleanroom

Engineering

Synchronize

and Stabilize

Visual

Modeling

UML

RUP

PSP

CMM

TSP

Agile Methods

Pascal Art of Computer

Programming

Mythical Man-Month

SEI

Smalltalk CASE Tools Agile

Manifesto

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 Softwarelebenszyklus6 und das daraus abgeleitete Wasserfallmodell hatten im

Rahmen der „Industrialisierung“ starre Prozessmodelle hervorgebracht – mit

Fachdisziplinen, die einer strikten Rangordnung7 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).

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.

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.

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

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

Kerninformatik

Theoretische

Informatik

Praktische

Informatik Technische

Informatik

Software

Engineering

Softwareentwicklung Softwaremanagement Softwarequalitäts-

management

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

Untersuchungen12

, der daraus abgeleiteten Prinzipien, Methoden und Werkzeuge

(Balzert, 2009 S. 17) sowie einer festen Terminologie13

(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

Voraussetzung

Das vorhandene und verfügbare

technische Knowhow

Ist unter anderem die Inspiration des

Künsters

2 Termine Sind in der Regel mit genügender

Genauigkeit planbar

Sind wegen der Abhängigkeit von

Inspiration nicht planbar

3 Preis Ist an den Kosten orientiert und

darum kalkulierbar

Ist nur durch den Marktwert, nicht

durch die Kosten bestimmt

4 Normen und

Standards

Existieren, sind bekannt und

werden in aller Regel respektiert

Sind rar und werden, wenn sie

bekannt sind, nicht respektiert

5 Bewertung,

Vergleich

Kann nach objektiven,

quantifizierten Kriterien

durchgeführt werden

Ist nur subjektiv möglich, das

Ergebnis ist umstritten

6 Urheber Bleibt meist anonym, hat keine

emotionale Bindung zum Produkt

Betrachtet das Kunstwerk als Teil

seiner selbst

7 Gewährleistung

und Haftung

Sind klar geregelt, können nicht

ausgeschlossen werden

Sind undefiniert und praktisch kaum

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

wesentlicher Hive-Faktor19

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 Gruppen21

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 Reifegradstufen22

. 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

Prozess durch Fähigkeitsgrade mit sechs Stufen.24

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

erst in der Implementierung.

Das Softwaredesign entsteht erst während der

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

shouldn‟t design APIs or GUIs or languages.

Eine API entsteht organisch während der

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

Accidental difficulties 11

Accidential difficulties 129

Alan Kay 98

Alistair Cockburn 25, 121

Anwendungs-Software 15

API 86, 101, 128

Black-Box-Test 70, 82

Change Management 38

CMMI 72

Code and Fix 29, 61

Code Reading 97

Code Review 74, 85, 97

Code-Optimierung 92

Coding Monkey 4, 128

Collective Code Ownership 57, 117

Computer-System 15

Conway‟s-law-in-the-small 114

Coverage-Based Testing 70

Creative-Commons 6

Demonstrationsprototyp 32

Duct Tape 76

Duct Tape Programmer 1, 76

Egoless Programming 27

Eigenschaften von Software 19

Einbahnstraßenmodell Siehe strenge

Wasserfallmodell

Error-Based Testing 70

Essential difficulties 11, 19, 128, 129

ETVX-Template 55

Evolutionäre Entwicklung 34

Evolutionäres Prototyping 33, 111

Experimentelles Prototyping 33

Exploratives Prototyping 33

Extreme Programming 13, 29, 48, 61

Fault-Based Testing 70

Feature Driven Development 54, 61,

101, 112

Funktionale Prototypen 32

Garvin 17

Glass-Box-Test 70

Gordon Moore 7

Hive-Faktor 62

IEEE Standard Glossary 28

Industrial Strength Software System

21, 104

Industrieprogrammierer 127

Ingenieur 15

Ingenieurs-Prinzipien 15

Inkrementelle Softwareentwicklung

35, 98

Innovation 126

Iterative Softwareentwicklung 34

James Coplien 114

Kernsystem 35

Kindle 4

Labormuster 32

Lebenszyklus 17, 20

Leichtgewichtiger Prozesse 39

Literate Programming 93

Mangel 66, 109

Mechanische Prüfung 67

140

Million Monkey Ansatz 9

Nicht mechanische Prüfungen 67

No Silver Bullet 10, 27

OmniOutliner 4

Over-Engineering 91

Paar-Programmierung 51, 114

Phasenmodell 39, 60

Pilotsystem 32

Premature Optimization 125

Problem of Scale 21

Produktqualität 63

Produktzyklus 16

Programming-in-the-large 21

Programming-in-the-small 21, 104

Projektqualität 63

Protoping 111

Prototyping 32

Prozessmodell 28

Prozessmodelle 38

Prozessqualität 72

Qualität 17

Rational Objectory Process Siehe

Rational Unified Process

Rational Unified Process 45, 61

Real artists ship 81

Refactoring 34, 51, 87, 102, 124

Robert Martin 76, 122, 124

Schwergewichtige Prozesse 38

Scrum 58, 61

Shrinkware 63

Smalltalk 98

Software 14

Software Gap 8

Software Inspektionen 68

Software-Engineering 9, 16

Softwarekrise 7, 9, 30

Softwarelebenszyklus 12, 30

Software-Produkt 14

Softwarequalität 18, 64, 82

Softwarequalitätssicherung 65

Software-System 14

Software-Technik 15

SPICE 73

Spiralmodell 36, 99, 112

Stereotyp 105, 126

Strenge Wasserfallmodell 31, 40

Sudoko Solver 85

SWEBOK 24

System-Software 14

Tailoring 38, 44

Taylorismus 10

Test Driven Development 51, 77, 87,

109, 122

The Humble Programmer 8

The Mythical Man-Month 10

Timeboxing-Modell 40, 112

UML 89

Unified Process 29, 45

Unit Test 70, 77, 123

Unit Tests 51

V-Modell 41

V-Modell XT 41, 61

Vorgehensmodell 28

Wasserfallmodell 12, 30, 31, 88, 114

141

Wiederverwendbarkeit 22

Wiederverwendung 89

Wirkungskontext 21

Worse is better 82

Ziele 19, 103