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.

09.09.1994

Die Einfuehrung von Standardsoftware ist sehr teuer Re-Engineering kann eine preiswerte Alternative sein

Die Einfuehrung von Standardsoftware ist in aller Regel teuer - ebenso die Entwicklung komplexer Applikationen. Mario Zaleski* raet Anwendern, vorab zu pruefen, ob sich Softwareprobleme nicht mit einem preiswerteren Re-Engineering loesen lassen.

In vielen Faellen bildet Re-Engineering eine lohnenswerte Alternative zur Neuentwicklung einer Individualapplikation oder zum Kauf von Standardsoftware. Dabei bewaehrt es sich, Re- Engineering als Festpreisprojekt mit klar bestimmtem Endtermin durchzufuehren.

Hauptvorteile sind die ueberschaubaren Projektkosten und

-risiken sowie die sehr kurze Projektdauer, verglichen mit einer Neuentwicklung oder Standardsoftware-Einfuehrung. Die Benutzer arbeiten mit ihrem gewohnten System weiter, so dass keine oder nur geringe Schulungs- und Einarbeitungskosten anfallen. Und nicht zuletzt wird durch Re-Engineering die Qualitaet der Altanwendung stark verbessert, ihre Lebensdauer erhoeht.

Oft hilft eine Verbesserung der Programmstruktur

Oft kann schon allein das Optimieren von Programmstruktur und - dokumentation den Aufwand fuer die Softwarewartung und - weiterentwicklung reduzieren und damit ein Re-Engineering-Projekt rechtfertigen. Die sanierten Softwaremodule lassen sich zudem in kuenftigen Entwicklungsprojekten einfacher wiederverwenden. Nicht zuletzt laesst sich durch Re-Engineering wertvolle Zeit gewinnen, etwa bis die finanziellen Mittel fuer eine Abloesung der Altsysteme bereitstehen oder eine stabile informationstechnische Basis vorhanden ist.

Die Ausgangslage vor Re-Engineering-Projekten aehnelt sich oft: Mehrere grosse Anwendungssysteme decken zwar funktional die Anforderungen des Unternehmens ab, aber aus den unterschiedlichsten Motiven heraus ist es noetig, sie auf eine neue technische Basis zu stellen. Zum Beispiel wird die Programmarchitektur des Unternehmens auf relationale Datenbanken umgestellt, im Rahmen der PC-Integration sind grafische Benutzeroberflaechen gewuenscht, der Hersteller unterstuetzte eine wichtige Hardwarekomponente oder Systemsoftware nicht laenger, oder das Anwendungssystem soll im Zuge von Downsizing oder Dezentralisierung auf offene Systeme und Client-Server-Strukturen portiert werden.

Andererseits koennen anstehende dringende organisatorische Aenderungen umfangreiche funktionale Adaptionen am Programm erfordern, etwa im Rahmen des Business Process Re-Engineering, einer Neupositionierung des Unternehmens in seinen Maerkten oder im Zuge von Rationalisierungsmassnahmen.

Unabhaengig von der Groesse der IT-Abteilung und der Branche, in der das Unternehmen aktiv ist, steckt der IT-Manager in einer vertrackten Zwangslage. Normalerweise ist die Applikation nach vielen Jahren durch haeufige Fehlerkorrekturen, Optimierungsmassnahmen und Weiterentwicklungen nur noch schwer zu warten und auszubauen. Oft fehlt die Dokumentation der Software und die dem Programmdesign zugrundeliegende Geschaeftsprozessanalyse, oder sie ist unzureichend und veraltet.

Ist die Applikation schon sehr alt, laesst sich der Quellcode unter Umstaenden gar nicht mehr auffinden, oder er ist in einer Sprache geschrieben, die niemand im Hause mehr nutzt (Assembler, PL/1, alte Cobol-Versionen, ausgemusterte Sprachen der 4. Generation). Manche IT-Manager sehen als Ausweg nur einen voelligen Neubeginn - vorausgesetzt, die betraechtlichen finanziellen Mittel dazu sind vorhanden.

Sie wollen mit einem Befreiungsschlag den Ballast der Vergangenheit abwerfen und setzen entweder auf eine Standardsoftware, die ein Softwarehaus wartet und ausbaut, oder auf eine Neuentwicklung mit Hilfe moderner Software- Entwicklungstechnologien.

