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.

Software Engineering Environment gestalten, Folge 1:


01.04.1983 - 

Richtige Methodenwahl verlangt gutes Feeling

Die industrielle Softwareproduktion erlebt in den letzten Jahren einen drastischen Wandel. Durch die seit einigen Jahren intensiv betriebene Forschung auf dem Gebiet "Software Engineering" entstand eine Vielzahl von Methoden für alle Phasen der Softwareentwicklung und auch Werkzeugen zur Automatisierung der Methoden. In dieser Serie sollen solche "Umgebungen für Softwareingenieure" vorgestellt und diskutiert werden. Mittelpunkt ist dabei immer die praktische Projektarbeit, die durch die Phasen des "Software Life Cycles" gegliedert wird. An den Phasen wiederum orientieren sich die einzelnen Methoden, deren Einsatz durch Rechner unterstützt werden sollte. Wie diese Unterstützung aussehen kann, welche Hilfen wann sinnvoll sind, wird ebenfalls erörtert und beispielhaft an einem bereits realisierten Software Engineering Environment demonstriert.

Seit 1969 spricht man in der DV-Welt über Software-Engineering. Damals begann man, die Probleme zu studieren, die die Programmentwickler plagten. Man untersuchte große Projekte, die mit einem Fehlschlag endeten, analysierte die "Softwarekrise" und ermittelte Fakten, Statistiken und Erstellungsaufwand umfangreicher Systeme.

Software Engineering ist also eine sehr junge Wissenschaft (falls man dieses Wort überhaupt schon dafür verwenden darf). Doch wurden in den letzten zwölf Jahren einige Erkenntnisse gesammelt, die man heute - auch in der Praxis - nicht mehr ignorieren darf.

Zunächst wurde versucht, Ordnung in die Abwicklung von Projekten zu bringen, "Phasen" kristallisierten sich heraus, die den Entwicklungsprozeß charakterisieren. Zusätzlich zur Definition dieses Phasenmodells, das oft als Software Life Cycle bezeichnet wird, wurden die Tätigkeiten der an der Entwicklung beteiligten Personengruppen in den Phasen, sowie die Produkte, die in den einzelnen Phasen entstehen sollen, inhaltlich genauer festgelegt (siehe Bild 1).

Zwar gibt es weder in der anglikanischen noch in der deutschen Fachwelt eine Einigung auf den Begriffsapparat für Phasen, Tätigkeiten und Produkte. Jedoch weisen die bekannten Modelle /Boe76/, /Fre77/, /Ker81/ nur geringe Unterschiede auf und sind in ihrer Grundidee alle gleich.

Die ersten Phasen dienen zur Festlegung der Anforderungen

("Requirements") an Hard- und Software. Man untersucht, was gemacht werden soll. Danach kommen die Entwurfsphasen; Systemarchitektur und Programmstruktur werden entworfen und zeigen, wie man das Problem lösen will. Im Anschluß daran wird der Entwurf codiert. Den Anschluß bilden die Testphase des Systems und die Betriebs- und Wartungsphase.

Software Engineering im Philosophiestreit

Außer dem Software Life Cycle beschert uns die Forschung auf dem Gebiet Software Engineering eine Vielzahl neuer Methoden, Verfahren und Techniken, die - wenn man sie in den einzelnen Phasen einsetzt - zu qualitativ besseren und vor allem korrekteren Endergebnissen beitragen.

Unter Verwendung anerkannter Grundtechniken, wie Top-down-Entwicklung, Abstraktion, schrittweise Verfeinerung haben sich verschiedene Philosophien entwickelt, die während der Systementwicklung verschiedene Kriterien in den Vordergrund stellen.

Lange Zeit bekämpften sich Anhänger der funktional orientierten Vorgehensweisen, der datenstrukturorientierten und der datenflußorientierten Methoden. Jeder der Methodenerfinder hatte eine Reihe von Beispielproblemen (kleineren oder größeren Umfangs), für die seine Methode die ideale war und andere Methoden (nachweisbar?) zu schlechteren Ergebnissen führten.

