Die Planungsphase

Diese Phase ist von der Softwaretechnik noch nicht so stark formalisiert. Das liegt wohl unter anderem daran, daß hier primär der Kunde seine Wünsche äußert, und dieser keine formalen Methoden kennt bzw. benutzen kann. In der Planungsphase wird also der Produzent vom Kunden angesprochen und muß dessen prosaisch geäußerten Absichten zunächst konkretisieren.

Die Wirtschaflichkeitsanalyse

Zunächst muß versucht werden, den Aufwand und die Kosten für die Erstellung des neuen Produkts zu berechnen. Ein Möglichkeit dazu ist die Schätzmethode: Übliche Kostenmaße sind hier

Lines of Code (LOC): Die geschätzte Anzahl von notwendigen Programmzeilen (eine Anweisung pro Zeile)
(Diese Angabe ist eng mit prozeduralen Sprachen korreliert. Möglicherweise wären zukünftig abstraktere Maße, zum Beispiel Anzahl der neuen Klassen und Spezialisierungen oder die Größe des ObjectCodes - besser.)
Mannjahre (auch Personalmonate, Mannstunden etc.): Die geschätzte (bzw. aufgewendete) Arbeitszeit.
Wenn also 2000 Programmierer bei MS 10 Minuten vor dem Mittagessen noch schnell ein Programm hacken, ergeben sich 2000*10 PersonalMinuten = 20000/(60*8) PersonalTage = fast zwei MannMonate.
Man rechnet 9-10 MannMonate pro Jahr, um Krankheits-. und Urlaubszeiten abzudecken.

Für die Schätzung beider Kostenmaße braucht man im wesentlichen Erfahrungswerte, die mit bekannten Methoden (Balzert, 64ff) zu noch besserer Abschätzung herangezogen werden können.

Beispiel:: Bei einer Produktivitätsrate von 3500 LOC pro Mitarbeiter pro Jahr braucht eine 2-Mann Firma für ein 21000-LOC-Projekt 3 Jahre.

Meist ist die Gesamtproduktivität einer Firma beschränkt, man kann deshalb den Zusammenhang zwischen Produktivität, Qualität (Fehlerfreiheit, gutes Design etc.), Quantität (Programmgröße), Entwicklungsdauer und Entwicklungskosten gut graphisch (Teufelsquadrat nach Sneed87) darstellen. Für Mathematiker vermutlich besser handhabbar ist die Darstellung als Formel (die sich auch nach den Kosten auflösen läßt):

Qualität * Quantität
	=	Produktivität
Entwicklungsdauer * Kosten

bzw.

Qualität * Quantität
	=	Kosten
Entwicklungsdauer * Produktivität

Es ist sehr schwer, die Produktivität linear zu erhöhen, da bei mehr Mitarbeitern auch der Kommunikationsaufwand steigt. Es gibt für optimale Entwicklungsdauer und optimale Projektgruppengrößen auch Faustformeln.

Beispiel:: Vor einigen Semestern wurde als Produkt ein Scrabble-Spiel erwartet, bei dem ein möglicher Spieler der Computer sein sollte. Dabei wurde die Produktivität der Arbeitsgruppen zu hoch geschätzt, so daß die Produktionsdauer auf ein Jahr anstieg.

Eine ganz andere Schätzmethode ist die Function-Point-Methode, in der einzelnen Kategorien der Aufgabe Schwierigkeitspunkte vergeben werden, diese werden aufsummiert und das Ergebnis wieder mit einer Erfahrungskurve verglichen. Wir können hier leider nicht näher darauf eingehen.
Bezahlt der Kunde (bzw. der Markt) die Kosten bei der erwarteten Entwicklungsdauer, lohnt sich die Produktion, und das Lastenheft kann entworfen werden. Die Analyseergebnisse können dann als ein Ergebnis der Planungsphase der internen (Zeit-)Kontrolle bei der Produktentwicklung dienen.

Das Lastenheft

Im Lastenheft werden die diffusen Erwartungen des Kunden mit den konkreten Leistungen der Softwarefirma verknüpft. Es ist das erste Dokument in der Produktenwicklung, und auch das erste Dokument, was die Leistungen des neuen Produktes beschreibt. (Manche Autoren verzichten auf das Lastenheft und gehen gleich zum wesentlich komplexeren Pflichtenheft über. Das Lastenheft kann aber sehr sinnvoll als 'grobes Pflichtenheft' dienen, und ist in der Kommunikation mit dem Kunden zunächst besser geeignet.)

Ein Lastenheft läßt sich durch folgende Schlagworte beschreiben:

Adressaten:: Kunde und Softwareproduzent
Aufgabe: Beschreibt die fachlichen Basisanforderungen an der Produkt aus Sicht des Auftraggebers
Inhalt: Beschrieben wird was geleistet werden soll, nicht wie die Leistung entsteht.
Form: Die Form folgt einer (standardisierten) Gliederung. Die Aufgaben werden verbal beschrieben. Die Einzelleistungen werden für spätere Bezüge sauber numeriert.
Umfang: Wenige Seiten

Ein mögliches Lastenheftgliederungsschema ist:

1. Zielbestimmung: Was soll durch den Einsatz des Produktes erreicht werden?
2. Einsatz: Wer sind die Zielgruppen, was die Anwendungsbereiche?
3. Funktionen: Die erwarteten Kernfunktionen werden aus Kundensicht beschrieben.
Jede Einzelfunktion bekommt einen Gliederungspunkt, wobei wir bei der Gliederungsnummerierung wie im Balzert verfahren: Jede Funktion bekommt eine Nummern /LFnn/, wobei nn eine Zahl ist. Hochgezählt wird in Zehnerschritten, um ggf. später noch Funktionen einfügen zu können. Beispiel:
/LF10/ WWW-Formular bereitstellen. auf dem Formular muß ...
/LF20/ Anfragen beantworten, und zwar ...
4. Daten: Permanent zu speichernde Haupt-Produktdaten werden festgelegt. Nummerierung der Einzelpunkte wie oben: /LD10/ ...
5. (Zusatz-)Leistungen: Zu den o.g. Produktfunktionen werden ggf. weitere Rahmenbedingungen gesetzt. z.B. max. Ausführungsdauer, mindestens mögliche Datenmenge, Ergebnisgenauigkeit, etc. auch ier wird ggf. numerriert: /LL10/ ...
6. Qualitätsanforderungen: Falls über den üblichen Rahmen hinausgehede Qualitätsanforderungen erfüllt werden sollen (z.B. für Buchungssysteme, Kernkraftanlagen), sollten diese hier niedergelegt werden.
7. Ergänzungen: Außergewöhnliche Ergänzungen und Anforderungen, z.B. zusätzliches Interface für Bedienung durch Blinde etc.

Wenn man sich für die Produktentwicklung entschieden hat, ist das Lastenheft das hauptsächliche Ergebnis der Planungsphase.

Beispiel:: Ein Lastenheft zur Seminarorganisation

Beispiel:: Ein Lastenheft eines Praktikums der Uni Hannover zur Medienverwaltung und eines für einen Email-Client.

Beispiel:: Ein Lastenheft der Uni Dresden nach einem anderen Schema, zur Auftragsabwicklung (Fertigung und Handel)

[vorige Seite] [nächste Seite] [Inhalt] [Literatur] [Stichworte]

Dietmar Lammers

Last modified: Tue Apr 6 13:25:15 MET DST 1999