<< zurück

MBSE Home

weiter >>

2 Agile und UML-basierte Methodik

Der zielgerichtete, in eine Methodik eingebettete Einsatz ist für die erfolgreiche Verwendung einer Modellierungssprache unverzichtbar. In diesem Kapitel werden Charakteristika agiler Methoden, insbesondere des Extreme Programming (XP) Prozesses [Bec04, Rum01] herausgearbeitet. Gemeinsam mit weiteren Elementen wird daraus ein Vorschlag für eine agile, auf der UML basierenden Methodik eingeführt.

2.1 Das Portfolio der Softwaretechnik
2.2 Extreme Programming (XP)
2.3 Ausgesuchte Entwicklungspraktiken
2.3.1 Pair Programming
2.3.2 Test-First-Ansatz
2.3.3 Refactoring
2.4 Agile UML-basierte Vorgehensweise
2.5 Zusammenfassung

Die Verbesserungen in der Softwaretechnik sind seit Jahren verantwortlich für kontinuierliche Effizienzsteigerungen in Softwareentwicklungsprojekten. Software mit hoher Qualität ist mit immer weniger personellen Ressourcen in immer kürzeren Zeiten zu erstellen. Prozesse wie der Rational Unified Process (RUP) [Kru03] oder das V-Modell XT [HH08] sind eher für große Projekte mit vielen Teammitgliedern geeignet. Sie sind aber speziell für kleinere Projektgrößen überfrachtet mit Tätigkeiten, die für das Endergebnis nicht unbedingt essentiell sind, und deshalb auch zu schwerfällig, um auf die sich schnell ändernde Umgebung (Technik, Anforderungen, Konkurrenz) eines Softwareentwicklungsprojekts reagieren zu können.

Flexibilität, schnelles Feedback, Konzentration auf die wesentlichen Arbeitsergebnisse und die Fokussierung auf die im Projekt beteiligten Personen und insbesondere Kunden sind wesentliche Charakteristika der neu entstandenden Prozesse, denen unter dem Begriff der „Agilen Prozesse“ ein gemeinsames Label gegeben wurde.

Der Standish Report [Gro09b] beschreibt, dass wesentliche Ursachen des Scheiterns von Projekten im schlechten Projektmanagement zu suchen sind: Es wird nicht adäquat kommuniziert, zu viel, zu wenig oder das Falsche dokumentiert, Risiken nicht rechtzeitig entgegengesteuert oder zu spät Rückkopplung von den Anwendern eingefordert.

Speziell die menschliche Komponente, also die projektinterne Kommunikation und Zusammenarbeit zwischen Entwicklern untereinander und der Entwickler mit den Anwendern, wird als wesentliche Ursache für das Scheitern von Softwareentwicklungsprojekten erkannt. Auch laut [Coc06] scheitern Projekte selten aus technischen Gründen. Das spricht einerseits für die gute Beherrschung auch von innovativen Techniken, ist andererseits aber zumindest teilweise zu hinterfragen. Denn wenn die Technik Schwierigkeiten bereitet, dann verursachen diese Probleme oft zwischenmenschliche Kommunikationsstörungen, die dann im weiteren Projektverlauf aus emotionalen Gründen in den Vordergrund rücken und letztlich als „gefühlte“ Gründe für das Scheitern des Projekts in Erinnerung bleiben.

Die richtige Technik ist in Form von Sprachen und Werkzeugen die wesentliche Grundlage für die „Leichtgewichtigkeit“ der neuen Prozessgeneration. Je kompakter die Sprache und je besser die Analyse- und Generierungswerkzeuge sind, um so effizienter sind die Entwickler und um so weniger Zusatzaufwand für Management oder Dokumentationsleistungen fällt an.

Softwaretechnik bietet mittlerweile ein großes Portfolio an Vorgehensweisen, Prinzipien, Entwicklungspraktiken, Werkzeugen und Notationen, die zur Entwicklung von Softwaresystemen unterschiedlichster Form, Größe und Qualität verwendet werden können. Diese Elemente des Portfolios ergänzen sich teilweise, können aber auch alternativ eingesetzt werden, so dass in einem Projekt eine Bandbreite an Auswahlmöglichkeiten zur Verfügung steht, die das Management, die Kontrolle und die Durchführung des Projekts betrifft.

Dieses Kapitel untersucht zunächst den aktuellen Stand des Portfolios der Softwaretechnik. In Abschnitt 2.2 wird „Extreme Programming“ (XP) diskutiert und in Abschnitt 2.3 drei essentielle Praktiken daraus vorgestellt. Abschnitt 2.4 beinhaltet einen Vorschlag für eine einfache Methode, die sich als Referenz für die detailliert diskutierten Notationen der UML/P und Techniken dieses Buchs eignet.

In Kapitel 3 folgt eine kompakte Übersicht über das für die vorgeschlagene Methode verwendbare Sprachprofil UML/P der Unified Modeling Language, die die wesentlichsten Eigenschaften des Sprachprofils erläutert und in [Sch12] mit einem geeigneten Werkzeugt unterstützt wird. Das Sprachprofil UML/P ist wie die UML selbst weitgehend methodenunabhängig. Das bedeutet, es ist möglich und sinnvoll, UML/P als Notation in Kombination mit anderen Methoden zu verwenden. Allerdings ist durch den Fokus auf Generierbarkeit von Code und Tests die UML/P besonders gut geeignet für den Einsatz in agilen Methoden.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>