Abstrakt

Konzepte des Software Engineering

Diese Arbeit gibt einen Rückblick auf die Entstehung der ingeneurmäßigen Softwareentwicklung - des Software Engineering - und beschreibt die Konzepte in groben Zügen. Es werden die Produktivitäts- und Qualitätsziele sowie die Konzepte zur Zielerreichung aufgeführt. In diesem Rahmen werden die allgemeinen Prinzipien beschrieben und erläutert, was unter Methoden, Sprachen und Werkzeugen zu verstehen ist. Es wird aufgezeigt, wie durch standardisiertes Vorgehen mit Hilfe von Phasenmodellen vorgegangen wird. Jede Phase des Software-Entwicklungsprozesses wird überblicksartig beschrieben und ihre Problematik hervorgehoben. Diese Arbeit schließt mit Hinweisen auf die Defizite der Disziplin in Wissenschaft und Praxis.

Das Software Engineering bildet ein so komplexes Thema, dass die einzelnen Themen im Rahmen dieser Arbeit nicht ausführlich behandelt werden können. Es gibt eine Vielfalt einander überlappender, sich ergänzender oder sich ausschließender Methoden, Werkzeuge und Sprachen. Es ist nicht möglich, sie alle in dieser Arbeit darzustellen. Auf phasenspezifische Prinzipien und manche Aspekte, wie z.B. Menschenführung, Kostenschätzung, Produktivitätsmessung, Planung und Qualitätssicherung wird in dieser Arbeit ebenfalls nicht eingegangen.

2

Inhaltsverzeichnis

  Abstrakt  2

  Inhaltsverzeichnis  3

1.  Einleitung  5

2.  Zum Begriff des Software Engineering  5

2.1.  Entstehung und Definition.  5

2.2.  Gegenstand der Disziplin.  7

2.3.  Arbeitsweise eines Ingenieurs  8

3.  Ziele des Software Engineering  9

3.1.  Qualität  9

3.2.  Produktivität.  11

4.  Konzepte des Software Engineering  11

4.1.  Allgemeine Prinzipien  11

4.1.1.  Maximale konstruktive Qualitätssicherung.  12

4.1.2.  Entwicklungsbegleitende, integrierte Qualitätssicherung.  12

4.1.3.  Frühzeitige Fehlererkennung  12

4.1.4.  Konstruktive Voraussicht  13

4.1.5.  Abstraktion.  13

4.1.6.  Strukturierung  13

4.1.7.  Modularisierung  14

4.1.8.  Hierarchisierung.  15

4.1.9.  Lokalität  15

4.1.10.  Standardisierung.  16

4.1.11.  Mehrfachverwendung  16

4.1.12.  Integrierte Dokumentation  17

4.2.  Methoden.  18

4.3.  Sprachen und Programmierstil  18

4.4.  Werkzeuge  21

4.5.  Strukturierung der Entwicklung durch standardisiertes Vorgehen  23

4.5.1.  Phasen des Software-Entwicklungsprozesses  23

4.5.1.1.  System Engineering als Voraussetzung des Software Engineering  23

4.1.1.2.  Anforderungsdefinition bzw. Spezifikation  24

4.5.1.3.  Entwurf  28

3

4.5.1.4.  Implementierung  31

4.5.1.5.  Test.  32

4.5.1.6.  Betrieb und Wartung.  34

4.5.2.  Phasenmodelle  35

4.5.2.1.  Sequentielles Wasserfallmodell  35

4.5.2.2.  Klassisches Wasserfallmodell.  35

4.5.2.3.  Verifikations-Modell (V-Modell)  36

4.5.2.4.  Sichten-Modell  36

4.5.2.5.  Spiral-Modell.  37

4.5.3.  Alternativen bzw. Ergänzung der Phasenmodelle  37

4.5.3.1.  Prototyp-Entwicklung  38

4.5.3.2.  Entwicklungsaktivitäten durch Endbenutzer.  39

5.  Defizite in Wissenschaft und Praxis  40

6.  Schlußbetrachtung  41

  Literaturnachweis.  42

4

1. Einleitung

