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.

03.02.1978

Zeitalter der DV-Axt vorbei

MÜNCHEN/TÜBINGEN (uk) - Mehr Zeit und höhere Kosten als geplant, geringe Effektivität, geringe Lebensdauer sowie hoher Wartungsaufwand kennzeichnen die derzeitige Situation bei der Programmentwicklung. Um die Software-Produktion leistungsfähiger zu gestalten, sind in den letzten Jahren eine Reihe von Organisationsverfahren entstanden. Jüngste Entwicklung auf diesem Gebiet ist das Mentor-Paket (Methoden und Techniken der EDV-Organisation und Programmierung) der Integrata GmbH, Tübingen. Mentor stellt die strukturierende Vorgehensweise in den Mittelpunkt und ist außerdem durch Top-Down-Design, schrittweise Verfeinerung und parallele Dokumentation gekennzeichnet. Wie mit dem Verfahren im einzelnen gearbeitet wird, erläutert Integrata-Geschäftsführer Dr. Wolfgang Heilmann in folgendem Gespräch mit CW-Redakteur Udo Kellerbach.

- Die Softwarekrise findet nach wie vor statt: Zwar wurden allenthalben Verfahren propagiert, mit deren Hilfe die Software-Enwicklung und Wartung effizienter würde. Nun belebt auch Integrata mit seinem Mentor-Konzept die Konkurrenz zwischen Orgware, Methodos, Norsys, Bisad, Ardi und Hipo. Was bewog Sie dazu, mit einem weiteren Verfahren in dieses Feld zu stoßen, auf dem es mit der Benutzer-Akzeptanz bislang schlecht bestellt war?

Wir haben bereits im Jahr 1967 unter der Bezeichnung EDV-Einsatzplanung das erste Methodenpaket auf den Markt gebracht. Sein Schwerpunkt lag bei der ersten Einführung eines EDV-Einsatzes im Unternehmen. Andere haben die ergänzenden Arbeiten wie Systemanalyse im eigentlichen Sinne oder Programmierung als Standardpakete formuliert. So sind im Laufe der Jahre auf dem deutschen Markt eben eine Reihe von solchen Paketen entstanden. Wir haben uns nun alle diese Pakete angesehen und versucht, ein modernes Methodenpaket zu erarbeiten, daß man auch wirklich praktizieren kann . . .

- Können Sie nachweisen, die anderen Methoden seien nicht praktikabel?

Die anderen Methodenpakete sind natürlich auch mehr oder weniger praktikabel gewesen. Es ergab sich aber, daß in der Theorie-Diskussion eine Fülle von Schlagworten auftauchen wie "structured programming" Völer ,;Topdown-Design", die eine große Verunsicherung beim Anwender verursacht haben. Eine Verunsicherung, die auch Rückschläge für die anderen Methodenpakete brachte, zumal diese moderne Entwicklungen noch nicht verwenden konnten, gerade was das strukturierte Vorgehen im Topdown-Design anbetrifft. Deshalb entwickelten wir mit Mentor ein Methodenpaket, das diese modernen Verfahren berücksichtigt und außerdem praktikabel ist.

- Welche Systementwicklungs-Phasen decken Sie mit Mentor ab?

Das Gesamtpaket deckt Projektmanagement, Systemanalyse, Programmierung, Dokumentation und Systemführung.

- Sie bezeichnen Mentor auch als Werkzeugkasten des Software-Ingenieurs. Welche Werkzeuge sind konkret in Mentor enthalten?

Wie beim Werkzeug kann man zwischen manuellem und maschinellem Werkzeug unterscheiden. Mentor faßt zunächst alle Handwerkszeuge zusammen, die für die Systemarbeit erforderlich sind.

- An welche "Faustwerkzeuge" denken Sie?

Unseres Erachtens gehören vor allem fünf Dinge dazu: Das Strukturdiagramm, nicht zu verwechseln mit dem Struktogramm, das Flußdiagramm, das HIPO- oder wie wir sagen EVA-Diagramm, die Entscheidungstabelle und die Datentabelle in den verschiedenen Verwendungsformen.

- Und wie steht es mit den "Maschinen"?

Was die maschinellen Werkzeuge anbetrifft, so können wir hier unterschiedliche Generatoren und andere Tools gezielt einsetzen. Wir führen beispielsweise für ein Unternehmen, das jetzt mit systematischer Systementwicklung Ernst machen will, eine Methodenanalyse und eine Methodenkonzeption durch. Dabei wird einmal festgelegt, nach welchen Verfahren im Projektmanagement der Systemanalyse und Programmierung gearbeitet werden soll. Auf der nächsten Stufe wird darüber entschieden, welche Softwaretools eingesetzt werden sollen. Das könnte ein Entscheidungstabellengenerator oder ein Generator für strukturierte Programmierung oder ein Testdatengenerator sein. Wir gehen dann so vor, daß wir für den Auftraggeber nach bestimmten Kriterien diese Generatoren auswählen und in das Gesamtmethodenpaket miteinbeziehen.

