Gemessen an der rasanten Entwicklung im Bereich der Hardware hinkt die Softwareproduktion heute hoffnungslos hinterher. Schon viele Unternehmen haben einen Zustand erreicht, in dem sie kaum noch freie Kapazität für neue Projekte haben. Um diesem Trend nachhaltig entgegenzuwirken, muß Software so entwickelt werden, daß sie mit wesentlich weniger Aufwand als heute gepflegt werden kann. Hierin liegt der Schwerpunkt des "Bertelsmann-Modell Software-Engineering". Erst an zweiter Stelle steht die Forderung nach hoher Produktivität bei der Erstentwicklung.

Zu Beginn der elektronischen Datenverarbeitung wurde das Hauptaugenmerk auf die Entwicklung und Fertigung der Hardware gelegt. Damals lagen die Hardware-Kosten noch bei 80 Prozent der gesamten EDV-Kosten. Inzwischen hat auf diesem Sektor eine beispiellose Entwicklung stattgefunden, die zu einer vieltausendfachen Verbesserung des Preis-/Leistungsverhältnisses geführt hat.

Parallel mit dieser Tendenz stieg auch die gesamtwirtschaftliche Bedeutung der Software-Entwicklung. 1980 wurden in Deutschland etwa 12 Milliarden für Software ausgegeben. Dies ist etwa 0,8 Prozent des Bruttosozialproduktes. In den USA liegt der Softwarekosten-Anteil bereits bei 2 Prozent des Bruttosozialproduktes. Tendenziell läßt sich eine ähnliche Entwicklung sicherlich auch für Deutschland voraussehen.

Pflegephase ist entscheidend

Wenn man von hohen Softwarekosten spricht, meint man in der Regel die Kosten der Erstentwicklung. Wesentlich entscheidender aber ist die Pflegephase. Früher mußte man bei Projekten mittlerer Größe mit einer Lebensdauer von 5 bis 7 Jahren rechnen. Mittlerweile produzieren wir aber wesentlich größere und komplexere Systeme. Wir haben uns auf eine Lebensdauer von 10 bis 15 Jahren einzustellen. Betrachtet man die Kosten eines Projektes über seinen ganzen Lebenslauf, so sind etwa nur 20 bis 30 Prozent Erstentwicklungskosten; 70 bis 80 Prozent der gesamten Kosten entfallen auf die Pflegephase. Es sind Unternehmen bekannt, bei denen eine Neuentwicklung praktisch nicht mehr möglich ist, es sei denn durch Software-Häuser.

Analysiert man einmal, warum die Pflegekosten in der Regel so hoch sind, so läßt sich dieses nur teilweise durch die häufigen Änderungswünsche der Anwender erklären. Vielmehr liegen wesentliche Faktoren in der Beschaffenheit der Software selber begründet. Im wesentlichen lassen sich drei Punkte anführen: Einmal werden immer noch häufig Software-Systeme in die Produktion gegeben, die nur unzureichend ausgetestet sind und sich durch eine hohe Instabilität auszeichnen. Die Bereinigung dieser Fehler ist oft sehr aufwendig, da es sich überwiegend um Fehler aus dem Entwurf handelt und weniger um reine Programmierfehler, die relativ einfach zu beseitigen sind.

Hinzu kommt die Komplexität der Software-Systeme, die sich nicht nur auf die Fehlerbereinigung hinderlich auswirkt, sondern vor allem auch auf den Einbau von Änderungen und Erweiterungen. Die Software ist unstrukturiert oder falsch strukturiert. Beides führt zu langen Einarbeitungszeiten und erhöht die Fehleranfälligkeit. Besonders erschwerend kommt schließlich noch hinzu, daß die Dokumentation entweder fehlt oder nicht aktuell ist.

Aus diesen Erkenntnissen lassen sich die wesentlichen Ziele des Software-Engineerings darstellen: Da in der Maintenance-Phase die meisten Kosten anfallen, muß an erster Stelle die wirtschaftliche Pflegbarkeit angeführt werden. Erst an zweiter Stelle geht es darum, auch in der Erstentwicklung eine hohe Wirtschaftlichkeit zu erreichen. Eine dritte Zielsetzung besteht darin, die Zuverlässigkeit der Software (weniger Abstürze und Fehler in der Produktion) zu verbessern. Weiterhin gewinnt die Portabilität von Anwendungssoftware immer mehr an Bedeutung. Hier kommt es darauf an, die Software so zu entwickeln, daß sie beispielsweise nicht von Datenbanksystemen, TP-Monitoren und ähnlichen Systemsoftware-Komponenten oder gar von der Hardware, auf der sie läuft, abhängig ist.

