Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.05.1992 - 

Minimierung des Software-Projektrisikos

Bei komplexeren Projekten eine zweigeteilte Spezifikation

In den meisten Phasenmodellen der Software-Entwicklung ist das Ermitteln der an die Software zu stellenden Anforderungen und ihre Formulierung der erste Schritt. Bevor man ein aufwendiges Projekt startet, sollte man sich darüber im klaren sein, was man will. Ist es insbesondere sinnvoll, aus Kosten- oder sonstigen Gründen die Spezifikation in zwei Teile aufzusplitten?

Es gibt durchaus Argumente für das Aufteilen der Spezifikation in zwei Dokumente. Zunächst sind da die unterschiedlichen Interessenslagen von Auftraggeber und Auftragnehmer. Besonders der Auftraggeber eines Software-Projekts sollte differenziert betrachtet werden: Der Benutzer oder User des Programms ist deutlich vom eigentlichen Auftraggeber oder Customer im Jargon der Branche zu unterscheiden. Während bei kleinen Projekten diese Personen oder Gruppen identisch sein können, ist das bei größeren Organisationen kaum je der Fall. Der Endnutzer weiß durchaus, was er will und wie ein Programm für seine Belange beschaffen sein sollte. Hingegen sieht die Stelle einer Organisation, die den Auftrag vergibt, die Software eher unter dem Gesichtspunkt der Problemlösung für den Betrieb. Gehen jedoch die Forderungen des Benutzers nicht in die Spezifikation ein, wird möglicherweise ein Produkt eingekauft, das der Benutzer am Ende der Entwicklungsphase gar nicht akzeptiert. Warum aber die Diskussion über zwei Spezifikationen?

Ganz einfach deswegen, weil Benutzer und Kunde nur eine Seite sehen. Zwar kennt der Kunde vielleicht die funktionellen Anforderungen, wenn sie der Benutzer klar formuliert hat. Doch zu einem Programm gehört oft weit mehr:

- Algorithmen,

- ein Betriebssystem,

- ein Runtime-System,

- Testanforderungen,

- Telemetrie und auch

- ein grobes Ablaufmodell.

Das Problem mit der Dokumentation

Dies sind berechtigte Forderungen, um die der sachverständige Auftragnehmer sicherlich weiß. Dafür müssen Ressourcen bereitgestellt werden. Manchmal geht für solche Dinge die halbe Leistung des Rechners drauf. Trotzdem: Weder der Benutzer noch der Kunde werden sich in der Lage sehen, die Anforderungen zu spezifizieren, schon gar nicht im Detail. Es erscheint daher sinnvoll, daß der Kunde nur seine funktionellen Anforderungen und die Leistung in Form von Eckwerten spezifiziert und den Rest der Spezifikation dem Auftragnehmer überläßt.

Einen nicht zu unterschätzenden Faktor stellen die Kosten dar. Zwar wird der Auftragnehmer in der Regel bereit sein, sich ein Bild über die von ihm erwarteten Leistungen zu verschaffen. Das darf jedoch nicht dazu führen, daß er eine seitenlange und detaillierte Spezifikation umsonst erstellt. Das wäre nicht sinnvoll, denn im Grunde weiß nur der Kunde und Benutzer genau, was für Software er braucht.

Und aus Kostengründen spricht ebenfalls einiges für die

Teilung der Spezifikation: Der Kunde formuliert seine funktionellen Anforderungen, die als Grundlage für ein Angebot dienen. Die detaillierte Spezifikation wird dann vom Auftragnehmer ausgeführt, wobei die Anforderungen des Kunden als Grundlage dienen.

Das Erstellen technischer Dokumente ist nicht ganz einfach. Die Sprache ist oft zweideutig, und gerade Ingenieure sträuben sich manchmal, die Dokumentation anzupacken. Weder beim Auftraggeber noch beim Auftragnehmer werden Spezialisten, die eine gute Spezifikation erstellen können, im Übermaß vorhanden sein. Ein Software-Haus oder eine Systemfirma wird diese Fachleute jedoch noch eher bereitstellen können. Schließlich macht man das dort nicht zum erstenmal.

Das Umsetzen technischer Forderungen in ein Dokument setzt immer voraus, daß man das Wissen der Fachleute umsetzt und in die Spezifikation einfließen läßt. Die notwendige Rückkopplung durch ein "Review" des Dokuments ist unerläßlich, und da ist der Auftragnehmer schon allein auf Grund der räumlichen Nähe der beteiligten Fachleute meist die bessere Wahl.

Die Algorithmen und das System

Wenn es sich nicht gerade um ein sehr einfaches Problem handelt, wird der Software-Entwicklung das Erarbeiten und Formulieren der notwendigen Algorithmen vorausgehen müssen. Das ist um so mehr der Fall, wenn das Software-Projekt in technisches Neuland vorstößt, also zum Beispiel bei Mustererkennung oder bei einer neuartigen Mensch-Maschine-Schnittstelle. Nur der Auftragnehmer wird in der Lage sein, diese Entwicklung voranzutreiben und die Erkenntnisse der Algorithmen-Entwicklung in geeigneter Form in die Spezifikation einfließen zu lassen.

Immer häufiger sind Programme Teil eines größeren Systems, mag es sich um einen Flugkörper oder auch nur um den Toaster mit Digitaluhr handeln. Wenn allerdings die Anforderungen an die Software durch das Herunterbrechen der Systemanforderungen entstehen, kann eigentlich nur der Auftragnehmer die Spezifikation erstellen. Er hat dazu das notwendige Fachwissen und kann "Trade offs" auf Systemebene, zum Beispiel zwischen Hardware und Software, richtig beurteilen.

