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.

05.11.1982 - 

Die Überprüfungsmethoden der Anforderungs- und Entwurfsphase, Folge 4:

Exakte Vorgabe trocknet erste Fehlerquelle aus

In Ermangelung einer echten Software-Metrik wuchern die gepriesenen Überprüfungsmethoden und -werkzeuge dermaßen aus, daß es heute beinahe unmöglich ist, die Spreu vom Weizen zu trennen. Sicher haben alle Vorschläge ihre Berechtigung in einer konkreten Projektanwendung gehabt. Erst der Versuch, sie für den allgemeinen Anwendungsfall zu vermarkten, macht vieles zur Spreu. Diese Vermarktung ist übrigens durchaus verständlich. Sie entspringt einmal aus dem Mitteilungsbedürfnis, wenn man eine gute Lösung zu haben glaubt. Zum anderen stecken häufig wirtschaftliche Wünsche und Notwendigkeiten hinter dem Versuch, eine ursprüngliche Speziallösung zu einem SW-Produkt zu machen.

Der Stand der Technik ist heutzutage der, daß man nur ein mehr oder weniger gutes Gefühl haben kann, das jeweils Beste getan zu haben. Dies ist sehr unbefriedigend und deshalb scheint es um so wichtiger, das richtige Augenmaß zu bewahren.

Natürlich darf an dieser Stelle nicht verschwiegen werden, daß es einige Bemühungen gibt, das Problem der Fehlerfreiheit von SW in den Griff zu bekommen. Gemeint sind die Instrumente, die nachweisen sollen, daß ein Programm tatsächlich fehlerfrei ist. Es handelt sich dabei meistens um sehr aufwendige, mathematische Verfahren, die teilweise manuell oder interaktiv im Rechner ablaufen.

Es ist aber für große Programme (sagen wir etwa ab 500 Befehlen) noch nicht gelungen, die Fehlerfreiheit wirklich nachzuweisen, wobei zusätzlich noch die Frage bleibt, ob es prinzipiell überhaupt möglich und wirtschaftlich ist, Programme absolut fehlerfrei zu erstellen. Darüber hinaus ist die Fehlerfreiheit nur ein wichtiger Qualitätsaspekt, nämlich ein Bestandteil der Zuverlässigkeit.

Sparsamkeit wird teuer

Orientieren wir uns lieber an dem, was heute wirtschaftlich machbar ist. Um eine Leitlinie zu finden, bietet sich wieder das Phasenkonzept an. im Sinne der Überprüfung der einzelnen Phasenergebnisse ergeben sich die nötigen Schritte gemäß Abbildung 1. Die Terminologie bedeutet, daß Verifikation die Überprüfung eines Phasenergebnisses zum vorherigen ist und die Validierung die Überprüfung des Endergebnisses zur Anforderung.

Ein Prinzip sollte alle Maßnahmen leiten: Die Erkenntnis, daß die Fehlerkosten exponentiell steigen, je später man einen Fehler entdeckt und je früher er gemacht wurde, sollte uns veranlassen, gerade bei den Maßnahmen in den ersten Phasen nicht zu sparsam zu sein (siehe Abbildung 2).

Welche Möglichkeiten bieten sich zur Überprüfung der Anforderung? Speziell geht es darum, die SW-Anforderung gegen die Systemanforderung zu überprüfen, oder, wenn es gar keine Systemanforderung gibt, die Qualität der SW-Anforderung zu überprüfen.

Da die Anforderung sozusagen der technische Vertragsbestandteil zwischen Auftraggeber und -nehmer ist, spielen bei der Überprüfung vor allem auch Kalkulation und Planung eine Rolle. Folgende Fragen sind offentsichtlich relevant:

- Erfüllen die geforderten Funktionen die Forderung an die SW aus der Sicht des Gesamtsystems?

- Sind die Funktionsforderungen in sich konsistent?

- Sind die Forderungen nötig? (Eine keineswegs triviale Frage, da häufig technische Möglichkeiten beide Partner blenden und sie die wirtschaftlichen Notwendigkeiten nicht mehr erkennen lassen).

- Sind die geforderten Nachweisverfahren ausreichend und nötig?

- Sind die Randbedingungen vollständig, korrekt, nötig und konsistent?