Schließlich sei die Produktionsgerechtigkeit als Qualitätsmerkmal angeführt. Sie gewinnt immer dann mehr an Bedeutung, wenn man sich das Ziel setzt, die Rechenzentrumsproduktion zu automatisieren.

Natürlich gibt es verschiedene Möglichkeiten und Wege, die Software-Krise zu überwinden. In dem nachfolgenden Beispiel möchte ich kurz skizzieren, welchen Weg die Bertelsmann Datenverarbeitung gewählt hat.

Das Bertelsmann-Modell Software-Engineering entstand in den Jahren 1978 bis 1982. Mittlerweile liegen mehr als 100 Mannjahre Projekterfahrung vor, so daß man durchaus davon ausgehen kann, daß ein gewisser Reifegrad erreicht ist. Dennoch wird das Modell permanent weiterentwickelt. Vor allem auf dem Werkzeug-Sektor sind noch erhebliche Verbesserungen zu erwarten.

Der Begriff Software-Engineering wird schon seit vielen Jahren international verwendet. In Deutschland sprechen wir auch von der ingenieurmäßigen Projektentwicklung. Beide Begriffe deuten auf eine Hinwendung zu den Ingenieurdisziplinen. In der Tat gibt es dort seit langem erprobte Methoden- und Verfahrenstechniken, die sich auch auf die Entwicklung von Softwareprojekten anwenden lassen.

Ein wesentlicher Bestandteil ist das Phasenkonzept. Es teilt den gesamten Projektentwicklungsprozeß in verschiedene Phasen ein, die sich durch genau definierte Phasenergebnisse voneinander abgrenzen lassen.

Entwurf nach Inhalt und Technik trennen

Wir unterscheiden zwischen Entwurfsphasen und Realisierungsphasen. Die Entwurfsphasen muß man noch unterteilen in den fachinhaltlichen Entwurf und den technischen Entwurf. Die erstere nennen wir Fachinhaltsbeschreibung und den technischen Entwurf beschreiben wir durch die Phasen Systementwurf und Modulentwurf. Die Phasen Programmierung und Test schließen das Projekt ab, bevor es dann in die Wartungsphase übergeht.

Wichtig bei diesem Phasenkonzept ist die Trennung von fachinhaltlichen Anforderungen und technischer Realisierung. Zur Klärung, des Begriffs Fachinhaltsbeschreibung hier noch einige andere Bezeichnungen, die sich auch gelegentlich in der Literatur wiederfinden: Anforderungsdefinition, Requirement Specification, Problembeschreibung, Pflichtenheft. Alle Begriffe meinen im wesentlichen denselben Sachverhalt.

Früher hat man die ersten beiden Phasen Fachinhaltsbeschreibung und Entwurf häufig zusammengefaßt; heute gehört es zu den Grundsätzen des Software-Engineerings die fachinhaltlich organisatorische Konzeption ohne Bezug auf Softwaretechnische Dinge zu beschreiben.

Auf diese Weise kann sich der Organisator voll auf die ohnehin schon komplexen fachlichen Zusammenhänge konzentrieren; der Systementwerfer wiederum verfügt über die notwendige Freiheit zum Entwurf des technisch optimalen Lösungssystems.

In diesem Sinne enthält die Fachinhaltsbeschreibung zwei Aussagen:

1. Die funktionellen Anforderungen an das zu entwickelnde Softwareprodukt.

2. Die Art und Weise, wie der Endbenutzer mit dem technischen Lösungssystem kommuniziert.

Zum Phasenkonzept gehören zwei wichtige Grundsätze. Der erste Grundsatz wurde bereits dargestellt und lautet noch einmal zusammengefaßt:

Die Projektabwicklung findet in Phasen statt mit jeweils fest definierten Phasenergebnissen.

Über die fest definierten Phasenergebnisse wird abgesichert, daß das Ende einer Projektphase auch überprüfbar ist.

Der zweite Grundsatz besagt, daß eine Phase erst beginnen darf, wenn die vorherige Phase vollständig abgeschlossen ist.

