Es gibt heute eine kaum noch zu übersehende Vielfalt von "SW-Methoden". Gleichzeitig mit ihnen entstand eine Vielzahl von Werkzeugen, die die einzelnen Verfahren mehr oder weniger unterstützen. Methoden und Werkzeuge decken in der Regel aber nur einen spezifischen Problemkreis ab, sie unterstützen selten mehr als eine Entwicklungsphase.

Das Hauptaugenmerk ist meistens auf die interne Programmstruktur gerichtet (structured programming). Um aber den gesamten Entwicklungsprozeß Technik unterstützen zu können, hat man häufig diejenigen Werkzeuge organisatorisch zu einem "System" zusammengefaßt, die insgesamt den gesamten SW-Entwicklungsprozeß unterstützen. Es entstanden "Werkzeugkästen" mit "blendender" Oberfläche, aber ohne durchgängige Methodik. Man hat in der Tat den Eindruck, als ob viele glaubten, eine farbige und grafische Oberfläche mache aus einem Editor schon eine SPU.

Der anfänglichen Euphorie folgt dann bei einem konkreten Einsatz sehr schnell die Ernüchterung, weil die methodischen "Gräben" zwischen den einzelnen Phasen und Werkzeugen nur mit administrativen Maßnahmen und zusätzlichem, manuellem Mehraufwand überbrückt werden können. Diese "Gaps" entpuppen sich außerdem häufig als zusätzliche Fehlerquellen, weil die Konsistenz der Entwicklungsergebnisse aufgrund der fehlenden geschlossenen methodischen Basis nicht gewährleistet werden kann.

Nicht selten hört die Unterstützung auch einfach nach der Entwurfsphase auf. Der entstehende Code führt dann ein intensives Eigenleben, so daß die Entwurfsdokumentation sehr schnell zur Makulatur werden kann, insbesondere, wenn es sich um langlebige Software handelt.

Mindestanforderungen an die SPU

Wie die Erfahrung zeigt, sollte eine SPU einigen Mindestanforderungen genügen, wenn sie den Anspruch erhebt, als solche bezeichnet zu werden Die SPU soll alle Phasen des Produktionsprozesses methodisch durchgängig unterstützen und sowohl für die Neuentwicklung, Weiterentwicklung als auch Korrektur gleichermaßen verwendbar sein. Der Übergang zwischen den Phasen innerhalb des Produktionsprozesses darf für den Anwender weder ein methodisches Umdenken noch zusätzliche technische oder organisatorische Maßnahmen erfordern.

Die Arbeit mit der SPU hat den Anwender nicht mehr zu belasten als bei den bekannten konventionellen Verfahren. Die Arbeitsergebnisse sollen von der SPU zusammenhängend, überschaubar und effizient kommunizierbar dargestellt werden. Der Anwender muß die Möglichkeit haben, den Bindungsgrad an die zugrunde gelegte Methode selbst bestimmen zu können (Methodenaffinität).

Die Anforderungen an die Entwicklung eines Anwendersystems (AWS) müssen sich mindestens hinsichtlich Wirkung (Funktion) und Qualität mit Hilfe der SPU eindeutig und vollständig formulieren lassen.

Die eindeutig und vollständig beschriebene Wirkung (Anforderungsdefinition) soll eindeutig nachvollziehbar in einen Systementwurf umgesetzt werden können. Aus dem Systementwurf müssen nachvollziehbar eindeutige Realisierungsvorgaben abgeleitet werden können. Die Realisierung soll anhand der Realisierungsvorgaben direkt mit Unterstützung durch die SPU durchgeführt werden können. Es muß möglich sein, die realisierten Teile ebenfalls mit direkter Unterstützung durch das SPU zu einem Ganzen zu integrieren und in ihrer Wirkung zu testen. Das Anwendersystem soll unabhängig von einer Programmiersprache oder sonstiger HW/SW-Umgebung entworfen werden können (Portabilität des Entwurfs).

