Softwaretechnologische Methoden - eine Forderung der Praxis?

17.11.1978

"Noch schafft der Begriff ,Softwaretechnologische Methoden' mehr Verwirrung als Klarheit." So die Meinung von Marion Sachsenberg, zuständig für Verfahren und Normen bei der Deutschen Lufthansa in Frankfurt. Um den Anwender aufzuklären, fordert sie eine andere Definition für erfolgversprechende Methoden zur Verbesserung der Produktivität: "Betriebliche Problemlösung einschließlich der organisatorischen Komponenten." Erst mit diesem Denkansatz kann realisiert werden, was Claus Otto, Leiter der Systemanalyse und Programmierung bei MBB in Augsburg, in den nächsten Jahren von der EDV erwartet: "Wie in der Industrie gehören Herstellungsmethoden zum selbstverständlichen Rüstzeug." Und um das - so Marion Sachsenberg - "einzuführen und die Konsequenzen dafür zu tragen, gehört eine gehörige Portion Kraft". CW befragte drei "Structo 78" Teilnehmer. hö

Claus Otto,

Leiter der Systemanalyse und Programmierung, Messerschmitt-Bölkow-Blohm GmbH (MBB), Augsburg

Die Frage, ob Software-technologische Methoden heute als eine Forderung der Praxis zu sehen sind, muß mit einem klaren "ja" beantwortet werden. Bei der Herstellung von Produkten werden jeweils ähnliche Ziele verfolgt: Das Produkt soll dem Bedarf des Kunden entsprechen, möglichst kostengünstig erstellbar sein; es soll zuverlässig und nicht zuletzt gut wartbar sein.

Auch bei der Software-Erstellung haben wir es mit einem Produkt und gleicher Zielsetzung zu tun. Es unterscheidet sich von einem industriellen Erzeugnis nur dadurch, daß es nicht in Serie gebaut, sondern jeweils nur einmal produziert wird - jedoch beliebig oft reproduzierbar ist. Stellen wir einmal einigen industriellen Herstellungsmethoden schon bekannte Software-Erstellungsmethoden gegenüber, so erkennen wir unschwer die Analogien. Strukturierung: Strukturierung (Hipo, Michael-Jackson-Methode), Arbeitsteilung: Arbeitsteilung (Phasenkonzept, Workthroughs etc.), Fertigungsverfahren: Erstellungsverfahren (Strukturierte Programmierung und dergleichen), Hilfsmittel: Hilfsmittel (Compiler, Generatoren), Normung: Standards.

Bemerkenswert erscheint mir auch zu sein, daß sich die Entwicklung von Methoden zur Software-Erstellung im wesentlichen ähnlich vollzieht, wie wir es aus der Industrie kennen: Als erstes entwickelte man dort Methoden, die sich hauptsächlich auf den Herstellungsprozeß bezogen, und erst jetzt beschäftigt man sich mit der Automatisierung der Konstruktionen (CAD). Vielleicht ist dies ein Lichtblick für diejenigen, die die vorhandenen Software-Erstellungsmethoden als nur auf die Programmierung ausgerichtet sahen und so vehement nach Entwurfsautomatisation rufen.

Um noch einmal auf die eingangs erwähnte Frage einzugehen: In der Industrie gehören die unterschiedlichen Herstellungsmethoden zum selbstverständlichen Rüstzeug. Ich glaube, daß in einigen Jahren dies auch in der EDV so ist.

Marion Sachsenberg,

Verfahren und Normen, Deutsche Lufthansa AG, Frankfurt

Wenn damit gemeint ist, daß wir uns für die Verbesserung unserer Arbeitsmethoden und -ergebnisse etwas einfallen lassen müssen, ist die Antwort: Ja. Wenn allerdings gemeint ist, daß bestimmte Methoden mit all ihren teils aufwendigen Konsequenzen einzuführen sind, dann sind die Antworten weniger klar.

Noch schafft der Begriff "Softwaretechnologische Methoden" mehr Verwirrung als Klarheit. Praktiker sprechen eher von Programmiertechniken und Stilen, von phasenweiser Projektbearbeitung, von Dokumentationsverfahren. Nicht immer ist klar, daß es die ganze Breite von der Anwendung einheitlicher Vorgehensweisen für fünf Programmierer ohne Arbeitsteilung bis zu sehr komfortablen, computerunterstützten Methodensystemen für ausgeprägt arbeitsteilige große Organisationen abzudecken gilt.

Und hier beginnt die sehr unterschiedliche Interessenlage. Die Mehrheit erfahrener EDV-Organisatoren und Programmierer hat wenig Zeit und Anlaß, nach neuen Methoden zu fragen. Sie haben mit ihren bisherigen Arbeitsverfahren mehr oder weniger die Termine

gehalten und Erfolg gehabt. Wer kann ihnen schon garantieren, daß sie gleiche Erfolgserlebnisse (eine sehr persönliche Kategorie) mit der neuen Methode haben und in der Lernphase nicht zusätzlichem Termindruck ausgesetzt sind?

Neue Mitarbeiter sind leichter zu überzeugen, aber sie müssen unter den erfahrenen Projektleitern und anderen Vorgesetzten arbeiten. Und diese Vorgesetzten sind in einer ganz anderen Lage: In aller Regel haben sie mehr Arbeit in ihren Auftragsbüchern, als mit vorhandener Kapazität machbar ist. Termine der Fachbereiche tun ein übriges.