Ein Verstoß gegen dieses zweite Phasengesetz bedeutet beispielsweise, mit dem technischen Entwurf zu beginnen, noch bevor die Fachinhaltsbeschreibung fertig ist oder bereits zu programmieren, noch bevor System- und Modulentwurf abgeschlossen sind. Diese Vorgehensweise wird häufig gewählt, weil man glaubt, damit Zeit einsparen zu können. Doch genau das Gegenteil ist der Fall.

Sollte die Fachabteilung in einer fortgeschrittenen Projektphase ihre fachinhaltlichen Anforderungen präzisieren, so werden die Entwurfsüberlegungen hinfällig und Teile der Programmierung können weggeworfen werden. Es entstehen erhebliche Mehrkosten und Zeitverzögerung durch Überarbeitung des Entwurfs und teilweise Neuprogrammierung. Dies geschieht in der Regel nicht nur einmal, sondern kommt im Verlaufe des Projektes öfters vor.

Allein aus dem Grunde der Phasenüberlappung werden oft die geplanten Projektkosten um ein Mehrfaches überschritten. Die Konsequenz kann nur lauten: Es führt kein Weg daran vorbei eine Fachinhaltsbeschreibung bis ins Detail komplett abzuschließen, bevor mit dem Systementwurf begonnen wird. Dasselbe gilt für die weiteren Projektphasen.

Realisierung nicht zu früh beginnen

Für eine komplette Fachinhaltsbeschreibung rechnen wir mit zirka 30 Prozent des gesamten Projektaufwandes. Diese Zahl erscheint höher, als es von Projekten, die nicht streng nach dem Phasenkonzept abgewickelt werden, bekannt ist. Diese Vermutung trifft allerdings nur bedingt zu.

Vielfach wurde früher bereits nach 10 bis 15 Prozent des Projektaufwandes mit der technischen Realisierung begonnen. Die Fachinhaltsbeschreibung lag allerdings nur im groben Umfang vor und mußte phasenüberlappend während der nächsten Projektphasen permanent ergänzt und erweitert werden. Insgesamt kam man dabei ebenfalls auf einen Anteil von zirka 30 Prozent am Gesamtprojekt.

Ähnliches gilt für den technischen Entwurf (Systementwurf und Modulentwurf). Hierfür müssen wir heute ebenfalls rund 30 Prozent in Ansatz bringen, während früher für diese Projektphase ein wesentlich geringerer Aufwand von 15 Prozent angesetzt wurde. Hier wird jedoch übersehen, daß wesentliche Tätigkeiten des technischen Entwurfs in der Programmierphase angesiedelt waren. Die Codierung liegt etwa bei 15 bis 20 Prozent und die Testphase beansprucht noch 20 bis 25 Prozent.

Betrachtet man die methodische Unterstützung in den einzelnen Projektphasen, so merkt man sehr schnell, daß hier eine deutliche Diskrepanz besteht. Dort, wo wir heute noch am meisten für die Projektrealisierung aufwenden müssen, ist die methodische Unterstützung am geringsten. Für Modulentwurf und Codierung, die mit dem geringsten Aufwand zu Buche schlagen, gibt es sehr viele Methoden.

Die Unterstützung für Fachinhaltsbeschreibung, Systementwurf, Test und Wartung ist weit weniger untersucht worden. Hier gibt es noch einen erheblichen Nachholbedarf.

Wesentliche Bedeutung in unserem Methodenkonzept hat der Tatbestand, daß die Testfälle bereits in der Phase der Fachinhaltsbeschreibung entwickelt werden. Sie entstehen gewissermaßen als Abfallprodukt des Reviews der Fachinhaltsbeschreibung. Durch diese Vorgehensweise lassen sich bereits 80 bis 90 Prozent aller fachinhaltlichen Fehler, Ungenauigkeiten oder Unvollständigkeiten erkennen, bevor die technische Realisierung beginnt.

Der Fachinhaltsbeschreibung kommt im gesamten Softwarenentwicklungsprozeß eine fundamentale Bedeutung zu. Sie ist der Ausgangspunkt aller späteren Realisierungsüberlegungen. Das endgültige System wird nur solche Dinge enthalten, die in der Fachinhaltsbeschreibung beschrieben sind, aber auch alle dort vorhandenen fachinhaltlichen Fehler und Unvollständigkeiten.