Der Schulungsaufwand für den Umgang mit einer SPU darf höchstens ein bis zwei Tage betragen. Ohne daß das Anwendersystem vollständig realisiert worden ist, muß es möglich sein, bereits erste Erkenntnisse über dessen konkretes Verhalten zu gewinnen (Prototyping). Ferner soll es möglich sein, jederzeit und unmittelbar eine Auskunft über den Projektstatus zu bekommen.

Auf der Basis dieser Anforderungen läßt sich ein Prototyp einer SPU entwickeln, um den Nachweis zu führen, daß eine solche SPU überhaupt machbar ist und um weitere Erfahrungen zu sammeln. Basis des Prototyps ist eine in vielen Entwicklungsprojekten erprobte Gestaltungsmethode, die durchgängig alle Phasen der SW-Entwicklung unterstützt.

Produktionsprozeß wird durchgängig unterstützt

Der gesamte Produktionsprozeß wird methodisch, technisch und organisatorisch unterstützt. Die Unterstützung beginnt bei der Analyse der Zielsetzung für ein AWS, nämlich was mit einem AWS bewirkt werden soll, und endet bei der Validierung, nämlich der Überprüfung, ob das realisierte AWS auch wirklich die geforderte Wirkung hat.

Die Anwendung des Prototyps ist unabhängig davon, ob der Anlaß für eine Aktivität eine Neuentwicklung eine Weiterentwicklung oder eine Korrektur eines AWS ist. In dem Prototyp werden folgende Anwendungsarten unterschieden:

- Systemgestaltung

Die wesentliche Aufgabe der SPU besteht darin, den Anwender bei der Gestaltung seines Systems derart zu unterstützen, daß er es mit der gewünschten Qualität entwickeln und pflegen kann.

- Systemdokumentation

Alle Arbeitsergebnisse, beginnend bei der Festschreibung der Anforderungen an ein AWS bis hin zu den Testergebnissen, werden konsistent verwaltet und können in unterschiedlicher Zusammenstellung und Darstellung sowohl am Bildschirm als auch am Drucker ausgegeben werden.

- Projektmanagement

Alle Statusinformationen, die für das Management eines Projektes von Bedeutung sind, werden unmittelbar aus den Arbeitsergebnissen gewonnen; es müssen keine zusätzlichen Informationen für die Projektverfolgung erfaßt oder verwaltet werden.

- Unterweisung

Für den Umgang mit der SPU gibt es eine ausführliche, systemimmanente Unterweisung, die sowohl Auskunft über den methodischen Hintergrund als auch die einzelnen Arbeitsschritte gibt.

Die Systemgestaltung erfolgt in dem Prototyp in den Phasen Anforderungsdefinition, Entwurf, Realisierung, Integration und Validierung.

Beziehungen zur Umwelt sind zu erfassen

Die Wirkung, die ein AWS haben soll, wird in der Anforderungsdefinition vollständig beschrieben. Alle Beziehungen, die ein zu gestaltendes AWS zu seiner Umwelt hat beziehungsweise haben soll, werden systematisch erfaßt. Was alles als Umwelt eines AWS zu betrachten ist, hängt von der aktuellen Ausgangssituation ab. Folgende Ausgangssituationen werden unterschieden:

- Ein AWS soll neu entwickelt werden (Neuentwicklung).

- Ein bestehendes AWS soll erweitert oder modifiziert werden.

- Die Leistung (Performance) eines AWS soll verbessert werden.

- Die technische Struktur eines AWS soll verbessert werden.

- Die Schnittstellen zum Supportsystem (Hardware, Software) haben sich geändert (neue und modifizierte Supportfunktionen).

- Funktionale Analyse und Erfassung eines bestehenden, bisher nicht mit der SPU entwickelten AWS.

In dem Prototyp wird ganz konsequent zwischen einem funktionalen und einem technischen Entwurf unterschieden. Der Entwurf gliedert sich daher in einen Funktions- und einen Bausteinentwurf. Die entworfene Funktionsstruktur läßt sich in Bausteinen abbilden. Das Ergebnis der Abbildung ist ein Bausteinnetz.

