"Ein eklatanter Widerspruch", schreibt Dr. Dieter Noga, Bereichsleiter in der Geschäftsstelle "Zentrale Projekte" der SCS (Hamburg), "kennzeichnet Software." Während das Produkt Rationalisierung bewirke, sei die Produktionsweise "arbeitsintensiv wie kaum eine andere". Der SCS-Mann gibt Anwendern, die Software-Design-Werkzeuge suchen, einen ungewöhnlichen Rat: Wo der Grenznutzen der derzeitigen Werkzeuge strittig sei, begnüge man sich mit graduellen Verbesserungen - und warte. Zu Ende gedachte Produkte würden kommen - allerdings kaum im nächsten Jahr.
Dr. Gerhard Heldmann, Geschäftsführer, Softlab, München
Wir befinden uns heute in einem Übergangsprozeß: Noch vor relativ kurzer Zeit bestand Programmieren im wesentlichen aus der Entwicklung und Codierung von Algorithmen und dem anschließenden Test. Auch die "klassische" strukturierte Programmierung änderte an dieser Grundauffassung nicht viel. Es wurde gelehrt, wie ein Algorithmus entworfen und codiert werden muß (Dijkstra) oder wie man seine Ablaufstruktur aus den zu erarbeitenden Datenstrukturen ableiten kann (Jackson). Diese Entwicklungsphase der Softwaretechnologie ist heute weit fortgeschritten, methodische Unsicherheiten bestehen hier nur noch in Randgebieten.
Einige Untersuchungen ergaben jedoch, daß bis zu 80 Prozent der in ausgetesteten und abgenommenen Programmsystemen gefundenen Fehler nicht bei der Codierung, sondern bereits in der Planungsphase des Softwareprojektes entstehen und daß ihre Behebung bis zu hundertmal teurer ist, als sie es etwa bei einem Design-Review gewesen wäre. Damit verschoben sich die Schwerpunkte: Planung ist heute nicht mehr Programm-, sondern Systemstrukturierung, das heißt Formulierung der exakten Aufgabenstellung, Modularisierung und Schnittstellen-Definition. Es traten neue Methoden in den Vordergrund - funktionale Spezifikationen, "abstrakte Datentypen", "Systemfamilien" - und neue Probleme wie etwa der erst jetzt bekanntwerdende Gegensatz einiger früher unkritisch parallel benutzter Verfahren (zum Beispiel "HIPO" und "abstrakte Datentypen").
Der Schritt vom "Programming in the small" zum "Programming in the large" ist nicht nur durch eine ,quantitativen sondern durch einen qualitativen, Unterschied geprägt.
So wie man vor einigen Jahren begonnen hat zu verstehen, was ein gutes von einem schlechten Programm unterscheidet, und Kriterien für eine gute Programmstruktur formulierte (goto-freie Programmierung), so beginnt man heute zu verstehen, wie ein Systementwurf beschaffen sein sollte und welche Kriterien für seine Bewertung entscheidend sind ( "Bindungen" zwischen den Modulen "Kohäsion" eines Moduls, Kompiexität des Entwurfs).
Gegenwärtig gibt es nur wenige Hochschulinformatiker, die hier auch für den Praktiker brauchbare Überlegungen und Ansätze erarbeiten - und es gibt nur wenige Softwareentwicklungszentren, welche diese Arbeiten in realisierbare Projekttechniken umsetzen und mit Werkzeugen unterstützen.
Trotzdem - Software-Design morgen erfordert das Entwickeln und Beherrschen von Entwurfs-Spezifikations- und Verifizierungstechniken und nicht nur die "Fließbandproduktion" von (strukturiertem) Code.
Der einheitliche Begriff verdeckt eine Vielfalt von Tätigkeiten und Arbeitsschritten. Design ist der Entwurf der benutzerrelevanten Systemfunktionen- Design ist Systemstrukturierung vor dem Hintergrund des funktionalen Designs; Design ist Entwurf von Programmlogiken auf der Basis eines fertigen Systemdesigns.
Bei der Automatisierung dieser Tätigkeiten geht es intern um die Konstruktion einer Designsprache, an die schwer miteinander zu vereinbarende Forderungen gestellt werden. Der Designer muß in ihr denken können. Sie muß die Kommunikation mit Benutzern, Teamkollegen und Produktionskontrollinstanzen tragen. Sie muß eine interpersonell eindeutige und über den Lebenszyklus des Produkts pflegbare Dokumentation ermöglichen. Last, not least - sie muß den Übergang von einer Designphase zur nächsten und zur Programmierung unterstützen, das heißt grundsätzlich automatisierbar machen.
Es versteht sich, daß die derzeitigen Werkzeuge diesem Wunschkatalog nicht entsprechen. Im ungünstigsten Falle sind sie ärgerliche Verwechslungen von Form und Inhalt, Fetischisierungen der Technik, gewisse Kästchen nebeneinander auf DlN-A4-Blätter zu malen ( statt andere untereinander. Selbst im günstigsten Falle tendieren je doch Verkäufer dazu den Unterschied zwischen einem Lohn- und Gehaltsprogramm und einem komplexen eingebetteten System vergessen zu machen.
Dr. Ulrich Schedl, Geschäftsstellenleiter der gfs-München
Es existiert heute eine Vielzahl 4 von Entwurfsmethoden, Hilfsmitteln und Werkzeugen für die Softwareentwicklung. Methoden für die Funktionsbeschreibung (zum Beispiel HIPO), Datenbeschreibung (zum Beispiel Jackson, DDL), Ablaufbeschreibung (zum Beispiel SP, ET) und Programmstrukturbeschreibung (zum Beispiel NP) stehen als Ergänzung Werkzeuge, wie NP-, SP- oder ET-Generatoren, Skelettgeneratoren oder Makros für den Zugriff auf Methodenbanken gegenüber. Basismaterial genug, um das Zeitalter des Software-Handwerks zu verlassen, dem Software-Ingenieur das Feld zu überlassen und Informatik-Forschungseinrichtungen mit dem Aufbau normierter, das heißt allgemein verwertbarer Softwareentwicklungssysteme zu betrauen.
Die Realität und auch die nahe Zukunft sehen jedoch anders aus. Einmal ist das Vertrauen der EDV-Leute bezüglich der Qualitätssteigerung der Systementwicklung durch den Einsatz oben genannter Methoden und Werkzeuge nicht besonders hoch. Anläßlich einer bei der "Strukto 78" durchgeführten Befragung bewerten 38 Prozent den Einfluß auf die Qualität mit 10 bis 25 Prozent und 39 Prozent mit 40 bis 60 Prozent. Zum anderen ist die Kenntnis der Verfahren zum Software-Design zumindest bei den ORG- und Anwendungsprogrammierern sehr unterentwickelt.
Voraussetzung für den Durchbruch der Verfahren auf der Ebene der kleinen und mittelgroßen EDV-Anwender ist ein Umdenkprozeß bei den Verantwortlichen der Softwareentwicklung. Systemanalytiker und Programmierer müssen die Möglichkeit bekommen, einmal ohne Termindruck - bei kleineren Projekten - diese Methoden zu erlernen und anzuwenden. Nur mit diesem Prozeß der Selbsterfahrung können neue Erkenntnisse gewonnen und alte Pfade verlassen werden. Dies müßte die Investition wert sein!
Dr. Dieter Noga, Bereichsleiter in der Geschäftsstelle für zentrale Projekte, SCS, Hamburg
Ein eklatanter Widerspruch kennzeichnet Software. Während das Produkt Rationalisierung bewirkt, den Einsatz von Personal durch Kapital, ist die Produktionsweise arbeitsintensiv wie kaum eine andere: Abhängig von einzelnen Personen, schwer prognostizierbar, tendenziell instabil. Dieser Widerspruch erzeugt den bekannten Druck, auch hier von der künstlerischen zur industriellen Produktion überzugehen. Insbesondere bei den aufwendigen und entscheidenden Aktivitäten, die grundsätzlich mit Papier und Bleistift allein zu bewältigen sind, beim Design.