Software-Engineering mit RUP und UML

Wie der Definition zu entnehmen ist handelt es sich beim Software-Engineering um die Summe aller Verfahren zur Entwicklung und Einsetzung von Programmen. Aus dem englischen frei übersetzt könnte man aber auch sagen, dass Software-Engineering das ingenieurtechnische Bauen von Software ist (da neben engine – Maschine – auch engineer – Ingenieur – in Engineering enthalten ist). Jede (Entwicklungs-)Tätigkeit eines Ingenieurs zeichnet sich dadurch aus, dass sie auf bekannten und dokumentierten Verfahren beruht und jeweils auch selbst so dokumentiert wird, dass ein anderer Ingenieur mit demselben Basiswissen jederzeit in der Lage ist, dasselbe Ergebnis zu erreichen.
Basierend auf den Verfahren, die sich in der noch recht jungen Ingenieurdisziplin Software-Engineering als besonders robust erwiesen haben, sind Prozessbeschreibungen wie das V-Modell entstanden, die einen Rahmen für die in der Softwareentwicklung anfallenden Tätigkeiten vorgeben. Durch das Verwenden dieser Prozesse wird die Softwareentwicklung nachverfolgbar und somit auch transparenter für alle beteiligten Personen. Dies erleichtert das Steuern der Softwareentwicklung und trägt somit auch dazu bei selbst in komplexen Projekten das zu erstellende Produkt innerhalb der zur Verfügung stehenden Zeit mit den kalkulierten Kosten und einer hohen Produktqualität zu erstellen. Viele der aktuell verwendeten Prozesse zur Softwareentwicklung, sei es ein Standard wie das V-Modell oder eigenentwickelte Prozesse, sind jedoch auf der „grünen Wiese“ entstanden und decken nicht die wahren Bedürfnisse der Softwarentwicklung. Stattdessen neigen sie dazu den Entwicklungsprozess zu bürokratisieren und zu lähmen.

Der Rational Unified Process

Für objektorientierte Softwareentwicklung hat sich der Rational Unified Process (RUP) als sehr erfolgreicher Entwicklungsprozess herauskristallisiert. Es gibt mehrere Gründe, warum der RUP gerade für objektorientierte Softwareentwicklung so erfolgreich ist. Dazu zählt zum Einen, dass er sich aus diversen objektorientierten Ansätzen entwickelt hat (und noch immer entwickelt) und zum Anderen, dass er auf jahrzehntelanger Erfahrung wie man am besten Software entwickelt (den so genannten „Best Practices“) beruht.

Der RUP teilt die Softwareentwicklung in die vier Phasen Konzept, Entwurf, Konstruktion und Übergang auf, in denen jeweils die Kerndisziplinen (ursprünglich Workflows) Geschäftsprozessmodellierung, Anforderungsmanagement, Analyse und Design, Implementation, Test und Verteilung angewandt werden. Parallel zu den Kerndisziplinen gibt es noch die unterstützenden Disziplinen Konfigurations- und Änderungsmanagement, Projektmanagement und Umgebung. Die unterstützenden Disziplinen sind zwar nicht für die eigentliche Softwareentwicklung notwendig, aber unabdingbar für die Durchführung größerer Projekte.

Jede einzelne Phase wird dabei in mehreren Iterationen durchlaufen an deren Ende (eventuell mit Ausnahme der Konzeptphase) ein funktionsfähiges Produkt steht. Jede einzelne Iteration wird dabei nach dem Wasserfallmodell durchlaufen (wobei dies nicht ganz genau ist, da es nicht explizit verboten, teilweise sogar erwünscht ist, die einzelnen Disziplinen parallel zu durchlaufen).

Zuschneiden

Wie jeder andere Prozess muss auch der RUP an die jeweiligen Bedürfnisse eines konkreten Softwareentwicklungs-Projekts angepasst werden. Nicht immer ist es sinnvoll, jedes im RUP beschrieben Artefakt (Dokumente, Diagramme, Projektplan etc.) auch zu erzeugen. Sehr schnell kann es da passieren, dass man mehr Zeit für das Verwalten und Anwenden des RUP verwendet als für die eigentliche Entwicklungstätigkeit. Der RUP ist kein Selbstzweck und bevor ein bestimmtes Artefakt erzeugt wird, sollte immer erst überlegt werden, ob die Lösung eines konkreten Problems nicht auch einfacher zu erreichen ist.

Die Phasen und Disziplinen im RUP (Quelle: Rational)

Fallstricke

