 | Die Definitionsphase |
Erinnerung zur Einstufung der Definitionsphase:
| Planungsphase |
Produkt planen |
Lastenheft |
| Definitionsphase |
"echte" Produktdefinition |
Pflichtenheft, Produktmodell, GUI-Modell, ggf. Handbuch |
Das Lastenheft hat das neue Produkt aus Sicht des Kunden
bzw. Anwenders beschrieben. Diese rein verbale, grobe
Beschreibung kann unvollständig und widersprüchlich sein.
Eine Aufgabe der Definitionsphase ist, aus diesen Angaben
vollständige, konsistente, eindeutige und durchführbare
Produktanforderungen zu formulieren und im Pflichtenheft
darzulegen. Entsprechend zur Spezifikation der Anforderungen
im Pflichenheft wird ein Produktmodell entwickelt, ein
UserInterface-Konzept und ein Handbuch erstellt. Zusammen
bilden sie das Ergebnis der Definionsphase. Sie werden meist
gleichzeitig nebeneinander erstellt, da sie sich gegenseitig
beeinflussen.
Die Definitionsphase nimmt bei der
Produktentwicklung vermutlich den breitesten Raum ein, es gibt
sogar ein Berufsbild, den Systemanalytiker, der
nur diese Phase umsetzt, d.h. mit Mitteln der Analyse eine
hinreichende Produktdefinition erarbeitet.
Die Systemanalyse
(engl. requirements engineering) ist ein in
wiederholten Schritten (iterativ)
verlaufender Prozeß: der Systemanalytiker formuliert mit Hilfe
der Methoden Fragen an den Kunden/Benutzer, dieser
konkretisiert seine Vorstellung des Produktes mit den
Antworten, diese führen zu neuen Fragen etc.
Grundsätzlich werden die Anforderungen nun nicht mehr nur aus
Sicht des Anwenders beschrieben. Es wird in notwendige und
wünschenswerte Ziele unterschieden. Entwicklungs- und
Zielumgebung müssen festgelegt werden.
Die sich aus der Analyse ergebende
Produktdefinition muß einige Qualitätskriterien erfüllen:
- Vollständigkeit
-
Stellt das Produkt selbst alle Features bereit, die nötig
sind, um die Ziele zu verwirklichen?
- Beispiel:
- Ein spezialisierter Maskeneditor muß die
eingegebenen Daten auch speichern und dann wiederherstellen können.
- Konsistenz
-
Sind die Anforderungen widerspruchsfrei?
- Beispiel:
- Ein interaktives System darf nicht von
Antworten abhängen, deren Berechnung mehrere Stunden benötigt.
- Eindeutigkeit
-
Verbal eindeutge Anforderungsbeschreibungen zu erreichen ist
sehr schwer. Ohne formale Methoden ist das oft ein Problem
der Anwälte, die Beschreibungen sollten also im juristischen
Sinne eindeutig sein.
- Durchführbarkeit
- (produktabhängig)
Wenn die Anforderungen nicht erfüllbar sind, machen sie
keinen Sinn. Es kann aber ganz subtile Teilanforderungen
geben, die nicht gehen.
- Beispiel:
- Ein System soll die Meßdaten aus einer
Hochtemperaturmessung verarbeiten und auswerten. Wenn es
keine Meßfühler gibt, die in der Umgebungstemperatur die
Daten in der erwarteten Geschwindigkeit anliefern, kann das
beste Programm kaum etwas machen.
Bei allen Qualitätsanforderungen, besonders aber bei der
Durchführbarkeitsstudie, ist oft die Entwicklung einer
Simulation oder eines Prototyps
sehr hilfreich. Es gibt deswegen viele Softwarewerkzeuge, die
rapid prototyping (bzw. einfach
prototyping) unterstützen.
Besonders bei der Entwicklung der Benutzerschnittstelle ist das
relativ einfach und sinnvoll. Eventuell kann auch der Entwurf des
Produktmodells als Ersatz für eien Prototyp als Analysehilfsmittel
herangezogen werden, dann wird das Produktmodell parallel zum
Pflichtenheft entwickelt.
Erfüllt die Anforderungsdefinition die o.g. Kriterien, kann die
entsprechend formalisiert niedergelegt werden. Es gibt dazu
informale (verbale) und formale Methoden, und wegen der
mangelnden Eindeutigkeit der informalen Methoden ist die
Entwicklung formaler Methoden in diesem Bereich eines der
Hauptziele der Softwaretechnik. Wir betrachten im folgenden
das Pflichenheft und das
Produktmodell genauer.
Das Konzept einer Benutzerschnittstelle kann mit ähnlichen
Methoden wie das Produktmodell beschrieben werden, ggf. kann auch
ein Prototyp erstellt werden. look and feel einer
(graphischen) Benutzeroberfläche werden heutzutage meist von der
im Pflichtenheft festgelegten Einsatzumgebung bestimmt, und
sollten sich auch homogen in das übliche Umfeld des Benutzers
einfügen. Wir können auf das interessante Thema
Software-Ergonomie (Balzert widmet
ihm 5 Lehreinheiten) leider nicht
näher eingehen.
Balzert empfiehlt die Erstellung des Handbuchs bereits in dieser
Phase parallel und iterativ zur Erstellung des
Benutzerinterface-Konzeptes. Mir leuchtet das ein: Im
Pflichtenheft wird die Semantik der Funktion verbal beschrieben,
im Produktmodell ihre Umsetzung modelliert, und im Handbuch die
Bedienung erläutert und damit das Benutzerinterface
beschrieben. Das meiste eines hier erstellten Handbuchs wird in
die Endfassung übernommen werden können. Zumindest die Konzeption
bzw. Gliederung des Handbuchs hängt mit der Konzeption des
Produktes eng zusammen, und sollte hier angesprochen werden.
Man sollte bedenken, das für größere Produke ein online-Manual
und eine online-Hilfe üblich ist. Das Handbuch sollte also so
angelegt sein, daß es ggf. die Funktionen gedruckes Buch,
elektronisches Buch mit Hyperlinks und online-Hilfe gleichzeitig
erfüllen kann. So erspart man sich auch Inkonsistenzen der
Beschreibung. Diese Ansätze gibt es schon lange Zeit ('man'
unter UNIX, texinfo-Handbücher für GNU). Moderne Hilfsmittel
dazu existieren genug, man betrachte nur etwa diesen
(Hyper-)Text als Beispiel. Im Handbuch beschrieben werden
sollten die Produktfunktionen aus dem Pflichtenheft,
Gliederungspunkt 4 (PH.4)
| Übrigens wurden für die Erstellung dieses Textes
xemacs 19.14/20.3 (html/SGML-mode), gnu-make, gnu-m4 und m4-makros des Autors
verwendet, für das Literaturverzeichnis zusätzlich (Bib)TeX und
latex2html, und xfig für das Logo und anderer Abbildungen |
[vorige Seite]
[nächste Seite]
[Inhalt]
[Literatur]
[Stichworte]
Dietmar Lammers
Last modified: Thu Apr 29 09:40:49 MET DST 1999