Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

28.01.1977 - 

Die neuen Software-Tools:

Funktionsstandards fehlen!

Von der permanenten Softwarekrise soll die Rede sein und der Skepsis vieler Anwender gegenüber Methodensoftware wie Programmierhilfen und Generatoren - was sich am augenscheinlichsten dadurch dokumentiert, daß die neuen "Werkzeuge" im Durchschnitt nicht mehr als fünfmal installiert sind. Indes: Wer sich diesem Problemkreis nähern will, ist gehalten, mit endgültigen (stabbrechenden oder allzu enthusiastischen) Urteilen zurückhaltend zu sein.

Ob die professionellen Software-Spezialisten so in der "Klemme" zwischen Hardware-Hersteller und Anwender sitzen, wie es CW-Zeichner Claus Witt sieht, oder ob sie sich nicht vielmehr in einer selbstgestellten Falle gefangen haben, anscheinend unentrinnbar darin zappeln - weil sie sich nämlich gegenseitig lahmlegen: Diese Frage (unter anderen) stellten wir 30 Firmen, die im neuen Isis-Software-Report 1/77 Systemsoftware anbieten, und darunter eben software-technologische Tools. Ersteres dürfte zumindest zum Teil richtig sein: Wo von den Herstellern Anwendungspakete en masse "für`n Appel und `n Ei" angeboten werden, und wo auf der "anderen" Seite insbesondere die Systemprogrammierer beharrlich an "Althergebrachtem" festhalten, sich querlegen, wenn es um die Verbesserung ihrer eigenen Arbeitstechniken geht, da kann es Methodensoftware nicht leicht haben. Zumal insbesondere kleinere und mittlere Anwender mit auch nur kleinen Programmier-Teams eigentlich immer Alltagsprobleme zu lösen haben.

Andererseits - und das betrifft die zweite, für die Softwarebranche weniger angenehme Behauptung: Jeder kocht sein eigenes Süppchen, zu viele wollen das "Non-plus-ultra" gefunden haben - wer soll da noch großes Vertrauen in "hochgradig" erklärungsbedürftige Softwaresysteme haben, die sich als "black box" darstellen?

Zudem sind - wie zugegeben wird - erst wenige Produkte einfach bedienbar und den Benutzerwünschen angepaßt. Das Gegenargument, der Anwender wisse letztlich gar nicht, was er wolle, sticht so lange nicht, wie es an Versuchen von seiten der Anbieter fehlt, Funktionsstandards zu definieren. Wenn schon von "Werkzeugen" gesprochen wird, neuerdings gar von "Software-Engineering", dann muß es sich die Softwarebranche auch gefallen lassen, an diesem Anspruch gemessen zu werden. Es ist an der Zeit, daß Produktionsspezifikationen festgelegt werden, daß beschrieben wird, was beispielsweise ein Generator können muß - dann weiß der Anwender wenigstens, worauf er beim Kauf von Software achten muß de

Im folgenden - auszugsweise - die Stellungnahmen derjenigen Softwarehauser, die uns geantwortet haben.

Wenn von der Software-Krise die Rede ist, sollte erwähnt werden, daß sie erstens noch schwerer gewesen wäre, wenn Software-Häuser nicht existieren würden, sie zweitens bereits dem Ende entgegengeht und wir drittens alle froh sein sollten, daß es sie gab. Schließlich sind wirklich brauchbare neue Ideen fast immer aus Krisen heraus entstanden. Daß die Herstellung von Softwarewerkzeugen aufgrund dieser neuen Ideen beim Softwarehaus gut aufgehoben ist, daran kann es keinen Zweifel geben. Kein anderes Entwicklungsteam hat gegenüber der Mannschaft eines Softwarehauses irgendeinen Vorteil - sowohl in qualitativer als auch in quantitativer Hinsicht. Daran muß der Wert des Entwicklungsergebnisses gemessen werden. Die Softwarewerkzeuge, die wir in den nächsten Jahren haben werden, sind das Resultat organisierter Kreativität. Und gerade auf diesem Gebiet liegt die Stärke des Softwareherstellers. Wenn die Produkte bislang bei einem Großteil der Anwender auf wenig Gegenliebe gestoßen sind, so liegt dies im wesentlichen an den betreffenden Produkten selbst.

Auch größere Vertriebskräfte können die Produkte nicht brauchbarer machen. Solange die Technologie nicht in ein gewisses Reifestadium getreten war, ließen sich die Anwender kaum überzeugen.