Die Problematik für die Masse der Systemanalytiker und Programmierer besteht darin, daß man all diese Methoden nicht in kurzer Zeit beurteilen kann. Ein Einsatz einer neuen Technik muß konsequent über längere Zeiträume in einem Projekt erfolgen - und nicht einmal danach kann man die Güte der Methode sofort beurteilen.

Oft sind die Vorteile, die der Einsatz einer Methode zur Systemanalyse bringt, erst Jahre danach in der Testphase und in der Wartungsphase erkennbar. Was bleibt einem also übrig, als den einen oder anderen Versprechungen zu glauben, und zu hoffen, daß man sich für die geeignetste Methode entschieden hat. Die beruhigende Bemerkung kann man jedoch allen mit auf ihren "Erfahrungsweg" geben: Ganz gleich, für welche Methode man sich entscheidet - der Einsatz einer Methode ist auf jeden Fall gewinnbringender und qualitätssteigender als die Arbeit ohne Methode.

Methodenwechsel in den Phasen

Eine weitere Problematik besteht in der Zuordnung der existierenden Methoden zu bestimmten Phasen des Software Life Cycles. Man muß sich bemühen, eine Methode in der Projektphase einzusetzen, in der sie die beste Wirkung erzielt und rechtzeitig zu einer anderen Methode übergehen, die eine andere Phase besser unterstützt.

In dem letzten Satz liegt das größte Problem, dem wir uns zu stellen haben: Es gibt für alle Phasen der Entwicklung Methoden, von denen jede ihre Stärken und Schwächen hat. Aufgrund der unterschiedlichen Philosophie ist aber ein reibungsloser Übergang von einer Methode zur anderen nicht von vornherein gewährleistet.

Eine weitere Schwierigkeit liegt darin, daß viele der Methoden eben nur Methoden sind - das heißt Denkschemata, Anleitung, Ratschläge zur Durchführung - und nicht automatisiert und durch Werkzeuge unterstützt werden.

Nicht für alle Phasen gut

In der Praxis spielt sich die Einführung meistens so ab: Ein Systemanalytiker oder ein Programmierer wird zu einem Kurs geschickt, lernt die Methoden kennen, löst ein kleines Beispiel und kommt wieder in seine alltägliche Arbeitsumgebung zurück. Vieles von den gelernten Ideen geht wieder verloren, da niemand in der Praxis den Einsatz der Methode kontrolliert und verbessert. Oftmals fehlt auch die Zeit und der Anreiz, die Methode einzusetzen, weil die Ergebnisse nicht unmittelbar zu sehen sind.

Ein weiteres Ziel der Softwareingenieure war es daher, für einige Vorgehensweisen rechnergestützte Werkzeuge zur Verfügung zu stellen, die dem Anwender sofort Feedback liefern, Fehler korrigieren, Auswertungen erstellen und ihn von einigen lästigen Routinetätigkeiten befreien. Zu diesen rechnergestützten Werkzeugen zählen Produkte wie PDL/Cai75/, Aides/Wil80/, PSL/PSA/Teil77/ oder in Deutschland EPOS/Lau80/ und Darts /Keu82/.

Aber die einzelnen Methoden sind noch nicht der Stein der Weisen des Software-Engineerings. In ihrer Vielzahl findet sich keine, die für alle Phasen der Softwareproduktion gleichermaßen geeignet ist.

Deshalb zielen die (vorläufig) letzten Forschungen darauf ab, Methodenbündel oder Systeme zu schaffen. Man greift aus der Vielzahl der bekannten Methoden einige heraus, die

- zusammengenommen den ganzen Software Life Cycle abdecken,

- allgemein genug sind, um bei verschiedensten Problemstellungen angewandt werden zu können,

- spezifisch genug sind, um bei verschiedenen Problemstellungen effizient und hilfreich zu sein,

- in ihren zugrundeliegenden Philosophien so ähnlich sind, daß zwischen den Phasen der Softwareentwicklung kein Umdenkungsprozeß stattfinden muß,

- durch Werkzeuge unterstützt werden, um möglichst viele Tätigkeiten automatisieren zu können.

Die letzten beiden Punkte verdienen noch etwas mehr Aufmerksamkeit: Der Einsatz von neuen Methoden und Techniken stößt sicherlich zunächst einmal auf Ablehnung bei all denen, die jahrelang "gute Programme" ohne all diese neuen Hilfsmittel erstellt haben.