Die Fachinhaltsbeschreibung muß eine gemeinsame Kommunikationsbasis zwischen Fachabteilung, Organisation und Systementwicklung bilden. Kommunikationsbasis für die Systementwicklung erfordert ein Höchstmaß an Präzision der Aussage, Eindeutigkeit, Vollständigkeit Widerspruchsfreiheit und Redundanzfreiheit. Schließlich muß gewährleistet sein, daß die Fachinhaltsbeschreibung hinsichtlich dieser Forderungen auch überprüfbar ist. Die Überprüfbarkeit sollt möglichst maschinell möglich sein.

Um all dies zu gewährleisten, sind eine Reihe von Ansätzen mit formalen Sprachen gemacht worden. Diese haben jedoch den Nachteil, daß sie nur noch von speziell ausgebildeten Informatikern und Software-Ingenieuren verstanden werden.

Der Grad der Verständlichkeit einer Sprache nimmt dagegen zu, je mehr man sich der Umgangssprache nähert. In diesem Fall wird es aber außerordentlich schwierig, die Anforderungen der Informatiker nach Präzision und Eindeutigkeit zu erfüllen. Man befindet sich in einem nur schwer lösbaren Widerspruch.

Als weitere Anforderung kommt auf eine Fachinhaltsbeschreibung zu, daß sie sich in verschiedenen Feinheitsstufen darstellen und entwickeln läßt. Es muß also möglich sein, zunächst eine grobe fachinhaltliche Darstellung zu geben und diese in mehreren Teilschritten zu verfeinern (Topdown-Vorgehensweise).

Schließlich sollte eine Fachinhaltsbeschreibung auch für den gesamten Projektentwicklungsprozeß mit gepflegt werden können. Dies setzt in aller Regel voraus, daß sie maschinell pflegbar ist.

Im Bertelsmann-Modell Software-Engineering wird als Beschreibungsmethode für eine Fachinhaltsbeschreibung eine semiformale Sprache verwendet. Zunächst wird das fachinhaltliche Problem mittels der Topdown-Vorgehensweise strukturiert. Es entsteht ein Inhaltsverzeichnis mit Hauptkapiteln, Unterkapiteln und einzelnen Sektionen. Diese Strukturierung wird allerdings nicht bis ins Unermeßliche weitergetrieben, vielmehr hören wir dann auf weiter zu untergliedern, wenn Einheiden einer bestimmten Größe, die wir Funktion oder Funktionselemente nennen, entstanden sind. Diese Funktionen wären zwar formal noch weiter teilbar, bilden aber dann keinen sinnvollen fachinhaltlichen Zusammenhang mehr.

Der Informatiker spricht von einer linearen Baumstruktur, deren Knoten jeweils eine Zusammenfassung der Überschrift für die darunter liegenden Knoten (Teilüberschriften) bilden. Die Blätter des Baumes werden Funktionen oder Funktionselemente genannt.

Zur Beschreibung der Funktionselemente gehen wir auf eine andere Beschreibungsart über. Je Funktionselemente werden die Ein- und Ausgaben vom Layout her dargestellt, die ein- und ausfließenden Felder allgemein verständlich beschrieben und die fachinhaltlichen Algorithmen in Form von Entscheidungstabellen dargestellt. Hierbei ist wichtig, daß wir in 95 Prozent aller Fälle auf textliche Darstellungen verzichten.

Es hat sich in der Praxis herausgestellt, daß es durchaus zumutbar ist für eine Fachabteilung, Entscheidungstabellen zu lesen. Die Erstellung von Entscheidungstabellen jedoch ist nicht generell zumutbar. Sie ist deshalb in unserem Konzept bei den Systementwicklern angesiedelt.

Als dritter Bestandteil unserer Fachinhaltsbeschreibung sind die Testfälle vorgesehen. Dabei kommt es darauf an, alle Testfälle zu ermitteln, die zu einer vollständigen fachinhaltlichen Überdeckung führen.

Aus den Testfällen der Fachinhaltsbeschreibung werden zunächst maschinell lesbare Testdaten erzeugt. Diese laufen durch das Programm, welches maschinelle Testergebnisse produziert. Diese maschinellen Testergebnisse werden mit den manuellen Testergebnissen (Bestandteil der Testfälle der Fachinhaltsbeschreibung) verglichen. Stimmen diese Ergebnisse überein, ist der Test beendet.