Es ist schon fast müßig, die Zwickmühle des DV-Managements zu beleuchten. Ziel ist sicher, bessere Produktqualität für Informationssysteme und -programme, um die Produktivität zu erhöhen. Aber welche Antwort gibt es für die laufende Produktion und die in Arbeit befindlichen Produkte? Soll man eine Methode, die man für erfolgversprechend hält, nur für neue Projekte anwenden, und was geschieht dann mit den Erweiterungen, und Anpassungsmaßnahmen für alte Anwendungen? Dann kann man mit einem wirklichen Greifen einer Methode erst nach längerem Verlauf rechnen. Oder soll man tatsächlich rückwirkend umstellen? Das scheint unsinnig, aber eigentlich konsequent.

Man könnte meinen, es handle sich hier um einen Widerspruch: Es gibt erfolgversprechende Methoden zur Verbesserung der Produktivität, und doch beißen die Praktiker nicht in erwartbarem Umfang an. Kein Widerspruch, so meine ich. Denn die Forderung heißt nicht: Softwaretechnologische Methoden, sondern sie heißt: Betriebliche Problemlösung einschließlich der organisatorischen Komponenten. Die Forderung nach solchen Methodenkonzepten auszusprechen, sie einzuführen und die Konsequenzen zu tragen verlangt schon eine gehörige Portion Kraft.

Frank N. Stockebrand

Leiter der Abteilung Systementwicklung Marketing-Systeme, Deutsche BP AG, Hamburg

Wir sind durch verschiedene Fachpublikationen sowie durch den Besuch mehrerer Veranstaltungen auf den Gesamtkomplex "Neue Software-Technologien" aufmerksam gemacht worden. Zwei Seminarveranstaltungen (BIFOA "Wirtschaftliche Programmierung",

Structo 78) in der letzten Zeit waren ausschlaggebend dafür, daß wir uns jetzt intensiv mit der strukturierten Programmierung und den anderen Methoden und Techniken beschäftigen werden.

Beschlossen haben wir bereits die Einführung der Bildschirmprogrammierung und des Online-Testens durch den Check-out-Compiler unter TSU. Außerdem sind wir den Weg gegangen, für bestimmte Funktionen Spezialisten zu ernennen: In unserer Organisation gibt es seit Anfang des Jahres in den drei Abteilungen für Anwendungssysteme jeweils einen Mitarbeiter, der die Aufgabe eines Programmierberaters hat. Diese Funktion geht jedoch weit über eine reine Programmier- beziehungsweise Codierberatung hinaus; sie besteht im wesentlichen aus der "Quality Assurance". So hat der Programmierberater zum Beispiel ein Mitwirkungsrecht in der Systemdesignphase. Nach Fertigstellung bestimmter Zwischenprodukte im Erstellungsprozeß eines Anwendungssystems muß der Programmierberater vom Projektleiter oder dem für eine Studie verantwortlichen Mitarbeiter eingeschaltet werden. Der nächste Schritt in der stufenweisen Realisierung kann erst in Angriff genommen werden, wenn das entsprechende Konzept durch den Programmierberater freigegeben worden ist. Weitergebildet werden diese Spezialisten, die zum Zeitpunkt der Ernennung den Status "Senior Systemanalytiker" hatten, durch eine sehr exzessive Schulung sowie durch Kontakte mit anderen Anwendern. Unser nächster Schritt auf dem Wege zur Implementierung der neuen Software-Technologie wird darin bestehen daß wir externe Fachleute zu uns ins Haus bitten. Dabei geht es uns zunächst darum zu einer einheitlichen Meinung über den einzuschlagenden Weg zu gelangen.

Nach den bisherigen Erfahrungen läßt sich noch folgendes anmerken: Es wird viel - unter anderem auch auf der Structo 78 - über neue Software-Technologien gesprochen; was jedoch beinahe gänzlich fehlt, ist die Unterstützung beim Systemdesign. Bei uns läuft der Prozeß der Systementwicklung in drei Stufen ab:

- Festlegung der Grobkonzeption des gesamten EDV-unterstützten Informationssystems (Rahmenplan);

- Design des einzelnen Anwendungssystems in der Abfolge Feasability und Detailstudie;

- Realisierung des einzelnen Anwendungssystems in Form eines Projektes.

Zum Beispiel haben wir ab Anfang 71 in Form einer Studie mit einem Gesamtaufwand von etwa 25-Mann-Monaten einen Rahmenplan erarbeitet, der einen Zeitraum von etwa fünf bis sechs Jahren abdeckt. Basierend auf den Informationsbedürfnissen der einzelnen Fachbereiche und ausgerichtet in den absehbaren Entwicklungen auf dem Hard- und Softwaremarkt (zugegebenermaßen ein schwieriges Unterfangen) wurde ein entsprechendes Konzept erarbeitet und mit den Fachbereichen abgestimmt. Bis heute sind weite Teile dieses Konzepts bereits realisiert, und wir sind dabei, eine zweite Studie mit gleicher Zielsetzung durchzuführen.

Die Unterstützung in den ersten beiden Phasen halten wir gegenwärtig für eindeutig unzureichend (obwohl wir Orgware 2-Anwender sind), da wir den Schwerpunkt der neuen softwaretechnologischen Verfahren eindeutig in der dritten Stufe sehen.

Gestatten Sie mir abschließend noch folgende Bemerkung: Bei der neuen Softwaretechnologie sehen wir den Schwerpunkt bei dem Einsatz von neuen Methoden, nicht aber bei der Umgestaltung unserer Arbeit in einen industriellen Produktionsprozeß in Form einer Programmier- und Testfabrik, wie zum Beispiel von Herrn Sneed auf der Structo 78 propagiert.