Informatik Forsch. Entw. (1995) 10: 197±213 

Springer-Verlag 1995

Ein Modell zur stufenweisen Umsetzung von SoftwareWiederverwendung in der Praxis Mit Feedback aus strategischen Projekten im Bank- und Versicherungsbereich als Denkanstoû fuÈr EntscheidungstraÈger groûer Eigenentwickler Stefan Biffl*, Gerald Futschek, Christian Brem

Institut fuÈr Softwaretechnik, Technische UniversitaÈt Wien, Resselgasse 3/188, A-1040 Wien Eingereicht am 17.September 1994/Angenommen am 8.Mai 1995

Die Wiederverwendung bereits existierender Software verspricht sowohl hoÈhere ProduktivitaÈt als auch bessere Wartbarkeit und ProduktqualitaÈt. In der industriellen und wirtschaftlichen Praxis anzutreffende Software ist allerdings schon innerhalb eines Unternehmens sehr heterogen. Sie variiert stark in Alter, Anwendungsgebiet, Dokumentationsgrad, verwendeter Entwicklungsumgebung und ist durch Programmierer mit unterschiedlichem Ausbildungsstand im Software-Engineering entstanden. FuÈr die EinfuÈhrung von Software-Wiederverwendung (Reuse) in der Praxis schlagen wir drei Entwicklungsstufen vor, die durch schrittweise steigende Investitionen von der Basis grundsaÈtzlicher Wartbarkeit bis zu einer unternehmensweiten Reuse-Kultur fuÈhren. Das Modell baut auf VorschlaÈgen der Reuse-Forschung und unseren Erfahrungen mit zwei Beratungsprojekten aus der Praxis industrieller Software-Entwicklung im Bank- und Versicherungsbereich mit RuÈcksicht auf lokale Zeit- und KostenbeschraÈnkungen auf. Die fuÈr den Einsatz von Software-Wiederverwendung notwendigen Rollen der beteiligten Mitarbeiter und begleitende organisatorische Maûnahmen werden erklaÈrt. Die erfolgreiche institutionalisierte EinfuÈhrung von Wiederverwendung bedingt eine Anpassung der Unternehmenskultur, deren Verlauf sich mehr am Potential der vorhandenen Mitarbeiter orientieren muû als am Einsatz der neuesten Ideen von Methoden- oder Werkzeuganbietern. SchluÈsselwoÈrter: Software-Wiederverwendung, Wartbarkeit, Standards, QualitaÈtssicherung, Managementaspekte, EinfuÈhrung von Wiederverwendung Abstract. Reuse of existing software can significantly increase productivity and provide higher maintainability as well as higher product quality. Existing software systems in industrial practice are usually very heterogeneous ± even within the same company. The software varies in age, problem domain, level of documentation, Zusammenfassung.

* E-Mail: [email protected]

used development environments as well as in levels of software engineering consciousness and skills among the involved software developers and maintainers. We describe a model for reuse that provides three levels of reuse intensities/investments designed to lead from basic maintainability to a company-wide reuse culture. The model is based on suggestions in state-of-the-art reuse research and our experiences in two consulting projects with in-house-developers in the banking and insurance industry to meet local constraints of time and costs. Important roles of personnel and accompanying organizational measures are explained. Successful introduction of institutionalized reuse needs a shaping of the corporate culture, which must be oriented towards enhancing the potential of employees rather than toward trying out the hottest ideas of method-consultants or tool-vendors. Key words: software reuse, maintainability, standards, quality assurance, management issues, introduction of reuse CR Subject Classification: D.2.7, D.2.9, D.2.m 1. Einleitung

Die Idee der Wiederverwendung bereits entwickelter1 Software-Komponenten in neuen Projekten (Reuse ) ist beinahe so alt wie das Programmieren in hoÈheren Sprachen. Software-Wiederverwendung gewann in den letzten Jahren durch die stark steigenden Software-Lebenszykluskosten an Bedeutung. Die hohen Kosten entstehen durch uÈberhoÈhte Wartungskosten infolge unzureichender ProduktqualitaÈt. Die notwendige Bindung personeller und finanzieller Mittel an die Wartung erhaÈlt technisch unflexible Software-Altlasten am Leben 1 In dieser Arbeit werden die Begriffe Reuse und Wiederverwen-

dung von Software synonym verwendet.

198

und behindert dadurch die Neuentwicklung der vom Markt geforderten qualitativ hochwertigen und immer komplexer werdenden vitalen Applikationen. Wiederverwendung ist ein Ansatz, um der zunehmenden Bremsung der Neuentwicklung entgegenzuwirken und durch den Einsatz bereits existierender, qualitativ hochwertiger Komponenten die Gesamtkosten des Software-Lebenszyklus zusaÈtzlich zu mindern. Allerdings sind vor dem breiten Einsatz von Wiederverwendung strategische Vorkehrungen zu treffen. Es ist zwar sehr leicht moÈglich, vorhandene Softwareteile in neuen Projekten zu verwenden, aber alleine dadurch eine ErhoÈhung der QualitaÈt neuer Produkte zu erreichen, ist kaum zu erwarten, da diese stark von der QualitaÈt der waÈhrend der Entwicklung der verwendeten Komponenten erstellten Dokumente abhaÈngt. In einem Unternehmensbereich kann erst dann an die EinfuÈhrung einer Umgebung zur Software-Wiederverwendung gedacht werden, wenn dort bereits ein Software-Engineering-Prozeû existiert, der die Produktion qualitativ hochwertiger Produkte ermoÈglicht. Software-Wiederverwendung ist als eine Erweiterung eines solchen Software-Engineering-Prozesses kein rein technischer Ansatz; Werkzeuge und Methoden muÈssen die Software-Wiederverwendung unterstuÈtzen, fuÈhren aber niemals von sich aus zu einer entsprechenden Entwicklungskultur. Vielmehr ist die Umsetzung eines Modells zur Software-Wiederverwendung neben den technisch-methodischen, kognitiven, sozialen, rechtlichen und oÈkonomischen Aspekten primaÈr ein organisatorisches und kulturelles Problem [10, 23, 28]. Deshalb existiert kein einfaches Patentrezept fuÈr den Einsatz der Software-Wiederverwendung. Im Rahmen von zwei Beratungsprojekten im Bankund Versicherungsbereich konnten wir feststellen, daû ein Scheitern von Software-Wiederverwendung meist auf das organisatorische Umfeld zuruÈckzufuÈhren ist [5, 12]. Im zweiten Kapitel werden anhand von Fallbeispielen technische und organisatorische Spezifika von Unternehmen diskutiert, die bei einer EinfuÈhrung von Reuse zu beachten sind. Das dritte Kapitel beschreibt unseren Ansatz zur EinfuÈhrung der Software-Wiederverwendung in Form eines Modells mit drei IntensitaÈtsbzw. Investitionsstufen. Die Basisstufe I repraÈsentiert Software-Wiederverwendung innerhalb eines einzelnen Projektes und wird deshalb Wartbarkeit genannt. Das Erreichen dieser Stufe ist Voraussetzung fuÈr die weiteren Stufen. Stufe II baut Wiederverwendung innerhalb einer Gruppe aÈhnlicher Projekte auf. Sie ist durch die Existenz abstrakter Dokumente in allen Entwicklungsphasen fuÈr eine bestimmte AnwendungsdomaÈne charakterisiert, wobei die inhaltlichen von den technischen Belangen sauber getrennt sind und die Dokumente top-down vom Generellen zum Speziellen ausbalanciert abgestimmt sind. Diese Stufe wird in Anlehnung daran Ausgewogenheit genannt. Stufe III, Standardisierung, beschreibt eine unternehmensweite Organisationsstruktur zur Sammlung, Aufbereitung und Verteilung von Dokumenten in jeder Entwicklungsphase. Basis dieser Stufe sind das namengebende standardisierte Vorgehen bei der Wiederverwendung, das erst wirk-

same QualitaÈtssicherung und breitere Verwendbarkeit ermoÈglicht, und eine klar definierte Rollenverteilung mit SchluÈsselpositionen. Diese Positionen werden mit besonders kompetenten Mitarbeitern besetzt, die gemeinsam die interne Kommunikation vereinfachen und damit intensivieren. Das vierte Kapitel gibt einen kurzen UÈberblick uÈber verschiedene reuse-unterstuÈtzende Konzepte, Methoden und Werkzeuge aus der Literatur, die von Praktikern aus den genannten Projekten auf ihr Anwendungspotential im eigenen Umfeld eingeschaÈtzt wurden. Moderne Reuse-Methoden brauchen zum Erfolg i.a. Personen mit Spezialqualifikationen (wie sie deren Erfinder haben), die einen breiten Einsatz im ¹Tieflandª industrieller Entwicklung wirksam verhindern. Ein industriell erfolgversprechendes Reuse-Programm muû die vorhandenen Qualifikationen nutzen und in kleinen Schritten inkrementell weiterentwickeln. Wenn Spezialisten mit den Voraussetzungen fuÈr moderne Reuse-Methoden vorhanden sind, ist es sinnvoll diese mittels VernetzungundelektronischerKommunikationgleichzeitig fuÈr strategisch wichtige Ziele zu konzentrieren und als BeraterfuÈrmehrereProjektebreitverfuÈgbarzumachen. È berlegungen vor dem Start 2. Strategisch-praktische U eines Reuse-Projekts

In diesem Abschnitt werden die technischen und organisatorischen Spezifika von Unternehmen betrachtet, die sich auf die Konzeption bzw. Umsetzung eines Organisationsmodells zur UnterstuÈtzung der Software-Wiederverwendung (Reuse-Modell) auswirken. Wir gehen dabei von Unternehmen aus, die Software in mehreren, eventuell miteinander in2 Beziehung stehenden Sparten (AnwendungsdomaÈnen ) entwickeln und in jeder Sparte im Vergleich zur Lebensdauer der dort verwendeten Produkte laufend neue Projekte absetzen. Unsere konkreten Erfahrungen stammen aus der Beobachtung der Entwicklungs- und Wartungslandschaft einiger Banken und einer Versicherung, die in wechselnden ProjektzusammenhaÈngen jeweils groûe Eigenentwicklungsmannschaften im Haus (in der GroÈûenordnung von 80 bis 400 Personen) betreiben. Das in dieser Arbeit vorgestellte Stufenmodell wurde im Rahmen eines strategischen Projektes in einer Bank entwickelt. Ziel dieses Projektes war eine Bewertung moderner AnsaÈtze zur Software-Herstellung. Das dort vorgefundene Projektportfolio deckt sich groûteils mit den Landschaften der anderen Banken (groûe Bereiche Giro, Spar, Kredit, Wertpapiere, Ausland, etc.). Auch bei der Versicherung findet die Software-Entwicklung spartenorientiert statt, und es konnten hier erstaunliche AÈhnlichkeiten mit Bankapplikationen vorgefunden werden (etwa Teile der Bereiche Lebensversicherung und Wertpapiere). Die Beobachtungen zur schrittweisen EinfuÈhrung von Reuse stammen aus der auftraggebenden Bank, 2 In dieser Arbeit werden die Begriffe Sparte, Unternehmensbe-

reich und AnwendungsdomaÈne synonym verwendet.

mit drei Projekten auf Stufe I und zwei Projekten auf Stufe II. Mit dem Aufbau eines qualifizierten Mitarbeiterstabs und der Reuse-Datenbanken im Haus wurde begonnen. Bei der Versicherung konnten nach Vorstellung des Stufenmodells probehalber zwei Projekte auf Stufe I untersucht und die Analyse einer Sparte als Kandidat fuÈr Stufe II begonnen werden (siehe Kapitel 3). Wesentliche Motivationsfaktoren fuÈr das Management beider Betriebe waren eine externe objektive Untersuchung der lebensnotwendigen ¹Altlastenª auf die gegenwaÈrtige korrektive und adaptive Wartbarkeit, eine grobe EinschaÈtzung der vorhandenen Software-Landschaft auf extreme qualitative Schwankungen und VorschlaÈge zur Verbesserung der Reaktionsgeschwindigkeit auf Marktanforderungen. 2.1. Technische Firmenspezifika

