Das Pflichtenheft dokumentiert, welche Aufgaben zu lösen sind. Die Spezifiktion beschreibt Lösungsansätze. Die Aufgabenstellung ist zwar schon in der Projektbeschreibung spezifiziert; Sie werden aber schnell feststellen, daß diese Spezifikation noch eine Reihe von Fragen offenläßt.
Das Pflichtenheft soll Antworten auf die folgenden Fragen geben:
Welche Funktion realisiert das Programm?
Im Prinzip also die Aufgabenstellung. Oft ist aber die Aufgabenbeschreibung noch konkretisiserungsbedürftig. Die Punkte, wo eine genauere Spezifikation nötig ist, sind hier aufzulisten. Die in Absprache mit dem Betreuer getroffenen Entscheidungen sind hier zu dokumentieren.
Behandlung von Fehlerfällen
Wie verhält sich das Programm bei auftretenden Fehlern wie z.B. ungültige Eingabe, Zahlbereichsüberschreitung, Division durch Null? Soweit die Projektspezifikation nichts nähers festlegt, müssen die Fehlersituationen behandelt werden, die mit vertretbarem Aufwand abgefangen werden können. Z.B. sollte ein Unterprogramm einen Parameter, durch den dividiert wird, auf Null prüfen, ebenso eine Zeigervariable (Pointer) auf NULL. Im Zweifelsfall klären Sie den Umfang der nötigen Fehlerbehandlung mit Ihrem Betreuer
Wie verwendet man das Programm?
Beschreibung der Aufruf- bzw. Benutzerschnittstelle im Stil eines Benutzerhandbuches.
Festlegung der formalen Verantwortlichkeiten
Zu jedem dieser Punkte ist ein verantwortliches Gruppenmitglied zu benennen.
Das Projekt wird unterteilt in Arbeitspakete, für die Verantwortlichkeiten festgelegt werden. Es ist auch die Abhängigkeit der Pakete voneinander zu dokumentieren (z.B.: "Implementierung von Modul B kann erst begonnen werden, wenn Schnittstelle von Modul A definiert ist"). Der Zeitplan soll Termine für die Fertigstellung einzelner Arbeitspakete festlegen und den Aufwand für ihre Realisierung in Personen-Stunden abschätzen. Beispiel:
| Arbeitspaket | Verantwortliche | Aufwand (P.-Std.) | Termin |
|---|---|---|---|
| Definition der Schnittstelle von Modul A | Meier, Müller | 1.5 | 1. April 1999 |
| ... | ... | ... | ... |
| Implementierung Modul B | Huber | 3 | 7. April 1999 |
| ... | ... | ... | ... |
| Erstellung der Ausarbeitung | Huber, Meier, Müller | 2 | 10. April 1999 |
| ... | ... | ... | ... |
Aufgrund der Erfahrungen der vergangenen Semester möchte ich noch folgende Punkte erwähnen:
Eine Einteilung der Form
Die Einheit des Aufwandes ist die Arbeitszeit in Personen-Stunden (so wie die Arbeitszeit auch auf Handwerker- oder Werkstattrechnungen aufgelistet ist). Angaben der Form "3 Tage" sind als Aufwandsschätzung ungeeignet, da nicht ersichtlich ist ob drei Leute drei Tage lang je acht Stunden arbeiten oder eine Person jeden Tag 10 Minuten.
Einen Anhaltspunkt für den Gesamtaufwand liefert folgende Rechnung:
Daraus ergibt sich der zu erwartende ungefähre Gesamtaufwand pro Projekt als 4*12*3/2=72 Personen-Stunden. Der tatsächliche Aufwand ist natürlich von Projekt zu Projekt unterschiedlich. Wenn Sie aber auf weniger als 30 oder mehr als 150 Personenstunden kommen, sollten Sie Ihre Abschätzung und ggf. auch Ihre Spezifikation noch mal intensiv durchsehen.
Die Spezifiktation beinhaltet folgende Punkte:
Wie könnte man es machen? Wie machen Sie es und warum gerade so?
Für die meisten Projekte gibt es viele denkbare Lösungsansätze. Die Spezifikation soll darlegen, welche Möglichkeiten Sie erwogen haben, und warum Sie sich für die gewählte Alternative entschieden haben.
Es gibt auch Projekte, wo keine große Auswahl an Lösungsansätzen besteht. Hier brauchen Sie auch nicht krampfhaft nach einer Alternative suchen. Sie sollten aber dann erwähnen, daß (und warum) es hier keine vernünftigen Alternativen gibt.
Beschreibung des gewählten Lösungsansatzes
Beschreiben Sie Ihren Lösungsansatz verbal. Meist eignet sich als Ergänzung eine pseudo-code-artige Darstellung des Algorithmus.
Wie soll das Programm getestet werden?
Festelegung der Testumgebung, z.B. Rahmenprogramm, das das zu testende Unterprogramm aufruft. Definition von Testdatensätzen, die möglichst alle denkbaren Fälle abdecken.