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.

21.06.1991 - 

Unternehmen lügen sich bei der Projektdauer in die Tasche

Fließende Übergänge von der Entwicklung bis zur Wartung

Immer wieder wird der ungeheure Wartungsaufwand in den DV-Abteilungen beklagt. Nicht selten, so die Erfahrung von Gerd M. Henselmann*, wird ein Projekt lediglich aus Gründen der Selbstdarstellung für termingerecht abgeschlossen erklärt. Wirklich fertiggestellt wird die Anwendung dann erst in der sogenannten Wartungsphase.

Zur Wartung gehört laut Brockhaus Pflege, Betreuung, regelmäßiges Nachschauen, Instandhaltung. Ständiges kostenpflichtiges Nachbessern ist damit nicht gemeint. Das ist jedoch genau die Situation, in der sich viele DV-Abteilungen heute befinden.

Die Hälfte des Wartungsaufwandes in den DV-Abteilungen entfällt nach Untersuchungen der IBM und der Marktbeobachter von IDC auf Funktionserweiterungen. Und weil diese Addons nicht von Anfang an im Konzept vorgesehen wurden, zieht das Flickwerk wiederum einen erhöhten Pflegeaufwand nach sich. Ein Faß ohne Boden, ein Kreislauf ohne Ende?

Ganz im Gegensatz zum allgemeinen Verständnis führen die Ovum-Marktbeobachter und die IBM unter dem Begriff Wartung einen Wust an Aktivitäten an, zu denen Rettungs- und Wiederbelebungsversuche in bezug auf Systeme gehören, von denen Anbieter wie Kunden wissen, daß ihre Leistung nicht den sich ständig verändernden Anforderungen gerecht werden kann.

Die falschen Vorstellungen vom Wartungsbegriff stammen aus den Tagen der ersten Computer. Damals konnten Kunde und Anbieter optimistisch davon ausgehen, gemeinsam ein Problem zu definieren, eine Lösung als Antwort vorzulegen und zu realisieren.

Eine solche Vorgehensweise funktioniert heute nur noch bei kleinen Projekten. Die Komplexität von Aufgaben, die darüber hinaus gehen, kann weder das Software-Unternehmen noch der Anwender überblicken. Unternehmen, die das nicht einsehen, laufen Gefahr, daß Systeme entwickelt werden, die weder vollständig sind, noch zur Zufriedenheit der Anwender arbeiten. Dies umso mehr, je interaktiver und integrativer die Lösungen in Firmen eingebracht werden. Hinzu kommt, daß auch das Verhalten des Anwenders sich verändert. Die Wünsche des Nutzers in bezug auf sein System stellen immer nur eine Momentaufnahme dar und können daher nicht festgeschrieben werden.

Kunden sollten heute für ihr neues System nicht die komplette, sprich: maximale, Funktionalität fordern, sondern eine Grundfunktionalität auf Basis einer offenen Architektur. So können später zusätzliche Wünsche leichter eingebracht werden.

Der Grund: Software-Entwicklung ist ein evolutionärer Prozeß. Die Anwendungen müssen reifen können. Systeme von heute können nicht den Anforderungen von morgen gerecht werden. Einen Ausweg aus dieser Situation bietet der Einsatz einer offenen Architektur.

Bei der Finanzplanung sollte die erste Projektphase mit einem bis zwei Drittel des insgesamt vorgesehenen Finanzvolumens ausgestattet sein. Dabei muß der Projektleiter damit rechnen, daß weitere, wichtige funktionale Erweiterungen folgen. Die Spezifikationen dafür ergeben sich auf Basis von Erfahrungen, die der Kunde mit seiner ersten Systemversion gemacht hat.

Entwicklungen von Softwarehäusern

Wenn sich Unternehmen bei ihren Entwicklungen von Softwarehäusern helfen lassen, dann bieten sich hierfür zwei grundsätzliche Vorgehensweisen an:

- Die Entwicklung eines neuen Systems kann über einen Prototypen gehen, der nach der ersten Spezifikation des Anwenders erstellt wird und ihm die Möglichkeit gibt, anhand dieses Prototypen seine Meinung zu verifizieren.

