Wenig Teamwork, überproportionaler Wartungsaufwand, Mangel an qualifiziertem Personal sowie unzureichende Rechnerleistung sind wichtige Gründe für die sogenannte Softwarekrise. Die Lösung: Rationalisierung des Rationalisierungsinstruments Softwareentwicklung.
Im Wachstumsmarkt Nummer eins unserer Wirtschaft, dem Softwaremarkt, kriselt es. Das Schlagwort vom Backlog - gemeint ist der Auftragsüberhang in den Entwicklungsabteilungen von Computerherstellern und Großanwendern - geht um. Dabei wurden 1987 für Software in Deutschland 19 Milliarden Mark aufgewendet. Das sind rund 30 Prozent des europäischen Software-Umsatzes. Für 1991 prognostiziert das Marktforschungsinstitut IDC, Eschborn, einen europäischen Gesamtumsatz von 91 Milliarden Mark. Der deutsche Softwaremarkt wird sich nach Schätzungen des VDMA dann auf 38 Milliarden Mark belaufen, was in nur vier Jahren ein Wachstum um 100 Prozent bedeuten würde.
Auf herkömmlichem Weg ist keine Lösung des Backlog-Problems in Sicht, da Fachleute schon heute den Auftragsüberhang in der Software-Entwicklung auf über drei Jahre schätzen. Dieser Trend ist nicht erst seit gestern bekannt. Das US-Verteidigungsministerium hat festgestellt, daß der Anteil der Software-Kosten am gesamten DV-Aufwand in der Zeit von 1955 bis 1985 kontinuierlich von zuerst 20 Prozent auf fast 90 Prozent gestiegen ist. Nun mögen US-Army und -Air-Force kein Maßstab für deutsche Anwender und Hersteller sein, aber symptomatisch sind die Zahlen zumindest als Trend allemal.
Ohne DV geht nichts mehr in der Wirtschaft
Es stellt sich zunächst die Frage, wie in Großunternehmen heute Software erstellt wird, und worin die Herausforderung an die Softwareentwicklung besteht. Die Erstellung neuer Softwarepakete wird durch zwei Faktoren wesentlich bestimmt: Einmal bedingen die ständig steigenden Anforderungen der Anwender Neuentwicklungen von Programmpaketen. Andererseits verlangen neue Rechnergenerationen und Anwendungsgebiete (Stichwort: CIM) nach neuen Programmstrukturen.
Von der Datenverarbeitung versprechen sich heute die Unternehmen und Behörden so große Rationalisierungseffekte wie bisher von keinem anderen Werkzeug. Man kann getrost sagen, daß ohne DV in unserer Wirtschaft gar nichts mehr geht. Das gilt gleichermaßen für die technische Entwicklung wie für den Dienstleistungsbereich im weitesten Sinn. Dabei werden die Programme mit zunehmender Anwendungsbreite immer umfangreicher, verzweigter und komplexer, eine Tatsache, der zentrale Bedeutung bei Betrachtungen über die Softwareentwicklung zukommt. Große Unternehmen beschäftigen oft Hunderte von Softwareentwicklern und beklagen dennoch den "Auftragsstau". Woran liegt das?
Die Entwicklung von DV-Programmen wird oft als die kreative Leistung eines einzelnen verstanden. Das Bild vom einsamen Programmierer mit Kaffeetasse und Zigaretten zu später Nachtstunde vor seinem Bildschirm ist noch weit verbreitet. Die Möglichkeiten der Teamarbeit finden also kaum Beachtung.
Bei aller Würdigung der Individualleistung darf jedoch nicht übersehen werden, daß Gruppenarbeit nicht zu ersetzen ist. Der allein arbeitende Entwickler geht in Urlaub, wird krank oder verläßt das Unternehmen - das Projekt gerät ins Stocken und muß unter Umständen erneut begonnen werden - eine Reihe von Gründen für den Auftragsüberhang.
Eine andere Ursache wiegt weit schwerer: Die vorhandenen Programmpakete müssen ständig gewartet werden. Gesetzliche Bestimmungen ändern sich, technische Abläufe werden modifiziert oder die Organisation des Unternehmens umstrukturiert - alles Gründe, die zu Programmänderungen führen.
Technische Mängel an Programmen, die oft erst nach längerem Einsatz auffallen und bei konventionellen Entwicklungsmethoden trotz umfangreicher Tests nicht vermeidbar sind, zwingen ebenfalls dazu, ständig an "fertigen" Programmen zu arbeiten. Fachleute behaupten, daß der Wartungsaufwand rund 70 Prozent der Kapazität der Entwicklungsabteilung bindet. Das Entwicklungsvolumen für neue Programme wird dadurch erheblich dezimiert. Eine Änderung der Software-Entwicklungstechnologie ist somit dringend erforderlich.
Die Kostenexplosion ist ein weiterer kritischer Punkt. Für den Arbeitsplatz eines Entwicklers müssen an die 10 000 Mark pro Monat aufgewendet werden. Das erfordert bei einer 50köpfigen Entwicklungsabteilung einen monatlichen Gesamtaufwand von einer halben Million. Berücksichtigt man, daß davon bis zu 70 Prozent im Wartungsbereich verschwinden, so verbleibt für Neuentwicklungen nur noch ein Drittel des vorhandenen Budgets - bei einem ständig steigenden Bedarf an neuer Software ein viel zu geringes Volumen.
Es bietet sich hier der Einsatz externer Softwareentwickler an; damit ist aber eine weitere Kostenprogression verbunden. Dem Ausbau der Softwareproduktion setzen neben den Kosten auch andere Gründe Grenzen: Einmal fehlt es auf dem Arbeitsmarkt an qualifizierten Fachkräften, zum anderen ist die vorhandene Rechnerleistung eine Barriere. Wenn man bedenkt, daß über 60 Prozent der Programmierarbeit aus Testläufen bestehen, die viel Rechenzeit erfordern, so ist leicht ersichtlich, daß entweder die Kapazität des Host oder der Entwicklungsrechner bald erschöpft ist. Wird auf einem Zentralrechner programmiert, steht dieser zudem für seine eigentliche Aufgabe - das Tagesgeschäft - nicht in vollem Umfange zur Verfügung.
Die Softwareentwicklung ist also in der grotesken Situation, daß sie als Träger der Rationalisierung selbst nicht rationalisierbar zu sein scheint. Die dringend erforderliche Verbesserung der Wirtschaftlichkeit geht an der Softwareentwicklung bisher offensichtlich vorbei.
Leistungsdruck schadet der Qualität
Die geschilderten Umstände, nämlich Auftragsüberhang und Kostenprogression, veranlassen häufig das Management eines Unternehmens verstärkten Leistungsdruck auf die Software-Entwicklungsabteilung auszuüben. Das trägt sicher nicht zur Verbesserung neuer Programmsysteme bei. Unter Zeitdruck arbeitende kreative Mitarbeiter können keine hundertprozentige Qualität erbringen.
Die Folgen sind vermehrte Testläufe und die oft beklagten Mängel in der Dokumentation. Auf der einen Seite steigen damit wieder einmal die Kosten, auf der anderen Seite entstehen bei den Anwendern Unzufriedenheit und erhöhter Wartungsaufwand mit den bereits erwähnten Folgelasten. Sind mit einem Projekt oder Teilprojekt mehrere Entwickler nacheinander beschäftigt, so kommt zu den Schwierigkeiten hinzu, daß unterschiedliche "Handschriften" im Programm vorkommen. Brüche in der Abfolge algorithmischer Gedankengänge können Fehler produzieren.
Bei Großprojekten treten weitere Probleme in der Qualität der Programme auf. Ein Softwareprojekt läßt sich nicht in beliebig kleine Teile zerlegen. Mißachtet man diese Tatsache, so entstehen Instabilitäten, die sich sowohl in der Realisierung der Programme als auch im praktischen Betrieb sehr nachteilig auswirken können. Eine aus Zeitgründen oft vernachlässigte Qualitätssicherung trägt außerdem dazu bei, daß sich Fehler in die Systeme einschleichen, die oft zu spät entdeckt werden.
Eng mit den Qualitätsproblemen verbunden ist die fehlende Integration innerhalb der Entwicklungsumgebung. Das gilt sowohl für die verwendeten Werkzeuge, denen oft die gleichartige semantische Interpretation von Schnittstellenobjekten fehlt, als auch für die Verwendung einer von allen Entwicklern gemeinsam nutzbaren Objekt-Datenbank. Es ist aber gerade der Mangel an Integration, der die Arbeit des Entwicklers erschwert und verlangsamt.
Rationelle Methoden müssen eingesetzt werden
Die einzelnen Teile des Projektes, von verschiedenen Mitarbeitern erstellt, fügen sich nicht nahtlos aneinander. Erschwerend kommt in solchen Produktionsumgebungen hinzu, daß sie die Arbeit der Individualisten und nicht den Teamgedanken fördern. Fällt dann dieser Spezialist aus irgendwelchen Gründen aus, ist das gesamte Projekt - oder zumindest Teile davon - in Gefahr. In jedem Fall führt das zu Verzögerungen und zu Mehrkosten. Besonders schwer wiegt dieses Problem bei der Dokumentation, die erfahrungsgemäß viel Entwicklungszeit kostet. Die häufig anzutreffenden "Insellösungen" behindern ein Zusammenfügen unterschiedlicher Programmierleistungen zusätzlich.
Ein weiterer Schwachpunkt in der Software-Entwicklung ist die fehlende Standardisierung. Das zeigt sich in nicht kongruenten Phasenmodellen und in unterschiedlichen Entwicklungs-Tools. Negativ sind die Auswirkungen sowohl für den Prozeß der Entwicklungsarbeit als auch für das Produkt selbst. Besonders hinderlich wirkt sich das in der Analyse- und Entwurfsphase aus, da hier eine falsche Weichenstellung das gesamte Projekt in die verkehrte Richtung führen könnte.
Zudem behindert die fehlende Standardisierung eine sinnvolle Projektsteuerung. Ohne einheitliches "Handwerkszeug" ist es praktisch unmöglich, Vorgaben zu errechnen oder auf unvermeidliche Änderungen im vorgeplanten Projektverlauf zu reagieren. Dies ist einer der wichtigsten Gründe, warum in vielen Entwicklungsabteilungen Termine überschritten, Etats überzogen und Produkte minderer Qualität ausgeliefert werden. Überdies behindert das Fehlen von Standards die Übergabe der Teilaufgaben an andere Mitarbeiter, was wiederum das Spezialistentum fördert.
Die bisher aufgezeigten Mängel der traditionellen Softwareentwicklung beeinflussen nicht nur die wirtschaftlichen Ergebnisse des Unternehmens. Sie behindern in starkem Maße auch die Innovationskraft der Entwickler selbst. Wer unter ständigem Zeit- und Kostendruck arbeiten muß, wird nach Möglichkeit immer den Weg des geringsten Widerstandes gehen, also nach einfachen und nicht immer nach den besten Lösungen suchen. Das gerade ist es aber, was die Datenverarbeitung beim Anwender ins Zwielicht bringt.
Die Mängel beginnen beim schlechten Maskenaufbau, gehen weiter über umständliche Eingabeverfahren und enden bei unübersichtlichen Ausdrucken auf schlecht gestalteten Formularen. Wäre der Entwickler von der täglichen Kleinarbeit entlastet und könnte sich auf seine eigentliche, kreative Ingenieurarbeit konzentrieren, würde in der Softwarelandschaft manches anders aussehen.
Das Resümee: In der Software-Entwicklung muß nach Wegen gesucht werden, die geeignet sind, den Auftragsstau abzubauen; es müssen endlich rationelle Arbeitsmethoden eingesetzt werden. Der Weg führt in Richtung "Computer Aided Software Engineering". Das bedeutet, eine integrierte Software-Produktions-Umgebung zu schaffen, die sowohl den technischen als auch den ökonomischen Anforderungen entspricht.