INNSBRUCK (de) - Über "Entwicklungstendenzen bei der Gestaltung und beim Einsatz von DV-Verfahren" sprach Professor Dr. Joachim Griese, Universität Dortmund, auf dem Softwareforum "Industrie und Handel", das von der Siemens AG in Innsbruck durchgeführt wurde (CW 41 vom 7. Oktober 1977, Seite 1: "Bei der Software tritt die Planung in den Vordergrund"). Hier die Kurzfassung seines Referates.
Software kostet am Markt heute allgemein Geld, und die Tendenzen über die Kostenentwicklung für Hard- und Software, die sieh andeuten, sind etwas beängstigend: Die Hardwarekosten werden mit der Zeit sinken - das hat man im letzten Jahr sehr markant erlebt, dieser Trend wird noch weitergehen - , die Softwarekosten werden jedoch steigen. Ein Spaßvogel hat einmal behauptet, in zwanzig Jahren würden die Hardware-Hersteller die Hardware umsonst hinstellen, wenn man nur ihre Software kauft. Es ist also nützlich, sieh unter dem Kostenaspekt auch einmal mit der Software, im konkreten Fall mit der Gestaltung von DV-Verfahren zu befassen. DV-Verfahren möchte ich als betriebliche EDV-Anwendungssysteme beschreiben: Es gibt eine Reihe von EDV-Anwendungssystemen für die administrative Ebene; es gibt einige für die dispositive Ebene und - wenn wir in der Unternehmenshierarchie nach oben gehen - einige für die planende Ebene.
Durch Dekomposition überschaubarer machen
Dabei kann wiederum unterteilt werden: in Planung, Erhebung und Analyse des bisherigen Anwendungssystems, in Konzept, Entwicklung und Einführung im Betrieb eines neuen EDV-Anwendungssystems. Sichtbar soll dadurch werden, daß man sieh heute bemüht, diesen Gesamtkomplex der Gestaltung durch Zerlegung in einzelne Teile überschaubar zu machen.
Das ist ja auch ein Vorgehen, das wir mit nüchternem Menschenverstand in sehr vielen Situationen wählen: Wenn uns ein Problem zu groß erscheint, dann zerlegen wir es in Einzelteile, die dann handlicher, überschaubarer werden und die wir dann besser angehen und lösen können.
Im Bereich der Gestaltung von EDV-Anwendungssystemen ist es allerdings schwierig, diese "Planungsideologie der Dekomposition" in konkrete Handlungsanweisungen umzusetzen, in konkrete Verfahren, mit denen auch handgreiflich gearbeitet werden kann.
Zwang zur Rechtfertigung
Denn wenn es auch in einigen Fällen möglich ist, sieh bei der Hardware-Beschaffung mit einer gewissen Salami-Technik am Rande durchzumogeln, bei der Software gelingt so etwas nicht so leicht. Insofern wird also der Zwang, diese Entscheidungen durch Argumente zu untermauern, sie der Unternehmensleitung zu verkaufen, immer dringender. Wie könnte man vorgehen, um in der Phase der Planung verläßliche Angaben über Aufwand und Zeitstruktur zu machen, die in den übrigen Phasen des Gestaltungsprozesses anfallen?
Zum einen eröffnen sieh Möglichkeiten mit Hilfe von Schätzverfahren, Aussagen über den Aufwand und die Zeitstruktur zu bekommen, die sieh bei einem gewissen Projekt zur Gestaltung eines betrieblichen Anwendungssystems ergeben wird. Man könnte, wenn man wüßte, daß ein Anwendungssystem 16000 Lines of Code hätte, und man eine gewisse Übersetzungszahl hat, wie viele Lines of Code in einem Mann-Monat erbracht werden können, errechnen, daß 80 Mann-Monate notwendig wären, um dieses Softwareprojekt zu realisieren.
Das ist auf den ersten Blick bestechend, daß das so einfach ist. Man sollte sieh aber darüber im klaren sein, daß kaum einer in der Lage ist zu sagen, das hat so und so viele Lines of Code. Insofern ist dieses Schätzverfahren, das vom Mechanismus her sehr einleuchtend funktioniert, bedenklich, weil Eingangsgrößen nicht zu bekommen sind.
Alle Schätzverfahren, die so zur Zeit in der Literatur beschrieben werden kranken daran, daß die Eingangsgrößen nicht sicher genug formuliert werden können. Sie kranken auch daran, daß man sich heute - insbesondere auf der Ebene der Entwicklung, der Ebene des Programmentwurfes und der Programmierung - in einem technologischen Umbruch befindet und daß diese Schätzverfahren schon deshalb keine Gültigkeit mehr haben.
Verläßlicher mit Projektdatenbanken
Eine Alternative, die heute sehr oft erwähnt wird und die sicher sehr vernünftig ist, wäre die Verwendung früherer Projektdaten. Es gibt beispielsweise im Hause einiger EDV-Hersteller große Projektdatenbanken, in denen die Abrechnungsdaten ab gewickelter Softwareprojekte vorhanden sind, die könnte man hernehmen, um gewisse Rahmenwerte für zukünftige Projekte zu bekommen. Wenn sich etwa aus einer Analyse einer Reihe von Softwareprojekten ergäbe, daß von den 100 Prozent des Aufwandes für ein Projekt:
- 10 Prozent auf die Phase Planung
- 15 Prozent auf Erhebung und Analyse des gegenwärtigen Systems,
- 15 Prozent auf ein Konzept für ein neues System
- 30 Prozent für die Entwicklung dieses Konzeptes
- 20 Prozent für die Einführung und
- 10 Prozent für den laufenden Betrieb anfallen, dann hätte man einen Ausgangspunkt, um solche Schätzungen und solche Planungen durchführen zu können. Dieser Weg, nämlich die Verwendung von Projektdaten, das Auswerten einer Projektdatenbank, scheint verläßlich zu sein, um die voraussichtlichen Kosten eines Software-Projekts zu ermitteln.