Diese Arbeit gibt einen Rückblick auf die Entstehung des Software Engineering und beschreibt die Konzepte der Disziplin in groben Zügen. Zunächst wird der Begriff Software Engineering definiert. Anschließend werden die Produktivitäts- und Qualitätsziele sowie die Konzepte zur Zielerreichung aufgeführt. Es werden allgemeine Prinzipien überblicksartig beschrieben, anschließend wird erläutert, was unter Methoden, Sprachen und Werkzeugen zu verstehen ist. Es wird aufgezeigt, wie mit Hilfe von Phasenmodellen standardisiert vorgegangen wird. Jede Phase des Software-Entwicklungsprozesses wird überblicksartig beschrieben und ihre Problematik hervorgehoben. Diese Arbeit schließt mit kurzen Hinweisen auf die Defizite der Disziplin in Wissenschaft und Praxis.

Das Software Engineering bildet ein so komplexes Thema, daß die obengenannten Themen im Rahmen dieser Arbeit nicht angemessen ausführlich behandelt werden können. Auf phasenspezifische Prinzipien kann nicht eingegangen werden. Es gibt eine Vielfalt einander überlappender, sich ergänzender oder sich ausschließender Methoden, Werkzeuge und Sprachen. Es ist nicht möglich, sie alle in dieser Arbeit darzustellen. Auf manche Aspekte, wie z.B. Kostenschätzung, Produktivitätsmessung, Planung, Menschenführung und Qualitätssicherung, kann in dieser Arbeit ebenfalls nicht eingegangen werden. Die Auswahl der behandelten Aspekte des Software Engineering stellt keine Wertung dar. Den in dieser Arbeit nicht berücksichtigten Aspekten müßte mindestens die gleiche Aufmerksamkeit gewidmet werden wie den behandelten.

2. Zum Begriff des Software Engineering

2.1. Entstehung und Definition

In der Frühzeit der Computerentwicklung (ca. 1942 - 1948) gab es bei der Software-Entwicklung allgemein keine Probleme, denn

-die Programme behandelten eine eingeschränkte Problemklasse und griffen nicht unmittelbar in betriebliche Abläufe ein.

-Programme waren lediglich Nachbildungen von Algorithmen, die aus der Mathematik bekannt waren.

-Konstrukteure, Programmierer und Anwender hatten durchweg die gleiche Vorbildung und bildeten eine im wesentlichen geschlossene Gruppe.

In diesem Szenario gab es keinen Bedarf für Software Engineering. Die bekannten Techniken aus der Mathematik oder der Elektrotechnik waren ausreichend. Die Problematik

5

lag allein auf dem Hardware-Sektor. Aufgrund der Fortschritte auf dem Hardware-Sektor ist es aber spätestens seit den 60er Jahren möglich, Software-Systeme zu entwickeln, die so komplex sind, daß eine bloße Umsetzung mathematischer Algorithmen in Computerprogramme nicht mehr ausreicht. ¹ Es kristallisieren sich seither folgende Hauptprobleme bei der Entwicklung und dem Einsatz von Software heraus:

-Die ausgelieferte Software enthält zu viele Fehler, sie ist teilweise sogar unbrauchbar.

-Die Anwender sind mit der Software unzufrieden. Sie entspricht nicht ihren Anforderungen und läßt sich nur mit erheblichem Aufwand anpassen oder ändern. Hierdurch entstehen umfangreiche Kosten in der Wartungsphase.

-Die kostenmäßigen sowie zeitlichen Kalkulationen einer Software-Entwicklung sind nur sehr vage möglich. Sie führen oft zu erheblichen Termin- und Budgetüberschreitungen. Die Software-Entwicklung und Wartung wird zu teuer. 2

Mittlerweile hängen sogar Menschenleben und große ökonomische Werte vom korrekten Funktionieren von Software ab. Deshalb und aus obengenannten Gründen ist es nötig, sich mit dem Beherrschen der Komplexität, dem Management, der Produktivitätssteigerung und vor allen Dingen mit der Qualitätssicherung für Software-Produkte zu befassen. 3

Als sich die Fachwelt Ende der 60er Jahre darüber klar wurde, daß die Software-Entwicklung in einer Krise steckte, wurde die Fachrichtung Software Engineering initiiert. F.L. Bauer trug auf einer Konferenz der NATO 1968 in Garmisch-Partenkirchen im wesentlichen folgende Gedanken vor:

Wenn die Entwicklung von komplexen Software-Systemen unsystematisch geschieht und wenn andererseits sich die Ingenieurwissenschaft traditionell mit der Entwicklung komplexer Systeme beschäftigt, sollte man versuchen, auch Software-Systeme nach ingenieurmäßigen Prinzipien und Regeln zu erstellen. Das neue Schlagwort "Software Engineering" wurde im Nachgang zu der obengenannten Konferenz begeistert aufgenommen und hat seitdem seinen festen Platz in der Informatik. 4