Verifikation und Validation im Test

Die Verifikation und Validation der Software erfolgt zum großen Teil durch Testen. Allerdings ist dies ein langwieriger und zeitraubender Prozeß. Er beginnt beim "Unit-Test" und zieht sich über "String-Tests" bis hin zu einem abschließenden Abnahmetest. Beim Abnahmetest und der Validierung der Software sollte man den Kunden auf alle Fälle mit einbeziehen. Schließlich hat der Auftraggeber ein Recht darauf, die auszuliefernde Software beurteilen zu können.

Schreibt man jedoch eine sehr detaillierte Spezifikation, in die eine Vielzahl von einzelnen Forderungen eingehen, müßte der Kunde bei jedem Test dabei sein. Da sich jedoch die Tests an der Software über Monate - und manchmal Jahre - hinziehen, ist das für den Auftraggeber eine kaum zu bewältigende Aufgabe. Bei der Vielzahl der Fehler in der Software müßte er dazu auf Abruf Mitarbeiter bereitstellen. Das läßt sich in der Praxis kaum verwirklichen.

Gerade bei größeren Systemen, bei denen die Software nur ein Subsystem darstellt, kommen die Forderungen zur Instrumentierung der Software und die Testanforderungen aus der Testgruppe des Auftragnehmers. Der Auftraggeber wird zu Beginn des Projekts kaum in der Lage sein, fundierte Forderungen zum Testen der Software und des Systems zu formulieren. Ich will hier keinesfalls falsch verstanden werden: Test muß sein, und das beginnt bei der kleinsten Einheit des Programms. Die Entwicklung sollte dazu auch immer die Qualitätssicherung hinzuziehen, um die Ergebnisse bestätigen zu lassen. Ob ein Einbeziehen des Kunden auf dieser Ebene notwendig ist, würde ich bezweifeln.

Teilt man die Spezifikation in zwei Teile auf, kann sich der Kunde darauf beschränken, im Rahmen eines Abnahmetests die funktionellen Anforderungen zu überprüfen. Auch das wird ein gewisser Aufwand sein, doch ist er überschaubar und läßt sich zeitlich eingrenzen.

Es gibt bereits einen Typ von Software, bei dem zwei Spezifikationen geschrieben werden müssen: Sicherheitskritische Software. Dabei handelt es sich um Software, durch deren Versagen Menschenleben gefährdet sein könnten. Denken Sie zum Beispiel an den Autopiloten eines Flugzeugs, die Steuerung eines Kernkraftwerks oder einer Maschine zur Bestrahlung Krebskranker. In allen diesen Fällen kann durch einen Fehler menschliches Leben bedroht sein.

In diesem Zusammenhang sind besonders zwei Normen zu nennen: Der britische Defense Standard 00-55 (PART 1) heißt "The Procurement of Safety Critical Software in Defense Equipment". Software, die nach dieser Norm erstellt wird, verlangt zwei Spezifikationen: zum einen müssen die Anforderungen in verständlicher Sprache formuliert werden. Darüber hinaus muß eine formelle Spezifikation erstellt werden, deren Richtigkeit im mathematischen Sinne bewiesen werden kann.

Diese Forderung der Norm ist sicherlich nicht ganz einfach zu erfüllen, doch angesichts der hohen Ansprüche an die Sicherheit der Software verständlich.

Die zweite Norm auf diesem Gebiet kommt von der IEC, (International Electrotechnical Commission) und ist zur Zeit

ein Entwurf. Obwohl der Ansatz etwas anders ist als bei der britischen Norm, das Ziel ist das gleiche: Die Gefährdung menschlichen Lebens durch Softwarefehler zu verringern oder ganz aus zuschließen.

Kosten sprechen gegen zwei Dokumente

Gegen das Erstellen von zwei Dokumenten anstatt eines einzigen sprechen in vielen Fällen die Kosten. Man sollte allerdings auch eines nicht vergessen: Eine einzige Spezifikation, die nie fertig wird, dient dem Projektfortschritt nicht.

Bei zwei Dokumenten entstehen zusätzliche Arbeiten durch die Verifikation zweier Dokumente, die miteinander konsistent sein sollen. Die Gefahr, daß die Spezifikation nicht Was, sondern das Wie der Software behandelt, besteht eigentlich immer. Die Spezifikation sollte nicht den Entwurf der Software vorwegnehmen, aber an dieser Stelle ist die Grenze der Praxis oft eine recht fließende. Die Gefahr, zu sehr in den Entwurf zu geraten, wird nur einem Dokument für Spezifikation jedoch größer.

Bei kleinen und wenig komplexen Software-Projeken spricht kaum etwas für die zweigeteilte Spezifikation. Handelt es sich jedoch um

- sicherheitskritische Software,

- komplizierte Algorithmen,

- technisches Neuland,

- "embedded systems" oder

- Software in Echtzeit,

so sieht die Lage anders aus: In solchen Fällen sollte die Projektleitung durchaus erwägen, Spezifikation aufzuteilen. Es gibt gute Argumente für diese Vorgehensweise, und das Projektrisiko wird vermindert.

*Georg Erwin Thaller ist bei den Diehl-Werken in Nürnberg zuständig für Softwarequalität.