Ist es im Zeitalter der Standardsoftware noch zweckmaessig, selbst zu entwickeln? Matthias Karbstein und Monika Beckerle* sind davon ueberzeugt. Standardsoftware koenne die neuen, durch den Business- Re-Engineering-Trend entstandenen IT-Anforderungen zur Zeit nur teilweise abdecken. Eine moderne Softwareproduktions-Umgebung sei zwingende Voraussetzung, um die Neuorientierung der Anwendungsentwicklung effizient zu unterstuetzen.

Standardsoftware nimmt nicht nur aus Kosten-, sondern auch aus organisatorischen Gruenden einen immer wichtigeren Stellenwert ein, wenn es darum geht, betriebswirtschaftliche Anwendungssysteme zu reorganisieren. Mit dem sogenannten Business Process Re- Engineering sollen kosten- und zeitoptimierte betriebswirtschaftliche Ablaeufe (Geschaeftsprozesse) konzipiert und eingefuehrt werden. Informationstechnologie muss diese Prozesse hinsichtlich Effizienz und Flexibilitaet unterstuetzen.

Neue IT-Ansaetzensorgen fuer Veraenderung

Beim Wechsel von Individual- zu Standardsoftware steht weniger der Informatikaspekt als die betriebswirtschaftliche Seite im Vordergrund - eine Tatsache, die aufgrund der gegenwaertigen Konjunktursituation noch an Bedeutung gewinnt. Laesst man ausser acht, dass es neben dem Trend, Standardsoftware einzusetzen, noch weitere Ansaetze gibt, Informationstechnik effizient an die neuen Beduerfnisse der Ablauf- und Aufbauorganisation anzupassen (Objektorientierung, Client/Server-Konzepte etc.), so koennte man zu dem Schluss kommen, dass Individualsoftware - und damit auch die Software-Entwicklungsumgebungen insgesamt - durch Standardsoftware verdraengt werden koennten.

Ein solch radikales Vorgehen birgt jedoch auf absehbare Zeit unueberschaubare Risiken. So ist noch laengst nicht fuer alle betrieblichen Aufgaben Standardsoftware verfuegbar. Bis sie in Bereichen produktiv zum Einsatz kommt, in denen heute noch eigenentwickelte Systeme ihre Arbeit tun, muessen diese weiter gepflegt und gewartet werden. Diese Aufgabe laesst sich mit Hilfe einer geeigneten Software-Entwicklungsumgebung wahrnehmen.

Zudem koennen auch zukuenftig mit Standardsoftware nicht alle betriebswirtschaftlichen Ablaeufe 100prozentig abgedeckt werden - als Beispiel mag die Gefahrengut-Abwicklung dienen. In einem Unternehmen mit der Komplexitaet des Hoechst-Konzerns wird daher weiterhin Individualsoftware erstellt werden muessen.

Das Ziel eines Softwareprojekts besteht bekanntlich darin, ein qualitativ hochwertiges Produkt unter Einhaltung von Kosten- und Zeitrahmen zu erstellen, das einen minimalen Aufwand an Wartung und Pflege benoetigt. Um dahin zu gelangen, sind eine sorgfaeltige Planung und methodisches Vorgehen unerlaesslich. Missverstaendnisse sind umso teurer, je frueher sie begangen wurden.

Ein Beispiel mag dies belegen. Wird in der Phase der Anforderungsanalyse eine falsche Entscheidung getroffen, so hat dies zur Folge, dass unvollstaendige oder fehlerhafte Ergebnisse an spaetere Entwicklungsphasen weitergereicht und umgesetzt werden. Mit jeder Phase wird die Fehlerkorrektur schwieriger und aufwendiger, die Kosten steigen exponentiell an.

Missverstaendnisse dieser Art lassen sich reduzieren, wenn alle an der Entwicklung Beteiligten die "gleiche Sprache sprechen". Einheitliche Methoden und standardisierte Verfahren sind gefordert, die das Vorgehen waehrend aller Phasen des Softwareprojektes in Form von Aktivitaeten, Ergebnissen und anzuwendenden Methoden beschreiben.

