Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

15.12.2000 - 

Componentware/Rational Unified Process 2000 versus V-Modell '97

Softwareprojekte brauchen Navigationshilfe

In immer kürzeren Zyklen müssen hochwertige IT-Systeme gebaut werden. Gängige Entwicklungsmodelle wie der Rational Unified Process (RUP) und das V-Modell ?97 sollen Entwicklern helfen, diesem Trend gerecht zu werden. Markus Reinhold* erklärt die beiden Prozessrahmenwerke.

In vielen Unternehmen wird die Erstellung von Software immer noch als Kunst und weniger als ingenieurmäßige Disziplin angesehen. Wie die beiden Themen "Jahr 2000" und "Euro" zudem gezeigt haben, ist die Lebenserwartung von Software länger als ursprünglich angenommen. Wenn bei zukünftigen Projekten die erkannten Probleme vermieden werden und auch die Kostenseite stimmen soll, müssen Verfahren definiert werden, nach denen IT-Systeme zu bauen sind. Softwareingenieure wollen hier jedoch keinen starren Dogmen folgen, die sie bei ihren täglichen Aufgaben eher behindern als unterstützen. Auch für das Management ist es wichtig, schnell genug auf die Anforderungen ihrer Kunden reagieren zu können. Hierzulande haben sich insbesondere zwei Prozeßrahmenwerke etabliert, mit denen sich der Softwareentwicklungsprozess strukturieren lässt: das V-Modell ''97 und der Rational Unified Process 2000 der Firma Rational.

