Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Transkript

1 Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und tatsächlich ist dies auch des Öfteren der Fall. Fehler in der Organisation von Projekten führt meist zu deren Scheitern. Es stellt sich grundsätzlich die Frage, ob die Softwareentwicklung ein künstlerischer Prozess mit vielen Gestaltungsfreiräumen ist oder das ingenieurmäßiges Vorgehen zu besseren Ergebnissen führt [ReVe02,135]. Tatsächlich ist die Softwareentwicklung nach ingenieurmäßigen Prinzipien, unter Verwendung eines Vorgehensmodells, erfolgreicher als der künstlerische Ansatz. Die Hauptaufgabe eines Vorgehensmodells ist es, die Softwareentwicklung planbar und überschaubar zu machen. Daraus resultiert, dass das Vorgehen auch leichter nachvollziehbar ist und gleichzeitig die Qualität der Ergebnisse gesteigert wird. Weitere Vorteile eines Vorgehensmodells ergeben sich wie folgt: Verbesserte Kommunikation der Projektbeteiligten Höhere Produktqualität wird gewährleistet Produktivitätsgewinn durch Reduzierung von Einarbeitungs- und Schulungszeiten Bessere Kalkulation von Neuprojekten bei standardisiertem Vorgehen Geringere Abhängigkeit von Personen und Firmen Verringerung der Wartungsfälle durch verbesserte Produktqualität Verringerung des Wartungsaufwands durch leichtere Verständlichkeit und durch ausreichende/einheitliche Dokumentation Ein Vorgehensmodell, das den gesamten Lebenszyklus eines Software-Produkts abdeckt, wird meist als Lebenszyklusmodell bzw. Life-Cycle-Modell bezeichnet. Dieses umfasst sowohl die Phasen Analyse und Design bis zur Testphase, als auch den eigentlichen Einsatz des Produktes und dessen Wartung. In der Praxis existieren verschieden Ausprägungen von Vorgehensmodellen. Die Verwendung ist meist abhängig vom Umfang des Softwareprojektes. Im folgenden werden vier verschiedene Vorgehensmodelle betrachtet, welche in der Praxis eingesetzt werden: Wasserfallmodell, Extreme Programming (XP), Rational Unified Process (RUP) und das V- Modell. Natürlich existieren noch weitere Vorgehensmodelle. Es wurden aber die genannten Modelle auf Grind ihrer Praxis-Relevanz augsgewählt. Wasserfallmodell Wie bereits erwähnt, nennt man den Zeitraum eines Software-Projekts von Planung über Realisierung und Einsatz bis hin zur Ausmusterung den Lebenszyklus der Software. Die verschiedenen Phasen eines Software-Projekts können unterschiedlich organisiert und untereinander verknüpft sein. Ein sehr gängiges Modell, um diesen Lebenszyklus abzubilden ist das Phasen- oder Wasserfallmodell. Dieses besteht meist aus fünf unterschiedlichen Phasen: Analyse und Design Entwurf Implementierung Test Einsatz und Wartung