Ein wesentlicher Kostenfaktor entsteht auch bei der Wartung und Pflege vorhandener Softwaresysteme. Entwickler sind heute bis zu 80 Prozent ihrer Zeit mit diesen Aufgaben beschaeftigt. Um diesen Aufwand zu verringern, ist eine integrierte Dokumentation des gesamten Systems von strategischer Bedeutung. Sowohl die Kenntnisse der organisatorischen Ablaeufe im Unternehmen als auch das Detailwissen ueber das Softwaresystem duerfen nicht allein in den Koepfen der Entwickler verfuegbar sein. Sie muessen personenunabhaengig zur Verfuegung stehen.

Wie bei der Herstellung anderer Produkte hat auch bei der Software-Entwicklung die Qualitaetssicherung eine zentrale Rolle zu spielen. Sie muss in das Total Quality Management einbezogen werden. Die Definition von Qualitaet klingt banal: Ein System genuegt dann den gesetzten Qualitaetsmassstaeben, wenn es sich fuer den gewuenschten Verwendungszweck eignet.

Qualitaet laesst sich nicht nachtraeglich in ein Erzeugnis hineinpruefen, sie ist von Anfang an ein wesentlicher Aspekt der Entwicklung. Qualitaetssicherung zaehlt zu den elementaren Bestandteilen der Software-Erstellung. Sie wird durch ein in den Entwicklungsprozess integriertes Qualitaets-Managementsystem gewaehrleistet, das sich an den Normen ISO 9000 ff orientiert.

Dazu gehoeren sowohl Qualitaetssicherungs-Pruefungen in festgelegten Realisierungsschritten als auch phasenuebergreifende Massnahmen, zum Beispiel Reviews zum Verifizieren und Validieren der Vorgaben fuer vorangegangene Phasen. Insbesondere sind systematische Tests zur Ueberpruefung des ordnungsgemaessen Funktionierens ein unverzichtbarer Bestandteil, wenn ein qualitativ hochwertiges Produkt geschaffen werden soll.

In der Hoechst AG steht fuer diese Aufgaben eine offene

Software-Entwicklungsumgebung (Oseu) zur Verfuegung. Sie umfasst sowohl ein Vorgehensmodell als auch Werkzeuge, die die Software- Entwicklung unterstuetzen. Offen heisst in diesem Zusammenhang, dass neue Werkzeuge mit wenig Aufwand in die vorhandene Entwicklungsumgebung integriert werden koennen.

Basis ist die Software-Engineering-Plattform Maestro II des Muenchner Softwarehauses Softlab. Kern dieser Umgebung ist das objektbasierte Online-Repository OMS (Object Management System), das sich dem Benutzer ueber ein Projekt- und Kon-

figurations-Management-System (PCMS) praesentiert. Das System gewaehrt eine effektive Teamarbeit, zumal alle Ergebnisse sofort saemtlichen Teammitgliedern zur Verfuegung stehen.

Alle Aktivitaeten und Ergebnisse, die innerhalb des LebenszyklusA der Software anfallen, werden im OMS verwaltet. Darueber regeln OMS beziehungsweise PCMS die Versionskontrolle, die Verwaltung von Status- und Zugriffsberechtigungen und das Konfigurations- Management.

Unsere Hardware-Umgebung besteht zur Zeit aus zwei HP9000- Systemen, die als Maestro-II-Server fuer derzeit 150 Workstations dienen. Fuer die Anbindung des IBM-Hosts werden vier SNA-Gateways sowie der Remote Job Entry (RJE) Link ueber Token Ring betrieben. Das Vorgehensmodell der Oseu umfasst ein Phasenmodell mit den Phasen Definition der Anforderungen, Spezifikation, Entwicklung und Test, Anwendertest und produktiver Einsatz, mit dem alle Ergebnisse waehrend des gesamten LebenszyklusA der Software abgedeckt werden.

Das Vorgehensmodell ist als Ergebnismodell in Form eines Baums im PCMS implementiert. Im wesentlichen besteht das Ergebnismodell aus den Bloecken Anforderungen und Pflichtenhefte, DV-System, Konfigurations-Management und Benutzerdokumentation. Die Ergebnisse, zum Beispiel des DV-Systems, werden in die Teilbaeume Funktionen, Oberflaeche, Daten und Tests gegliedert. In jeweils untergeordneten Strukturen sind die Spezifikationsdokumente und der eigentliche Sourcecode abgelegt.