Die technischen Spezifika, die bei der Konzeption eines Reuse-Modells zu beruÈcksichtigen sind, koÈnnen grob in folgende Kategorien unterteilt werden: • Status der derzeit existierenden Software-Systeme in Produktion und Wartung • Status der gegenwaÈrtigen Entwicklungsmethoden • Status des gegenwaÈrtigen Entwicklungsablaufs • Spezifika der derzeit zur Entwicklung verwendeten Hard- und Software Offensichtlich stellen die vorhandenen Software-Systeme die Basis fuÈr weitergehende Untersuchungen zur EinfuÈhrung von Software-Wiederverwendung dar; sie bilden den Grundstock, aus dem wiederverwendbare Komponenten rekrutiert werden. Die folgenden Aspekte sind bei einer Bewertung dieser Systeme besonders zu beachten: • Volumen der existierenden Software-Systeme • QualitaÈt der existierenden Software-Systeme FuÈr den Start eines glaubwuÈrdigen Wiederverwendungsprogramms ist eine gewisse Mindestanzahl von vorhandenen Programmen erforderlich, aus denen eine ¹kritische Masseª von wiederverwendbaren Komponenten als Grundbestand einer Reuse-Datenbank, unabhaÈngig von der Art und Weise ihrer Implementierung, extrahiert werden kann [6, 13, 14]. Das notwendige Volumen dieser ¹kritischen Masseª ist abhaÈngig von der GroÈûe der firmeninternen Software-Entwicklung und dem geplanten Einsatzbereich des Programms (projektbezogen, spartenbezogen oder firmenweit). Wesentlich fuÈr eine Anfangsakzeptanz ist besonders der subjektive Eindruck der Entwickler, daû wiederverwendbare Komponenten ¹natuÈrlichª im Lauf ihrer Arbeit entstehen koÈnnen, da eine fast leere Reuse-Datenbank weder den Entwickler noch das Management vom Erfolg der Software-Wiederverwendung im Unternehmen und der Sinnhaftigkeit zusaÈtzlicher AnfangsaufwaÈnde uÈberzeugen kann. Ziel der Wiederverwendung ist eine personenunabhaÈngige Verwendung des Inhalts der Reuse-Datenbank;

Status der derzeit existierenden Software-Systeme in Produktion und Wartung.

199

an die QualitaÈt der vorhandenen Kandidatenkomponenten muÈssen daher besonders hohe AnspruÈche in bezug auf die Codierungs- und auch DokumentationsqualitaÈt gestellt werden. SelbstverstaÈndlich waÈre eine hohe QualitaÈt von Komponenten in allen Bereichen wuÈnschenswert. In der Praxis ist man jedoch von diesem Ziel sehr weit entfernt. In der Wartung eines bestimmten Software-Systems koÈnnen SchwaÈchen durch den Einsatz speziell ans System gebundener qualifizierter Einzelpersonen lokal kompensiert werden. Diese teure und unflexible Vorgehensweise wird durch minderwertige Systemteile notwendig; eine Verbreitung dieser Teile steht dem Sinn der Wiederverwendung diametral entgegen. Wesentliche Kritikpunkte, die eine unmodifizierte UÈbernahme in eine Reuse-Datenbank behindern, sind: È berdimensionierte • U durchschnittliche ModulgroÈûe • Grobe MaÈngel im Codierungsstil • Fehlende spartenuÈbergreifende Datenmodelle bzw. nicht ausgenutzte gemeinsame Datenmodelle • Teilweise MaÈngel in der funktionalen und strukturellen Dokumentation • Fehlende globale Applikationsdokumentation DieseMaÈngelfuÈhrenzueinemhohenWartungsaufwand unddamitzumAnsteigenderEntwicklungskosten.Eine sehr hohe Codierungs- und DokumenationsqualitaÈt ist daher zwar unabhaÈngig von der Software-Wiederverwendung wuÈnschenswert, aber in der RealitaÈt leider kaum gegeben. Bei der Konzeption eines Reuse-Modells steht folglich die Notwendigkeit im Vordergrund, als ersten Schritt die Wartbarkeit der Applikationen herzustellen bzw. zu verbessern. Unter demÈ Begriff Herstellen der Wartbarkeit wird dabei der Ubergang von chaotisch-genialenWartungsablaÈufen,diebestenfallseinem ¹Quick-Fixª Wartungsmodell entsprechen, zu einem geordneten, in derweiteren FolgeauchfuÈr die Wiederverwendung geeigneten Wartungsmodell verstanden (siehe Kapitel 3.1). Sollten Modifikationen an einem Produkt oÈkonomisch nicht mehr sinnvoll sein, da der Aufwand im Vergleich zur geschaÈtzten weiteren Einsatzdauer nicht tragbar erscheint, empfiehlt sich die Neuentwicklung einer wartbaren Version. Bei den untersuchten Software-Paketen zeigte sich vor allem in den Bereichen des KerngeschaÈfts der Banken die problematische Situation, daû gerade in den vitalsten Bereichen uralte unwartbare Assembler-Programme die aktuellen Anforderungen mit einiger Pflege durch Eingeweihte klaglos erfuÈllen. Gleichzeitig wird aber die EinfuÈhrung innovativer Bankprodukte wirksam verzoÈgert und oft verhindert, da die Modifikation dieser Software personell zu aufwendig ist. Rund um diesen neu zu schreibenden Kern gibt es eine Reihe neuerer Host-Funktionen, die in den letzten zehn Jahren mit konservativer Technologie implementiert wurden und eine gute Basis fuÈr etwaige RenovierungsansaÈtze sind, da diese Software laut Plan noch etwa 5 bis 10 Jahre in Betrieb gehalten werden soll. Das Fehlen einer global definierten und auch konsequent Status der gegenwa È rtigen Entwicklungsmethoden.

200

umgesetzten Entwicklungsmethodik innerhalb des Unternehmens fuÈhrt einerseits zu qualitativen Streuungen zwischen den einzelnen Sparten und andererseits dazu, daû groÈûtenteils keine wie auch immer geartete Form der Projekt- und Wissensdokumentation existiert. Diese ist jedoch eine notwendige Voraussetzung zur Umsetzung eines Wiederverwendungsprogramms. Es besteht daher bei der Konzeption eines Reuse-Modells primaÈr die Notwendigkeit, eine globale abstrakte Entwicklungsmethodik nach Gesichtspunkten des modernen Software-Engineering zu definieren und ihre nachfolgende Umsetzung durch organisatorische Maûnahmen abzusichern. Der Abstraktionsgrad der Entwicklungsmethodik ist so zu waÈhlen, daû einerseits moÈglichst viele Aspekte der Software-Entwicklung abgedeckt werden, die Methodik aber andererseits durch Spezialisierung bei moÈglichst vielen Projekten anwendbar ist. Als Beobachtung ist hier eine besondere ZuruÈckhaltung vieler Entwickler bzw. ihrer Vorgesetzten in bezug auf die Schulung moderner Softwaretechnik-Methoden zu vermerken. StaÈrkste Auswirkung ist eine auf ein Werkzeug hin orientierte Ausbildung, die zu entsprechend speziellen und eingeschraÈnkten LoÈsungsansaÈtzen fuÈhrt. Dies geht in EinzelfaÈllen so weit, daû etwa die Verwendung von Parametern anstelle globaler Variabler auch bei Verwendung einer modernen Programmiersprache nicht Teil des persoÈnlichen mentalen Konzepts ist ± mit allen Auswirkungen auf die so produzierten Programme. In einer der Banken wurden etwa 100 ArbeitsplaÈtze mit kapitalintensiven CASE-Umgebungen ausgestattet, ohne im weiteren eine begleitende Schulung der Mitarbeiter vorzusehen. Von diesen Umgebungen werden nur die Zeichen- und Textverwaltungsfunktionen wirklich verwendet, die dahinterliegende maÈchtige FunktionalitaÈt wird mangels Know-How nicht genutzt. Dieser Punkt hat fuÈr die Konzeption eines Reuse-Modells eine geringere Bedeutung, da bei der EinfuÈhrung eines solchen Modells klarerweise primaÈr die vorhandenen AblaÈufe neu organisiert bzw. umstrukturiert werden muÈssen. Ein unternehmensspezifischer Vorteil waÈre, wenn die verschiedenen EntwicklungsablaÈufe nicht an unterschiedliche organisatorische Einheiten, d.h. Abteilungen, gebunden sind. Eine Umstrukturierung im Rahmen einer EinfuÈhrung von Reuse ist dann leichter und mit geringerem Aufwand durchfuÈhrbar. Ein wesentlicher Schwachpunkt ist oft die fehlende Ausstattung der QualitaÈtssicherungsgruppe mit exekutiven Vollmachten. Die Umsetzung eigentlich vorgeschriebener QualitaÈtskriterien ist daher einerseits vom Kooperationswillen der beteiligten Entwickler abhaÈngig, andererseits spielen hier auch externe Faktoren (durch Entwicklungsvorgaben bedingter Termin- bzw. Kostendruck etc.) eine wesentliche Rolle. In der beobachteten Versicherung wurde Ende der 80er Jahre eine QualitaÈtssicherungsabteilung zur Hebung der produzierten QualitaÈt in Entwicklungsprojekten geschaffen. Da diese Abteilung nur den Status eines Beobachters ohne projektsteuernde Kompetenz hatte, Status des gegenwa È rtigen Entwicklungsablaufs.

gab es gerade bei den kritischen Projekten keine ErhoÈhung der QualitaÈt, da bei allen Konflikten zwischen der Einhaltung von Lieferterminen und der Schaffung einer MindestqualitaÈt, der Projekttermin Vorrang vor etwaigen EinwaÈnden der QualitaÈtssicherung erhielt. Dieser Punkt ist normalerweise sehr kritisch, da vor allem eine unzulaÈngliche Ausstattung der Entwicklungsabteilungen im Hardwarebereich groûen Investitionsbedarf nach sich zieht. Im SoftwareBereich ist die Wahl von entwicklungsunterstuÈtzenden Werkzeugen, die auch nach der EinfuÈhrung eines Reuse-Programms eingesetzt bzw. zur Umsetzung eines solchenProgramms herangezogen werden koÈnnen, relevant, sowie die derzeit zur Entwicklung verwendete(n) Programmiersprache(n) und deren Eignung Reuse zu unterstuÈtzen. Bei den verwendeten Programmiersprachen ist die HeterogenitaÈt der Sprachen sowie der Zielrechner der Applikationen (Host, PC) sicherlich ein gewisses Hindernis bei der Wiederverwendung bereits existierender Software, dasselbe gilt fuÈr die verwendeten Dokumentations- bzw. CASE-Werkzeuge. Spezifika

der

derzeit

zur

Entwicklung

verwendeten

Hard- und Software.

2.2. Organisatorische Spezifika

Als wesentlichste organisatorische Spezifika betrachten wir den Aufbau der Entwicklungsabteilungen sowie ein starkes und personell kontinuierliches Management. In vielen Unternehmen besteht keine personelle Trennung zwischen Entwicklung und Wartung. Den jeweiligen Abteilungen ist eine AnwendungsdomaÈne zugeteilt, fuÈr deren kontinuierliche Weiterentwicklung und Wartung sie verantwortlich ist. Dies hat den offensichtlichen Vorteil, daû die Abteilungen bzw. die Entwickler mit der jeweiligen Applikation bestens vertraut sind. Weiterentwicklungen sind also quasi Entwicklungen fuÈr den Eigengebrauch und notwendige WartungstaÈtigkeiten koÈnnen durch die Kenntnis der Applikation rasch durchgefuÈhrt werden. Dieses Faktum steigert die ProduktivitaÈt der Wartung. Ein negativer Aspekt dieser Organisationsform in Blickrichtung Wiederverwendung ist jedoch, daû dadurch weitgehend keine Dokumentation der Anwendungsprogramme auf einer hoÈheren Abstraktionsebene (Requirements, Design) existiert. Die fehlende Dokumentation wird dabei durch einen besonders intensiven informellen Informationsfluû zwischen den Entwicklern ersetzt. Dieser informelle Informationsaustausch kann nur innerhalb kleiner organisatorischer Einheiten zufriedenstellend funktionieren. SpartenuÈbergreifende Wiederverwendung setzt jedoch die Existenz solcher Dokumente voraus, da eine informelle, verbale Kommunikation zwischen organisatorisch getrennten Abteilungen ineffizient ist und somit jede Abteilung meist eine Informationssenke darstellt. Organisatorischer Aufbau der Entwicklungs- und Produktionsabteilungen.