Die Methode, auf der ein Software-Werkzeug basiert, ist entscheidend für dessen Erfolg. Sie entsteht aus intensiver Forschungs- und Entwicklungstätigkeit, die ein Softwarehaus mit großem Aufwand betreiben muß, wenn es erfolgreich sein will.

Wir teilen die Gründe, die nicht zum befriedigenden Einsatz von Normierter Programmierung (NP) führen, in eine anwender- und eine herstellerbezogene Gruppe ein.

Auf der Anwenderseite sperren sich "eingefahrene Kräfte" gegen das Umdenken und setzen die Einführung von NP mit einer Minderbewertung ihrer bisherigen Arbeit gleich.

Die Erwartungen in der Zeit des ersten Einsatzes von NP sind häufig zu hoch gesteckt: stellt sich nach der Abwicklung von wenigen Programmen heraus, daß keine Zeitersparnis erzielt wurde, so wird die NP nicht länger eingesetzt. In diesem Zusammenhang erscheint die Wahl der Basis für den Zeitvergleich besonders interessant.

Die Schulung in NP wird nicht für alle Mitarbeiter der Programmierabteilung durchgeführt. Fehlende Kontrollen nach Einführung der NP, die sicherstellen sollten, daß die NP durchgängig eingesetzt wird, sorgen dafür, daß das Prinzip einheitlicher Programmier-Richtlinien nie ernst genommen wird.

Die Kosten für den Kauf des NP-Generators und für die Schulung in NP stehen fest; die Vorteile lassen sich erst erkennen, wenn das Prinzip der NP erkannt ist. Die Einsparungen, die durch einen konsequenten Einsatz der NP möglich sind, erscheinen so hoch, daß sie schon beginnen, unglaubwürdig zu werden.

In den Verkaufsgesprächen der Hersteller werden dagegen die Aufwendungen, die der Anwender erbringen muß, bagatellisiert, so daß der Anwender für die Zeit des ersten Einsatzes von falschen Voraussetzungen ausgeht; doch gerade in dieser Zeit entscheidet sich, ob die NP auch tatsächlich eingesetzt wird.

Das Interesse des Herstellers erlischt mit dem Verkauf des NP-Generators; die Schulung der Mitarbeiter des Käufers wird vernachlässigt.

Dem fortschrittlichen EDV-Anwender von gestern, der sich von den Vorzügen verschiedener Software-Werkzeuge zur Programm-Generierung, Entscheidungstabellen-Umwandlung, Listgenerierung, Dokumentationserstellung etc. überzeugen ließ, treibt es heute die Tränen in die Augen, wenn er zusehen muß, wie es mehrerer Generierungs- und Umwandlungs-Prozesse bedarf, bis endlich das Endprodukt, nämlich ein gut dokumentiertes ausgetestetes Programm, auf dem Tisch liegt. Die unbestreitbaren Qualitäten der einzelnen Generatoren heben sich in der Summe wieder auf.

Die Lösung kann hier nur heißen: Integration der Einzellösungen zu einem Konzept untereinander verträglicher modularer Generatoren, die gezielt eingesetzt werden können. Daß es solche "Paket-Lösungen" bereits gibt, ist vielen Anwendern noch unbekannt. Diejenigen, die es wissen, scheuen sich häufig vor dem organisatorischen Aufwand, der zur Einführung notwendig ist oder weil es nach herkömmlicher Methode ja auch noch ganz gut geht, oder weil das Tagesgeschäft solche Überlegungen im Augenblick nicht zuläßt, oder weil gerade ein DB-System evaluiert wird, oder. . . oder.. .

Meistens sind die Argumente stichhaltig, doch in ein paar Jahren, wenn die Hardware-Technologie den Methoden der Anwendungssoftware nicht nur um Nasenlängen, sondern gleich um mehrere Köpfe voraus sein wird, dürfte es häufig zu spät sein, über die Innovationsgeschwindigkeit unseres Metiers nachzugrübeln.

Und, ob es eines Tages einen Chip für Lohn und Gehalt, einen für das Bachnungswesen, einen für die Materialwirtschaft und so weiter geben wird, das ist doch noch sehr fraglich.

Zur Definition: Eine software-technologische Entwicklung muß realisieren, daß