In der Funktionsentwurfsphase wird das innere Wirkungsgefüge eines AWS systematisch top-down gestaltet. Jede Funktion der entstehenden Funktionshierarchie ist entsprechend dem Grad der gewählten Methodenaffinität beschrieben. Das wesentliche Ergebnis des Funktionsentwurfs stellen die Hierarchisch-Funktionale Struktur (HFS) und die Hierarchische Interaktionsstruktur (HIRS) des AWS dar, die auch gleichzeitig die Machbarkeit dokumentieren. Die HIRS ist ein hierarchisches Gebilde analog zur HFS, in der die Funktionen jeder Hierarchieebene durch Informationsflüsse miteinander verbunden sind.

Die HIRS wird in der Bausteinentwurfsphase in Bausteine abgebildet. Dabei erfolgt eine Aufteilung in Funktionskomplexe, die als eine technische Einheit (Baustein) realisiert werden sollen. Die Art der Aufteilung richtet sich nach den Anforderungen, die an die technische Qualität (zum Beispiel Wartbarkeit) eines AWS gestellt werden.

Für jeden Baustein wird ein sogenannter Montagerahmen angefertigt. Der Montagerahmen repräsentiert gleichzeitig die innere Struktur eines Bausteins, er enthält auch alle internen und externen Deklarationen für die vollständige Bausteinversorgung. Der Montagerahmen wird in Form einer Codiervorlage ausgedruckt. Gleichzeitig ist für jeden Baustein eine Prüf(Validation)-Tabelle anzulegen.

Codeübersetzung ergibt montagefähigen Baustein

Ein Baustein wird anhand des Montagerahmens realisiert. Dabei ist zu überprüfen, ob die beim Funktionsentwurf vereinbarten Datentypen Verwendung finden. Es muß nicht der gesamte Baustein codiert werden, um einen montagefähigen Baustein zu erhalten. Es ist vollkommen ausreichend, wenn die sogenannten Managementanweisungen codiert sind.

Danach wird der Code des Bausteins übersetzt. Das Übersetzungsergebnis ist ein montagefähiger Baustein (Objekt). Jeder montagefähige Baustein kann sofort in das Bausteinnetz integriert werden, und das Gesamtverhalten läßt sich untersuchen, auch wenn noch nicht alle Funktionen codiert worden sind. Wenn eine Funktion vollständig realisiert worden ist, wird ihre tatsächliche Wirkung automatisch mit der vorgegebenen Wirkung (Prüf-Tabelle aus dem Funktionsentwurf) verglichen.

Der Prototyp ist im Laufe der Zeit aufgrund der gesammelten Erfahrungen weiterentwickelt worden. Von den Anwendern werden folgende Merkmale besonders hervorgehoben:

- Methodische Geschlossenheit

Der Übergang zwischen zwei aufeinanderfolgenden Gestaltungsphasen erfordert kein methodisches Umdenken. Die Arbeitsergebnisse einer gerade abgeschlossenen Phase lassen sich direkt als Vorgabe für die nachfolgende Phase verwenden. So kann man sich zum Beispiel nach der Phase Entwurf gezielt Codiervorlagen für die Bausteinrealisierung ausdrucken lassen.

- Verwaltung und Darstellung der Arbeitsergebnisse

Alle Arbeitsergebnisse werden konsistent verwaltet. Die Arbeitsergebnisse können nach unterschiedlichen Kriterien zusammengestellt und vielfach auch grafisch aufbereitet über den Arbeitsbildschirm oder den Drucker ausgegeben werden.

- Kein zusätzlicher Aufwand

Die Arbeit mit dem Prototyp bringt insbesondere in der Entwunfsphase eine spürbare Entlastung, da alle Arbeitsergebnisse Bestandteil der Systemdokumentation sind und zusammenhängend verwaltet werden. Eine zusätzliche oder nachträgliche Dokumentation des Anwendersystems ist vom Prinzip her nicht erforderlich.

- Einfache Anwendung