1 vgl. Klaeren, S. 22

2 vgl. Spillner, S. 48

3 vgl. Dumke, S. 4

4 vgl. Klaeren, S. 22

6

Es gibt für den Begriff "Software Engineering" zahlreiche verschiedene Definitionen, z.B.

"...die Anwendung eines systematischen, disziplinierten, quantifizierbaren Ansatzes auf Entwicklung, Betrieb und Wartung von Software, d.h. die Anwendung der Ingenieurkunst auf Software." 5

"...das Aufstellen und Benutzen fundierter, ingenieurmäßiger Prinzipien, um auf ökonomische Weise Software zu erstellen, die zuverlässig ist und effizient auf realen Maschinen läuft." 6

Software Engineering ist eine Disziplin, die mit ökonomischem Vorgehen und ingenieurmäßigen Mitteln den Entwickler dabei unterstützt, zielgerichtet qualitativ hochwertige Software herzustellen und zu pflegen. 7

Zwar werden etliche noch umfassendere Definitionen vorgeschlagen, alle aber betonen die Notwendigkeit einer ingenieurmäßigen Software-Entwicklung.

2.2. Gegenstand der Disziplin

Der Begriff Software ist ca. in den Jahren 1959/1960 aufgekommen. Er wird für Systemprogramme wie Compiler, Ein- und Ausgabesysteme usw. sowie auch für Anwenderprogramme verwendet. Der heutige Sprachgebrauch bezieht zu den eigentlichen Programmen, d.h. zum Quell- und Objektcode, auch noch die dazugehörige Dokumentation und Anwendungsregeln mit ein. 8

Ein wesentlicher Unterschied zur Hardware und auch zu anderen industriellen Gütern ist der abstrakte Charakter von Software. Dieser Unterschied hat wichtige Konsequenzen für den Herstellungsprozeß von Software im Vergleich zu anderen industriellen Gütern. ⁹ Der häufig gebrauchte Begriff "Software-Produktion" vermittelt leicht einen falschen Eindruck. Die industrielle Fertigung stellt mehrere oder viele Stücke eines bestimmten Produkts in Serien-oder Massenfertigung her. Gerade letzteres ist aber bei der Software-Entwicklung ein zu vernachlässigender Vorgang. Das Problem besteht vielmehr darin, das "Produkt" Software zu entwickeln, die Herstellung von Kopien ist dagegen eine triviale Angelegenheit. Der Software-Erstellungsprozeß ist in dieser Hinsicht eher mit der Produktion von Büchern oder Filmen vergleichbar als mit der Produktion von Rechnern, Kühlschränken oder Autos. Wenn der Ausdruck "Software-Produktion" gebraucht wird, so muß sich dieser sinnvollerweise auf die Ersterstellung beziehen. Diese ist aber von ihrem Wesen her vor allem ein Entwurfs-,

5 IEEE Standard Glossary of Software Engineering Terminologie, zit. in Klaeren, S. 22

6 Pressman, S. 12

7 vgl. Naur, zitiert in Wallmüller, S. 3

8 vgl. Gewald u.a., S 22, vgl. Platz, S. 18

9 vgl. Gewald u.a., S. 22, 23

7

Entwicklungs-, Konstruktionsvorgang und kein Fertigungsvorgang. ¹⁰ Aus diesen Gründen wird im folgenden stets von Software-Entwicklung gesprochen.

Ein weiterer Unterschied, der auf die abstrakte Natur von Software zurückzuführen ist, ist die Tatsache, daß Software im Gegensatz zu anderen industriellen Gütern nicht abnutzt. Sie kann allerdings durch Ergänzungen und Änderungen so fehlerhaft werden, daß sie unbrauchbar oder wertlos wird.

Entgegen anderen industriellen Gütern hat das Produkt Software überaus vielfältige Einsatz-und Anwendungsgebiete. Abgesehen von der noch relativ homogenen System-Software führt dieses zu einer außerordentlich großen Heterogenität der Software-Produkte. Es gibt eine nahezu unüberschaubare Vielfalt von verschiedenen Programmen für unterschiedliche Branchen. Die Software paßt die Hardware an die unterschiedlichen Aufgaben der EDV an.