In der Reuse-Literatur [24] herrscht Einigkeit daruÈber, daû zur EinfuÈhrung von Wiederverwendung die aktive UnterstuÈtzung des Management Bedingung ist. Dem ist hinzuzufuÈgen, daû offene oder verdeckte ¹Verhindererª auf allen Ebenen mehr oder weniger wirksam sein koÈnnen, breite UÈberzeugungsarbeit also wesentlich ist, und weiters bei der Umsetzung jeden Vorhabens abzuschaÈtzen ist, ob die Person, mit der gerade verhandelt wird, auch bis zum Ende der Umsetzung in dieser Position bleiben wird bzw. welche Einstellung potentielle Nachfolger haben. In der Versicherung war in den beobachteten Teilbereichen der politische Wille zur mittelfristigen Umsetzung des vorgeschlagenen Reuse-Programms vorhanden; im Zug einer Fusion mit einem anderen Betrieb war Wiederverwendung kein Thema mit hoher PrioritaÈt mehr, da die Managementstrukturen verschmolzen und insgesamt verkleinert werden sollten, was fuÈr die meisten Manager einen Kampf um den eigenen Posten bedeutete. Konsens und Kontinuita È t in der Organisation.

3. Ein Stufenmodell zur EinfuÈhrung von SoftwareWiederverwendung

Wie im vorangehenden Abschnitt beschrieben, muÈssen bei der Konzeption eines Reuse-Modells bzw. einer dafuÈr geeigneten Entwicklungsumgebung zwei hauptsaÈchliche firmen- bzw. projektspezifische Bereiche beruÈcksichtigt werden. Zum einen sind dies die gegebenen technischen Spezifika, die im wesentlichen durch die HeterogenitaÈt in bezug auf Alter und Anwendungsbereich der existierenden Applikationen sowie in bezug auf die derzeit benutzten Entwicklungsumgebungen und -methoden bestimmt sind. Zum anderen sind das die strategischen Spezifika, die im wesentlichen durch die neu geplanten Entwicklungen bestimmt sind. Um diese diametralen Anforderungen innerhalb eines Modells zu vereinen, stellen wir im folgenden ein Reuse-Modell vor, das drei QualitaÈts- bzw. Reife- und Investitionsstufen der Software-Wiederverwendung umfaût. Die unterste QualitaÈtsebene der Software-Wiederverwendung ist die Wartbarkeit einer Applikation bzw. eines Projekts; man kann den Wartungsprozeû auch als Wiederverwendung innerhalb eines einzelnen Projekts bezeichnen. Die Umsetzung der Stufe I, Herstellen der Wartbarkeit, ist Voraussetzung fuÈr die naÈchsthoÈhere QualitaÈtsstufe, die Ausgewogenheit. Auf dieser Ebene wird die Existenz klar strukturierter Dokumente fuÈr alle Phasen der Entwicklung von der Anforderungsanalyse bis hin zu Testdokumenten innerhalb einer bestimmten AnwendungsdomaÈne vorausgesetzt. Das Erreichen dieser QualitaÈtsstufe erlaubt domaÈnenbzw. spartenspezifische Wiederverwendung. Die hoÈchste Stufe, die Stufe der Standardisierung, Strukturinvestition und Reorganisation, setzt wiederum die beiden tieferen Schichten mit einem geordneten Entwicklungsprozeû und funktionierender QualitaÈtssicherung voraus. Auf dieser Ebene wird spartenuÈbergreifende Wiederverwendung moÈglich. Die Namensgebung beruht

201

auf der unsererAnsicht nachnotwendigenStandardisierung aller Methoden im Entwicklungsablauf sowie der dabei entstehenden Dokumente. Der wesentliche Vorteil dieses Stufenmodells ist, daû die Umsetzung der einzelnen Ebenen schrittweise erfolgen kann, die Implementierung einer einzelnen Stufe jedoch bereits zu einer QualitaÈts- und ProduktivitaÈtssteigerung in der Software-Entwicklung fuÈhrt. Ebenso ist es moÈglich, in verschiedenen Entwicklungsbereichen oder Projekten unterschiedliche Stufen einzufuÈhren. Firmenweite HomogenitaÈt in der Umsetzung ist also keine notwendige Voraussetzung. Wichtiger ist eine an die MoÈglichkeiten der einzelnen ProjekteÈ und Sparten angepaûte Vorgehensweise, die eine Uberforderung vermeidet und gleichzeitig das Bewuûtsein fuÈr den aktuellen Standort und die wuÈnschenswerte Zielrichtung vermittelt. Die VeraÈnderung einer lange gewachsenen lokalen Entwicklungsstrategie verlangt kleine uÈberschaubare Schritte und foÈrdert idealerweise mittelfristig das interne Heranwachsen der benoÈtigten Fachleute. In den folgenden drei Abschnitten werden die einzelnen IntensitaÈtsstufen der Wiederverwendung von Software-Dokumenten und ihre moÈgliche Umsetzung beschrieben. 3.1. Stufe I: Wartbarkeit ± Wiederverwendung innerhalb eines einzelnen Projekts

In beinahe allen groÈûeren datenverarbeitenden Betrieben, die seit der EinfuÈhrung von EDVauch Software fuÈr den Eigengebrauch entwickeln, hat sich im Laufe der Zeit ein umfangreicher Bestand an Anwendungsprogrammen angehaÈuft. Diese Anwendungen wurden oft fuÈr den Betrieb unter verschiedenen Betriebssystemen als auch fuÈr unterschiedliche Generationen der zugrundeliegenden Hardware entwickelt. Die SystemumgebungenaÈndertensichimLaufederZeit,ebensodiefunktionalen Anforderungen, die vom Benutzer an das Anwendungssystem gestellt werden. Das Ergebnis ist eine intensive adaptiveund perfektive WartungstaÈtigkeit. HaÈufige Wartung beeinfluût die QualitaÈt der Software, und zwar abhaÈngig von der urspruÈnglichen CodequalitaÈt sowie der QualitaÈt des eigentlichen Wartungsprozesses. So wird im Bankbereich etwa im Rahmen der adaptiven Wartung Software mit Hilfe von Emulationstechniken portiert, um die Programme auch in geaÈnderten Systemumgebungen(Hardware bzw. Betriebssystem) weiterverwenden zu koÈnnen. Dieses Vorgehen fuÈhrt zur Zementierung der engen Grenzen veralteter Technologie und setzt daruÈber hinaus in weiterer Folge genaue Kenntnisse einer nicht mehr existierenden (eben der emulierten) Hardware voraus, d.h. entweder eine genaue Dokumentation oder aber Wartungsprogrammierer, die mit dem urspruÈnglichen Programm vertraut sind. Die Wartung dieses Codes wird uÈblicherweise so weit personenabhaÈngig, daû diese Personen kurzfristig nicht mehr ersetzbar sind. Das ist nicht Software-Engineering, kann aber in der Praxis bei fast jeder Bank oder Versicherung beobachtet werden.

202

Ideale reuse-orientiere Wartung eines gut dokumentierten Anwendungssystems Abb. 1.

Stufe I: Typische Quick-Fix Wartung eines normal (links) und schlecht (rechts) dokumentierten Systems Abb. 2.

Eine qualitativ hochwertige WartungstaÈtigkeit im Rahmen des Software-Lebenszyklus ist notwendige Voraussetzung fuÈr die EinfuÈhrung eines Reuse-Modells. In diesem Abschnitt stellen wir ein Modell des Wartungsprozesses vor, das bereits die WartungstaÈtigkeit selbst als eine reuse-orientierte Form einer Programmodifikation betrachtet. Der Wartungsprozeû laÈût sich ebenso wie der normale Entwicklungsablauf in verschiedene Phasen unterteilen ± das vorhandene System und die notwendige AÈnderung werden analysiert, das Design wird analysiert und geaÈndert, der Code modifiziert, notwendige Tests durchgefuÈhrt und entsprechende Dokumente nachgefuÈhrt. Es ist offensichtlich, daû in diesem Prozeû die Nutzbarkeit bereits vorhandener Dokumente (Requirements, Design, etc.) Vorteile in bezug auf die QualitaÈt und ProduktivitaÈt der WartungstaÈtigkeit mit sich bringt. Je nach Grad der IntensitaÈt der Wiederverwendung von bereits vorhandenen Dokumenten lassen sich verschieden stark reuse-orientierte Wartungsmodelle unterscheiden. Abbildung 1 zeigt dabei den Idealfall einer reuse-orientierten WartungstaÈtigkeit. Eine notwendige Modifikation aufgrund geaÈnderter Anforderungen fuÈhrt unter Wiederverwendung aller Entwicklungsdokumente des alten Systems zu Modifikationen der Dokumente der nachgeordneten Phasen, die das neue System bilden. Im Sinne dieses Modells ist gute Software-Wiederverwendung innerhalb eines einzelnen Projekts gleichzusetzen mit guter Wartbarkeit des dabei entwickelten Systems. Dieses ideale reuse-orientierte Modell setzt allerdings ein im Sinne des Software-Engineering gut entwickeltes Anwendungssystem sowie die Existenz aller

den einzelnen Entwicklungsphasen zugehoÈrigen Dokumente voraus. Weiters muÈssen diese Dokumente in geeigneter Form verwaltet werden, d.h. zumindest die primitiv Ènotwendigen Funktionen wie etwa Suche, Zugriff und Anderung von Dokumenten sowie ein Versionsmanagement der verschiedenen generierten Systeme muÈssen unterstuÈtzt werden. Hier bietet sich der Einsatz einer geeigneten Reuse-Datenbank bzw. eines Repository an. DemgegenuÈber zeigt Abb.2 im linken Teil den Idealfall der in der industriellen Praxis uÈblicherweise durchgefuÈhrten Form des Wartungsprozesses. Die durch geaÈnderte Anforderungen notwendige ÈModifikation des Systems wird relativ rasch durch eine Anderung des Codes erreicht, deshalb die Bezeichnung Quick-Fix Wartung. Im Rahmen der Wartung von gut entwickelten Systemen, bei denen bereits alle Dokumente zur VerfuÈgung stehen (links), werden diese zur BewaÈltigung der eigentlichen Wartungsaufgabe benutzt und im nachhinein an die geaÈnderte Version angepaût. Das so entstandene neue System beinhaltet ebenfalls alle modifizierten Dokumente. Diesen Fall bezeichnen wir deshalb als Idealfall, da hier alle Entwicklungsdokumente zur VerfuÈgung stehen. Im Normalfall industrieller Praxis wird dies bei den meisten Anwendungssystemen jedoch nicht der Fall sein. Oft steht nur undokumentierter bzw. teilweise dokumentierter Code zur VerfuÈgung. Hier kann nun im Rahmen der Wartung ein iteratives, relativ zeit- und kosteneffizientes Reengineering durchgefuÈhrt werden, um die Entwicklungsdokumente im nachhinein zu erstellen. Jedesmal, wenn ein Wartungseingriff notwendig ist,

203

Stufe II: Anwendungsentwicklung unter Benutzung gut strukturierter und ausgeglichener Information uÈber Requirements-, Design-, Codeund Testdokumente aÈhnlicher Projekte Abb. 3.

