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.

14.03.1980 - 

Rationalisierungskennziffern für Software-lngenieure fremde Begriffe:

Die große Zeit der Standardsoftware wird kommen

DORTMUND - In vielen Unternehmen hat der Controller die EDV-Abteilung noch nicht entdeckt, meint Professor Dr. Joachim Griese, Betriebsinformatiker an der Universität Dortmund. Dies sei ein wesentlicher Grund dafür, daß sich der Siegeszug der Standardsoftware noch hinauszögere. Griese sprach auf der Informationsveranstaltung der Gesellschaft für Elektronische Informationsverarbeitung (GEI) mbH, der dritten seit l970.

Das Grußwort an die Zuhörer nutzte GEI-Geschäftsführer Wolfgang Schönfeld zu einem Kurzporträt seines Hauses. Demnach ist die GEI heute ein Systemhaus mit drei Systemtechnik-orientierten Töchtern und Expansionsplänen zu den Standorten Hamburg, München und - eventuell - Stuttgart, "um Wartungsfragen softwaretechnischer Art zu lösen" (Schönfeld). 50 Prozent der derzeitigen GEI-Aktivitäten gelten der Prozeßrechner-Steuerung, und mit den für 1980 geplanten 24 Millionen Mark Umsatz sieht Schönfeld sein Haus im bundesdeutschen Vergleich "irgendwo auf Platz drei, vier oder fünf".

Professor Griese, der zum Thema "Verfahren der rationellen Softwareentwicklung" sprach, konstatierte ein zunehmendes Kostenbewußtsein in deutschen Betrieben und in diesem Gefolge das "Ende des Paradieses" in mancher DV-Abteilung. Eine heilsame Wirkung im Ernstfall könnte nach seiner Ansicht die vermehrte Verwendung von Standardsoftware entfalten - derzeit etwa bei DB-Systemen und systemnäheren Programmen, aber auch bei Anwendungen im administrativen Bereich (Fibu etc.).

Diese "Verzerrung des Know-hows" wird ihrerseits aber das Umsteigen auf hochwertige Standardsoftware weiter beschleunigen, sagt der Wissenschaftler. Ein weiteres Hilfsmittel im Kampf gegen steigende Softwarekosten sieht Griese in der Rationalisierung der Software-Entwicklung, und hier insbesondere in der bisher zu wenig beachteten Festsetzung des Leistungsumfangs eines Softwaresystems ("Spezifikation durch Requirements Engineering").

Kein Leistungsmesser

Neben der Spezifikation seien aber auch Entwurf, Realisierung und schließlich ein richtig gewählter Verfahrensverbund von entscheidender Bedeutung für die Qualität der Software. Die Schwierigkeiten, vor denen der Software-Ingenieur steht, faßt Griese so zusammen: Produktivitätszahlen oder Rationalisierungskennziffern sind fremde Begriffe, Lines of Code pro Zeiteinheit kein geeigneter Leistungsmesser.

Die Spezifikation sollte - so Griese - mit einem Erhebungsverfahren beginnen, das je nach Art des DV-Anwendungssystemes unterschiedlich sein könne - bei dispositiven oder planerischen Anwendungen beispielsweise eine Befragung der Abteilungsfachleute. Die somit bekannten Leistungskomponenten sollten dann beschrieben werden - nach Möglichkeit formalisiert, beispielsweise mit Hilfe der Problem Statement Language (PSL).

Die sich im dritten Schritt daran anschließende Prüfung der Spezifikation sei zum Beispiel mit dem Problem Statement Analyzer (PSA) oder auch im Walkthrough-Verfahren oder durch eine nicht-maschinelle Inspektion vorzunehmen.

Keine objektiven Zahlen

Bei der Auswahl des Entwurfsverfahrens bieten sich datenstrukturorientierte á la Jackson oder funktionsorientierte Verfahren wie etwa Composite Design an. Griese, der betont ideologiefrei über dieses "von der Modewelle erreichte" Thema sprechen wollte, nannte als gemeinsames Merkmal beider Denkschulen, daß so gut wie kein objektives Zahlenmaterial über ihre Effizienz vorliege. Bei der Swissair glaube man die Programmiererproduktivität durch die Einführung der Jackson-Methodik um sechs bis zehn Prozent erhöht zu haben. Exxon berichte in diesem Zusammenhang von verbesserter Programmqualität und 7000 Lines of Code pro Mannjahr.

Mehr Aufschluß soll ein Entwurfsmethodenvergleich geben, den Griese noch in diesem Sommer mit Studenten der Universität Dortmund unter möglichst wissenschaftlichen Bedingungen durchführen will. Die Software-Entwurfsphase endet mit einer abschließenden Prüfung, beispielsweise einer nicht-maschinellen Entwurfsinspektion. Die darauf folgende Realisierungsphase ist nach Grieses Darstellung nicht Gegenstand ideologischer Auseinandersetzungen.

Anstrengungen im Vorfeld

Ihr Ablauf wird unterstützt entweder durch höhere Sprachen wie "Girl" oder "Gogol" oder durch Systeme wie "PET/X 1150". Zur Dokumentation verweist Griese beispielsweise auf maschinelle Beschreibungsverfahren wie "Data Catalogne" oder "Byblos"; und die Prüfung nehmen Testwerkzeuge vor wie etwa maschinell - "Pro/Test". Griese plädiert nachhaltig für verstärkte Anstrengungen im Vorfeld der Codierung. Neben einer akribischen Programm-Spezifikation seien vor allem Verfahrensverbunde zu fordern. Solche aufeinander abgestimmten, in einem organisatorischen Ablauf eingeordneten Verfahren seien geeignet, den Software-Kostenberg entscheidend in Richtung Projektanfang zu verlagern. Dort sei das Erkennen von Fehlentwicklungen finanziell weit weniger folgenreich als bei dem zur Zeit noch allgemein üblichen Kostenverlauf.

