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.

26.02.1988 - 

Mit einer Prototyping-Produktions-Umgebung Entwurfsfehler frühzeitig erkennen:

CASE Tools helfen Wartungskosten sparen

Die Hälfte der Wartungskosten für Individualsoftware fällt in den

ersten sechs bis zwölf Monaten des Lebenszyklus' an - durch nachträgliche Korrektur von Fehlern bei der Analyse und der Spezifikation.

Georg Barkow* beschreibt, wie durch Einsatz von Computer-Aided Software-Engineering (CASE) solche Folgekosten vermeidbar werden.

Die Anwendungsentwicklung unterliegt heute einem starken Wandel. Anwendungssysteme können mit den nunmehr verfügbaren Werkzeugen, Datenbank-Managementsystemen, Methoden und Verfahren komfortabler, schneller und mit besserer Qualität entwickelt werden.

Auf dieser Basis entsteht möglicherweise eine "Anwendungsentwicklungs-Synergie". Jedoch erst ein konzertierter Einsatz aller modernen Komponenten (Prototyping-Vorgehensweise, integrierte Methoden, CASE-Werkzeuge, relationale Datenbank-Managementsysteme) führt zum gewünschten Erfolg.

CASE-Werkzeuge ermöglichen den schnellen und komfortablen Entwurf eines Modells von dem künftigen Anwendungssystem. In mehreren iterativen Schritten kann mit dem Benutzer zusammen dieses Modell weiter bearbeitet und somit seinen Wünschen entsprechend ausgestattet werden. Zum Teil ist es möglich, an einem ablauffähigen Modell zu arbeiten, was natürlich dem Verständnis des Benutzers am besten entspricht und somit die Effizienz der Zusammenarbeit besonders positiv beeinflußt.

Die diesen Werkzeugen zugrunde liegenden Entwicklungsmethoden wie zum Beispiel Structured Analysis, Entity/Relationship-Modelling, Data-Normalization und Modular Design, haben sich inzwischen in der Praxis bewährt und auch Einzug gehalten in die Anwendungsentwicklungs-Abteilungen. Vorgehensweisen für die Anwendungsentwicklung, die diesem Komfort der Werkzeuge und Methoden in besonderer Weise entsprechen, werden diskutiert und auch schon praktiziert.

Die veränderte Vorgehensweise ermöglicht es, einen Prototyp des zukünftigen Anwendungssystems anzufertigen und die partizipative Zusammenarbeit zwischen Anwendungsentwickler und Benutzer. Der Begriff Prototyping ist inzwischen die geläufige Bezeichnung für diese neue Vorgehensweise.

Prototyping einzuführen heißt, eine bestehende neue Ordnung zu ersetzen. Das bedeutet also keineswegs, von einem geordneten Entwicklungsprozeß Abschied zu nehmen, denn viele Standards und auch Methoden und Verfahren können oder müssen bestehen bleiben. Auch beim Prototyping sollte die Entwicklung geordnet ablaufen, um ein Chaos zu verhindern.

Der Hauptunterschied in den bei den Ordnungen besteht darin, daß viele Aktivitäten, in denen detaillierte Spezifikationen erarbeitet werden, beim Prototyping durch iterative Arbeiten am Entwicklungsmodell (Prototyp) ersetzt werden können.

Dies bedeutet eine Arbeitserleichterung in dem offensichtlich schwierigen Prozeß, die Bedürfnisse der Benutzer wirklich in Erfahrung zu bringen und auch zu dokumentieren.

Es ist erfahrungsgemäß ausgesprochen schwierig, eine genaue Spezifikation für ein komplexes Anwendungssystem herzustellen. Die Anwendungsentwicklung scheint eine der wenigen Disziplinen zu sein, in der man meint, eine Entwicklung ohne ein praktisches Modell durchführen zu können. Die Benutzer brauchen ein Hilfsmittel, um ihre Bedürfnisse überhaupt erst erkennen zu können. Und die beste Hilfe ist nun einmal ein Beispiel aus der realen Welt in Form eines Modells.

In der traditionellen Anwendungsentwicklung ist der Benutzer in den Anfangsphasen beteiligt, aber nach der Fertigstellung der Spezifikation hört er lange Zeit nichts mehr von den Entwicklern. Erst beim Testen und Erproben wird er wieder hinzugezogen. Dann ist es aber meistens zu spät, grundlegende Abweichungen von seinen Vorstellungen mit wirtschaftlich vertretbarem Aufwand zu korrigieren.

Boehm, Phister und DeMarco haben die Kosten aus vielen Anwendungen analysiert. Laut DeMarco sind die meisten Änderungen und Ergänzungen nicht auf Erweiterungen eines Anwendungssystems zurückzuführen, sondern auf Dinge, die bei der Systemanalyse und der Spezifikation vergessen worden sind oder falsch gemacht wurden.

