Verantwortliche in der Software Entwicklung entscheiden sich - vielleicht nach einem Messerundgang - oftmals für ein CASE-Werkzeug, ohne die Rahmenbedingungen für dessen Einführung geschaffen zu haben. Die Implementierung einer "Software Produktionsumgebung" (SPU) beinhaltet indes weit mehr als nur die Auswahl eines CASE Tools, wie Gerd Hilgendorff beschreibt.

Wer sich mit CASE bereits näher beschäftigt hat, wurde häufig auch durch Anbieterversprechungen - hochgesteckten Erwartungen nicht erfüllt werden konnten. Etwas süffisant wird die Abkürzung dann mit einem ähnlich klingenden Nahrungsmittel in Verbindung gebracht, denn beides habe ja Löcher.

Die Grafiken sind uns aus der einschlägigen Literatur bekannt: Der Zielerreichungs-Grad der Software-Entwicklung ist beschämend gering. 47 Prozent der Software wurden zwar bezahlt, aber nicht geliefert. Ein Anteil von 29 Prozent wird zwar an den Auftraggeber geliefert, kann dort aber nicht benutzt werden, da das Paket nicht (mehr) den Anforderungen des Auftraggebers entspricht. Nur ein Prozent wird genau dem Auftrag entsprechend entwickelt und kann auch ohne weitere Änderung für den vorgesehenen Zweck eingesetzt werden.

Knapp 50 Prozent der festgestellten Fehler während der SW- Entwicklung resultieren aus falscher Analyse oder funktionaler Spezifikation, sind also der Projektphase "Analyse" zuzuordnen Weitete 26 Prozent der festgestellten Fehler sind in der Projektphase "Design" zu suchen, und nur das letzte Viertel der Fehler stammt aus der Realisierungsphase. Der Aufwand zur Behebung eines Fehlers steigt mit jeder dieser Projektphasen und den Faktor zehn. Offensichtlich wird der Analyse und den funktionalen Anforderungen eines Softwaresystems nicht die notwendige Aufmerksamkeit und Genauigkeit geschenkt.

Die Folge ist, daß rund zwei Drittel des gesamten Aufwands bei der Software-Entwicklung für die Wartung und Änderung von Softwaresystemen benötigt werden, und das mit steigender Tendenz. Im Klartext: Weniger als ein Drittel der Software-Entwickler stellt für Neuentwicklungen zur Verfügung. Offensichtlich liegt hier das größte Rationalisierungspotential in der Software-Entwicklung. Grundlage für eine hochwertige und schnelle Wartung ist jedoch eine konstruktive Voraussicht bereits bei der Entwicklung der Software.

Die am häufigsten genannten Probleme in der Software-Entwicklung sind:

- keine klare Zieldefinition;

- Probleme bei der Terminierung von Projekten;

- uneinheitlich Methode der SW Entwicklung;

- Methoden und Werkzeuge sind oft nicht adäquat:

- keine Wiederverwendbarkeit vorliegender Ergebnisse;

- Dokumentation entspricht nicht dem aktuellen Release;

- Abhängigkeit von einzelnen Entwicklern;

- mangelnde maschinelle Unterstützung insbesondere in der Konzeptphase;

- keine maschinelle Konsistenzprüfung innerhalb eines Projektes;

- keine einheitlichen Standards;

- Qualitätssicherung erst am Ende eines Projektes;

- zu hoher Aufwand für die Softwarewartung.

Bereits hier wird klar, daß Auswahl und Einsatz eines CASE-Tools allein nicht ausreichen, um die vorstehenden Probleme zu lösen.

Viele Probleme sitzen jedoch tiefer; sie müssen bereits im Vorfeld eines Projektes packt werden.

Einführung einer SPU: Die Ziele

Verbesserungen auf mehreren Ebenen sollten beim SPU-Einsatz angestebt werden und können auch erreicht werden: Einheitliche Verfahren der SW-Entwicklung, festgehalten in einem Projekt-Management-Handbuch, reduzieren insgesamt die Entwicklungszeiten und führen zu strikterer Termintreue sowie dazu, daß Kostenvereinbarungen zuverlässiger werden. Standardisierte, ingenieurmäßig produzierte Software verringert die Abhängigkeit von einzelnen Entwicklern und vereinfacht die ständige Qualitätskontrolle. Wegen der höheren Produktivität sind Entwicklungsmitarbeiter eher für neue Projekte frei.

Aus der Dezentralität einer SPU ergibt sich der Vorteil, daß Entwicklungsarbeiten auf vernetzten PCs oder Workstations stattfinden können, während alle Entwicklungsergebnisse zentral in einer Datenbank vorgehalten werden. Sie sind dadurch in höherem Maße wiederverwendbar.