Die Ergebnisse koennen zusaetzlich netzwerkartig miteinander verknuepft werden, indem Referenzen mit unterschiedlicher Semantik definiert werden. Eine Referenz kann beispielsweise beschreiben, welche Includes, Masken oder Daten ein Modul benoetigt. Moeglich ist auch die Definition der Zusammensetzung einer Testeinheit mittels Referenzen.

Hohe Prioritaet hat in einer modernen Entwicklungsumgebung die Versionsverwaltung aller im Software-Lebenszyklus erstellten Ergebnisse. Es muss zu jedem Zeitpunkt moeglich sein, eine bestimmte Version eines Ergebnisses zu rekonstruieren. Ein Dokument, etwa ein Quellcode, kann zeitgleich in verschiedenen Versionen existieren. Eine Variante laeuft beispielsweise produktiv, eine befindet sich aufgrund von Fehlern in Wartung und eine dritte wird weiterentwickelt. Um diesem Umstand Rechnung zu tragen, ist eine effektive Versionsverwaltung wichtig.

Zu wissen, welche Version eines bestimmten Ergebnisses zu einem Zeitpunkt produktiv gelaufen ist, reicht jedoch allein nicht aus. Ebenso muss die Gesamtheit aller Ergebnisse betrachtet werden koennen, also die Menge an Funktionen, die vom Anwender definiert, getestet und zum Einsatz freigegeben wird.

Die Entwicklungsumgebung Oseu der Hoechst AG umfasst daher ein integriertes Konfigurations-Management, das die Versionsfuehrung der gesamten Software regelt. Dazu werden die entsprechenden Versionen der Ergebnisse in Konfigurationen zusammengefasst. So existiert eine produktive Konfiguration, die die Ergebnisse enthaelt, welche im produktiven Einsatz sind. Darueber hinaus gibt es Entwicklungs- und Wartungskonfigurationen, die alle Versionen eines Entwicklungs- beziehungsweise Wartungsprojektes umfassen.

Diese Konfigurationen werden durch Zustandsautomaten gepflegt. Mit deren Hilfe lassen sich der aktuelle Status jedes Ergebnisses dokumentieren, die Entwicklungsschritte regeln und Versionen und Varianten der Ergebnisse erzeugen, da mit dem Uebergang eines Objektes von einem Zustand in einen Folgezustand jeweils entsprechende Funktionen verknuepft sind.

Des weiteren wird mit jeder Konfiguration festgehalten, welche Anforderungen in das Softwareprodukt eingegangen sind und in einem Entwicklungs- beziehungsweise Wartungsprojekt verarbeitet wurden. So laesst sich automatisch dokumentieren, welche Anforderungen wann zu welchen Aenderungen in bestimmten Programmen gefuehrt haben. Durch die Buendelung von Anforderungen zu einem Aenderungspaket werden die Aenderungsprozesse standardisiert und kontrolliert an der Software durchgefuehrt. Es entstehen jeweils neue Versionen oder Korrekturstaende. Damit ist Change Control ein integraler Bestandteil der Oseu.

Die Softwareproduktions-Um-gebung bietet ebenfalls die Moeglichkeit, systematisch Tests durchzufuehren. Die physische Aufspaltung in die produktive Umgebung sowie in die Entwicklungs- und Anwendertestumgebung gewaehrleistet eine saubere Trennung zwischen den Tests der Entwickler, der Anwender sowie dem produktiven Einsatz der Software. Der Uebergang der Software von einer Umgebung in die naechste wird durch ein wohldefiniertes Uebergabeverfahren geregelt und durch das Konfigurations-Management unterstuetzt.

Unter systematischem Test verstehen wir den jederzeit wiederholbaren Nachweis der Korrektheit eines Testobjektes relativ zu den vorher festgelegten Testzielen. Um dieses Ziel zu erreichen, wird fuer die Entwicklung, die privaten Tests jedes Entwicklers und die Integrationstests von Teilen des Systems eine geeignete Testumgebung bereitgestellt.

