Konzepte des Software Engineering (Stand 1995)

Inhaltsverzeichnis

Abstrakt

1. Einleitung

2. Zum Begriff des Software Engineering
2.1. Entstehung und Definition
2.2. Gegenstand der Disziplin
2.3. Arbeitsweise eines Ingenieurs

3. Ziele des Software Engineering
3.1. Qualität
3.2. Produktivität

4. Konzepte des Software Engineering
4.1. Allgemeine Prinzipien
4.1.1. Maximale konstruktive Qualitätssicherung
4.1.2. Entwicklungsbegleitende, integrierte Qualitätssicherung
4.1.3. Frühzeitige Fehlererkennung
4.1.4. Konstruktive Voraussicht
4.1.5. Abstraktion
4.1.6. Strukturierung
4.1.7. Modularisierung
4.1.8. Hierarchisierung
4.1.9. Lokalität
4.1.10. Standardisierung
4.1.11. Mehrfachverwendung
4.1.12. Integrierte Dokumentation
4.2. Methoden
4.3. Sprachen und Programmierstil
4.4. Werkzeuge
4.5. Strukturierung der Entwicklung durch standardisiertes Vorgehen
4.5.1. Phasen des Software-Entwicklungsprozesses
4.5.1.1. System Engineering als Voraussetzung des Software Engineering
4.1.1.2. Anforderungsdefinition bzw. Spezifikation
4.5.1.3. Entwurf
4.5.1.4. Implementierung
4.5.1.5. Test
4.5.1.6. Betrieb und Wartung
4.5.2. Phasenmodelle
4.5.2.1. Sequentielles Wasserfallmodell
4.5.2.2. Klassisches Wasserfallmodell
4.5.2.3. Verifikations-Modell (V-Modell)
4.5.2.4. Sichten-Modell
4.5.2.5. Spiral-Modell
4.5.3. Alternativen bzw. Ergänzung der Phasenmodelle
4.5.3.1. Prototyp-Entwicklung
4.5.3.2. Entwicklungsaktivitäten durch Endbenutzer

5. Defizite in Wissenschaft und Praxis

6. Schlußbetrachtung

Literaturnachweis

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.

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 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.^[1] 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]

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.^[9] 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-, Entwicklungs-, Konstruktionsvorgang und kein Fertigungsvorgang.^[10] 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.^[11] 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:

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.^[17] 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.^[18] Als Qualitätssicherungsmaßnahmen werden alle Maßnahmen zur Erzielung der geforderten Qualität bezeichnet.^[19] 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.^[20] 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.^[21] In der Literatur werden etliche Qualitätsmerkmale für Software genannt. Die wichtigsten, in der Literatur am meisten genannten Eigenschaften sind:^[22] Korrektheit, Zuverlässigkeit, Benutzerfreundlichkeit (Adäquatheit, Erlernbarkeit, Robustheit), 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 ausreichend sind.^[23] Unter Korrektheit wird verstanden, daß das Programm übereinstimmt mit der Spezifikation^[24] bzw. dem Pflichtenheft.^[25]

Zuverlässigkeit: Ein Programm kann als zuverlässig angesehen werden, wenn die Fehlerrate, d.h. die Wahrscheinlichkeit, daß in einem bestimmten Zeitintervall ein Fehler auftritt, gering ist.^[26]

Benutzerfreundlich ist ein Programm, wenn die vom Anwender erforderlichen Eingaben sich auf das Notwendigste beschränken. Das Programm sollte dem Anwender eine flexible Dateneingabe ermöglichen und Plausibilitätskontrollen der eingegebenen Daten durchführen. Einheitlichkeit, Klarheit und Einfachheit der Benutzerführung ist in dialogorientierten Programmsystemen besonders bedeutend. Die Leistungsfähigkeit sollte unter Berücksichtigung der eventuellen Erweiterbarkeit den Wünschen des Kunden angepaßt sein. Die Ergebnisse sollten übersichtlich und gut strukturiert ausgegeben werden Das Programm soll flexibel bezüglich des Umfangs und der Art der Präsentation der Ergebnisse sein. Fehlermeldungen sollen für den Benutzer verständlich aufbereitet sein.^[27] Das Programm soll gut erlernbar sein. Die Erlernbarkeit hängt von der Benutzerführung und der Benutzerdokumentation ab. Das Programm soll robust sein, d.h. die Eigenschaft haben, die Auswirkungen von Bedienungsfehlern, falschen Eingabedaten und Hardware-Fehlern abzuschwächen.