Die Voraussetzungen eines SPU-Projektes

Grundsätzlich gilt, daß zuerst die organisatorischen Methoden identifiziert und eingeführt werden müssen, bevor ein CASE-Tool ausgewählt wird. Das oberste Management muß aktiv die Einführung einer SPU unterstützen. Die Gründe dafür liegen auf der Hand:

Es können organisatorische Änderungen notwendig werden: Die Einführung einer SPU verändert die DV eines Unternehmens. Es handelt sich um eine unternehmensstrategische Entscheidung für zehn bis fünfzehn Jahre. Der Investitionsbedarf für die Entwicklung und unternehmensweite Einführung eines Projekt-Management-Handbuchs, der Methoden der Sofware-Entwicklung und eines CASE-Tools liegt in einer Größenordnung, die in aller Regel von der Unternehmensleitung genehmigt werden muß. Die an dem Projekt beteiligten Mitarbeiter sollen von anderen Aufgaben freigestellt werden, damit sie sich voll auf die Projektarbeit konzentrieren können.

Eine externe projektbegleitende Beratung ist sinnvoll: Dadurch wird eher eine vorhandene Betriebsblindheit überwunden und eine objektive Vorgehensweise ermöglicht. Für die Auswahl der Software-Entwicklungsmethoden sowie das Definieren der Kriterien zur Auswahl eines CASE-Tools kann ein erfahrener Berater sicherlich einiges beitragen.

In diesem Arbeitsblock sollten folgende Fragen beantwortet werden: Welche Projekte, welche Softwaresysteme werden im Unternehmen künftig durchgeführt beziehungsweise entwickelt - technische, kommerziell administrative? Gibt es neue Geschäftsfelder, für die Softwaresysteme erstellt werden sollen? Welche Anforderungen seitens der Fachabteilungen bestehen in den nächsten Jahren? Welche Zielsysteme, welche externen und internen Schnittstellen und Systeme müssen berücksichtigt werden? Werden Client-Server-Architekturen, verteilte Datenhaltung, verteilte Datenverarbeitung künftig gefordert?

Die Fragen müssen mit dem DV- und dem Fachabteilungs-Management ausführlich besprochen werden. Dadurch werden maßgeblich die Auswahl der Software-Entwicklungsmethoden und die Kriterien für die Auswahl eines CASE-Tools bestimmt.

Organisation

In diesem Arbeitsblock wird festgelegt, in welcher Organisationsform künftig Projekte abgewickelt werden sollen. Es gibt mehrere Projekt-Organisationsformen, so zum Beispiel die Stab-, die Matrix- und die reine Projektorganisation. Jede dieser Organisationsformen hat ihre spezifischen Vor- und Nachteile, die analysiert werden müssen. Mitarbeiter, die an einem Softwareprojekt arbeiten, sollten aus ihrem Tagesgeschäft (zum Beispiel Wartung und Pflege) herausgelöst und für die Projektarbeit freigestellt werden. Ideal ist es, wenn die Mitarbeiter der Software-Entwicklung und der Fachabteilung (Auftraggeber) in ein gemeinsames Büro "zusammenziehen" um sich so voll auf die Projektarbeit konzentrieren zu können Die Projekte werden so besser kalkulierbar, planbar und terminierbar.

Verfahren

Ziel dieses Arbeitsblockes ist das Erarbeiten, Abstimmen und Einführen eines unternehmensweiten Projekt-Management-Handbuchs (PMH). Dadurch wird eine durchgängige und einheitliche Vorgehensweise für die Durchführung von Softwareprojekten gewährleistet. Das PMH; sollte sich an mittelgroßen Projekten orientieren, für Großprojekte kann es individuell ergänzt werden. Das PMH sollte kein dicker Ordner sein, den niemand liest, sondern eher eine Handanweisung, eine Checkliste, die als Orientierungshilfe schnell zur Verfügung steht. Die wichtigsten Punkte des PMH können in einer unternehmensspezifisch gestalteten Reference-Card allen Mitarbeitern zur Verfügung gestellt werden; so wird gewährleistet, daß sowohl die Fachabteilung als auch die SW-Entwicklung die gleiche Terminologie verwenden und nicht aneinander vorbei reden.

Besser ist also eine praxisorientierte, mit den Mitarbeitern abgestimmte und daher von ihnen auch getragene Handanweisung, die auf jedem Schreibtisch Platz hat, als ein theoretisch abgefaßtes und alle erdenklichen Möglichkeiten berücksichtigendes Handbuch, das in den Schränken verstaubt. Natürlich muß das Projekt-Management einschließlich der Anwendung des Handbuchs unternehmensweit geschult werden. Dies stellt zwar einen recht hohen Aufwand dar, der Nutzen, der sich daraus ergibt, rechtfertigt dies aber.

