Projektmanagement

Bei der "Use-Case"-Analyse (auf deutsch auch Anwendungsfall-Analyse) wird genau einen Ablauf oder einen Prozess beschrieben. Dabei definiert man eine Interaktion zwischen Akteuren (dargestellt als Strichmännchen) und dem betrachteten System.

Hintergrund ist dabei immer ein beestimmtes fachliches Ziel (plattdeutsch: "business goal") zu erreichen. Die UML2 vermeidet allerdings den Begriff "System" und verwendet stattdessen den Begriff "Subjekt" um zu betonen, dass ein Anwendungsfall das erforderliche Verhalten einer Vielzahl von Modellelementen der UML2 deklarieren kann.

Definition: Ein Use Case beschreibt eine abgeschlossene, ununterbrochene Abfolge von Aktionen eines Akteurs am System mit Ergebnis von fachlichem Wert.

Schwierig ist die Abgrenzung von Anwendungsfällen, vor allem da sie nicht immer an Geschäftprozessen festzmachen sind. Um festzustellen, ob ein Anwendungsfall schon zu komplex ist, wurde von Cockburn der "Kaffeepausen-Test" vorgeschlagen: Ein Anwendungsfall soll so weit gehen, wie ein Nutzer für diesen Anwendungsfall und die notwendige Interaktion keine Kaffeepause einlegen würde.

Ein CASE-Tool für die Darstellung von Use-Case ist Rational Rose, ein Werkzeuge für die Architektur- und Entwurfsmodellierung, die modellorientierte Entwicklung, die architekturbasierte zeiteffiziente Anwendungsentwicklung (Rapid Application Development, RAD) sowie die Durchführung von Komponententests und Laufzeitanalyse.

(aus einer Use-Case-Modellierung mit Rational Rose)

Das Volere-Schema wurde von der Atlantic Systems Guild entwickelt und stelt Hilfsmittel und Materialien um das Thema Anforderungsdefinition im Software Engineering bereit.

"il volere" ist italienisch und bedeutet auf Deutsch soviel wie "wollen", "mögen" aber auch "brauchen".

Am bekanntesten ist dabei sicher die "Snowcard", ein Karteikarten-Formular, mit dem die einzelnen Anforderungen strukturiert und formalisiert für ein Software-Projekt auch in einer Datenbank erfasst werden können.

Der Name Snowcard soll übrigens von dem optischen Eindruck kommen, der ensteht wenn ein Karteikasten mit diesem A6-Kärtchen aus der Hand gleitet...

Jede Anforderung bekommt eine Nummer. Damit kann sie von weiteren Anforderungen referenziert und eindeutig identifiziert werden.

Dazu wird jede Anforderung einem "Requirement Type", also einem Anforderungstyp zugeordnet. [...]

Eine kurze Beschreibung und der Hintergrund dieser Anforderung, also was mit dieser Anforderung beweckt werden soll, sind dann die nächsten beiden Punkte, die erfasst werden.

Die Quelle der Anforderung wird ebenfalls vermerkt, wer hat diese Anforderung haben wollen?

Zusätzlich wird angeben, wie später überprüft werden kann, ob diese Anforderung vom fertigen Produkt erfüllt werden kann. Im idealen Fall kann hier schon ein Test für die Qualitätssicherung spezifiziert werden.

Zwei wichtige Felder sind die Kundenzufriedenheit, wenn das Feature implementiert wurde oder der Grad der Unzufriedenheit, wenn das Feature in der fertigen Software nicht vorhanden ist. Sie werden mit Werten von 1 bis 5 ausgefüllt, dabei stellt 1 relative Emotionslosikeit und 5 extreme Emotionen dar, aber sehr unzufrieden oder auch sehr zufrieden.

Damit kann man die sogenannten "goldenen Türklinken am Rolls-Royce" vermeiden, darunter versteht man Features die einige Benutzer gern hätten, die aber eigentlich gar nicht so wichtig sind.

Schließlich können noch Abhängigkeiten und Konflikte angegeben werden. Abhängigkeiten treten vor allem zu weiteren Anforderungskarten auf und können so mit der Angabe der Anforderungsnummer an dieser Stelle dokumentiert werden "wenn nicht dies, dann aber auch nicht das". Konflikte bedeuten eher "wenn jenes Feature, dann aber dieses Feature nicht".

Jedes Fußballspiel beginnt mit dem Anstoß und jedes Projekt hat auch einen Anfang. Diesen Anfang sollt man klar definieren und er gibt einen guten Startpunkt in der Dokumentation vor.

Ein sogenanntes Kickoff-Meeting hat für fast jedes Projekt stattgefunden, oft ist man sich dessen aber gar nicht so sehr bewusst. Vielleicht war es nur ein kurzes Gespräch in der Pause, vielleicht hat einen der Chef auch zu sich gerufen, aber eins ist sicher: Der Kunde hat hier einen Wunsch geäußert, was er gerne haben möchte.

Dabei werden üblicherweise Notizen angefertigt, denn niemand kann sich alles merken, und hier etwas zu verwechseln oder zu vergessen ist später meist nur noch mit grossen Aufwand (sprich: Kosten) zu korrigieren.

Wenn man vorher weiß, dass ein neuen Projekt angeschoben werden soll, also ein Kickoff-Meeting ansteht, dann sollte man schon mal ein Flipchart bereitstellen wo die Ergebnisse notiert werden können. Das Papier kann man dann später abfotografieren oder zusammenfassen. Alternativ nimmt man ein Notebook mit und schließt es an einen Beamer an, in diesem Fall kann man Programme wie PowerPoint, Visio oder MindManager verwenden (sofern man sie beherrscht).

Schlau ist es an dieser Stelle zu zeigen, was man gelernt hat um ein Brainstorming festzuhalten: Ein Mindmap (mit dem Mindmanager) oder eine erste Use-Case-Analyse (mit einem UML-Tool) sind hier sicher geeignete Werkzeuge. Aber auch ein Lastenheft oder im einfachsten Fall ein paar Anforderungen in einer Notiz sind möglich, vielleicht gabs auch eine E-Mail, die das Projekt ausgelöst hat.

Auf jeden Fall ist es wichtig zu zeigen, wie man an die Wünsche des Kunden gelangt ist! Es muss für die Prüfer nachvollziehbar sein, welche Wünsche zu dem Projekt geführt haben um zu beurteilen, ob daraus vom Prüfling korrekt die richtigen Schritte abgeleitet wurden.

Die Analyse der Wünsche eines Kunden braucht schließlich auch noch Zeit; diese Zeit muss in der Planung wiederzufinden sein und die Kosten dem Projekt zugerechnet werden.