Das UML (Unterrichts-Ministerium des Landes) hat wie lange schon erwartet endlich die Standardisierung der Unterrichtsmaterialien und -methoden beschlossen. Auch wenn die Inhalte bekannt sein sollten, hier noch einmal die Kurzfassung:
Das zukünftige Kernelement ist die Unit of Communication (UC), mit den vorgeschriebenenen Unterelementen Haupt-Stunde (HS) und beliebig vielen Anhangstunden (AS). Die Lerninhalte sind in Einzelaspekte (EA) gegliedert, wobei das Ablaufdiagramm (AD) den Zusammenhang der EA in HS und AS festlegt.
Allseits wurde damit die Eindämmung unterschiedlichster Darstellungsformen und Tafelbilder begrüßt – Lehrern werden mit dem Tool TeachIT die entsprechenden Templates an die Hand gegeben, und Schüler erkennen durch die einheitliche Diagramm-Form die Lerninhalte sofort. Zur Erreichung der Vereinheitlichung ist den Lehrern per Erlass 4711 die Verwendung anderer Diagramme nur in Ausnahmefällen und nur mit Begründung gegenüber dem UML erlaubt. Die Schulbuchverlage wurden informiert, dass ab 2014 nur noch standardkonforme Bücher für den Unterricht zugelassen werden, und die Verlage sagten zu, bis dahin die bislang unterschiedlichsten Bildquellen in ihren Schulbüchern gemäß UML-Standard zu vereinheitlichen.
Hand auf’s Herz – möchten Sie, dass das Lernumfeld Ihrer Kinder wie beschrieben gestaltet wird? Ich persönlich hänge an den unterschiedlichsten Bild- und Darstellungsformen – in der Physik anders als in der Grammatik, und in Biologie mit Skizzen der Tiere oder Organe. Manche Inhalte wurden mir erst über Beispiele und dann über das generelle Prinzip vermittelt, andere beginnend mit einer theoretischen Herleitung mit anschließender Betrachtung der Praxis oder Anwendung.
Aber – was hat das alles mit Use Cases (UC), Haupt- und Alternativ-Szenarien (HS, AS), Einzelanforderungen (EA) und Aktivitätsdiagrammen (AD) zu tun? Sie werden die Parallelen in der Einleitung sofort erkannt haben. In meinen Augen ist das erste Ziel des Requirements-Engineering ein tiefes Verständnis, ähnlich wie im Unterricht. Ein Business Analyst beschreibt sein Verständnis des Zielsystems, und viele Projektmitarbeiter müssen daraus das gleiche Verständnis entwickeln:
- Der auftraggebende Fachbereich – wenn er nicht detailliert versteht, was beschrieben ist, wird das System nicht gesichert den Wünschen des Fachbereichs entsprechen, und kostentreibende Change Requests sind die Folge.
- Die Entwicklungsabteilung – auch hier ist der erste Schritt nicht ein Design, sondern ein detailliertes Verständnis des Geforderten.
- Die Tester – man kann immer leicht testen, ob z.B. ein Feld wie beschrieben mandatory ist, aber end-to-end Testfälle für Geschäftsprozesse erfordern im Kopf des Testers ein mentales Bild des Zusammenspiels von sehr vielen Einzelanforderungen unterschiedlichster Use Cases.
- Last but not least: Projektmanagement und andere Projektbeteiligte – irgendwann (meist erst zu Ende der Testphase) liegen Bug Reports zur Entscheidung an, bei denen i.W. deutlich wurde, dass Fachbereich, Development und Tester einfach ein anderes Verständnis aus der Requirements Beschreibung abgeleitet haben; diese Klärungen sind meist die unangenehmsten im Projektverlauf.
Ich möchte hier nicht falsch verstanden werden: ich verstehe durchaus die Verlockungen und auch die unbestreitbaren Vorteile eines standardisierten Requirements-Templates. Man kann wesentlich leichter mit Requirements-Management-Tools arbeiten, Fortschritts-Reports sind leichter zu erstellen (ich bin mir aber nicht sicher, ob sie dann die Realität korrekt darstellen), und die zuständige Projekteinheit ist „auf der sicheren Seite“ (typischerweise nach einem eher weniger mitreißenden Vormittag zur Darstellung der verwendeten Templates und Tools).
Trotzdem: ich habe in den unterschiedlichsten Projekten zu viele Unfälle gesehen, in denen bei einer oder mehreren Projekteinheiten gerade nicht das korrekte Verständnis erzielt wurde (und auch durchaus genug Fälle, in denen aus der UC/HS/AS/EA/AD-Lage auch kein wirkliches Verständnis abgeleitet werden konnte).
Es klingt redundant, aufwandstreibend, nicht gradlinig genug, aber gerade größere Projekte brauchen nach meiner Überzeugung je Themen-Komplex erst eine Freestyle-Phase. In dieser wählen der Fachbereich und die Business-Analysten die jeweils zum Komplex passende Darstellungsform und erstellen darin eine Dokumentation. Dies können Zustandsübergänge, Prozessabläufe oder eine neue Darstellungsform sein – häufig auch mit den Mitteln, die wir aus dem Unterricht kennen, also Piktogrammen und ähnlichem. Wichtig ist, dass diese Darstellung das Maß der Dinge bleibt, d.h. wenn (verständlicherweise) in Folgeschritten zu standardisierten Darstellungsformen gegriffen wird, muss dies immer wieder mit der iniital erstellten Kerndarstellung abgeglichen werden und diese bei Bedarf angepasst werden. So wird sichergestellt, dass eine neu hinzukommende Person in die Lage versetzt wird, hieraus das vertiefte Verständnis zu erlangen. Insofern ist es m.E. verpflichtend, dass das Resultat einer solchen Freestyle-Phase nicht weggelegt wird als das war mal die Einleitung, sondern integraler Bestandteil der Artefakte des Requirements Engineerings bleibt. Nach meiner persönlichen Meinung kann sie sogar hier und da dann viele standardisierte Elemente ersetzen.
Insofern: Nicht für die Schule, sondern für das (Projekt-) Leben sollten wir doch damals lernen!
Noch ein ketzerischer Gedanke zum Schluss: häufig wird man den Einwand hören „aber das große Bild ist doch so komplex – das hat im Moment doch niemand im Kopf, so dass man es erstellen könnte“. Ist dies nicht, wenn man genau genug hinschaut, das klare Eingeständnis, dass man sich in diesem Projekt einfach zu viel für ein (leider sehr häufig gewähltes) Wasserfall-artiges Vorgehen vorgenommen hat, und dass man eigentlich gar nicht an iterativen, ggfs. agilen Vorgehensweisen für dieses Projekt vorbeikommt? Wenn man diese Vorwarnzeichen ignoriert und sich in UC, EA, … vergräbt, besteht m.E. die große Gefahr, dass man am Ende auch mit der typischen Termintreue und Anforderungstreue eines Wasserfallprojektes konfrontiert wird.