Methoden

Es gibt eine Vielzahl von Software-Entwicklungsmethoden, die jedoch in der Praxis nur sehr selten angewendet werden. Die Abkürzungen SA, SA/RT, SD, OOSD, SADT, JSD, JSP, HIPO, IE und LSDM stehen wohl für die bekanntesten Methoden. Bei der Auswahl einer geeigneten Methode sollte man sich nicht von dem manchmal haarspalterischen Philosophenstreit der SW-Gurus beeindrucken lassen. Manchmal hat man den Eindruck, daß gleiche Sachverhalte nur mit anderen Symbolen und Namen versehen werden.

Nachdem die vorgenannten Punkte, die Analyse der zukünftigen Softwareprojekte, der Organisationsform, das Verfahren zur Projektabwicklung und die Methoden der Software-Entwicklung geklärt, ausreichend geschult und eingeführt sind, folgt die Auswahl der Software-Entwicklungswerkzeuge.

Werkzeuge

Zunächst werden die Grundanforderung für eine Werkzeugumgebung definiert: Unverzichtbar ist die Unterstützung verschiedener Zielsysteme und Netzumgebungen. Die Oberfläche sollte grafikorientiert sein und die Verwendung einer Maus als Eingabemedium unterstützen. Für die unterlegte Entwicklungsdatenbank gilt, daß sämtliche Ergebnisse der einzelnen Teilschritte eines Projektes zentral abzulegen sein müssen. Die Entwicklungsdatenbank sollte multiprojekt- und multiuserfähig sein und eine Status und Versionsverwaltung beinhalten. Die von den Werkzeugen unterstützten Ziel-Programmiersprachen (Cobol, C, SQL) und Standards sind festzulegen.

Dasselbe gilt für die Methoden, die in sämtlichen EntwickIungsphasen eines Projektes eingesetzt werden. Auswahlkriterium hat zu sein, ob diese Methoden, etwa SA, SD, ERM, Datennormalisierung, Prototyping etc., durchgängig maschinell unterstützt werden können. Allgemeine Kriterien, zum Beispiel die Unterstützung der Projektplanung und -verfolgung und die Fähigkeit zur Kommunikation mit anderen Werkzeugen, sind anzulegen, ebenso wie die Anforderungen an die Im- und Export-Schnittstellen.

Mit Hilfe externer Unterstützung und entsprechender Fachliteratur wird nun ermittelt, welche Werkzeuge überhaupt in Frage kommen. Die Anbieter dieser Werkzeuge werden mit dem Katalog der Grundanforderungen angeschrieben. Die eingehenden Antworten und Unterlagen werden gegen die Grundanforderungen geprüft. Bei unklaren Antworten sollte Rücksprache erfolgen. Hier ist jedoch Vorsicht geboten: Die Marketing-Aussagen in den Hochglanzprospekten stimmen nicht immer mit den tatsächlichen Leistungsfähigkeiten der Produkte überein. So haben wir bei Vorführungen und bei Tests der Produkte zum Teil eklatante Differenzen zwischen Werbung und tatsächlicher Leistung festgestellt.

Die drei bis fünf Produkte, die die Grundanforderungen zum größten Teil erfüllen, werden genauer untersucht. Für die "Endausscheidung" sollte ein ausführlicher Kriterienkatalog erarbeitet werden, anhand dessen jedes einzelne Produkt ausführlich überprüft und bewertet werden kann. Um keine wichtigen Positionen zu vergessen, kann als Grundlage für diesen Kriterienkatalog ein Musterkatalog dienen, der von mehreren Instituten angeboten wird. Dieser Musterkatalog sollte an die firmenindividuellen Gegebenheiten angepaßt und ergänzt werden. Auch die Gewichtung der einzelnen Punkte muß überprüft und angepaßt werden.

Damit die Erfüllung der einzelnen Punkte nachvollzogen werden kann, wird eine Musteranwendung, also ein Testprojekt erstellt. Damit der anschließende Test auch wirklich aussagekräftig ist, sollte diese Musteranwendung nicht zu klein sein und alle Phasen eines Softwareprojektes abdecken.

Für jedes Produkt wird jetzt eine ausführliche Präsentation organisiert, die bis zu drei Tage dauern sollte.

Anhand der zuvor erstellten Musteranwendung wird der Erfüllungsgrad jedes einzelnen Punktes im Kriterienkatalog überprüft und bewertet. Wird ein Kriterium überhaupt nicht erfüllt, erhält es den Wert null, wird es voll erfüllt, erhält es den Wert zehn. Es empfiehlt sich daß die eigenen Mitarbeiter mit dem Produkt arbeiten, damit sie ein Gefühl für die Handhabbarkeit erhalten.