wird dieser durch eine Modifikation des Codes durchgefuÈhrt. Anschlieûend kann das Wartungspersonal im Rahmen eines kurzen Reverse-Engineering-Prozesses das, durch die Wartung gewonnene, aktuelle Wissen uÈber das Programm dazu benutzen, Dokumente anderer Entwicklungsphasen zu generieren bzw. zu modifizieren. In einer Sparte einer Bank bleibt 10 Jahre alter undokumentierter und unstrukturierter PL/1-Code (etwa 2000 Batchprogramme) noch absehbar weiter in Produktion; ein totales Reengineering aller Programme ist nicht realistisch (selbst eine Dokumentation auf einfachstem Niveau wuÈrde geschaÈtzte 18 Personenmonate Aufwand erfordern), da die hierfuÈr notwendigen Wartungsprogrammierer nicht entbehrt werden koÈnnen; als Kompromiû werden haÈufig geaÈnderte Teile nachdokumentiert um schrittweise zu einem personenunabhaÈngigeren System zu gelangen. Zielgruppe fuÈr diesen Ansatz sind in der Organisation eher werkzeugorientiert arbeitende Personen wie Programmierer oder Gruppenleiter (siehe Abb.4). Diese Vorgangsweise fuÈhrt im Laufe der Zeit zu einem gewissermaûen immer ¹weniger schlechtª entwickelten Anwendungssystem, mit mehr oder weniger vollstaÈndigen Entwicklungsdokumenten, das auch gute Wartbarkeit im Sinne einer Reuse-Umgebung ermoÈglicht. Diese Stufe von Wiederverwendung, das Herstellen reuse-orientierter Wartbarkeit in den einzelnen Anwendungssystemen, sollte als minimale qualitative Anforderung fuÈr deren Aufnahme in ein Reuse-Vorhaben betrachtet werden. Sie ist auch fuÈr jene neuen Projekte sinnvoll und anwendbar, bei denen die hohen EinfuÈhrungskosten fuÈr ein umfassendes Reuse-Programm (noch) nicht gerechtfertigt scheinen. 3.2. Stufe II: Ausgewogenheit ± Wiederverwendung innerhalb a È hnlicher Projekte

Die Wartbarkeit eines Systems bedeutet in erster Linie, daû ein Anwendungssystem mit begrenztem und vorhersagbarem Ressourcenaufwand modifiziert werden kann. Jedoch ist auch ein im Sinne der Stufe I gut wart-

bares System nicht notwendigerweise fuÈr gravierende AÈnderungen der Systemanforderungen (Requirements) vorbereitet. Wiederverwendbarkeit in verschiedenen Systemen mit aÈhnlichen Anforderungen setzt die Existenz von inhaltlich generell gehaltenen, abstrahierten Entwicklungsdokumenten voraus. Dies fuÈhrt uns zur Definition der zweiten Reifestufe des Reuse-Modells, der Stufe der Ausgewogenheit. Auf Stufe I wird ein gut wartbares System unter anderem durch die Existenz von hoÈheren Entwicklungsdokumenten definiert, dabei enthaÈlt bzw. besteht jedes System aus einer Reihe von Komponenten, die jeweils sehr projektspezifisch oder eher generell gehalten sein koÈnnen. Die UnterstuÈtzung der Wiederverwendung fuÈr aÈhnliche Projekte erfordert tendenziell mehr generelle, also abstraktere Dokumente als die auf ein Projekt bezogene UnterstuÈtzung [15, 24]. Auf Stufe II des ReuseModells fordern wir daher nicht nur die Existenz aller hoÈheren Entwicklungsdokumente, sondern auch, daû die Entwicklungsdokumente eine klare top-down Struktur des Abstraktionsgrads vom Generellen zum Spezifischen hin haben. Wir bezeichnen eine Gruppe von Anwendungssystemen als ausgewogen, wenn diese Forderung von allen Dokumenten innerhalb dieser Gruppe erfuÈllt wird. Dies gilt fuÈr die Dokumente aller Entwicklungsphasen, also Requirements, Design, Code und Test (siehe Abb.3). Prinzipiell sehen wir mehrere moÈgliche Wege, diese Reifestufe von Wiederverwendung zu erreichen. Eine in der Praxis haÈufig eingesetzte MoÈglichkeit [14] ist, durch branchenspezifische Experten, meistens branchenerfahrene Entwickler, eine Menge von AktivitaÈts-, Dokument- und Modulschablonen (Templates) einer bestimmten DomaÈne zu entwickeln. Diese Schablonen fungieren dann im weiteren Entwicklungsprozeû als eine Art abstrakte Entwicklungssprache, deren Objekte die domaÈnenspezifischen Datenstrukturen und Algorithmen sind. Ausgewogenheit kann aber auch durch eine gute strukturierte Analyse oder durch qualifiziertes Redesign einer bereits bestehenden Anwendung erreicht werden. Eine notwendige Vorbedingung fuÈr die Stufe der Ausgewogenheit ist also in allen FaÈllen eine

204

sauber durchgefuÈhrte Analyse der zugrundeliegenden DomaÈne [22]. Idealerweise sollte die DomaÈnenanalyse in Verbindung mit dem Einsatz einer objektorientierten Entwicklungsumgebung geschehen, da hier aÈquivalente Analysephasen existieren. Jedoch kann eine solche Analyse auch nachtraÈglich im Rahmen einer konventionellen Entwicklungsumgebung durchgefuÈhrt werden. Der wesentliche Punkt zum Erreichen eines ausgewogenen Software-Systems ist unserer Ansicht nach die bestmoÈgliche Ausnutzung personeller Ressourcen und der Einsatz bereits bewaÈhrter Methoden zur Extraktion der gemeinsamen Architektur aus einer Menge von Applikationen, unter Einbeziehung aller zur VerfuÈgung stehenden Wissensquellen (Dokumente, Code, Entwickler etc.). Zu beachten ist dabei, daû auf dieser Stufe eine klare Trennung von inhaltlichen und technischen Aspekten erreicht werden muû. Die DomaÈnenanalyse der zugrundeliegenden Daten und Prozesse einer Sparte beschraÈnkt sich also auf die Beschreibung des DomaÈnenwissens. Rein technische Details (Implementierung, Programmiersprache, Hardware etc.) duÈrfen hier nicht involviert werden, sondern werden klar durch definierte Schnittstellen getrennt. Ein wesentliches Ergebnis der Analyse ist eine Art Handbuch mit abstrakter DomaÈnensprache, das sich auf Vorgehensweise, Daten, Funktionen und Datenbankstrukturen auf Abteilungsebene bezieht und als Vorgabe und Kommunikationsmittel fuÈr lokale DomaÈnenexperten zur geordneten Entwicklung neuer Systeme dieser DomaÈne dient. Zur Zeit werden in der Bank fuÈnf Projekte aus zwei Sparten (Giro und Spar) von einem Projektteam zur EinfuÈhrung von Wiederverwendung betreut. Es wurden mangels interner KapazitaÈten externe QualitaÈtssicherer und Berater zugekauft, die beim Betrieb von lokalen Prototypen der Reuse-Datenbanken und der internen Auswahl und Weiterbildung behilflich sind. Im Zuge der Arbeiten wurden Aspekte der Entwicklungskultur herausgefunden, die dem Management nicht bewuût gewesen sind: Durch spaÈrliche Kommunikation zwischen Projekten der gleichen Sparte kam es neben DoppellaÈufigkeiten, die zur mehrmaligen Entwicklung aÈhnlicher Komponenten und ganzer Applikationsstrukturen mit groûteils geringer QualitaÈt fuÈhrten, vor allem zur Monopolisierung besonders qualifizierter Experten, deren Existenz den anderen Teams nicht bekannt war. Infolgedessen wurde eine ErhoÈhung der Sichtbarkeit einzelner Projekte und damit auch deren Vergleichbarkeit und implizit auch das Bewuûtsein der Teams fuÈr das eigene Handeln im Spartenkontext als Ziel definiert. FuÈr die Wiederverwendung innerhalb von Sparten wurden jeweils Querschnittskomponenten gefunden und AnsaÈtze zu verschiedenen Variationen fuÈr eine gemeinsame Architektur zur Integration zweier existierender Projektstrukturen herausgearbeitet. Mit der Ausarbeitung eines Handbuchs zur Anleitung, wie eine Anwendung der Sparte in Zukunft anzugehen sei, wurde begonnen. Die groÈûte Schwierigkeit dabei stellte die Freistellung eines analytisch begabten Mitarbeiters mit

mehrjaÈhriger Erfahrung und UÈberblick uÈber den entsprechenden GeschaÈftsbereich fuÈr das Projekt dar. Nach diesen Anlaufschwierigkeiten stellte sich schon der Entwurf des Handbuchs als gute Grundlage zur Einschulung neuer Mitarbeiter dar. GegenwaÈrtig wird das Handbuch in Zusammenarbeit mit den Designern der beteiligten Projekte erweitert, so daû trotz unterschiedlicher AnsaÈtze in den Projekten versucht wird, die Details uÈber eine allgemeinere Konstruktion zu integrieren oder sich fuÈr eine der MoÈglichkeiten als zukuÈnftige Variante zu entscheiden und so einen lokalen Standard festzulegen. Die Vorteile liegen auf der Hand: Mitarbeiter der Sparte werden durch kuÈrzere Einlesezeiten mobiler einsetzbar, die Projekte werden durch die Anleitung stabiler, und existierende Systeme koÈnnen im Rahmen der Wartung bei Gelegenheit konvergent in Richtung der neuen Struktur gefuÈhrt werden. Allerdings sind gerade diese Entscheidungen nicht einfach und oft Reibungspunkte zwischen den Teams und dem Handbuchverfasser. Das Erreichen der zweiten Stufe des Reuse-Modells stellt noch keine EinfuÈhrung einer wirklichen, bewuûten Reuse-Kultur dar. Es bietet lediglich eine domaÈnenspezifische Ausgewogenheit aller Entwicklungsdokumente ohne einer speziell reuse-orientierten Entwicklung. Diese Stufe ermoÈglicht jedoch sowohl die Wartbarkeit von Software-Systemen als auch eine vernuÈnftig angepaûte zeit- und kostenguÈnstige Wiederverwendung innerhalb aÈhnlicher Projekte. Ein strategischer Vorteil der Stufe II ist die Entwicklung und Sammlung von Bestandteilen fuÈr die Vorbereitung der in Stufe III einzufuÈhrenden Standards, ohne jedoch die Verwendung eines solchen Standards sofort zwingend vorzuschreiben und implizit damit existierende ± klarerweise nicht dem neuen Standard entsprechende ± System(teil)e abzuwerten. In der beobachteten Versicherung gibt es im Bereich Lebensversicherung etwa 5000 COBOL Batchprogramme, die gut wartbar und dokumentiert waren. Die Restrukturierung einer domaÈnenorientierten Abstraktion erfordert geschaÈtzte sechs bis acht Personenjahre, die im Hinblick auf die langfristige Bedeutung des Bereichs uÈber die naÈchsten zwei bis drei Jahre investiert werden. Wesentliche Erkenntnisse der am laufendenProjekt Beteiligten waren: Das Wissen des vorhandenen Personals kann nur durch den Einsatz einfacher AnsaÈtze (etwa einfacher Schablonentechnik und objektorientierter Bibliotheken im Bereich der Benutzerschnittstelle) breit eingebunden werden, da das Wissen sehr weniger Mitarbeiter dem Stand der Technik entspricht und nur ein inkrementeller Aufbau neuen Wissens auf der vorhandenen Basis mittelfristig Erfolg verspricht. Die VeraÈnderung alter Gewohnheiten des Handelns braucht Didaktik und auch politisches Geschick zur UÈberwindung von WiderstaÈnden. Zielpersonen fuÈr AnsaÈtze der Stufe II in der Organisation sind Designer, Analytiker, QualitaÈtssicherer und Projektmanager, aus denen die lokalen DomaÈnenexperten rekrutiert werden und die fuÈr die weitere Verbreitung des Wissens und Handelns sorgen. FuÈr die Umsetzung der beiden ersten Stufen des vorgestellten Reuse-