- Wenn das Prototyping bei einem großen System zu aufwendig ist, sollte eine evolutionäre Software-Entwicklung angestrebt werden. Der Anwender erhält ein Produkt, das weitgehend seinen Vorstellungen entspricht, jedoch die Möglichkeit der Weiterentwicklung in sich trägt. Das System kann der Nutzer bereits einsetzen, es wurde aber von vornherein mit dem Ziel der Weiterentwicklung konzipiert.

Leichte Wartbarkeit und Erweiterbarkeit sollten also in der Konzeption Berücksichtigung finden. Denn dies sind zwei Gesichtspunkte, die sich auf die Gesamtstruktur der Software, ihre Leistungsfähigkeit und auf die Wirtschaftlichkeit auswirken. Die oben vorgestellte Vorgehensweise ist bei Standardsoftware üblich. Es spricht nichts dagegen, bei der Entwicklung von Anwendungssoftware analog zu verfahren. Geschieht dies nicht, hat man heute in vielen Systemen nicht die Chance, gewünschte und erforderliche Veränderungen einzubringen.

Der vorher erwähnte Prototyp wird bei Standardsoftware Release 0 genannt. Alle weiteren Release-Stände bestehen dann aus konsequent durchgezählten Erweiterungen zugunsten von Stabilität, Zeitverhalten, zusätzlicher Funktionalität oder sonstiger Eigenschaften. Diese Vorgehensweise verfolgen heute bei der Anwendungssoftware noch zu wenige Systemfirmen - mit dem Ergebnis eines undurchdringlichen Wartungs-Dschungels.

Leistungsdruck behindert das "Learning by doing"

Es sind nicht die Software-Entwickler oder die Anwender, sondern Firmenleitungen auf beiden Seiten, die der Softwareweiterentwicklung bewußt das Mäntelchen der Wartung umhängen.

Auf Anwenderseite scheint es der Unternehmensleitung oft wichtiger zu sein, sich zu einem fixen Termin unter dem Stichwort "System läuft" (Operation geglückt, Patient tot) zu präsentieren. Weniger beliebt ist der nicht so wirkungsvolle Auftritt, bei dem die erfolgreiche Umsetzung immer neuer Phasen eines Gesamtkonzepts vorgestellt wird.

Das Investitionsverhalten der Betriebe unterstützt diese Vorgehensweise: Die Firmenleitung hat ein Budget für das Jahr X und das Projekt Y verabschiedet. Wenn das Geld verbraucht, das Projekt realisiert und das abgesteckte Zeitlimit abgelaufen ist, beginnt die Wartungsphase. In Wirklichkeit geschieht auch jetzt nichts anderes als während der Projektdauer.

Gegen diese Form der scheinbar abgeschlossenen Projekte spricht auch, daß es den Anwendern in der Regel schwer fällt, von vornherein die Anforderungen genau zu spezifizieren. Ihnen wäre es lieber, sie könnten die auftauchenden Wünsche nach und nach in ein laufendes Projekt einbringen. So stehen sie unter dem Druck, entweder mit ständig neuen Nachbesserungswünschen den Projektablauf zu stören oder auf die Funktionen zu verzichten, die sie eigentlich brauchten.

Die Chefs der Software-Industrie ziehen gern prestigeträchtige Großprojekte an Land. Sie sind überschaubar und kalkulierbar, vor allem was die langfristige Planung der Mitarbeiterauslastung betrifft. Auch hier empfiehlt eine wachsende Gruppe von Informatikern, die aus der methodischen Software-Entwicklung kommt, evolutionäres Denken.

Von Technikern ist bekannt, daß sie viel zufriedener sind, wenn sie ihre Projekte in überschaubaren Schritten realisieren können. Die Devise heißt: keine Kraftakte mehr, keine Nacht- und Nebelaktionen, sondern kontinuierliches Abarbeiten einer Aufgabe. Auf diese Weise produzieren die Mitarbeiter höhere Qualität, weil wenige aber nicht dauernd wechselnde Mitarbeiter durch eine dauerhafte Beschäftigung mit einem Thema zu besseren Lösungen kommen.

*Gerd M. Henselmann ist Mitglied der Geschäftsleitung der Collogia Unternehmensberatung GmbH in Köln.