Die Software-Altlasten, um die es in der Re-Engineering-Diskussion geht, sind sehr grosse, komplexe, mit Datenbanken und anderen Anwendungen eng verzahnte Programme, die ueberlebenswichtige Unternehmensfunktionen unterstuetzen. Das mit Neuentwicklung oder Austausch durch Standardsoftware verbundene Risiko, Geschaeftsprozesse zu stoeren oder gar zu unterbrechen, ist inakzeptabel.

Zudem sind die Kosten fuer solche Mammutprojekte in der heutigen Zeit kaum zu rechtfertigen. Und nicht zuletzt passt ein mehrjaehriges Entwickungsprojekt, wie es dafuer notwendig waere, nicht mehr so recht in eine Zeit, in der Flexibilitaet und schnelle Reaktionen am Markt zaehlen.

Im Prinzip eignen sich alle vorhandenen Altanwendungen fuer hochautomatisiertes Re-Engineering, vorausgesetzt Re-Engineering wird als systematischer Prozess aufgefasst. Natuerlich sind die Methoden des Re-Engineering gezielt und bewusst einzusetzen. Dazu empfiehlt sich eine gruendliche Analyse des Softwarebestands. Analysiert werden die Applikationen in dreierlei Hinsicht:

- nach ihrer Bedeutung fuer das Unternehmen (geschaeftsnotwendig, wichtig, unterstuetzend, zukunftsorientiert, nicht laenger notwendig);

- nach Funktionalitaet und Nutzung (Abdecken der Geschaeftsprozesse, Aenderungsfrequenz, Ergebnisqualitaet, Anzahl der Nutzer, Mengengeruest, Schnittstellen);

- nach informationstechnischer Qualitaet (Nutzungsdauer und Alter, Stabilitaet und Zuverlaessigkeit, Performance, Entwicklungsqualitaet, Wartungsqualitaet und -intensitaet, Personalsituation).

Die vorhandenen Programme lassen sich in fuenf Klassen einteilen:

- Neuentwicklung oder Abloesung durch Standardsoftware notwendig - wegen der grossen Bedeutung fuer das Unternehmen und der starken Differenz zu den fachlichen Anforderungen;

- Re-Engineering nach einer Prioritaetsskala erforderlich - wegen der hohen Relevanz fuer den Geschaeftsbetrieb sowie der funktionalen und technischen Qualitaet;

- unveraenderter Betrieb und Wartung - wegen der Relevanz des Programms fuer das Unternehmen und wegen ihrer hohen fachlichen und technischen Qualitaet, die auch in Zukunft die Anwendungsarchitektur nicht stoeren wird;

- unveraenderter Betrieb, reduzierte Wartung und Weiterentwicklung - wegen geringerer Relevanz fuer das Unternehmen, die eine reduzierte Wartung erlaubt;

- kuenftig aussortierte Applikationen, fuer die ein Support entfaellt.

Historischen Ballast abwerfen

Bei nur zehn bis 15 Prozent der Programme ist im Normalfall eine Neuentwicklung oder die Abloesung durch Standardsoftware unverzichtbar. Allein das Ermitteln hinfaelliger Programme, die allein als "historischer Ballast" mitgeschleppt werden, kann die Anwendungsentwicklung von ueberfluessiger Wartungsarbeit befreien.

Dieser Ballast macht mitunter zehn bis 20 Prozent des gesamten Softwarebestands aus. Die Programmierer koennen sich auf die "wartungswuerdigen" Applikationen konzentrieren. Dieser Effekt verstaerkt sich durch die Priorisierung der Programme.

Den groessten Block, normalerweise rund 50 Prozent aller Anwendungen, bilden die Re-Engineering-Kandidaten. Durch Konzentration der Sanierungsarbeiten auf diese wirklich relevanten Programme steigen zudem die Erfolgschancen des Re-Engineering- Projekts deutlich. Insgesamt lassen sich allein durch die Reduktion des Aufwands mit Hilfe der Priorisierung und Modernisierung die Support-Kosten drastisch senken.

Solch typische Re-Engineering-Kandidaten sind Applikationen mit hoher Wartungsintensitaet und vielen Modifikationen, an denen aber funktional nichts auszusetzen ist und die vital fuer das Geschaeft sind. Andere Anwaerter sind beispielsweise wichtige Programme mit niedriger Entwicklungsqualitaet (zum Beispiel undokumentiert oder nicht modularisiert), die erweitert werden sollen.