Eine "Inventur" der Bestände an Individualsoftware fördert oft Erschreckendes zutage: Die Anzahl der Programme ist meist erheblich größer als angenommen, bisweilen fehlt der Sourcecode, dafür findet sich viel Redundanz. Dieses Chaos rührt daher, so Ernst F. Schierholz, daß so gut wie jede verfügbare Entwicklungsumgebungen den Anwender an entscheidenden Stellen allein läßt.
Nach 30 Jahren emsiger Programmierung haben wir allein in Deutschland einen Berg von etwa 15 Milliarden Codezeilen zu pflegen und verwalten. Dies entspricht Entwicklungskosten von ungefähr 600 Milliarden Mark. Dennoch finden wir diese Investitionen nirgendwo bilanztechnisch aktiviert und abgeschrieben, wie dies etwa bei einem Werkzeugmaschinenpark völlig normal wäre. Dies ist möglicherweise durch unsere Unfähigkeit begründet, die dafür unerläßlichen präzisen Aussagen über Qualität, Normierung und Funktionalität der Individualsoftware zu machen.
Unser Unternehmen hat in den vergangenen Jahren eine Vielzahl sogenannter Software-Inventuren durchgeführt und dabei die gesamte Individualsoftware des Kunden bezüglich den Kriterien Quantität, Qualität, Komplexität, Korrelation und Konsistenz überprüft. Wir mußten feststellen, daß keiner der analysierten Großsystem-Anwender genau wußte, wie viele Programme und Copy-Books-Jobs sich in seinen Bibliotheken befanden beziehungsweise produktiv im Einsatz waren. Generell schließen wir daraus, daß Individualsoftware auch heute noch nicht industriell gefertigt, sondern mehr oder weniger "zusammengeschmiedet" wird.
Einige Beispiele mögen dies verdeutlichen. So fragten wir unsere Kunden, wie viele Software-Einheiten nach ihren Informationen für den produktiven Gebrauch im Einsatz seien. Die eigenen "offiziellen" Zahlen weichen im Durchschnitt über 50 Prozent, im Einzelfall gar bis zu 142 Prozent von der Wirklichkeit ab.
Gehen wir weg von der logischen Ebene "Software-Entität" zur einzelnen Codezeile, so machen wir eine erstaunliche Feststellung: Zwar ist auch diese einfache physikalische Größe mit einer Fehlerquote von etwa 27 Prozent, im Extrem sogar 88 Prozent, behaftet. Andererseits sind die Angaben des Anwenders fast doppelt so genau wie bei der Frage auf der logischen Ebene nach der Anzahl Programme. Hieraus darf man getrost folgern, daß die quantitative Kontrolle auch heute noch am ehesten auf der "Lochkarten"-Ebene (80 Zeichen pro Zeile) möglich ist. Der Hauptfortschritt besteht lediglich darin, daß die Lochkarten nur mehr selten in Papierform existieren.
Werden alle Software-Entitäten gegeneinander abgeglichen (korreliert), so tritt eine teils erhebliche Menge an Programmen zu Tage, die nirgendwo referenziert, also auch nicht gebraucht wird. Wir haben Redundanzen von über 40 Prozent festgestellt, der Durchschnitt liegt bei zirka 14 Prozent.
Der hier betrachtete Anwenderkreis (große DOS/VSE- und MVS-Kunden) verfügt im Durchschnitt über 4000 Einheiten ß 250 Zeilen. Die Entstehungskosten für eine Zeile betragen etwa 40 Mark. Bei einer Redundanz von 14 Prozent kann das pro Anwender auf Fehlinvestitionen von bis zu 5,6 Millionen Mark hindeuten.
In fast allen untersuchten Fällen war es trotz mehrfacher "Nachlieferung" nicht möglich, die gesamte produktiv eingesetzte Individualsoftware tatsächlich bereitzustellen. Im Mittel "fehlten" sechs Prozent. Fehlender Programmcode ist unter anderem deshalb möglich, weil die maschinenlesbare Form des Programmes (Load-Module) unabhängig vom Sourcecode existiert.
Das Fehlen wird erst dann schmerzhaft deutlich, wenn Fehler zu beheben beziehungsweise Änderungen zu machen sind oder wenn aus Systemgründen eine Umwandlung erforderlich ist. In den meisten Fällen läßt sich der Sourcecode mühsam wiederherstellen. Jeder Zehnte unserer Kunden muß sich jedoch damit abfinden, daß einige seiner Programme unwiederbringlich verloren sind.
Von wesentlicher Bedeutung für den Wartungsaufwand ist unter anderem der Grad der Vernetzung. Je mehr Entitäten miteinander durch Aufruf oder sogenannte Copy-Klauseln vernetzt sind, desto höher ist die Fehlerquote bei der Änderung. Der Aufwand für Compile und Link steigt sprunghaft.
Wir haben Fälle untersucht, wo bei 8000 Entitäten Hunderttausende von Vernetzungen auftraten. Wir fanden Hauptprogramme, die über eine fünfstufige Hierarchie Bezug auf nahezu 300 Unterelemente nahmen. Es liegt auf der Hand, daß in solchen Fällen der Hauptaufwand im "Treffen" der richtigen Kombination und nicht in der applikatorischen Anpassung besteht.
Wie ist dieser wenig ermutigende Stand der heutigen Individualsoftware zu erklären. Wir meinen, die Verantwortung liegt hauptsächlich bei den Softwareherstellern. Generatoren und 4GL-Sprachen sollen die Entwicklung beschleunigen. Diese Systeme ignorieren jedoch durchwegs die "Altlasten", nämlich den bereits existierenden Code. Sie vergrößern somit das Chaos.
Die am weitesten verbreiteten sogenannten Entwicklungssysteme entsprechen nur unvollständig unseren Anforderungen an eine solche Plattform (siehe Kasten). Sie sind zumeist passiv und schieben so die Verantwortung wieder dem Anwender zu.
Zum Beispiel gibt es ein französisches System, das den objektorientieren Ansatz propagiert. Bereits bei mittleren Anwendern können dabei Millionen von Regeln ("Rules") entstehen. Der Hersteller hat aber schlicht "vergessen" ein System zum Auffinden dieser Regeln mitzuliefern. So wird aus einer guten Idee schnell ein Spielzeug für Akademiker.
Allgemein ausgedruckt: Es kann nicht Aufgabe des DV-Anwenders sein, Systeme zur industriellen Fertigung von Individualsoftware selbst zu entwickeln. Hier sind die Hersteller von Systemsoftware angesprochen.
Was kann der DV-Manager angesichts der skizzierten Lage tun? Zunächst sollte er eine Inventarisierung seiner Anwendungssoftware durchführen. Bereits bei dem Versuch, die "aktiven" Programmelemente zu identifizieren, lassen sich erstaunliche Feststellungen
machen.
Zweitens sollte der DV-Manager den Versuch unternehmen, die Geschäftsleitung zu erziehen. Die Inventur mag ihm dafür einige Argumente liefern, die ewigen Sorgen über Termine, Ressourcen und Programmfehler liefern die übrigen. Schließlich ist es kein Zufall, daß alles immer länger dauert und mehr kostet.
Die Softwarehersteller geben für Qualitätskontrolle viel Geld aus und planen die dafür notwendige Zeit ein. Warum sollten die Anwenderunternehmen auf diese Maßnahme verzichten können? Ein chinesisches Sprichwort sagt: "Bist Du in Eile, dann setze Dich!" Analog dazu gilt: Es ist oft billiger, Geld auszugeben.
In den 80er Jahren hat sich das Angebot an fertigen Anwendungspaketen enorm vergrößert. Insofern sollten die teuren Programmierer nur dort eingesetzt werden, wo es wirklich individuelle, für das Unternehmen typische und lohnende Aufgaben zu behandeln gilt. Warum muß ein Anwender unbedingt die tausendste Lohnabrechnung verfassend
Ein anderer wichtiger Punkt heißt: Entzaubern Sie die Programmierer! Programmieren ist ein Handwerk. Programme, die nur für den Autor schön und lesbar sind, dürfen also niemals in Produktion gehen. Und ein Programmierer, der darauf beharrt er habe keine Zeit, Kommentare zu schreiben, darf nur noch einen Auftrag erhalten, nämlich den, sein Kündigungsschreiben auszudrucken.
Darüber hinaus müssen einfache Regeln geschaffen werden. Bei unseren Inventuren und Softwaremigrationen treffen wir in diesem Punkt die ganze Bandbreite an, die von überhaupt keinen schriftlichen Richtlinien bis zu riesigen Normierungsbibeln reicht. Es dürfte sich aber niemand finden, der sein Gehalt auf die konsequente Einhaltung dieser Standards verwerten würde. Hier gilt: je einfacher die Regeln sind, desto besser.
"Vertrauen ist gut, Kontrolle ist besser", sagte Lenin. Recht hat er! Was sich nicht maschinell prüfen läßt oder trotz gegebener Möglichkeit nicht maschinell geprüft wird, kann getrost aus den Richtlinien gestrichen werden.
Die letzte Empfehlung lautet: Etablieren Sie die richtige Arbeitsumgebung! Der supereffiziente Full-Screen-Editor und das Byte-sparende Bibliothekssystem sind leider nur untergeordnete Bausteine einer umfassenden Software-Entwicklungsumgebung, die wir "Workframes" nennen.
Aus diesem Rahmen wird jedes Software-Element am richtigen Ort entnommen, selbständig gemäß seiner Eigenschaften wie Status, Sprache, Datenbank sowie Anwendung behandelt und wieder dort abgelegt. Ein Workframe muß also über eine ganze Menge aktiver Intelligenz verfügen, das heißt, er nimmt den Anwender an die Hand und führt ihn.