2 Vorgehensmodelle Seite 2/6 Das Wasserfallmodell bietet auf den ersten Blick einige Vorteile. Die strenge Aufgabenteilung ist scheinbar leichter zu verwalten. Ist eine Phase abgeschlossen, braucht man sich um diese nicht mehr zu kümmern. Damit ergibt sich eine gewisse Reduzierung der Komplexität des gesamten Projektes, da die Phasen isoliert gesehen werden. Weiters ist Test und Wartung eine integrierter Bestandteil des Modells. Doch es gibt auch eine Reihe von Kritikpunkten das klassische Wasserfallmodell betreffend. Die strikte sequentielle Abfolge, welche eine Erleichterung bei der Verwaltung des Projektes ermöglicht, birgt Probleme. Dadurch sind sehr spät lauffähige Versionen verfügbar. Weiters sind keine Rückwirkungen in bereites durchlaufene Phasen vorgesehen. Eine Verzögerung während des Projektes wirkt sich immer negativ auf die Testphase auf, da diese isoliert am Schluss des Projektes angesiedelt ist. Aus diesen genannten Gründen wurde das klassische Wasserfallmodell verfeinert: iteriertes Phasenmodell iteriertes Phasemodell mit Prototyping Das iterierte Phasenmodell sieht Rückwirkungen der einzelnen Phasen auf vorherige Phasen vor. Allerdings ist auch hier die Testphase weiterhin am Ende angesiedelt. Das iterierte Phasenmodell mit Prototyping setzt schnell verfügbare Prototypen ein, welche vor allem die Analyse- und Designphase unterstützen. Diese Vorgangsweise wird vor allem bei GUI- bzw. Webprojekten angewandt. Prototyp Abb. 1 verfeinertes Wasserfallmodell Das Wasserfallmodell wird in der Praxis immer noch in kleinen, überschaubaren Projekte angewandt. Obwohl sich die Wissenschaft einig ist, dass dieses auch dort nicht mehr verwendet werden soll. Als klarer Nachteil des Wasserfallmodells ist die zu isoliert betrachtete Testphase am Ende des Projektes anzusehen. Als Begründung für die Verwendung dieses Modells ist seine Einfachheit zu nennen. Diese mag bei kleinen überschaubaren Projekten noch als Vorteil erscheinen, allerdings führt der Einsatz des Wasserfallmodells bei größeren Projekten zu Problemen. Dort sollten schwergewichtige Prozesse eingesetzt werden.

3 Vorgehensmodelle Seite 3/6 Extreme Programming XP Extreme Programming erfreut sich als alternatives Vorgehensmodell zunehmender Beliebtheit. Dieser Ansatz wurde zu Beginn der 90er Jahre von Kent Beck entwickelt. Dabei handelt es sich um eine neue Vorgehensweise, um Projekte, welche starken Änderungen unterworfen sind, bzw. bei denen zu Projektbeginn die Ziele noch nicht klar definiert wurden, besser managebar zu machen und die Qualität des Ergebnisses zu verbessern. Kent Beck bezeichnet Kommunikation, Einfachheit, Feedback und Mut als die vier Grundprinzipien von XP. XP beinhaltet eine Reihe von Regeln und Aufgaben (Practises). Diese betreffend die Planung, das Design, das Codieren sowie das Testen. Der Grundgedanke von XP besteht in einer inkrementell iterativen Entwicklung. Der Start eines XP-Projektes beginnt stets mit einer User-Storie. Dabei wird mit dem Kunden eine Beschreibung des Systems erarbeitet, welche im weiteren Verlauf die Grundlage für das Release Planing sowie die Acceptance-Tests dient. Wichtig ist dabei, dass der Kunde während des gesamten Projekte integriert wird. Somit keine schnell steuernd eingegriffen werden, wenn das Projekt in die falsche Richtung läuft. Die Entwickler schätzen die Zeit, welche für die Implementierung einer User-Story benötigt wird. Überschreitet der Aufwand einen Zeitrahmen von 3 Wochen, so muss die User-Story in Teilbereiche aufgebrochen werden. Dabei verlangt XP dass die Implementierung der Funktionalität immer im Team erfolgt. Somit ist währen der Implementierung gleichzeitig ein Code-Review gegeben (Pair- Programming). Ein weiterer zentraler Bestandteil von XP sind die integrierten Tests. XP sieht vor, dass Testfälle bereits vor der eigentlichen Erstellung der jeweiligen Funktionalität implementiert werden sollen. Alle Codeteile müssen die integrierten Tests durchlaufen, damit diese akzeptiert werden. Werden Fehler gefunden, führt dies zu einer neuen Iteration. Somit soll sicher gestellt werden, dass keine bzw. sehr wenige Fehler in der endgültigen Version des Systems auftreten. [WeDo01] Abb. 2 Extreme Programming Bei XP ist die Anzahl der Teammitglieder beschränkt. Diese umfasst im Normalfall 2 10 Leute. Mehr Teilnehmer sind in diesem Vorgehensmodell nicht vorgesehen. Somit ist auch der Einsatz von XP auf kleinere bist mittlere Projekte beschränkt. Größere Projekte werden in der Praxis meist mit schwergewichtigeren Prozessen wie dem Rational Unified Process bzw. nach dem V-Modell bestritten.