205

Modells ist kein in der Reuse-Literatur beschriebenes Verfahren notwendig. Es kommen hier also nur bekannte und bewaÈhrte technische Methoden des Software-Engineering zum Einsatz. Die auf Stufe II erreichte Wiederverwendbarkeit innerhalb aÈhnlicher Projekte ist vielmehr ein aus der verstaÈndlichen Struktur aller Entwicklungsdokumente resultierender Seiteneffekt. 3.3. Stufe III: Standardisierung ± Grundlage fu Èr bereichsu È bergreifende Wiederverwendung

FuÈr das Institutionalisieren einer unternehmensweiten Reuse-Kultur in der Entwicklung sind zusaÈtzliche technische und organisatorische Aufwendungen notwendig. Der unserer Ansicht nach groÈûte und wichtigste Teil der dabei notwendigen Aufwendungen liegt in der Entwicklung und Durchsetzung von geeigneten Standards, sowohl fuÈr die wesentlichen Ablaufphasen als auch fuÈr die dabei entstehenden Produkte. Diese Standardisierung ist weniger ein technisches denn ein organisatorisches Problem. Ein Groûteil der in der wissenschaftlichen Literatur beschriebenen Reuse-AnsaÈtze ist methodenorientiert. Wiederverwendung ist aber vor allem ein Problem der Organisation und des Management. Wird dieses Faktum nicht erkannt oder zuwenig beruÈcksichtigt, so kann die Idee des Software-Reuse leicht das gleiche Schicksal erleiden wie etwa die QualitaÈtssicherung in den 80er Jahren. Um die Bedeutung der organisatorischen Maûnahmen zur Definition von Standards hervorzuheben, bezeichnen wir die dritte Stufe des ReuseModells als Stufe der Standardisierung. Das Etabliereneiner funktionierenden Reuse-Kultur bedarf geeigneter organisatorischer Maûnahmen zur Definition und Durchsetzung von Standards in allen relevanten Bereichen. Im technischen Bereich ist etwa eine geeignete Methodik zur QualitaÈtssicherung notwendig. Im organisatorischen Bereich muû sowohl eine Koordination der qualitaÈtssichernden AktivitaÈten als auch der speziellen Reuse-AktivitaÈten erfolgen. Zur DurchfuÈhrung all dieser Aufgaben sind spezielle neue Positionen (Rollen) zu besetzen, der Reuse-Ingenieur und der Reuse-Koordinator (siehe Abb.4). Im folgenden werden die in Abb.4 dargestellten Rollen, die ihnen zugeordneten AktivitaÈten und Verantwortlichkeiten sowie gegebenenfalls die dafuÈr notwendigen Qualifikationen beschrieben. Dabei wollen wir uns im wesentlichen auf die Beschreibung der Positionen mit technischer Kompetenz beschraÈnken. Die Ebene der wirtschaftlich und strategisch kompetenten Positionen wird nur kurz erlaÈutert. Die Aufgabe des Top-Management ist es, Wiederverwendung als bewuûten Teil der Software-Entwicklung zu definieren, als Teil der firmeninternen Entwicklungskultur. Die in der Literatur [6, 8, 13, 14] beschriebenen praktischen Erfahrungen zeigen sehr deutlich, daû ein Reuse-Programm nur dann erfolgreich sein kann, wenn es vom obersten Management initiiert, laufend beobachtet, unterstuÈtzt und als Teil der Entwicklungskultur verankert wird.

Taxonomie der Rollen innerhalb einer Reuse-Umgebung unter BeruÈcksichtigung von a) Projektebene und strategischer Ebene und b) technischer und wirtschaftlicher Kompetenz Abb. 4.

Das mittlere Management (MM) entwickelt auf organisatorischer Ebene Methoden und Standards, um die Durchsetzung der Reuse-Kultur in der taÈglichen Entwicklungs- und WartungstaÈtigkeit abzusichern. Das mittlere Management definiert und bewertet Testprojekte mit Hilfe von technischen Beratern (TB), es strukturiert die Software-Entwicklung in Applikationsbereiche (DomaÈnen) und ordnet den einzelnen Gruppen Reuse-Ingenieure (RI) zu. Weiters muû die Etablierung einer zentralen Datenbank aller das Reuse-Programm firmenweit betreffenden Komponenten mit Hilfe der QualitaÈtssicherung (QS) erfolgen. Andere wesentliche Aspekte betreffen etwa die Entwicklung von Belohnungsschemata, die laufende Schulung der Mitarbeiter sowie die LoÈsung allfaÈlliger rechtlicher Probleme. Das mittlere Management muû ein Entwicklungsklima etablieren und unterstuÈtzen, das es dem Projektmanagement erlaubt, auch unter Zeitdruck qualitativ hochwertige, den existierenden Standards entsprechende, Komponentenzuproduzieren.Esdarfzukeinendauerhaften ¹quick-and-dirtyª LoÈsungen kommen; das Prinzip der QualitaÈt muû als oberste Maxime Vorrang haben. Dem Projektmanagement (PM) obliegt es, die tatsaÈchliche DurchfuÈhrung der vorgegebenen Reuse-AktivitaÈten durch die an den einzelnen Projekten beteiligten Gruppen zu garantieren. In der Abb.4 wird das Projektmanagement noch in eine wirtschaftliche (WL) und technische (TL) Projektleitung unterteilt. Die Aufgabe der wirtschaftlichen Projektleitung (WL) ist es, etwaige Subunternehmer oder sonstige an Projekten beteiligte Vertragspartner zur Entwicklung von Komponenten (Software und Dokumente) anzuhalten, die den festgelegten Standards entsprechen. Die technische Projektleitung (TL) hat sowohl organisatorische alsauchrein technische Aspektezu beruÈcksichtigen. Auf der organisatorischen Seite ist der Einsatz von effizienten und konsistenten Methoden in allen Phasen

206

der Software-Entwicklung und Wartung durch die zugehoÈrigen Gruppenleiter (GL) und die eigentlichen Entwickler (PR) zu gewaÈhrleisten. Die technische Projektleitung ist also fuÈr die eigentliche Umsetzung der firmenweiten Standards in der taÈglichen Entwicklungsarbeit verantwortlich. Die Einhaltung der Standards muû auch unter Zeitdruck garantiert sein, da ansonsten ein Anwendungssystem (Projekt) einer schleichenden QualitaÈtserosion unterworfen ist, die im Laufe der Zeit die firmenweite und spartenuÈbergreifende Wiederverwendung unmoÈglich macht. Ein firmenweites Reuse-Programm wuÈrde somit unterminiert. Um dies zu verhindern, muû die technische Projektleitung die auf Stufe I beschriebene starke inhaltliche Beziehung zwischen Wiederverwendung und zukuÈnftigen WartungstaÈtigkeiten sowohl organisatorisch als auch technisch in Abstimmung mit den Gruppenleitern fuÈr die jeweiligen sparteninternen Teilprojekte etablieren. FuÈr die Menge aller Teilprojekte muû die auf Stufe II beschriebene Ausgewogenheit erhalten werden. Dem technischen Projektleiter obliegt auf technischer Seite die endguÈltige Filterung der spartenspezifischen Reuse-Datenbank. Dazu gehoÈrt die Auswahl zu uÈbernehmender Komponenten sowohl aus den eigenen Entwicklungsgruppen als auch der firmenweiten Datenbank. Ersteres erfolgt dabei in Abstimmung mit den jeweiligen Gruppenleitern, letzteres in Abstimmung mit den zugehoÈrigen Reuse-Ingenieuren. Der Reuse-Ingenieur beraÈt die technische Projektleitung in Fragen der AnwendungsdomaÈne und deren Schnittstellen zu den uÈbrigen firmeninternen DomaÈnen. Die technische Projektleitung ist daher auch die primaÈre Kommunikationsschnittstelle zwischen firmenweitem und spartenspezifischem Reuse (siehe auch Abb.5 u. 6). Um die spartenspezifische Ausgewogenheit zu erhalten, muÈssen die auf Stufe II beschriebenen technischen AktivitaÈten in Zusammenarbeit mit der QualitaÈtssicherung (QS) koordiniert und uÈberwacht werden. Die Aufgabe der technischen Projektleitung ist es dabei, aufgrund der Anforderungen bereits existierende sehr generelle Entwurfsdokumente zu identifizieren, um danach die Entwicklung wiederverwendbarer Komponenten durch die untergeordneten Gruppen zu ermoÈglichen. Die technische Projektleitung ist daher fuÈr den Entwurf der spartenspezifischen Applikationen auf sehr hohem Niveau verantwortlich. Solange die firmenweiten Standards nicht verletzt werden, steht es der technischen Projektleitung frei, innerhalb des Projekts (der Sparte) eigene Richtlinien zur Entwicklung vorzugeben, oder spezielle Methoden einzusetzen (Anwendungsgeneratoren, OO-AnsaÈtze, parametrisierte Modulskelette etc.). Dadurch wird die notwendige FlexibilitaÈt und Autonomie der einzelnen Sparten gesichert. Die Rolle der technische Projektleitung ist mit hoher Verantwortung und hohen technischen Anforderungen verbunden und erfordert daher auch eine hohe Qualifikation. Wesentliche Punkte des Anforderungsprofils sind: hohes Verantwortungsbewuûtsein und Konsequenz-, Delegations- und KommunikationsfaÈhigkeit, exzellentes DomaÈnenwissen, Abstraktions- und Analy-

severmoÈgen sowie gute Kenntnisse der spartenspezifischen technischen Aspekte. Die Gruppenleitung (GL) ist primaÈr mit technischen Aspekten der Entwicklung befaût. Sie waÈhlt in der Entwurfsphase eventuell existierende Komponenten aus oder selektiert aus Komponenten mit gleicher FunktionalitaÈt aufgrund der spartenspezifischen technischen Aspekte. Die Gruppenleitung versucht in der Integrationsphase, so weit wie moÈglich bereits vorhandene TestfaÈlle und Testdaten wiederzuverwenden. Eine weitere wichtige Aufgabe der Gruppenleiter ist es, innerhalb des bearbeiteten Teilprojekts die auf Stufe I definierten Ziele zu verfolgen und das Teilprojekt im Sinne der QualitaÈtsanforderungen konsistent zu halten. Die Methoden des gewaÈhlten Software-Engineering-Modells sind also konsequent anzuwenden, um spaÈtere Modifikationen und Wartungseingriffe leicht moÈglich zu machen. Die Gruppenleitung ist fuÈr die AktualitaÈt und Konsistenz aller Dokumente des Teilprojekts verantwortlich. Sie filtert in ihrem Teilprojekt die von denEntwicklern gelieferten Module auf moÈgliche spartenweite Verwendbarkeit. Die Gruppenleitung benoÈtigt daher sowohl umfassende Kenntnisse des eigenen Teilprojekts als auch sparteninterner aÈhnlicher Applikationen auf Designebene. Die Entwickler bzw. Programmierer (PR) sind fuÈr den eigentlichen Einsatz wiederverwendbarer Komponenten auf Code-Ebene zustaÈndig. So weit wie moÈglich werden aufgrund des Designs bereits existierende Module und Testdaten verwendet. Sind diese nicht vorhanden, sollten bei der Programmierung moÈglichst vorgegebene parametrisierte Module oder Codeskelette eingesetzt werden, um groÈûere GeneralitaÈt zu erreichen. Die Programmierer sind fuÈr die AktualitaÈt und Konsistenz der Dokumentation auf Code-Ebene verantwortlich und sollten derart verantwortungsbewuût sein, auch unter Zeitdruck auf guten Programmierstil und VerstaÈndlichkeit zu achten. Die Programmierer koÈnnen eigenentwickelte Module, die ihrer Ansicht nach auf hoÈherer Ebene wiederverwendbar sind, der Gruppenleitung zur Begutachtung vorlegen. Die Programmierer sind damit Produzenten wiederverwendbarer Code-Module. Die bis jetzt vorgestellten technischen Rollen (Projektmanager bzw. Technischer Projektleiter, Gruppenleiter, Programmierer) im Reuse-Modell sind die TraÈger des Modells auf der Ebene der einzelnen Sparten. Sie fuÈhren sparteninterne Wiederverwendung durch und sind eine Voraussetzung fuÈr spartenuÈbergreifende Wiederverwendung. Die einzelnen Rollen koÈnnen in AbhaÈngigkeit von der GroÈûe der firmenweiten Entwicklung auch teilweise miteinander verschmolzen werden, z.B. durch eine IdentitaÈt von technischer Projektleitung und Gruppenleitung. Basierend auf der innerbetrieblichen Struktur der genannten Beratungskunden, gibt Tabelle 1 eine AbschaÈtzung der benoÈtigten Personalressourcen in AbhaÈngigkeit von der GroÈûe der Entwicklung sowie der VerfuÈgbarkeit von qualifiziertem Personal. Um spartenuÈbergreifende, firmenweite Wiederverwendung zu ermoÈglichen, sind jedoch noch einige Positionen zu besetzen, die primaÈr fuÈr die Kommunikation