Die Arbeit mit dem Prototyp gestaltet sich einfach. Man wird im Dialog (Menü-Technik) geführt, man braucht weder eine besondere Sprache noch irgendwelche Anweisungen oder Kommandos zu lernen. Die Regeln für die Systemgestaltung sind dialogimmanent. Durch die besondere Art der Dialogführung ist also weitestgehend sichergestellt, daß ein Verstoß gegen die Gestaltungsregeln so früh wie möglich erkannt wird, so daß aus diesem Grunde keine aufwendigen Korrekturen erforderlich werden und man unnötig demotiviert wird.

- Methodenaffinität

Man hat die Möglichkeit, der zugrunde liegenden Methode unterschiedlich detailliert folgen zu können.

- Geringer Schulungsaufwand

Durch die methodische Geschlossenheit und die besondere Art der Dialogführung ist der Schulungsaufwand gering.

- Problemorientiertes Arbeiten

Bis zur Gestaltungsphase "Realisierung" sind keine Programmierkenntnisse erforderlich, man kann sich voll auf die Gestaltung seiner Lösung konzentrieren.

- Prototyping

Erkenntnisse über das Verhalten des Anwendungssystems können schon während des Entwicklungsprozesses gewonnen und bei der weiteren Gestaltung bereits berücksichtigt werden. Ein Entwurf kann bereits realisiert werden, ohne daß er insgesamt bis ins Detail durchgestaltet sein muß.

- Wiederverwendbarkeit von bestehenden Bausteinen zur Lösung neuer Probleme kann auf einfache Weise überprüft werden. Man wird zur Standardisierung angehalten.

- Vollständigkeit und Korrektheit

Die Vollständigkeit und Korrektheit der Lösung eines Anwenderproblems wird unter anderem dadurch erreicht, daß man durch die besondere Dialogführung zu einer systematischen Vorgehensweise angehalten wird. Die Gestaltung beziehungsweise der Gestaltungs-Dialog beginnt mit der Präzisierung der Wirkung, die durch eine Neu-, Weiterentwicklung oder Korrektur erreicht werden soll und setzt sich systematisch über alle Gestaltungsphasen fort. Erst wenn eine Gestaltungsphase vollständig abgeschlossen worden ist, kann zur nächsten Phase übergegangen werden. Dasselbe gilt für die Gestaltungsschritte innerhalb einer Phase. Vollständig heißt in diesem Zusammenhang nicht, daß ein aktuell betrachteter Systemabschnitt schon bis ins Detail vollständig gestaltet sein muß. Die Vollständigkeit bezieht sich lediglich darauf, daß alle zutreffenden Gestaltungsanforderungen eines Gestaltungsschrittes berücksichtigt worden sein müssen, zum Beispiel auch mit der Antwort: "Kann jetzt noch nicht beantwortet werden." Man wird auf diese Weise zum ganzheitlichen Systemdenken angehalten, da man sich systemunterstützt erst dann einem Detail zuwenden kann, wenn man auf diese Weise mit der Systemgestaltung bis an den interessierenden Systemabschnitt vorgedrungen ist.

- Konsistenz der Gestaltungsergebnisse

Alle Gestaltungsergebnisse bleiben auch bei der Weiterentwicklung (Pflege) eines AWS untereinander konsistent. Ein mögliches Auseinanderklaffen zwischen der "Dokumentation" und dem Code eines AWS wird verhindern

- Portabilität des Entwurfs

Die Gestaltung des AWS ist weder an eine Programmiersprache noch an eine bestimmte HW/SW-Umgebung gebunden. Erst in der Gestaltungsphase "Realisierung" muß man sich für eine Programmiersprache entscheiden.

Die positive Resonanz die ein solcher Prototyp finden wird zeigt, daß das Konzept stimmt - erst die geschlossene Methode und dann das Werkzeug. Es ist aber noch viel Detailarbeit zu leisten. Die schrittweise Entwicklung eines Prototyps hat sich sehr bewährt, denn die unmittelbare Konfrontation mit der Realität hat frühzeitig theoretische Vorstellungen in ihrer Bedeutung relativiert.