MÜNCHEN (je) - Das Herausarbeiten immer neuer Standards kann in der öffentlichen Verwaltung - und keinesfalls nur dort - die Datenverarbeitung auf zunehmend höheren Ebenen in geordnete Bahnen lenken; eine Rückkehr zur Individual-EDV der Anfangsjahre ist ausgeschlossen. Diese Auffassungen vertritt und erläutert Hermann Schelle vom Kommunalen Gebietsrechenzentrum (KGRZ) in Gießen in einem Beitrag, der in der letzten Ausgabe von "inform" erschienen ist. "inform", herausgegeben von der Hessischen Zentrale für Datenverarbeitung, Wiesbaden, ist ein EDV-Organ für den öffentlichen Sektor im Lande Hessen"
Dem Artikel liegt die Absicht zugrunde, im Vorfeld der an Bedeutung gewinnenden Standardsoftware die Entwicklung bestimmende Kriterien aufzuzeigen. Die Entwicklungsstufen der DV-Komponente Software werden in Anlehnung an die drei Computergenerationen unter Einbeziehung softwaretechnischer Zielsetzungen veranschaulicht.
Die ersten Rechenanlagen wurden praktisch ohne Software ausgeliefert. Dem Benutzer gereichte es zur Ehre, sämtliche Befehle (noch dazu im Maschinencode) höchstselbst niederschreiben zu dürfen. Die zu lösenden Aufgaben resultierten im wesentlichen aus dem technisch-wissenschaftlichen Bereich.
Ehrfurcht vor dem Rechner noch nicht passé
Mit den Rechnern der zweiten Generation (etwa ab 1975) stellten sich sodann die ersten symbolischen Programmiersprachen, Ein-/Ausgabe-Routinen sowie Dienstprogramme ein, womit sie kommerziellen Aufgabengebieten erschlossen waren. Das softwaretechnische Denken in jener Phase wurde durch stark von technisch (speicherplatz-, durchsatz- und programmiersprachenbedingt) auferlegten Grenzen bestimmt. Individuelles Handeln selbst bei gleichen Problemstellungen kennzeichnete die Softwareentwicklung. Der Rechenzentrumsbenutzer war geneigt, ehrfurchtsvoll jeglichen Computer-Output entgegenzunehmen. Dieser Zustand hat sich dank Weiterentwicklung im software- und hardwaretechnischen Bereich sowie durch Verbesserung des organisatorischen Ablaufs gewandelt. Es ist jedoch ein noch nicht abgeschlossener Prozeß.
Mit erheblichem rechnerbedingtem Umstellungsaufwand begann Mitte der sechziger Jahre die Ära der dritten Rechnergeneration. Anstelle des Ein-Programm-Betriebes war es von nun an möglich, mehrere Programme parallel zur Ausführung zu bringen. Die Hauptspeicherkapazität nahm um ein Vielfaches zu, und die nunmehr umfassendere Software mit dem Kernstück Betriebssystem erlaubte in zunehmendem Maße problemorientiertes Denken.
Auf dieser Basis begannen die heutigen Softwareprodukte heranzureifen. Dialogsysteme (Teilhaber- und Teilnehmersysteme) ergänzten den Stapelbetrieb. Neben Programmsystemen zur Verarbeitung von Massendaten setzte die Entwicklung von Verfahren für Planungs- und Entscheidungszwecke ein. Im Hintergrund entwickelten sich Datenbankkonzepte; Herstellersoftware erlaubte, Systemverhalten zu messen; das Gebot der Stunde hieß Integration und Zentralisierung.
Zählebige maschinenorientierte Softwaretechnik
Die Einführung der virtuellen Speichertechnik beeinflußte diese Entwicklung nur indirekt. Jedoch litt das ganze Geschehen unter der an der zweiten Rechnergeneration orientierten stark maschinenbezogenen Softwaretechnik, sowie am Mangel an tauglichen Werkzeugen zur Softwareentwicklung, -wartung und -verwaltung.
Einer der ersten, die sich dieser Problematik widmeten, war Dijkstra. Er erkannte die Problematik und begann Methoden und Techniken zur klaren Darstellung komplexer Sachverhalte zu entwickeln, indem er eine Aufgabe in hierarchisch geordnete Teilfunktionen gliederte. Problemorientiertes Denken sollte dem speicherplatz-, durchsatz- und sprachenbezogenen Denken übergeordnet werden.
Parallel hierzu erfolgte recht kurzfristig mit den gleichen Zielsetzungen der Einsatz von Generatoren zur Erzeugung von Steuermodulen und Entscheidungstabellen, die Ablösung der Assemblersprache durch höhere Programmiersprachen sowie eine Aufwertung von Testabwicklung und Dokumentationsgestaltung. Richtlinien zur Sicherstellung einer einheitlichen Anwendung dieser Erkenntnis rundeten das Ganze ab.
Einige Praktiker der Datenverarbeitung erkannten den über die Größenordnung einer Marktnische hinausgehenden Problembereich und begannen Grundsteine für die heutigen Softwarehäuser zu legen, indem sie einerseits aus der im Softwarebereich herrschenden Individualität die Gemeinsamkeiten herausfilterten und als Standards anboten, andererseits Alternativen zu der nicht immer anwenderfreundlichen systemnahen Herstellersoftware entwickelten.
Software-Engineering mit Hardware-Systematik
Verwaltungsseitig wurde man ebenfalls aktiv (IMKA, KoopA etc.) in dem Bemühen, das sich nunmehr auftürmende Gedankengut in geordnete Bahnen, sprich Normen, zu lenken. Der Leitgedanke all dieser Aktivitäten, "SOFTWARE ENGINEERING", begann sich abzuzeichnen (eine an der Systematik bei der Hardwareentwicklung orientierte Vorgehensweise).
Die in den einzelnen Bereichen unternommenen Schritte in Richtung Problemnähe (letztendlich Wirtschaftlichkeit, Transparenz, Flexibilität) bei der Entwicklung von Anwendersoftware haben inzwischen zu einer verbindlicheren Form geführt. Forderungen, auf immer höheren Ebenen zum Gleichschritt zu finden, sind ebenso Grenzen (durch Mensch und Mittel) gesetzt, wie dem Verlangen, sich auf die Ebenen ausschließlichen individuellen Handelns zurückzubegeben. Zugegeben werden soll, daß die kaum für möglich gehaltenen Hardwarepreise insbesondere auch im Kleinrechnerbereich zu Unterbewertung der Bereiche Software und Organisation verführen können.
Seitens der Rechenzentren ist mittels Projektmanagementmethoden sicherzustellen, daß die unter Systemengineering zusammengefaßten Zielsetzungen konsequent weiterverfolgt werden. Dies bedeutet bei der Strukturierung einer Aufgabe, vorranging das Problem im Auge zu haben und technische Abhängigkeiten auf einer möglichst niedrigen Ebene und spät wirksam werden zu lassen (Unterziele: Wertbarkeit, Wiederverwendbarkeit, Portabilität). Diese Ansätze treffen auch für Dialogverfahren zu, die im Rahmen von Distributed Processing zu entwickeln sind.
Weitere Ansätze ergeben sich im Bereich der Ablaufsteuerung (Datensicherung, Wiederanlauf, JOB-/STEP-Steuerung, Protokollierung, Fehlerverzeichnisse, Listaufbereitung und Steuerung, Datenstrukturen). Diesem Bereich wurde (im Gegensatz zur Programmebene) unter dem Aspekt einer verfahrensübergreifenden Vorgehensweise seither nur wenig Beachtung geschenkt. Ergänzend insbesondere aufgrund des Einsatzes verschiedener Methoden und Mittel ist bei größeren Projekten in zunehmendem Maße auf kompatible Schnittstellen zu achten (KoopA-Beschlüsse). Ferner ergeben sich im Bereich der Dokumentationsgestaltung und Erstellung sowie der Testabwicklung Verbesserungsmöglichkeiten.
Verwaltungsgerechter Input und Output = DV-Nutzen
Ergänzend sei der berechtigten Frage nach dem Nutzen dieser Bemühungen nachgegangen, jedoch nicht ohne den Hinweis, daß dieser letztlich einer Synthese aus organisatorischem Rahmen (Projektteam), Softwarewerkzeugen (beispielsweise zur interaktiven Programmentwicklung) und Softwaretechniken (funktionaler Ansatz, datenorientierter Ansatz etc.) entspringt, wobei man die Bereiche Test und Dokumentation nicht übersehen darf.
Für die Verwaltung stellt sich der DV-Nutzen in Form einer der Verwaltungsstruktur angepaßten Aufbereitungsmöglichkeit ihres INPUTS sowie Verwendbarkeit des OUTPUTS dar, basierend auf einem entsprechend gegliederten Anwendungshandbuch (frei von nicht benötigten Funktionen). Korrektheit der Ergebnisse sowie rascher Service bei Gesetzesänderungen, ad-hoc-Anfragen und ähnlichem tragen ebenfalls zu verwaltungsseitigem Nutzen bei.
Der RZ-seitige Nutzen im Sinne wirtschaftlichen Handelns erwächst aus der Zuverlässigkeit der Software, deren Wartbarkeit und Systemverhalten einschließlich Handling. Die unmittelbaren Voraussetzungen hierfür sind die mittels der beschriebenen Methoden erzeugten Produkte (Moduln, Programme, Teilsysteme, Systeme). Ein Softwareprodukt soll folgende Eigenschaften besitzen: hierarchisch nach Funktionen gegliedert, portabel (auf Systeme anderer Hersteller übertragbar und vermarktbar), teilweise wiederverwendbar (Standardroutinen) und kompatibel (genormte Schnittstellen etwa in Datenbanken). Bei solchen Softwarepaketen läßt sich in begrenztem Umfange deren Korrektheit beweisen, womit sich der zum Beweis der Anwesenheit (nicht Abwesenheit) von Fehlern erforderliche Testaufwand reduzieren läßt.
Teilweise wird davon ausgegangen, daß es um einen Faktor bis zu 100 teuerer ist, einen Entwurfsfehler während des Abnahmetests zu beheben, als unmittelbar nach Entstehen der Entwurfsunterlagen; von Modul- zu Abnahmetest wird ein Faktor von ungefähr 30 angegeben. Die Ausführungen sind auf Kleinrechner nur bedingt übertragbar. Jedoch, ob groß oder klein, letztlich geht es um bürgergerechtes Verwaltungshandeln.