- Sind Qualitätsmerkmale gefordert und konsistent (die Qualitätsmerkmale sollten heutzutage tatsächlich unbedingt Bestandteil einer Anforderung sein, da sie einen wesentlichen Beitrag zu einer wirtschaftlichen SW-Produktion darstellen)?

- Sind Kostenkalkulation und Terminplanung plausibel?

Bei dieser Phase wurde bewußt über den rein technischen Aspekt der Anforderungsbeurteilung hinausgegangen. Dies liegt einfach in der etwas veränderten Zielsetzung. Hat man früher das Thema hauptsächlich aus der Sicht der fehlerfreien Software betrachtet, spielt heute im harten Geschäft die Wirtschaftlichkeit eine erheblich wichtigere Rolle. Was keinesfalls heißen soll daß die Fehlerfreiheit in den Hintergrund tritt. Geändert hat sich lediglich die Anschauung, daß man nämlich nicht unbedingt alles technisch Machbare realisieren kann. Dies ist der einzige Weg für die SW, den Schwarzen Peter, den sie schon einige Zeit besitzt, wieder loszuwerden.

Welche Mittel hat man nun zur Überprüfung der Anforderung? Mit den automatischen Methoden ist es nicht weit her. Dazu müßte eine Anforderung in formaler Weise erstellt sein, was im allgemeinen ein wenig dem Zweck der Anforderung widerspricht, nämlich auch für Nichtfachleute verständlich und damit beurteilbar zu sein. Klassisches Beispiel für ein Werkzeug ist das schon einmal zitierte PSL/PSA. Die Zurückführung der Definitionen in der Anforderung auf Objekte und die Relationen zwischen diesen Objekten ermöglicht natürlich eine formale Überprüfung (Vollständigkeit und Konsistenz). Mit dem Programm Statement Analyzer (PSA) lassen sich eine Reihe von Überprüfungen durchfuhren:

- Überprüfung der (syntaktischen) Richtigkeit von Angaben

- Ausgabe von Berichten (Reports): Alle Informationen über eingegebene Objekte, Namen und Datum der Objekte, Datenfluß in grafischer Form (Picture Report), Darstellung der hierarchischen Struktur (Structure Report) oder der Datenbankübersichtsbericht.

Sicher alles gute Hilfen zur Beurteilung, andererseits stellt die Komplexität und schwierige Erlernbarkeit eines solchen Systems den allgemeinen Einsatz sehr in Frage. Zudem werden die genannten wirtschaftlichen Aspekte natürlich nicht berücksichtigt.

Anforderungsbewertung mit Checklisten

Eine manuelle Vorgehensweise scheint in den meisten Fällen derzeit angebrachter zu sein. Im allgemeinen wird hierfür wie später auch beim Entwurf ein sogenanntes Review vorgeschlagen, in dem in Anwesenheit der Beteiligten mit Hilfe einer Reihe von Fragen, die zum Beispiel in einer Checkliste vorgegeben sind, die Anforderung bewertet wird.

Übrigens sollte man die Möglichkeit nicht außer acht lassen, zum Beispiel schwierige technische Detailprobleme auf ihre Realisierbarkeit schon vorher zu untersuchen, vielleicht sogar mit Hilfe von Programmen. Die Problematik dabei ist natürlich, daß im allgemeinen in dieser Phase noch kein Auftrag und damit auch kein Geld vorhanden ist. Das Ganze fällt damit unter das Akquisitionsrisiko. Auf der anderen Seite kann die finanzielle und terminliche Sicherheit der Entwicklung damit wesentlich verbessert werden.

Häufig ist es übrigens sinnvoll, diese Phase nicht als ein einmaliges Ereignis zu sehen. Eine Iteration zwischen Auftraggeber und Entwickler führt zwangsläufig zu einer höheren Genauigkeit der Anforderung und damit zu einer wichtigen Voraussetzung für eine erfolgreiche Durchführung.

Verifikation in Subphasen

Die nächste Stufe ist dann die Verifikation des Entwurfs. Ausgehend von der Einteilung in zwei Subphasen, nämlich Grobentwurf und Feinentwurf (Modulentwurf), gibt es prinzipiell drei formale Schritte:

- Großentwurfsüberprüfung

- Feinentwurfsüberprüfung

- Gesamtentwurfsüberprüfung.