Im anderen Fall gibt es drei Möglichkeiten: Entweder sind die Algorithmen der Fachinhaltsbeschreibung zu korrigieren oder aber ein eingegebener Testfall enthält einen Fehler oder das Programm enthält einen Fehler.

Wichtig ist noch die Trennung von Modul- und Integrationstest. Besonders großen Wert legen wir auf die Testdatenverwaltung, das heißt die Testdaten werden nicht nur für das einmalige Austesten und für die Abnahme des Systems verwandt, sondern spielen eine große Rolle in dem späteren Pflegekonzept. Sie werden wie alle anderen Elemente des Projektes mit verwaltet und gepflegt.

Softwarehäuser wiesen falschen Weg

Vielfache Erfahrungen haben gezeigt, daß es unerläßlich ist, erst ein durchgängiges Methodenkonzept zu entwickeln, bevor man darauf abgestimmte Werkzeuge einsetzt. Hier wurde uns lange Zeit - vereinzelt geschieht es auch noch heute- von Softwarehäusern und Werkzeugproduzenten der umgekehrte Weg vorgeschlagen.

Dieser Empfehlung sind sehr viele gefolgt und auch heute gibt es noch vereinzelt Werkzeugmacher, die ernsthaft eine solche Vorgehensweise propagieren. Daß damit die Probleme Fachinhaltsbeschreibung, Phasenüberlappung, Systementwurf, Kopfmonopole, Kosten und Termine nicht gelöst worden sind, war für viele erst nach Jahren eine schmerzliche Erkenntnis.

Deshalb muß als erster Grundsatz gelten: Werkzeuge sind kein Ersatz für ein durchgängiges Methodenkonzept.

Zwei Typen von Werkzeugen müssen wir unterscheiden. Zunächst die Werkzeuge zur Routineentlastung. Hierzu gehören Editorsysteme, Bibliothekssysteme oder Textsysteme. Sie können schon in erheblichem Umfang zur Produktivität der Erstentwicklung beitragen.

Die zweite Gruppe bilden Werkzeuge zur Methodenunterstützung. In den frühen und späten Projektphasen gibt es wenig, für die mittleren Projektphasen gibt es eine Reihe von Einzelwerkzeugen.

Für die zukünftige Werkzeugentwicklung kommt es weniger auf Einzelwerkzeuge an, als vielmehr auf ein Gesamtwerkzeugsystem, das aufeinander abgestimmt ist und den gesamten Projektentwicklungsprozeß von der Spezifikation bis zur Wartungsphase abdeckt. Dieses ist ein Entwicklungsprozeß, der noch einige Jahre in Anspruch nehmen wird.

Das Projektmanagement ist ein ganz besonders wichtiger Bestandteil des Bertelsmann-Modells Software-Engineering. Projekte, die nicht in einem sehr frühen Stadium in einen planbaren Zustand gebracht werden, können nicht im einzelnen durchgeplant werden. Dieses ist ein Management-Problem. Es ist kein Problem der Programmierer. Projekte, die aber nicht richtig durchgeplant sind, werden automatisch nach einer gewissen Zeit notleidend. Das liegt daran, daß man nur grob geplante Projekte in ihrem wirklichen Aufwand in aller Regel unterschätzt. Kommen die Projekte dann in ihre notleidene Phase, wird versucht, mit mehr Kapazität, das heißt mehr Mitarbeitern doch noch den Einführungstermin zu erreichen.

Daß dieses Unterfangen völlig fruchtlos verläuft, ja daß sogar genau das Gegenteil erreicht wird, ist zuerst von Brook mit dem sogenannten Brook'schen Gesetz dargestellt worden. Danach nimmt die Projektdauer ab, je mehr Mitarbeiter man einsetzt. Dies aber nur bis zu einem bestimmten Punkt. Darüber hinaus werden bei Einsatz weiterer Mitarbeiter die Kommunikationskosten so groß, daß sie schließlich den Effekt der Mehrkapazität überwinden und zu einer Projektverlängerung führen.

Planeinheiten sind die Basis

Das Projekt ist erst mit einer Genauigkeit von fünf bis zehn Prozent kalkulierbar, wenn die komplette Fachinhaltsbeschreibung vorliegt Dann sind aber in der Regel schon zirka 30 Prozent der Projektkosten erbracht.

