BONN - Über die weithin übliche Art der Software-Erstellung und ihre Schwachpunkte, über theoretische Ansätze der Software-Technologie sowie über den Einsatz von Standardsoftware und die Erfahrungen der Anbieter berichtete die Projektgruppe STPMU anläßlich einer Ergebnis-Präsentation, die die Gesellschaft für Mathematik und Datenverarbeitung (GMD) mbH am 13. November in der Bonner Beethovenhalle veranstaltete(CW - Nr. 47 vom 23. 11. 79, Seite 1). Das Projekt STPMU (Software- Technologie-, Produkt-, -Markt-Untersuchung), dessen Schlußbericht für Anfang 1980 erwartet wird, umfaßt auch eine Marktanalyse und -prognose, aus der das Münchener Infratest-Institut in Bonn einige wichtige Erkenntnisse vortrug. (Siehe auch Seite 17).

Die übliche Art der Programmierung charakterisieren die Untersucher folgendermaßen: Von DV-Anwendern wird heute ein beträchtlicher Teil der benötigten Software selbst produziert. "Standard -Softwareprodukte werden oft als zu groß und nicht den speziellen Anforderungen entsprechend abgelehnt.

Der größte Teil der Programmierkapazität (oft bis zu 80 Prozent) wird durch Wartungs- und Änderungsarbeiten gebunden. Diese Arbeiten werden häufig als unkalkulierbares Schicksal hingenommen.

Personenabhängige Programmierung

Die Ausbildung des Personals erstreckt sich im wesentlichen auf die Beherrschung der Programmiersprache(n) und die im Betrieb verwendeten Programmierhilfsmittel. Die Personalfluktuation ist sehr gering (Folge: personenabhängige Programmierung). Neues Personal zu gewinnen ist äußerst schwierig.

Viele DV-Abteilungen arbeiten im Auftrag von Fachabteilungen. Für diese Zusammenarbeit gibt es jedoch sehr viele verschiedene Organisationsformen und Rollenverteilungen. Moderne Methoden der Software-Technologie werden nur in geringem Umfang verwendet, fanden die Untersucher heraus und beleuchteten auch die Ursachen. Viele Firmen befinden sich softwaretechnologisch noch im Experimentierstadium; das Bewußtsein, "etwas tun zu müssen", ist weit verbreitet.

Eingesetzt werden vorwiegend Methoden und Hilfsmittel für

- Programmentwicklung im Dialog,

- rechnergestützte Dokumentations- und Programmverwaltungssysteme,

- Entwurfshilfsmittel und Programmgeneratoren,

- Projektführung und allgemeine Arbeitsregelungen.

Es fehlen weitgehend Methoden und Hilfsmittel für

- Festlegung der (Benutzer-)Anforderungen,

- Zeit- und Kostenschätzung, Fortschrittskontrolle

- Prüfung fron Konzepten und Entwürfen vor der Implementation,

- Test und Abnahme von Software (Testdatengeneratoren haben sich nicht bewährt),

- Unterstützung von Wartung und Änderungen.

Unsichere Methodenbewertung

Der Anwender benötigt für die verschiedenen Tätigkeiten der Software- produktion ein ganzes Bündel von Methoden und Hilfsmitteln. Angeboten werden fast nur Einzelmethoden und -hilfsmittell, deren Kombination unklar ist. Einige Anwender haben sich die Ausarbeitung eines (firmen-)spezifischen Methodenbündels zur Aufgabe gesetzt. Die Umstellung von der stapelverarbeitungorientierten Produktionsweise auf Dialogverarbeitung erfordert beträchtlichen Aufwand, neue Hilfsmittel und Methoden und neue Denkansätze.

Es gibt keine Methoden, die sich heute auf breiter Front durchgesetzt haben. Es herrscht große Unsicherheit bei der konkreten Bewertung einzelner Methoden. Hier fehlen Methoden und Hilfsmittel. Es hat sich gezeigt, daß der Erfolg einer Methode nur zum Teil von der technischen Qualität der Methode selbst abhängt. Andere Faktoren wie Managementunterstützung, Einführungsstrategie und Qualifikation des Personals haben ebenfalls einen großen Einfluß.

Der Einsatz einer (fast beliebigen) Methode führt heute oft schon deshalb zu einer Verbesserung, weil damit eine stärkere Strukturierung und Disziplinierung der Arbeit gegenüber früher verbunden ist. Die Entscheidung für eine Methode bedeutet eine langfristige Festlegung. Die damit verbundener Risiken werden aber vom oberen Management oft nicht mitgetragen.

Verbreitetes Qualitätsbewußtsein

Oft ist pro Jahr nur eine neue Methode durchsetzbar. Die Einführung eines kohärenten Bündels von Methoden für Entwurf, Implementierung, Test und Dokumentation wird damit leicht eine 10-Jahres-Aufgabe.

Der Nutzen der eingesetzten Methoden liegt weniger in der Verkürzung der Entwicklungszeit, mehr in der Verbesserung der Qualität. Konkrete Erfolge zeigen sich oft erst nach langer Zeit (Wartung); manchmal wird auch scheinbar ein Nachteil gegenüber herkömmlichen Projekten beobachtet.

