Analyse

Illustration Analyse Die Analyse dient der genauen Aufgabenklärung vor Beginn der eigentlichen Software-Entwicklung. Bei der Aufgabenklärung werden Anforderungen und Ziele aus unterschiedlichen Blickwinkeln heraus dokumentiert. Welche Methode konkret angewendet wird (typischerweise die UML) und welche Dokumente und Diagramme im Rahmen einer Methode verwendet werden ist dabei weniger entscheidend. Viel wichtiger sind ihre Präzision und Vollständigkeit, denn nur unmissverständliche und verbindliche Dokumente erfüllen ihren Zweck als Grundlage für die Realisierungsschritte in einem Projekt. Die nachfolgend kurz beschriebenen Dokumenttypen haben sich in der Praxis bewährt und sollten in keinem Projekt fehlen.

Das Lastenheft

... beschreibt das Projekt aus der Sicht der Anforderungen der Anwender und vor allem in deren Sprache: Was soll die Software leisten, welche Probleme soll sie lösen. Hierbei erfolgt jedoch idealerweise keinerlei Vorgriff auf die konkrete Realisierung.

Das Pflichtenheft

... beschreibt technische Festlegungen, die aufgrund der im Lastenheft genannten Ziele und Vorgaben benötigt werden - angefangen von der Festlegung auf Betriebssystem(e) und Programmiersprache(n) über die Auslegung der Server und Organisation der Software bis hin zum detaillierten Aufbau von Bildschirmdialogen, Datenbanktabellen und benötigten Schnittstellen. Bei einem prototypisch orientierten Vorgehen kann und sollte der Detaillierungsgrad ganz zu Anfang allerdings eher grob sein, hier werden die Vorgaben zyklisch Hand in Hand mit der laufenden Entwicklung verfeinert.

Die Analysediagramme

... beschreiben Begriffe und ihre Zusammenhänge aus Entwicklersicht. Die Analyse steht in enger Beziehung zum Lastenheft und muss alle wichtigen Begriffe aus dem Lastenheft in den jeweils zuständigen Analysediagrammen enthalten (OOA / UML), typischerweise im Objektmodell. Auch die von der Anwendung abzudeckenden Anwendungsfälle werden als Use Cases in Diagrammform dokumentiert. Eine gut aufeinander abgestimmte Kombination von Use-Case- und Objektmodell stellt die wichtigste Referenzdokumentation aus Sicht der Software-Entwicklung dar, weil sie besser standardisiert ist als der freie Text in einem Lastenheft. Idealerweise besteht das Lastenheft zum größten Teil aus den genannten Modellen und enthält Freitext nur für schwer formalisierbare Anforderungen. Wenn die Analysedokumente konsistent abgeschlossen sind, können die Entwickler garantieren, dass die Vorgaben aus dem Lastenheft im Sinne des Kunden umsetzbar sind.

Die Prozesse

... strukturieren das Vorgehen. Korrekt aufgebaute Spezifikationen stehen in einem engen Zusammenhang zueinander und entstehen meist parallel. Sie werden iterativ verfeinert, bis sie als abgeschlossen betrachtet werden können. Dieser Prozess ist Teil des gesamten Vorgehens, worin auch die Bewertung des Status und der Qualität der Dokumente eingeschlossen ist.

Auch das iterative Vorgehen sollte strukturiert werden, z.B. in Form des weit verbreiteten "Rational Unified Process" (RUP). Hierbei wird berücksichtigt, dass zu Beginn eines Projekts die Anforderungen oft noch nicht hinreichend genau bekannt sind und es daher ein großes Risiko wäre, frühzeitig eine verbindliche Planung für das gesamte Vorhaben aufzustellen. Immer mehr Kunden erkennen die Vorteile eines prototypischen Vorgehens:

Beim prototypischen Vorgehen wird die Planungssicherheit über das gesamte Projektvolumen bewusst zurückgestellt. Oft genug war diese Sicherheit in der Praxis realer Vorhaben aber ohnehin nur eine scheinbare, weil es auch für engagierte Anwender sehr schwierig ist, ihre Bedürfnisse nur auf Basis theoretischer Vorüberlegungen genau zu beschreiben. Trotzdem können und müssen die entscheidenden Unwägbarkeiten eines Projekts jeweils zum richtigen Zeitpunkt geklärt werden, damit das gesamte Vorhaben steuerbar bleibt. Ein guter Berater erkennt in den Anforderungen des Kunden die entscheidenden Punkte und entwickelt dazu ein Prozessmodell, das exakt auf die vorgefundene Situation zugeschnitten ist.

nach oben