In der Oseu unterscheidet Hoechst im Bereich Entwicklungsumgebung zwischen den "privaten" Umgebungen der Entwickler und der "oeffentlichen" Umgebung. Jedem Projektmitglied steht eine private Umgebung fuer individuelle Tests zur Verfuegung. Auf diese hat kein anderer Mitarbeiter Zugriff. Hier koennen die einzelnen Tabellen und Dateien zu Beginn eines Tests vom Projektmitglied mit einem definierten Anfangsinhalt geladen werden, der jederzeit reproduzierbar ist. So ist gewaehrleistet, dass Tests wiederholt werden und die Ergebnisse eines Testlaufs mit den gespeicherten Ergebnissen eines zuvor durchgefuehrten Testlaufs verglichen werden koennen.

Regressionstest zur Fehlerpruefung

Mit diesen sogenannten Regressionstests wird beispielsweise geprueft, ob durch eine Programmaenderung Fehler in das bestehende System implementiert wurden. Ein weiterer Aspekt, der den Integrationscharakter der Entwicklungsumgebung noch einmal verdeutlicht, ist die Einbindung der Projektmanagement-Komponente in das Vorgehensmodell. Projekte lassen sich waehrend des gesamten EntwicklungszyklusA mit der fuer Projekt-Management erforderlichen Funktionalitaet versorgen.

Dieser Aspekt spielt eine wichtige Rolle, wenn es darum geht, die Komponenten Kosten, Nutzen und Ressourcen in einen optimalen Zusammenhang zu bringen. Technisch gesehen basiert die Anbindung der Projektmanagement-Funktionalitaet auf einer bidirektionalen Schnittstelle zwischen den Aufgaben, die Bestandteil des Vorgehensmodells sein werden, und dem Third-Party-Tool PMW der Firma Hoskyns.

Projektmanagement-Informationen, die in der Oseu eingegeben werden, koennen durch ein Download-Verfahren an PMW exportiert werden. Mit Hilfe der Funktionalitaet des Werkzeugs lassen sich die Daten hinsichtlich der Projektplanung beziehungsweise -verfolgung auswerten und in einem naechsten Schritt wieder in die Oseu importieren.

Diese Vorgehensweise ermoeglicht eine zentrale Ablage aller Projektinformationen (Aufgaben, Ergebnisse und Ressourcen) in einem Repository. So koennen Multiprojekte angemessen geplant und verfolgt werden, was dazu fuehrt, dass sich die folgenden Fragen projektuebergreifend beantworten lassen:

- In welcher Reihenfolge koennen Teilprojekte durchgefuehrt werden (Planung)?

- Welches Teilprojekt kann aktuell bearbeitet werden (Verfolgung)?

- Welche Teilprojekte muessen aufgrund von Ressourcenknappheit verschoben oder gestrichen werden (Planung und Verfolgung)?

- Wie koennen Gesamtkosten und -nutzen kalkuliert werden (Planung)?

- Wie sieht die praktische Arbeit mit der Oseu aus?

Die praktische Arbeit mit der Oseu, soll an einem Beispiel aus der Pflege eines bereits produktiv eingesetzten Systems verdeutlicht werden. Die Phase "Definition der Anforderungen" wird dazu verwendet, die Beduerfnisse des Kunden aufzunehmen, zu analysieren und schliesslich zu modellieren. Zunaechst werden die Anforderungen gesammelt und fuer die Entwicklung einer neuen Version oder eines neuen Korrekturstandes gebuendelt.

Zu jeder Anforderung koennen Informationen bezueglich des Anfordernden, der Prioritaet, der Termine sowie ueber Kurz- und Langbeschreibung etc. abgelegt werden. Zusaetzlich lassen sich Referenzen von der Anforderung zu Ergebnissen des DV-Systems definieren. Somit ist dokumentiert, welche Module, Masken etc. bei der Realisierung einer Anforderung veraendert werden muessen.

Umgekehrt lassen sich natuerlich auch ausgehend von einem Modul die Referenzen zu Anforderungen auswerten, so dass festgestellt werden kann, durch welche Anforderungen Veraenderungen im Modul durchgefuehrt wurden. Zusammen mit umfangreichen Reportfunktionen gelangt man somit zu einem integrierten Change Request Management.

