"Das Experiment hat uns gezeigt, daß sich Produktivität und Qualität durch eine konsequente Wiederverwendung signifikant steigern lassen", faßt Elisabeth Kauba, Projektleiterin der Siemens AG Österreich Programm- und Systementwicklung (PSE), Wien, die Ergebnisse von "Re-Use" zusammen und fügt hinzu: "sofern die Voraussetzungen stimmen." In erster Linie gehört dazu ein Prozeß, bei dem die Wiederverwendung eine wesentliche Rolle spielt (siehe Abbildung unten). Das Re-Use-Team erweiterte hierfür die bestehende "System Entwicklungs Methode" (SEM) der PSE in diesem Sinne. Das Verfahrensmodell berücksichtigt nun die Erstellung erneut verwertbarer Software, das Bereitstellen wiederverwendbarer Komponenten, ihr Auffinden sowie Möglichkeiten ihrer Integration.

Drehscheibe für den Austausch von Software-Elementen zwischen Projektteams und über Abteilungsgrenzen hinweg ist eine Bibliothek. Sie speichert sowohl Inhalte, ganze Anwendungen, Anwendungsteile, Algorithmen und Routinen als auch Servicekomponenten, die anwendungsunabhängig Dienste zur Verfügung stellen können: GUI-Elemente, Patterns, Frameworks und Basisfunktionen. Grundlage der Bibliothek ist bislang die Microsoft-Datenbank "Access", die beim Übergang vom Re-Use-Projekt- in den Anwendungsstatus durch ein anderes relationales Datenbanksystem abgelöst werden soll.

Die Einlagerung von wiederverwendbarer Software regelt ein Klassifikationsschema. Es beinhaltet Kategorien zur Beurteilung des Entwicklungsstands wie "noch im Test", "abgenommen" oder beim "Kunden im Einsatz" - sowie der Vollständigkeit von Dokumentationen. Zudem wird erfaßt, nach welcher Methode entwickelt wurde, und ob Bausteine sicherheitskritisch sind. Eigentlich sollte die Bibliothek nur gut getestete, tatsächlich einsatzfertige Bausteine enthalten. Die hohen Anforderungen waren kontraproduktiv. Die Entwickler trauten sich laut Kauba zunächst nicht, ihre Software anzubieten.

Nun ist die Bibliothek zweigeteilt. Sie enthält geprüfte Module und für die Wiederverwendung bereitgestellte Komponenten, die noch überprüft und komplettiert werden müssen. So stehen Arbeitsergebnisse recht früh im Entwicklungsprozeß zur Verfügung.

Das PSE-Experiment begann Anfang 1996, war in drei Phasen gegliedert und endete noch vor dem Jahreswechsel. In diesem Jahr soll Wiederverwendung unternehmensweit eingeführt werden. Organisatorische Zentralstelle ist die Re-Use-Task-Force. Eine ihrer vornehmlichen Aufgaben war und ist es, eine breite Akzeptanz für Wiederverwendung zu schaffen. Sie besteht aus vier PSE-Mitarbeitern, die mindestens zehn Jahre im Software-Engineering tätig sind. Ein Mitarbeiter brachte Erfahrungen aus dem Reverse- und Re-Engineering ein, einer ist Spezialist für Metriken, der Schwerpunkt des dritten Teammitglieds ist die Vorgehensmodellierung, und der vierte im Bund ist zuständig für Mitarbeiterschulungen und -motivation.

Zur Vorbereitung des Experiments schuf das Team zunächst die technischen Voraussetzungen für eine Wiederverwendung. Außerdem mußten Richtlinien her, die festlegen, was alles Re-Use-fähig ist, aber auch das Software-Design, die -Entwicklung und die -Dokumentation regeln. Darüber hinaus waren Tools auszuwählen, vor allem für eine visuelle Beschreibung der Assets, wie Kauba die als wiederverwendbar eingestuften Programmteile nennt.

Das PSE-Team ist nach einer Vorauswahl nun bei drei Werkzeugen geblieben: "Easy Case" von Siemens, ein Case-Tool, "QA", eine Produktfamilie der Programming Research Ltd., mit der sich hauptsächlich statische C- und C++-Codeanalysen vornehmen lassen, sowie "Objec- tive", ein objektorientiertes CASE-Tool, das unter anderem Klassenmodelle grafisch darstellen und über den bestehenden Quellcode Metriken liefern kann.