- ein konfigurierbares System auf die individuelle Situation des Anwenders bei gleichzeitiger Adoption vorhandener Normen angeboten werden kann, - unabhängig von EDV-Systemen organisatorische Strukturen in Regelkreisen abgebildet werden können,

- Logik ( = Anwendungsprobleme) und Technik (=EDV-Realisierung) in der Entwicklung, Wartung und Pflege getrennt dokumentiert sein müssen,

- existierende EDV-Systeme in die gleiche Systematik überführt werden können,

- ein Herstellerwechsel vereinfacht wird und

- der Computer von der Analyse bis zur Realisierung und Wartung als "Werkzeugmaschine" den Taktgeber darzustellen hat.

Die Entwicklung von leistungsfähigen Einzelgeneratoren begann vor sieben Jahren. Geschlossene Systeme den oben definierten Ansprüchen gerecht, wurden erst seit zirka drei Jahren konzipiert und teilweise realisiert. Ihr Entwicklungsaufwand muß die Finanzkraft eines einzelnen Software- Hauses überfordern, weil "eine Idee haben", eine Sache ist; sie zu realisieren, eine andere - nämlich eine kostenaufwendige. Und beides zu institutionalisieren, im Minimum noch einmal soviel Kosten erfordert wie die beiden ersten Schritte.

Die Realisierung von umfangreichen Methoden-Systemen kann nur in einem arbeitsteiligen, kooperativen Prozeß bestehen.

Bei der "Institutionalisierung" wiederholt sich eine Erfahrung, die die Industrie seit mehr als 70 Jahren beim Übergang von der "Meisterwirtschaft" zur industriellen Fertigung erlebt hat. Die neuen Denkkategorien computergestützter Software-Methoden legen offen, daß die sozialen Strukturen unserer Gesellschaftsbereiche und deren Einteilung in "Bremser/Konservative/ Progressive" sogar auch für EDV-Manager und deren Mitarbeiter Geltung haben.

Die Situation auf dem Markt für Standard-Software-Pakete ist heterogen. Während einerseits die Verbreitung von Standard-Anwendungssoftware, also Paketen zur Lösung von Anwendungsproblemen, nach wie vor relativ gering ist (wie wir in einer gemeinsam mit Infratest durchgeführten Studie dargelegt haben), ist die Situation im Systemsoftware-Bereich, wozu gerade Programmierhilfen und Generatoren zu zählen sind, völlig anders: Hier haben DV-Manager und EDV-Spezialisten erkannt, daß es hervorragende Möglichkeiten gibt, Systemplanung, Programmierung und Test durch Standard-Software zu rationalisieren. Hier sind nämlich kaum Interessen der Fachabteilungen berührt, so daß Software-Entscheidungen in einem relativ kleinen Kreis von Betroffenen gefällt werden können. Gerade die Installationszahlen des Isis-Katalogs beweisen, daß Programmierhilfen und Generatoren zu den erfolgreichsten Software-Paketen überhaupt zu zählen sind.

Ein Beispiel für die Rationalisierungsmöglichkeiten der DV mag die von unserem Hause seit 1970 verbreitete und geschulte Entscheidungstabellentechnik sein, in der bisher über 8000 Lehrgangsteilnehmer ausgebildet wurden. Der entsprechende mbp-Vorübersetzer für Entscheidungstabellen "Vorelle" ist mittlerweile über 115mal installiert - wahrlich keine übliche Installationszahl und sicherlich kein Merkmal der "permanenten Software-Krise".

Die "Zwickmühle Hersteller/Anwender" bedeutet für uns zwar eine Marktlücke, in der wir mit unserem Generatorsystem auch erfolgreich operieren konnten; eine gezielte Vermarktung an Anwender mit großer PR Vorleistung beabsichtigen wir vorerst jedoch nicht. Wir sehen dafür keinen Markt, denn

- Großanwender haben längst "ihre" Methodik und sind nüchtern genug, um nicht bei jedem neuen "Geheimrezept"-Schlagwort ob des eigenen Tuns verunsichert zu sein.

- Klein- und Neuanwender sind meist froh, wenn ihre Hauptprobleme

halbwegs termingerecht zum Laufen kommen. Um das "Wie" kann sich bei einem EDV-Stamm von zwei bis fünf Leuten kaum jemand intensiv kümmern.