Das Projekt wird in Planeinheiten zerlegt; die Größe einer Planeinheit sollte fünf bis 15 Manntage nicht über-oder unterschreiten. Auf dieser Basis werden dann Kapazitätspläne - und Testpläne aufgestellt.

Auf der Basis einer in dieser Weise durchgeführten Planung, deren Aufwand man auf keinen Fall unterschätzen sollte, ist dann auch eine Projektkontrolle in allen Pojektphasen möglich. Hierzu finden Reviews statt, für Projekte ab einer bestimmten Größe werden Controlboards abgehalten, denen die permanenten und periodischen Projektfortschrittsberichte zugrunde liegen.

Das Ganze ist eine Management-Aufgabe. Der Software-Manager hat dafür zu sorgen, daß Projekte in einen planbaren Zustand versetzt werden, das heißt, so viele Vorarbeiten erledigt werden, wie zu einer ordentlichen Planung erforderlich sind. Auf dieser Grundlage hat die Projektleitung dann die Planung und Kalkulation durchzuführen.

Es ist ein Trugschluß zu glauben daß Projekte, die mangels Planung notleidend werden, von Programmierern noch gerettet werden können. Dieses wird zwar immer wieder versucht, führt aber ebenso regelmäßig zu dem Umstand, daß die Erkenntnis über nicht zu haltende Termine später kommt und daß der Überziehungszeitraum eher größer wird.

Zum Abschluß möchte ich noch auf einige Ergebnisse und Erfahrungen bei Bertelsmann eingehen, die mit dem beschriebenen Modell erzielt wurden. Obwohl wir als erste Priorität die Wirtschaftlichkeit der Pflege im Auge hatten, zeigte sich k bald, daß unsere Konzeption auch sehr wohl geeignet war, die Produktivität der Erstentwicklung nachhaltig zu verbessern.

Erkennen wir beispielsweise, daß trotz erheblich gestiegener Stundensätze (von 48 Mark in 1977 auf 84 Mark in 1983) die Kosten pro Poduktionseinheit um zirka 33 Prozent gesunken sind. Dies bedeutet konkret für unsere Kunden, daß ein Programm, das -1977 rund 100 000 Mark gekostet hat, 1983 für zirka 66 000 Mark entwickelt werden kann. Also eine absolute Preissenkung in der Software. Zurückzuführen ist diese Preissenkung auf die enorme Steigerung der Produktivität. Sie konnte von 20 Lines of Code in 1977 auf 70 Lines of Code 1983 angehoben werden.

Was nun das Ziel der Reduktion der Pflegekosten anbelangt, können wir heute schon auf einen erheblichen Erfolg verweisen. Lag diese Position i978 noch bei etwa 70 Prozent, dann liegt sie heute schon deutlich unter 50 Prozent, und es ist erkennbar, daß die angepeilte Marke von etwa 30 Prozent erreicht werden kann.

Natürlich ist dies ein länger dauernder Prozeß, da Erfolge hier nur in dem Maße sichtbar werden, wie alte Projekte durch neue Software, die besonders pflegbar konstruiert worden ist, abgelöst werden.

Unser Modell hat zu einer wesentlichen Verschiebung zwischen Entwurf und Realisierung geführt. Lag diese Relation 1978 noch bei 40 Prozent zu 60 Prozent, so liegt sie heute bei 60 Prozent zu 40 Prozent. Es hat also eine Umkehrung stattgefunden. In dieser Betonung der Entwurfsphasen liegt sicherlich der wesentliche Schlüssel zum Erfolg dieser Konzeption.

Das eigentliche Problem des Software-Engineering liegt nicht etwa in der Entwicklung von Methoden - diese sind teilweise schon seit vielen Jahren bekannt - sondern in der Einführung dieser Konzeption. Deshalb ist der Grund dafür daß es nur in ganz wenigen Fällen bisher gelungen ist, ein durchgängiges Software-Engineering-Konzept zu realisieren, darin zu suchen, daß das Akzeptanzproblem nicht gelöst wurde.

Die Entwicklung und Durchführung einer Einführungsstrategie ist deshalb eine der wichtigsten Aufgaben, wenn nicht die wichtigste des Software-Managers.

* Dipl.-Ing. Helmut Bender ist Leiter der Bertelsmann Datenverarbeitung in Gütersloh.