- Und Ihr Werkzeugkasten hat für jeden praktischen Fall den passenden Inhalt?

Es ist nicht erforderlich, daß man vom ersten Moment an bereits alle Tools schon festgelegt hätte. Sondern es können jederzeit noch zusätzliche Tools, die als solche noch gar nicht bekannt sind, sondern die am Markt erst entwickelt werden, mit in dieses Methodenpaket eingebaut werden. Wir plädieren sehr für den Einsatz von Tools, aber noch mehr für die Einführung eines manuellen Basis-Systems, mit dem wirklich von Anfang bis Ende durchgearbeitet werden kann. Es gibt noch kein maschinelles Hilfsmittel, das diesen Planungs-, Entwicklungs- und Programmierungsprozeß in allen Einzelheiten abdecken würde, und es wird noch sehr viel Zeit vergehen, bis solche volldurchgängigen maschinellen Systementwicklungssysteme existieren. Das kommt aber sicher irgendwann einmal.

- Hier stellt sich aber die wichtige Frage der Kompatibilität unter diesen einzelnen Werkzeugen. Wodurch ist die bei Ihnen gewährleistet?

Die Frage der Kompatibilität ist insofern nicht so gravierend, als diese Softwaretools mit wenigen Ausnahmen praktisch bestimmte Teilbereiche der Gesamtarbeit abdecken.

- Welche Voraussetzungen müssen maschinelle Hilfsmittel erfüllen, um im Mentorkonzept eingesetzt werden zu können?

Wir fordern neben einer übersichtlichen Handhabung vor allem, daß die Möglichkeit der Strukturierung voll gegeben ist.

- Stichwort Entscheidungstabellentechnik: Sie behaupten, die bisher in der Computerwoche geführte Diskussion um die Frage "Selbst programmieren oder generieren?" ginge am Kern vorbei.

Meines Erachtens geht es zunächst darum, Methoden und Techniken der täglichen Arbeit festzulegen und dann die Maschinenwerkzeuge zu bestimmen, die man dafür einsetzt. Insofern ist Ihre Frage nach dem Entscheidungstabellenproblem von mir aus gesehen nur eine Frage zu einem Teilaspekt. Zunächst einmal muß in einem Unternehmen darüber entschieden werden, daß überhaupt mit der Entscheidungstabellentechnik gearbeitet wird. Das bringt ja nur in wenigen Fällen etwas, und so gibt es auch nur wenige Firmen, die mit Entscheidungstabellen arbeiten. Erst mal muß man manuell damit arbeiten und dann kommt es darauf an, ob soviel Entscheidungstabellen produziert werden, daß es sich lohnt, hierfür einen Entscheidungstabellen-Generator einzusetzen.

- Und wann lohnt es sich?

Ich bin der Meinung, daß das sehr bald der Fall sein kann. Der Entscheidungstabellen-Generator ist ja vom Preis her keine übertrieben große Investition.

- Sehen Sie zwischen den Methoden "Entscheidungstabellentechnik" und "strukturierte Programmierung" eine Kollision?

Nein, das sehe ich nicht. Es ist so, daß manchmal in der Diskussion in den letzten Jahren der Eindruck entstanden ist, als würden ein paar Verfechter bestimmter Methoden die ihrige als alleinseligmachend in den Mittelpunkt stellen wollen. Wir haben durch Mentor und auch sonst immer wieder auf den Fehler hingewiesen, der in dieser Annahme liegt. Es ist falsch zu glauben, daß man mit einer einzigen Technik die ganze Problematik erschlagen könnte. Das ist ungefähr so, als würden Sie als Zimmermann nur mit der Axt arbeiten und auf Hobel, Säge und Stemmeisen verzichten. Genauso ist es in der Datenverarbeitung: Das Zeitalter, in dem bloß mit der Axt, sprich Datenflußblatt, gearbeitet wurde, ist vorbei. Wir haben heute mehrere Werkzeuge, die wir immer dann einsetzen sollten, wenn sie einen Vorteil bringen. So werde ich, wenn eine komplexe Entscheidungsregel zu formulieren ist,

selbstverständIich Entscheidungstabellen einsetzen. Aber ich werde Entscheidungstabellen niemals einsetzen, wenn ich die Reihenfolge von Arbeitsschritten festlegen will, dann setze ich den Flußplan ein. Und wenn ich die Systemstruktur darstelle, dann nehme ich ein Strukturdiagramm, und wenn ich den Zusammenhang zwischen Daten und Programm herstellen will, dann nehme ich ein EVA-Diagramm. Diese richtige Auswahl muß der einzelne Systemanalytiker und Programmierer erlernen.

- Alles gut und schön. Aber wie wollen Sie den EDV-Praktiker dazu bringen, diese Hilfsmittel zur Systementwicklung auch einzusetzen?

Die Voraussetzung für den Einsatz ist, daß die Handwerkszeuge komplett, übersichtlich definiert und daß ihre Verwendung nachdrücklich propagiert wird.