4 Vorgehensmodelle Seite 4/6 Rational Unified Process - RUP 1999 wurde der RUP zusammen mit der Rational Suite eine Sammlung von Tools für die Softwareentwicklung auf den Markt gebracht. Der Rational Unified Process basiert dabei auf sechs Grundprizipien: Iterativ/inkrementelle Entwicklung Anforderungsmanagement Architekturzentrierte Entwicklung Visuelle Modellierung Verifikation der Software Qualität Kontrollierte Änderung der Software Der RUP gliedert ein Softwareprojekt in acht verschiedene Prozesse sowie vier verschiedene Phasen. Die folgende Abbildung gibt einen Überblick der Prozesse sowie Phasen: Abb. 3 Ratinal Unified Process Die vier Phasen Einführung, Ausarbeitung, Konstruktion und Übergang erlauben eine Organisation des Projektes entsprechend des zeitlichen Ablaufs, während die Prozesse eine Organisation entsprechend der verschiedenen Aufgaben ermöglicht. Dabei entsprechen die fünf Kern-Prozesse den Phasen eines klassischen Wasserfallmodells. Unterstützt werden diese Prozesse vom Konfigurations- und Änderungsmanagement, dem Projektmanagement sowie dem Enivronment, welche die Projekt Rahmenbedingungen definiert. Wie aus der Grafik ersichtlich, laufen die verschiedenen Prozesse zeitlich parallel ab. Der RUP verfolgt eine inkrementelle iterative Entwicklung eines Softwareprojektes. Die verschiedenen Phasen und Prozesse lassen sich dabei übergreifend und in jeder Iteration durchführen [ReVe02,136]. Der Rational Unified Process wird weltweit von vielen Unternehmen für mittel bis große Softwareprojekte eingesetzt. Dies vor allem auch daher, da die weit verbreiteten Rational-

5 Vorgehensmodelle Seite 5/6 Produkte, wie Rational Rose (UML), auf den RUP abgestimmt sind. Der RUP ist dabei flexibel einsetzbar und wird von Rational ständig weiterentwickelt. Als Nachteil kann man vermerken, dass dieser besonders auf Rational Produkte ausgerichtet ist. V-Modell Das V-Modell entstand aus einer Initiative des Deutschen Innen- bzw. Verteidigungsministeriums und wurde 1997 in einer überarbeiteten Fassung unter der Bezeichnung V97 auf den Markt gebracht. In der Deutschland ist der Einsatz des V-Modells bei öffentlichen Ausschreibungen verpflichtend vorgesehen. Dieses Modell war das erste, das alle Aspekte des Software-Engineering inklusive seiner Zusammenhänge komplett abdeckte: Entwicklung, Konfigurationsmanagement, Qualitätssicherung und Projeketmanagement [ReVe02,135]. Diese genannten Submodelle weisen weitere Bereiche auf. Ergebnisse eine Submodells liefern die Eingabe für ein anderes Submodell. Durch integrierte Tabellen wird hierbei ein Überblick verschafft. Diese geben an, welche Aktivitäten welchen Input von welchem Submodell benötigen. [ReVe02] Die V-Modelle führten in der Qualitätssicherung eine Trennung der Aktivitäten zwischen konstruktiven und prüfenden Aktivitäten ein. So ist jeder Phase mit hauptsächlich konstruktiven Elementen eine Phase mit den entsprechenden prüfenden Aktivitäten zugeordnet. Diese Aufteilung lässt sich in einem V darstellen. Auf der linken Seite befinden sich die konstruktiven Elemente, auf der rechten Seite in gleicher Höhe die zugeordneten prüfenden Aktivitäten. Fehler, die in einer Konstruktionsphase begangen werden, lassen sich am leichtesten in der zugehörigen Prüfphase finden. Weiters entsprechen die unterschiedlichen Strecken innerhalb des V die steigenden Korrekturkosten bei später entdeckten Fehlern. Das V-Modell wird des öfteren als eine Wasserfallmodell bezeichnet. Diese trifft allerdings nicht zu. Prinzipiell ist ein wasserfallartiges sowie ein inkrementelles Vorgehen möglich. Die Definition ist hier sehr wage gehalten, sodass im Prinzip verschiedene Entwicklungsszenarien Abb. 4 V-Modell

