\documentclass[oneside]{article}
\usepackage[dvips, pdfauthor={Jan Hendrik Dithmar}, pdftitle={Extreme Programmierung}, a4paper]{hyperref}
\usepackage{german}

\begin{document}

  \begin{titlepage}
    {\centering \Huge \sffamily\bfseries Extreme Programming\\}
    {\centering \large \sffamily\bfseries Ein Bericht "uber den Vortrag von Herrn Prof. Dr. Andreas Zeller\\}
    {\centering \sffamily\bfseries Von Jan Hendrik Dithmar\\}
  \end{titlepage}

  \newpage

    Prof. Dr. Andreas Zeller er"offnet die Ringvorlesung \glqq Perspektiven der Informatik\grqq\ mit seinem Vortrag "uber \glqq Extreme Programming\grqq . Zun"achst stellt er kurz heraus, dass es grunds"atzlich zwei Arten bei der Programmentwicklung gibt: die Arbeit allein oder die Arbeit im Team. \\

    F"ur die Arbeit stellt er den Studentinnen und Studenten den \glqq Code-and-Fix-Zyklus\grqq\ vor, bei dem es im wesentlichen drei Schritte gibt:

    \begin{enumerate}
      \item Code schreiben und testen
      \item Code \glqq verbessern\grqq\ (Fehlerbeseitigung, Erweiterung, Effizienz, \dots)
      \item wieder bei Punkt 1 beginnen
    \end{enumerate}

    Daf"ur gelten aber ganz spezielle Voraussetzungen. Denn das Problem muss ganz klar spezifiziert sein und eine Person sollte das Programm allein erstellen und "uberschauen k"onnen. Treffen diese zwei Punkte zu, so ist gegen die \glqq Code-and-Fix-Zyklus\grqq -Methode nichts einzuwenden.
    Diese Programmiermethode hat allerdings auch gewaltige Nachteile, denn man kann keine Prognose "uber die Kosten oder die Qualit"at -- schon gar nicht "uber einen m"oglichen Fertigstellungstermin -- machen. Des weiteren nimmt die Qualit"at des jeweiligen Produkts mehr und mehr ab, je l"anger man daran bastelt. Irgendwann ist man an dem Punkt angelangt, an dem es schwer f"allt, das Programm zu warten bzw. an dem die Wartung gar nicht mehr m"oglich ist.
    Da diese Programmiermethode de facto nur f"ur 1-Personen-Projekte geeignet ist, kommt auf eine Firma ein gro"ses Problem zu, wenn der verantwortliche Programmierer k"undigt. In dieser Situation kann der Extremfall eintreten: dass der Quellcode ist nicht mehr zu gebrauchen ist, da au"ser dem Programmierer diesen keiner richtig durchschaut.
    Wenn man daraus die Konsequenzen zieht, stellt man fest, dass es unausweichlich ist, gro"se Software-Projekte sorgf"altig zu planen und zu koordinieren.
    Sobald ein Programmierer f"ur einen Anwender eine Software erstellen soll, sind Meinungsverschiedenheiten, was den Funktionsumfang etc. betrifft, schon vorprogrammiert. In diesem Fall steht der Informatiker vor einer ernstzunehmenden Herausforderung: er muss herausfinden, was der Anwender eigentlich will. \\
    Im Jahre 1968 f"uhrten diese Probleme zur sogenannten \glqq Software-Krise\grqq . \\

    Als Konsequenz der Software-Krise entwickelte man das sogenannte \glqq Wasserfallmodell\grqq . Dieses Modell ist in f"unf Phasen gegliedert: 
      \begin{itemize}
        \item Anforderungen,
        \item Entwurf,
        \item Codierung,
        \item Test und
        \item Produktion. \\
      \end{itemize}

    In der ersten Phase (Anforderungen) wird festgelegt, was das Programm leisten soll. Dabei wird nicht n"aher darauf eingegangen, wie es das tut, denn dies ist nicht im Interesse des Auftraggebers. Endprodukt dieser ersten Phase ist ein \itshape Pflichtenheft\upshape , welches alle relevanten Merkmale der Software bez"uglich Funktionsumfang und Qualit"at enthalten und pr"azise beschreiben, sowie vollst"andig, konsistent und f"ur Auftraggeber und Auftragnehmer verst"andlich sein soll. \\
    Allerdings ist Forlgendes anzumerken: man wird es generell nicht schaffen, ein Pflichtenheft pr"azise und -- zumindest f"ur den Auftraggeber -- verst"andlich zu formulieren. \\

    Die zweite Phase besch"aftigt sich mit zwei Fragen die Systemarchitektur betreffend: Welche Module gibt es und wie stehen sie untereinander in Beziehung? Sind die Fragen bez"uglich der Systemarchitektur gekl"art, so entsteht eine \itshape Entwurfsbeschreibung\upshape . Die Entwurfsbeschreibung bildet die Grundlage f"ur Phase 3: die Codierung des Programms. \\

    Nun beginnt das, was sich viele Leute unter der Arbeit des Informatikers vorstellen: die Implementierung (im Volksmund: Programmierung). Liegt ein sorgf"altig ausgearbeiteter Entwurf vor, so ist die dritte Phase recht einfach und macht lediglich 10-15\% der eigentlichen Arbeit an der Software aus. Als Ergebnis dieser Phase kann man nun den \itshape Programmcode\upshape\ bewundern. \\

    Nun kann Phase 4 beginnen: die Testphase. Das Testen (Validieren) der Software kann sehr gut durch Gegenlesen eines zweiten Programmierers geschehen (Reviews). Eine weitere M"oglichkeit ist das Vorhaben, bewusst Fehler zu produzieren. Bei kritischer Software, z.B. bei Flugzeugen oder Satelliten, wird man allerdings keine der beiden Methoden verwenden. In diesem Fall versucht man die Validierung des Produkts durch Programmbeweise. \\
    Ein Programmierer zeigt meist eine gewisse Beziehung zu seinem Programm. Da die Validierung ein destruktiver (= zerst"orerischer) Prozess ist, sind es sehr oft Dritte, die diesen Prozess vornehmen. In der Regel will der Programmierer selbst seine Sch"opfung nicht zerst"oren. Wurde das Programm ausf"uhrlich getestet, so kann man in die f"unfte Phase "ubergehen: die Produktion. \\

    Bei der Produktion wird die fertige Software beim Kunden installiert und danach gewartet. Wartung von Software ist ein wichtiger Teil und macht 50\% der Kosten aus. \\

    Das Wasserfallmodell brachte klare Vorz"uge, wie z.B. strukturiertes Vorgehen, klares Benennen einzelner Phasen und ihrer Anforderungen, als auch die M"oglichkeit des ersten Messens und Absch"atzens des Entwicklungsaufwandes. Allerdings hat dieses Modell nicht nur Vorz"uge. Durch Verfeinerungen, wie z.B. der Durchf"uhrung fr"uher Tests -- sobald etwas implementiert wurde -- und der Tatsache, dass der Kunde Prototypen des Produkts sehen und ausprobieren kann (R"uckkopplung), konnte der Prozess der Softwareentwicklung optimiert werden. \\

    Ein weiterer Punkt im Vortrag: die \glqq Prozessmodellierung\grqq . Die dahinter steckende Grundidee ist folgende: Entwicklungsprozesse sind auch nur Software. Auf Grund dieser Idee kamen in den 90ern immer mehr programmierte Entwicklungsumgebungen auf. Folge der Prozessmodellierung war eine automatisierte, sehr systematische Programmentwicklung. Doch kommen dabei auch Fragen auf: Bringt eine systematische Entwicklung auch systematische Programme vor? Lassen sich Programmierer gerne automatisieren? \\

    Man nimmt an, dass die "Anderungskosten exponentiell ansteigen. Dies hei"st f"ur die Softwareentwicklung, dass man schon bei den Anforderungen und dem Entwurf sehr sorgf"altig arbeiten muss. Je sp"ater eine "Anderung erfolgt, desto mehr muss man zur"uckgehen und die Informationen auf den neusten Stand bringen (angefangen bei den Anforderungen, "uber den Entwurf,\dots). Nun stellt sich die Frage: wie viel Aufwand sollte man dann f"ur den Entwurf betreiben? Auf der einen Seite ist ein gro"ser Aufwand beim Entwurf gut, jedoch stellen sich dem Informatiker einige Probleme. Die Erstellung der Anforderungen und des Entwurfs k"onnen sehr viel Zeit in Anspruch nehmen. In dieser Zeit k"onnen sich die Einsatzbedingungen l"angst ge"andert haben. Des weiteren k"onnen manche Anforderungen nur beim Einsatz eines Prototypen gekl"art werden. Da ein Prototyp fr"uhestens nach der Codierungsphase zur Verf"ugung steht, bedeutet eine "Anderung sehr viel Aufwand und auch hohe Kosten. Au"serdem ist eine fr"uhe Verf"ugbarkeit der Software w"unschenswert und kann sogar "uber die Zukunft einer Firma entscheiden. \\
    Es w"are also ein sehr gro"ser Vorteil, die "Anderungskosten niedrig und kostant zu halten und gleichzeitig flexibel zu sein. In diesem Fall greift das Modell des \itshape Extreme Programming\upshape\ oder kurz XP. Extreme Programming ist ein Vorgehensmodell f"ur kleine bis mittelgro"se Teams, deren Anforderungen vage sind und/oder sich schnell "andern k"onnen. Extreme Programming beruht auf bew"ahrten Techniken und setzt diese in h"ochstem (extremem) Ma"se ein. \\

    Ein wichtiger Vorteil ist das Programmieren in Paaren. Somit wird schon w"ahrend der Programmentwicklung kontinuierlich der Quellcode auf seine Richtigkeit und Konsistenz "uberpr"uft. Ein weiterer Punkt ist das automatische bzw. automatisierte Testen von Komponenten. Kontinuierliches Design und Redesign der Software sowie kurze Release-Zyklen, die eine kontinuierliche R"uckmeldung und ein st"andiges Einbeziehen des Auftraggebers gew"ahrleisten sollen, sind weitere Vorteile. \\
    In den 90er Jahren kam man zu der Erkenntnis, dass das Gegenlesen von Programmen der beste Weg ist, die Qualit"at zu steigern. Im Extreme Programming findet dieser Vorteil Anwendung. Deshalb wird in Paaren programmiert. Das bedeutet: ein Monitor und eine Tastatur, aber zwei Programmierer. Vorteil hierbei ist (wie schon oben erw"ahnt): es findet ein st"andiger Dialog zwischen den beiden statt, weil der eine schreibt und der andere gegenliest. Au"serdem findet hier keine Spezialisierung auf Rollen (z.B. \glqq Programmierer\grqq\ und \glqq Tester\grqq ), sondern eine h"aufiger Rollen- und damit verbundener Tastaturtausch statt. \\

    Als Beispiel, wie erfolgreich das Programmieren in Paaren ist, kann man das \glqq C3 Chrysel Payroll System\grqq\ von 1997 anf"uhren. Teile dieses Projekts wurden zum einen in Einzelarbeit, zum anderen in Paararbeit erstellt. Tatsache ist, dass nicht nur das System termin- und ressourcengerecht installiert wurde, sondern dass nahezu alle in den ersten 5 Monaten des Einsatzes aufgetretene Fehler aus der Einzelarbeit stammten. \\
    Als zweites Beispiel kann man ein Experiment der Universit"at in Utah aus dem Jahre 1999 anf"uhren: 13 Einzelprogrammierern (Studenten) und 14 Programmiererpaaren wurden 4 Aufgaben in 6 Wochen gestellt. Danach wurden die eingereichten Programme getestet. Als Ergebnisse konnte man damals festhalten, dass Programmiererpaare zum einen bessere Qualit"at produzieren und zum anderen schneller fertig sind. Paar-Programmierer finden au"serdem, dass die Arbeit in Paaren ihr Vertrauen in das Programm erh"oht (96 \%) und mehr Spass macht als Einzelarbeit (94 \%). Ein weiteres Argument f"ur die Arbeit in Paaren ist folgendes: bei der Arbeit im Programmiererteam beschr"ankt man sich auf die wesentlichen Dinge der Programmerstellung. Das wichtigste bei der Arbeit im Programmiererteam ist, dass die Chemie zwischen den Partnern stimmen sollte, ja sogar stimmen muss. \\

    Ein weiterer wichtiger Punkt ist das kontinuierliche (automatische) Testen der Programme. Ziel ist es, jederzeit die Funktionsf"ahigkeit des Systems zu gew"ahrleisten. Auch diese Art der Validierung hat ihre Vor- und Nachteile. Im Extreme Programming werden z.B. lediglich Testf"alle definiert, bevor eine Implementierung stattfindet. Gut dabei ist, dass der Test die Modulfunktion aus exemplarischer Sicht beschreibt und dass die Tests automatisch ablaufen (selbst radikale "Anderungen k"onnen so validiert werden). Des weiteren sind Testf"alle formaler als Spezifikationen und k"onnen auftretende Fehler dokumentieren: f"ur jeden neuen Fehler wird sofort ein reproduzierender Testfall erstellt. Jedoch gibt es auch einen sehr gro"sen Nachteil: die Testf"alle als Spezifikation decken nur Beispiele ab. \\

    F"ur das Software-Praktikum der Universit"at Saarbr"ucken bedeutet dies, dass das Verhalten des Systems durch Szenarios beschrieben wird und dass diese Szenarios in ausf"uhrbare Testf"alle gegossen werden, bevor implementiert wird. Testbarkeit verbessert die Systemstruktur erheblich: die Subsysteme werden deutlich mehr entkoppelt und es findet eine deutliche Trennung von Funktionalit"at und Pr"asentation statt. \\
    Konkret hei"st das, dass man durch konsequente Testbarkeit selbst gr"o"sere "Anderungen am System vornehmen kann, ohne die Qualit"at oder Stabilit"at zu gef"ahrden. Diese Methode findet im XP Anwendung, damit das System stets so einfach wie m"oglich gehalten wird. Man kann vier Punkte aufz"ahlen, wann ein Design richtig ist:

      \begin{itemize}
        \item alle Testf"alle m"ussen korrekt behandelt werden,
        \item es d"urfen keine Redundanzen enthalten sein,
        \item alle wichtigen Absichten m"ussen klar ausgedr"uckt sein und
        \item das System muss mit einer minimalen Anzahl von Klassen und Methoden auskommen.
      \end{itemize}

    Refactoring (w"ortl. \glqq Refaktorisieren\grqq ) beinhaltet das Umstrukturieren von Software in weitgehend unabh"angige Faktoren. Beim XP finden sogenannte Refactoring-Verfahren beim systematischen Redesign Anwendung. Refactoring-Verfahren sind z.B. die \itshape Extract Method\upshape\ (Code zu einer Methode zusammenfassen), die \itshape Move Method\upshape\ (Bewegen einer Methode von Klasse zu Klasse), \dots Erste Werkzeuge realisieren bereits solche Methoden. \\
    Der Vorteil bei der Extract Method: das System ist und bleibt stets wohlstrukturiert. Nachteile sind, dass man fast nichts der Arbeit au"serhalb des Projekts wiederverwenden kann. \\

    Wichtiger Unterschied ist, dass beim XP der Auftraggeber die Anforderungen "uber Stories beschreibt. Jede Story beschreibt einen konkreten Vorfall, der f"ur den Betrieb des Systems notwendig ist. Beim Extreme Programming werden keine Entwurfsphasen ben"otigt; das Programmieren steht im Mittelpunkt. Die Funktionalit"at der Software wird in Stories zusammengefasst und jede Story in einen Testfall umgesetzt. Dieser wird dann implementiert. Die Implementierung selbst ist abgeschlossen, wenn alle Testf"alle bestanden sind. Sollten bei der Abnahme weitere Fragen auftreten, so werden neue Stories formuliert. Das Spiel beginnt von vorne. Sehr vorteilhaft dabei ist, dass der Kunde st"andig in die Entwicklung einbezogen ist. Der Projektfortschritt wird gemessen an den erfolgreich getesteten Stories. \\

    Das Modell des Extreme Programming wird allerdings auch kritisiert: das Vorgehensmodell sei unvollst"andig, denn Stories alleine reichten nicht aus, ein System zu beschreiben. Ein weiterer Kritikpunkt besteht darin, dass Extreme Programming keine Aussage "uber Qualit"at und die Integration von Qualit"atsstandards macht und dass man die Kosten der Entwicklung nicht absch"atzen kann. Als einzig logische Folge hat man also Extreme Programming mit bew"ahrten Verfahren und Modellen erg"anzt. \\

\end{document}