Bei der Anforderungsverwaltung liegt wohl das größte Potenzial zur Verbesserung der aktuellen Lage in der Softwarebranche. Mängel an dieser Stelle sind laut dem "Chaos Report" der Standish Group die häufigste Ursache für Systemfehler (http://www.standishgroup.com/visitor/chaos.html). Sowohl das V-Modell als auch der RUP haben einen Schwerpunkt im Bereich der Anforderungsverwaltung. Beide Ansätze berücksichtigen, dass sich Anwenderforderungen ändern. Das V-Modell stellt zur Beschreibung von Anforderungen ein Template zur Verfügung. Darin wird eine konkrete Dokumentenstruktur vorgeschlagen, die dem Autor hilft, alle Aspekte bezüglich der Anforderungen zu erfassen. Derartige Strukturen sind umfangreich und haben den Charakter einer Checkliste. Die iterativ inkrementelle Entwicklungsstrategie im V-Modell ''97 schlägt vor, das gesamte System in Stufen (Inkrementen), beginnend von einer Kernausbaustufe in mehreren Schritten zum Endausbau zu gestalten. Hier wird also der Begriff Inkrement mit einer voll funktionsfähigen operativen Ausbaustufe eines Systems gleichgesetzt, die an den Kunden ausgeliefert wird.

Der Rational Unfied Process sieht ein Inkrement als das Delta zwischen zwei aufeinanderfolgenden Iterationen. Interessant sind die Aussagen zum Thema Anzahl von Iterationen beziehungsweise Dauer einer Iteration: Beim einmaligen Durchlaufen der vier vordefinierten Phasen des RUP werden in der Regel zwischen drei und neun Iterationen durchlaufen. Es ist also offensichtlich, dass hier ein und derselbe Begriff für zwei unterschiedliche Zeitrahmen verwendet wird. Bei genauerem Nachforschen stellt man fest, dass der Unified-Process-Begriff, der inhaltlich die gleiche Aussage liefert wie das "V-Modell Inkrement", Cycle genannt wird. Hieraus sollte man nicht den falschen Schluss ziehen, dass es bei der Abwicklung von Projekten nach V-Modell, keine Inkremente im Sinne des RUP geben darf.

Bei iterativ inkrementeller Vorgehensweise bildet die architekturzentrierte Entwicklung eine der wichtigsten Grundlagen. Ohne wohldefinierte Architektur führt ein stufenweiser (inkrementeller) Aufbau des Systems in vielen Fällen ins Verderben. Sowohl das V-Modell ''97 als auch der RUP 2000 setzen hier einen deutlichen Schwerpunkt, wobei der RUP betont, dass der Begriff "Architektur" für unterschiedliche Projektbeteiligte verschiedene Bedeutungen hat. Hier ist es somit möglich, die Architektur eines Systems großteils mit Hilfe von Ausschnitten (Sichten, Views) aus Modellen zu beschreiben. Jede Sicht bietet eine vereinfachte Beschreibung des Systems aus einem bestimmten Blickwinkel.

Somit erhält jeder Projektbeteiligte den Blickwinkel, der ihm hilft, die Architektur zu verstehen, ähnlich wie es in der Baubranche Pläne für die elektrische Verkabelung (interessant für Elektriker) wie auch Pläne für die Raumaufteilung pro Stockwerk (interessant für Maurer) gibt. Im Vergleich hierzu wird die Architektur im V-Modell aus zwei Blickwinkeln beschrieben. Die dynamische und statische Zerlegung des Systems bis zu einer bestimmten Ebene bildet die "Systemarchitektur". Für jedes kleinste Element dieser Zerlegung wird dann eine detailliertere "Softwarearchitektur" erarbeitet. Auch hier stellt das V-Modell ''97 hilfreiche Dokumentationsvorlagen zur Verfügung.

Eine der Kerneigenschaften des RUP ist die Unterstützung visueller Modellierung von Systemen. Speziell im Bereich Objektorientierung kann man sagen, dass sich hier die Unified Modeling Language (UML) durchgesetzt hat. Auch im V-Modell wird diese Bedeutung klar hervorgehoben, jedoch aufgrund seiner breiteren Einsetzbarkeit (nicht notwendigerweise nur für Objektorientierung) auf separate Dokumente ausgelagert. Die Beschreibung von V-Modell-Aktivitäten (zum Beispiel Erfassen von Anwenderforderungen) wurden unabhängig von speziellen Modellierungssprachen wie der UML gehalten. Natürlich wurde aber auch im V-Modell ''97 eine Brücke gebaut zwischen "Was?" ist zu tun und "Wie?" ist es zu beschreiben.

Beim Einsatz einer Modellierungssprache wie der UML im RUP ist es ferner zwingend erforderlich, mit den bereits erwähnten Sichten (Views) zu operieren. Das bedeutet jedoch, dass in verschiedensten Sichten ein und dasselbe Element auftauchen kann. Problematisch ist in solchen Situationen, die Konsistenz zu gewährleisten. Ohne ein Werkzeug, das die semantische Information auch wirklich pflegt, ist ein Sichtenansatz innerhalb kurzer Zeit zum Scheitern verurteilt, da eine manuelle Pflege nur mit hohem personellen Aufwand möglich wäre. Daraus ergibt sich die Konsequenz, dass bei Einsatz des RUP ein entsprechendes UML-Modellierungswerkzeug nötig ist. Doch dieser Tool-Einsatz alleine reicht nicht aus. Ein konsequent durchgezogener Modellierungsansatz ist ebenso erforderlich, das heißt die Verwendung eines kostspieligen Modellierungswerkzeuges als Mal-Tool führt innerhalb kurzer Zeit zu Problemen. Hier stellt sich allerdings die Frage, wie viele Projekte ein Case-Tool in einer solch konsequenten Form nutzen.

Als weitere Best Practice wird im RUP schließlich die Verifikation der Softwarequalität genannt. Hier ist der Qualitätsbegriff nicht auf das einfache Erfüllen von funktionalen wie nichtfunktionalen Anforderungen beschränkt, sondern beinhaltet auch die Definition von Maßnahmen und Kriterien zum Nachweis, dass die Qualität erreicht wurde. Ferner fordert der Qualitätsbegriff eine durchdachte Softwareentwicklung, damit sich das Endergebnis durch die gewünschte Qualität auszeichnet und später erneut erzielt werden kann (Wiederholbarkeit). Das V-Modell bezeichnet dies als analytische beziehungsweise konstruktive Qualitätssicherung und verfolgt einen vergleichbaren Ansatz.

Beim Einsatz eines iterativ inkrementellen Prozessmodells ist sehr effektives Testen möglich. Anstelle eines riesigen Prüfblocks vor Auslieferung kann das Testen stufenweise geschehen, da jede Iteration im Entwicklungsprozess ein prüfbares Ergebnis liefert. Ein derart kontinuierliches Testen ist jedoch nur möglich, wenn Werkzeuge zum Einsatz kommen, da ein manuelles Vorgehen einen extrem hohen Personalaufwand mit sich bringt und zudem sehr fehleranfällig ist.

Einen relevanten Unterschied zwischen V-Modell ''97 und RUP 2000 scheint es im Bereich der Rollendefinitionen zu geben. Im RUP wird auf die Rolle des "Quality Engineer" verzichtet, und die Qualität liegt explizit in jedermanns Verantwortung. Ein Blick in den RUP zeigt, dass keine spezifischen Rollen für das Testen von Klassen, Paketen, Komponenten und Subsystemen existieren. Der Vorschlag des V-Modells ist hier, dass auch für diese Bereiche ausgezeichnete Rollen zur Verfügung stehen. Zusätzlich ist jedoch eine Selbstprüfung definiert, für die der Entwickler als primär Verantwortlicher gilt.

Auch die Art und Weise, wie das zu erstellende System später geändert werden kann, muss kontrollierbar sein. Speziell bei einem iterativ inkrementellen Ansatz, der ja eine frühe und kontinuierliche Einbeziehung des Kunden vorsieht, ist dieser Gedanke essentiell, da sonst die Gefahr besteht in Änderungen zu ertrinken. Für komponentenbasierte Entwicklung ist deshalb ein funktionierendes Konfigurations- mit zugehörigem Änderungs-Management ein entscheidender Aspekt. Was hilft ein Stück Software in Form einer Komponente, wenn alle dazugehörigen Informationen (Modelle, Dokumentation, Testfälle etc.) nicht auffindbar, unvollständig oder veraltet sind?

*Markus Reinhold ist Trainer und Berater für OO-Entwicklung, Vorgehensmodelle und Tooleinsatz und Gründer der Firma Cocoo in Putzbrunn.

AngeklicktDerzeit befassen sich viele Unternehmen mit der Verbesserung oder Definition ihrer Softwareentwicklung. Nur wenige versuchen, das Rad neu zu erfinden. Viele setzen auf allgemein verfügbare Prozessrahmenwerke, die den Anspruch erheben, sich an die individuellen Bedürfnisse des jeweiligen Unternehmens anpassen zu lassen. Aber nur wer ausreichend firmenspezifisches Wissen und eine erhebliche Menge an Grundlagenwissen besitzt, sollte sich mit der Einführung eines Prozessrahmenwerks inklusive Anpassung an firmenspezifische Bedürfnisse befassen.

InformationenInteressenten können sich zum Thema "Rational Unified Process (versus V-Modell ''97" im Rahmen bundesweiter Veranstaltungen diverser Anbieter weiter informieren: 12. 01. 01 (Erlangen), 12. - 13. 02. 01 (Mainz), 13. - 14. 03. 01 (Stuttgart), 02 - 03. 04. 01 (Köln), 21. - 22. 06. 01 (München) - weitere Infos u. Termine siehe www.cocoo.de. Ziel der Überblicksveranstaltungen ist es, Anwendern bei der Auswahl und Bewertung dieser und anderer Rahmenwerke zu unterstützen.

Abb: Der Rational Unified Process bietet ein Prozessrahmenwerk, das den Entwicklungsprozess strukturieren hilft. Quelle: CW