Klassisch, agil, und dann? – Teil 2 Agile Ansätze im Requirements Engineering

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Diese dreiteilige Beitragsserie gibt einen Überblick zu klassischen und agilen Verfahren des Requirements Engieneering und wirft einen Blick auf zukünftige Herausforderungen. Teil 2 beschäftigt sich mit den heute sehr beliebten agilen Methoden, ihren Techniken, Vor- und Nachteilen.

Aufgrund der Softwarekrise in den sechziger Jahren wurde auf der NATO Konferenz in Garmisch-Partenkirchen der Begriff „Software Engineering“ geprägt. Ziel war, eine ingenieurmäßige Vorgehensweise bei der Entwicklung von Software und Systemen vorzugeben. Ursache dieser Krise war die Tatsache, dass erstmals die Kosten für die Software die Kosten der Hardware überstiegen. Ausschlaggebend hierfür waren verzögerte Fertigstellungen, unbefriedigende Resultate oder extreme Kostenüberschreitungen. Die Entwickler unterschätzten teils die sehr komplexen Projekte oder waren damit überfordert.

Im Zuge dieser Reform wurden zahlreiche Vorgehensweisen entwickelt. Diese wurden immer aufwendiger und komplexer und lenkten den Fokus mehr auf den Entwicklungsprozess an sich, weniger auf das zu entwickelnde System. Teils führte dies regelrecht zu Verdruss bei den Entwicklern.

Bildergalerie

Durch provozierende Aussagen zu Extreme Programming, kurz XP, prägten Kent Beck und Ward Cunningham ein anderes Leitbild für Softwareentwicklung, welches 17 Experten 2001 in Utah konkretisierten. Dieses Idealbild, welches nach heftigen Diskussionen der anwesenden Softwareentwickler und Methodenforscher festgelegt wurde, wird als Manifest der agilen Softwareentwicklung bezeichnet.

Diese agile Bewegung ist keine Gegenbewegung, vielmehr soll das Gleichgewicht wiederhergestellt werden. So wird die Dokumentation durchaus befürwortet, aber nicht um Unmengen Papier zu produzieren, das nie gepflegt wird und selten Verwendung findet. So sollen in einem turbulenten Umfeld die Grenzen der Planung erkannt werden. Im Manifesto heißt es wörtlich übersetzt „Wir entdecken bessere Wege zur Entwicklung von Software, indem wir Software entwickeln und anderen bei der Entwicklung helfen…“ (Fowler und Highsmith, 2001)

Tabelle 1 illustriert die Prioritäten des agilen Manifests. In jeder Zeile gibt das erste Segment eine Präferenz wieder, während das zweite Segment zwar wichtig ist, aber eine niedrigere Priorität genießt. So wird die Bedeutung von Prozessen und Werkzeugen anerkannt, aber das Zusammenspiel der beteiligten Akteure hat eine größere Bedeutung. Eine umfangreiche Dokumentation ist ebenfalls notwendig, das Hauptaugenmerkt sollte aber nicht auf der Dokumentation sondern der lauffähigen Software sein.

So sollte jedes Projektteam selbst entscheiden, welche Unterlagen zwingend erforderlich sind, und welche nicht. Verträge liefern die notwendigen Rahmenbedingen für eine erfolgreiche Zusammenarbeit. Aber nur durch den regelmäßigen Austausch kann das Verständnis des Projektteams für das zu entwickelnde Produkt entstehen und somit auch das gewünscht Resultat, die benötigte Software, entstehen. Zum Zeitpunkt der Erstellung eines Plans kann aufgrund der turbulenten Welt der Wirtschaft und Technik niemand abschätzen, ob das geplante Vorgehen so korrekt ist. Daher kann ein striktes befolgen dessen fatale Folgen haben.

(ID:42704398)