Wartungsfreundlich ist ein Programm, wenn es zur Lokalisierung von Fehlerursachen und Durchführung von Korrekturen geeignet ist und wenn es sich leicht verändern oder erweitern läßt. Die Wartungsfreundlichkeit hängt ab von der Lesbarkeit, Erweiterbarkeit, Testbarkeit,^[28] Änderbarkeit und Korrigierbarkeit eines Programmsystems.

Effizienz bedeutet, daß ein Programm in der Lage ist, seinen Zweck unter bestmöglicher Ausnutzung aller Ressourcen, d.h. Zeit, Speicherplatz, Übertragungskanäle und periphere Einheiten, zu erfüllen.^[29]

Unter Portabilität wird die Leichtigkeit verstanden, mit der ein Programmsystem auf andere Rechner übertragbar ist.^[30]

Die gleichzeitige Realisierung einiger Qualitäts-Anforderungen an Software-Produkte führt zu Konfliken unter den Qualitätsmerkmalen, z.B. verringert zusätzliche Effizienz oft die Portabilität, die Verständlichkeit und somit die Wartbarkeit. Manchmal wird anstelle einer höheren Programmiersprache Assembler verwendet, um auf Kosten der Lesbarkeit Effizienzverbesserungen zu erhalten.^[31]

Bessere Qualität soll durch konstruktive Qualitätssicherung und analytische Qualitätsprüfung erreicht werden. Während es bei der konstruktiven Qualitätssicherung darum geht, Fehler im Entwicklungsprozeß zu vermeiden, geht es bei der analytischen Qualitätsprüfung darum, die vorhandene bzw. nicht vorhandene Qualität zu prüfen.^[32] Die Realisierung von Software-Qualität wird durch das Einhalten von Prinzipien unterstützt und gefördert.^[33]

3.2. Produktivität

Der Begriff Produktivität ist noch nicht ausreichend definiert. Wenn die Entwicklungsproduktivität gesteigert werden soll, wird beabsichtigt, Systeme schneller unter Berücksichtigung der Qualitätsziele zu entwickeln. Um diese Ziele zu erreichen, ist es notwendig, die Entwicklungsproduktivität zu messen.^[34] Die hierfür vorhandenen Maße sind jedoch schwierig und unbefriedigend.^[35]

Die Konzepte zur Steigerung der Produktivität gehen in zwei Richtungen, nämlich Einsatz von Methoden, Werkzeugen und Hilfsmitteln, um die Produktivität im konventionellen Entwicklungsprozeß zu verbessern, und Verringerung des arbeitsintensiven Prozesses der Software-Entwicklung durch Einsatz von Sprachen der 4. Generation und einem Entwicklungsverfahren, das sich nicht am klassischen Vorgehensmodell orientiert (z.B. Prototyping). Dabei werden verstärkt die Endbenutzer direkt miteinbezogen.^[36]

4. Konzepte des Software Engineering

4.1. Allgemeine Prinzipien

Der Begriff "Prinzip" wird im Software Engineering verwendet als allgemeingültiger Grundsatz des Denkens oder Handelns im Sinne einer Norm. Prinzipien enthalten allgemeine Verhaltensregeln. Viele dieser Prinzipien erscheinen trivial. Die Schwierigkeit ihrer Anwendung liegt aber darin, daß sie sich zum Teil wechselseitig voraussetzen und stark miteinander verwoben sind. Es läßt sich keine Kausalkette herleiten, die besagt, in welcher Reihenfolge sie zeitlich angewendet werden könnten.^[37] Allgemein anerkannte Prinzipien für die verschiedenen Aufgaben in der Entwicklung und Wartung von Software sind zum Beispiel:^[38]