In der anschließenden Nutzwertanalyse wird für jedes Kriterium die Gewichtung mit der Bewertung multipliziert und in die Tabelle eingetragen. Das Produkt mit der höchsten Punktzahl hat den höchsten Erfühllungsgrad. Vor zu großer Euphorie sei allerdings gewarnt: Es ist nicht unwahrscheinlich, daß selbst der "Sieger" nur 60 Prozent der Anforderungen erfüllt.

Produkteinführung

Vor der endgültigen Entscheidung für ein Produkt sollte es in einem mittleren Testprojekt getestet werden, das vollständig durchgeführt wird. Viele Hersteller bieten zwar eine Testinstallation für ein bis zwei Monate an, dies reicht aber nicht aus, um sich ein abschließendes Urteil über das Produkt bilden zu können. Wir haben eine sechsmonatige Testinstallation für fünf Arbeitsplätze vereinbart. Diese Testinstallation ist zwar nicht kostenfrei, während eines sechsmonatigen Testprojektes einschließlich Ausbildung der Mitarbeiter in Methoden und Werkzeug und einschließlich Hotline-Support des Herstellers werden die Stärken und Schwächen des Produktes und des Anbieters jedoch so weit sichtbar daß die endgültige Entscheidung als gesichert angesehen werden kann.

Nach der endgültigen Entscheidung empfiehlt sich eine inkrementelle Einführung: Zunächst wird ein Kern von zirka fünf bis zehn Mitarbeitern in Methode und Werkeugeinsatz geschult, und erste Projekte werden mit dem neuen Werkzeug durchgeführt. Da die Analyse und die fachlichen Anforderungen häufig von der Fachabteilung erarbeitet werden, empfiehlt es sich, daß auch die Projektmitarbeiter der Fachabteilung zumindest in der Vorgehensweise und in den Uppercase-Tools geschult werden. Die Bereitschaft seitens der Fachabteilung dazu ist häufig höher als von der Software-Entwicklung angenommen. Für die Folgeprojekte werden dann einer oder zwei "Könner" des Produktes in das neue Team aufgenommen, 8 die für die Durchführung und richtige Anwendung des Werkzeugs sorgen. Auf diese Weise wird der Einsatz der Werkzeuge spiralförmig ausgeweitet. Ein Mitarbeiter sollte als Ansprechpartner für das Werkzeug dienen .

Qualitätszuwachs vor Produktivitätsgewinn

Die Einführung einer Software-Produktionsumgebung sollte grundsätzlich unter dem Aspekt der Qualitätsverbesserung gesehen werden. Eine etwaige Produktivitätsverbesserung in der Software-Entwicklung steht erst an zweiter Stell. Die Einführung eine SPU bedeutet mehr, als nur ein CASE-Tool auszusuchen; zunächst sind die organisatorischen und technischen Rahmenbedingungen zu schaffen, zum Beispiel die Organisation das Verfahren zur Projektabwicklung und die Einführung von Software-Enwicklungsmethoden. Dies bedeutetet einen ich zu unterschätzenden Aufwand der aber als Investition in die Zukunft gut angelegt. Das gilt jedes rechnergestützte Werkzeug.

Die Auswahl eines CASE-Tools ist eine recht zeitaufwendige und im Detail schwierige Angelegenheit. Die CASE-Tool-Einführung verändert das Denken, die Arbeit und den Arbeitsplatz der Software-Entwickler. Die Kosten für die Einführung eines CASE-Tools sind erheblich:

Mit minimal zwei Wochen Ausbildung und zwei Wochen "Learning by doing" muß je Mitarbeiter gerechnet werden. Die Kosten für die software belaufen je nach CASE-Tool zwischen 10 000 und 30 000 Mark pro Software-Entwickler, dazu kommen noch Hardware-Anforderungen (PCs Server, Netze) die leicht noch einmal 10 000 bis 20 000 Mark für jedem Mitarbeiter betragen können, sofern diese Ausstattung nicht bereits zur Verfügung steht. Die jährliche Abschreibung dieser Investition jedoch ist im Vergleich zu den Personalkosten und als "Preis" für eine zu erwartende Qualitätsverbesserung eher gering.

Wilhelm Dangelmaier ist Professor für Wirtschaftsinformatik an der Universität-Gesamthochschule Paderborn und geschäftsführendes Vorstandsmitglied des Heinz-Nixdorf-Instituts "Interdisziplinäres Forschungszentrum für Informatik und Technik". **Karin Geck ist wissenschaftliche Mitarbeiterin im Fachbereich Wirtschaftswissenschaften.