Die Grob- und Feinentwurfsüberprüfung unterscheiden sich wesentlich in ihrer Aufgabenstellung. Beim Grobentwurf wird gegen die im allgemeinen nicht formale Anforderung geprüft (gleiches gilt für die Gesamtentwurfsüberprüfung). Beim Feinentwurf gilt es, den Modulentwurf gegen die Moduldefinition zu überprüfen. Beide sind, wenn man modernen Engineeringregeln folgt, schon ziemlich formal. Insbesondere dann, wenn man Pseudocodes verwendet, die wegen ihrer relativ einfachen Verwendbarkeit für rechnergestützte Verfahren immer mehr im Vormarsch sind. Besonders im Zusammenhang mit den modernen Programmiersprachen wie Pascal liegen die Vorteile klar auf der Hand. Pascal und moderne Pseudocodes unterscheiden sich nicht allzusehr.

Kaum Tools zur Entwurfsbewertung

Wie sieht es hier mit Tools aus? Je weiter wir im SW-Prozeß nach unten kommen, desto mehr häufen sich natürlich auch die Tools. Versucht man eine generelle Aussage zu treffen, so kann man feststellen, daß es kaum Tools gibt, die die Entwurfsbewertung selbst vornehmen. Schwerpunkt ist vielmehr die Darstellung der Zusammenhänge auf verschiedene Weise (Daten, Hierarchien, Abläufe), um ein manuelles Auswerten zu erleichtern. Insofern ist dies ganz ähnlich dem, was wir bei PSL/PSA feststellen konnten.

Nehmen wir als Beispiel das System EPOS. Nachteil ist übrigens, daß EPOS derzeit noch kein Modulkonzept kennt. Die Aufgabenzerlegung erfolgt stufenweise, bis man sich entschließt, nicht mehr weiter zu verfeinern, sondern zu codieren. Die erzeugten Strukturen, die auf einer Datenbank abgelegt sind, lassen sich in EPOS entweder durch Flußdiagramme, Struktogramme oder Petrinetze darstellen. Fehler in der Strukturierung lassen sich dadurch gut erkennen.

Die Vollständigkeit des Entwurfs gegenüber der Anforderung wird in gewisser Weise automatisch überprüft. Ein wenig Augenwischerei. Man muß nämlich bei einem Entwurfselement selbst angeben, welche Anforderung es erfüllt. Ob diese Angabe richtig war, kann das System natürlich nicht überprüfen. Trotzdem scheinen die Systeme dieser Art der richtige Weg zu sein, da sie so angelegt sind, daß zukünftige Entwicklungen eingebracht werden können.

Beziehungsprüfungen

Überwiegend ist heute wohl noch eine manuelle Vorgehensweise bei der Entwurfsbewertung einzusetzen. Dabei findet auch im allgemeinen ein Review statt. Checklisten helfen, nichts Wesentliches zu vergessen. Um bestimmte Entwurfsregeln und die Erfüllung von Qualitätsmerkmalen nachzuweisen haben sich bestimmte Beziehungsprüfungen als recht brauchbar erwiesen, wie sie beispielsweise Harry Sneed darstellt. Die Beziehungsprüfungen Modul - Modul, Modul - Daten, Modul - Funktionen in Form von Tabellen geben Aufschluß über so wichtige Entwurfskriterien wie Kompaktheit der Module oder die Minimierung der Zugriffsmöglichkeiten auf Daten, um einige zu nennen.

Ergebnis der Entwurfsbewertung ist ein verbindlicher und freigegebener Entwurf, der nun so ohne weiteres nicht mehr verändert werden darf. Nicht so ohne weiteres heißt, nicht ohne ein Verfahren, das sicherstellt, daß alle betroffenen Entwickler von der Änderung erfahren und sich zu den Auswirkungen äußern. Dies war in der früheren, nicht ingenieurmäßigen Vorgehensweise eine erhebliche Schwachstelle.

Erst jetzt beginnt im Entwicklungsprozeß der Schritt hin zum Rechner, nämlich mit dem Codieren. Mit dem Testen des Codes und der entstandenen SW wollen wir uns in der nächsten, letzten Folge befassen. Nicht ohne jetzt schon darauf hinzuweisen, daß das Bild bezüglich Systematik und Endgültigkeit von Vorgehensweisen und Mitteln auch nicht besser ist, eher sogar noch schlimmer wegen der ins Unermeßliche wachsenden Zahl von Vorschlägen und Werkzeugen.