Metriken ermöglichen, Programme nach quantitativen Merkmalen zu überprüfen. Für solche Raster zu sorgen, war ebenfalls Aufgabe der Task-Force. Außerdem mußte die Gruppe Ausschau nach wiederverwendbaren Teilen in bestehenden Applikationen halten. Seither befinden sich auch Cobol-Programme, Dokumente, Pläne, Testfälle und Spezifikationen in der Re-Use-Bibliothek.

Für das Experiment wählte das PSE-Team zwei Pilotprojekte aus, für die es bereits Assets aus ähnlich gelagerten Entwicklungen gab. Beim ersten handelte es sich um eine Call-Center-Applikation, die von drei Projektteilnehmern traditionell in C entwickelt wurde. Das andere Team zählte acht oder neun Mitglieder. Sie erstellten ein Planungs-Tool für Vernetzungssysteme mit Hilfe objektorientierter Techniken in C++. Zum ersten Mal in der Geschichte der PSE gab es jeweils einen "Re-Use-Manager" im Projektteam, der die Schnittstelle zur Task-Force bildete.

Die größten praktischen Hindernisse bei der Durchführung bildeten gruppendynamische Probleme (siehe Kasten: "Potentielle Hindernisse"). Neben Widerständen, die jede Veränderung in einem Unternehmen begleiten, kann die Wiederverwendung Existenzängste unter den Entwicklern wecken. Mitarbeiter befürchten, wegrationalisiert zu werden, haben Angst um ihren Arbeitsplatz. "Da hilft es auch nicht, wenn sich die Task-Force als Wanderprediger betätigt", beteuert Kauba. Hier sei eindeutig das Management gefragt, das beispielsweise die Weiterbeschäftigung zusichere.

Gravierend wirkt sich zudem das "Not-invented-here-Syndrom" aus. Entwickler zeigen deutliche Ressentiments gegen Software, die sie nicht selbst entwickelt haben. Sie befürchten schlechtere Qualität und fühlen sich in ihrem kreativen Selbstverständnis getroffen.

Wie Projektleiterin Kauba ausführt, habe in diesem Stadium des Experiments insbesondere der Einsatz des QA-Tools geholfen. Das Werkzeug habe gleichsam als "objektiver Kritiker" fungiert, der Vorbehalte bezüglich der Softwarequalität beseitigen konnte. Außerdem sei mit Hilfe der Tools evident geworden, wie Verfahren, Werkzeuge und Assets die tägliche Arbeit der Entwickler erleichtern können.

Auf der organisatorischen Ebene mußte jemand gefunden werden, der genug Elan, Kompetenz und Befugnisse hatte, um das Projekt aus der Taufe zu heben, es in Gang zu bringen und vor allem es am Laufen zu halten. Es kristallisierte sich auch eine Mindestgröße für Projektmannschaften heraus. Während das größere Team ein Einsehen mit dem formalen Mehraufwand etwa durch Leitsätze und Dokumentation hatte, konnte sich die kleine Entwicklungsmannschaft damit nur schwer anfreunden. Für sie blieb die persönliche Information die adäquate Kommunikationsform.

Obwohl noch nicht alle Probleme gelöst werden konnten, bevor die Wiederverwendung flächendeckend eingeführt wird, hat die Revision gezeigt, daß sich Wiederverwendung lohnt (siehe Abbildung 1, Seite 13). Dafür muß sie Teil des "normalen" Projektgeschäfts und laut Kauba in eine Infrastruktur eingebunden sein, die einen unkomplizierten Zugriff auf die Assets erlaubt.

Potentielle Hindernisse

ökonomisch- fehlendes Commitment - unklare Geschäftsstrategie - Investitionshöhe - Aufwandsgeschäft - fehlende Nutzungs- und Verwertungsrechte

soziologisch

- Not-invented-here-Syndrom - Widerstand gegen Verände- rungen - Existenzängste: "Re-Use ist ein Job-Killer" - Selbstverständnis des Entwicklers/geändertes Rollenbild

organisatorisch

- im Prozeß nicht vorgesehen - Verantwortung nicht zugewiesen - fehlender Katalysator - fehlende Infrastruktur

technisch

- fehlende Erfahrung mit praktischen Anwendungen - mangelndes Know-how-Schwächen im Software-Engineering-Prozeß - fehlende Tools