Bei der Einführung bzw. beim Einsatz hält der RUP mehrere Fallstricke bereit, über die man leicht stolpern kann. Eine Entwicklergruppe, die jahrelang nach dem Wasserfallmodell gearbeitet hat, wird sich nicht ohne weiteres an das Iterative Vorgehen gewöhnen und tendiert schnell dazu, die Iterationen auf eine Einzige zusammenzustreichen, um dann doch wieder nach dem Wasserfallmodell zu entwickeln. Oder es wird nur vermeintlich iterativ, in Wirklichkeit aber inkrementell entwickelt, was dann dazu führt, dass sich das Datenmodell nicht stabilisiert und schon bestehende Teilprodukte immer wieder angepasst werden müssen. Sehr häufig wird eine Entwicklungsgruppe auch so aufgebaut, dass einem Gruppenmitglied genau eine der Rollen aus dem RUP zugewiesen wird. Dann gibt es einen Analytiker, einen Architekten, einen Programmierer usw. und das, obwohl es wünschenswert ist, dass Gruppenmitglieder mehrere Rollen wahrnehmen. Die Spezialisierung der einzelnen Gruppenmitglieder geht auch immer einher mit einem erhöhten Dokumentationsaufwand. Jedes Gruppenmitglied möchte naturgemäß seine Arbeit so gut wie möglich machen und tendiert schnell dazu zu viele Details in z.B. der Analyse zu beschreiben. Auch muss ein Designmodell dann so umfangreich beschrieben sein, dass ein Programmierer alleine mit diesem Modell seine Arbeit durchführen kann. Nichts ist schlimmer als viele unterschiedliche Quellen für die jeweils durchzuführende Tätigkeit, da diese sich unter Umständen widersprechen oder nicht alle relevanten Quellen bekannt sind (auch wenn diese sich nicht immer vermeiden lassen wie z.B. bei Offshore- oder Nearshore-Entwicklung). Je mehr einzelne Rollen eine Anforderung zu durchlaufen hat, umso wahrscheinlicher ist es, dass die Anforderung falsch umgesetzt wird (Prinzip „stille Post“).

RUP und UML

Ein weiterer Fallstrick lauert beim Einsatz der Unified Modeling Language. Obwohl sich der RUP unter anderem auch auf Basis der UML entwickelt hat, ist der RUP nicht allein auf das Verwenden der einzelnen Modellelemente der UML beschränkt. Unter Umständen kommt man deutlich schneller durch Einsatz von CRC-Karten und Post-It-Prototypen zum Ziel, als durch das stundenlange Modellieren von Use-Cases, Klassendiagrammen, Sequenzdiagrammen oder Aktivitätsdiagrammen. Die UML sollte als das betrachtet werden was sie ist, ein standardisierter Werkzeugkasten, der bei Bedarf mit Spezialwerkzeug aufgefüllt werden kann.

Enterprise Unified Process

Wie eingangs erwähnt handelt es sich beim Software-Engineering um die Summe aller Verfahren zur Entwicklung und Einsetzung von Programmen. Dem aufmerksamen Leser wird sicherlich aufgefallen sein, dass der RUP nur einen Prozess für die Softwareentwicklung beschreibt. Nach der Phase Übergang (der Software in den Betrieb) fehlt noch eine Phase für den Betrieb und den Support, ggf. zusätzlich auch noch eine Phase für die Betriebseinstellung einer Software. Dieser fehlenden Punkte hat sich der Enterprise Unified Prozess (EUP) angenommen.

Fazit

Wenn man nicht wegen äußerer Zwänge einen bestimmten Prozess einsetzen muss, sollte man für objektorientierte Softwareentwicklungsprojekte den Rational Unified Process bzw. seine Erweiterung den Enterprise Unified Process einsetzen. Durch seinen Fokus auf die Verwendung von „Best Practices“ hat er sich schon im Ganzen bzw. in Teilen in Hunderten von Projekten bewährt. Allerdings ist man auch beim Verwenden des RUP nicht vor Fallstricken gefeit. Diese kann man jedoch weitestgehend vermeiden, wenn man - gerade bei der Einführung des RUP - auf jemanden zurückgreifen kann, der schon erfolgreich mit dem RUP gearbeitet hat, und wenn alle am Projekt Beteiligten dazu gewillt sind, auf den ersten Blick ungewöhnliche oder unbequeme Methoden wie die Iterative Vorgehensweise einzusetzen.

Literatur

Versteegen: Projektmanagement mit dem Rational Unified Process, Springer Verlag

Rational Unified Process, www.rational.com

Enterprise Unified Process, www.enterpriseunifiedprocess.info/downloads/eupIntroduction.pdf

UML, www.uml.org

Autor

Reiner Grabasch, Senior Consultant, Concrete Logic GmbH

Download

Sie können diesen Artikel auch als PDF-Dokument herunterladen, um ihn sich auszudrucken.