Notwendige Personalressourcen in AbhaÈngigkeit von der GroÈûe der Entwicklung GroÈûe/Rollen PR GL PM/TL groûe Entwicklung (∼ 600 Personen) 300±400 80±100 30±40 mittlere Entwicklung (∼ 120 Personen) 60±80 20±25 8±12 kleinere Entwicklung (∼ 30 Personen) 15±20 5±6 3±5 Tabelle 1.

und den Informationsaustausch auf sehr hoher Ebene zustaÈndig sind. Die technischen Berater (TB) pruÈfen den firmenexternen aktuellen Stand der Technik in bezug auf Software-Engineering und Reuse-Methoden und beraten das Top-Management in allen diesbezuÈglichen strategischen Fragen. Die QualitaÈtssicherung (QS) hat zwei wesentliche Aufgaben im vorgeschlagenen Modell. Sie ist einerseits fuÈr die formale UÈberpruÈfung der vom mittleren Management definierten Standards zustaÈndig. Dies gilt sowohl fuÈr die angewandten Entwicklungsmethoden als auch fuÈr die entwickelten Komponenten. Um diese Funktion erfuÈllen zu koÈnnen und die QualitaÈt der entwickelten Komponenten konstant zu halten, muû die QualitaÈtssicherung mit einem wirksamen Einspruchsrecht im Entwicklungsprozeû ausgestattet sein. Die QualitaÈtssicherung pruÈft weiters, ob Komponenten, die in diefirmenweite Reuse-Datenbank uÈbernommen werden sollen, den formalen Kriterien entsprechend codiert und dokumentiert sind. Dies gilt fuÈr Komponenten aller Entwicklungsebenen bzw. -phasen. Im Zusammenhang mit der firmenweiten Datenbank hat die QualitaÈtssicherung also die Sicherstellung der Mindestanforderungen an die QualitaÈt der aufzunehmenden Software-Komponenten zu garantieren. Andererseits erfuÈllt die QualitaÈtssicherung auch die Rolle eines Moderators zwischen extremen Verhaltensweisen von Programmierern: Dabei sollen die ¹penetranten Besserwisserª, die immer wieder geniale Versionen oder Verbesserungen eher nebensaÈchlicher Komponenten schicken, eingebremst werden, waÈhrend ¹stille Arbeiterª eher dazu aufgefordert werden, ihre wertvollen BeitraÈge auch zur VerfuÈgung zu stellen. Diese ModeratorentaÈtigkeit wird gemeinsam mit dem Projektmanagement und/oder Gruppenleiter wahrgenommen. Die Reuse-Ingenieure (RI) haben eine zweifache Aufgabe zu erfuÈllen. In der Reuse-Factory (siehe Abb.5) sind sie fuÈr die Entwicklung und Wartung der Komponenten der firmenweiten Datenbank zustaÈndig. Sie implementieren dabei einerseits Komponenten, die von den Reuse-Koordinatoren (RK) als firmenweite Abstraktion identifiziert wurden, andererseits verbessern (¹tunenª) sie von den Programmierern entwickelte Komponenten vor einer UÈbernahme in die firmenweite Datenbank. Die Reuse-Factory ist organisatorisch keinem spezifischen Projekt oder Sparte zugeordnet. Ihre zweite Funktion ist die UnterstuÈtzung und Beratung der Projektmanager bei den einzelnen, speziellen Projekten. Hier bringen sie ihr spezifisches Wis-

207 QS 10±20 8±10 2

RI 4±8 2±4 1

RK 2±4 1±2 1

sen uÈber die firmenweit verfuÈgbaren Komponenten und deren FunktionalitaÈt ein. Die Reuse-Ingenieure sind damit fuÈr die Projektmanager die primaÈre Schnittstelle zwischen dem firmenweiten Reuse-Material und den jeweiligen spartenbezogenen Projekten. Die Reuse-Koordinatoren (RK) sind fuÈr die FunktionalitaÈtund Wartung der zentralen Datenbank verantwortlich. In diesen Aufgabenbereich faÈllt die Definition von formalen Standards, die die Komponenten der Datenbank erfuÈllen muÈssen. Ein wichtiger Punkt ist dabei die Definition des firmenweiten Klassifikationsschemas fuÈr Komponenten und Dokumente, die Implementierung von benutzerfreundlichen Zugriffsfunktionen auf die Datenbank, sowie die Etablierung einer effizienten Informationspolitik uÈber verfuÈgbare Komponenten. Ein umstaÈndliches Handling des Reuse-Materials kann zum Versagen des gesamten Reuse-Programms fuÈhren. Im inhaltlichen Bereich ziehen die Reuse-Koordinatoren die Ergebnisse der DomaÈnenanalyse heran, um noch nicht vorhandene potentiell wiederverwendbare Komponenten zu identifizieren und gegebenenfalls durch die Reuse-Factory implementieren zu lassen. Sie pruÈfen Komponenten, die von Sparten zur Aufnahme in die firmenweite Datenbank vorgeschlagen auf ihre inhaltliche Eignung, d.h. auf die GeneralitaÈt der Abstraktion. Die Reuse-Koordinatoren haben eine hohe Verantwortlichkeit, da ihre TaÈtigkeit firmenweite Wiederverwendung erst funktionieren laÈût. Sie stellen eine Kommunikationsschnittstelle von der zentralen Datenbank zu den einzelnen Sparten dar. Die FaÈhigkeit, Prozesse auf moÈglichst hoher Ebene zu analysieren und zu abstrahieren, ist daher wesentliche Voraussetzung fuÈr diese Position. Insgesamt erfolgt durch die Investition in institutionalisierte Wiederverwendung tendenziell eine Verschiebung und Verfeinerung der Entwicklungsqualifikationen weg vom zeilenorientierten Programmieren in Richtung Zusammensetzen und Konfigurieren existierender LoÈsungen. Entsprechende Ausbildung ist ein zentraler Beitrag zum Gelingen von breit eingesetztem Software-Engineering und von Wiederverwendung: WaÈhrend ausreichend viele Personen im klassischen Programmieren geschult sind, gibt es zu wenig Personen mit den wuÈnschenswerten Qualifikationen fuÈr die Rollen Designer, DomaÈnenanalytiker, QualitaÈtssicherer oder auch Projektmanager. Nur Betriebe die durch rollenspezifische Ausbildung und Training gezielt in ihr Personal investieren, werden einen ausreichenden Anteil (etwa ein Achtel, siehe Tabelle 1) genuÈgend qualifizierter Personen erreichen, um die oben beschriebenen

208

Informationsfluû zur Sammlung wiederverwendbarer Dokumente Abb. 5.

Rollen sinnvoll besetzen zu koÈnnen. Wo gute Designer oder Projektmanager Mangelware sind, ist es kontraproduktiv, diese wenigen Juwelen aus Produktionsprojekten fuÈr zentrale Services abzuziehen. Dort wo es ausreichend viele derart qualifizierte Personen gibt, besteht die MoÈglichkeit zwischen Entwicklung (Gruppenleiter, Projektmanager), Produktion und Inhouse-Consulting (wie etwa die Reuse-Ingenieure) zu rotieren und damit einen Anreiz fuÈr die Mitarbeiter zu schaffen, breitere Erfahrung zu sammeln, was sich letztendlich fuÈr die Firma als strategischer Vorteil erweist. Nach der Beschreibung der einzelnen Rollen des Modells und der dabei existierenden Kommunikationswege zwischen den jeweiligen Personen (in Abb.4), zeigt Abb.5 die tatsaÈchliche, firmenweite Sammlung von wiederverwendbaren Komponenten und Dokumenten in Reuse-Datenbanken auf drei organisatorischen Ebenen: eine jeweils projektweit verwendete Datenbank, eine jeweils spartenspezifische Datenbank und schlieûlich die firmenweite Datenbank. Wiederverwendbare Komponenten werden auf zwei verschiedene Arten erzeugt: Top-down von der ReuseFactory und bottom-up von den Anwendungsentwicklern. In der Reuse-Factory werden wiederverwendbare Komponenten aufgrund der Identifikation von Potentialen durch einen Reuse-Koordinator implementiert und stehen danach den einzelnen Sparten zur VerfuÈgung. Diesen Vorgang kann man als eine Art top-down orientierte Produktion von wiederverwendbaren Komponenten ansehen, da hier Komponenten sehr hoher GeneralitaÈt entstehen. Die GeneralitaÈt der Komponenten bildet dabei die Abstraktion eines firmenweit eingesetzten Prozesses (oft ein GeschaÈftsfall) ab.DieIdentifizierung dieser Prozesse erfolgt dabei auch durch den Reuse-Koordinator. Es ist offensichtlich, daû eine relativ groûe Menge von firmenweiten Prozessen auf relativ niedriger Abstraktionsebene existieren muû, die aus der Sicht des Reuse-Koordinators nicht erkenntlich sind bzw. nicht wesentlich scheinen. Diese Prozesse werden in der ProjekttaÈtigkeit der Entwickler implementiert,

durch den Erzeuger oder dessen Vorgesetzten vorgeschlagen bzw. auf Anfrage eines projektzugeordneten Reuse-Ingenieurs oder QualitaÈtssicherers weitergegeben, und wandern aufgrund ihrer inhaÈrenten GeneralitaÈt schlieûlich in die firmenweite Datenbank. Dieser Vorgang entspricht einer bottom-up orientierten Produktion wiederverwendbarer Komponenten durch die Entwickler. Die drei verschiedenen Arten von Reuse-Datenbanken in Abb.5 werden nun, wie in Abb.6 folgt, mit bottom-up entwickelten Komponenten gefuÈllt. Die entwickelten Komponenten werden dabei aufgrund ihres Abstraktionsgrads und ihrer GeneralitaÈt fuÈr die Eignung zur UÈbernahme in die jeweilige Datenbank gepruÈft. Die Filterung auf den einzelnen Ebenen garantiert, daû die Verbreitung der Komponenten mit ihrer VerwendungsmoÈglichkeit (projekt-, sparten-, firmenweit) korreliert. Die Schritte 5 und 6 werden notwendig, wenn die Komponenten noch weiter verbessert werden muÈssen. Diese Filterung garantiert beim umgekehrten, topdown orientierten Vorgang des Informationsflusses in Abb.7 eine optimale Auswahl der wiederzuverwendenden Komponenten, da vonBeginn an Personen mit breitem UÈberblick (Reuse-Koordinator, Reuse-Ingenieur) eingebunden werden, die dem Verantwortlichen (Projektmanager) VorschlaÈge machen, die dann lokal verfeinert werden (Gruppenleiter, Programmierer). Der wesentliche Unterschied zwischen den in den Abb.6 und 7 dargestellten InformationsfluÈssen besteht darin, daû in Abb.6 konkrete Komponenten transferiert werden, wogegen in Abb.7 eher Informationen uÈber konkrete Komponenten weitergegeben werden. Dies gilt jedoch nur bis zu Schritt 3, ab dann erfolgt der Informationsaustausch gruppenintern auf informeller Ebene. In AbhaÈngigkeit von der GroÈûe der firmenweiten EntwicklungstaÈtigkeit koÈnnen einzelne Rollen auch miteinander verschmolzen werden (siehe dazu auch Tabelle 1). Die Konzeption von mehreren Reuse-Datenbanken auf drei Ebenen im Gegensatz zu einer einzigen groûen