Mit dem Aufsetzen einer neuen Entwicklungsversion wird das Konfigurations-Management automatisch angestossen, so dass die benoetigten Konfigurationen angelegt und entsprechend initialisiert werden. Ein Modul, das bei dem Pflegeprozess geaendert werden muss, befindet sich anfangs im Zustand "in Bearbeitung". Hier kann es editiert, kompiliert und gelinkt sowie in der privaten Testumgebung des Entwicklers getestet werden.

Ein besonderer Schwerpunkt wird hierbei auf die Wiederholbarkeit der Tests gelegt. Fuer jede Testfolge, die sich auf eine Testkomponente (ein oder mehrere Module oder bereits ausgetestete Komponenten) bezieht, werden die Ein- und Ausgabedaten, die waehrend des Tests entstehen, aufbewahrt. Auch die Anfangs- und Endinhalte der Datenbanken (vor und nach Ablauf des Tests) werden deponiert.

Ein solcher Test, fuer den die oben genannten Daten aufbewahrt wurden, laesst sich nun mit einem veraenderten Testobjekt zu jeder Zeit wiederholen. Indem die Datenbank mit dem gespeicherten Anfangsinhalt initialisiert und das Testobjekt mit den Eingabedaten versorgt wird, findet die Durchfuehrung des Tests unter den gleichen Voraussetzungen statt wie beim vorherigen Mal. Durch einen automatischen Vergleich der Ergebnisse des ersten Tests mit denen des zweiten laesst sich verifizieren, ob die Aenderungen des Testobjektes die erwarteten Auswirkungen auf das Ergebnis haben und keine unerwuenschten Nebeneffekte bei den restlichen Funktionen der Komponente entstanden sind.

Nach Abschluss der Bearbeitung wird das Modul in den Zustand "in Integration" gebracht. Geschuetzt gegen Schreibzugriffe kann er nun in der Integrationsumgebung des Projektes kompiliert, gelinkt und in Integrationstests getestet werden.

Im Zustand "in Qualitaetssicherung" werden nun die festgelegten Qualitaetssicherungs-Aktivitaeten durchgefuehrt. Hat das Modul diese Zustaende passiert, kann es zusammen mit anderen Komponenten des Softwaresystems dem Anwender in der Anwendertestumgebung zur Verfuegung gestellt werden.

Da durch das integrierte Konfigurations-Management in einer sogenannten Delta-Konfiguration dokumentiert wird, welche Komponenten der Anwendertest-Umgebung zu uebergeben sind, kann die Installation letztendlich in der Anwendertest-Umgebung automatisch durchgefuehrt werden. Verlaufen alle Tests in der Anwendertestumgebung zufriedenstellend, wird das nun freigegebene Modul als Bestandteil der neuen Version in die produktive Umgebung uebertragen.

Basierend auf den geschilderten Konzepten laesst sich ein grosses Nutzenpotential fuer die Wartung und Pflege bestehender sowie die Erstellung neuer Systeme erkennen. Wird dieses Potential gezielt eingesetzt, kann die Produktivitaet und Qualitaet der Software- Entwicklung erhoeht werden.

Wo liegen nun die moeglichen Einsatzfelder einer Entwicklungsumgebung, wenn es darum geht, Standardsoftware einzufuehren? Wie bereits erwaehnt, lassen sich bei der Einfuehrung von Standardsoftware nicht alle betriebswirtschaftlichen Ablaeufe gleichzeitig beruecksichtigen. Dieser Prozess vollzieht sich sukzessive, er ist abhaengig von Rahmenbedingungen und der Komplexitaet eines Konzerns. Daher ist es wichtig, ein moeglichst reibungsloses Zusammenspiel aktueller Anwendungssysteme mit der neu einzufuehrenden Standardsoftware zu ermoeglichen. Mit anderen Worten: Je nach Anforderung sind Schnittstellen zwischen der Standardsoftware und den operativen Anwendungssystemen zu schaffen. Auf diese Weise ist es moeglich, einen Teil der betriebswirtschaftlichen Funktionen durch Standardsoftware zu ersetzen, ohne den produktiven Betrieb zu behindern.