Ähnlich wie in der Bundesrepublik gibt es im Ausland (speziell in den USA) ein verbreitetes Bewußtsein für die Wichtigkeit von methodischem Vorgehen bei der Software-Produktion. Von einer starken Verbreitung "moderner Programmierpraktiken" kann aber auch dort nicht die Rede sein. Der Wartungsanteil liegt im Durchschnitt bei 65 Prozent der Gesamtkosten eines Software Produktes. Eine Möglichkeit zur Senkung dieser Kosten wird nur in einem erhöhten Aufwand für die Anfangsphasen der Entwicklung (Analyse, Definition, Entwurf) und damit in einer Qualitätsverbesserung gesehen.

Ungeklärtes Nebeneinander

Es gibt viele, meist positive Berichte über den Einsatz folgender Methoden (in der Reihenfolge des Ersteinsatzes):

- Strukturierte Codierung,

- Strukturierter Entwurf,

- Top-Down-Entwurf,

- Chef-Programmierer-Team,

- Walkthrough/Entwurf-Code-Inspektion,

- Programmbibliothek,

- HIPO,

- Strukturierte Analyse.

Ein Vergleich der Aussagen ist in der Regel nicht möglich (keine kontrollierten Experimente). Der Nutzen der angewendeten Methoden wird jedoch im allgemeinen eher positiv beurteilt.

Faßbare Gründe für die Ablehnung einer Methode werden kaum berichtet (Ausnahme: Chef-Programmierer Team Organisation). Die Probleme der Methodeneinführung werden gesehen, jedoch keine Lösungen angeboten. In der untersuchten Literatur ist durch alle Erfolgsmeldungen hindurch eine große Unsicherheit Über die geeignete Kombination von Methoden zu spüren.

Wie in der Studie festgestellt wird, kranken die theoretischen Software-Konzepte auch durchweg an einer mangelhaften Berücksichtigung kommunikativer und sozialer Implikationen: Wesentliche Probleme der arbeitsteiligen Software-Entwicklung gehen zurück auf Kommunikationsprobleme. Für diesen Beriecht bietet die Software-Technologie eine Fülle von Konzepten und Darstellungsmitteln. Spezielle Arbeiten über die menschliche Kommunikation im SW- Entwicklungsteam fehlen jedoch.

Einseitige Forschungsaktivitäten

Für die zur Zeit in der DV-Praxis offensichtlichen Probleme der Methodeneinführung (als sozio-technische Aufgabe) sind keine Lösungsansätze gefunden worden. Es gibt nur sehr bruchstückhafte Ansätze für eine Beurteilung von Software und Produktionsmethoden. Die Prüfung der Qualität wird oft verengt auf eine Prüfung oder Abschätzung der Restfehlerzahl. Die Forschung konzentriert sich hauptsächlich auf technische Fragen des Software-Entwicklungsprozesses von der Spezifikation bis zur Implementation. Problembereiche der Praxis wie Test und Abnahme oder Wartung (also Umgang mit bestehender Software) bleiben weitgehend unberührt.

Die meisten theoretischen Ansätze sind als Konzept vorhanden. Eine Aufbereitung für den DV-Anwender, etwa in der Form von Werkzeugen oder Verfahrensvorschriften, wird nicht geliefert. Diese Aufbereitung wird von den Forschungseinrichtungen auch nicht als ihre Aufgabe angesehen. Die neueren Konzepte der Software-Technologie unterstützen oder gehen aus von einer verstärkten Arbeitsteilung. Die hiermit implizierten sozialen Probleme sind bisher nicht sichtbar geworden.

Untersucht wurden auch Verhaltensweisen und Motive der Anwender im Zusammenhang mit Standardsoftware. Für große Anwender sind Werbeschriften, Kataloge und andere Anbieter-Informationen nur halb so wichtig wie Kontakte zu anderen Anwendern und die Lektüre von Fachzeitschriften. Für kleine Anwender besitzt Information durch den Anbieter jedoch 70 Prozent von der Bedeutung, die die Anwenderkontakte haben. Benutzervereinigungen und Fachzeitschriften als Informationsquellen haben hier nur je 40 Prozent der Wichtigkeit, die den Anwenderkontakten zukommt.

Wichtigste Einzelkriterien bei den Anforderungen der Anwender an die Software sind:

1) Übereinstimmung mit Anforderungsprofil.

2) Anbieter-Fachkenntnisse,

3) Kompatibilität zu vorhandenem System,

4) Probeinstallation (vom großen Anwender).

Bei zwei Dritteln der Anwender findet (nur) ein informeller Auswahl-/Entscheidungsprozeß statt. Nur bei 50 Prozent der Anwender wurden mehr als zwei Produkte in die Auswahl genommen. Gründe gegen Eigenerstellung: keine ausreichende Personalkapazität (88 Prozent), Termine (63 Prozent), Kosten/Leistung (50 Prozent).

Erfahrungen bei der Installation der Produkte: problemlos (43 Prozent), diverse Probleme (57 Prozent) der Anwender. Vorhandene Datenbestände mußten angepaßt (41 Prozent) oder Umsetzprogramme permanent eingesetzt werden (32 Prozent).

Wünsche der Anwender:

- Unabhängigkeit der Produkte von den physischen Datenstrukturen; abstrakte Datentypen (84 Prozent),

- Kooperation der Anbieter zwecks Abstimmung (74 Prozent),

- Angebot von Programmrahmen, in die der Anwender individuelle Teile einsetzen kann (58 Prozent),

- Endmontage von Bausteinen sollten Anbieter, Fachhändler oder Servicebüro (52 Prozent), die Anwender selbst (48 Prozent) durchführen.