Diese kurze Skizzierung der Andersartigkeit der Software zeigt an, daß Software Engineering keine bloße Kopie von anderen Ingenieurdisziplinen sein kann. ¹¹ Es ist der Aufbau einer auf die speziellen Gesetzmäßigkeiten und Gegebenheiten von Software ausgerichteten Disziplin nötig. Das bedeutet aber nicht, daß das Software Engineering nicht von anderen Ingenieurdisziplinen lernen könnte. Die Disziplin Software Engineering orientiert sich auf jeden Fall in der grundsätzlichen Vorgehensweise an den traditionellen Ingenieurdisziplinen. 12

2.3. Arbeitsweise eines Ingenieurs

Unter Bezug auf die Encyclopädia Britannia hat Klaeren die Arbeitsweise eines Ingenieurs wie folgt definiert:

"... die schöpferische Anwendung wissenschaftlicher Prinzipien auf Entwurf und Entwicklung von Strukturen, Maschinen, Apparaten oder Herstellungsprozessen im Hinblick auf seine gewünschte Funktion, Wirtschaftlichkeit und Sicherheit von Leben und Eigentum..." 13

Ingenieurmäßig orientierte Software-Entwicklungsorganisationen müssen sowohl die Planung und Durchführung von Projekten auf Basis von Modellen als auch die Entwicklung von besseren Modellen auf der Basis von Erkenntnissen aus Entwicklungsprojekten unterstützen. Dazu ist es notwendig, jedes Entwicklungsprojekt wie folgt zu planen und durchzuführen:

10 vgl. Gewald u.a., S. 22,23

11 vgl. Bauer (1972) zitiert in Gewald u.a., S. 25

12 vgl. Gewald u.a., S. 25

13 Klaeren, S. 22

8

Produktivitätsziele definieren,

Qualitätsziele definieren,

Projektplan erstellen, 14

Reihenfolge des Arbeitsablaufes festlegen (Phasenkonzept), 15

Auswahl der Methoden und Werkzeuge,

Ausführen des Projekts entsprechend dem gewählten Plan. 16

3. Ziele des Software Engineering

3.1. Qualität

Qualitätssicherung ist in allen Ingenieurberufen eine wesentliche Komponente des Erstellungsprozesses. ¹⁷ Am Anfang einer Software-Entwicklung müssen eindeutige Qualitätsziele festgelegt und Prioritäten gesetzt werden. Welches Maß an Qualität verlangt werden muß, hängt von der Art der Aufgaben und Ziele ab, insofern gibt es keine absolute, sondern nur eine relative Qualität. ¹⁸ Als Qualitätssicherungsmaßnahmen werden alle Maßnahmen zur Erzielung der geforderten Qualität bezeichnet. ¹⁹ Durch eine entwicklungsbegleitende Qualitätssicherung muß dann die Einhaltung dieser Ziele gewährleistet werden. Die Qualitätsmerkmale sind jedoch schwer quantifizierbar. Es fehlen ausgewogene Methoden und Maße, um Qualitätsmerkmale von Software zu messen. ²⁰ In der Praxis stößt man oft auf ungelöste Probleme, die darauf zurückzuführen sind, daß eine eindeutige Definition und objektive Bewertung der Qualität eines Software-Produktes nicht möglich ist. ²¹ In der Literatur werden etliche Qualitätsmerkmale für Software genannt. Die wichtigsten, in der Literatur am meisten genannten Eigenschaften sind: ²² Korrektheit,

Zuverlässigkeit,

Wartungsfreundlichkeit (Lesbarkeit, Erweiterbarkeit, Testbarkeit), Effizienz und Portabilität.

Korrektheit wird als das wichtigste Qualitätsmerkmal betrachtet. Eine in hohem Maße fehleranfällige Software ist praktisch wertlos, auch wenn ihre anderen Qualitätsmerkmale

14 vgl. Rombach, S. 269

15 vgl. Balzert (1985), S.12

16 vgl. Rombach, S. 269

17 vgl. Rombach, 267

18 vgl. Schulze, S. 2238

19 vgl. Hesse, S. 119

20 vgl. Schröter, S. 97, vgl. Dunn, S. 27ff, vgl. Sommerville, S. 331

21 vgl. Pomberger (1993), S. 9

22 vgl. Balzert (1992), S. 11, vgl. Franz, S. 9ff, vgl. Trauboth, S. 25, vgl. Dunn, S. 17 ff, vgl. Pomberger (1993), S. 9, vgl. Asam, S. 25, vgl. Wieken, S. 87 f, vgl. Klaeren, S. 23

9