Innerhalb der ersten sechs bis zwölf Monate der Einsatzdauer eines Anwendungssystems steigen die Kosten für die Wartung rapide an. Dieser Buckel nimmt 15 Prozent des Lebenszyklus' eines Anwendungssystems ein, er stellt aber 50 Prozent der Wartungskosten dar. Alle Möglichkeiten, den Benutzer partizipativ am Entwicklungsprozeß zu beteiligen, um seine Anforderungen und Wünsche optimal berücksichtigen zu können, sollten ergriffen werden: Die Hälfte der Wartungskosten steht zur Disposition.

Ein weiteres Problem sind Produktivitätsengpässe. In einem Maschinenbau-Unternehmen hatte die klassische Projektabwicklung zu einem Anwendungsstau von 30 Mannjahren geführt. Von 30 Mitarbeitern der Entwicklungsabteilung waren nur noch zehn mit Neuentwicklung befaßt.

Daraus ergab sich die Alternative, die bisherige Entwicklungsphilosophie beizubehalten und mit komfortableren Werkzeugen und neuen Methoden die Produktivität zu erhöhen oder mit einer neuen Vorgehensweise, einem komfortablen Datenbanksystem und einer Sprache der vierten Generation einen neuen Weg einzuschlagen. Die Firma hat sich für den zweiten Weg entschieden. Das Ergebnis kann sich sehen lassen:

Von den 30 Mitarbeitern können sich jetzt wieder 25 mit Neuentwicklung beschäftigen.

Zufriedene Benutzer und enorme Produktivitätssteigerungen sind das Resultat einer Prototyping-Produktions-Umgebung (PPU), also einer Verbindung von Prototyping-Vorgehensweise, effizienten Methoden sowie mächtigen und komfortablen Entwicklungswerkzeugen auf Grundlage eines relationalen Datenbank-Managementsystems.

Moderne Produkte für die Professionelle Anwendungs-Entwicklung (PAE) und für die Individuelle Daten-Verarbeitung (IDV) ermöglichen zwar eine veränderte Vorgehensweise. Bevor ein Produkt jedoch in eine Prototyping-Produktions-Umgebung eingebunden und genutzt werden kann, muß genau untersucht werden, ob es den hohen Anforderungen einer Prototyping-Vorgehensweise überhaupt entspricht.

Das Dictionary ist die verbindende Komponente

Es werden nicht nur hohe Anforderungen in bezug auf Komfort gestellt, sondern auch in puncto Schnelligkeit und Integrität. Das heißt, alle Werkzeuge müssen über ein Dictionary-System miteinander verbunden sein.

Folgende Komponenten müssen in integrierter Form vorhanden sein: ein Anewendungsgenerator, ein Dialogstrukturgenerator sowie ein Masken- und Listengenerator, darüber hinaus eine Sprache der vierten Generation, SQL und eine Cobol-Schnittstelle. Hinzu kommen folgende Komponenten, mit denen zusammen erst ein sicherer und komfortabler Entwicklungsprozeß gewährleistet ist: ein Analyse/Entwurfs-Arbeitsplatz (mit Grafikunterstützung) sowie praktikable integrierbare Methoden, ein Prototyping-Vorgehensmodell mit Driver und eine leistungsfähige Hardware.

Eine weitere Steigerung bieten dann solche Systeme, die mit der gleichen Benutzeroberfläche auf verschiedenen Rechnertypen (PCs, Minis, Hosts) eingesetzt werden können. Ein Netzwerk mit verteilten Entwicklungsdatenbanken wäre dann die Spitze des Komforts.

Die meisten Software-Produktions-Umgebungen (SPUs) bestehen aus nichtintegrierten Werkzeugen. Oft haben sie keine gemeinsame Entwicklungsdatenbank und kein gemeinsames Dictionary. Außerdem entsprechen die Benutzeroberflächen meist nicht dem Stand der Kunst.

Bei Systemen, die ein Data Dictionary als Basissystem benutzen, ist es oft nicht möglich, verschiedene Komponenten des Anwendungssystems formulargestützt und im Zusammenhang (zum Beispiel Masken mit Feldern, Formaten, Prüfregeln und Bezügen zu Datenstrukturen) einzugeben. Bridge-Prozeduren müssen dafür sorgen, daß die Daten zwischen den nichtintegrierten Werkzeugen ausgetauscht werden. Darüber hinaus läßt es sich kaum umgehen, redundante Informationen zu speichern, und oft ist es nicht möglich, Auswertungen einzelner Elemente über alle Komponenten hinweg durchzuführen.