6 Vorgehensmodelle Seite 6/6 eingesetzt werden können. Es ist z.b. auch mögliche, den Rational Unified Process und das V-Modell miteinander zu verschmelzen. Dieses Vorgehen hat den Vorteil, dass die präzise Auslegung der iterativ inkrementellen Entwicklung des RUP eine Hilfestellung bei der Definition des Phasenmodells sowie der Planung eines iterativen/inkrementellen Vorgehens für das V-Modell bietet. Das V-Modell weist wie jedes Vorgehensmodell Vor- bzw. Nachteile auf: [ReVe02] VT: Quasistandard in Deutschland für jedes Projekt einsetzbar konfigurierbar (Tailoring) kontinuierliche Weiterentwicklung NT: nur im deutschsprachigem Raum verbreitet letzte Version 1997 hoher Anpassungsbedarf bei OO-Projekten Wie bereits erwähnt ist das V-Modell in Deutschland ein Quasistandard und wird bei mittleren bis größeren Projekten eingesetzt. Nicht zuletzt dadurch bedingt, dass es bei öffentlichen Ausschreibungen vorgeschrieben ist. Prinzipiell kann das V-Modell für alle mögliche Projekte eingesetzte werden. Die Bandbreite des Modells umfasst dabei Anforderungsspezifikation, Analyse, Design, Implementierung, Rollout, Wartung, Prozess- Management, Projekt-Management, Qualitäts-Management und Test-Management. Auf Grund des Umfangs wird das V-Modell vor allem bei mittleren bis großen Projekten eingesetzt. [EtAn01] Fazit Zusammenfassend lässt sich feststellen, dass sich der Einsatz von Vorgehensmodellen als Richtlinie zu Software-Entwicklung in der Praxis bewährt hat. Das richtige Vorgehensmodell hängt vom jeweiligen Einsatzzweck bzw. vom Projektumfang ab. Kleine überschaubare Projekte entwickelt man am einfachsten immer noch mit dem Wasserfallmodell. XP wird ebenfalls für kleinere Projekte eingesetzt, erfordert aber eine Umstellung aller Beteiligter sowie eine Portion Mut. Für größere Projekte werden schwergewichtiger Prozesse wie RUP bzw. das V-Modell eingesetzt. Schlussendlich entscheiden aber die weichen Faktoren wie etwa das Akzeptanzverhalten der Mitarbeiter über Erfolg oder Misserfolg des eingesetzten Vorgehensmodells. Quellen [EtAn01] [ReVe02] [WeDo01] Andreas Etling (2001) Richtungsweisend, Ein Kriterienkatalog für Vorgehensmodelle. ix 12, Heise Verlag Hannover. Seiten Markus Reinhold, Gerhard Versteegen (2002) Geordnetes Chaos, V-Modell versus Rational Unified Process. ix 5, Heise Verlag Hannover, Seiten Donovan Wells (2001) Extreme Programming. ( )