![]() |
Comelio GmbH
|
Software-Technologien > Vorgehen > Use Cases Anforderungsanalyse mit der Use Case-Technik
Anforderungsanalyse mit Use CasesDie Comelio GmbH setzt für die Durchführung von Anwendungsfallanalysen innerhalb der Modellierungs- und Planungsphase von Softwareprojekten die Use Case-Technik ein. Die erstellten Anwendungsfälle (Use Cases) lassen sich im Projektverlauf in vielfältiger Weise nutzen und bieten während des gesamten Projektzeitraums eine umfangreiche Materialsammlung für eine geordnete und anforderungszentrierte Projektarbeit. Die Technik ist rein textbasiert, lässt sich problemlos in das Projektmanagement mit dem V-Modell in seiner jeweils gültigen und aktuellen Fassung integrieren und untermauert die Use Case- und Verhaltensdiagramme der UML mit konkreten Beschreibungen und ausformulierten Transaktionsschritten. Die Use Case-Diagramme erhalten durch sie eine textuelle Basis, welche die Übersichtsdarstellung der UML nicht gewährleistet, während die verschiedenen genutzten Verhaltensdiagramme zwar für die grafische Übersicht von Prozessbeschreibungen nützlich sind, aber nur von UML-Kundigen verstanden werden. Die textbasierten Use Cases dagegen erlauben gerade die Interaktion mit Endanwendern und sonstigen Beteiligten sowie ihre Integration in die Analyse- und Designphase, weil hier kein spezielles Vorwissen für die Lektüre der Texte notwendig ist. Sofern die Anwendungsfälle direkt von den Beteiligten erstellt werden sollen, bieten sie dennoch die Möglichkeit, sich diese Technik mit einer relativ kurzen Einarbeitungszeit zu Eigen zu machen. Geschichte und UrsprungDas Konzept der Use Cases ist bereits sehr alt und stammt ursprünglich aus den späten 60er Jahren und wurde von Ivar Jacobson entwickelt. Erst Ende der 80er Jahre jedoch wurde die Methode als anerkannter Bestandteil in die Anforderungsanalyse für objektorientierte Softwaresysteme übernommen. Die gleichnamigen UML-Diagramme haben grundsätzlich keine Beziehung zu den rein textbasierten Use Cases. Zwar sind Parallelen wie eine Systemgrenze, der Anwender als Akteur oder auch die Möglichkeit, Use Cases zu erweitern und einzubinden, erkennbar, doch bleibt das UML-Diagramm lediglich grafisch und bietet daher ausschließlich eine Übersicht über die einzelnen identifizierten Use Cases einer Software. Durch zusätzliche Diagramme, wobei hier insbesondere die dynamischen zu erwähnen sind, lassen sich dann ähnliche Informationen abbilden wie sie in den textbasierten Use Cases vorhanden sind. Seit 1994 hat sich hauptsächlich Alistair Cockburn für die Verbreitung der Methode in Form von verschiedenen Schriften eingesetzt und gilt heute als führender Vertreter dieser Technik. Definition und AbgrenzungDer Begriff Use Case lässt sich am besten mit dem deutschen Begriff Anwendungsfall übersetzen. Es handelt sich um eine Vereinbarung zwischen den von einem System betroffenen Personen, wobei das sowohl die tatsächlichen Endanwender sein können, die eine besondere Rolle in der Methode spielen, als auch die Organisatoren und Verantwortlichen im Auftragsvergabeprozess oder im Führungsbereich des Softwareprojekts, also der allgemeinen Verwaltung. Ein solcher Use Case ist ein nach einem weitgehend festen Schema verfasster Text (Aufsatz), der durch seine Struktur und seine einfachen Aussagen dazu beiträgt, die Verhaltensweisen eines Softwaresystems unter verschiedenen Bedingungen und im Laufe einer Transaktion oder bei der Bearbeitung von Anfragen darzustellen. Darstellungen mit Hilfe von Diagrammen der UML oder über Petri-Netze und Flussdiagramme können ebenfalls die Transaktionsschritte abbilden, die in den Use Case-Aufsätzen zum Ausdruck kommen, bieten aber nicht immer die Zusatzinformation für Vor- und Nachbedingungen, Trigger oder einzuhaltende Garantien. Ein wesentliches Merkmal der Use Cases ist zudem ihre einfache Erstellungsweise ohne besondere Software und auch ohne eine umfassende Schulung der Autoren oder Leser. So ist es einfach möglich, jede betroffene Person in den Analyse- und Design-Prozess einzubinden und auch Verifizierungsaktivitäten direkt an die Betroffen abzugeben, um möglichst umfangreiche Informationen und Rückmeldungen zu erhalten. BasismethodikEin Use-Case-Aufsatz zeichnet sich insbesondere durch seine klare und einfache Struktur aus, die zu einem leichten Verständnis und einfacher Auseinandersetzung mit den Systemanforderungen führen soll. Folgende Basisstruktur ist für einen Use Case in jedem Fall einzuhalten und erfordert eine schriftliche Fixierung. UmfangDer Umfang (engl. scope) bezeichnet das Ausmaß der Designtätigkeit, für das im Rahmen eines Projekts Verantwortung übernommen wird. Es lässt bewusst alle Designaspekte von bereits existierenden oder von anderen verantwortlichen Einheiten abhängigen Systemen außer Betracht. Dies ermöglicht eine genaue Fokussierung der tatsächlich notwendigen Designaufgaben und ihre Bezüge untereinander. Grundsätzlich ist es relativ einfach, den Umfang eines Systems festzumachen, doch gibt es gerade in der genauen Festlegung der Systemgrenzen im Rahmen von Schnittstellenbetrachtungen, Abhängigkeiten oder Integration / Verwendung von technischen Geräten sowie beliebigen anderen Systemen wie Server, Datenbanken und Dateisystemen Konkretisierungsbedarf. Einige Varianten des Umfangs lassen sich hier unterscheiden:
Primärakteur und StakeholderMit einem Stakeholder wird eine Person verstanden, der an einer Vereinbarung, die ein System zu erfüllen hat, Verantwortung und Anteil hat. Mit dem Begriff Akteur ist dagegen jemand gemeint, der nicht nur allgemein Verantwortung trägt, sondern das System verwendet, Transaktionen aufruft und die verschiedenen Anwenderziele erreichen will. Damit ist der Primärakteur eine Untermenge der Stakeholder. Er ist für die Systemerstellung von herausragender Bedeutung und übertrifft zumeist die restlichen Stakeholder, was sich allerdings im Rahmen der Vertragsstellung und organisatorischen Abwicklung umkehrt. Auch der Auslöser eines Use Cases ist in vielen Fällen dieser Primärakteur, weil sein Anwenderziel im Rahmen seiner Tätigkeit erreicht werden soll. Neben dem Akteur-Begriff lässt sich auch noch der Begriff der Rolle verwenden. Wie auch bei Datenbanksystemen oder anderen Servern besteht die Möglichkeit, dass mehrere konkrete Individuen unterschiedlichen Rollen zugeordnet werden und auch mehrere Rollen nacheinander im Rahmen einer Verwendung des Systems eingenommen werden können. Die Rollen gruppieren die Benutzerarten und ihre Berechtigungen, mit dem System umzugehen. Sie bilden eine Zwischenschicht, die für die Planung von Sicherheitsaspekten und für den Aufbau der grafischen Benutzeroberfläche nützlich ist. In besonderen Fällen kann es auch zu Benennung von Sekundärakteuren oder unterstützenden Akteuren kommen. Die beiden synonym zu verwendenden Begriffe charakterisieren Akteure, die in irgendeiner Weise Informationen übermitteln oder als externe Beteiligte auftreten.
ZielebenenAnwendungsfälle lassen sich durch ihre unterschiedlichen Zielebenen charakterisieren. Diese Einteilung erlaubt es, einem Use Case einen Detaillierungs- und Präzisionsgrad innerhalb des gesamten Systems zuzuordnen. Gleichzeitig haben die verschiedenen Ebenen eine organisatorische und strukturierende Wirkung auf das Datenmaterial, das für die Projektkoordination von Vorteil ist, indem zwischen sehr oberflächlichen, mehr zusammenfassenden Zielen und solchen unterschieden werden kann, die genau eine vollständige Transaktion erfordern. Eine zu detaillierte Darstellung der Ziele auf einer reinen Funktionsebene ist meistens nicht notwendig und in vielen Fällen eher hinderlich, da systemische (Sub-)Funktionen meistens ausdrücklich auf die Implementierung, die genaue Benutzerführung oder den Maskenaufbau verweisen, was im Rahmen der Design- und Analysephase zumeist nicht angestrebt wird.
Folgende Zielebenen lassen sich unterscheiden:
Zusätzliche Use Case-AngabenNeben den erwähnten grundlegenden Inhalten eines Use Case-Aufsatzes lassen sich weitere Angaben machen, deren Auftreten vom jeweiligen Use Case selbst abhängt. Sie lassen sich in wenigen Worten beschreiben.
Nutzen von Use CasesAuf der Ebene der Primärakteure ergeben sich unterschiedliche Vorteile durch den Einsatz der Use Case-Technik:
Der vollständige Nutzen von Use Cases entfaltet sich nicht unmittelbar im Rahmen ihrer Erstellung, d.h. in der Design- und Analysephase, sondern erst zu einem großen Teil während des Projekts. So lassen sich die Unit Tests für eine Verifizierung des Klassenaufbaus zwar grundlegend schon mit den Use Cases planen, doch die eigentliche Umsetzung, Erstellung und natürlich Ausführung der Testläufe gelingt erst nach Erstellung der zu testenden Einheiten. Hier können für die Gestaltung von Testdaten, Fehlerszenarien oder Übergabeparameter die fehlerhaften Eingabedaten erkannt werden, während für den Testabschluss sowohl der Erfolgsfall als auch über die Mindestgarantien der Misserfolgsfall und seine Enddaten getestet werden können. Auch solche Ziele wie Organisation und Durchführung von Mitarbeiterschulungen oder Erstellung von gruppenbezogenen Handbüchern gelingt erst nach Fertigstellung und sogar erst nach Auslieferung der Software. Hierbei helfen allerdings die verschiedenen Use Cases ebenfalls, die man dann nach den verschiedenen Primärakteur-Gruppen und Rollen untersucht. Weiterer Nutzen betrifft nicht wie in verschiedenen oben erwähnten Vorteilen die Datenstrukturen, die geschrieben oder übergeben werden, sondern den Masken-/GUI-Aufbau sowie die Erstellung von Transaktionen und Prozessen mit Hilfe von GUI-orientierter Benutzerführung und natürlich auch entsprechenden Softwaretechniken wie Datenbank-Transaktionen oder Thread-Programmierung. Die Projekt steuernde Komponente von Use Cases entfaltet ihren Nutzen ebenfalls nicht nur zu Projektbeginn, wenn die Aufgaben verteilt werden, sondern ermöglicht auch eine Arbeitskontrolle und fortschreitende Arbeitsvergabe in Form von einzelnen Use Cases oder Use Case-Paketen entlang der gesamten Zeitschiene. Dies setzt eine objektorientierte Umsetzung der Use Case-Aufsätze in ein entsprechendes Klassendiagramm der UML bzw. überhaupt eine objektorientierte Kristallisation der Use Case-Inhalte voraus. Die Projektkoordination und auch das Projektcontrolling kann sich allerdings dennoch der Use Cases bedienen. Der Hauptteil der Use Case-Erstellung sollte natürlich im Vorfeld der Programmierarbeiten fertig gestellt werden und nicht erst im Rahmen des Projekts erfolgen. In Ausnahmenfällen kann dies für Zusatzanforderungen oder vergessene Anforderungen auch während des Projektes geschehen. Dadurch ist zunächst im Rahmen der Design-Arbeiten eine große textuelle Datenmenge zu erstellen. Sie wird allerdings nicht nur als Vorarbeit für die Umsetzung in UML genutzt, sondern dient vielmehr während des Projektes als Datensteinbruch, der immer wieder durchgearbeitet und auf unterschiedliche Informationen hin gesiebt wird.
Umsetzung in Comelio-ProjektenDie Bedeutung von Use Cases wird von der Comelio GmbH als wesentlich für erfolgreiches Projektmanagement verstanden. Sie lassen sich teilweise in agil geführten Projekten durch intensive Kundeneinbeziehung vermeiden. Allerdings hat die Erfahrung gezeigt, dass echtes agiles Vorgehen von vielen Auftraggebern nicht tatsächlich gewollt ist, sondern mehr aus falsch verstandenem Kostenbewusstsein vorgeschlagen wird. Daher bietet die Comelio GmbH nicht nur als Dienstleistung die Erstellung von Anwendungsfallanalysen und entsprechenden Interviews und Texterfassung an, sondern steht auch bereit, um ihren Kunden die Technik in Form einer Schulung / Beratungsveranstaltung zu vermitteln. Dies senkt grundsätzlich die Kosten, da dann die eigenen Mitarbeiter in die Lage versetzt werden, die Anwendungsfälle zu notieren. Insbesondere hier ist die vorgeschlagene Methode hilfreich, weil sie kein besonderes Vorwissen erfordert und auch innerhalb eines Tages vermittelt werden kann und nach einigen Testläufen zu guten Ergebnissen führt. Aus den erstellten Use Case-Aufsätzen können dann in einem iterativen Prozess Prototypen, GUI-Elemente und Masken sowie Transaktionen / Prozesse abgeleitet werden. Sie werden Teil des Projekthandbuchs und des Vertrages und ermöglichen beiden Seiten, einen hohen Grad an Klarheit und Verständnis zu erreichen, was der Umfang der Arbeitsaufgabe ist.
Seminare
|
||