Das zufällige Experimentieren mit Tools und ein Mangel an strategischer Planung bremsen den CASE-Vormarsch. Heute arbeiten etwa 15 Prozent aller Software-Entwickler mit entsprechenden Weikzeugen - eine Zahl, die sich bis Mitte der 90er Jahre verdreifachen dürfte. Nur mit einer durchdachten Software-Engineering-Strategie, so Frank Kühle, sind auch die erwünschten Effekte zu erzielen.
CASE-Anbieter hatten 1991 trotz Prognosen eines bevorstehenden Booms ein schwieriges Jahr zu überstehen. Offensichtlich überdenken immer mehr DV-Chefs noch einmal die Methoden und Verfahren ihrer CASE-Einführungspläne. Berichte von den Unzuläriglichkeiten vieler Werkzeuge oder auch das Warten auf AD/Cycle mögen der Grund dafür sein.
Der Einsatz eines CASE-Tools ist nur dann sinnvoll, wenn zuvor neue Methoden, Regeln und Standards unternehmensspezifisch ausgearbeitet und eingeführt worden sind. Sollen die Technologien für Entwicklung und Betrieb von Software einem strategischen Wandel unterzogen werden, so ist dieser Vorgang gründlich zu planen.
Der erste Schritt zur Ausarbeitung einer Software-Engineering-Strategie (SE-Strategie) für das Unternehmen ist die genaue Bewertung des Entwicklungsstandes bereits vorhandener Technologien. In der Fachliteratur werden zwei Verfahren beschrieben, mit denen anhand eines vorgegebenen Fragenkatalogs der erreichte Stand quantifizierbar gemacht wird. Dabei handelt es sich um die Verfahren "SEI Assessment Methodology" nach Humphrey und "RSP&A Assessment Method" nach Pressman (beschrieben in Humphrey, W.: Managing the Software Process und in Pressman, R.S.: Making Software Engineering Happen).
Die den einzelnen Gegenstandsbereichen zugeordneten Fragen beziehen sich unter anderem auf Organisationsregeln, den Einführungsstand von Methoden und Verfahren, die durchgesetzten Qualitätsmerkmale und die Integration der Tools. Im Ergebnis erhält man für jeden Gegenstandsbereich eine Bewertung zwischen eins und fünf sowie zusätzlich eine Gesamtbewertung des Unternehmens auf dieser Skala.
Das detaillierte Bewertungsergebnis identifiziert einerseits Schwachstellen in den eingesetzten Technologien und liefert andererseits Vergleichswerte für die Ermittlung des erreichten Fortschritts, sofern im Rahmen eines Technologiewandels sorgfältig geplante Schritte durchgeführt werden.
Nach erfolgter Bewertung läßt sich die unternehmensspezifische SE-Strategie erarbeiten. Wiederum bezogen auf die genannten Gegenstandsbereiche wird dabei eine Vision über die zukünftigen Technologien der Entwicklung und des Betriebs von Softwaresystemen gezeichnet, die auch die Überwindung von historisch Gewachsenem
beinhalten kann. Es muß sich zunächst nur ein Leitfaden ergeben, aus dem ein überschaubarer Weg für den notwendigen Wandel der Technologien ableitbar ist.
Bei der Festlegung strategischer Ziele wird sich der Software-Engineering-Verantwortliche des Unternehmens vom Stand der Technologien und deren zukünftiger Weiterentwicklung leiten lassen. Anhaltspunkte hierzu bezieht er aus dem genannten Fragenkatalogen. Der Betreffende wird sich aber nicht zuletzt auch auf seine eigene Einschätzung der aktuellen Tendenzen verlassen.
Eine SE-Strategie ist im Zusammenhang mit der strategischen Informationstechnik-Planung des Unternehmens zu betrachten. Zwei Entscheidungen aus dieser übergeordneten Strategie wirken sich besonders stark auf die Software-Engineering-Vision aus: welches Verhältnis von Individual- und Standardsoftware angestrebt wird und welche Entwicklungsplattform zukünftig strategisch ist - ein Mainframe, ein Minicomputer oder eine Workstation. Ferner muß das verfügbare Mitarbeiterpotential beachtet werden. Wird eine SE-Strategie erarbeitet, so sollten die Beteiligten den fortgeschrittensten Stand computerunterstützten Software-Engineering zum Maßstab nehmen.
Resultierend aus den strategischen Zielen und dem derzeit erreichten Stand sind nun praktische Schritte des Technologiewandels abzuleiten. Dabei ist es sinnvoll, zunächst Schritte zur Überwindung von technologischen Rückständigkeiten zu planen. Häufig stellt man hier im Rahmen einer Kosten-Nutzen-Analyse fest, daß das Niveau anderer Bereiche, zum Beispiel der Qualitätssicherung oder der Einführung von Standards und strukturierten Methoden, viel eher Handlungsbedarf hervorruft, als das Niveau des computergestützten Software Engineering (CASE). Als Gegenargument läßt sich allerdings anführen, daß in manchen Bereichen, zum Beispiel bei Methoden und Techniken, das CASE-Tool kaum von der neuen Technologie zu lösen ist. Aber auch hier sollte die Einführung des CASE-Werkzeugs in den strategischen Rahmen passen, es sei denn, der Anwender möchte in einem Entwicklungsprojekt auf der grünen Wiese nur einmal exemplarisch Erfahrung sammeln.
Werden Schritte im Bereich der Werkzeuge und Tools geplant, so sind diese stets verbunden mit Schritten in anderen Gegenstandsbereichen der SE-Technologien. Denn Tools können lediglich die Computerstützung für Methoden und Techniken sowie zur Durchsetzung von Regeln und Standards bereitstellen. Deren Einführung ist von primärer Bedeutung, während die Tools zwar wichtig, aber letztlich doch sekundär sind.
Der Höhepunkt des Technologiewandels vollzieht sich immer dann, wenn in Analyse und Design die strukturierten Methoden eingeführt werden sollen. Für deren Unterstützung wird ein CASE-Tool mit einer möglichst integrierten Unterstützung aller Phasen erforderlich. An diesem Punkt angelangt, ist meist von der CASE-Einführung schlechthin die Rede. Dafür ist ein mittleres Pilotprojekt von zwei bis fünf Mannjahren zu veranschlagen.
Dessen Planung und Durchführung muß unbedingt alle anderen Bereiche des Technologiewandels einschließen. Hierzu ist die Unterstützung der höchsten Management-Ebene notwendig.
Erfahrungsgemäß ist die strategische Informationstechnik-Planung nach etwa zwei Jahren zu überarbeiten. Für eine SE-Strategie kann das wegen des beschleunigten Technologiewandels schon früher erforderlich werden. An dieser Stelle schließt sich der aus Bewertung, Strategieableitung und Strategieumsetzung bestehende Zyklus des Wandels der SE-Technologien. Der Erfolg läßt sich durch eine normierte Bewertung des erreichten Standes in einem jeden Zyklusdurchlauf messen. Der SE-Verantwortliche wird bereits mittelfristig auf einen solchen Nachweis des Technologiefortschritts angewiesen sein. De-facto erwarten Software-Engineering-Fachleute aber in ihrem Bereich erhebliche Produktivitätsfortschritte und Kostenreduzierungen erst auf längere Sicht.
Im folgenden möchte ich auf den gegenwärtigen Stand der CASE-Technologien eingehen und Fakten und Tendenzen aufzeigen.
1. Obwohl der CASE-Umsatz zuletzt stagnierte, ist doch die Einstellung zu diesem Thema positiver geworden. Die meisten DV-Fachleute halten diese Technologien nicht mehr für avantgardistisch. Fortschrittliche Unternehmen empfinden teilweise schon Nachholbedarf.
2. Ein Anteil von zehn bis 15 Prozent der Software-Ingenieure benutzt bereits CASE-Tools, bis 1995 erwarten Marktbeobachter 50 Prozent.
3. Große CASE-Anbieter wie Intersolv, Andersen Consulting oder Texas Instruments wollen sich endlich auch dem Reverse Engineering zuwenden.
4. Die Teilmodelle von IBMs Repository Information Model sind nun vollständig, es gibt aber noch immer keine relevanten CASE-Tools im AD/Cycle-Rahmen mit Repository-Manager-Anschluß.
5. Die Objektorientierung dringt in Ergänzung zu klassischen Methoden immer stärker in CASE-Technologien ein.
6. Wer heute eine CASE-Umgebung aufbauen will, kauft Tools der zweiten Generation, sogenannte I-CASE-Produkte (Integrated CASE). Damit gibt es für die Auswahl mindestens zwei K.o.-Kriterien, die Integration aller Entwicklungsphasen und ein zentrales, multiuserfähiges Repository.
Die CASE-Tools der ersten Generation werden noch in Lower- und Upper-CASE-Tools eingeteilt. "Lower" steht für die späten Phasen, also Codierung/Generierung und Test. Damit sind die Programmierumgebungen für Sprachen der 3. und 4. Generation, im engeren Sinne aber nur die 4GL-Systeme und Generatoren gemeint. Upper-CASE unterstützt die frühen Phasen: Anforderungsdefinition, Analyse und Design.
Diese Zweiteilung der CASE-Welt wird in der zweiten Generation, beim integrierten CASE-Ansatz, überwunden. CASE-Produkte decken endlich den gesamten Lebenszyklus von Software ab. Obwohl derzeit einige Produkte (zum Beispiel IEF von Texas Instruments) diesem Ziel schon sehr nahe kommen, sind noch sehr viele reine Upper-CASE-Tools im Einsatz. Dazu gehören die typischen Workstation-Tools IEW/ADW, Excelerator oder Promod. Nach ihrer Nutzung für die Analyse und Teile des Designs werden Diagramme und Reports erzeugt, die dann als Papierunterlagen in die weitere Entwicklungsarbeit auf anderen Plattformen eingehen. Hier liegt der für CASE-Technologie der ersten Generation typische Bruch zwischen den Phasen Analyse und Design einerseits und Codierung/Test andererseits. Die Ergebnisse auf beiden Seiten lassen sich nicht automatisch kongruent halten. Deshalb ist heute die 100prozentige Generierung des Anwendungscodes als K.o.-Kriterium zu betrachten. Viele Workstation-Tools sind in Richtung I-CASE weiterentwickelt worden.
Heute werden die typischen Workstation-Tools mangels zentralem Repository (auf dem Server oder Host) meist noch als Einzelplatzsystem genutzt. Ein weiteres wichtiges Kennzeichen einer CASE-Technologie der zweiten Generation ist jedoch die zentrale Entwicklungsdatenhaltung in einem Multiuser-fähigen Repository.
Im Zusammenhang mit diesem Datenbehälter wird das ganze Thema der neuen Generation integrierter CASE-Umgebungen stark von der AD/Cycle-Ankündigung des Mainframe-Marktführers dominiert. Das erste und auch wichtigste inzwischen verfügbare Produkt aus dieser Ankündigung ist der Repository Manager/MVS. Er ist Dreh- und Angelpunkt der neuen Technologien der Anwendungsentwicklung und deshalb das Kernstück von IBMs Technologierahmen AD/Cycle.
Die Struktur der durch den Repository Manager zu verwaltenden Daten über alle informationellen Prozesse des Unternehmens ist durch das Repository Manager Supplied ER-Model, IBMs Information Model festgelegt. Dieses Meta-Datenmodell ist die intellektuelle Leistung, mit der IBM einen De-facto-Standard für die Daten-Integration aller AD/Cycle-Tools geschaffen hat.
Frank Kühle ist Berater bei der Heyde und Partner GmbH in Bad Nauheim
Methoden und Techniken: Welchen Stand erreicht ein Unternehmen bei der Einführung der in der kommerziellen DV etablierten Methoden Structured Analysis und Structured Design in einer ihrer Varianten (nach Yourdon/DeMarco, Gane/Sarson oder anderen) in Analyse und Design? Werden Modularisierung, Strukturierte Programmierung, Datenabstraktion etc. in der Realisierung qualifiziert genutzt? Welche Methoden und Techniken für Reverse Engineering sind im Einsatz?
Organisationsstrukturen und -regeln:
Wie sind Entwicklungsprojekt-Teams, Mannschaften für die Wartung und das Reverse Engineering, für Qualitätssicherung, Methoden und Verfahren (eigene Hauptabteilung?) in das Organigramm eingeordnet? Welche organisatorischen Regeln gelten für die Einbeziehung der auftraggebenden Fachabteilungen?
Vorgehensmodell:
Welche Phasen sind für Entwicklungs- und Reverse-Engineering-Projekte oder Studien festgelegt und welche Ergebnistypen sollen daraus hervorgehen? Welche firmenspezifischen öder allgemeinen Standards werden genutzt?
Tools:
Welche Unterstützung beziehungsweise Automatisierung von Methoden und Techniken wird erreicht, und welchen Stand hat die Integration der Tools in einer unternehmensspezifischen Software-Produktionsumgebung über alle Phasen hinweg? Ist die Haltung von Entwicklungsdaten in einem zentralen Repository bereits realisiert?
Qualitätssicherung:
Welche Qualitätsmerkmale und -maße liegen zugrunde? Mit welchen Verfahren der konstruktiven und analytischen Qualitätssicherung (Review, Walkthrough, systematische Testfall-Ermittlung und Testdurchführung etc.) werden Qualitätsmaße ermittelt beziehungsweise Qualitätskriterien erfüllt?
Projektmanagement:
Mit welchen Verfahren werden Projekte hinsichtlich Personal, Zeit und Mittel geplant? Wie sind Projekte und Projektverfolgung beziehungsweise -steuerung organisiert? Wie erfolgt die Verwaltung von Konfigurationen und Versionen?
Bewerten, Schätzen, Messen:
Welche Verfahren nutzt der Anwender zur Schätzung des Projektaufwandes in frühen Phasen (Function Point, Cocomo, Prozentsatzverfahren oder andere)? Welcher
Stand wird bei der Ermittlung der dafür notwendigen unternehmensspezifischen
Vergleichswerte und Normative erreicht? Wie werden Produktivität ermittelt und Kosten-Nutzen-Analysen geführt?
Aus- und Weiterbildung:
Know-how ist die Voraussetzung für die Akzeptanz des Software-Engineering bei den Beteiligten. Entscheidend ist daher, wie dieses Know-how aufgebaut wird. Wichtig ist ebenfalls, welche SE-Kenntnisse abgestuft auch im Management und in den Fachabteilungen erreicht werden.
Die Aufzählung der Gegenstandsbereiche zeigt, daß der Technologiewandel in Entwicklung und Betrieb von Software wesentlich umfassender ist, als die Einführung eines CASE-Tools. Die aufgeführten technischen Fragen lassen sich natürlich nicht für jedes Unternehmen gleichartig beantworten. Der CASE-Anbieter kann in seinem Tool die Unterstützung ausgewählter Methoden und Techniken mit mehr oder weniger Flexibilität vorsehen. Das methodenunabhängige Tool sollte deshalb auf die unternehmensspezifischen Methoden, Standards und Konventionen anpaßbar sein.