Versucht man, auf einmal fünf neue Methoden einzuführen, so wird diese Ablehnungsschwelle fünfmal überwunden werden müssen. Beschränkt man sich hingegen auf eine Philosophie, die man bei mehreren Methoden anwenden kann, so muß man diese Schwelle nur einmal überwinden.

Nicht zu unterschätzen ist auch der Ausbildungs- und Trainingsaufwand, falls man mehrere, nicht so gut verträgliche Verfahren einführen will. Die oberflächlichen Ideen kann man rasch vermitteln, es bedarf jedoch eines großen zeitlichen Aufwands, Personen in einer Methode so auszubilden, daß sie Detailprobleme effizient zu lösen imstande sind.

Richtiger Einsatz

Der letzte Punkt spricht folgende Thematik an: Eine Methode ist nur so lange gut, wie sie richtig eingesetzt wird. Der richtige Einsatz kann (und sollte!) durch Rechner unterstützt, teilweise sogar erzwungen werden. Prozessoren, die relativ kurzfristig (eventuell interaktiv) Reaktionen auf die bisher durchgeführten Schritte zeigen und die Korrektheit und Vollständigkeit dieser Schritte überprüfen, sind ein wertvolles Hilfsmittel in der Systementwicklung.

Methodensysteme, die alle genannten Forderungen erfüllen, werden in der Literatur häufig als Software Engineering Environments (kurz SE2 oder SEE) bezeichnet. Es handelt sich - wörtlich übersetzt - also um Umgebungen, in denen ein Softwareingenieur sich bei seiner täglichen Arbeit bewegen und wohlfühlen soll; Umgebungen, in denen er all die Hilfsmittel vorfindet, die ihm seine Arbeit erleichtern und ihn gezielt auf den Weg zum fertigen, auslieferbaren System führen.

Das Projektmodell als Rückgrat

Ein Phasenmodell bildet die Grundlage für eine geordnete, planmäßige und zielstrebige Projektabwicklung. Deshalb wird es auch als "Projektmodell" bezeichnet. Es bildet gleichsam das Rückgrat für die systematische Softwareerstellung, die Anleitung, das Rezept für die Durchführung von Musterprojekten.

Das Projektmodell legt fest, welche Methoden und Werkzeuge wann und wie eingesetzt werden. Es teilt die Entwicklung eines Systems in überschaubare und kontrollierbare Abschnitte auf. Es veranschaulicht, welche Personen welche Teilaufgaben bearbeiten und welche Produkte dabei entstehen sollen.

Unser Projektmodell unterscheidet sechs Hauptphasen:

Die erste Phase - die Anforderungsanalyse und -definitionsphase

- geht aus von den Benutzerwünschen. Dabei spielt es keine Rolle, ob bereits eine Vorgabe in Form eines Pflichten- oder Lastenheftes vorliegt oder ob der Benutzer erst gemeinsam mit dem Systemanalytiker die Vorstellungen über das System erarbeitet. Ziel der ersten Phase ist ein strukturiertes Systemmodell, das in konsistenter und vollständiger Weise die technischen Anforderungen an das System enthält.

Die zweite Phase - die Systementwurfsphase - dient zur Festlegung der Architektur eines Softwaresystems. Das Systemmodell aus der ersten Phase wird so umgestaltet und ergänzt, daß eine hierarchische Modulstruktur mit genauer Beschreibung der Schnittstellen zwischen den einzelnen Moduln entsteht. Die Zugehörigkeit von einzelnen Funktionen zu Moduln wird festgelegt, ohne diese Funktionen inhaltlich genauer zu beschreiben. Das entstehende Dokument bezeichnen wir als Systemspezifikation.

Im dritten Abschnitt - der Programmentwurfsphase - werden die bisher nur "angedeuteten" Funktionen der einzelnen Moduln durch Ausformulierung der Algorithmen und Daten in Pseudocode präzisiert. Dabei entsteht eine sehr genaue Codiervorgabe, die Programmspezifikation.

