Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.02.1992 - 

Schwachstellenanalyse ist erste Voraussetzung

Ohne Strategie wirft der CASE-Einsatz Probleme auf

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 Enginecring 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 irn 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 Mainfrarne, 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 Iools zwar wichtig, aber letztlich doch sekundär

sind.

Der Höhepunkt des Fechnologiewandels vonzieht 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 CASECinfü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 ancleren Bereiche des Technologiewandels einschließen. Hierzu ist die Unterstützung der höchsten Management-Ebene notwendig.

Erfahrungsgemäß ist die stra@egische InformationstechnikPlanung nach etwa zwei Jahren zu überarbeiten. Für eine SEStrategie kann das wegen des beschleunigten Iechnologiewandels schon früher erforderlich werden. An dieser Stelle schli eßt sich der aus Bewertung, Strategieableitung und Strategieumsetzung bestehende Zy-

klus 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-Enginecring-Fachleute aber in ihrem Bereich erhebli-

che 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 dieseFechnologien 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 fexas Instruments wollen sich endlich auch dem Reverse Enginecring zuwenden. 4. Die Teilmodelle von IBMs Repository Information Model sind nun vonständig, es gibt aber noch immer keine relevan-

ten CASE-Tools im AD/CycleRahmen mit Repository-Manager-Anschluß.

5. Die Objektorientierung dringt in Ergänzung zu klassischen Methoden immer stärker in CASETechnologien ein, 6. Wer heute eine CASE-Umgebung aufbauen will, kauft Tools der zweiten Generation, sogenannte 1-CASE-Produkte öntegrated 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 Codierungl 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. UpperCASE unterstützt die frühen Phasen: Anforderungsdefinition, Analyse und Design.

Diese Zweiteilung der CASEWelt wird in der zweiten Gene-

ration, beim integrierten CASEAnsatz, :iberwunden. 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 UpperCASE-Fools im Einsatz. Dazu gehören die typischen Worksta-

tion-Tools IEWIADW, 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 Codie. rung/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 1-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/CycleAnkündigung des MainframeMarktführers dominiert. Das erste und auch wichtigste inzwischen verfügbare Produkt aus dieser Ankündigung ist der Re-

pository ManagerlMVS. 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 informa-

tionelien Prozesse des Unternehmens ist durch das Reposi. tory Manager Supplied ER-MO. del, IBMs Information Model festgelegt. Dieses Meta-Daten. modell ist die intellektuelle Leistung, mit der 14M einen Defacto-Standard für die Daten-In. tegration 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 Ein. fü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 Genutzte Welche Methoden und Techniken für Reverse Enginecring sind im Ein. satz?

Organisationsstrukturen

und -regeln:

Wie sind Entwicklungspro,jekt-Teams, Mannschaften für die Wartung und das Re. verse Enginecring, für Qualitätssicherung, Methoden und Verfahren (eigene Hauptabteilun@.) in das Organigramm eingeordnet? Welche organisatorischen Regeln gelten für die Einbeziehung der auftraggeben. den Fachabteilungen?

Vorgehensmodell:

Welche Phasen sind für Ent@ wicklungs- und Reverse-Enginecring-Projekte oder Studien festgelegt und welche Ergebnistypen sollen daraus hervorgehen? Welche fir. menspezifischen öder allgemeinen Standards werden

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äts icherung:

Welche Z7ualitätsmerkmale und -maße liegen zugrunde? Mit welchen Verfahren der konstruktiven und analytischeu Qu.alitätssicherung

(Review, Walkthrough,

systematische Testfall-Er-

mittlung und Testdurchfüh-

rung etc.) werden Qualitätsmaße ermittelt beziehungsweise Qualitätskriterien t fülice

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, Co-

como, Prozentsatzverfahren

oder andere)? Welcher

Stand wird bei der Ermitt-

lung der dafür notwendigen

unternehmensspezifischen

Vergleichswerte und Norma-

tive erreicht? Wie werden

Produktivität ermittelt u

Kosten-Nutzen-Ana.

führt?

Aus. und Weiterbüdung:

Know-how ist die Vorausset. zung für die Akzeptanz des Software-Enginecring 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.

Di@,Aufzählung der Gegenstandsbereiche zeigt, daß der Technologiewandel in Entwicklung und Betrieb von Software wesentlich umfassender istg als die Einfüh. rung 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 me.

thodenunabhängige Tool

sollte deshalb auf die unter-

nehmensspezifischen Me.

thoden, Standards und Kon-

ventionen anpaßbar sein-