Die Softwaretechnik stehe da, wo der Maschinenbau - gemessen an seinem heutigen Niveau - um 1990 herum gestanden habe, also noch vor Taylor, meinte Griese illusionslos und hatte noch einen zweiten Wermutstropfen parat: Es lägen Untersuchungen vor, denenzufolge der Entwicklungsaufwand für Software durchschnittlich ganze 20 Prozent der während eines "Software-Life-Cycles" anfallenden Gesamtkosten ausmache. Damit relativiere sich der Streit der Entwurfsideologen in seiner Bedeutung ganz erheblich, aber auch die Arbeit der Software-Ingenieure.

Umdenken der Mittelbetriebe

"Statements rosten nicht", diagnostiziert Griese bei der Untersuchung der Hintergründe von Software-Alterung und fand heraus, hier gebe es anwendungsbedingte und technologische Ursachen. Den DV-Leuten hielt er ihr Festhalten an uralten Assembler-Programmen vor, mit denen sie - ganz nebenbei - auch einen oftmals nützlichen Systemwechsel verhinderten. Die große Zeit der Standardsoftware - resümierte Griese - werde schon aus Kostengründen kommen. Ein Umdenken in diese Richtung finde bereits von unten, von den Mittelbetrieben her statt. Daß sich bei den Großanwendern hier noch kaum etwas tue, ist für Griese der "Tribut an die Bürokratie der Großen".

Die Datenverarbeitung steckt trotz manch vorzeigbarer Leistung entwicklungsgeschichtlich noch in einer Frühphase - dies wurde auch deutlich, als Werner Paul Org/DV-Leiter bei der Dortmunder Orenstein & Koppel (O & K) AG, berichtete, wie es dem Investitionsgüterkonzern - Beispiele: Baumaschinen, Schiffbau - beim Aufbau seiner vernetzten EDV ging und noch geht. "Zentrale oder dezentrale Datenverarbeitung?" hatte er sich zum Thema gemacht.

Bei der 50prozentigen Hoesch-Tochter O & K mit Produktionsstätten beispielsweise in Hattingen, Ennigerloh und Lübeck, aber auch in Kanada, wollte man eine Datenverarbeitung realisieren, bei der lokale Unabhängigkeit unter Beachtung der typischen Aufgaben einer Konzernzentrale und gleichzeitig Verbindungsaufbauten zwischen beliebigen Rechnern im Netz integrale Bestandteile gewesen wären - das ganze angereichert um einige sofzwaretechnische Anforderungen: nur selektiver, kontrollierter Remote-Datenzugriff, nur eine Anwendungssoftware für gleichartige Anwendungen, Transportabilität ganzer Datenbanken über Leitung.

Aufgrund einer sehr detaillierten Ausschreibung von O & K sandten zehn Hersteller Angebote ein, von denen einige DV-Chef Paul so erschienen, als hätte sie ein flotter Verkäufer unter Zuhilfenahme der vertrieblichen Textverarbeitung zusammengeflickt: Die Software-Preisofferten für das O & K-System variierten zwischen 30 000 und 800 000 Mark. Gegenwärtig - so Paul - "prüfen wir IBMs 8100, Nixdorfs 8860, Tandem oder auch MDS". O & K will sich dann für den "glaubwürdigsten" Anbieter entscheiden. Einstweilen arbeitet O & K mit seiner bisherigen EDV weiter (die auch jetzt schon ein sternförmiges Netzwerk umfaßt).

Das Rechenzentrum in Dortmund ist zur Zeit mit zwei geleasten /370-Maschinen bestückt (-158 und -168), 54 Platten-, 12 Band- und 48 TP-Einheiten; daran hängen - remote und lokal - 344 Bildschirme und 48 Drucker. Systemsoftware-Komponenten sind OS/VS 1 (IMS) sowie BTAM für TP- und RTAM für RJE-Anwendungen.

Bereits seit 1977 erwäge man, wie man "von diesem Wasserkopf wegkommen" könne, kommentierte Paul diese Situation.

Wahrheit liegt im Mixed

Paul machte den Zuhörern klar, daß - zumindest von einer bestimmten Betriebsgröße an - eine eindeutige Alternative zwischen zentraler und dezentraler DV nur noch selten existiere. "Die Wahrheit liegt im Mixed", meinte er, und das gehe so weit, daß auch "zentrale" und "dezentrale" Organisatoren eine Aufgabe gemeinsam anzugehen hätten. Eben diese Erkenntnis fordert aber auch dazu heraus, sukzessive und sorgfältig zu prüfen, wo zentrale und wo dezentrale Lösungen am Platze sind.

Dazu legte Paul eine umfangreiche Check-Liste vor. Sie enthielt beispielsweise eine Prüfung der Funktionen und Betriebsmittel, der Zuständigkeiten, des Datenschutzes und sämtlicher Software-Konditionen. Als zuverlässigste Entscheidungshilfe bezeichnete Paul eine Errechnung der Kosten pro Leistungseinheit - mal bei zentralem, mal bei dezentralem Verfahren. Eine moralische Stärkung der anwesenden DV-Fachleute verabreichte Paul zum Abschluß: Resignation vor einflußreicher Unwissenheit sei nicht angebracht.