Use Cases werden in der Software-Entwicklung bereits seit 25 Jahren als Mittel zur Darstellung der funktionalen Anforderungen verwendet. Nicht zuletzt als Bestandteil der Unified Modeling Language (UML) haben sie eine recht hohe Verbreitung gefunden. Insbesondere im Zusammenhang mit agilen Methoden erfuhren die Use Cases in den letzten Jahren einige Kritik, da bei dieser Methode häufig schon recht detaillierte Abläufe im Voraus erarbeitet werden. Agile Entwickler arbeiten daher gerne mit User Stories, die sich eher auf die Ziele des Benutzers konzentrieren als bereits frühzeitig Bedienungsdetails festzulegen. Die vorliegende Studie untersucht den Einsatz von Use Cases in der Praxis. Ein verlässliches Bild über die tatsächliche Verbreitung dieser Methodik liefert die Studie nicht, wurde doch ein Großteil der 83 Teilnehmer aus dem Umfeld eines GI-Arbeitskreises mit dem Schwerpunkt Use Cases gewonnen. Daher dürften hauptsächlich Menschen geantwortet haben, die sich sowieso für dieses Thema interessieren. Und so verwundert es nicht, dass über 90% bereits Use Cases einsetzen oder dies planen. Dennoch deutet die Tatsache, dass sich dieses Teilnehmerfeld aus ganz unterschiedlichen Branchen finden ließ, darauf hin, dass Use Cases vielerorts nach wie vor zum festen Methodenrepertoire der Softwareentwicklung gehören.
Use Cases werden erwartungsgemäß vor allem zur Spezifikation der funktionalen Anforderungen auf Anwenderebene verwendet. Eine wichtige Rolle spielen sie für die Kommunikation mit Auftraggebern und im Entwicklungsteam. Als ein wesentlicher Vorteil der Methodik wird die saubere Strukturierung der Anforderungen genannt. Zudem verhelfen Use Cases zu einem gemeinsamen Verständnis der Anforderungen. Doch es gibt auch Herausforderungen. So finden es die Use Case-Anwender schwierig, die geeignete Granularität zu finden und die Vollständigkeit sicherzustellen. Die Aussage, dass Use Cases einen wichtigen Beitrag zum gesamten Projekterfolg leisten, trifft nach Meinung von 76% der Befragten „eher“ oder „voll“ zu.
Da bei etwa der Hälfte der Befragten Software mit agilen Verfahren entwickelt wird, wäre es auch noch interessant zu untersuchen, ob und wie Use Cases auch in der agilen Entwicklung eingesetzt werden, oder ob sich ihr Einsatz auf klassische Verfahren beschränkt.
Hallo Thomas,
das mit den Use Cases und User Stories muss ich hier klarstellen, damit es keine Verwechslungen gibt.
Auch in agilen Projekten wird modelliert. Wir benutzen dort genauso UML und DSLs wie in anderen Projekten auch. User Stories sind kein Ersatz für vernünftige Modelle. User Stories sind eine andere Art Anforderungen zu beschreiben.
Was tatsächlich anders ist, ist, dass wir erst modellieren, wenn wir wissen, dass eine Anforderung auch umgesetzt werden soll. Aus agiler Sicht wäre es Verschwendung, Anforderungen auszuspezifizieren, deren Umsetzung in Frage steht.
Ein weiterer Punkt ist, dass agile Verfahren in Projekten genutzt werden, die hohe Unsicherheit auf Anforderungs- und auf Technologieseite haben. Das bedeutet, dass wir im Voraus gar nicht das endgültige Design oder die endgültigen Anforderungen festlegen können. Daher muss man in diesen Projekten seine Arbeitsweise ändern.
Für Teams gibt es zum Beispiel in Scrum mehrere Punkte, an denen modelliert wird: Beim sog. Backlog-Refinement stellt das Team fest, ob noch Modelle von der Fachseite fehlen. Dann wird z. B. der sog. Product Owner losgeschickt, um die nötigen Details zu holen. Im sog. Sprint Planning, in dem die konkreten Anforderungen für die nächsten 2-4 Wochen geplant werden, sprechen Team jnd PO auch über Modelle und skizzieren auch gemeinsam. Bei der Bearbeitung der einzelnen Stories modellieren die Entwickler vielleicht sogar tiefer aus.
Bei größeren Projekten kann es auch sein, dass Architekten ein Sprint Vorlauf bekommen, und den Teams Modelle für die nächste Sprintplanung liefern. Aber wie schon gesagt: nur wenn auch klar ist, dass die Anforderung dran kommt.
In der agilen Szene gibt es immer wieder Leute, die sich Gedanken machen, wie man Modellierungs- und Dokumentationsanforderungen mit den Anforderungen aus Projekten mit hoher Unsicherheit in Einklang bringt. Ich denke da an Eric Evans und Domain Driven Design, Scott Amblers Agile Modeling oder Andreas Rüping mit Agile Documentation. Es wird auch versucht, viele Teile der Specification in Testform zu beschreiben („executable specification“).
Auch in agilen Kreisen gilt es als unprofessionell, wenn jemand Software und Hardware baut, ohne entsprechende Modelle zu pflegen.
Beste Grüße, Jan
Vielen Dank für den Hinweis, dem ich nur voll zustimmen kann. Das Thema agile Modellierung und Dokumentation sollte in Veröffentlichungen und Kursen zur agilen Entwicklung wesentlich stärker betont werden.