209

Bottom-up Informations- und Komponentenfluû; Software-Entwicklung Wiederverwendung Abb. 6.

fu Èr

Top-Down Informationsfluû; Software-Entwicklung Wiederverwendung Abb. 7.

mit

Datenbank, in der alle jemals erzeugten und irgendwo fuÈr wiederverwendbar befundenen Dinge enthalten sind, hat drei GruÈnde: 1) Einfacherer UÈberblick fuÈr den Wiederverwender, 2) Positive Korrelation von QualitaÈt und Verbreitung einer Komponente und 3) Konzentration der besten Leute an den wirkungsvollen Stellen. Ein potentieller Verwender soll moÈglichst nur uÈber Komponenten informiert werden, die wahrscheinlich fuÈr sein Projekt interessant sind; die Sicht eines Entwicklers auf die Datenbank zu seinem eigenen Projekt, seiner Sparte und den firmenweit verwendbaren Teilen verspricht eine anteilsbezogen hoÈhere Ausbeute passender Teile und bildet die gewohnten organisatorischen Beziehungen ab. Die Vielzahl beteiligter Leute erfordert als Grundlage fuÈr effektives Handeln eine vernetzte Kommunikation, die einfach innerhalb von Stufen und zwischen Stufen moÈglich ist. Jede Reuse-Datenbank enthaÈlt pro Komponente neben den technischen Daten (Name der Komponente, Stichworte, Kurzbeschreibung, GroÈûe, Version, Entwicklungsumgebung) auch Hinweise zu den WissenstraÈgern in der Organisation (Hersteller (Name, Projekt, Sparte, Datum, Telefon, E-Mail) und Wartungsverantwortlicher), sodaû neben den uÈblichen Funktionen Suchen, Finden und Anschauen einer KomponentevorallemauchmitdenkompetentenAnsprechpartnern einfach Kontakt gefunden werden kann. Die strikte Trennung der einzelnen Sparten durch Verwenden verschiedener Datenbanken wird durch die informelle persoÈnliche Kommunikation, uÈber elektronische Diskussionsforen bzw. ¹schwarze Bretterª oder die weit herumkommenden Reuse-Ingenieure als Berater gezielt aufgeweicht. Im Normalfall ist eben diese Trennung ein wirksamer Filter gegen eine UÈberhaÈufung des potentiellen Verwenders mit spartenfremder Information, die ihn zum groÈûten Teil nicht interessiert. È berblick fu Einfacherer U È r den Wiederverwender:

Es ist auch in Zukunft davon auszugehen, daû ein Groûteil der neuen Komponenten unter Zeitdruck fuÈr die Einmalverwendung hergestellt wird. Der RuÈckhalt qualitativ schwacher Komponenten ist ein integrales BeduÈrfnis der Wiederverwendungsidee; erste Filter innerhalb eines Projekts oder Sparte ± etwa der lokal kompetente Gruppenleiter oder Projektmanager ± sind wirksamer bei der ZuruÈckweisung als etwaige entfernte zentrale Stellen. Sehr groûe Firmen koÈnnen eine groÈûere oder mehrere verteilte firmenweite Reuse-Datenbanken haben, der Austausch von Komponenten zwischen diesen erfolgt uÈber die lokalen Reuse-Koordinatoren und ist eine Abbildung der DomaÈnenkongruenz zwischen den Firmenteilen. Wirklich gute Leute mit Spezialqualifikationen sind effektiv, knapp und teuer; daher ist ein strategisches Ziel, diese wenigen in SchluÈsselstellen zu konzentrieren. Die Reuse-Factory und die firmenweite ReuseDatenbank mit der zugehoÈrigen QualitaÈtssicherung sind solche SchluÈsselstellen. Durch die Vorfilterung innerhalb der Sparten und Projekte erhalten nur noch relativ wenige und wichtige Komponenten (siehe Tabelle 2) die konzentrierte Aufmerksamkeit der QualitaÈtssicherung und Reuse-Ingenieure. Nur dadurch kann eine hohe QualitaÈtsstufe der firmenweit verwendeten Komponenten sichergestellt werden. Tabelle 2 illustriert die im Rahmen der genannten Projekte angestrebte Filterwirkung der drei Reuse-Ebenen: Unter der Annahme, daû in einem Jahr etwa 400 Entwickler pro Person 20 bis 45 neue Komponenten erstellen, von denen 10% zumindest im Projekt wiederverwendet werden koÈnnen, ergibt das insgesamt 800 bis 1800 Komponenten pro Jahr, die pro Projekt in die lokale Datenbank wandern. Davon werden in diesem Beispiel wiederum 10% spartenweit verbreitet, und 10% Positive Korrelation von Qualita È t und Verbreitung ei-

ner Komponente:

Konzentration der besten Leute an den wirkungsvol-

len Stellen:

210

Beispiel zur Filterwirkung der gestaffelten Reuse-Datenbanken Dinge Projektebene Anzahl der Reuse-Datenbanken auf dieser Ebene 40±60 Anzahl wiederverwendbarer Komponenten pro Datenbank pro Jahr 20±30 Gesamtzahl wiederverwendbarer Komponenten pro Jahr 800±1800 Filterwirkung (Annahme) 10% der erstellten Komponenten Tabelle 2.

Spartenebene 8±10 10±20 80±200 10% der Komponenten von der Projektebene

Konzepte, Methoden und Werkzeuge fuÈr Wiederverwendung in der Praxis Management Requirements Design Domain Analysis [1] Design Apprentice Konzept Prozeûmodelle [2] PBO, QualitaÈtssiche- Bo, Requirements [29] Pb rung PBO, Incentives Apprentice [26] Pb PBO Methode Software-Factory [16, Draco [18] Pb, OOA OOD PBo, Parametri17] PBO, KostenschaÈt- PBo, Experten, Schu- siertes Programmieren lung von Neulingen pBo, Verallgemeinerte zungsmodelle Pb, Komponenten [27] Bo Metriken zur Projekt- PBO evaluierung PBo, REBOOT [25] pBO Werkzeug CASE-Werkzeug mit allg. DomaÈnenmodell Module Templates pBo, implementiertem in einem OOA-Tool OO-Klassen BiblioProzeûmodell P Bo thek Pb, SE-Umgebung PBo, MIL [21] Tabelle 3.

aller spartenweit qualifizierten werden in die firmenweite Reuse-Datenbank gestellt. Die Prognose der Filterwirkung uÈber fuÈnf Jahre hinweg laÈût einen jaÈhrlichen relativ konstanten langsamen Zuwachsauf Sparten- und Organisationsebene erwarten, wo alle Komponenten, die einmal dorthin gelangt sind erhalten bleiben. Die Sammlung auf Projektebene bleibt lokal und stirbt mit dem Projekt, was einer wirksamen Garbage Collection aller qualitativ ungenuÈgenden bzw. nur lokal bedeutungsvollen Komponenten gleichkommt. Ein potentieller Verwender (Programmierer oder Gruppenleiter) sieht so im Verlauf der Jahre statt 800 bis 9000 Komponenten aller QualitaÈtsabstufungen (wie im Modell ¹Eintopf-Datenbankª) nur 60 bis 100 Komponenten (Projekt plus Sparte plus Firma uÈber einige Jahre), die leicht zu uÈberblicken sind. Falls ihm diese Auswahl nicht reicht, kann er mit einer RuÈckfrage an Reuse-Ingenieure oder Reuse-Koordinatoren weitere Information einholen. In einer Bank wird nach unserem Vorschlag der Aufbau einer Organisation auf Stufe III fuÈr neu hinzukommende Bereiche uÈber die naÈchsten drei bis fuÈnf Jahre angestrebt. Bisher wurden Mitarbeiter auf ihre Eignung fuÈr spezifische Rollen eingeschaÈtzt, und fuÈr etwa 30 Personen ein mittelfristiger AusbildungsplanÈ entworfen. Aus parallel laufenden strategischen Uberlegungen wurden in einzelnen Bereichen Testprojekte zur EinfuÈhrung von Kommunikations- und Workflow-Instrumenten gestartet, die mittelfristig flexible informelle Kommunikation bringen werden. Binnen zwei bis drei Jahren werden Reuse-Datenbanken aufgebaut, in die

Organisation 1 20 20 10% der Komponenten von der Spartenebene

Code Application Generator [6] p, Problemorientierte Sprachen [6] p Coding for Portability PB, Komponenten Klassifikationschema [9, 11] pBo

Test Wiederverwendung von TestfaÈllen P

Komponenten Bibliothek [7] PBO, CASE-Repository P

Capture/ReplayWerkzeug [3] Pb

Configuration Management [4] Pb

alle bis dahin erfolgreichen Sparten auf Stufe II sowie einzelne gut strukturierte Projekte von Stufe I integriert werden sollen. 4. Reuse-unterstuÈtzende AnsaÈtze aus der Literatur

Betrachten wir ein Software-Lebenszyklusmodell mit vier Phasen (Requirements, Design, Code und Test) als Basis des Prozeûmodells, so erhalten wir zusammen mit dem Managementaspekt insgesamt fuÈnf Segmente, in denen reuse-unterstuÈtzende Maûnahmen gesetzt werden koÈnnen. Tabelle 3 zeigt in der Literatur genannte, fuÈr den Einsatz in der industriellen Praxis geeignete bzw. dort bereits eingesetzte, konkrete AnsaÈtze zur UnterstuÈtzung reuse-orientierter Entwicklungsprozesse. Die Auswahl und die EinschaÈtzung erfolgte nach Umfragen und Diskussionen mit Entwicklern und den Mitarbeitern der Reuse-Projekte in der Bank und kann daher nicht pauschal verallgemeinert werden. Die genannten AnsaÈtze werden dabei von uns sowohl nach der zugehoÈrigen Ebene als auch nach dem Grad der Konkretheit bzw. Reife (Konzept, Methode, Werkzeug) klassifiziert. Ein Konzept ist hier eine eher abstrakte Idee mit eventuell einem Prototypen, eine Methode eine ausprobierte Handlungsanleitung und ein Werkzeug ein kommerziell verwertbares StuÈck Software. Weiters haben wir versucht, in unserem Kontext den zugehoÈrigen Wirkungsbereich des jeweiligen Ansatzes

sowie dessen Effizienz mittels der daneben angefuÈhrten Buchstaben zu bewerten. Der Buchstabe bezeichnet projektbezogene, branchen- bzw. spartenbezogene, und eine organisationsweite Anwendbarkeit; Groûbzw. Kleinbuchstaben kennzeichnen hohe bzw. niedrige Effizienz, fehlt dagegen ein Buchstabe, so ist der Ansatz im entsprechenden Bereich von keinem relevanten Nutzen oder prinzipiell nicht anwendbar. Die nach den vorliegenden Praxisberichten am haÈufigsten eingesetzten und meistverbreiteten ReuseWerkzeuge sind Software-Component-Libraries, objektorientierte Entwicklungsumgebungen sowie CASE-Werkzeuge. Manche Autoren, etwa [16], betrachten CASE-Werkzeuge als ideale Basis fuÈr den Einsatz von Wiederverwendung in der Praxis. Sie verfuÈgen uÈber Repositories, geben Entwicklungsmethoden und Richtlinien vor und implementieren spezielle Prozeûmodelle. Unserer Ansicht nach ist ein CASE-Werkzeug jedoch nur dann als Basis fuÈr eine Reuse-Umgebung zu empfehlen, wenn es speziell fuÈr den Einsatz in einer solchen konzipiert wurde. Wurde ein solches Werkzeug dagegen ohne klare Absicht zur UnterstuÈtzung von Wiederverwendung entwickelt, so haben die vorgegebenen Methoden oft einen gegenteiligen Effekt. Ein Groûteil der in der wissenschaftlichen Literatur vorgestellten AnsaÈtze zur Umsetzung von SoftwareReuse ist methodenorientiert; Wiederverwendung ist unserer Erfahrung nach aber vor allem ein Problem der Organisation und des Management [12]. Die in der Tabelle 3 dargestellten AnsaÈtze sollten also beim gegenwaÈrtigen Stand der Technik nur als Werkzeuge zur UnterstuÈtzung einzelner Prozeûphasen verstanden werden, keinesfalls koÈnnen sie jedoch allein als theoretische oder praktische Grundlage einer reuse-orientierten Entwicklungsumgebung herangezogen werden. P