In der vierten Phase - der Implementierungsphase - wird die Programmspezifikation unter Verwendung der Single Source Philosophie in die gewählte Programmiersprache übertragen. Gleichzeitig werden die einzelnen Komponenten auch getestet.

Die getesteten Einzelprogramme bilden dann den Ausgangspunkt für die Systemtestphase. Einige Teile der Testdaten (insbesondere für den Blackbox-Test) können bereits aus den Informationen übernommen werden, die im Systemmodell als Benutzerwünsche enthalten waren.

Ziel: Fehlerarme Betriebsphase

Durch die systematisch durchgeführte Systementwicklung wird der Grundstein für eine lange, fehlerarme Betriebsphase des Systems gelegt. Erst wenn im Laufe der Zeit die Wünsche nach vielen zusätzlichen Funktionen und nach stark verändertem Leistungsspektrum des Systems auftreten, muß man den Entwicklungszyklus von vorne beginnen.

Im folgenden sollen noch einige Bemerkungen zu den Personen gemacht werden, die im Laufe der Zeit mit der Systementwicklung beschäftigt sind (siehe Bild 2).

Für den Manager, der ein Projekt planen und überwachen muß, bietet das Projektmodell ein Gerüst, anhand dessen die Arbeiten in überschaubare Blöcke aufgeteilt werden können; diese "Work Breakdown Structure" kann als Grundlage für exaktere Schätzungen benutzt werden. Zur Kontrolle des Projektfortschritts bietet das Projektmodell natürliche Punkte für Meilensteine an den Schnittstellen der Phasen an. An diesen Punkten können Reviews oder Walkthroughs angesetzt werden.

Fingerspitzengefühl

In der ersten Phase wird die Entwicklung von einem oder mehreren Systemlanalytikern getragen. Ihre Hauptaufgabe ist es, möglichst früh alle Wünsche des Benutzers zu erfahren - auch die, die oftmals dem Benutzer selbst noch nicht so klar sind, daß er sie genau formulieren kann. Dazu muß der Systemanalytiker außer seinem entsprechenden Fachwissen und seiner Erfahrung sehr viel Einfühlungsvermögen, Fingerspitzengefühl und Anpassungsfähigkeit mitbringen.

Die Anforderungen an einen Designer, der die zweite und die dritte Phase bearbeitet, sind anderer Natur. Hier ist es am wichtigsten, ein solides Fachwissen auf dem Gebiet des Software Engineerings zu haben. Vor allem die Entscheidungen, die in der zweiten Phase getroffen werden, beeinflussen die Wartbarkeit, Änderbarkeit und die Zuverlässigkeit des fertigen Systems. Fehlentscheidungen in der Systementwurfsphase verursachen später sehr große Kosten.

Danach übernimmt ein Programmierteam die Arbeit. Genauigkeit bei der Codierung, gute Kommentierung der Programme und gute Kenntnisse der Programmiersprache, der Compiler und der Hardware zeichnen den guten Programmierer aus. Durch diese Eigenschaften kann man den Testaufwand an der Maschine auf ein Minimum reduzieren. Viele mögliche Fehlerquellen wurden in den Vorphasen durch kontrollierte Vorgehensweise ausgeschaltet.

Die Vorteile, die dem Benutzer durch das Projektmodell erwachsen sind vielfältig. Zum ersten erhält er frühzeitig und durchgehend Informationen über "sein" System. Die in den einzelnen Phasen entstehenden Produkte, insbesonders das Systemmodell, sind so gestaltet, daß der Benutzer intensiv über das Endprodukt mitdiskutieren kann. Das Endprodukt, das unter Anwendung dieses Projektmodells entsteht, ist qualitativ wesentlich besser als herkömmliche "gewachsene" Systeme. Benutzerfreundlichkeit und Bedienkomfort werden von Anfang an in die Systeme integriert. Nicht zu unterschätzen ist, daß derartig erstellte Systeme flexibler und dadurch langlebiger sind, Änderungen und Zusatzwünsche des Benutzers lassen sich leichter realisieren.

Durch die Verwendung dieses Projektmodells wird die Erstellung von Softwaresystemen planbar, besser kontrollierbar und dadurch insgesamt kostengünstiger.

Fortsetzung folgt