B. Rumpe: Agile Modellierung mit UML

<< zurück

weiter >>

2.1 Das Portfolio der Softwaretechnik

In [AMB⁺04, BDA⁺99] wurde ein Anlauf unternommen, das mittlerweile seit über 40 Jahren gewachsene Wissen der Softwaretechnik in einem „Software Engineering Body of Knowledge“ (SWEBOK) zusammenzufassen. Dabei werden Begriffsbildungen vereinheitlicht, die wesentlichen Kernelemente der Softwaretechnik als Ingenieursdisziplin dargestellt und insbesondere versucht, einen allgemein akzeptierten Konsens über die Inhalte und Konzepte der Softwaretechnik herzustellen.

Ein für unsere Überlegungen wesentlicher Teil der für Softwareentwicklungsprozesse verwendeten Terminologie ist in Abbildung 2.1 dargestellt.

Vorgehensmethode: Eine Vorgehensmethode (syn. Vorgehensmodell) beschreibt das Vorgehen „für die Abwicklung der Softwareerstellung in einem Projekt“ [Pae00]. Es kann zwischen technischem, sozialem und organisatorischem Vorgehensmodell unterschieden werden.
Softwareentwicklungsprozess: Der Begriff Softwareentwicklungsprozess wird gelegentlich als Synonym zu „Vorgehensmethode“ verwendet, oft aber als detailliertere Form verstanden. So definiert [Som10] einen Prozess als Menge von Aktivitäten und Ergebnissen, mit denen ein Softwareprodukt erstellt wird. Meist werden auch die zeitliche Reihenfolge oder die Abhängigkeiten der Aktivitäten herausgestellt.
Entwicklungsaufgabe: Ein Prozess wird in eine Reihe von Entwicklungsaufgaben unterteilt, die jeweils bestimmte Ergebnisse in Form von Artefakten erbringen. Die Projektbeteiligten führen Aktivitäten aus, um diese Aufgaben zu erledigen.
Prinzip: „Prinzipien sind Grundsätze, die man seinem Handeln zugrunde legt. Prinzipien sind allgemein gültig, abstrakt, allgemeinster Art. Sie bilden eine theoretische Grundlage. Prinzipien werden aus der Erfahrung und der Erkenntnis hergeleitet […].“ [Bal00]
Best Practices: beschreiben erfolgreich erprobte Entwicklungspraktiken in Entwicklungsprozessen. Eine Entwicklungspraktik kann als konkretes, operationalisiertes Prozessmuster aufgefasst werden, das ein allgemeines Prinzip umsetzt (vgl. RUP [Kru03] oder XP [Bec04]).
Artefakt: Entwicklungsergebnisse werden in einer konkreten Notation dargestellt. Dafür werden zum Beispiel die natürliche Sprache, UML oder eine Programmiersprache verwendet. Die Dokumente dieser Sprachen werden Artefakte genannt. Dies sind beispielsweise Anforderungsanalysen, Modelle, Code, Reviewergebnisse oder ein Glossar. Ein Artefakt kann hierarchisch gegliedert sein.
Transformation: Als Transformation kann die Entwicklung eines neuen Artefakts oder einer verbesserten Version eines gegebenen Artefakts verstanden werden, die automatisiert oder manuell erfolgen kann. Letztendlich können fast alle Aktivitäten als Transformationen der im Projekt gegebenen Menge von Artefakten verstanden werden.

Abbildung 2.1: Begriffsdefinitionen im Softwareentwicklungsprozess

Aus der in den letzten Jahren gesammelten Erfahrung bei der Durchführung von Softwareentwicklungsprojekten kristallisiert sich heraus, dass es den Prozess für Softwareentwicklung nicht geben kann. Es scheint heute noch nicht einmal möglich, ein einigermaßen aussagekräftiges Prozessframework angeben zu können, das für die nach Wichtigkeit, Größe, Anwendungsbereich und Projektumfeld sehr unterschiedlichen Softwareentwicklungsprojekte Allgemeingültigkeit besitzt. Stattdessen ist man dabei, eine Sammlung an Konzepten, Best Practices und Werkzeugen aufzustellen, die es erlaubt, projektspezifischen Erfordernissen in einem individuellen Prozess Rechnung zu tragen. Dabei werden Detaillierungsgrade und Präzision der Dokumente, Meilensteine und die abzuliefernden Ergebnisse in Abhängigkeit von der Größe des Projekts und der gewünschten Qualität des Ergebnisses festgelegt. Vorhandene, als Muster zu verstehende Prozessbeschreibungen können dabei Hilfestellung geben. Jedoch werden projektspezifische Anpassungen als grundsätzlich notwendig erachtet. Für Projektbeteiligte ist es daher sinnvoll, möglichst viele Vorgehensweisen aus dem derzeit vorhandenen Portfolio zu kennen.

War in den 90’er Jahren ein starker Trend hin zu vollständigen und dadurch eher bürokratischen Softwareentwicklungsprozessen zu beobachten, so haben sich die agilen Methoden in den 2000’er Jahren von diesem Trend abgekoppelt. Ermöglicht haben diese Umkehr das deutlich gewachsene Verständnis der Aufgaben bei der Entwicklung komplexer Softwaresysteme sowie die Verfügbarkeit verbesserter Programmiersprachen, Compiler und einer Reihe von weiteren Entwicklungswerkzeugen. So ist es heute nahezu genauso effizient eine GUI direkt zu implementieren, wie sie zu spezifizieren. Entsprechend kann die Spezifikation durch einen für den Anwender ausprobierbaren und in der Realisierung weiterverwendbaren Prototyp ersetzt werden. Der Trend zur Reduzierbarkeit der notwendigen Entwicklerkapazitäten wird dadurch verstärkt, dass bei weniger Projektbeteiligten auch weniger organisatorischer Overhead notwendig ist und damit die Personalaufwände weiter reduziert werden können.

Auch die mit agilen Methoden verstärkte Betonung der individuellen Fähigkeiten und Bedürfnisse der am Projekt beteiligten Entwickler und Kunden erlaubt die weitere Reduktion von Projektbürokratie zugunsten verstärkter Eigenverantwortung. Diese Teamorientierung kann auch in anderen Bereichen des Wirtschaftslebens, wie zum Beispiel bei flachen Management-Hierarchien, beobachtet werden und basiert auf der Annahme, dass mündige und motivierte Projektbeteiligte von sich aus verantwortungsvoll und couragiert handeln werden, wenn durch das Projektumfeld die Möglichkeiten dafür geschaffen werden.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>