MÜNCHEN (hh) - Auf fast zwei Milliarden Mark wird das Volumen des deutschen Software-Marktes geschätzt. Unter dem aktuellen Gesichtspunkt von Kostenexplosion und Personalknappheit diskutierten in München Weichwerker von Anwendern und Anbietern neue Wege, "bessere Software zu produzieren". Unter diesem Motto stand ein Symposium der CSE-CW Communications Services & Education, München, an dem rund 120 DV-Spezialisten teilnahmen. Die COMPUTERWOCHE berichtet in zwei Folgen über das "Softwareforum 1981". Der erste Teil behandelt die aktuelle Situation des deutschen Software-Marktes und umreißt Kerngedanken zur Ausbildung. Im zweiten Teil heißt das Thema in "Programmiersprachen" und "Software-Produktionsumgebung".
"Software is a gentle word for a tough problem", mit diesen Worten leitete Dieter Jekat, Geschäftsführer der Nomina GmbH, München, seinen Vortrag über die aktuelle Lage des Software-Marktes in der Bundesrepublik ein. Derzeit sind dem Unternehmen aus der Auswertung des im gleichen Hause produzierten Isis-Kataloges 2810 Software-Produkt-Angebote bekannt. Diese Zahl sei um gut 500 Produkte höher als im Vorjahr (2293), sagte Jekat, wobei die Steigerungsrate der branchenspezifischen Anwendungssoftware (+ 175) vor der kommerziellen Anwendungssoftware (+ 161) und Systemsoftware (+ 93) liege. Technische Anwendungssoftware verzeichnet einen Zuwachs um 80 Produkte.
Als Programmiersprache behauptet sich nach Berechnung der Münchner eindeutig Cobol, betrachtet man das gesamte Produktangebot. Den 28,8 Prozent Anteilen dieser Sprache folgt dichtauf Assembler mit 21,4 Prozent. Das Mittelfeld bilden Fortran (14,9), Basic (14,5) und RPG (10,9). Als Schlußlicht dann PL/ 1 mit nur 1,3 Prozent der Anwendungen.
Bei den kommerziellen Programmen führt Cobol als Programmiersprache mit 42 Prozent. Das Mittelfeld mit 14 bis 9 Prozent besteht aus RPG, Basic und Assembler.
Basic im Kommen
Aufgefächerter sieht der Einsatz der Programmiersprachen bei Branchenpaketen aus: Zwar liegt auch hier Cobol vorne, aber Basic schließt mit 26,1 Prozent dicht an den Cobol-Wert an.
Fortran ist der Renner bei der Programmierung technischer Programmpakete: 62,4 Prozent. Basic hat auf dem zweiten Rang immerhin noch einen Anteil von 11,5 Punkten. Für die Einsatzhäufigkeiten anderer Sprachen werden fast nur noch Werte hinter der Komma gezählt.
Die große Stärke der Systemprogrammierer liegt bei Assembler. Diese Sprache wird in 50 von 100 Fällen als Favorit gewählt. Aber auf diesem Gebiet macht sich auch, Cobol, wieder stark mit 19,6 Prozent. Die restlichen verfügbaren Sprachen bewegen sich um den Fünf-Prozent-Bereich.
Auf der Basis von 878 Programmen des Isis-Kataloges mit Kaufpreisangaben errechnen sich Kosten zwischen 10 000 und 20 000 Mark für 21,6 Prozent der Gesamtprodukte. Fast gleichauf liegen die Programme in der Klasse vor 5000 bis 10 000 Mark mit 21,0 Prozent. Nur 4,9 Prozent kosten über 100 000 Mark, 12,3 Produkte aus 100 sind bis zu 5000 Mark zu haben. Unterteilt man nach Anwendungsgebieten, so verschieben sich die Anteilswerte bei Branchen-Paketen nur geringfügig in teurere Regionen, während bei technisch/wissenschaftlichen Programmen ein Trend zu unteren Preisklassen bis 10 000 Mark zu verzeichnen ist. Das derzeitige Marktvolumen betrage 1,6 bis 1,7 Milliarden Mark so
Jekat.
Zu sprechen kam Jekat auch auf aktuelle Probleme des Software-Marktes und der produzierenden Unternehmen.
So stellte er fest, daß in Deutschland nur relativ wenige Großanbieter von Software existieren. Die Mehrzahl der Unternehmen beschäftige unter 50 Mitarbeiter. Ein weiteres Kennzeichen der deutschen Situation sei die oftmals geringe Kapitaldecke der Unternehmen.
Nur wenige Produkte dieses Marktes würden exportiert, befand Jekat. Der Import erstrecke sich hauptsächlich auf System-Software.
Babylonische Terminologie
Der Vortragende bemängelte, daß in der Bundesrepublik wenige Tools für die Konzeptionierung, dafür um so mehr für die Realisierung zur Verfügung stünden. Hierbei sei eine unterschiedliche Terminologie Fortschritten hinderlich, Obwohl keine eindeutige Meßgröße für Software existiere, müsse man nach Jekats Meinung zu einem konstruktiven Wettbewerb kommen.
Über die zukünftige Entwicklung meint Jekat auch einen stärkeren Wettbewerb zwischen Software-Häusern und Hardware-Herstellern auf dem behandelten Sektor voraussagen zu können. Es bedürfe neuer Marketing-Überlegungen, wobei der Massenmarkt nicht vernachlässigt werden darf. Auch sei in absehbarer Zeit mit einem Einstieg der Japaner ins Software-Business zu rechnen.
"Ist die Software-Krise ein Resultat der Ausbildung?", fragte Professor Dr. Christiane Floyd die Seminarteilnehmer. Für die Professorin der TU Berlin hat sich diese Krise, aus der heraus das Software-Engineering entstanden ist, gewandelt. Ging es Ende der 60er Jahre um die Qualität der Software und der Software-Erstellung, so liege die Problemstellung heute darin, eine drohende "Systemkrisen" zu vermeiden. Als Ursache dafür sieht Professor Floyd, daß Software ohne die hinreichende Kenntnis über die langfristigen Auswirkungen am Einsatzort in großen Mengen produziert wird und daß die Software langlebiger wird. In vielen Fällen gelinge es nicht, sich- von unangemessener: Software zu trennen, meint die Professorin.
Zudem hätten sich die Schwierigkeiten von der Produktion ins Vor- und Umfeld verlagert, so eine These der Lehrstuhlinhaberin. Eine wichtige Rolle bei der Bewältigung dieser Problemstellungen spiele die Ausbildung, wobei die universitären Aktivitäten auf andere Bereiche einwirken.
Dennoch bestehe zwischen Theorie und Praxis ein Spannungsfeld, das sich auf die Situation an den Universitäten niederschlägt. So werden vielfach veränderte Anforderungen aus der Praxis nicht an die Hochschulen übermittelt. Ein Student, der heute die Hochschule verläßt, sollte in der Lage sein, größere Programmesystematisch erstellen zu können so eine der Floydschen Forderungen. Dazu werden in Berlin zunehmend praxisrelevante Projekte durchgeführt, wobei Spezifikationsmethode und Projektorganisation nach dem Phasenmodell Verwendung finden.
Dennoch gebe es Lücken in der theoretischen Ausbildung. Diese zu schließen sei nicht nur Aufgabe der Universität, sondern auch der Praxis, schloß Professor Floyd die Ausführungen.
Kommunikationskatalysator
Als Mittler bezeichnet Karl Steinmayr, Sektionsleiter Konzern-Organisation der Deutsche Babcock AG, Oberhausen, den EDV-Organisator, der zwischen DV- und -Fachspezialisten steht. Ihm obliege die Aufgabe, DV-gestützte Anwendungen bis zur programmreifen Vorgabe entwickeln. Dabei liege es in seiner Hand, dem DV-Spezialisten den Weg zum Anwender aufzuzeigen, umreißt Steinmayr.
Damit ein gutes Ergebnis der Arbeit erzielt wird, bedarf es einer umfangreichen fachlichen Grundausbildung und einer praktischen Hinführung zu der Aufgabe. Hierbei habe
sich gezeigt, daß ein Mitarbeiter in dieser Tätigkeit schwerpunktmäßig Anwenderwissen benötigte, was nicht nur durch Seminare erreicht werden könne.
" Training on the job" gebe in dieser Funktion einen guten Blick über die Qualität der Programme, über die Probleme der Anwender und auf der anderen Seite über die Leistungsfähigkeit des Rechenzentrums und der eigenen Hardware.
Als eine wesentliche Voraussetzung für ein erfolgreiches "Training on the job " betrachtet Steinmayr die Anleitung durch einen Senior-Organisator, der den vorgesehenen Mitarbeiter mit den Besonderheiten des Unternehmens und der Arbeitsweise der einzelnen Abteilungen vertraut mache. Auch die Fachabteilungen ihrerseits sollen Verständnis für den "Trainee" zeigen.
Steinmayr sieht die Vorteile einer Ausbildungsmethode in der kontinuierlichen Weiterführung der Organisationsarbeit und einer Förderung der Kooperationsbereitschaft aller Beteiligten. Durch gründliche Vorbereitung eines Anwenderprogramm-Systems im Dialog mit den Fachabteilungen hielten sich, so seine Erfahrungen, Änderungswünsche in Grenzen, und eine größere Akzeptanz werde erzielt.
Mit der Frage, wie Software-Engineering-Methoden in die Praxis übertragen werden können, beschäftigte sich Dr. Horst Strunz, stellvertretender Geschäftsführer der MBP, Dortmund, in seinem Referat. Viele Anwender neigten aufgrund des Tagesgeschäftes und einer Unsicherheit über die richtige Vorgehensweise dazu, Software-Engineering-Methoden nicht einzusetzen, umreißt Dr. Strunz die gegenwärtige Situation. Probleme des Methodentransfers ergeben sich aus mangelnder Information und Abschreckungseffekten durch Methodenstreits unter Fachleuten. Auch sieht Strunz Probleme der Methodenkombination, die in Unsicherheit über Methoden und ihre Leistungsfähigkeit begründet liegen." Welche Möglichkeiten der Implementierung softwaretechnischer Methoden gibt es aber nun?" fragt der Redner. Sein Unternehmen habe Transferprozesse untersucht und sei zu folgender Klassifizierung gelangt:
þPolitik der kleinen Schritte,
þBeginn mit Software-Tools,
þDemonstrationsprojektansatz,
þPilotprojektansatz,
þpartizipative Verfahrensentwicklung
Die Politik der kleinen Schritte sei wohl am häufigsten anzutreffen, meint Dr. Strunz, berge aber auch Gefahren, da sie in der Regel nicht sinnvoll geplant ist. Mit "Software-Tools" beginnen, könne eine gute Strategie sein, doch solle das Vorhaben mit der Implementierung nicht abgeschlossen sein.
Bei der Strategie "Demonstrationsprojekt" gehe man davon aus, mit der erfolgreichen Anwendung einer Methode in einem kleinen Projekt und der Demonstration der positiven Ergebnisse den zukünftigen Anwender zu überzeugen. Die Einschränkung auf ein kleines Projekt bedinge, daß in der Regel die nicht beteiligten Mitarbeiter nicht voll überzeugt würden, erläutert Dr. Strunz. Beim Versuch mit Pilotprojekten ist ein effizientes "Methoden-Monitoring" notwendig, um den Einfluß der Methoden objektiv erkennbar zu machen. MBP habe ein "partizipatives Verfahren" entwickelt, berichtet Dr. Strunz bei dem die betroffenen Mitarbeiter an der Informationssammlung, Beurteilung und Einführung beteiligt sind.
Transferprozesse seien, so führt Dr. Strunz nach den Erläuterungen über diese Methode aus, wie auch Entwicklung und Einführung von DV-Systemen in Fachabteilungen organisatorische Gestaltungsmaßnahmen, und unterliegen gleichgearteten Regelungen und Vorgehensweisen wie in einem Software-Entwicklungprozeß. (wird fortgesetzt)