Um Schnittstellen zwischen Standardsoftware und Eigenentwicklungen bereitzustellen, muss auf Informationen aus den Anwendungssystemen (zum Beispiel abstrakte Datenstrukturen) zugegriffen werden. Diese sind im wesentlichen in der Oseu abgelegt und koennen jederzeit recherchiert werden.

Die Anwendungsentwicklung erhaelt einen neuen Stellenwert. Waehrend Standardsoftware auf den Gebieten betriebswirtschaftlicher Ablaeufe ueberall dort eingesetzt wird, wo sie erstens zur Verfuegung steht und zweitens die Ablaeufe sinnvoll abbildet, konzentriert sich die Eigenentwicklung auf komplementaere Bereiche.

Bei allem Enthusiasmus fuer Standardsoftware gibt es auch hier Huerden, die erst einmal genommen werden muessen. Bei der Einfuehrung stehen Methoden, Modelle und Verfahrensweisen zur Abbildung betriebswirtschaftlicher Funktionen zur Verfuegung, mit denen unter Umstaenden die Anpassung auf eine komplexe Unternehmensstruktur, wie sie in Grossunternehmen zu finden ist, erfolgen kann. Dabei bleibt einem Unternehmen jedoch oft nur die Alternative, betriebswirtschaftliche Ablaeufe an die vorgegebenen Modelle anzupassen. Dieser Trend wirkt den Bemuehungen um ein oder mehrere Unternehmensdatenmodelle entgegen, da diese in der Regel nicht mit denen der Hersteller von Standardsoftware uebereinstimmen.

Dieser Aspekt stellt sich bei der Erstellung von Individualsoftware ganz anders dar, weil hier die Moeglichkeit besteht, auf interne Besonderheiten unter Beruecksichtigung bereits existenter Unternehmensdatenmodelle individuell einzugehen. Dies wiederum bedingt die Moeglichkeit, auf Informationen betrieblicher Anwendungssysteme effizient zugreifen zu koennen - Informationen, die zum Beispiel im Repository einer Entwicklungsumgebung abgelegt sind.

Auf diese Art und Weise besteht die Moeglichkeit, auf sich veraendernde Organisationsstrukturen gezielt und vor allem schnell zu reagieren, ein Faktor, der fuer das Erarbeiten von Wettbewerbsvorteilen wichtig ist. Wird auf die Entwicklung von Individualsoftware gaenzlich verzichtet, so ist man mehr denn je darauf angewiesen, dass Loesungen vom Hersteller der Standardsoftware kommen. Dies koennte bei kurzfristig eintretenden Veraenderungen

(zum Beispiel Gesetzesaenderungen) zu einem Verlust an Flexibilitaet fuehren.

Entwickler-Know-how ist wichtiges Kapital

Standardsoftware deckt zwar einen grossen Teil an betriebswirtschaftlichen Funktionen ab, ist jedoch branchenneutral und muss infolgedessen auf die individuellen Beduerfnisse angepasst werden. Gelingt dies nicht, so kommen die individuellen Anforderungen des Unternehmens zu kurz. Die Erfahrungen sowie das Know-how, das auf dem Gebiet Software-Engineering im Laufe der Jahre erarbeitet wurde, stellt ein Kapital dar, das gerade bei der Realisierung von Spezialanforderungen eingebracht werden kann.

Der Verzicht auf eine ausgereifte Software-Entwicklungsumgebung wuerde zwar zu einer kurzfristigen Kostensenkung im Bereich Informationstechnik fuehren, duerfte aber ein Defizit an Flexibilitaet zur Folge haben, weil die Reaktionsgeschwindigkeit auf wechselnde Verhaeltnisse von mehr Faktoren als dem Potential und der Kreativitaet der eigenen Mitarbeiter abhaengt.

In Zeiten sich wandelnder Geschaeftsprozesse und neuer Technologien im Bereich der Informationstechnik sollte die Chance ergriffen werden, betriebswirtschaftliche Funktionen unter Beruecksichtigung der Komponenten Kosten, Nutzen und Ressourcen effizient zu gestalten - mit Standard- und mit Individualsoftware!