maximale konstruktive Qualitätssicherung, entwicklungsbegleitende, integrierte Qualitätssicherung, frühzeitige Fehlerentdeckung, Konstruktive Voraussicht, Abstraktion, Strukturierung, Modularisierung, Hierarchisierung, Lokalität, integrierte Dokumentation, Standardisierung und Mehrfachverwendung. Die Prinzipien sind miteinander verwoben.^[39]

4.1.1. Maximale konstruktive Qualitätssicherung

Fehler, die nicht gemacht werden, brauchen auch nicht behoben werden. Durch vorausblickende konstruktive Maßnahmen sollen analytische Qualitätssicherungsmaßnahmen reduziert werden.^[40] Dieses Prinzip ist eng verbunden mit dem Prinzip der konstruktiven Voraussicht.

4.1.2. Entwicklungsbegleitende, integrierte Qualitätssicherung

Zwecks Realisierung des Prinzips der frühzeitigen Fehlerentdeckung und um zu einer systematischen, vorgeplanten Qualitätssicherung zu gelangen, ist eine in den Entwicklungsprozeß integrierte Qualitätssicherung erforderlich. Das bedeutet, daß alle Teilprodukte, die am Ende einer Entwicklungsphase fertiggestellt sind, einer sofortigen Qualitätskontrolle unterworfen werden sollten. Die nachfolgende Entwicklungsphase darf erst begonnen werden, wenn das Ergebnis der Vorgängerphase den geforderten Qualitätsansprüchen genügt.^[41]

4.1.3. Frühzeitige Fehlererkennung

Oft fängt man in der Praxis erst nach der Programmierung an, ein Produkt auf die vorgegebenen Qualitätsmerkmale hin zu überprüfen. Wenn man jedoch erst in dieser späten Phase feststellt, daß das Produkt von den Anforderungen abweicht, dann muß nicht nur der Code, sondern auch der Entwurf geändert werden. Noch aufwendiger werden Fehlerkorrekturen, wenn Fehler erst im Betrieb des fertigen und freigegebenen Produktes festgestellt werden.

Durch das Prinzip der frühzeitigen Fehlerentdeckung soll betont werden, daß den ersten Phasen der Software-Entwicklung besonders viel Aufmerksamkeit gewidmet werden sollte,^[42] denn je länger ein Fehler im Programm verweilt, desto aufwendiger und teurer wird seine Behebung.

[...]

---

^[1] vgl. Klaeren, S. 22

^[2] vgl. Spillner, S. 48

^[3] vgl. Dumke, S. 4

^[4] vgl. Klaeren, S. 22

^[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

^[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

^[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

^[23] vgl. Schumann u.a., S. 47

^[24] vgl. Kopetz zit. in Pomberger (1993), S. 10

^[25] vgl. Wieken, S. 88

^[26] vgl. Kopetz zit. in Pomberger (1993), S. 11, vgl. Balzert (1992), S. 12

^[27] vgl. Pomberger (1993), S. 11

^[28] vgl. Pomberger (1993), S. 12

^[29] vgl. Balzert (1992), S. 12, vgl. Pomberger (1993), S. 13

^[30] vgl. Balzert (1992), S. 12

^[31] vgl. Peter, S. 48

^[32] vgl. Wallmüller, S. 16

^[33] vgl. Balzert, (1982), S. 27

^[34] vgl. Wallmüller, S. 58

^[35] vgl. Wallmüller, S. 59 ff

^[36] vgl. Wallmüller, S. 57

^[37] vgl. Balzert, (1982), S. 66

^[38] vgl. Balzert (1985). S. 27ff

^[39] vgl. Balzert (1985), S. 15

^[40] vgl. Balzert (1985), S. 10

^[41] vgl. Balzert (1985), S. 11

^[42] vgl. Balzert (1985), S. 11