B

O

5. Schluûfolgerungen

211

Atem und personelle Konstanz des Top-Management voraussetzt. Die Stufen I und II fallen in den autonomen Entscheidungsbereich des mittleren Management; Stufe I bedeutet lokale Investition in vorhandene Personen und Dokumentation, Stufe II verlangt Investition in strategische Strukturen sowie die Heranbildung von DomaÈnenxperten. Auch Stufe III verlangt gezielte Investition in Personen: Projektmanager, QualitaÈtssicherer, Reuse-Ingenieure, Reuse-Koordinatoren (ca. ein Achtel der Belegschaft; siehe Tabelle 1); allerdings mit breiterer Wirkung als in der personengebundenen Wartung. Hier ergeben sich im Erfolgsfall MoÈglichkeiten fuÈr Karriere und Incentives durch Rotation uÈber mehrere Rollen. Die EinfuÈhrung einer solchen Reuse-Kultur in weiten Teilen der Entwicklung ergibt jedoch ausschlieûlich im Rahmen einer neuen Software-Strategie Sinn. Dabei faÈllt eine hohe Startinvestition fuÈr die Etablierung einer Expertengruppe an, die im weiteren Verlauf die Entwicklung, Schulung und den Support fuÈr die verwendeten Reuse-Methoden und -Werkzeuge uÈbernimmt. Zur EinfuÈhrung einer Reuse-Kultur im Sinne der Stufe III muû der gesamte Prozeû der Software-Entwicklung soweit definiert werden, daû zumindest die Reifestufe 33 des SEI-Modells [19, 20] erreicht wird. Bei einer geringeren Reifestufe ist die durchschnittliche QualitaÈt der produzierten Software mit hoher Wahrscheinlichkeit nicht ausreichend, um die Investitionen in Wiederverwendung zu amortisieren. Der wesentliche Punkt ist unserer Ansicht nach die Entwicklung einer Systemumgebung fuÈr die DomaÈne derjenigen Bereiche, in denen zukuÈnftig reuse-orientierte Entwicklung eingesetzt werden soll. Das bedeutet, daû in diesen Bereichen eine ausfuÈhrliche DomaÈnenanalyse vorgenommen wird, sodaû sichergestellt ist, daû inhaltliche Aspekte der neuen Applikationen von den technischen getrennt sind. Nur durch eine saubere Trennung der technischen Aspekte von den inhaltlichen ist eine Wiederverwendung von Applikationsteilen und Modulen in Zukunft moÈglich. Ein geeignetes CASE-Werkzeug stellt beispielsweise ein adaÈquates Kommunikationsmedium fuÈr die im Modell involvierten Personen dar. Wesentliche FunktionalitaÈtsmerkmale sind dabei die MoÈglichkeit der Kommunikation mittels E-Mail, eine gemeinsame Datennutzung, sowie integrierte Werkzeuge zur Bearbeitung dieser Daten. Wichtig ist hier, daû ein spezifisches CASEWerkzeug sowohl den gegenwaÈrtigen als auch den antizipierten Entwicklungsablauf unterstuÈtzt und nicht behindert. Es muû sich also an die zukuÈnftigen Prozesse des Unternehmens anpassen lassen. Die Implementierung der Stufe III des Modells, die firmenweite EinfuÈhrung einer Reuse-Kultur, entspricht primaÈr der EinfuÈhrung einer effizient organisierten Kommunikationsstruktur. Firmenweit existentes Wissen soll dabei in hochwertiger, leicht handhabbarer

Das aus drei Reife- bzw. QualitaÈtsstufen bestehende vorgestellte Reuse-Modell zeichnet sich vor allem dadurch aus, daû auf den ersten beiden Stufen keinerlei hochentwickelte, spezielle Technikenzur UnterstuÈtzung benoÈtigt werden. Hier werden ausschlieûlich bekannte und bewaÈhrte Methoden des Software-Engineering eingesetzt. Die auf Stufe III erreichte Implementierung einer Reuse-Kultur in der Entwicklung bietet im wesentlichen ein geeignetes Kommunikations- und Organisationsschema um spartenuÈbergreifendes Entwickeln, d.h. spartenuÈbergreifende Wiederverwendung moÈglich zu machen. Vernetzung und E-Mail fuÈhren zur leichteren VerfuÈgbarkeit von bzw. Zugang zu Experten und Fakten, da die fruÈher wirksamen formalen Trennungen nun von Personen mit aÈhnlichen Interessen kurzfristig umgangen und mittelfristig umgeformt werden koÈnnen. Die Entscheidung, welche Reuse-Stufe angestrebt wird, ist wesentlich: Stufe I ist Bewahren des Alten, Stufe II, heiût Neues konzertiert angehen, und Stufe III be- 3 Die Definition der Verwendung eines QS-Ansatzes wie in SEI deutet, die Organisation umzustellen; das bedeutet i.a. CMM oder ISO 9000±3 enthalten, garantiert alleine noch keinen einen sehr weitgreifenden Kulturwandel, der unterneh- Erfolg, da in der Praxis i.a. die entsprechend qualifizierten Permenspolitisch heikel sein kann und ausreichend langen sonen fuÈr die Umsetzung fehlen.

212

Form transportiert und ausgetauscht werden koÈnnen. Wesentliche Aufgaben einer solchen Reuse-Kultur sind daher das Informieren uÈber bereits existierendes Wissen (Personen, Dokumente, Komponenten, Methoden etc.), dieses Informieren beinhaltet sowohl Verwendung als auch VerfuÈgbarmachung von Wissen, das Lehren der Verwendung vonÈ Methoden und Werkzeugen und schlieûlich das UberpruÈfen von Systemen und Teilen auf ihre weitere Verwendbarkeit. Literatur

1. Arango, G.: Domain Analysis: From art form to engineering discipline. Proc. Int. Workshop on Software Specification and Design, Washington D.C., 152±159 (May 1989) 2. Basili, V.R., Rombach, H.D.: Support for comprehensive reuse. Software Eng. J., 303±316, (Sept.1991) 3. Beizer, B.: Software testing techniques, 2nd ed. Van Nostrand: Reinhold 1990 4. Berlack, H.: Software configuration management. New York: Wiley 1992 5. Biffl, St., Grechenig, Th.: Degrees of consciousness for reuse of software in practice: maintainability, balance, standardization. Proc. of COMPSAC 93, 17th IEEE International Software & Applications Conference, Phoenix, Arizona, IEEE Computer Society Press (Nov.1993) 6. Biggerstaff, T.J., Perlis, A.J.: Software reusability. ACM-Press 1989 7. Burton, B.A., Aragon, R.W.: The reusable software library. IEEE Software 4(4), 25±33 (1987) 8. Dunn, M.F., Knight, J.C.: Software reuse in an industrial setting. Proc. ICSE-13, 329±338 (1991) 9. Frakes, W.B., Nejmeh, B.A.: An information system for software reuse. In Tracz, W. (ed.) IEEE Tutorial: Software Reuse: Emerging Technology, IEEE Computer Society 1988 10. Frakes, W.B., Isoda, S.: Success Factors of Systematic Reuse. IEEE Software (Sept.1994). 11. Frakes, W.B., Pole, T.P.: An empirical study of representation methods for reusable software components. IEEE TSE 20(8), 617±630 (1994) 12. Grechenig, Th., Biffl, St.: Introducing a software reuse culture in practice. In Proceedings of CSEE 94, SEI Conference on software engineering education, San Antonio, Texas (Jan.1994)

13. Hooper, J.W., Chester, R.O.: Software reuse: guidelines and methods. New York, London: Plenum Press (1991) 14. Lanergan, R.G., Grasso, C.A.: Software engineering with reusable designs and code. IEEE TSE 10(5), 498±501 (1984) 15. Matsumoto, Y.: Some experiences in promoting reusable software: presentation in higher abstract levels. IEEE TSE, 502± 512 (Sept.1984) 16. Matsumoto, Y.: A Software Factory: An overall approach to software production. Proc. of the ITT Workshop on reusability in programming, Newport R.I., 1983 und in FREEMAN P.: Tutorial ¹Software reusabilityª; IEEE-CS Press 1987 17. Matsumoto, Y.: Management of industrial software production. IEEE Computer 17(2), 59±72 (1984) 18. Neighbors, J.: The Draco approach to constructing software from reusable components. IEEE TSE 10(5), 564±573 (1984) 19. Paulk, M.C., Curties, B., Choissis, M.B., Weber, C.U.: Capability maturity model for software, Version 1.1. Technical Report CMM/SEI-93-TR-24 1993. 20. Paulk, M.C.: A Comparison of ISO 9001 and the Capability maturity model for software. Technical Report, CMM/SEI-94TR-12 1994. 21. Prieto-DõÂaz, R., Neighbors, J.M.: Module interconnection languages. Journal of Systems and Software, 307±334 (Nov. 1986) 22. Prieto-DõÂaz, R.: Domain analysis: An introduction. ACM Software Engineering Notes 15(2), 47±54 (1990) 23. Prieto-DõÂaz, R.: Making software reuse work: An implementation model, ACM SIGSOFT SE Notes 16(3), 61±68 (1991) 24. Prieto-DõÂaz, R.: Software reuse: From concepts to implementation. Tutorial at ISAC'93, Monterrey, Mexico (Okt.1993) 25. REBOOT-Konsortium: The REBOOT approach to software reuse. Brochure and case-studies distributed via e-mail: contact [email protected] (1995) 26. Reubenstein, H.B., Waters, R.C.: The requirements apprentice: automated assistance for requirements acquisition. IEEE TSE 17(3), 226±240 (1991) 27. Riehle, R.: Software components ± designing generalized components by creating abstractions. Programmers J., 75±78 (Nov./ Dez. 1990) 28. SchaÈfer, W., Prieto-D'az, R., Matsumoto M. (eds.): Software reusability. Horwood Workshop Series, Chichester, England, 1993 29. Waters, R.C., Tan, Y.M.: Towards a design apprentice: supporting reuse and evolution in software design. Software Engineering Notes 16(2), 33±44 (1991)

213

ist Assistent am Institut fuÈr Softwaretechnik, AG Industrielle Softwaretechnik, der Technischen UniversitaÈt Wien. Er studierte Informatik und Wirtschaftsinformatik und promovierte 1991 zum Doktor der technischen Wissenschaften. Seine Interessen liegen in den organisatorischen Aspekten der Softwaretechnik und der QualitaÈtssicherung, die im Rahmen der Software-Werkstatt praktisch erprobt werden. Stefan Biffl

ist Assistenzprofessor am Institut fuÈr Softwaretechnik, AG Information and Software Engineering, der Technischen UniversitaÈt Wien. Er studierte Informatik und Technische Mathematik und promovierte 1984 zum Doktor der technischen Wissenschaften. Seine Arbeitsschwerpunkte liegen in den Bereichen Softwaretechnik und Didaktik der Informatik.

Gerald Futschek

studiert Informatik an der Technischen UniversitaÈt Wien. Er ist Forschungsassistent der Software-Werkstatt am Institut fuÈr Softwaretechnik im Bereich Didaktik der Softwaretechnik mit Schwerpunkten auf Objektorientierter Entwicklung und Projektmanagement. Christian Brem