die personelle Organisation,Die Vorgehensmodelle (siehe Kap. 9) sind geeignet, dem Projektleiter und den Entwicklern Hinweise zu geben, welche Tätigkeit als nächste auszuführen ist. Sie machen aber keine Aussagen über
die personelle Organisation,
die Gliederung der Dokumentation,
die Verantwortlichkeiten für Aktivitäten und Dokumente.
Nimmt man diese Punkte zur Vorgabe des Ablaufs hinzu, so entsteht aus dem Vorgehensmodell ein Prozessmodell. Wenn dieses für eine Firma oder eine Abteilung verbindlich vorgegeben, also standardisiert ist, wird es möglich,
Planungen (halbfertig) »von der Stange« zu verwenden,
Werkzeuge und Methoden gemeinsam einzuführen,
Resultate zu vergleichen und auszutauschen,
Schwachstellen zu erkennen und aus Erfahrungen zu lernen.
Die Literatur bietet eine Reihe sehr unterschiedlicher Prozessmodelle an. Bevor man eines davon übernimmt, sollte man aber in jedem Falle den Prozess, wie er bisher verstanden und gelebt wird, feststellen und analysieren, um seine Stärken und Schwächen zu erkennen, damit man nicht am Ende den Spatzen in der Hand preisgegeben hat, um – mit unsicherem Ausgang – die Taube auf dem Dach zu jagen. Änderungen des Prozesses sind mühsam und riskant. Wenn man sich darauf einlässt, sollte man genau wissen, was man erreichen will und was man verlieren kann.
In der öffentlichen Diskussion ist das Thema der Prozesse – ähnlich wie früher, manchmal auch heute noch, das Thema der Programmiersprachen – durch Heilslehren, Glaubenskriege und Lagerdenken geprägt. Das macht eine rationale Auseinandersetzung mit den Konzepten schwierig und eine Synthese nahezu unmöglich. Natürlich sind auch die Verfasser dieses Buches nicht frei von Emotionen. Aber wir bemühen uns um eine rationale Wertung.
Ein (Software-)Prozessmodell ist die Beschreibung eines Software-Prozesses als präskriptives Modell für die Durchführung der Projekte. Da ein solches Modell nicht alle Details vorgeben kann, weil sie nach den konkreten Bedingungen der speziellen Projekte unterschiedlich ausgeprägt werden müssen, lässt es mehr oder minder große Spielräume für die konkrete Ausgestaltung. Entsprechend kann ein Prozessmodell sehr karg sein, also nur einige zentrale Punkte vorgeben, oder sehr detailliert, sodass die Projekte kaum Unterschiede aufweisen.
Überall, wo das Prozessmodell keine (genauen) Vorgaben macht, müssen sie für jedes Projekt oder für eine Gruppe sehr ähnlicher Projekte hinzugefügt werden. Diesen Vorgang bezeichnet man als Prozessausprägung (Tailoring). Durch die Prozessausprägung wird aus dem generischen Prozessmodell ein konkreter Prozess, der im Idealfall eins zu eins im Projekt umgesetzt wird. Natürlich muss dieser konkrete Prozess geprüft und abgenommen werden, bevor er zum Einsatz kommt.
Ob es sinnvoll ist, mit den Vorgaben sehr weit zu gehen, hängt von den Rahmenbedingungen ab: Ein Software-Haus, das für eine heterogene Kundschaft arbeitet, braucht große Freiheit bei der Ausprägung der Prozesse, weil der eine Kunde verlangt, was der andere auf keinen Fall haben will. Dagegen profitiert eine Bank, die ein riesiges Software-System einsetzt, von einer weit reichenden Standardisierung. Auch die Kultur der Firma spielt eine wichtige Rolle: Entwickler mit Cowboy-Mentalität lassen sich kaum auf einen rigiden Prozess ein, während viele disziplinierte Programmierer einen solchen Prozess begrüßen.
Es ist daher nicht möglich, eine allgemeingültige Festlegung zu treffen, was alles zu einem Prozessmodell gehört. In der Regel finden sich darin Aussagen zu folgenden Punkten:
Organisation und Verantwortlichkeiten, Rollenverteilung
Struktur und Merkmale der Dokumente
einzusetzende Verfahren, z. B. für die Erhebung der Anforderungen oder für die Prüfung der Zwischenergebnisse
die auszuführenden Schritte der Entwicklung, ihre Reihenfolge und ihre Abhängigkeiten (das Vorgehensmodell)
Projektphasen und Meilensteine, Prüfkriterien
Notationen und Sprachen
Werkzeuge
Mindestens implizit ist durch das Prozessmodell auch eine bestimmte Terminologie vorgegeben, beispielsweise für die Rollen und die Dokumente im Projekt.
Das Feld der Prozessmodelle ist unübersichtlich und nicht abgegrenzt. Täglich werden neue erdacht, vielleicht ausprobiert und meist verworfen; nur gelegentlich schafft eines den Sprung in die Fachwelt, wird Gegenstand von Publikationen und Kursen und schließlich auch eingesetzt. Aber nur ganz selten sind die neuen Prozessmodelle wirklich neu. In der Regel werden bekannte Konzepte neu kombiniert, neu etikettiert – und als Wundermittel angeboten.
Im Zusammenhang mit den sogenannten agilen Prozessen ist die Unterscheidung zwischen leichten und schweren Prozessmodellen aufgekommen. Leider ist unklar, worauf sich diese Attribute beziehen. Ganz offensichtlich sind alle Prozessmodelle, die von ihren Verfassern als leicht eingestuft werden, durch einen geringen Aufwand für die Dokumentation gekennzeichnet. Das ist natürlich kein Wert an sich. Wer bei schönem Wetter durch Kalifornien fährt, fühlt sich in einem leichten, womöglich offenen Wagen sehr wohl; wer eine Expedition durch die Wüste Taklamakan unternimmt, braucht ein sehr stabiles Fahrzeug mit Allradantrieb, das große Mengen an Lebensmitteln, Zelten, Treibstoff, Werkzeug und Ersatzteilen befördern kann. Die Entscheidung, welche Dokumentation erforderlich ist, muss also unter dem Gesichtspunkt getroffen werden, welche später mutmaßlich benötigt wird.
Weit verbreitet ist auch die Vorstellung, dass »schwere Prozesse« eigentlich schwerfällige, wenig flexible Prozesse sind. Natürlich ist ein Prozessmodell, das eine vollständige Planung zu Beginn des Projekts vorsieht, hinderlich, wenn der Projektverlauf immer wieder Änderungen des Plans erfordert. Aber auch für die Flexibilität gilt, was oben zur Dokumentation gesagt wurde: Wenn es darum geht, einen wankelmütigen Kunden zu bedienen, ist Flexibilität notwendig; wenn aber ein komplexes System aus Hardware, Software und nicht zuletzt menschlicher Organisation entstehen soll, ist die Stabilität und Zuverlässigkeit der Arbeiten, die getrennt ausgeführt werden, vorrangig.
Eine weitere Interpretation des Wortes »leicht« bezieht sich auf die Menge der Regeln. Allerdings zeigt sich, dass die »leichten Prozesse« keineswegs besonders wenige Regeln haben, sie haben nur andere als die vermeintlich schweren Prozesse.
Schließlich gibt es – beim V-Modell, siehe Abschnitt 10.3 – die verwirrende Situation, dass ein nach landläufiger Einschätzung schweres Prozessmodell als eine von mehreren Möglichkeiten das Vorgehen nach dem Konzept der leichten Modelle anbietet. Die Situation ist also alles andere als klar. Wir machen darum keinen Versuch, die Prozesse in das Schema »leicht – schwer« einzuordnen.
In Abschnitt 8.3.2 haben wir bereits beschrieben, dass Phasen und Meilensteine wichtige Elemente der Projektplanung sind. Nachfolgend gehen wir auf diese für die Prozessmodelle wichtigen Konzepte genauer ein.
Eng mit dem Software-Lebenslauf verbunden ist die Vorstellung, dass er in Abschnitte, sogenannte Phasen, gegliedert ist, an deren Grenzen wesentliche Änderungen eintreten. Am auffälligsten ist eine solche Änderung, wenn sie als sichtbare Metamorphose verläuft wie bei einer Libelle, die sich aus einer Larve befreit. Phasen sind also Abschnitte des Lebenslaufs, die Anfang und Ende haben, nicht unterbrochen werden können und nicht überlappen.
Auch eine längere Wanderung ist in Etappen (= Phasen) gegliedert. Wenn ein Meilenstein (allgemeiner ein markanter Punkt mit bekannter Position) erreicht ist, endet die eine und beginnt die nächste Etappe. Bei der Planung der Wanderung schätzen wir ab, wie viel Zeit und wie viel Wegzehrung wir für jede Etappe brauchen werden. Sicher vorhersagen können wir aber weder das eine noch das andere. Der Weg kann weit schwieriger sein als erwartet, oder wir verlaufen uns. Dann erreichen wir den Meilenstein mit Verspätung und haben bereits die Vorräte für die nächste Etappe verzehrt. Der Meilenstein steht, wo er steht, er kommt uns nicht entgegen, wenn wir langsam gehen. Darum ist die Phase der Weg bis zu einem bestimmten Ziel. Wie viel Zeit dieser Weg benötigt, ist im Allgemeinen erst klar, wenn das Ziel erreicht ist.
Die Gliederung einer Wanderung in Etappen hat einige Vorteile:
Wir stellen fest, ob unsere Zeitschätzung realistisch war. Bei großer Abweichung korrigieren wir die Planung für die folgenden Etappen.
Wir stellen fest, dass wir noch auf dem richtigen Weg sind.
Wir teilen uns die Wegzehrung sinnvoll ein.
Wenn wir langsamer vorankommen, als geplant war, können wir eventuell eine Abkürzung nehmen oder einen Teil des Weges fahren statt gehen.
Wenn wir schon bis zum ersten oder zweiten Meilenstein viel zu lange brauchen, brechen wir die Wanderung ab, bevor wir in große Schwierigkeiten geraten.
Das Bild der in Etappen gegliederten Wanderung können wir komplett in das Projektmanagement übernehmen. Wir legen Zwischenziele, Meilensteine, fest, und schätzen ab, wie viel Zeit und welche Mittel wir für jede Phase brauchen. Dann führen wir das Projekt entsprechend der Planung durch und verfolgen dabei, ob wir planmäßig vorankommen. Bei kleinen Verzögerungen versuchen wir in der Regel, die Leistung zu erhöhen, sodass wir den Rückstand aufholen. Bei großen Abweichungen müssen wir mehr Zeit vorsehen (also die Termine verschieben) oder die Projektziele reduzieren oder das Projekt abbrechen.
Auch im Software-Projekt gilt für die Meilensteine, dass sie durch die Ziele, nicht durch den Termin definiert sind. Ein Meilenstein »Spezifikation fertig« mag für den 31. Oktober geplant sein; erreicht ist er nicht am 31. Oktober, sondern erst, wenn die Spezifikation fertig ist. Dazu sind klare Kriterien anzugeben; es reicht nicht aus, wenn die Entwickler versichern, dass alle Ziele erreicht sind. Erst wenn alle Teilresultate vorliegen und abgenommen sind, kann der Meilenstein gefeiert werden.
Wir folgen bei der Definition des Meilensteins Wallin et al. (2002):
A milestone is defined as a scheduled event that marks the completion of one or more important tasks, and it is used to measure achievements and development progress. At a milestone, a predefined set of deliverables should have reached a predefined state to enable a review.
Wir stellen aber klar, dass das Review oder allgemeiner die (bestandene) Prüfung eine Voraussetzung, keine Folge des Meilensteins ist. Für jeden Meilenstein wird definiert,
welche Ergebnisse (Dokumente) vorliegen müssen,
wer nach welchen Kriterien welche Prüfung vornimmt und
wer schließlich entscheidet, ob der Meilenstein erreicht ist.
Die Definition der Phase ist unmittelbar an die des Meilensteins geknüpft: Eine Phase ist der Zeitraum zwischen zwei Meilensteinen. Zwischen Beginn und Ende der Phase werden die Arbeiten durchgeführt, deren Ergebnisse vor dem Meilenstein geprüft werden. Am Meilenstein »Spezifikation fertig« (das könnte der Meilenstein M1 in Abb. 10–1 sein) muss die Spezifikation geprüft sein. Also ist die Phase 1 die Spezifikationsphase.
Abb. 10–1 Das Konzept der Phasen und Meilensteine
Das Phasenmodell kann damit wie folgt charakterisiert werden:
Die Software-Entwicklung wird vor Beginn in Phasen gegliedert, die streng sequenziell durchlaufen werden. Für jede Phase gibt es ein eigenes Budget; dieses Budget wird erst freigegeben, wenn der vorangehende Meilenstein erreicht ist. Dann kann die nächste Phase beginnen.
Wegen der strikten Verknüpfung der Phasen mit den Budgets wird das Phasenmodell auch Kostenmodell genannt. In der Planung werden die Phasen durch Arbeitspakete (siehe Abschnitt 8.3.1) verfeinert; das kann teilweise erst im Projektverlauf geschehen, wenn die Strukturen des Systems geklärt sind.
Mit dem Begriff des Phasenmodells ist keine Festlegung auf eine bestimmte Definition oder Reihenfolge der Phasen verbunden. Ausprägungen des Phasenmodells können also sehr unterschiedlich aussehen.
Die logische Sequenz Phasenanfang – Entwicklung – Prüfung – Phasenende suggeriert, dass die Prüfungen – wie eine Abiturprüfung am Ende einer langen Schulzeit – jeweils unmittelbar vor dem Meilenstein stattfinden. Das ist falsch. Auch innerhalb einer Phase gibt es Teilergebnisse, die sofort geprüft werden sollten. Am Ende müssen alle Prüfungen abgeschlossen sein, sie können aber bereits weit früher durchgeführt werden.
Im Beispiel oben war von der Spezifikationsphase die Rede. Haben wir also einfach das Wasserfallmodell mit Meilensteinen garniert, aber im Übrigen unverändert übernommen? In Abschnitt 9.2.1 hatten wir bereits festgestellt, dass das nicht funktioniert. Tatsächlich gibt es zwei wesentliche Unterschiede zwischen dem Phasenmodell und dem Wasserfallmodell:
Im Phasenmodell gibt es keine Zyklen. Eine abgeschlossene Phase kann nicht wieder geöffnet werden, sie ist Vergangenheit. Darum dokumentiert das Erreichen eines Meilensteins einen Fortschritt des Projekts.
Da kein Prozessmodell der Welt verhindern kann, dass Fehler gemacht werden, die erst später auffallen, oder dass der Kunde neue Anforderungen vorträgt, obwohl die Analyse längst abgeschlossen ist, oder dass auf Grund neuer Einsichten frühere Entscheidungen revidiert werden müssen, kann das Phasenmodell die Rückkehr in frühere Tätigkeiten nicht verbieten. Nur finden diese Tätigkeiten im Budget und unter den Bedingungen der gerade laufenden Phase statt. Das bedeutet: Sie werden sehr strikt überwacht, der Entwickler arbeitet quasi unter Aufsicht.
Auf den ersten Blick erscheint das wie ein Etikettenschwindel: Wir dürfen zwar nicht die Zyklen des Wasserfallmodells durchlaufen, sondern müssen in der Phase bleiben, in der wir sind. Aber wir können trotzdem die früheren Tätigkeiten fortsetzen. Dieser Eindruck täuscht. Wenn ein Entwickler bei der Arbeit an der Spezifikation einen Fehler im entstehenden Dokument bemerkt, klärt er die Sache auf und beseitigt den Fehler. Ganz anders sieht es aus, wenn sich erst bei der Codierung ein Fehler der Spezifikation zeigt. Die Entwickler können die Spezifikation nicht einfach korrigieren, auch dann nicht, wenn sie selbst die Verfasser sind. Der Fehler wird dokumentiert, und der Verantwortliche muss entscheiden, ob er behoben werden soll. (Manchmal ist es sinnvoller, eine bestimmte Funktion abzuschalten oder eine Warnung ins Handbuch zu drucken.) War die Entscheidung positiv, so wird die Spezifikation geändert. Dann wird sie nach den gleichen Kriterien geprüft, die am Meilenstein am Ende der Spezifikationsphase gültig waren. Alle, die auf der Basis der fehlerhaften Spezifikation gearbeitet hatten, z. B. die Codierer, die Tester, die Verfasser des Handbuchs, werden über die Änderung informiert, damit sie prüfen können, ob ihre Ergebnisse davon betroffen sind. Schließlich ersetzt die neue Version der Spezifikation die alte. Die Änderung eines bereits geprüften Dokuments ist also wesentlich aufwändiger. Der Mehraufwand ist durch die großen Risiken gerechtfertigt, die mit einer unkontrollierten Änderung verbunden sind.
Natürlich spielt aus den genannten Gründen die Konfigurationsverwaltung (siehe Kap. 21) im Phasenmodell eine wichtige Rolle. Sie garantiert, dass das Baselining zuverlässig funktioniert, also das »Einfrieren« der Dokumente, die gerade geprüft werden oder bereits geprüft und abgenommen sind.
Das Phasenmodell bringt erheblichen Aufwand für die Organisation und für die Prüfungen mit sich. Dafür gibt es eine Reihe von Vorteilen:
Das Projekt ist präzise geplant und organisiert. Abweichungen von der Planung sind leicht erkennbar, weil sie sich spätestens dann zeigen, wenn ein Meilenstein nicht wie geplant erreicht wird.
Die Dokumente, deren Erstellung geplant wurde, werden geprüft; entsprechen sie nicht den Anforderungen, ist der Meilenstein noch nicht erreicht. Damit ist sichergestellt, dass die Dokumente nach dem Meilenstein vorhanden sind und den Anforderungen genügen. Das ist in weniger systematisch geführten Projekten keineswegs selbstverständlich.
Der Personalbedarf ist ebenfalls frühzeitig geklärt. Damit kann sichergestellt werden, dass die Entwickler zur richtigen Zeit verfügbar sind und später auch wieder rechtzeitig an andere Projekte abgegeben werden können.
Die Durchführung der Prüfungen ist gewährleistet. Damit ist das Risiko, am Projektende zu erkennen, dass in die falsche Richtung gearbeitet wurde oder dass eine Komponente viel zu spät fertig wird, ganz erheblich reduziert.
Das 90 %-fertig-Syndrom ist ausgeschlossen. In Projekten ohne Meilensteine neigen die Entwickler dazu, den Entwicklungsstand als »zu 90 % fertig« zu charakterisieren. Rückblickend erkennt man, dass diese Aussage über lange Zeit unverändert bleibt (Abb. 10–2). Der Grund ist, dass zu Beginn die leichteren Aufgaben gelöst werden. Am Ende bleiben die schwierigen übrig; durch die Restriktionen, die alle bereits realisierten Teile schaffen, wird die Schwierigkeit erhöht. Dieses seit langem bekannte Phänomen ist treffend durch den Satz beschrieben: Die ersten 90 % des Projekts brauchen 90 % der Zeit. Die letzten 10 % des Projekts brauchen die anderen 90 % der Zeit. Meilensteine können diese Neigung der Entwickler nicht beseitigen, aber auf die einzelnen Phasen begrenzen.
Abb. 10–2 Das 90 %-fertig-Syndrom
Die Vorteile sind so gewichtig, dass man eine Entwicklung ohne Phasenmodell als ausgesprochen riskant einstufen muss. Die Festlegung auf ein Phasenmodell klärt allerdings noch nicht viel; es schafft nur einen weiten Rahmen, innerhalb dessen noch sehr viele Festlegungen zu treffen sind. Ausgeschlossen sind damit nur die optimistischen Ansätze nach dem Beckenbauer-Prinzip (»Schaun mer mal«).
In einem Software-Projekt werden je nach Einteilung bis zu acht Phasen durchlaufen, von der Anforderungsanalyse bis zum Betrieb. Da die den Phasen zugeordneten Tätigkeiten aufeinander aufbauen, liegt es nahe zu verlangen, dass sie strikt sequenziell, eine nach der anderen, durchgeführt werden. Praktisch sprechen drei Gründe gegen diesen »strengen« Ansatz:
1. Oft stehen notwendige Informationen nicht zur richtigen Zeit zur Verfügung (z. B. werden Anforderungen spät im Projekt zugefügt oder geändert).
2. Vor einem Meilenstein sind die meisten Beteiligten bereits mit ihren Arbeiten fertig und müssen warten, bis alle anderen ebenfalls den Meilenstein erreicht haben, bevor sie weiterarbeiten können.
3. In vielen Fällen ist es vorteilhaft, möglichst rasch Teilergebnisse zur Verfügung zu stellen.
Darum wird das Phasenmodell – viele sprechen ungenau vom Wasserfallmodell – »aufgeweicht«. Dies kann in unterschiedlicher Weise geschehen:
a) Wenn sich das geplante System aufspalten lässt in unbedingt notwendige und nicht unbedingt notwendige Teile, dann kann inkrementell entwickelt werden (siehe Abschnitt 9.5.4).
b) Teile, die keine oder nur geringe Abhängigkeiten aufweisen, können asynchron entwickelt werden, also je nach verfügbarem Personal gleichzeitig oder in beliebiger Reihenfolge.
c) Dokumente werden bereits verwendet, obwohl sie noch nicht als vollständig einzustufen sind. Dies wird als Überlappung bezeichnet.
d) Die Arbeiten werden ohne Rücksicht auf logische Abhängigkeiten nach Verfügbarkeit der Bearbeiter in beliebiger Reihenfolge ausgeführt.
Natürlich ist Vorgehen d inakzeptabel, weil es jegliche Qualitätssicherung konterkariert. (Tatsächlich wird diese Strategie offiziell nirgends angewendet, aber praktisch ist sie nicht selten zu beobachten.)
Das Vorgehen a ist sehr sinnvoll, weil es zu kürzeren Entwicklungszyklen führt und die Möglichkeit bietet, die Erfahrungen der Klienten in den späteren Inkrementen zu berücksichtigen. Allerdings setzt das inkrementelle Vorgehen eine präzisere Planung voraus, denn die Schnittstellen zu den später entwickelten Teilen sollten bereits beim Kernsystem stabil sein.
Das Vorgehen b ist sinnvoll und wird in aller Regel angewendet. Natürlich gewinnt dadurch die Integration an Bedeutung: Missverständnisse und Fehler der Komponentenentwicklung verursachen Integrationsprobleme. Da eine seriöse Bearbeitung dieser Probleme nur durch die Entwickler erfolgen kann, entstehen zeitraubende Nacharbeitszyklen. Alternativ werden Inkonsistenzen durch Bastelei (scheinbar) kompensiert.
Beim Vorgehen c ist weiter zu differenzieren: Die Überlappung muss durch definierte Änderungsprozesse abgepolstert sein, damit sichergestellt ist, dass späte Änderungen der bereits verwendeten Dokumente nicht ignoriert werden, sondern ins Endprodukt eingehen. Wird beispielsweise die Spezifikation verändert, während bereits auf Basis einer früheren Version implementiert wurde, so muss der Prozess sicherstellen, dass
• die Spezifikation erneut validiert wird,
• alle Entwickler über die Änderung informiert werden,
• Auswirkungen auf alle bereits fertiggestellten Teile geprüft werden.
Eine Überlappung ist nicht an allen Phasengrenzen möglich und zulässig: Während beispielsweise Spezifikation und Implementierung überlappen können (auch wenn das keineswegs unproblematisch ist), ist der Eintritt in die Prüfung völlig unsinnig, solange die Spezifikation nicht vollständig vorliegt. Einer Prüfung, die sich nicht auf die gültige Spezifikation abstützt, fehlt einfach die Basis. Es können aber Teile geprüft werden, deren Spezifikation bereits stabil ist.
Das V-Modell ist Teil des Entwicklungsstandards für IT-Systeme des Bundes. »V« hat anscheinend eine doppelte Bedeutung: Einerseits steht es für »Vorgehen«; tatsächlich ist aber durch das V-Modell weit mehr als das Vorgehen geregelt, es handelt sich um ein ausgewachsenes Prozessmodell. Zum anderen hatte in der ersten Fassung des V-Modells die V-förmige Darstellung des Entwicklungsganges zentrale Bedeutung; sie ist noch immer zu erkennen (siehe Abb. 10–7; zum »V« vgl. die Fußnote zur Badewannenkurve in Abschnitt 4.4, S. 63).
Das Interesse öffentlicher Auftraggeber an Prozess-Standards ist leicht zu verstehen: Die Ministerien, allen voran das Verteidigungsministerium, geben Entwicklungen in Auftrag. Dabei müssen sie einerseits die Kosten im Auge behalten, streng genommen also stets den billigsten Anbieter wählen, andererseits sicherstellen, dass sie Waren und Dienstleistungen in angemessener Qualität erhalten. Schließlich müssen sie die Entscheidung für einen Anbieter nach objektiven Kriterien fällen, die notfalls auch vor einem Verwaltungsgericht Bestand haben. Darum suchen sie nach klaren Vorgaben und Kriterien für ihre Zulieferer. In den USA ist aus den gleichen Gründen das CMM entstanden (siehe Kap. 11).
Das V-Modell wurde im Auftrag des Bundesministeriums für Verteidigung entwickelt und ist dort seit 1992 verbindlich vorgeschrieben (Bröhl, Dröschel, 1995). Im Sommer 1996 wurde es auch für den Einsatz im zivilen Verwaltungsbereich der Bundesbehörden empfohlen. Damit sind auch die Lieferanten in der Regel an das V-Modell gebunden. Da es öffentlich zugänglich ist, haben auch andere Unternehmen das V-Modell erprobt und eingesetzt. Die damit gemachten Erfahrungen wurden systematisch gesammelt. Auf dieser Basis wurde es überarbeitet und unter der Bezeichnung V-Modell 97 publiziert (V-Modell, 1997). Zu den Verbesserungen dieser Version zählten die Unterstützung der inkrementellen Entwicklung, die koordinierte Entwicklung von Hard- und Software und die objektorientierte Entwicklung. Dröschel, Heuser und Midderhoff (1998) haben die wesentlichen neuen Elemente des V-Modells 97 beschrieben. 2004 wurde als Ergebnis einer weiteren Revision das V-Modell XT vorgestellt. XT steht hier für »extreme Tailoring«. Das drückt zum einen die Flexibilität beim Tailoring (Abschnitt 10.1.1) aus, die im neuen Modell angestrebt wurde; Rausch und Niebur (2005) nennen als erstes von vier Zielen »Verbesserung der Unterstützung von Anpassbarkeit, Anwendbarkeit, Skalierbarkeit und Änder- und Erweiterbarkeit des V-Modells«. Zum anderen war es wohl das Bestreben der gewiss nicht extremistischen Urheber, am modischen Trend zum »X« teilzuhaben. Das V-Modell XT ist durch ein sehr reiches Informationsangebot im Web gut zugänglich (V-Modell XT, o.J.).
Da es beim V-Modell auch um die Absicherung eines System- oder Software-Bestellers geht, sind darin die Beziehungen zwischen Auftraggeber (AG) und Auftragnehmer (AN) besonders wichtig.
Die folgenden Merkmale charakterisieren das V-Modell:
Das V-Modell ist in allen seinen Versionen als Weiterentwicklung des Standard-Phasenmodells ein aktivitätsorientiertes Modell. Ein logisch verknüpftes Netz von Aktivitäten und Produkten bildet den Kern des Modells.
Das V-Modell XT teilt ein Projekt in Projektabschnitte, also in Phasen, ein. Am Ende jedes Projektabschnitts steht ein Meilenstein, der Entscheidungspunkt genannt wird.
Das V-Modell kann für verschiedene Projektarten genutzt werden. Während sich das V-Modell in der Fassung von 1992 darauf beschränkte, die Software-Entwicklung zu beschreiben, schließt es seit der Version 97 auch die Hardware-Entwicklung mit ein. Das V-Modell XT geht sogar noch einen Schritt weiter; es kann nicht nur für Entwicklungsprojekte genutzt werden, sondern auch für »Metaprojekte«, also für Projekte, die ein Vorgehensmodell in eine Organisation einführen oder pflegen.
Das V-Modell deckt nicht nur die technische Systementwicklung ab. Die wesentliche Neuerung, die das V-Modell vom Wasserfallmodell unterscheidet, ist die Integration projektbegleitender Tätigkeiten, insbesondere der Qualitätssicherung, der Konfigurationsverwaltung und des Projektmanagements.
Das V-Modell XT unterstützt neben der inkrementellen und komponentenbasierten auch die prototypische Entwicklung. Das traditionelle WasserfallModell wird als Sonderfall der inkrementellen Entwicklung betrachtet.
Das V-Modell lässt sich – besonders in seiner neuesten Fassung – in weitem Rahmen anpassen und erweitern.
Das V-Modell XT trennt zwischen Auftraggeber- und Auftragnehmerprojekten. Es ist aber auch möglich (und natürlich sinnvoll), beide Rollen in einem Projekt zusammenzubringen.
Die Terminologie des V-Modells XT ist gewöhnungsbedürftig; das beginnt schon mit der »Empfehlung« zur Anwendung. (Zitat: »... wird nunmehr die Anwendung des weiterentwickelten Entwicklungsstandards – V-Modell XT – in der vom IMKA1 verabschiedeten Fassung für die Planung und Durchführung von IT-Verfahren in der Bundesverwaltung empfohlen.« An anderer Stelle wird deutlich, dass es sich um eine bindende Vorschrift handelt.)
Viele bereits breit akzeptierte Begriffe wurden im V-Modell XT durch neue ersetzt (so wird der Begriff »Phase« nicht verwendet, stattdessen wird der Begriff »Projektabschnitt« eingeführt), andere Begriffe werden mit veränderter Semantik benutzt. So bedeutet zum Beispiel der Begriff »Projekttyp« nicht das, was man naiv dahinter vermutet.
Das V-Modell XT soll für unterschiedliche Projektkonstellationen nutzbar sein. Dazu definiert es vier Projekttypen:
PT1
Ein Systementwicklungsprojekt (AG) ist ein Entwicklungsprojekt, wie es sich aus der Sicht des Auftraggebers darstellt. Im Rahmen eines solchen Projekts erstellt der Auftraggeber eine Ausschreibung und wählt den Auftragnehmer aus den Angeboten aus. Ist das System fertig, nimmt es der Auftraggeber ab.
PT2
Ein Systementwicklungsprojekt (AN) ist ein Entwicklungsprojekt aus der Perspektive des Auftragnehmers. Nachdem auf der Basis einer Ausschreibung ein Angebot erstellt wurde und ein Auftrag erteilt ist, entwickelt der Auftragnehmer das System gemäß festgelegten Projektdurchführungsstrategien und übergibt es an den Auftraggeber.
PT3
Ein Systementwicklungsprojekt (AG/AN) liegt dann vor, wenn keine separaten Projekte auf der Auftraggeber- und Auftragnehmerseite notwendig sind. Dies kann beispielsweise der Fall sein, wenn Auftraggeber und Auftragnehmer aus derselben Organisation kommen.
PT4
Der Projekttyp Einführung und Pflege eines organisationsspezifischen Vorgehensmodells regelt, wie in einer Organisation ein Vorgehensmodell eingeführt oder ein vorhandenes Vorgehensmodell verbessert werden soll.
Der Gegenstand von Projekten der Typen PT1 bis PT3 kann ein Hardware-System, ein Software-System, ein eingebettetes System, ein komplexes System, das Hardware-, Software- und eingebettete Anteile hat, oder eine Systemintegration sein. Für jeden Projekttyp bietet das V-Modell XT angepasste Varianten an. So gibt es beispielsweise für den Projekttyp PT3 zwei Varianten, eine für die Neu- bzw. Weiterentwicklung (»AG-AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration) und eine für ein Wartungsprojekt (»AG-AN-Projekt mit Wartung und Pflege«). Die Einordnung eines Projekts in diese Klassifikation bildet die Grundlage für das projektspezifische Tailoring des V-Modells XT (Abschnitt 10.3.6).
Produkte werden in Aktivitäten erstellt oder bearbeitet; eine Aktivität kann in Arbeitsschritte gegliedert sein. Aktivitäten, die nicht weiter aufgeteilt sind, und Arbeitsschritte werden typischerweise en bloc durchgeführt.
Als Produkte werden die Ergebnisse und Zwischenergebnisse eines Projekts bezeichnet. Produkte können ebenfalls gegliedert sein, das V-Modell XT spricht dann von einem Thema. Inhaltlich zusammengehörende Produkte und die Aktivitäten, die sie erstellen, werden gruppiert und als Disziplin bezeichnet. Das V-Modell-XT definiert 13 Disziplinen und gruppiert diese in die Bereiche Entwicklung, Projekt und Organisation.
Betrachten wir beispielsweise die Disziplin »Konfigurations- und Änderungsmanagement« aus dem Bereich Projekt. Abbildung 10–3 zeigt die entsprechenden Produkte und Aktivitäten in der Notation des V-Modells XT. Die (leider ungerichteten) Kanten zwischen den Aktivitäten und den Produkten bedeuten: In jeder Aktivität entsteht ein Produkt.
Abb. 10–3 Produkte und Aktivitäten der Disziplin »Konfigurations- und Änderungsmanagement«
Produkte können voneinander abhängen. So hängt das Produkt »Änderungsentscheidung« unter anderem von den Produkten »Problemmeldung/Änderungsantrag« und »Problem-/Änderungsbewertung« ab.
Rollen beschreiben zusammengehörende Aufgaben und Verantwortlichkeiten sowie die dazu notwendigen Fähigkeiten. Jedem Produkt ist genau eine dafür verantwortliche Rolle zugeordnet. Zusätzlich können Produkten weitere Rollen zugeordnet sein, die am Produkt mitwirken. So ist beispielsweise die Rolle »Change Control Board« verantwortlich für das Produkt »Änderungsentscheidung«; die Rollen »KM-Verantwortlicher« und »QS-Verantwortlicher« wirken mit. Insgesamt sind im V-Modell XT mehr als 30 verschiedene Rollen definiert.
Vorgehensbausteine sind die zentralen Einheiten des V-Modells XT. Ein Vorgehensbaustein fasst Disziplinen oder Teile davon zusammen, die inhaltlich zusammengehören und für eine Aufgabe, z. B. für das Änderungsmanagement, relevant sind. Das V-Modell XT definiert für alle Projekte vier obligatorische Vorgehensbausteine (der sogenannte V-Modell Kern):
2. Qualitätssicherung
3. Problem- und Änderungsmanagement
4. Konfigurationsmanagement
Je nach Ausprägung spezieller Projektmerkmale kommen im Tailoring (Abschnitt 10.3.6) weitere Vorgehensbausteine hinzu. Vorgehensbausteine bauen aufeinander auf; diese Abhängigkeiten sind im Tailoring zu berücksichtigen.
Als Beispiel betrachten wir den Vorgehensbaustein »Problem- und Änderungsmanagement«. Abbildung 10–4 zeigt die Produkte, Tätigkeiten und Rollen der Disziplin »Konfigurations- und Änderungsmanagement«, die das V-Modell XT dazu vorsieht.
Abb. 10–4 Vorgehensbaustein »Problem- und Änderungsmanagement«
Wie man sieht, sind nicht alle Produkte und Aktivitäten dieser Disziplin diesem Vorgehensbaustein zugeordnet (z. B. die Produktbibliothek). Diese und andere sind Teil des Vorgehensbausteins »Konfigurationsmanagement«. Das V-Modell XT gibt nicht vor, wie der konkrete Prozess des Änderungsmanagements aussehen soll. Dafür ist die Rolle »Änderungsverantwortlicher« zuständig. Diese Rolle ist zudem verantwortlich für zwei Produkte, die »Problem-/Änderungsbewertung« und die »Änderungsstatusliste«. Bindende Entscheidungen über Änderungen trifft das Change Control Board. Das mit einem »E« gekennzeichnete Produkt »Problemmeldung/Änderungsantrag« ist ein externes Produkt; es wird nicht im Projekt erstellt, sondern kommt von außen.
Das V-Modell XT führt den Begriff Entscheidungspunkt ein. Entscheidungspunkte entsprechen etwa dem Konzept des Meilensteins (Abschnitt 10.2.1). Sie teilen das Projekt in Projektabschnitte (Phasen) ein. Ein Entscheidungspunkt ist ein Zeitpunkt im Projekt, an dem entschieden wird, ob der nächste Projektabschnitt begonnen werden kann. Dazu definiert jeder Entscheidungspunkt die Produkte, die am Entscheidungspunkt erstellt sein müssen und deren Bewertung die Grundlage der Entscheidung ist. Das V-Modell XT definiert 21 Entscheidungspunkte.
Eine Projektdurchführungsstrategie ordnet eine Menge von zusammengehörenden Entscheidungspunkten und gibt deren zeitliche Reihenfolge vor. Sie schafft den Rahmen, um ein Projekt geordnet und nachvollziehbar durchzuführen. Die gewählte Projektdurchführungsstrategie liefert die Grundlage für die Projektplanung. Der Projekttyp (inklusive der gewählten Variante) legt die Projektdurchführungsstrategie fest. Abbildung 10–5 zeigt am Beispiel des Projekttyps »AG-AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration« die zeitliche Anordnung der dafür definierten Entscheidungspunkte, dargestellt durch die beschrifteten Knoten.
Abb. 10–5 Entscheidungspunkte und Ablauf der Strategie für die Projekttypvariante: AG-AN-Projekt mit Entwicklung, Weiterentwicklung oder Migration
Wie zu erkennen ist, werden Entwicklungsprojekte immer in Iterationen durchgeführt. Für jede Iteration muss entschieden werden, welche Entwicklungsstrategie angewendet werden soll. Eine Entwicklungsstrategie ordnet ebenfalls eine Menge von Entscheidungspunkten, die erreicht werden müssen.
Das V-Modell XT unterstützt die folgenden drei Entwicklungsstrategien:
1. Inkrementelle Entwicklung
2. Komponentenbasierte Entwicklung
3. Prototypische Entwicklung
Wir betrachten diese im Abschnitt 10.3.5 genauer.
Abbildung 10–6 zeigt die beschriebenen zentralen Elemente des V-Modells XT und deren Zusammenhänge in der Notation der UML-Klassendiagramme.
Abb. 10–6 Struktur des V-Modells XT (vereinfacht)
Die Struktur des V-Modells XT kann folgendermaßen (vereinfacht) dargestellt werden:
Für jeden Projekttyp bzw. für jede Projekttypvariante sind Vorgehensbausteine und Projektdurchführungsstrategien festgelegt. Die vier Kern-Vorgehensbausteine sind obligatorisch, andere sind optional.
Eine Projektdurchführungsstrategie gibt Entscheidungspunkte vor, die erreicht werden müssen. An jedem Entscheidungspunkt müssen definierte Produkte fertiggestellt sein.
Ein Vorgehensbaustein fasst alle Rollen, Produkte und Aktivitäten (die Disziplinen) zusammen, die notwendig sind, um eine zentrale Projektaufgabe zu lösen. Vorgehensbausteine bauen aufeinander auf.
Produkte und Aktivitäten sind in Disziplinen gruppiert und können gegliedert sein. Jedes Produkt wird durch genau eine Aktivität fertiggestellt. Produkte hängen voneinander ab.
Rollen sind für Produkte verantwortlich und wirken an der Erstellung von Produkten mit.
Das V-Modell XT unterstützt drei Strategien, um ein System zu entwickeln (inkrementell, komponentenbasiert, prototypisch). Die zentralen Entscheidungspunkte dieser Strategien sind in Abbildung 10–7 in der typischen V-Anordnung dargestellt.
Abb. 10–7 Zentrale Entscheidungspunkte der Systementwicklung
Die Sequenz zwischen den Entscheidungspunkten und damit die Reihenfolge, in der diese erreicht werden müssen, variiert zwischen den unterschiedlichen Strategien (Abb. 10–8).
Bei der inkrementellen Entwicklung erkennen wir den typischen Zyklus: In jeder Iteration wird ein Inkrement entwickelt, ausgeliefert und abgenommen.
Die komponentenbasierte Entwicklung wird ebenfalls in Iterationen durchgeführt, die je ein Ergebnis abliefern. Zusätzlich können jedoch interne Iterationen durchlaufen werden. Diese Strategie sieht vor, dass auf Basis der Spezifikation und der vorhandenen Komponenten gleichzeitig top-down und bottom-up entworfen wird, um die Komponenten in die Architektur einzubinden.
Abb. 10–8 Ablauf der inkrementellen und der komponentenbasierten Entwicklung (vereinfacht)
In Abschnitt 9.4 hatten wir Prototyping als eine wichtige Vorgehensweise eingeführt, um die Anforderungen zu klären und damit eine lange und teure Entwicklung zu vermeiden, die ein unbrauchbares System liefert.
Das V-Modell XT sieht dafür die Entwicklungsstrategie »prototypische Entwicklung« vor. Dabei wird das V praktisch aufgebrochen und zerfleddert: Die Sequenz der zentralen Entscheidungspunkte ist hier (1) Anforderungen festgelegt, (2) Systemelemente realisiert, (3) Feinentwurf abgeschlossen, (4) System integriert, (5) System entworfen, (6) System spezifiziert, (7) Lieferung durchgeführt, (8) Abnahme erfolgt (Abb. 10–9).
Abb. 10–9 Ablauf der prototypischen Entwicklung (vereinfacht)
Prototypen sollten immer dann entwickelt werden, wenn Risiken und Unklarheiten dadurch beseitigt werden können. Das V-Modell XT erlaubt aber (wie das folgende Zitat zeigt), dass die gesamte Systementwicklung auf Prototypen aufgebaut wird. Das erscheint uns zweifelhaft, ja, fahrlässig, da Prototypen nicht die Qualitätsanforderungen erfüllen (sollen), die an das Zielsystem gestellt werden.
Die prototypische Entwicklungsstrategie basiert auf der Erkenntnis, dass es oft nicht möglich ist, die Anforderungen an ein System vorab zu definieren. Außerdem stellt sie sicher, dass nichts spezifiziert wird, was sich als nicht realisierbar herausstellt. Somit wird diese Strategie insbesondere verwendet, wenn Realisierungsrisiken im Projekt vorhanden sind. Änderungen an den Anforderungen werden über das Problem- und Änderungsmanagement verwaltet. Typisch für diese Entwicklungsstrategie ist darüber hinaus die Präsenz des Auftraggebers auf der Auftragnehmerseite während der Entwicklung. Dadurch kann der Auftraggeber Änderungswünsche sehr direkt übermitteln. Der Auftragnehmer entwirft, realisiert und liefert das System dann ähnlich wie bei der Entwicklungsstrategie inkrementelle Entwicklung in einzelnen Stufen. Diese Stufen werden jede für sich vom Auftraggeber abgenommen. Für den Auftraggeber hat diese Vorgehensweise den Vorteil, dass er bereits frühzeitig in den Besitz eines lauffähigen Systems gelangt, das die wichtigsten Grundfunktionalitäten realisiert. Ferner ermöglicht sie eine frühzeitige Rückmeldung durch den Auftraggeber, die die Entwicklungsrisiken des Auftragnehmers minimiert.
Das liest sich überraschend naiv. Die Aussagen schlachten nicht nur ein paar heilige Kühe des Software Engineerings (allen voran die Spezifikation als wichtigstes Dokument), sondern gehen auch von einer Bilderbuchwelt aus, in der der Auftraggeber (beim V-Modell meist die öffentliche Hand!) im Projekt präsent ist und sowohl die fachliche als auch die juristische Kompetenz hat, um die Resultate kontinuierlich abzunehmen. Hier wird anscheinend der Versuch unternommen, eine Artistengruppe als militärischen Verband zu organisieren.
Insgesamt ist nicht nachvollziehbar, warum es sinnvoll sein soll, die zahlreichen Optionen der Entwickler gerade auf die drei Modelle inkrementell, komponentenbasiert und prototypisch zu reduzieren.
Ging man beim V-Modell 97 von der Gesamtmenge der Aktivitäten aus, die durch Streichungen eingeschränkt wurde, so beginnt man im V-Modell XT umgekehrt. Die Anpassung des V-Modells XT für ein konkretes Projekt geschieht dadurch, dass auf Basis des gewählten Projekttyps und der gewählten Projekttypvariante die Vorgehensbausteine bestimmt werden, die minimal erforderlich sind. Weitere Vorgehensbausteine können hinzukommen, indem die Projektmerkmale bewertet werden. Dazu zählt neben dem Projektgegenstand (z. B. Hard- oder Software-System) beispielsweise der Einsatz von Fertigprodukten oder das Vorhandensein einer Bedienoberfläche. Einzelne Aktivitäten oder Produkte werden beim Tailoring nicht betrachtet, da sie immer Bestandteil eines Vorgehensbausteins sind.
Die folgende Tabelle 10–1 zeigt die Zuordnung von Vorgehensbausteinen zu den Projekttypen (X = verpflichtend, O = optional). Die obligatorischen Vorgehensbausteine, die jedes Projekt haben muss, sind nicht aufgeführt.
Für das V-Modell XT gibt es den sogenannten Projektassistenten, ein Werkzeug, das das Tailoring unterstützt. Der Projektassistent erhält als Eingaben den Projekttyp und die Werte für die Projektmerkmale, und bestimmt damit die Vorgehensbausteine. Mit dem Projektassistenten können nun die Projektdurchführungsstrategie (also die Reihenfolge der Entscheidungspunkte) geplant und die projektspezifische V-Modell-Dokumentation sowie die Vorlagen (Templates) für die zu erstellenden Produkte erzeugt werden.
Durch das projektspezifische Tailoring werden die Vorgehensbausteine festgelegt und die Projektdurchführungsstrategie, die alle Entscheidungspunkte und deren Reihenfolge definiert.
PT1 |
PT2 |
PT3 |
PT4 |
|
Lieferung und Abnahme (AG) |
X |
O |
X |
|
Vertragsschluss (AG) |
X |
O |
O |
|
Lieferung und Abnahme (AN) |
|
X |
X |
|
Vertragsschluss (AN) |
|
X |
|
|
Kaufmännisches Projektmanagement |
O |
O |
O |
O |
Messung und Analyse |
O |
O |
O |
O |
Anforderungsfestlegung |
X |
|
X |
|
Evaluierung von Fertigprodukten |
O |
O |
O |
|
Systemerstellung |
|
X |
X |
|
Hardware-Entwicklung |
|
O |
O |
|
Software-Entwicklung |
|
O |
O |
|
Logistikkonzeption |
|
|
O |
|
Benutzbarkeit und Ergonomie |
|
O |
O |
|
Systemsicherheit |
O |
O |
O |
|
Weiterentwicklung und Migration von Altsystemen |
|
O |
O |
|
Einführung und Pflege eines organisationsspez. Vorgehensmodells |
|
|
|
X |
Multi-Projektmanagement |
O |
|
|
|
Tab. 10–1 Zuordnung von Vorgehensbausteinen zu Projekttypen
Weil jeder Entscheidungspunkt die Produkte definiert, die fertiggestellt sein müssen, bevor der nächste Projektabschnitt beginnen kann, können nun die Tätigkeiten geplant werden, um die Produkte für die Entscheidungspunkte zu erstellen. Dabei sind natürlich die im V-Modell XT festgelegten Produktabhängigkeiten zu berücksichtigen. Die Entscheidungspunkte dienen als zentrale Bezugspunkte für die Projektfortschrittskontrolle. An jedem Entscheidungspunkt wird entschieden, ob das Projekt fortgesetzt werden kann (gegebenenfalls, nachdem Nacharbeiten durchgeführt wurden) oder abgebrochen werden muss. Die getroffene Entscheidung wird in einer sogenannten Projektfortschrittsentscheidung dokumentiert.
Mit dem Projektassistenten kann auf Basis der gewählten Projektdurchführungsstrategien eine erste Planung erstellt werden, die die Termine aller Entscheidungspunkte festlegt. Das Werkzeug erzeugt mit dieser Information einen Vorschlag für die Planung der Aktivitäten, die auf Grund der Vorgehensbausteine und Entscheidungspunkte notwendig sind. Diese Information kann dann in ein Projektmanagement-Werkzeug übernommen und dort angepasst werden.
Für die Anwendung des V-Modells XT liegen im Gegensatz zur Vorgängerversion V-Modell 97 bislang erst wenige dokumentierte Erfahrungen vor. Folgende Vorteile sehen wir in diesem Prozessmodell:
Dadurch, dass das Modell im Kern vier Vorgehensbausteine definiert, die Bestandteil jedes Projekts sind, erhalten diese im Bewusstsein des Managements und der Entwickler denselben Stellenwert wie sogenannte konstruktive Tätigkeiten (also Spezifizieren oder Codieren).
Das Modell ist öffentlich zugänglich und kann ohne Lizenzkosten benutzt werden.
Das Modell ist generisch und bietet Unterstützung, um es unternehmens- und projektspezifisch anzupassen. Das V-Modell XT ist im Sinne eines Baukastens immer ein sinnvoller Ausgangspunkt, wenn ein unternehmensspezifisches Prozessmodell erstellt werden soll. Es senkt das Risiko, dass Wichtiges vergessen wird.
Als problematisch sehen wir die folgenden Aspekte:
Mit dem V-Modell wird angestrebt, die Tätigkeiten, Arbeitsergebnisse und Abläufe vollständig festzulegen. Daraus ergibt sich ein großer Umfang, erkennbar an der enormen Menge von Produkten, Aktivitäten und Rollen, die das Modell definiert. Damit scheint es für kleinere und mittlere Projekte nicht ohne weiteres geeignet zu sein. Notwendige Anpassungen werden zwar durch das Modell unterstützt, die Erfahrung zeigt aber, dass der Anpassungsprozess viel Zeit und Aufwand erfordert. Die (nachvollziehbare) Tendenz, lieber zu viel als zu wenig zu fordern, hat zur Folge, dass auch nach dem Tailoring noch ein sehr umfangreiches Gerüst übrig bleibt.
Wird das V-Modell ohne erhebliche Anpassungen verwendet (das kann nur bei sehr großen Projekten sinnvoll sein), dann ist es auf Grund seiner Größe schwerfällig in der Anwendung. Die Menge der zu erstellenden Produkte (Dokumente) ist auch nach einem Tailoring für ein kleines Entwicklungsprojekt erheblich; die Wirtschaftlichkeit vieler Dokumente muss bezweifelt werden.
Die Beschreibungen und die in den Projektdurchführungsstrategien modellierten Abläufe der Entwicklungsstrategien sind zum Teil mehr als diskutabel (z. B. die prototypische Systementwicklung).
Nach unserem Eindruck ist die neue Version des V-Modells noch nicht ausgereift. Es ist daher abzuwarten, ob das V-Modell XT nicht nur bei großen, sondern auch bei mittleren und kleinen Projekten anwendbar ist (oder durch Weiterentwicklung anwendbar wird).
Die objektorientierte Programmierung verbreitete sich ab 1980 mit der Sprache SMALLTALK. Nur wenige Jahre später standen weitere Programmiersprachen zur Verfügung, die nicht wie SMALLTALK genuin objektorientiert sind, sondern durch Erweiterung älterer Sprachen um die Konzepte der Objektorientierung (siehe Abschnitt 17.4) geschaffen wurden. Insbesondere C++ spielte wegen der Kompatibilität mit der bereits weit verbreiteten Sprache C eine wichtige Rolle.
Die objektorientierte Programmierung wurde gegen Ende der Achtzigerjahre rasch populär, denn sie hatte neben dem Reiz des Neuen offensichtliche Vorteile: schnelle Entwicklung komplexer Systeme, vor allem ansprechender Bedienoberflächen, leichte (feingranulare) Wiederverwendung des Codes. Bald zeigten sich aber auch neue Probleme, am schnellsten bei den SMALLTALK-Projekten: Für die neuen Konzepte taugten die alten, auf rein imperative Sprachen zugeschnittenen Methoden für Analyse und Entwurf, Qualitätssicherung und Test nicht. Auch die konventionellen Prozessmodelle erwiesen sich als wenig geeignet für die objektorientierte Software-Entwicklung.
Ivar Jacobson entwickelte und publizierte zwischen 1987 und 1992 einen Ansatz, der zunächst Objectory (Object Factory for Software Development) genannt wurde. Hierbei handelte es sich um eine auf die Objektorientierung abgestimmte Entwurfsmethode. Jacobson erkannte aber, dass auch neue Prozesskomponenten benötigt wurden. So entstand der Objectory-Prozess. Als neues Element führte Jacobson den sogenannten Anwendungsfall (Use Case) ein und machte ihn zur Grundlage des Objectory-Prozesses. In Jacobson et al. (1992) werden die Konzepte und die Grundelemente des Objectory-Prozesses detailliert beschrieben.
1995 schlossen sich die Firmen Objectory AB von Ivar Jacobson und die Rational Software Corporation zusammen. Die Konzepte des Objectory-Prozesses in der Version 3.8 und die bei Rational entwickelten Ansätze zur Software-Entwicklung, die maßgeblich durch G. Booch, J. Rumbaugh und P. Kruchten geprägt wurden, verschmolzen. Sie wurden zuerst als Rational Objectory Process, ab 1998 als Rational Unified Process (RUP) bezeichnet.
1999 wurde der »Unified Software Development Process« (kurz: Unified Process) veröffentlicht (Jacobson, Booch, Rumbaugh, 1999), der von den Spezifika des RUP abstrahiert. Der RUP ist eine konkrete Ausprägung des Unified Process. Nachfolgend stellen wir die zentralen Konzepte und Elemente des Unified Process vor, anschließend betrachten wir den RUP.
Der Unified Process (UP) soll die Vorteile von Phasenmodellen und nichtlinearen Prozessmodellen vereinen: Phasen erleichtern die Planung und das Management von Entwicklungsprojekten, Iterationen und inkrementelles Entwickeln helfen, Risiken frühzeitig zu erkennen und zu beseitigen. Der Unified Process kann durch die folgenden Merkmale charakterisiert werden:
Der UP ist ein Phasenmodell
Er gibt vier Phasen vor, an deren Ende jeweils ein Meilenstein passiert werden muss. In jeder einzelnen Phase werden alle definierten Arbeitsabläufe durchgeführt, jedoch in unterschiedlicher Intensität. Der Durchlauf durch die vier vorgegebenen Phasen wird als Zyklus bezeichnet. Das Ergebnis eines Zyklus ist immer ein Release, das entweder intern oder an den Kunden ausgeliefert wird.
Der UP ist iterativ, ein Release entsteht inkrementell
Während Phasen die Managementsicht eines Projektes bilden, läuft die technische Realisierung in Iterationen ab. Jede Phase kann mehrere Iterationen enthalten. In jeder Iteration werden alle im Prozess definierten Arbeitsabläufe durchgeführt und die zu erstellenden Arbeitsergebnisse inkrementell weiterentwickelt. Das Ergebnis einer Iteration ist immer eine ausführbare Systemkonfiguration. Die Schwerpunkte der Iterationen sind unterschiedlich. In den Iterationen der frühen Phasen entstehen oft Prototypen. Der Test (hier im Sinne von Prüfung) verteilt sich auf die Iterationen aller Phasen, da in jeder Iteration geprüft werden muss (siehe dazu auch Abb. 10–11).
Die Produktentwicklung kann inkrementell erfolgen
Soll ein Produkt in Ausbaustufen entwickelt werden, dann werden mehrere Zyklen durchlaufen, in denen das Produkt inkrementell entwickelt wird. Am Ende des letzten Zyklus ist das Produkt fertig.
Der UP basiert auf der Verwendung von Anwendungsfällen (Use Cases)
Die Identifikation und Modellierung von Anwendungsfällen ist ein zentraler Bestandteil des Ansatzes. Anwendungsfälle dienen dazu, die funktionalen Anforderungen zu beschreiben. Die dabei erstellten Modelle bilden die Grundlage für viele andere Tätigkeiten (z. B. Entwerfen der Architektur, Auswahl von Testfällen, Planung von Ausbaustufen) und deren Ergebnisse.
Der UP ist architekturzentriert
Die Architektur bildet neben Anwendungsfällen die Basis für die Entwicklung. Die Architektur wird frühzeitig, parallel zu den Anwendungsfällen, entworfen und stetig weiterentwickelt.
Der UP benutzt nicht, wie sonst üblich, den Begriff »Rolle«, um zusammengehörende Aufgaben, Verantwortlichkeiten und Fähigkeiten zu bezeichnen, sondern führt dazu den Begriff »Worker« ein. Dies hat zwei Gründe: Zum einen ist der Begriff »Rolle« im Kontext von UML definiert, hier wollte man keine Verwirrung stiften, zum anderen nehmen »Worker« in den vorgesehenen Arbeitsabläufen unterschiedliche Rollen ein. Wir nutzen in diesem Abschnitt jedoch weiterhin den Begriff »Rolle«.
Der UP versteht unter einer Aktivität eine zusammenhängende Tätigkeit, die von einer Rolle in einem Arbeitsablauf ausgeführt wird. Eine Aktivität liefert ein definiertes Ergebnis (eine Menge von Artefakten, die erstellt oder modifiziert werden) und hat eine Menge von Artefakten als Eingabe. Die Rolle »System Analyst« führt beispielsweise die Aktivität »Find Actors and Use Cases« durch.
Mit dem Begriff »Artefakt« bezeichnet der UP jede explizit formulierte Information; dabei wird zwischen Dokumenten und Modellen (z. B. einem Use-Case-Modell) unterschieden. Artefakte werden im Rahmen von Aktivitäten durch Rollen erstellt, benutzt oder modifiziert. So nutzt die Rolle »System Analyst« in der Tätigkeit »Find Actors and Use Cases« z. B. das Artefakt »Business Model« und produziert oder erweitert die Artefakte »Use Case Model« und »Glossary«. Arbeitsergebnisse unterliegen der Konfigurations- und Änderungsverwaltung.
Der UP beschreibt lediglich die zentralen Rollen, Aktivitäten und Artefakte. Diese können (und müssen) für ein konkretes Prozessmodell angepasst und erweitert werden.
Als Phasenmodell definiert der UP die folgenden vier Phasen:
Inception
Das Ziel dieser Phase ist, die Produktidee und die Anforderungen an das zukünftige System so weit zu verstehen, dass auf der Basis von wirtschaftlichen Betrachtungen ein Entwicklungsprojekt gestartet werden kann. Dazu werden die zentralen Anwendungsfälle identifiziert und modelliert, die Risikosituation des Projekts wird bewertet, erste Fassungen der Architektur und des Projektplans werden erstellt. Wenn notwendig, werden erste Prototypen gebaut, um risikoreiche Aspekte zu untersuchen.
Elaboration
In dieser Phase werden alle noch fehlenden Anforderungen identifiziert. Ferner werden die grundlegenden Architekturentscheidungen getroffen und in der Systemarchitektur formuliert. Der Bau eines ersten Prototyps, der den Architekturkern und dessen Funktionalitäten zeigt, findet in dieser Phase statt. Aus Managementsicht gilt es, die größten Risiken zu identifizieren, zu bewerten und geeignete Gegenmaßnahmen zu planen sowie die Planung für die folgenden Phasen zu erstellen.
Construction
In dieser Phase wird das System auf der Basis der vorhandenen Systemarchitektur implementiert, integriert und getestet. Noch unvollständige Dokumente, wie die Benutzerdokumentation, werden fertiggestellt. Am Ende dieser Phase steht ein einsetzbares System in der Qualität einer Beta-Version zur Verfügung.
Transition
Das bereits einsetzbare System wird in dieser Phase so lange verbessert, bis sein Zustand stabil ist. Dabei spielen die Erfahrungen und die Rückmeldungen der Anwender eine zentrale Rolle. Das übergeordnete Ziel dieser Phase ist, das System mit allen dazugehörenden Dokumenten so weit zu vervollständigen, dass es Produktqualität erreicht, ausgeliefert und ohne Einschränkung eingesetzt werden kann. Diese Phase endet, wenn der Kunde mit dem gelieferten Ergebnis zufrieden ist. Das Projekt wird abgeschlossen und die Ergebnisse werden archiviert. Gegebenenfalls muss entschieden werden, ob ein weiterer Zyklus, d. h. eine weitere Ausbaustufe, geplant und realisiert werden soll.
Ein Arbeitsablauf (Workflow) fasst zusammengehörende Aktivitäten, die ausführenden Rollen sowie die benötigten und produzierten Artefakte zusammen. Der UP definiert fünf Kern-Arbeitsabläufe (Core Workflows): »Requirements«, »Analysis«, »Design«, »Implementation« und »Test«. Diese werden in allen Projektphasen ausgeführt. Abbildung 10–10 zeigt in der Notation des UP die Rollen und Aktivitäten des Workflows »Requirements«.
Wie bereits erwähnt, ist der UP ein iterativer Prozess. Jede Phase kann in mehrere Iterationen aufgeteilt werden. In einer Iteration werden die für die Phase relevanten Artefakte inkrementell weiterentwickelt. Jede Iteration wird durch einen (internen) Meilenstein abgeschlossen. Da alle Kern-Arbeitsabläufe in jeder Phase durchgeführt werden, sind sie immer auch Teil jeder Iteration. Der UP nennt diese dann »Iteration Workflows«. Abbildung 10–11 zeigt die Zusammenhänge zwischen Phasen, Arbeitsabläufen und Iterationen.
Abb. 10–10 Der Workflow »Requirements« (Jacobson, Booch, Rumbaugh, 1999, S. 143)
Abb. 10–11 Phasen, Iterationen und Arbeitsabläufe (Jacobson, Booch, Rumbaugh, 1999)
In jeder Phase werden die Arbeitsabläufe in unterschiedlicher Intensität durchgeführt. Während in den ersten Phasen die Tätigkeiten zur Anforderungsermittlung und zum Systementwurf dominieren, überwiegen in den späteren Phasen Codier-und Testaktivitäten.
Der Rational Unified Process (RUP) prägt den generischen Unified Process zu einem konkreten Prozessmodell aus. Dabei bleiben natürlich die Grundideen und Konzepte des UP erhalten. Die zentralen Elemente des UP – also Rollen, Aktivitäten und Artefakte – werden jedoch erweitert und konkretisiert. Der RUP wird von der Firma IBM/Rational vermarktet; seine Anwendung erfordert eine Lizenz. Er wurde bereits in mehreren Entwicklungsstadien publiziert und wird kontinuierlich weiterentwickelt. Der RUP ist gut dokumentiert; mit der Lizenz erhält man eine vollständige HTML-basierte Dokumentation. Aber auch die öffentlich zugängliche Literatur zum RUP ist umfangreich, eine gute Einführung gibt beispielsweise Kruchten (2003).
Leider verändert der RUP die Terminologie des UP an einigen Stellen, so wird der Begriff »Workflow« durch »Discipline« ersetzt. Als Workflow bezeichnet RUP die Anordnung und den Ablauf der Aktivitäten einer Disziplin. Wir benutzen weiterhin den Begriff »Arbeitsablauf«; ein Arbeitsablauf wird durch einen Workflow beschrieben. Neben neuen Rollen, Aktivitäten und Artefakten modifiziert und erweitert der RUP die fünf Kern-Arbeitsabläufe des UP. Insgesamt gibt es die in der folgenden Tabelle aufgeführten neun Arbeitsabläufe.
Arbeitsablauf |
Zweck des Arbeitsablaufs |
Business Modelling |
die Strukturen und die Abläufe in der Auftraggeber-Organisation verstehen, eine gemeinsame Sprache etablieren |
Requirements |
die Anforderungen an das zu entwickelnde System erheben und bearbeiten |
Analysis and Design |
aus den Anforderungen ein Entwurfsmodell und die Systemarchitektur gewinnen |
Implementation |
die Teile der Architektur codieren und integrieren |
Test |
Prüfungen verschiedener Arten durchführen, prüfen, ob das entwickelte System die Anforderungen erfüllt |
Deployment |
das System zusammenstellen, geordnet an den Auftraggeber übergeben und dort in Betrieb nehmen |
Configuration and Change Management |
die erstellten Arbeitsergebnisse systematisch verwalten und Änderungen daran geordnet durchführen |
Project Management |
ein Projekt und seine Iterationen planen und kontrollieren (einschließlich Risikomanagement) |
Environment |
das Entwicklungsprojekt unterstützen (z. B. durch die Auswahl von Entwicklungswerkzeugen, die Administration von Rechnern oder das Erstellen von Backups) |
Tab. 10–2 Arbeitsabläufe (Disciplines) des RUP
Jeder Arbeitsablauf wird auf der oberen Ebene durch einen Workflow in Form eines UML-Aktivitätsdiagramms beschrieben. Damit wird versucht, die Reihenfolge und die Abhängigkeiten der einzelnen Aktivitäten eines Workflows zweidimensional zu visualisieren. Jeder Workflow hat einen Ein- und einen Austrittspunkt. Neben Aktivitätssymbolen kann ein solches Diagramm auch Entscheidungsaktivitäten enthalten, die mit Bedingungen versehen sind. An diesen Punkten verzweigt sich der Arbeitsablauf. Außerdem kann durch sogenannte Synchronisationsbalken Parallelität modelliert werden. Wenn die auf einen Synchronisationsbalken führenden Aktivitäten abgeschlossen sind, können alle Aktivitäten, die vom Synchronisationsbalken ausgehen, parallel ausgeführt werden. Abbildung 10–12 zeigt den Workflow des Arbeitsablaufs »Requirements«. Man erkennt, dass der Detaillierungsgrad im Vergleich zum generischen Ablauf im UP (Abb. 10–10 auf S. 206) gestiegen ist.
Die Aktivitätssymbole fassen in der Regel eine Gruppe von Aktivitäten zusammen. Auf der darunterliegenden Ebene, die »Workflow Detail« genannt wird, werden die Gruppen ebenfalls in einer grafischen Notation aufgelöst. Abbildung 10–13 zeigt exemplarisch die im Workflow »Requirements« (Abb. 10–12) definierte Aktivität »Analyze the Problem«.
Abb. 10–12 Workflow des Arbeitsablaufs »Requirements«, © IBM Corp
Abb. 10–13 Darstellung der Aktivitätsgruppe »Analyze the Problem«, © IBM Corp.
Auf dieser Ebene werden die Beziehungen zwischen Aktivitäten, Rollen und den wichtigsten Artefakten sichtbar. So führt die Rolle »System Analyst« die vier gezeigten Aktivitäten durch. Die am Rand platzierten Rollen sind an den gezeigten Aktivitäten beteiligt, indem sie notwendige Informationen beisteuern. Die Aktivitäten produzieren oder verändern Artefakte; diese sind ebenfalls dargestellt.
Der RUP beschreibt jede atomare Aktivität detailliert durch einen Text, der die auszuführenden Schritte angibt. Für die Artefakte wird die Gliederung vorgegeben, der Inhalt wird umrissen.
Damit der Rational Unified Process eingesetzt werden kann, muss die Entwicklungsorganisation folgende Voraussetzungen erfüllen:
Ausgezeichnete Konfigurations- und Änderungsverwaltung
Die iterative und inkrementelle Entwicklung führt dazu, dass sich die Arbeitsergebnisse in jeder Iteration verändern. Damit dies nicht ins Chaos führt, muss die Konfigurations- und Änderungsverwaltung ausgereift und mit geeigneten Werkzeugen ausgerüstet sein.
Gute Projektmanagement-Fertigkeiten
Auch wenn die definierten Phasen auf der oberen Ebene die Struktur eines Projekts klar vorgeben, bleibt bei diesem Prozessmodell doch die Schwierigkeit bestehen, die Anzahl und die Dauer der einzelnen Iterationen zu planen, die in den Phasen durchgeführt werden müssen. Dies ist nicht einfach und erfordert entsprechende Erfahrung.
Kenntnis objektorientierter Konzepte und Notationen
Der RUP ist für die objektorientierte Systementwicklung konzipiert. Daher muss das dazu notwendige Know-how bereits vorhanden sein, es entsteht nicht durch Einführung des Prozesses. Insbesondere muss das für diesen Prozess essenzielle Konzept der Anwendungsfälle verstanden sein und beherrscht werden.
Das Prozessmodell hat unseres Erachtens seine Stärken in den folgenden Bereichen:
Gute Darstellung des Prozesses
Da der RUP in einer HTML-Fassung zur Verfügung steht, können seine Anwender einfach durch den Prozess navigieren und Informationen finden. Die Prozessbeschreibung ist jedem Mitarbeiter am Arbeitsplatz direkt zugänglich und erhöht damit die Bereitschaft, darin zu lesen und in Zweifelsfällen in der Prozessbeschreibung nachzuschauen.
Hoher Detaillierungsgrad
Der Prozess ist sehr detailliert beschrieben. So werden zu den Aktivitäten nicht nur die einzelnen Arbeitsschritte aufgelistet, sondern auch Arbeitsanleitungen mitgeliefert. Die Arbeitsergebnisse werden inhaltlich beschrieben, und zu jedem Arbeitsergebnis gibt es ein Musterdokument, das die Struktur des zu erstellenden Dokuments aufweist. Dieser feine Detaillierungsgrad ist ein Vorteil, weil die Prozessbeschreibung meist ausreichend Information enthält, damit der Ablauf und die definierten Tätigkeiten zu verstehen sind.
Daneben sehen wir die folgenden Problembereiche:
Schwierige Anpassung
Der RUP muss in der Regel an die speziellen Gegebenheiten einer Entwicklungsorganisation angepasst werden. Dies betrifft mindestens die Tätigkeiten der notwendigen Rollen und die geforderten Arbeitsergebnisse. Da der Prozess sehr detailliert beschrieben ist und dadurch die Prozesselemente sehr stark miteinander vernetzt sind, ist die Anpassung nicht einfach und nur mit erheblichem Aufwand möglich. Der RUP selbst gibt nur wenig Hilfestellung für das projektspezifische Tailoring.
Instabile Prozessdefinition
Der RUP ist ein Produkt und wird entsprechend vermarktet und weiterentwickelt. Dies führt unweigerlich dazu, dass immer wieder geänderte Fassungen des Prozesses entstehen. Damit wird die Definition des eigenen organisationsspezifischen Entwicklungsprozesses abhängig von der Weiterentwicklung dieses Produkts. Werden in kurzer Folge neue Fassungen des Prozesses erstellt, dann muss der eigene Prozess laufend angepasst werden. Dies ist schwierig, teuer und nicht immer gewünscht. Die Alternative ist, sich von der Weiterentwicklung des RUP abzukoppeln. Das kann aber andere Nachteile haben (Kompatibilität mit Werkzeugen, erschwerter Austausch mit Leuten, die an die neue Fassung gewöhnt sind).
Der Prozess täuscht vor, dass die Software-Entwicklung algorithmisch durchgeführt werden kann
Die mit Hilfe von Aktivitätsdiagrammen modellierten Arbeitsabläufe können den Eindruck erwecken, dass eine Durchführung der Tätigkeiten in der vorgeschriebenen Reihenfolge garantiert zu einem guten Ergebnis führt. Diese Sicherheit besteht tatsächlich nicht. Es genügt nicht, nur formal nach der Prozessvorgabe zu arbeiten. Viel wichtiger ist, dass die in den Aktivitäten erzielten Arbeitsergebnisse brauchbar und von ausreichender Qualität sind.
Offenkundig werden durch den Rational Unified Process viele Aspekte der Entwicklung sinnvoll identifiziert und geregelt. Besonders wichtig ist, dass man die Vorteile der phasenorientierten Entwicklung erhält, ohne auf die iterative Entwicklung verzichten zu müssen. Die Erfahrungen mit diesem Ansatz sind (2006) noch begrenzt. Es ist jedoch klar, dass seine Anpassung an die spezifischen Gegebenheiten einer Entwicklungsorganisation schwierig ist und dass die Voraussetzungen, die eine Entwicklungsorganisation erfüllen muss, erheblich sind.
In der traditionellen industriellen Fertigung entstehen unvermeidlich auch fehlerhafte Produkte. Darum werden die Resultate geprüft. Wo ein defektes Produkt entdeckt wird, kann man es wegwerfen oder, soweit dies möglich und rentabel ist, reparieren. In jedem Falle versucht man sicherzustellen, dass nur ein kleiner Teil der Produkte betroffen ist. Beispielsweise sind einige der produzierten Glühlampen Ausschuss, und bei Autos sind nicht selten Nachbesserungen nötig.
Bei der Fertigung hochintegrierter Schaltungen (Prozessor- und Speicher-Chips) ließ sich dieser Ansatz nicht ohne weiteres übernehmen: Nur ein kleiner Bruchteil der Chips war in Ordnung; die übrigen konnten aber nicht repariert werden, denn die Strukturen lassen sich selbst im Mikroskop nicht mehr betrachten, geschweige denn reparieren. Die Ausbeute war also extrem gering.
Ein beträchtlicher Teil der Defekte entsteht durch Verunreinigungen. Jedes noch so kleine Staubkorn, das sich auf den Wafer setzt, bedeutet einen Defekt. Darum wurden die Räume, in denen Chips produziert werden, mit großem Aufwand vor Staub geschützt. Durch Filter, Schleusentüren usw. wurde die Wahrscheinlichkeit einer Verunreinigung drastisch gesenkt und die Ausbeute entsprechend erhöht. Im Reinstraum (Cleanroom) wird also dafür gesorgt, dass nicht Fehler gemacht und dann beseitigt, sondern von Beginn an vermieden werden. Der erforderliche Aufwand ist groß, aber die Einsparung ist größer.
Software lässt sich – anders als die Chips – reparieren. Aber der Aufwand dafür ist sehr hoch, und der Erfolg ist höchst ungewiss, zumal bei einer Reparatur mit beträchtlicher Wahrscheinlichkeit neue Fehler entstehen. Forscher in der IBM Federal Systems Division hatten darum die Idee, das Konzept des Cleanrooms zu übernehmen, also Software so zu entwickeln, dass sie gleich richtig ist. Dieses Vorgehen führte zum Cleanroom Development Process (CDP).
Der CDP ist in der Literatur gut dokumentiert (beispielsweise in Mills, Dyer, Linger, 1987; Baker, Basili, Selby, 1987; Dyer, 1992; Linger, Trammell, 1996; Linger, 1993; Poore, Trammell, 1996; Prowell et al., 1999). Trotzdem ist nicht klar, welche Elemente genau den CDP definieren. Viele Nachahmer verwenden die Bezeichnung, obwohl sie kaum mehr als eine normale Qualitätssicherung zu bieten haben. Die Urheber selbst bieten drei verschiedene Stufen der Cleanroom-Implementierung an (Hausler, Linger, Trammell, 1994), nämlich die Basisimplementierung (introductory), die vollständige (full) und die fortgeschrittene Implementierung (advanced). Am klarsten sind die Aussagen zur mittleren Stufe: Daran orientieren sich die folgenden Aussagen. Auf der ersten Stufe sind vor allem die Grundideen verwirklicht, nicht die speziellen Techniken. Die dritte Stufe erlaubt und fordert die Adaption strenger, formaler Verfahren, die über die zweite Stufe hinausgehen.
Nach den Erfahrungen und Untersuchungen in den Siebzigerjahren können folgende Feststellungen als gesichert gelten:
Projekte begrenzter Größe und Laufzeit haben weit bessere Chancen als langlaufende Großprojekte.
Eine gründliche Analyse und Spezifikation (siehe Kap. 16) ist die wichtigste technische Voraussetzung für den Erfolg.
Inspektionen sind geeignet, Fehler frühzeitig, womöglich vor der Implementierung, zu entdecken. Das gilt sowohl für die Reviews (siehe Abschnitt 13.5) als auch – mit den entsprechenden Einschränkungen – für das gründliche Lesen durch den Verfasser selbst (vgl. Abschnitt 6.5). Aber auch beim Code ist die Inspektion wirksamer als der Test.
Hinter syntaktischen Fehlern verbergen sich oft semantische Probleme. Ein Bezeichner, zu dem es keine Deklaration gibt, kann durch einen Tippfehler entstanden sein, aber ebenso durch das Versäumnis, eine weitere Variable einzuführen. Die Unterscheidung zwischen syntaktischen und semantischen Fehlern ist oft spekulativ.
Nachbesserungen sind, wie oben festgestellt wurde, mit hohen Kosten und beträchtlichen Risiken behaftet.
Testdaten, die einzeln »von Hand geschnitzt« werden, lassen sich wegen des großen Aufwands nur in geringer Zahl bereitstellen, sie liefern keine Aussagen über die Zuverlässigkeit des Systems.
Aus diesen Feststellungen wurden die Regeln des CDP abgeleitet:
Ein großes Projekt wird durch ein inkrementelles Vorgehen (Abschnitt 9.5.4) aufgeteilt, also durch eine Serie kleiner Projekte ersetzt. Jedes dieser kleinen Projekte kann mit einigen (etwa fünf bis acht) Entwicklern in einigen Monaten durchgeführt und abgeschlossen werden.
Der Aufwand für Analyse und Spezifikation ist weit höher als üblich. Der CDP schreibt keine spezielle Methode oder Notation vor, je nach Problem verwendet man die besten Verfahren und Darstellungen, die in Frage kommen, also auch formale Techniken. Die Spezifikationen werden sehr gründlich inspiziert.
Den Entwicklern wird keine Möglichkeit gegeben, den Code zu compilieren und zu testen. Von ihnen wird erwartet, dass sie Programme liefern, die nicht nur semantisch, sondern auch syntaktisch fehlerfrei sind.
Auf einen Test der einzelnen Komponenten wird ganz verzichtet. Stattdessen werden sie integriert und insgesamt getestet (siehe unten Der statistische Test).
Fehler werden nur in sehr geringem Umfang akzeptiert und nicht von den Testern, sondern von den Entwicklern behoben. Zeigen sich in einer Komponente zu viele Fehler, wird sie nicht geflickt, sondern verworfen, also neu implementiert.
Linger (1993) gibt für den Verzicht auf den Modultest eine interessante Begründung: Testet man die Komponenten einzeln und entdeckt dabei Abweichungen von der Spezifikation, so erhält man oft kein vollständiges Bild des Problems. Denn viele Fehler entstehen durch subtile Inkompatibilitäten zwischen den Modulen. Die Korrektur beseitigt dann nicht den Fehler, sondern nur seine Symptome. Auf diese Weise wird die spätere Entdeckung und Beseitigung des Fehlers im Systemtest weniger wahrscheinlich, der Fehler mogelt sich durch die Prüfungen und bleibt im System. Wird der Fehler dagegen erst im Systemtest angezeigt, sind seine Wirkungen offensichtlich, der Fehler kann »enttarnt« und behoben werden.
Linger nennt als Fehlerrate 3 bis 4 Fehler pro KLOC (bei Eintritt in den ersten Test überhaupt) gegenüber ca. 25/KLOC bei traditioneller Codierung. Oft wurde beobachtet, dass bereits die allererste Übersetzung des Codes keine Fehler meldete. Die Publikationen sprechen von außerordentlich erfolgreichen Projekten verschiedenster Arten (Software-Komponente für einen Hubschrauber, COBOL Structuring Facility) und drastisch gesenkten Kosten für spätere Korrekturen.
Eine Black-Box-Spezifikation beschreibt eine Software-Einheit (unabhängig von ihrer Größe) durch den Zusammenhang zwischen Ein- und Ausgaben. Da die Systeme zustandsbehaftet sind, genügt es nicht, nur die aktuelle Eingabe zu betrachten, es muss jeweils auch die Eingabe-Historie, die Sequenz der früheren Eingaben, berücksichtigt werden. Wir sind damit auf der Ebene der Abstrakten Datentypen, wie sie in reiner Form mit der algebraischen Spezifikation definiert werden. Im CDP wird aber keine strikt mathematische Formalisierung verlangt, man verwendet Tabellen und präzise (natürliche) Sprache. Beispielsweise kann man die Reaktion eines Editors auf einen Befehl »speichern« etwa wie folgt beschreiben:
Wenn keine Datei geöffnet ist, wird eine Fehlermeldung erzeugt.
Wenn eine Datei geöffnet ist, seit dem Öffnen aber keine Veränderung daran vorgenommen wurde, hat der Befehl keinen Effekt.
Wenn eine Datei geöffnet ist und verändert wurde, wird die Datei in der aktuellen Form abgespeichert.
Aus der Black-Box-Darstellung wird die State Box entwickelt: An die Stelle der Vorgeschichte tritt der Systemzustand. Im Beispiel oben bedeutet das: Der Editor ist in einem von drei Zuständen (plus dem Zustand, bevor er gestartet wird): Diese Zustände können als »keine Datei«, »unveränderte Datei« und »veränderte Datei« bezeichnet werden. Durch den Befehl »speichern« wird im Zustand »keine Datei« eine Fehlermeldung hervorgerufen, der Zustand bleibt gleich; im Zustand »unveränderte Datei« hat »speichern« gar keine Wirkung. Im Zustand »veränderte Datei« wird gespeichert, und der Zustand wird auf »unveränderte Datei« gesetzt.
Die Clear-Box-Darstellung schließlich liegt auf der Ebene des Programmcodes, sie implementiert die State Box durch Datenstrukturen und den Ablauf durch Ablaufstrukturen. Damit liegt ein Feinentwurf vor, die Implementierung des Systems ergibt sich durch Komposition der Clear Boxes.
Die Clear Box wird gegen die State Box verifiziert, die State Box gegen die Black Box. Da die Darstellungen nicht streng formal sind, handelt es sich um eine Inspektion. Jeder im Projekt muss zustimmen, dass die Umsetzung korrekt ist.
Im Zuge der Entwicklung können gleichzeitig Boxes in verschiedenen Stadien vorliegen; typischerweise verwendet eine State Box oder eine Clear Box Verfeinerungen, die noch im Zustand der Black Box sind.
Testen dient dazu, Fehler zu entdecken; das wird in Kapitel 19 ausführlich dargestellt. Natürlich gilt das grundsätzlich auch für den Test im CDP. Aber ein Test hat auch stets eine andere Seite: Wir schließen – in aller Regel ohne große Überlegung – aus dem im Test beobachteten Verhalten auf den Einsatz: Hat ein Programm im Test völlig zuverlässig funktioniert, dann rechnen wir auch mit einem problemlosen Einsatz.
Im CDP wird dieser zweite Aspekt in den Vordergrund gerückt. Der Test ist so angelegt, dass man nicht nur »aus dem Bauch«, sondern mit guten Gründen daraus Prognosen der Zuverlässigkeit ableiten kann. Überspitzt könnte man sagen: Da die Fehler durch die Entwicklung vermieden werden, brauchen sie im Test nicht gesucht zu werden. Vielmehr zeigt der Test, ob die geforderte Zuverlässigkeit erreicht ist. Linger (1993, S. 11) formuliert das so:
The role of a Cleanroom certification team is not to debug software, but rather to certify its quality through statistical testing techniques. The certification may show adequate quality, but if not, the software will be returned to the development team for rework.
Dazu sind zwei Voraussetzungen zu erfüllen:
Die statistische Aussage zur Zuverlässigkeit erfordert große Mengen von Testdaten, also nicht zehn oder hundert, sondern viele Tausend. So viele Testdaten kann man sich nicht einzeln ausdenken, sie müssen automatisch erzeugt werden. Darum werden Zufallsdaten verwendet.
Die Testdaten müssen für die im späteren Betrieb anfallenden Daten repräsentativ sein. Betrachten wir dazu die Verwendung eines Editors. Hier treten bestimmte Aktionen und Sequenzen der Bedienung (z. B. die Sequenz »speichern« und »schließen«) sehr oft auf, während andere, selten ausgeführte Aktionen oder unsinnige Sequenzen nur sehr selten auftreten (z. B. die mehrfache Wiederholung des Speicherns ohne weitere Aktionen). Ebenso sind bestimmte Zeichen und Zeichenfolgen sehr viel häufiger als andere. Kennt man solche Abweichungen von einer rein zufälligen Verteilung, dann kann man Benutzungsprofile entwickeln (in Form von Häufigkeiten oder Markov-Ketten) und die Zufallsdaten entsprechend realistisch auswählen. Whittaker und Thomason (1994) haben diese Art der Testdatengenerierung beschrieben.
Im CDP werden darum Zufallsdaten verwendet, die nach Maßgabe der Benutzungsprofile ausgewählt sind. Treten dabei dann und wann Fehler des Programms auf, so können die Abstände gemittelt werden (als MTBF, Mean Time Between Failure) und zur Prognose der Zuverlässigkeit dienen. Natürlich hängen die Abstände von der Intensität der Benutzung ab; versagt das System mit automatisch erzeugten Daten etwa einmal in drei Stunden, so kann man in der Praxis, wenn die Aktionen hundertmal langsamer erfolgen, mit einer MTBF von dreihundert Stunden rechnen.
Der statistische Test gehört zu den umstrittenen Ideen des Cleanroom-Ansatzes (vgl. Abschnitt 19.7). Linger behauptet, dass der statistische Test wesentlich effektiver ist als der Test mit Überdeckungsmaßen: Statistical usage testing is more than 20 times more effective at extending MTBF than is coverage testing. Beizer (1997) hat dagegen plausibel dargelegt, dass diese Aussagen sowohl der Theorie als auch der praktischen Vernunft widersprechen, und darauf hingewiesen, dass nie ein seriöser Vergleich mit soliden Testtechniken angestellt wurde. Außerdem besteht bei einem Test mit Zufallsdaten immer das Problem, dass man die Soll-Resultate (siehe Abschnitt 19.1.2) nicht oder nur vage kennt.
Der CDP besteht aus 14 Aktivitäten, die zu vier Teilprozessen zusammengefasst sind. Diese Teilprozesse und ihre Aktivitäten sind, wie in Abbildung 10–14 gezeigt, miteinander vernetzt.
Abb. 10–14 Cleanroom Development Process (nach Linger, Trammell,1996, S. 16)
Die vier Managementaktivitäten wirken sich auf alle anderen Teilprozesse und deren Aktivitäten aus. Das gilt insbesondere für die Leistungsverbesserung, die darauf abzielt, die eingesetzten Methoden, Techniken und Abläufe stetig zu verbessern. Auch der Entwurf der Architektur ist als dauernde Aktivität angelegt.
Die übrigen drei Teilprozesse (Spezifikation, Entwicklung und Zertifizierung) werden in bestimmter Reihenfolge durchlaufen: Auf die Spezifikation folgen parallel die Entwicklung und die Erstellung der Benutzungsprofile. Der statistische Test führt die beiden Abläufe wieder zusammen. Die Entwicklung schließt die Integration vorhandener Komponenten ein, die in der Regel nicht nach CDP entwickelt wurden. In diesem Fall müssen diese Komponenten zuerst so weit verbessert werden, dass sie den angestrebten Qualitätskriterien genügen.
Da inkrementell entwickelt wird, bildet der gesamte Ablauf einen Zyklus, der im Allgemeinen mehrfach durchlaufen wird. In den Zyklus eingebettet ist ein weiterer Zyklus für die Spezifikation, die mit dem Kunden abgestimmt, ergänzt und korrigiert wird, bis sie als vollständig und korrekt beurteilt wird.
Die einzelnen Aktivitäten sind beschrieben durch ihre Ziele, die Beteiligten, die Eintrittsbedingungen, die zu erledigenden Aufgaben, die Verifikationsmaßnahmen, die durchzuführenden Messungen und die Abschlusskriterien.
Cleanroom Development wurde in mehreren industriellen Projekten erfolgreich eingesetzt (Hausler, Linger, Trammell, 1994, S. 92; Linger, 1994). Die publizierten Ergebnisse, insbesondere die geringe Zahl der Fehler, die erst im Betrieb entdeckt wurden, sind beeindruckend. Viele der publizierten und nach dem Cleanroom-Ansatz durchgeführten Projekte haben eingebettete Systeme realisiert, deren Zuverlässigkeit besonders kritisch ist.
Die Vorteile lassen sich wie folgt zusammenfassen:
Durch den systematischen Einsatz rigider, auch mathematischer Modellierungs- und Verifikationstechniken und durch den Test mit Zufallsdaten, die dem Benutzungsprofil entsprechen, entstehen Systeme, die ungewöhnlich fehlerarm sind und deren Zuverlässigkeit im Einsatz prognostiziert werden kann.
Da die (Teil-)Ergebnisse einer statistischen Kontrolle unterliegen, ist jederzeit klar, ob der Entwicklungsprozess den Vorgaben entspricht. Damit ist die Prozessverbesserung ein Nebeneffekt des Prozesses.
Eigentliche Nachteile sehen wir nicht, wohl aber Voraussetzungen, die in der Praxis oft nicht erfüllbar sind:
Die Anforderungen an die Entwickler sind hoch. Sie müssen in der Lage und bereit sein, nach den strengen Prinzipien des Prozesses zu arbeiten. Insbesondere müssen sie mit den formalen Techniken vertraut sein und sich auf die ungewohnte Herausforderung einstellen, hochwertige Programme abzuliefern, ohne sie getestet zu haben.
Die Organisation muss bereits an das methodische Arbeiten und an die iterative Entwicklung gewöhnt sein. Da die Entwickler ohnehin mit vielen neuen Anforderungen umgehen müssen, können nicht zugleich auch noch neue Vorgehensweisen vermittelt werden.
Dem Cleanroom-Ansatz liegt – wenigstens für jede Iteration – eine streng sequenzielle Vorgehensweise zu Grunde. Was nicht spezifiziert ist, kann nicht entwickelt werden. Bei vielen eingebetteten Systemen ist diese Voraussetzung gegeben; die technischen Randbedingungen sind relativ stabil. Dagegen entsteht Software mit komplexer Bedienoberfläche und viel Interaktion in der Regel nicht auf der Basis einer stabilen Spezifikation, sondern explorativ, nach dem Trial-and-Error-Prinzip. Darum sind solche Projekte für den Cleanroom-Ansatz nicht geeignet; sie lassen sich dagegen erfolgreich nach dem in vieler Hinsicht komplementären Konzept der sogenannten agilen Prozesse entwickeln (siehe Abschnitt 10.6).
Ein echtes Problem, das den Cleanroom-Ansatz mit den agilen Prozessen verbindet, ist der Mangel an neutralen Bewertungen: Hier wie dort (und auf vielen anderen Baustellen des Software Engineerings) gibt es reichlich viele positive Darstellungen und Kommentare, aber kaum distanzierte, für alle Ergebnisse offene Untersuchungen. Darum bleibt es schwierig, ohne eigene Erfahrungen Aussagen über den wahren Wert der Konzepte zu machen.
Was der Kunde haben und der Hersteller liefern will, ist funktionierende Software. Das war schon so, bevor der Begriff »Software Engineering« entstand, und es ist auch heute noch so. Aber wir haben gelernt, dass – wie in jeder Disziplin – Umwege nötig sind, um das Ziel sicher und insgesamt zu vertretbaren Kosten zu erreichen. Wenn man sich im Auto anschnallt oder gelegentlich Wartungsarbeiten am Auto machen lässt, dient das nicht direkt dem schnellen Transport von A nach B; die meisten Menschen haben aber verstanden, dass das Anschnallen trotzdem sinnvoll ist und regelmäßige Ölwechsel billiger sind als der Verzicht darauf.
Entsprechend ist auch das »Drauflos-Programmieren« (Code and Fix, siehe Abschnitt 9.1.1) weder sicher noch rentabel. Planung, Spezifikation, Architekturentwurf, Qualitätssicherung und Projektverfolgung sind die Schlüsselwörter der systematischen Software-Bearbeitung.
Allerdings tun sich viele Menschen mit diesen Umwegen schwer. Darum wurden Prozesse definiert, die die Entwickler führen. Diese Prozesse können vom Entwickler als Gängelung erlebt werden, besonders dann, wenn sie bürokratisch formuliert sind und durchgesetzt werden. Ein Prozess, der sich selbst dient und nicht dem übergeordneten Ziel, mit minimalem Aufwand qualitativ ausreichende Software bereitzustellen, hat mehr mit Kafka als mit den traditionellen Ingenieurprinzipien zu tun.
Die Neigung, solche bürokratischen Prozesse zu installieren, scheint in den USA besonders ausgeprägt zu sein. Sie provozierte eine Gegenbewegung: Entwickler, die ihre Situation erlebten, als sei sie die Vorlage zu den Dilbert-Cartoons, beschlossen gegen Ende der Neunzigerjahre, den Ballast der »schweren Prozesse« (siehe Abschnitt 10.1.2) abzuwerfen und sich auf die ursprüngliche Zielsetzung zu konzentrieren. Diese Tendenz wurde unterstützt durch die rasch wachsende Bedeutung, die zwei neue Anwendungsgebiete der Informatik gewannen, das Internet und die mobile Kommunikation. Auf beiden Gebieten hat die Fähigkeit, rasch auf die Wünsche der Kunden oder des Marktes zu reagieren, ein deutlich größeres Gewicht als die Existenz einer Dokumentation, die eine lange Lebensdauer möglich macht. Und auch wenn ein Fehler in der Software eines Mobiltelefons für den Hersteller schmerzhaft sein mag, so sind die Risiken doch nicht mit denen eines fehlerhaften Airbags vergleichbar.
Es entstand eine Reihe von »Anti-Prozessen« (Extreme Programming, Adaptive Software Development, Crystal, Scrum), die unter der Sammelbezeichnung »agile Prozesse« bekannt wurden. Abrahamsson et al. (2002) haben die Ziele im Abstract griffig formuliert:
Agile – denoting »the quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion« – software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment.
2001 haben sich die Protagonisten der agilen Prozesse in Utah getroffen und ein Agile Manifesto verfasst (Abb. 10–15).
Abb. 10–15 The Agile Manifesto (2001)
Manifest: Wem fällt bei diesem Wort nicht das kommunistische Manifest von 1848 ein? Mancher kennt auch das GNU-Manifest, das Dadaistische Manifest oder das Bauhaus-Manifest. Im »object-oriented database manifesto« (Atkinson et al., 1989) wurde den traditionellen Datenbanken die objektorientierte Alternative gegenübergestellt.
Alle diese Manifeste sind Streitschriften, in denen eine Minderheit, die Helden eines kleinen Dorfes in Gallien, der feindlichen Übermacht mit moralischen oder ästhetischen Argumenten den Krieg erklärt: So auch das »Manifest für die agile Software-Entwicklung«.
Seine Verfasser haben sich auf die folgenden Prinzipien geeinigt:
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity – the art of maximizing the amount of work not done – is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Das Manifest drückt die Ablehnung bestimmter Positionen und die Präferenz für andere aus. Viel weiter reichen die Gemeinsamkeiten nicht. Wenn wenigstens klar wäre, was ein typischer nichtagiler Prozess ist, dann wären die agilen Ansätze durch seine Negation definiert. In Deutschland würde sich dafür das V-Modell anbieten, ein Prozessmodell, das die Eleganz und Wendigkeit eines Armee-Lastwagens hat. Aber die Fronten sind verwischt: Das V-Modell bietet die agile Entwicklung als eine von mehreren Möglichkeiten an (siehe Abschnitt 10.3.5).
Schon ein zutreffender Sammelbegriff fehlt: Wir verwenden durchgehend das Wort »Prozessmodell«, auch wenn in manchen Fällen eher von Arbeitsprinzipien oder Organisationsgrundsätzen zu sprechen wäre. Mit diesen Einschränkungen kann man sagen, dass alle agilen Prozesse
iterativ angelegt sind; die Zyklen sind meist einige Wochen lang, höchstens drei Monate,
die Arbeit in einer kleinen Gruppe verlangen, meist aus sechs bis acht Leuten, die gemeinsam in einem großen Raum arbeiten (in Crystal, siehe Abschnitt 10.6.5, gibt es auch Konzepte für größere Gruppen),
die Idee einer großen, reichlichen Dokumentation ablehnen, radikal oder mit Einschränkungen,
den Kunden sehr wichtig nehmen und seine Präsenz im Projekt empfehlen oder verlangen,
dogmatische Regelungen ablehnen (auch wenn das beim Extreme Programming, siehe Abschnitt 10.6.4, manchmal anders klingt).
Die Modelle lassen sich nicht überlappungsfrei nebeneinander legen; beispielsweise erlaubt Crystal (Abschnitt 10.6.5), nach den Regeln von Extreme Programming oder Scrum zu arbeiten.
Nachfolgend betrachten wir Extreme Programming und die in gewissem Sinne komplementäre Crystal-Familie etwas näher. Zu allen anderen agilen Prozessmodellen (und natürlich auch zu den hier behandelten) empfehlen wir die Übersicht von Abrahamsson et al. (2002).
Allgemein ist die Literaturlage unbefriedigend. Zwar gibt es im Web sehr viele Beiträge dazu, doch sind diese ganz überwiegend parteiisch. Eine neutrale Literatur ist – außer zu Teilaspekten, etwa zum Paar-Programmieren – kaum zu finden.
Von allen agilen Prozessen hat das Extreme Programming (XP) die mit Abstand größte Aufmerksamkeit erreicht. Dies liegt auch daran, dass Kent Beck, der Urheber, keine Scheu vor plakativen Aussagen hat, die gut ankommen.
XP ist gut dokumentiert, viele Quellen sind im Internet verfügbar (z. B. Wells, o.J.). Neben dem Buch von Kent Beck (1999) gibt das Buch von Wolf, Roock, Lippert (2005) einen guten Einstieg in XP und beschreibt Erfahrungen beim Einsatz von XP in Entwicklungsprojekten.
Die zentralen Elemente von XP sind die sogenannten XP-Werte (values), die XPPrinzipien (basic principles) und die XP-Konzepte (practices). Kent Beck hat diese zentralen Elemente in der zweiten Auflage seines Buches (Beck, Andres, 2004) von Grund auf überarbeitet und erweitert. Wir beziehen uns hier jedoch auf die erste Fassung, die auch Grundlage der meisten Arbeiten über die Anwendung und die Erfahrungen mit XP war.
XP stellt als agiles Prozessmodell die Menschen, d. h. alle Projektbeteiligten, und nicht Dokumente, Werkzeuge oder Prozesse in den Mittelpunkt. Dies spiegelt sich in den vier Werten, auf denen XP basiert:
Einfachheit
Es sollen möglichst einfache Lösungen erstellt und möglichst einfache Prozesse genutzt werden. Einfache Lösungen sind leichter herzustellen und schneller zu verstehen als komplexe.
Feedback
Das Projektteam soll so schnell und so oft wie möglich Feedback über die erzielten Ergebnisse erhalten. Rückmeldungen sind Teil der Qualitätssicherung; sie kommen von den Anwendern, aber auch von den Kollegen im Team.
Kommunikation
Hier steht die persönliche und direkte Kommunikation zwischen den Projektbeteiligten im Vordergrund. Dies verlangt, dass das Projektteam nicht räumlich getrennt arbeitet und dass Kunde und Anwender in hohem Maße verfügbar sind. Dokumente als Mittel zur Kommunikation sind zweitrangig; sie ergänzen die direkte Kommunikation, wenn dies nötig ist.
Mut
XP betrachtet Mut als eine wichtige Voraussetzung, um die oben beschriebenen Werte im Projekt auch zu leben.
XP leitet aus diesen Werten Prinzipien ab. Diese sind, wie beispielsweise die Prinzipien »Ehrliches Messen« oder »Verantwortung übernehmen«, offensichtlich vernünftig.
Wir stellen nachfolgend die XP-Konzepte vor, da diese sich auf die konkrete Projektarbeit auswirken und helfen, die Werte und Prinzipien im Projekt umzusetzen. XP definiert 14 Konzepte, die in Management-, Team- und Programmierkonzepte gruppiert werden können (Wolf, Roock, Lippert, 2005). Abbildung 10–16 zeigt diese Gruppierungen von außen nach innen. Die Konzepte und die Regeln dazu erscheinen auf den ersten Blick einfach. XP ist (anders als Crystal, siehe Abschnitt 10.6.5) nicht von irgendwelchen Differenzierungen angekränkelt.
Abb. 10–16 XP-Konzepte (nach Wolf, Roock, Lippert, 2005)
Managementkonzepte
• Integrales Team
Ein XP-Projekt verlangt zwingend den Kunden im Projekt, weil nur dieser die fachlichen Anforderungen kennt und nach seinen Prioritäten ordnen kann. Der Kunde muss jederzeit für Fragen und Diskussionen zur Verfügung stehen (on-site customer).
• Planungsspiel (oder Planungssitzung)
XP ist ein iterativer und inkrementeller Prozess. Jedes Inkrement wird gemeinsam durch das Projektteam im sogenannten Planungsspiel festgelegt. Der Kunde gibt die zu realisierenden Anforderungen vor, die Entwickler schätzen die dafür benötigte Zeit sowie den Aufwand. Natürlich können hier die Vorstellungen beider Seiten weit auseinander liegen. Dann ist es Aufgabe der Entwickler, die Planungssitzung so lange zu moderieren, bis eine gemeinsame Basis für das nächste Inkrement gefunden ist.
• Kurze Release-Zyklen
Damit die Anwender möglichst schnell und oft Feedback geben können, darf die Zeit zwischen den Releases nicht zu groß sein (im Bereich weniger Wochen).
• Standup-Meeting
Die »Sitzungen« des (einzigen) Teams, das keine ausgeprägte Hierarchie aufweist, finden täglich im Stehen statt und sind kurz (ca. 15 min). Sie dienen dazu, die Aufgaben zu verteilen und sich über den Fortgang des Projekts, über Probleme usw. auszutauschen.
In längeren Abständen werden spezielle Sitzungen mit ausgewählten Personen durchgeführt, in denen das Projekt rückblickend bewertet wird. Ziel ist es, Fehler und Schwächen zu identifizieren, um daraus für kommende Projektabschnitte oder neue Projekte zu lernen.
Teamkonzepte
• Gemeinsame Verantwortung für den Code
Der Code gehört allen, und alle haben das Recht und die Pflicht, ihn weiterzuentwickeln und zu verbessern (Refactoring).
• Codierrichtlinien
Alle schreiben Code gemäß gemeinsam vereinbarten Richtlinien.
• Erträgliche Arbeitsbelastung
Überstunden gibt es höchstens ausnahmsweise, besser gar nicht. Damit soll vermieden werden, dass die Teilnehmer im Projekt verschlissen werden.
• Zentrale Metapher
Metaphern (vgl. Abschnitt 2.5) in der Software-Entwicklung helfen, den Anwendungsbereich und die Architektur zu strukturieren. Jedes XP-Projekt soll sich an einer Metapher orientieren, die vor allem dem fachlichen Entwurf zu Grunde liegt. Bekannte und erprobte Metaphern sind beispielsweise »Desktop« oder »Werkzeug-Automat-Material« (Züllighoven, 2005).
• Laufende Integration
Die Ergebnisse werden laufend in einer speziellen Umgebung (im Integrationsrechner) integriert. So werden Änderungen am System sofort allen Entwicklern zur Verfügung gestellt. Nach jeder Integration müssen alle für das Gesamtsystem vorhandenen Tests ohne Fehler ablaufen. Nur dann verbleibt der neu integrierte Code im Gesamtsystem.
Programmierkonzepte
• Testgetriebene Entwicklung
Testen geht vor Implementieren, d. h., jede Implementierung einer neuen Funktion beginnt mit der Implementierung der entsprechenden Tests (Unit-Tests), die automatisch ausgeführt werden. Akzeptanztests dienen dazu, implementierte fachliche Anforderungen abzunehmen.
• Strukturverbesserung (Refactoring)
Werden Schwächen im Code oder im Entwurf entdeckt, dann werden sie beseitigt, bevor neue Funktionen realisiert werden (zum Refactoring siehe Abschnitt 23.3).
• Einfacher Entwurf
Die gewählten Entwürfe sollen die zu realisierenden Anforderungen möglichst einfach umsetzen. Im Wechsel mit den Strukturverbesserungen wird die Architektur inkrementell erweitert.
Die Codierung wird grundsätzlich durch Programmierer im Doppelpack geleistet; einer codiert, der andere schaut zu, prüft und hinterfragt den erstellten Code. Diese Rollen wechseln ständig. Dadurch wird die Qualität des Codes erhöht, und das Wissen ist über mehrere Personen verteilt. Die Paare sind nicht stabil, sie wechseln ebenfalls.
Viele dieser Konzepte können nicht einzeln umgesetzt werden, da sie vielfache Bezüge untereinander haben; so bedingen sich beispielsweise die Konzepte »Planungsspiel« und »Integrales Team«. Trotzdem ist es möglich, die XP-Konzepte in sinnvoll zugeschnittenen Gruppen schrittweise einzuführen.
Die XP-Konzepte befreien die Entwickler von einigen Mühen und Lasten, die traditionell auf ihren Schultern liegen, vor allem von der Dokumentation, auch von einem mühsamen Prozess der Anforderungserhebung, von Review-Sitzungen, vom Ausfüllen der Stundenzettel und vom Kampf mit einer Planung, die am grünen Tisch gemacht wurde. Die Befreiung ist aber keineswegs total; tatsächlich ist XP weder chaotisch noch anarchisch, es erfordert im Gegenteil große Disziplin. Wer beispielsweise die gemeinsame Verantwortung für den gesamten Code so interpretiert, dass er nach Belieben darin herumflicken darf, wird sehr rasch zurückgepfiffen; aber das wird schon daran scheitern, dass natürlich auch das Refactoring in Zweiergruppen geschieht. (Zitat: Any pair of programmers can improve any code at any time.) Die Einfachheit der Konzepte ist teilweise vordergründig. Eine zentrale Metapher, das klingt plausibel und ist für die Kommunikation mit dem Kunden vorteilhaft. Beck spricht aber von einer Metapher, die nicht nur für den Kunden (zur Erklärung), sondern auch für die Entwickler (als Architekturvorgabe) verbindlich ist. Das kann im Allgemeinen nicht funktionieren und funktioniert auch nicht. Die Metapher taugt als Leitbild, nicht als Entwurf. Beck selbst hat nach viel Kritik die Bedeutung der Metapher in der zweiten Auflage seines Buches erheblich reduziert.
Wer aus Erfahrung skeptisch ist und Kent Beck fragt, wie er die Konzepte im Detail umsetzt, stellt überrascht fest, dass die Realität nicht ganz den klaren Regeln entspricht. Natürlich denkt er vor Beginn des eigentlichen XP-Projekts über die Konzeption nach, und zwar weder im Zweierteam noch in Anwesenheit des Kunden. Natürlich setzt man sich bei den Besprechungen (»ist bequemer«). Und natürlich ist keineswegs immer ein Kunde verfügbar, der anwesend ist, testen kann und Entscheidungsbefugnis hat. Ein XP-Projekt wird auch nicht abgebrochen, wenn sich eine ungerade Anzahl verfügbarer Mitarbeiter ergibt, die sich nicht mehr ohne Rest auf Entwickler-Paare verteilen lässt. Kurz: Der lautstarke Protest gegen die »schweren« Prozessmodelle ist ein wesentlicher Teil des Programms.
Alistaire Cockburn (der Wert auf die korrekte schottische Aussprache seines Namens wie »Coburn« legt) hat unter dem Fantasienamen Crystal eine Familie von Prozessmodellen vorgeschlagen. Welches dieser Modelle im Einzelfall anzuwenden ist, hängt von der Projektgröße (Zahl der Mitarbeiter, MA) und von den Risiken ab, die durch Software-Fehler entstehen. Die Projektgröße ist durch eine Farbe ausgedrückt: Clear (bis 8 MA), Yellow (bis 20 MA), Orange (bis 50 MA), Red (bis 100 MA), Maroon (bis 200 MA), Blue (bis 500 MA) und Violet darüber. Allerdings hat er die drei letzten Gruppen überhaupt nicht näher betrachtet. Da Cockburn für die Risikoeinschätzung vier Stufen vorsieht, entsteht eine Matrix von vier mal vier Modellen (Abb. 10–17).
Abb. 10–17 Die Crystal-Familie
Auch diese Matrix hat Cockburn nicht vollständig ausgefüllt: Die Ebene der höchsten Risiken hat er komplett ausgeblendet, und von den übrigen hat er sich vorwiegend mit den kleineren Projekten befasst (Clear bis Orange). Links unten (bei D6) fühlt er sich offenbar am sichersten; Crystal Clear hat er durch ein Buch dokumentiert (Cockburn, 2004).
Insgesamt handelt es sich eher um einen konzeptionellen Rahmen als um konkrete Prozessmodelle.
Crystal kümmert sich vor allem um den Managementaspekt des Projekts, besonders um die Kommunikation und den Prozess der Prozessverbesserung. Zu den Grundsätzen gehören die folgenden Punkte:
Das Produkt wird inkrementell, in regelmäßigen Schritten, entwickelt und ausgeliefert.
Meilensteine sind durch Entscheidungen und Lieferungen definiert, nicht durch Dokumente.
Der Benutzer ist direkt beteiligt.
Muster (Templates) werden in der Codierung und auch sonst verwendet.
Die Funktionalität wird durch automatisierte Regressionstests geprüft.
Jedes Release wird von mindestens zwei Benutzern geprüft.
Zu Beginn und in der Mitte jedes Auslieferungszyklus findet ein Workshop statt, um die Details des Produkts und der Entwicklungsverfahren festzulegen. Die lokalen Regeln (local matters), z. B. die Dokumentation des Projekts, sind nicht durch Crystal vorgegeben.
Einige Werkzeuge und Hilfsmittel sind erforderlich, beispielsweise eine Software zur Versionsverwaltung, auch eine elektronische Tafel (printing whiteboard), um die Ergebnisse der Besprechungen zu dokumentieren.
In Crystal Orange sind die Strukturen und Fristen dem größeren Projektvolumen angepasst (mehrere Teams, längere Zyklen).
In Crystal werden vier Personengruppen unterschieden: Sponsor, Senior-Entwickler, Entwickler, Benutzer. Diese Gruppen, insbesondere die Gruppe der Entwickler, sind weiter gegliedert.
In Crystal Orange gibt es darüber hinaus eine Reihe von Spezialisten, z. B. für den Entwurf der Bedienschnittstelle und der Datenbank, für die Architektur und für den Test, auch eine Person, die sich (unter anderem) um die Wiederverwendung kümmert. Jede der Gruppen enthält die wichtigsten Rollen, damit die Probleme lokal gelöst werden können.
In Crystal sind einige Aktivitäten vorgegeben:
Staging
Das Team wählt die Anforderungen aus, die im nächsten Inkrement realisiert werden sollen.
Revision and review
Die Inkremente werden iterativ entwickelt. Jede Iteration besteht aus den Schritten Konstruktion, Demonstration und Überprüfung der Ziele.
Monitoring
Fortschritt und Qualität (stability) der Arbeitsergebnisse werden überwacht. Wenn das Teilziel erreicht ist (»stable enough to review«), können die Entwickler bereits den nächsten Schritt beginnen.
Interviews and workshops
Sowohl die Technik als auch die Arbeitsweise und Organisation sind in Crystal immer wieder Gegenstand der Diskussion. Dazu sind verschiedene Maßnahmen im Prozess vorgesehen (Methodology Tuning, Reflection Workshops).
Crystal ist zwar auf vielen Webseiten präsent, aber Erfahrungen scheint es kaum zu geben. Abrahamsson et al. (2002) haben nur die beiden von Cockburn beschriebenen Projekte zitiert. Vergleicht man die beiden darin angewendeten Ansätze Crystal Clear und Crystal Orange mit den 16 (oder gar 28) Parzellen, die Cockburn skizziert hatte (Abb. 10–17 auf S. 226), dann wirkt das Vorhandene wie eine Vorübung zu dem, was noch kommen soll.
Viele Äußerungen und Kommentare im Web legen die Vermutung nahe, dass Cockburns Kunden und Fans mehr Interesse an seinen Ideen und Vorstellungen von der Kommunikation im Projekt als am konkreten Prozess haben; vielleicht ist es gerade die Ablehnung eines Prozesses, die Crystal kennzeichnet. Neben den beiden Zielen Sicherheit und Effizienz ist die »Bewohnbarkeit« (habitability) des Verfahrens wichtig, also die Verträglichkeit für die Beteiligten, vor allem für die Entwickler. Darum spielt die Anpassung des Vorgehens an die speziellen Bedingungen, unter denen das Projekt durchgeführt wird, eine wichtige Rolle. In diesem Punkt unterscheidet sich Crystal sehr erheblich von XP, das auf die Bedingungen keine Rücksicht nimmt.
Wir sehen zwei positive Beiträge durch Crystal:
Die Differenzierung der Prozesse in Abhängigkeit von Größe und Risiko des Projekts ist zweifellos sinnvoll und längst überfällig. Ein Software Engineering, das nach dem Prinzip »One size fits for all« gelehrt und angewendet wird, taugt nicht für die Praxis, denn viele Merkmale lassen sich nicht beliebig skalieren.
Die besondere Aufmerksamkeit für die Kommunikation, allgemeiner für das
Wohlbefinden der Beteiligten, und die Flexibilisierung des Prozesses zu Gunsten dieses Wohlbefindens sind unabhängig vom Prozessmodell in jedem Falle sinnvoll.
Scrum ist ein agiler Ansatz zum Management von Software-Entwicklungsprojekten. Er wurde von Jeff Sutherland, Ken Schwaber und Mike Beedle Mitte der Neunzigerjahre entwickelt und erstmals 1995 publiziert (Schwaber, 1995). Scrum basiert auf Ideen, die Takeuchi und Nonaka (1986) im Kontext der Lean Production entwickelt haben, um industrielle Produktionsverfahren den sich immer schneller ändernden Anforderungen anzupassen. Im Kern ihrer Ideen steht das sich selbst organisierende Team, bestehend aus verschiedenen Spezialisten, die nicht streng arbeitsteilig, sondern kooperativ die Entwicklung vorantreiben und auch den Erfolg oder Misserfolg kollektiv verantworten. Takeuchi und Nonaka vergleichen diesen Organisationsansatz mit dem Verhalten einer RugbyMannschaft, die nach jeder Unterbrechung ein Gedränge bildet (englisch: Scrum), das den Ball zu erobern versucht. Ist das gelungen, so folgt ein schneller Sprint mit dem Ball, der möglichst viel Raumgewinn bringen soll.
Scrum definiert einen rollenbasierten iterativen und inkrementellen Prozess zur Software-Entwicklung. Scrum beschränkt sich im Gegensatz zu XP auf das Management agil durchgeführter Projekte, es werden keine Techniken vorgeschlagen, die zu nutzen sind. Dementsprechend kann Scrum selbst schnell erlernt und auch schnell eingeführt werden. Scrum ist gut dokumentiert – wir stützen uns auf die Bücher von Schwaber und Beedle (2001) und Pichler (2008) – und wird erfolgreich in vielen Unternehmen eingesetzt.
Scrum definiert drei Rollen, die in jedem Scrum-Projekt wahrgenommen werden müssen:
Der Produktverantwortliche (Product Owner) vertritt die Interessengruppen außerhalb des Projektteams, insbesondere die des Auftraggebers. Er kennt die fachlichen und technischen Anforderungen an das zu entwickelnde System und sammelt und pflegt diese im Product Backlog. Der Produktverantwortliche plant und entscheidet, welche Anforderungen in der nächsten Iteration (dem sogenannten Sprint) realisiert werden. Dadurch hat er maßgeblichen Einfluss auf das Projektergebnis. Der Produktverantwortliche arbeitet eng mit dem Projektteam zusammen, um die Anforderungen zu klären. Er sollte, wenn möglich, (passiv) an den täglichen Projekttreffen (Daily Scrum) teilnehmen, damit er stets über Fortschritt und Probleme informiert ist. Der Produktverantwortliche muss in der Lage sein, am Ende jedes Sprints die Umsetzung der Anforderungen zu beurteilen.
Ein Scrum-Team muss so zusammengestellt sein, dass seine Mitglieder in der Lage sind, alle Entwicklungstätigkeiten autonom durchzuführen. Das Team entscheidet auf Basis der Priorisierung der Anforderungen durch den Produktverantwortlichen, wie viele Anforderungen im nächsten Sprint realisiert werden und welche Arbeitsschritte dafür benötigt werden. Ein Scrum-Team organisiert sich selbst; es gibt keinen Teamleiter, der die Aufgaben verteilt. Das Team entscheidet, welche Aufgaben durchzuführen sind und wer wann welche Aufgaben übernimmt. Dies ist insbesondere bei neuen Teams nicht leicht. Hilfe kann das Scrum-Team vom Scrum-Master bekommen (siehe unten). Zusätzlich stehen Dokumente zur Verfügung, die das Team bei der Planung und Fortschrittskontrolle des Projekts unterstützen. Weil die Mitglieder eines Scrum-Teams sehr intensiv kommunizieren und miteinander arbeiten, müssen ihre Arbeitsplätze nahe beieinander liegen (am besten im selben Raum).
Scrum führt mit dem Scrum-Master eine völlig neue Rolle für Entwicklungsprojekte ein. Die übergeordnete Aufgabe des Scrum-Masters besteht darin, dem Team und der Organisation zu helfen, Scrum-Projekte richtig durchzuführen. Er sorgt dafür, dass der Prozess und die Regeln eingehalten und die definierten Verantwortlichkeiten auch wahrgenommen werden. Der Scrum-Master unterstützt das Team und den Produktverantwortlichen und kümmert sich darum, dass Hindernisse beseitigt werden, die den erfolgreichen Einsatz von Scrum gefährden. Weiterhin stellt er sicher, dass das Team direkt mit dem Produktverantwortlichen zusammenarbeiten kann und dass es während eines Sprints nicht durch ungerechtfertigte Eingriffe gestört wird. Der Scrum-Master moderiert die Daily Scrums und sorgt dafür, dass die zentralen Scrum-Dokumente (wie das Product Backlog) aktuell sind. Neben diesen eher organisatorischen Aufgaben sollte ein kompetenter Scrum-Master auch in der Lage sein, die Arbeitstechniken und Vorgehensweisen zu bewerten und auch zu verbessern. Scrum-Master ist also die wichtigste Rolle im Scrum-Projekt. Ob die Einführung von Scrum gelingt, hängt vor allem vom Scrum-Master ab.
Scrum definiert als agiler Prozess nur wenige, dafür aber für den Erfolg wichtige Dokumente, die in jedem Scrum-Projekt zu erstellen und zu pflegen sind. Diese Dokumente unterstützen vor allem die Planung von Scrum-Projekten und dienen der Fortschrittskontrolle.
Das wichtigste Dokument eines Scrum-Projekts ist das Product Backlog. Es enthält alle Anforderungen, die im Projekt umgesetzt werden sollen. Zusätzlich werden im Product Backlog alle Aufgaben aufgeführt, die erledigt werden müssen. Der Produktverantwortliche erstellt und aktualisiert das Product Backlog. Ausgangsbasis für die erste Version des Product Backlogs ist das Produktkonzept oder die Sammlung der Anforderungen, die in einem Anforderungsworkshop (siehe Abschnitt 16.2.8) erhoben werden.
Die Einträge im Product Backlog sind priorisiert, den erforderlichen Aufwand hat das Team geschätzt. Als Schätzgröße werden in der Regel nicht Personentage, sondern Punkte (Story Points) verwendet. Diese werden bei der Planung eines Sprints in Personentage umgerechnet. Die Aufwandsbewertung der Anforderungen findet in Schätzklausuren statt, an denen das Team, der Produktverantwortliche und in der Regel auch der Scrum-Master teilnehmen.
Alle Anforderungen, die im nächsten Sprint umgesetzt werden sollen, werden aus dem Product Backlog in das Sprint Backlog übernommen. Dieses Dokument beschreibt somit die Ziele, die ein Sprint erreichen soll, und dient dem Team zur Organisation der Arbeit während eines Sprints. Die Einträge im Sprint Backlog sind möglichst präzise beschrieben und in Personenstunden oder Personentagen abgeschätzt. Welche Anforderungen in einem Sprint umgesetzt werden, wird in der Sprint-Planungssitzung festgelegt. Das Sprint Backlog wird täglich aktualisiert, d. h., es werden umgesetzte Anforderungen als erledigt markiert, die Aufwände dafür werden dokumentiert, und eventuelle Restaufwände und neue Aktivitäten und deren Aufwände werden eingetragen.
Um den Arbeitsfortschritt während eines Sprints zu dokumentieren, kennt Scrum den sogenannten Sprint-Burndown-Bericht. Dieser zeigt, typischerweise grafisch, über die Laufzeit des Sprints die Höhe der Aufwände, die im Sprint Backlog enthalten oder noch zu erbringen sind. Im Idealfall nehmen die Aufwände stetig und etwa linear ab. Natürlich können aber auch neue nicht vorhergesehene Tätigkeiten dazukommen, geplante Aufwände können sich als ungenügend erweisen. Durch den Sprint-Burndown-Bericht wird frühzeitig sichtbar, ob die im Sprint zur Implementierung vorgesehenen Anforderungen mit den geplanten Aufwänden realisiert werden können; andernfalls müssen Gegenmaßnahmen ergriffen werden. Beispielsweise kann der Produktverantwortliche Anforderungen aus dem Sprint Backlog streichen. Der Sprint-Burndown-Bericht wird täglich aktualisiert, meist ist der Scrum-Master dafür verantwortlich.
Am Ende jedes Sprints wird ein Sprint-Endebericht erstellt, der insbesondere dokumentiert, welche Anforderungen umgesetzt wurden und welche nicht realisiert werden konnten. Zudem werden etwaige Hindernisse, die im Sprint aufgetreten sind und zu Problemen geführt haben, beschrieben.
Natürlich muss bei einem größeren System geplant werden, in welchen Schritten (Ausbaustufen) das System realisiert (und wenn möglich auch eingesetzt) werden soll. Dazu wird auf Basis der initialen Version des Product Backlogs ein Release-Plan erstellt. Dieser legt fest, wie viele Sprints durchzuführen sind, um das Produkt zu erstellen, und welche zentralen Anforderungen in den einzelnen Sprints umgesetzt werden. Nach jedem Sprint wird der Release-Plan auf Basis der neuen Erfahrungen und Erkenntnisse aktualisiert. Analog zur Sprint-Fortschrittskontrolle wird auf Basis des Release-Plans ein Release-Burndown-Bericht erstellt und gepflegt.
Scrum verlangt einen iterativen Prozess, das Produkt entsteht inkrementell. Abbildung 10–18 zeigt die zentralen Elemente des Scrum-Prozesses, erweitert um Elemente der Release-Planung. Am Anfang müssen wie üblich Anforderungen gesammelt, priorisiert und bewertet werden. Dazu kann ein Anforderungsworkshop durchgeführt werden. Die gesammelten Anforderungen werden im Product Backlog festgehalten, das als Basis dient, um die Releases und die einzelnen Inkremententwicklungen, die Sprints, zu planen. Die Anforderungen, die in einem Sprint umgesetzt werden sollen, werden aus dem Product Backlog in das Sprint Backlog übernommen. Im Sprint werden alle Entwicklungstätigkeiten durchgeführt, die notwendig sind, um das Ziel des Sprints zu erreichen.
Abb. 10–18 Elemente des Scrum-Prozesses
Ein wesentliches Element des Sprints ist das sogenannte Daily Scrum, ein tägliches Treffen, nur eine Viertelstunde lang. Alle Teammitglieder berichten über ihre Fortschritte und stimmen die Planung des Tages ab. Neue Hindernisse werden besprochen und dokumentiert. So kennen alle den Stand des Projekts. Damit 15 Minuten ausreichen, muss das Treffen vorbereitet sein, das Sprint Backlog und der Sprint-Burndown-Bericht müssen aktualisiert vorliegen. Am Daily Scrum nehmen das Team, der Scrum-Master und, wenn möglich, der Produktverantwortliche teil.
Ein Sprint sollte nicht länger als 30 Tage dauern, kürzere Sprints sind die Regel. Am Ende jedes Sprints muss ein ausführbares und auslieferbares Produktinkrement vorliegen. Das ist jedoch, insbesondere bei den ersten Sprints, nicht immer sinnvoll. Pichler (2008) unterscheidet darum zwischen Explorations-, Standard- und Releasesprints. Explorationssprints dienen dazu, problematische und riskante Bereiche zu untersuchen und Lösungsalternativen zu erproben; das Ergebnis ist in der Regel ein Prototyp. Explorationssprints ähneln somit dem explorativen Prototyping (Abschnitt 9.4.4) oder einem Zyklus im Spiralmodell (Abschnitt 9.6). Während das Ergebnis eines Standardsprints ein Produktinkrement ist, das nicht unbedingt freigegeben und ausgeliefert wird, entsteht bei einem Releasesprint immer ein auslieferbares Produktinkrement.
Am Ende jedes Sprints finden zwei Bewertungssitzungen statt. Im Sprint-Review wird festgestellt, ob das Team alle Anforderungen vollständig und in der geforderten Qualität umgesetzt hat. Dazu präsentiert das Team die Ergebnisse und diskutiert sie mit dem Produktverantwortlichen. Der Produktverantwortliche nimmt die Implementierung ab, die erledigten wie auch die unerledigten Anforderungen werden im Sprint-Endebericht dokumentiert. In der Sprint-Retrospektive wird bewertet, wie gut der Scrum-Prozess im betrachteten Sprint umgesetzt werden konnte. Falls möglich, werden Verbesserungsmaßnahmen für kommende Sprints identifiziert. So wird der Scrum-Prozess stetig verbessert.
Die Ergebnisse des Sprints, des Sprint-Reviews und der Retrospektive fließen in die weitere Projektplanung ein, d. h., Product Backlog und Release-Plan müssen entsprechend aktualisiert werden, bevor ein neuer Sprint geplant werden kann.
Scrum wurde in vielen Projekten eingesetzt, die Erfahrungen sind mehrheitlich positiv. Jedoch ist Scrum nicht immer geeignet. So sollte die Teamgröße fünf bis zehn Personen nicht überschreiten, das Team muss am selben Ort arbeiten, und das Produkt muss sich inkrementell entwickeln lassen. Ist das Projektteam größer und soll das Projekt verteilt durchgeführt werden, dann müssen zusätzliche Organisationselemente eingeführt werden, da gleichzeitig mehrere Scrum-Teilprojekte koordiniert werden müssen. Dies wird als Scrum of Scrums bezeichnet. Generell sollte aber nur dann verteilt entwickelt werden, wenn dies unumgänglich ist.
Wie XP funktioniert auch Scrum nur dann, wenn ein kompetenter Produktverantwortlicher (entsprechend dem on-site customer in XP) in das Entwicklungsteam integriert werden kann. Der Erfolg oder der Misserfolg hängt, wie bei agilen Prozessen üblich, in besonderem Maße von der Motivation, der Kompetenz und der Kommunikationsfähigkeit der Teammitglieder ab. Diese müssen die Entwicklungstätigkeiten selbst organisieren und dafür sorgen, dass der Prozess und seine Regeln eingehalten werden. Das erfordert einen intensiven Lern- und Erfahrungsprozess, der maßgeblich vom Scrum-Master gestaltet werden muss. Natürlich verlaufen auch Scrum-Projekte nicht immer wie geplant, so können Sprints frühzeitig abgebrochen werden, wenn sich herausstellt, dass das Ziel nicht erreichbar ist. Scrum als Managementansatz kann offensichtlich gut mit agilen Techniken, wie sie beispielsweise XP vorgibt, kombiniert werden.
Now, a bigger gathering of organizational anarchists would be hard to find ...
aus der »History of the Agile Manifesto«
Die agilen Methoden können nicht pauschal charakterisiert oder bewertet werden; ihre Ähnlichkeit besteht vor allem in der Ablehnung der bürokratischen Prozesse. Weder das »Manifesto« noch die Prinzipien taugen als Definition eines Prozesses. Die hier behandelten Repräsentanten, Extreme Programming, Crystal und Scrum, unterscheiden sich erheblich; während XP durch eine oft irrationale Begeisterung für das »Anders-Arbeiten« geprägt ist und damit seinem Etikett »extrem« gerecht wird, erscheint Crystal als ein Ansatz, der speziell für kleine Projekte (Crystal Clear) einen vernünftigen Kompromiss zwischen den alten und den neuen Konzepten sucht. Scrum erweist sich als ein in vielen Situationen angemessenes Managementkonzept. Die Tatsache, dass XP große Aufmerksamkeit genießt, liegt vermutlich genau an seiner modischen Verpackung als Weltanschauung. Die im Manifesto demonstrierte Eintracht ist kein Bund fürs Leben; der Vater von Crystal stichelt auf seiner Webseite mit einer Abwandlung von Munchs »Schrei« zum »X-scream programming«.
Die Ablehnung einer bürokratischen Verkrustung der Prozesse ist nachvollziehbar und erfreulich; wer ein Webportal oder ein Spiel für das Mobiltelefon entwickelt, ist gut beraten, nicht monatelang nach einer umfassenden Spezifikation zu streben, sondern sich in einem evolutionären Ansatz mit kurzen Zyklen an eine Lösung heranzutasten, die dem Kunden gefällt. Dies sind typische Einsatzgebiete für die agilen Prozesse.
Wer aber die Software für ein Fly-by-Wire-System im Verkehrsflugzeug oder für die Datenübertragung einer Großbank entwickelt, wird (hoffentlich) nicht auf die Sicherheit und Solidität verzichten, die die traditionellen Ansätze bieten. Bei solchen Projekten gibt es keinen einzelnen Kunden, sondern Experten und Benutzer, deren Anforderungen sehr systematisch erhoben werden müssen. Und es ist zu erwarten, dass das System über Jahrzehnte eingesetzt und gewartet wird.
Wir rechnen damit, dass sich das religiöse Fieber legt und dass Ansätze wie XP und Crystal in einigen Jahren vergessen sein werden. Dagegen wird es weiterhin – und hoffentlich durch solide empirische Daten unterstützt – Versuche geben, für jede Klasse von Projekten den angemessenen Prozess zu finden. Bis jetzt (2010) können wir die Behauptung von Cockburn weder bestätigen noch bestreiten, dass große Projekte nicht agil durchgeführt werden können, in kleinen und mittelgroßen aber durch agiles Vorgehen erheblich bessere Effizienz erzielt wird.
