MÜNCHEN (qua) - Rund 45 Prozent des Programmieraufwands schluckt die nachträgliche "Verschönerung" der Software. Mit exakteren Methoden der Anforderungsanalyse und -deifnition wären hier jedoch drastische Einsparungen möglich, so Helmut Partsch, Professor für Informatik an der Universität Nijmegen, im Einführungsvortrag zur Systems-Fachtagung "Software Engineering".
"Wozu brauche ich Software-Engineering? Ich programmiere in Fortran". Wie Professor Partsch mit diesem Zitat eines Informatikstudenten höheren Semesters belegt, hat sich auch bei den Fachleuten die Einsicht in die Notwendigkeit systematischer Software-Entwicklung noch nicht von durchgesetzt. Noch schwieriger ist es, so ein Tagungsbesucher, die zumeist uneingeweihten Entscheider in den Anwenderbetrieben für diese Idee zu begeistern.
Dabei dokumentiert das vom US-Wissenschaftler Richard Foley zusammengetragene Zahlenmaterial, daß die eigentlichen Probleme der Software-Entwicklung nicht dem gängigen Klischee von der Programmierung entsprechen: Nur acht Prozent des Entwicklungsaufwands entfällt auf die eigentliche Codierung, 60 Prozent jedoch schluckt die Wartung im weiteren Sinne. Partsch zeigte sich jedoch optimistisch, daß diesem Budget-Posten beizukommen sei - und zwar mit einer Aufwertung der frühen Entwurfsphasen.
Starke Vorbehalte gegen Prototyping
Den hundert bis hundertfünfzig offensichtlich fachkompetenten Zuhörern legte der Informatikprofessor nahe, von Anfang an systematisch zu arbeiten. Wichtig sei das auch im Hinblick auf die Notwendigkeit, Fehler so früh wie möglich zu erkennen; eine rechtzeitige Fehlererkennung verringere nämlich den Korrekturaufwand erheblich.
Starke Vorbehalte äußerte Partsch gegen die als "Prototyping" bekannte Entwicklungsmethode: Sie berge die Gefahr eines Rückfalls in die Software-Bastelei. Ein nützliches Instrument für das Software-Engineering könne diese Methode nur dann sein, wenn zum einen der Begriff Prototyp eindeutig definiert sei und zum anderen sehr streng systematisiert werde.
In seinem anschließenden Vortrag mit dem Titel "Anforderungsanalyse und -definition" beklagte der Wissenschaftler, daß gerade für die Frühstadien der Programmentwicklung heute noch keine hinreichend fomalisierten Hilfsmittel zur Verfügung stünden. Das gelte auch für die beiden Urformen des Requirement Engineering, nämlich einerseits die Structured Analysis and Design Technique (SADT) und andererseits die Problem Statement Language beziehungsweise -Analysis (PSL/PSA). Außerdem erlaubten beide Methoden keinen methodischen Übergang zum Systementwurf, weshalb die Anforderungsdefinition quasi in der Luft hängen bleibe.
Pluspunkte für die algebraische Spezifikation
Typisch für jeden Software-Entwurf ist das Spannungsverhältnis zwischen der Exaktheit und der Verständlichkeit der Spezifikationssprache. Sowohl ASDT als auch PSL/PSA lösen diesen Konflikt laut Partsch, indem sie von "natürlicher", allgemein verständlicher Sprache ausgehend durch immer stärkere Einschränkung zu einer formalen Beschreibung gelangen. Der Professor beschäftigt sich jedoch seit geraumer Zeit mit einer Methode, die den Entwickler den umgekehrten Weg entlang führt; unter der Bezeichnung "algebraische Spezifikation" stellte er sie dem Tagungspublikum vor.
Die Vorteile der algebraischen Spezifikation beschreibt Partsch so: Sie hat einen vollständig formalen Ansatz, ist leicht maschinell unterstützbar, bedeutet eine ganzheitliche Entwicklungsmethodik, erzwingt eine präzise Ausdruckweise, ermöglicht die Überprüfung der Anforderungen auf mögliche Konsequenzen und kann durch einen immanenten Abstraktionsmechanismus leicht modifiziert werden. Allerdings erfordert diese Methode einen erhöhten Lernaufwand.
Zur Zeit läuft an der Universität Nijmegen ein Projekt, das überprüft, wie diese Definitions-Methode sich im praktischen Einsatz bewährt. Nach anfänglichem Zögern, so Partsch, habe sich auch die Industrie zur einer Mitarbeit in der Testphase bereit erklärt. An entsprechenden Werkzeuge werde noch gearbeitet.