Die Basis für eine Prototyping-Produktionsumgebung muß ein aktives und integriertes Data-Dictionary-System bilden, das Bestandteil des zugrunde liegenden Datenbank-Managementsystems ist. In einem traditionellen Vorgehensmodell für die professionelle Anwendungs-Entwicklung werden folgende Phasen durchlaufen: Anforderungsdefinition, Anforderungsanalyse, fachlicher und DV-Systementwurf, Programmierung und Integration, Erprobung und Einführung sowie Stabilisierung und Optimierung.

Zahlreiche neuere Vorgehensmodelle beinhalten diese oder eine ähnliche Phaseneinteilung. Gekennzeichnet sind diese Phasenmodelle dadurch, daß nach einem Vorlauf mit Definition der Anforderungen, Aufwandsschätzung und Ist-Analyse eine detaillierte fachliche Spezifikation des neuen Anwendungssystems angefertigt wird. Diese Fachspezifikation wird umgesetzt in eine DV-Spezifikation und in Programmvorgaben. Danach erfolgen Realisierung, Einführung und Einbettung des neuen Systems in das Systemumfeld.

Die Entwicklungsaufgaben der Vorgehensmodelle lassen sich klassifizieren in Software-Entwicklungsaufgaben (SE), Softwareumfeld-bezogene Aufgaben (SU), deklarative Aufgaben (DK), also Begründungen, Entscheidungsfindung, Vergleiche oder Studien sowie Projekt-Management-Aufgaben (PM). In einem Prototyping-Vorgehensmodell müssen nur die Software-Entwicklungsaufgaben (SE) anders und neu konzipiert werden. Die SU-, DK- und PM-Aufgaben bleiben inhaltlich bestehen. Sie werden in einem Prototyping-Vorgehensmodell nur in eine neue Struktur gebracht.

Dieses Prototyping-Vorgehensmodell besteht aus Anforderungsdefinition, Kurzanalyse (Rapid Analysis), Prototyping (Rapid Prototyping), Detailentwicklung (Tuning), Datenbbankintegration, Systemintegration und -erprobung sowie Stabilisierung und Optimierung.

In der Anforderungsdefinition wird der Anforderungskatalog erstellt. Dann muß der Datenbedarf des Anwendungssystems ermittelt und definiert werden. Die Kurzanalyse betrifft den Handlungsplan, der aus der Darstellung von Haupthandlungen (fachlichen Hauptfunktionen), Datenspeichern, Datenflüssen und Nachbarsystemen des zukünftigen Anwendungssystems besteht. Als Methode wird die Strukturierte Systemanalyse (Structured Analysis) verwendet.

Das Prototyping entwirft ein erstes Modell des zukünftigen Anwendungssystems. Die erste Version dieses Modells wird als Anforderungsmodell bezeichnet, die letzte Version in dieser Phase als Entwurfsmodell. Es werden die Schemata der Relationen entworfen, normalisiert und mit ihren Beziehungen dargestellt (Entity/Relationship, Data-Normalization). Das Anforderungsmodell ist als Prototyp ablauffähig und kann weiter bearbeitet werden. Der Zyklus wird mehrfach bis zur Erreichung eines definierten Ziels (Entwurfsmodell) durchlaufen.

Bei der Detailentwicklung (Tuning) werden die Einzelheiten des Anwendungssystems (zum Beispiel Detailhandlungsbeschreibungen, Prüfregeln) entworfen und realisiert. Wenn das Zielsystem nicht identisch mit dem Entwicklungssystem ist, wird das Entwurfsmodell für das Zielsystem umgesetzt. Die anschließende Datenbankintegration faßt alle Aktivitäten zusammen, die erforderlich sind, um die Datenstrukturen des Anwendungssystems (Tabellen) und der Datenfelder in das Unternehmensdatenmodell zu integrieren.

Organisation im Fachbereich den Veränderungen anpassen

Danach wird das System in das Umfeld integriert und erprobt. Die Fachbereichsorganisation paßt man den Veränderungen an. Abschließend werden die Systemleistungen gemessen sowie Optimierungsmaßnahmen durchgeführt und Stand-by-Aktivitäten für den Fachbereich in Angriff genommen.

Die Umstellung der Vorgehensweise, die Beschaffung geeigneter Anwendungsentwicklungswerkzeuge, die Organisation von Prototyping-Szenarien, die Einrichtung von Prototyping-Arbeitsplätzen und einer PPU sowie die Einführungsaktivitäten erfordern natürlich einen erheblichen zeitlichen und kostenmäßigen Aufwand. Bevor eine PPU für ein Großprojekt verwendet wird, sollten in mehreren kleinen Projekten Erfahrungen und Erfahrungswerte in bezug auf Speicherplatz, Antwortzeitverhalten, Durchlaufverhalten und Praktikabilität gesammelt werden.