Bei Softwarehäusern ist die Entwicklung von Programmierhilfen und Generatoren durchaus gut aufgehoben. Es wird sich aber zeigen, daß nur wenige Konzepte tatsächlich überleben. Mit partiellen Lösungen wie Normierter Programmierung, Entscheidungstabellentechniken oder Druckprogrammen für Nassi-Schneidermann-Diagramme ist keinem Anwender entscheidend geholfen.

Auch Softwarehäuser kochen nur mit Wasser: Der große Wurf (neue Super-Sprachen oder ähnliches) sollte von ihnen nicht erwartet werden. Wir erinnern nur an die Tatsache, daß Codasyl im "Journal of Development 1976" die Ergänzung von Cobol um Sprachelemente der Strukturierten Programmierung schon angekündigt hat.

Niemand sollte deshalb von uns verlangen, daß nur des Ehrgeizes wegen sinnlos investiert wird. Wir können auch keinem Anwender dazu raten, etwas bei uns zu kaufen, was er in zwei bis drei Jahren ohnehin in seinem Cobol-Compiler finden wird.

Viele EDV-Anwender sind zu Recht stolz auf ihre Mixed-Hardware. Warum stößt dagegen die Vorstellung von einer Mixed-Software auf so viele Ressentiments?

Zugegeben: Für den Programmierer mag es nicht leicht sein, Software - sein ureigenstes Metier - als black box vorgesetzt zu bekommen. Denken wir an ein Programmiersystem etwa das dank weitgehender Vereinfachung und automatischer Funktionen in die Lage versetzt, Codierarbeit und Fehlerwahrscheinlichkeit erheblich zu reduzieren. Nicht gesehen werden die wirtschaftlichen und arbeitstechnischen Vorteile, die beispielsweise allein eine Automatisierung der Eingabesteuerung durch einen Generator mit sich bringt.

Ein gutes Programmiersystem beschleunigt nachweisbar nicht nur die Programmerstellung, sondern kann auch bessere Durchlaufzeiten erwirken. Nach landläufiger Meinung soll jedoch eine solche "Metasprache" den Marktwert des Programmierers senken. Sie senkt allenfalls den Marktwert des Codierers.

Die Skepsis schlägt oft in gänzliche Ablehnung um, wenn Methodensoftware darauf abzielt, die Arbeitstechnik aller Mitarbeiter zu verbessern, die am EDV-Prozeß im weitesten Sinn beteiligt sind. Bestes Beispiel ist die Entscheidungstabellentechnik, die als Problemlösungstechnik in erster Linie kein EDV-Verfahren ist. Wie etwa auch Führungslehren, Verkaufstechniken etc. stößt die ET-Technik jedoch deshalb auf Widerstände, weil sie eine Änderung des bislang praktizierten Verhaltens bedingt: Das Vorhaben hat Experimentiercharakter, weil der Effekt, wie sehr menschliche Leistung verbessert werden kann, immer im nachhinein meßbar ist.

Dreierlei Voraussetzungen bestimmen vor allem den Markterfolg von softwaretechnologischen Werkzeugen:

- Die Nachfrage potentieller Anwender,

- Die Produktqualität,

- Der Vertriebs- und Serviceapparat des Anbieters.

Ob vom Hardwarehersteller, Softwarehaus oder Anwender, bereits an der ersten Forderung - der Existenz ausreichender Nachfrage - scheitern viele Produkte - nicht jede fixe Idee eines cleveren Entwicklers trifft auf eine Marktlücke.

Produktqualität bedeutet vor allem, hohe Benutzerfreundlichkeit - nur wenige Werkzeuge jedoch sind einfach bedienbar und den Benutzerwünschen genügend angepaßt.

Ein umfangreicher Vertriebs- und Serviceapparat schließlich fehlt vielen Produkten völlig - nur ein aktiver Vertrieb kann Anwender von guten Produkten überzeugen und damit hohe Installationszahlen erzielen.

Wer erfolgreiche Werkzeuge entwickeln. will, und das gilt für den Hardwarehersteller genauso wie für das Softwarehaus oder einen Anwender, muß sich dieser Voraussetzungen vergewissern. Sie erfordern in der Regel nicht unerhebliche Investitionen; auch darüber muß man sich im klaren sein.

Natürlich ist bei Vorliegen dieser Bedingungen die Entwicklung von Softwarewerkzeugen bei denjenigen am besten aufgehoben, die bei Software- und Systementwicklungen notwendigerweise auf professionelle ingenieurmäßige Techniken selbst angewiesen sind; dazu gehören mit Sicherheit qualifizierte Softwarehäuser.