Modul

Informatik III

Softwaretechnologie

Prof. Dr. W. Hasselbring

Wintersemester 2008/2009

Inhaltsverzeichnis

0 Organisatorisches 4

1 Einleitung 51.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Probleme in der Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Software Engineering als Losung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Prinzipien des Software Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4.1 Abstraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.2 Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.4.3 Modularisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.4.4 Kapselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.5 Separation of Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.6 Anderbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.7 Inkrementalitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.8 Grundlichkeit und Formalitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.5 Beziehungen zu anderen Disziplinen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.6 Professionelle Verantwortung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2 Vorgehensmodelle 252.1 Prozessmodell und Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2 Das Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3 Iterative, Inkrementelle und Evolutionare Entwicklung . . . . . . . . . . . . . . . . . . . . 302.4 Software-Prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Konfigurationsmanagement 353.1 Was ist Konfigurationsmanagement? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Versionen/Revisionen/Varianten/Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3 Versionsmanagement-Werkeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.1 RCS: Revision Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.2 Concurrent Versions System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.3 Subversion SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4 System Bauen (Build) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.1 Systembau mit make . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4.2 Apache Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.5 Planung des Konfigurationsmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

1

4 Anforderungsermittlung 514.1 Einfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 Lastenheft und Pflichtenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3 Anforderungsanalyse mit Anwendungsfallen . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.1 Akteure und Anwendungsfalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.2 Anwendungsfalldiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3.3 Anwendungsfalle ermitteln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3.4 Rational Unified Process (RUP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.4 [ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5 Modellierung der Struktur 705.1 Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.3 Assoziationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4 Von Anwendungsfallen zu Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.5 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.6 Pakete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.7 Stereotypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6 Modellierung der Dynamik 936.1 Aufruf von Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.2 Zustandsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.3 Aktivitatsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.4 Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.5 Ubersicht uber die UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.5.1 UML-Elemente zur Strukturmodellierung . . . . . . . . . . . . . . . . . . . . . . . 1056.5.2 UML Elemente zur Verhaltensmodellierung . . . . . . . . . . . . . . . . . . . . . . 1076.5.3 UML-Elemente zur Interaktionsmodellierung . . . . . . . . . . . . . . . . . . . . . 108

7 Entwurfsmuster 1117.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.2 Erzeugungsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.2.1 Erzeugungsmuster Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.2.2 Erzeugungsmuster Abstract Factory . . . . . . . . . . . . . . . . . . . . . . . . . . 116

7.3 Strukturmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207.3.1 Strukturmuster Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207.3.2 Strukturmuster Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.4 Verhaltensmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267.4.1 Verhaltensmuster Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267.4.2 Verhaltensmuster Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

7.5 Entwurfsmuster in JavaBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

8 Komponenten und Schnittstellen 1408.1 Modularer Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408.2 Softwarearchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458.3 Algebraische Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478.4 Entwurf als Vertrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

8.4.1 Eiffel als textuelle Entwurfsund Implementierungssprache . . . . . . . . . . . . . . 1498.4.2 Wie lasst sich das in der UML spezifizieren? . . . . . . . . . . . . . . . . . . . . . . 1548.4.3 Zusicherungen in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

8.5 Wiederverwendung von Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638.6 Design von Benutzungsschnittstellen: Software-Ergonomie . . . . . . . . . . . . . . . . . . 168

2

9 Qualitatssicherung 1759.1 Validation & Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1759.2 Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

9.2.1 White-Box Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1769.2.2 Black-Box Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809.2.3 Integrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839.2.4 Regressionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849.2.5 Objektorientiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

9.3 Statische Analysetechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879.3.1 Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879.3.2 Kontroll- und Datenflussanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1889.3.3 Formale Korrektheitsbeweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

9.4 Fehlervermeidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1949.5 Das V-Modell und andere Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1969.6 Cleanroom Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

10 Management von Software-Projekten 20010.1 Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20110.2 Aufwandsschatzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20410.3 Personalplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

3

0 Organisatorisches

Organisatorisches

• Das Folienskript, Information zu den Ubungen und weiteres Material gibt es uber: http://www.informatik.uni-kiel.de/se/

• Empfohlene Lehrbucher:

[Ghezzi et al. 2003] Bietet einen sehr guten Einstieg in die grundlegenden Prinzipien des Soft-ware Engineering.

[Sommerville 2007; 2008] Liefert eine breiten Uberblick, jedoch ohne sehr tief zu gehen.

[Brugge and DUTOIT 2004] Betont objekt-orientierte Techniken. Bafog-Ausgabe fur Euro29,95: [Brugge and Dutoit 2006].

[Winter 2005] Betont objekt-orientierte Techniken.

Leider kann ich (noch) kein einzelnes Buch empfehlen.

Organisatorisches

• Voraussetzungen:

– Informatik I & 2

• Vorlesung:

– Montags 1615 – 1745 Uhr im HRS7 – R.3

– Dienstags 1415 – 1545 Uhr im HRS7 – R.3

• Gelegentlich ”Große Ubungen“ statt der Vorlesung

• Sprechstunden:

– W. Hasselbring: Dienstags 1030 – 1130 Uhr in 1217

– J. Waller: Mittwochs 1000 – 1100 Uhr in 1215

– S. Frey: ist erst ab 17.11.2008 an der CAU

Formalia zur ModulbewertungNoch ohne Gewahr

• Belegung des Moduls und Einteilung der Ubungsgruppen erfolgt uber die StudiDB.

• Am Ende der Vorlesung findet eine schriftliche Klausur statt. Bei ihr konnen wahrend des Semestersanhand von Hausaufgaben erworbene Punkte als Bonuspunkte eingebracht werden.

• Mindestens 50 % der Punkte mussen insgesamt erreicht werden, um das Modul zu bestehen.

4

1 Einleitung

1.1 Software

Was ist Software?

Software

”Software: Computer programs, procedures, rules, and possibly associated documentation and data per-taining to the operation of a computer system“

IEEE Standard Glossary of Software Engineering Terminology [IEEE]

Zu unterscheiden:

• Software as a Service

• Software as Code

Softwaresysteme und Software Engineering

• Ein Softwaresystem ist ein System, dessen Komponenten aus Software bestehen.

• Softwaresysteme sind Produkte von Softwareprojekten.

• Betrachtet wird im Software Engineering vor allem die Entwicklung ”großer“ Softwaresysteme, z.B.:

– Betriebssysteme,

– Datenbankmanagementsysteme,

– Web-Informationssysteme,

– Steuerung von Industrieanlagen.

• Komplexe Softwaresysteme finden sich mittlerweise in allen Bereichen des Lebens, beispielsweise

– Eingebettete Software in PKWs, Haushaltsgeraten,

– Steuerungen in der Verkehrs- und Energietechnik,

– Informationssysteme in Unternehmen, und

– die zukunftige elektronische Gesundheitskarte.

1.2 Probleme in der Softwareentwicklung

Erwartungen an Softwaresysteme

Was wir nicht wollen:Fehlerhafte Software

DennFehler sind teuer:

• Sachschaden,

• Personenschaden,

• Konventionalstrafen (fur zu spate und/oder fehlerhafte Software),

• Kosten fur Fehlersuche und Behebung,

• Schaden fur das Unternehmens-Image,

• Rechtliche Konsequenzen, z.B. Schadenersatz.

5

I. Beispiel: Mariner 1 (1962)22.Juli 1962, Cape Canaveral / Florida: Start der ersten amerikanischen Venussonde Mariner 1

Betrachten wir das FORTRAN-Programm zur Steuerung der Flugbahn der Tragerrakete.I. Beispiel: Mariner 1

Ausschnitt aus dem FORTRAN-Steuerprogramm der Sonde

13 DO 40 M = 1 , 314 W0 = (M−1) ∗0 .515 X = H ∗1.74533E−2∗W016 DO 20 N0 = 1 , 817 EPS = 5.0∗10 . 0∗∗ ( N0−7)18 CALL BESJ (X , 0 , B0 , EPS , IER )19 IF ( IER . EQ . 0) GOTO 1020 20 CONTINUE21 DO 5 K = 1 . 322 T (K ) = W0

23 Z = 1 .0/ ( X∗∗2) ∗B1∗∗2+3.0977E−4∗B0∗∗224 D (K ) = 3.076E−2∗2.0∗(1 .0/ X∗B0∗B1+3.0977E−25 4∗∗( B0∗∗2−X∗B0∗B1 ) ) /Z26 E (K ) = H ∗∗2∗93.2943∗ W0/SIN ( W0 ) ∗Z27 H = D (K )−E (K )28 5 CONTINUE29 10 CONTINUE30 Y = H/W0−1

I. Beispiel: Mariner 1

Das FORTRAN-Programm im Detail

• Zeile 21 bis 28 noch einmal genauer:

DO 5 K = 1 . 3

. . .

5 CONTINUE

• Entscheidender Fehler: Punkt statt Komma!

• Wirkung:

DO5K = 1.3

I. Beispiel: Mariner 1

Was ist die Konsequenz dieses Fehlers?

• Wertzuweisung an eine nicht deklarierte Variable⇒ Kein Durchlauf der (nicht vorhandenen) Schlei-fe

• Folgen:

– Abweichung der Tragerrakete von der vorgesehenen Flugbahn

– Zerstorung der Rakete nach 290 Sekunden

• Kosten dieser (falschen) Wertzuweisung: 18.5 Millionen US$

I. Beispiel: Mariner 1

6

Wo genau liegen die Ursachen?

• Blanks (Zwischenraume) in Namen und Zahlen sind in FORTRAN-4 erlaubt (bzw. werden igno-riert).

• Eine Variablen-Deklaration ist nicht notwendig.

• Die Verwendung einer strukturierten Schleife (END DO) ist in FORTRAN-4 nicht moglich.

Ware das z. B. mit Java noch ein Problem?

Ein weiterer tragischer Fehler aus diesem Bereich ist die gescheiterte Marsmission Mars ClimateOrbiter. Aufgrund eines Einheitenfehlers im Navigationssystem ist die Sonde beim Mars verloren gegan-gen. Wahrend die NASA mit SI-Einheiten rechnete (Newton), arbeitete das System mit dem imperialenEinheitensystem (Pfund) Euler et al. [2001].

II. Beispiel: Therac 25 (1985/86)

• Therac 25 ist ein Linearbeschleuniger zur Tumorbehandlung.

• Eine Software errechnet und steuert die Bestrahlungsstarke entweder als Elektronenstrahlung oderals Rontgenstrahlung.

II. Beispiel: Therac 25

Was ging schief?

• Die Steuersoftware ließ jedes 64-ste Mal Fehleingaben durch das Bedienpersonal zu.

• Infolge dessen kam es fast unbemerkt zu massiven Strahlenschaden.

Etwas aktuellerFunf Patienten wurden 2001 in Panama durch ein Bestrahlungsgerat wegen Fehleingaben getotet [Noord-vyk 2001].

III. Beispiel: Airbus A320 (1993)Bruchlandung beim Landeanflug auf Flughafen Warschau Folgen: 2 Tote, erheblicher Sachschaden

III. Beispiel: Airbus A320

Warum sturtze der Airbus ab?

• Die Maschine hatte Auftrieb infolge zu hoher Geschwindigkeit und falscher Windvorhersage.

• Der Pilot wollte die Maschine nach dem Aufsetzten abbremsen.

• Der Fahrwerkssensor meldete: ”Die Maschine fliegt noch“.

• Das Programm des Bremssystems folgerte: ”Fliegende“ Maschine darf nicht abgebremst werden.

IV. Beispiel: Ariane 5 (1996)Ca. 40 Sek. nach dem Start kam die Rakete vom Kurs ab und wurde gesprengt.Folgen: Gesamtschaden von mehr als 1 Milliarde Euro

IV. Beispiel: Ariane 5

7

Warum ist die Ariane 5 beim Erstflug explodiert?

• Die Software fur das Tragheitsnavigationssystem wurde unverandert von der Ariane 4 ubernommen.Ein Test dieser Software-Komponente unterblieb daher.

• Die ubrigen Systeme der Rakete wurden komponentenweise grundlich getestet. Ein gemeinsamerTest der gesamten Steuerungssoftware der Rakete unterblieb aus Kosten- und Machbarkeitsgrun-den.

• In der Software fur das Tragheitsnavigationssystem gibt es eine Abgleichsfunktion, deren Werteeigentlich nur sinnvoll sind, solange die Rakete noch nicht fliegt. Diese Funktion arbeitet pro-grammgemaß bis ca. 40 s nach der Zundung weiter, weil das bei der Ariane 4 im Fall eines Count-downabbruchs kurz vor dem Abheben sinnvoll war.

IV. Beispiel: Ariane 5

Chronik der Ereingisse

1. Flug 501 startet am 4. Juni 1996. Die Triebwerke zunden um 933:59 Uhr.

2. Die ersten 36 Sekunden des Flugs verlaufen normal.

3. Die Ariane 5 hat eine andere Flugbahn als die Ariane 4, deshalb berechnet die Abgleichsfunktioneinen Wert, der wesentlich großer ist als erwartet

4. Bei der Konvertierung dieses Werts tritt ein Uberlauf auf (64 Bit Gleitkommazahl in 16 Bit Ganz-zahl)

5. Das Programm erzeugt eine Ausnahmebedingung (Fehlermeldung)

IV. Beispiel: Ariane 5

Chronik der Ereingisse (Forts.)

6. Die Ausnahmebedingung wird nicht behandelt (obwohl dies in der verwendeten Programmierspra-che Ada moglich ware)

7. Der Tragheitsnavigationsrechner setzt eine Fehlermeldung an den Steuerrechner ab und schaltetsich 36,75 s nach Start ab.

8. Das Tragheitsnavigationssystem ist doppelt ausgelegt

9. Ein Umschalten auf das zweite System schlagt fehl, da dieses System das gleiche Problem hatteund sich vor 0,05 s ebenfalls abgeschaltet hat

10. Der Steuerrechner ist nicht auf den Ausfall beider Tragheitsnavigationssysteme ausgelegt und in-terpretiert die gemeldeten Fehlercodes als Flugbahndaten

IV. Beispiel: Ariane 5

Chronik der Ereingisse (Forts.)

11. Dies fuhrt zu vollig unsinnigen Berechnungen und als Folge davon zu unsinnigen Stellbefehlen an dieSteuerdusen der Rakete: Diese werden bis zum maximal moglichen Anstellwinkel ausgeschwenkt.

12. Aufgrund der Schwerkrafte zerbricht die Rakete

13. Der Selbstzerstorungsmechanismus spricht an

14. Rakete und Nutzlast werden gesprengt um zu verhindern, dass großere Trummerteile auf den Bodenfallen.

IV. Beispiel: Ariane 5

8

Schaden durch den Absturz

Juni 1996

• Vier Satelliten verloren: 400 - 500 Millionen Euro

• Zwei Jahre Verzug im Entwicklungsprogramm: > 500 Millonen Euro

• Zwei zusatzliche Erprobungsstarts bei Gesamtkosten des Projekts von 1987 bis 1998 von 6700Millionen Euro

Dezember 2002

• Ariane 5-Plus nach Start gesprengt Rund drei Minuten nach dem Start versagte die Treibstoffzu-fuhr fur den Raketenmotor

• Weiterentwicklung zunachst auf Eis gelegt

“Es ist wichtiger, ein Umfeld des Vertrauens zu schaffen und ein sicheres Raketensystemzu haben.”

ESA-Generaldirektor Antonio Rodota

Folgerungen fur das Software EngineeringWas konnen wir daraus lernen?

Spezifikation: Bestehende Software darf nicht unbesehen fur eine neue Aufgabe wiederverwendet wer-den.

Vorher muss gepruft werden, ob ihre Fahigkeiten den Anforderungen der neuen Aufgabe entspre-chen.

Dokumentation: Die Fahigkeiten einer Software sowie alle Annahmen, die sie uber ihre Umgebungmacht, mussen dokumentiert sein.

Andernfalls ist die Prufung auf Wiederverwendbarkeit extrem aufwandig.

Design by Contract: Kooperieren zwei Software-Komponenten miteinander, so mussen eindeutige Re-geln definiert, dokumentiert und eingehalten werden.

Wer liefert wem was unter welchen Bedingungen?

Folgerungen fur das Software Engineering

Fehlerbehandlung: Jede potentielle Fehlersituation in einer Software muss

• entweder behandelt werden,

• oder die Grunde fur die Nichtbehandlung mussen so dokumentiert werden, dass die Gultigkeitder dabei getroffenen Annahmen uberprufbar ist.

Software 6= Hardware: Mehrfache identische Auslegung von Systemen hilft nicht gegen logische Fehlerin der Software.

Sicherheit: Bei Storungen in sicherheitskritischen Systemen ist Abschalten nur dann eine zulassigeMaßnahme, wenn dadurch wieder ein sicherer Zustand erreicht wird.

Fehlertoleranz: Eine hundertprozentige Absicherung gegen Fehler ist nicht moglich, daher mussenVerfahren zur Tolerierung von Fehlern entwickelt werden.

9

Qualitatsmanagement

Test: Bei der Prufung von Software, die aus mehreren Komponenten besteht, genugt es nicht jedeKomponente einzeln zu prufen.

Umfangreiche Integrations- und Systemtests unter moglichst realistischen Bedingungen sind not-wendig.

Review: Jedes Programm muss – neben einem sorgfaltigen Test – durch kompetente Fachleute inspiziertwerden, weil insbesondere die Erfullbarkeit und Adaquatheit von Annahmen und Ergebnissen haufignicht testbar ist.

Risikomanagement: Die Risiken erkennen, angemessene technische Maßnahmen (siehe oben) planen,durchsetzen und uberprufen. Evtl. Entscheiden, Projekte fruhzeitig zu beenden.

Weitere Beispiele fur versagende Software

Sicherheit/Safety Ford Explorer und Mountaineer: Der Tempomat erhoht gelegentlich eigenstandigdie Geschwindigkeit (2000): Software-Fehler in Antriebselektronik

Verfugbarkeit Die Verfugbarkeit der webbasierten Hartz-IV-Software A2LL sinkt von 99,7 Prozent imJahr 2005 auf 98,3 Prozent im Jahr 2006 [Bundestag 2006].

Zuverlassigkeit Transporter Vito und Viano von Mercedes-Benz: Ausfall der Kraftstoffzufuhr (2004):Die Software der Dieselsteuergerate aktiviert in Situationen, in denen dies eigentlich nicht vorkom-men sollte, die Kraftstoffabschaltung

Performance Polizei-Informationssystem: Niedersachsische Vorgangsbearbeitungs-, Analyse-, Dokumentations-und Informationssystem NIVADIS (2003): Extrem lange Wartezeiten bei der Bearbeitung von Vor-gangen

Ahnliche Probleme in Bayern mit Mangeln des Computerprogramms fur die Dienstplangestaltung(DiPlaZ):

Quelle: http://www.heise.de/newsticker/meldung/82125

Weitere Beispiele fur versagende Software

Sicherheit/Security W32.Sasser.Worm: Systemabsturze (2004:) Schwachstelle im “Local Security Au-thority Subsystem Service” von Windows

Privacy Hacker-Einbruch im Web-Informationssystem der Melbourne Transurban CityLink (2002): Ver-offentlichung von Kreditkartendetails von uber 500000 Kunden auf einer Web-Seite

Ein weiteres Beispiel aus http://www.pentagon.gov/releases/2006/nr20060428-12920.html :

Rechner des US-amerikanische Verteidigungsministerium wurden Opfer eines Angriffs, teilte dasPentagon mit. Die Angreifer konnten umfangreiche Informationen aus einer Datenbank kopieren,die Krankenversicherungsdaten von Angestellten der Behorde vorhalt.

Stromausfall Acht Staaten im Nordosten der USA und Teile Kanadas blieben im August fur funfTage ohne Strom (2003): Schuld am Blackout war ein Softwarefehler des Managementsystems zurUberwachung und Steuerung von Stromnetzen.

Qualitat der SoftwareWie definiert man Qualitat?

Externe Qualitat Korrektheit, Stabilitat, Performance (Effizienz, Skalierbarkeit), Benutzungsfreund-lichkeit und Benutzbarkeit, Sicherheit (Safety, Security), Zuverlassigkeit, Verfugbarkeit, usw.

Interne Qualitat Modularitat, Strukturiertheit, Wartbarkeit, Wiederverwendbarkeit, Portierbarkeit,Interoperabilitat, Programm-Dokumentation, systematischer Entwicklungsprozess, Konfigurations-management, usw.

10

Zentrales Ziel des Software EngineeringInterne Qualitat erhohen, um externe Qualitat zu erreichen

Qualitats-Charakteristiken und -AttributeNach ISO/IEC 9126-1, Jung et al. [2004]

Funktionalität

Zuverlässigkeit

Benutzerfreundlichkeit

Effizienz

Wartbarkeit

Portabilität

ISO-Norm 9126

ZeitverhaltenRessourcenauslastung

TauglichkeitGenauigkeit

InteroperabilitätEinhaltungSicherheit

AnalysierbarkeitVeränderlichkeit

StabilitätTestbarkeit

AdaptierbarkeitInstallierbarkeit

KonformitätAustauschbarkeit

ReifeFehlertoleranz

Wiedererlangbarkeit

VerständlichkeitErlernbarkeitBedienbarkeit

Attraktivität

Graduiertenkolleg TrustSoft

Component Technology

Ava

ilabi

lity

Priv

acy

Secu

rity

Safe

ty

Perf

orm

ance

Rel

iabi

lity

Cor

rect

ness

Certification

Quality of Service

http://trustsoft.uni-oldenburg.de [Hasselbring and Reussner 2006]

Qualitat der Software

Essenz

11

Qualitat wird sowohl vom Produkt als auch vom Prozess seiner Konstruktion gefordert.

Einige Probleme dabei

• Qualitat exakt zu ”messen“ (Metriken)

• Zusatzliche Kosten gering halten zur

– Fehlervermeidung,

– Fehlererkennung und -behebung,

– Fehlertoleranz.

1.3 Software Engineering als Losung

Geschichte des Software Engineering1968: Pragung des Begriffes Software-Krise

• Symptome

– Software fehlerhaft,

– Kostenschatzung fur Software vollig fehlerhaft,

– Termine kaum eingehalten,

– Anderung von Programmen kaum moglich.

• Ursachen

– Die Komplexitat der zu konstruierenden Softwaresysteme uberstieg die Moglichkeiten derverfugbaren Methoden und Techniken zu ihrer Konstruktion bei weitem!

– Insbesondere gab (und gibt) es Defizite im Management großer Teams.

• Ausweg

– 1968: Pragung des Begriffs Software Engineering als Antwort auf die Software-Krise

Aussagen zum Stand des Software Engineering

• Kein Fortschritt: Die selben Probleme seit 1968?

• Wirklich kein Fortschritt im Software Engineering?

– Die gleichen Probleme seit Jahrzehnten, aber fur deutlich komplexere und großere Systeme.

• Software wird entwickelt, nicht produziert!

• ”Planungskrise“ anstelle einer ”Software Krise“ [Glass 2002]:

– Projekt-Budgetierung und Zeitplanung wird von Kunden oder Managern vorgenommen, seltenvon Entwicklern.

– Nur zwei der folgenden drei Vorgaben sollten vom Kunden/Manager entschieden werden:Termine, Kosten, Qualitat.

• Software Engineering als Mittel zur Beherrschung der Komplexitat.

12

Termine, Kosten, Qualitat[DeMarco 1982]

Qualität

chooseany two !

KostenTermine

Termine, Kosten, Qualitat & Quantitat[Sneed 1987]

Produktivität

QuantitätQualität

KostenEntwicklungsdauer

+ +

+ +

- -

- -

a

b

Kiviat-Diagramme (auch Radar-Diagramm, Polar-Diagramm) sind zur ubersichtlichen Darstellung derWerte unterschiedlicher Metriken in einem Diagramm geeignet.

Warum ist Software so schwer zu entwickeln?

• Die meisten vom Benutzer in der Software gefundene Fehler basieren auf Problemen in der Pro-duktdefinition und Problemanalyse.

• Software ist leicht anderbar.

• Software altert:

– Wahrend der Entwicklung und spater durch den Einsatz der Software andern sich die Anfor-derungen.

– Manche Software gibt belegte Ressourcen nicht korrekt wieder frei.

13

Begriffsbildung: Software EngineeringSoftwaretechnik, Softwaretechnologie

[Naur and Randell 1968] The establishment and use of sound engineering principles in order to obtaineconomically software that is reliable and works efficiently on real machines.

[IEEE] Definition der IEEE:

1. The application of a systematic, disciplined, quantifiable approach to the development, ope-ration, and maintenance of software; that is, the application of engineering to software.

2. The study of approaches as in (1).

[Broy et al. 2006] Software Engineering ist die Methodenlehre der Softwarekonstruktion. Ihre Haupt-beitrage sind methodische Hilfsmittel wie Prozesse, Modelle, Werkzeuge und Prinzipien zur Kon-struktion und Beherrschung des Einsatzes hochwertiger Software.

Charakterisierung: Software EngineeringIngenieurmaßiges Entwickeln von Software

• Komplexe Softwaresysteme werden im Team entwickelt.

• Hohe Qualitat der Software ist ein zentrales Ziel zur Erfullung der

– funktionalen (fachlichen) Anforderungen und der

– nicht-funktionalen (technischen) Anforderungen.

Software Engineering hat etwas mit Beherrschung von Komplexitat zu tun:

• Die zu konstruierende Software hat viele Komponenten.

• Die zu konstruierende Software wird von vielen Anwendern benutzt.

• Die zu konstruierende Software wird von vielen Entwicklern realisiert.

• Die zu konstruierende Software soll auf vielen Plattformen laufen.

Benotigte Fahigkeiten im Software Engineering

Zitat aus [Ghezzi et al. 2003, Seite 5]A software engineer must of course be a good programmer, be well-versed in data structures and algo-rithms, and be fluent in one or more programming languages. The software engineer must be familiarwith several design approaches, be able to translate vague requirements and desires into precise speci-fications, and be able to converse with the user of a system in terms of the application rather than in

”computerese“.

Einige daraus folgende, notwendige Fahigkeiten

• Programmiertechniken

• Erstellung und Nutzung von Modellen / Spezifikationen auf verschiedenen Abstraktionsebenen

• Kommunikation mit Personen mit unterschiedlichen Zielsetzungen, Vorstellungen, Ausbildungen(Stakeholder)

• Arbeitsplanung und -koordination

14

System- vs. Software-Entwicklung

Software-Entwicklung

• Ausschließliche Betrachtung der Entwicklung von Software

Software Engineering ist die Lehre von den Methoden der Softwarekonstruktion. Ziel der Disziplin istdie Entwicklung methodischer Hilfsmittel zur Erstellung korrekter und effizienter Software. Zur Reper-toire des Software Engineering gehoren Prozesse, Modelle, Werkzeuge und Prinzipien. Dies orientiert sicham sogenannten Softwarelebenszyklus, indem die Entwicklung in allen Phasen vorangetrieben wird. DasLeben eines komplexen Softwaresystems beginnt mit der Anforderungsanalyse, auf deren Basis ein ersterEntwurf des Systems entsteht. Nach weiteren Verfeinerungsschritten kann eine Implementierung zunachstvon Einzelkomponenten erzeugt werden, die nach Einzeltests integriert werden, um das Gesamtsystemzu realisieren. Dem Integrationstest folgt das “Deployment”, also die Installation des Systems auf denZielrechnern. Bis zur Außerdienststellung der Software wird das System nun typsicherweise regelmaßiggewartet.

System-Entwicklung

• Entwicklung eines Systems, das aus Hardware- und Software-Komponenten besteht und/oder ineinen organisatorischen Kontext eingebunden ist.

• Bei der Entwicklung mussen zusatzliche Randbedingungen berucksichtigt werden.

Systems Engineering ist ein interdisziplinarer Ansatz, um erfolgreich Systeme zu entwickeln und zurealisieren. Dabei bezieht sich die Disziplin nicht auf einen speziellen Bereich wie etwa Software, sondernerhebt einen allgemeineren Anspruch. Betrachtet man jedoch die Methoden des Systems Engineering, sofallt eine Ubereinstimmung in mehreren Punkten auf:

• Projektmanagement, um die Organisation des Entwicklungsprozess unter Kontrolle zu halten;

• Anforderungsanalyse, Anforderungsdefinition und Anforderungsmanagement, die Grundlage derSystementwicklung;

• Systementwurf (Modellbildung, Simulation und Bewertung), die Entwicklung des Systems;

• Veranderungsmanagement, in der Entwicklung gibt es oft Veranderungen diese mussen jedoch nach-vollziehbar sein;

• Systemintegration (Schnittstellen-Spezifikation beziehungsweise -Produktentwicklung), um eine per-fekte Einbindung in das nachst großere Systems zu gewahrleisten;

• Systemverifikation und -validation um sicherzustellen, dass die Anforderungen erfullt wurden;

• Risikomanagement (also zum Beispiel Fehlerbaume, Fehleranalyse, FMEA), der Einfluss von Risi-ken sollten bei der Systementwicklung minimiert werden;

• Nachhaltige Entwicklung, anpassbar sollte jedes System entwickelt werden.

Der wesentliche Unterschied zum Software Engineering besteht in einer deutlich starkeren Konzentra-tion auf den Systemgedanken, d.h. der Blick auf das Ganze steht in allen Schritten im Vordergrund.Dabei werden auch die Schnittstellen zu anderen als softwaretechnischen Systemkomponenten (insbeson-dere Mensch, Organisation, Umwelt) umfassend berucksichtigt. Dies druckt sich durch eine Vielzahl vonManagement-Funktionen aus, die sowohl zu Projektbeginn als auch wahrend der Laufzeit eine standigeKontrolle des Gesamtprojekts gewahrleisten sollen.

Software Systems Engineering kombiniert nun die beiden Disziplinen miteinander, indem die eherubergreifenden Funktionen des Systems Engineering in die softwarebezogenen Prozesse, Methoden, Werk-zeuge und Prinzipien integriert.

15

Worum geht es also?

• Software Engineering dient zum Konstruieren von Softwaresystemen.

• Wir verwenden einen Prozess zur Konstruktion dieser Systeme:

– Arbeitsteilung, Prufungen bei Ubergabe.

• Anforderungen an

– den Entwicklungsprozess, u.a. Effizienz, bzgl. Kosten,

– das Produkt, u.a. Erfullung von Qualitatskriterien.

• Wir benotigen Werkzeuge, um diesen Prozess zu unterstutzen.

Werkzeuge im Software Engineering?

• Werkzeuge dienen der automatisierten Unterstutzung von Methoden und Notationen.

• Durch Werkzeuge kann die Einhaltung von Methoden, Standards und Notationen unterstutzt und(moglicherweise) die Produktivitat erhoht werden.

• Werkzeuge sind sinnvoll, um Tatigkeiten zu automatisieren, die

– eine hohe Prazision erfordern,

– oft wiederholt werden mussen,

– eine Uberprufung erfordern.

• Um Software zu entwickeln, ist der Einsatz von Werkzeugen notwendig, aber nicht hinreichend.

• Software mit Software entwickeln

• Stichwort CASE : Computer Aided Software Engineering

1.4 Prinzipien des Software Engineering

Prinzipien des Software Engineering

Prinzip Grundsatz, dem man seinem Handeln zugrunde legt. Noch unabhangig von konkreten Methodenund Techniken

Technik Vorschrift zur Durchfuhrung einer Tatigkeit (Was ist wie zu tun?)

Methode Planmaßig anwendbare, begrundete Technik zur Erreichung vorgegebener Ziele (Was ist wieund unter welchen Rahmenbedingungen zu tun, so dass ein gutes Ergebnis erreicht wird?)

Prinzipien des Software Engineering

• Abstraktion

• Strukturierung

• Modularisierung

• Kapselung

• Separation of Concerns

• Anderbarkeit

• Inkrementalitat

• Striktheit und Formalitat

16

1.4.1 Abstraktion

Prinzip: AbstraktionAbstraktion bedeutet Verallgemeinerung:

• Zerlegung in Hinblick auf die Identifizierung wichtiger und (zunachst) weniger wichtiger Aspekte

• Statt direkt ein spezielles Problem zu losen, kann es sinnvoll sein, zunachst ein allgemeineres Pro-blem zu losen, dessen Losung dann als Grundlage zur Losung des speziellen Problems verwendetwird.

• Abstraktion ist notwendig, um Komplexitat meistern zu konnen.

• Vielzahl von Abstraktionen erfordern eine weitere Gliederung: Modularisierung, Kapselung, Sepa-ration of Concerns

• Eine Abstraktion kann auch verschiedene Sichten auf ein zu losendes Problem liefern.

Unterschiedliche Sichten erfordern unterschiedliche Abstraktionen[Booch 1994, Booch et al. 2007]

Abstraktion vom UnwichtigenWichtigkeit und Unwichtigkeit ist relativ zum Zweck der Abstraktion

17

Realität Modell

verkürzendeEigenschaft

erweiternde Eigenschaft

Ergänzte Eigenschaften :

- Längen- und Breitengrade- Legende

, z.B.Verkürzende Eigenschaften, z.B.:

- Temperatur- Luftfeuchtigkeit

Erde Landkarte

EinModell hat nach Stachowiak [1973] grundsatzlich

• einen Zweck,

• einen Bezug zu einem Original, und

• abstrahiert bestimmte Eigenschaften des Originals.

Aufgrund der Immaterialitat von Software, die bei einem weit gefassten Modellbegriff auch ein Modellvon sich selbst bzw. den durch sie beschriebenen Ablaufen ist, bestehen zwischen dem Original und seinenModellen vielfaltige Beziehungen, die sich auch durch den jeweiligen Einsatzzweck bemerkbar machen.So werden Modelle nicht nur zur Erringung eines substantiellen Anforderungsbzw. Systemverstandnisses,sondern haufig auch zur konstruktiven Generierung von Code oder zur qualitatssichernden Ableitung vonTests eingesetzt.

Modell als Abstraktion

Modell

Programm

Reale Welt

Abstrahiert vonImplementierungs-Details

Abstrahiert von un-wichtigen Details

@@

@@@I

@@

@@@R

Modellierung und Abstraktion

Kramer [2007]Abstraktionsfahigkeit ist eine der Kern-Qualifikationen fur die Informatik, bzw. fur ein Informatikstudi-um.

18

1.4.2 Strukturierung

Prinzip: StrukturierungArten der Strukturierung

• zeitliche Strukturierung: Anforderungsanalyse / Entwurf / Programmierung / Test

• qualitative Strukturierung: Effizienz / Robustheit / Korrektheit

• perspektivische Strukturierung: Verwendung von Datenstrukturen / Datenfluss / Kontrollfluss

• Dekomposition (Strukturierung in Bestandteile): Komponente 1, Komponente 2 Diese Strukturie-rung ist so wesentlich, dass sie unter dem Prinzip Modularisierung gesondert betrachtet wird!

Strukturierung ist wichtig fur Teamarbeit und Arbeitsteilung, um Verantwortlichkeiten zuordnen zukonnen.

1.4.3 Modularisierung

Modularisierung: Produkteigenschaften

Kohasion Innerhalb einzelner Module sollte ein enger Zusammenhang bestehen.⇒ hohe Modul-Kohasion

Kopplung Zwischen Modulen sollten moglichst wenig Abhangigkeiten bestehen.⇒ geringe inter-modulareKopplung

Modularisierung hilft Programme zu verstehen

• Es ist leichter mit Anderungen umzugehen (Information Hiding, Kapselung).

• Es ist leichter Verantwortlichkeiten zuzuordnen (Separation of Concerns).

• Es ist leichter bereits implementierte und evtl. benutzte Module wiederzuverwenden.

Kohasion und KopplungFur das Prinzip Modularitat

hohe Kohäsion /geringe Kopplung

geringe Kohäsion /geringe Kopplung

geringe Kohäsion / hoheKopplung

hohe Kohäsion /hohe Kopplung

19

Prinzip: ModularisierungDer Prozess

bottom up Zuerst werden unabhangige Module konstruiert, die dann spater ,zusammengebaut‘ werden.⇒ Zusammensetzbarkeit

top down Zuerst wird das Gesamtsystem in unabhangige Module aufgeteilt, die dann einzeln imple-mentiert werden. ⇒ Zerlegbarkeit

1.4.4 Kapselung

Prinzip: KapselungDie Kapselung dient dem “Information Hiding.”

• Begrenzen der Details eines Moduls, die von außen sichtbar sind,

• Abgrenzen von Verantwortungsbereichen,

• Verringern von Abhangigkeiten zwischen Modulen,

• Zusammenhang mit anderen Prinzipien:

– Modularisierung wird unterstutzt.– Abstraktionen werden abgegrenzt.

1.4.5 Separation of Concerns

Prinzip: Separation of ConcernsTrennung von Belangen / Zustandigkeiten:

• Aufteilen in unabhangige Belange / Aspekte, z.B.

– in Kontroll- und Datenfluss,– in fachlich und technisch gepragte Losungsteile,– nach Produkteigenschaften,– nach externen und internen Qualitatskriterien.

1.4.6 Anderbarkeit

Prinzip: AnderbarkeitSoftware ist Gegenstand von Anderungen.Typische Ursachen fur Anderungen:

• Beseitigung von Fehlern (korrektive Wartung)

• Verbesserung nicht-funktionaler Eigenschaften (perfektive Wartung)

• Anpassung der Funktionalitat wegen sich andernder Rahmenbedingungen (adaptive Wartung)

• Erweiterung der Funktionalitat wegen Erkenntnisgewinn wahrend der Entwicklung (inkrementelleWartung)

1.4.7 Inkrementalitat

Prinzip: InkrementalitatInkrementalitat einer Tatigkeit bedeutet, dass diese Tatigkeit in Schritten vorgenommen wird. Nach

jedem Schritt wird ruckgekoppelt.Beispiel:

• es werden einzelne Software-Komponenten entwickelt und integriert, bevor alle Komponenten ent-wickelt werden

Inkrementalitat basiert auf der Annahme, dass Anderungen notig werden (und Aufwand verursachen).

20

1.4.8 Grundlichkeit und Formalitat

Prinzip: Grundlichkeit und FormalitatAspekte u.a.:

• Formale Anforderungsspezifikation

• Formale Dokumentation des Software-Prozesses und seiner Ergebnisse

• Formaler Entwurf

• Formale Verifikation der Korrektheit von Software

Formalitat ist (zumeist) Voraussetzung fur einen Werkzeugeinsatz.

Formalitat benotigt i.A. mathematische Fertigkeiten und zumeist auch eine gewisse Disziplin.

1.5 Beziehungen zu anderen Disziplinen

Beziehungen zu anderen Bereichen der InformatikProgrammiersprachen

• Unterstutzung fur Modularitat spielt eine zentrale Rolle.

• Strenge Typisierung erhoht die Zuverlassigkeit.

• ”Generierung“ von Programmen aus formalen Spezifikationen (z.B. Compiler-Compiler oder mo-dellgetriebene Softwareentwicklung)

• Anwendungs-orientierte Sprachen (Domain Specific Languages) enthalten vorgefertigte Elementefur Softwaresysteme bestimmter Anwendungsbereiche.

Beziehungen zu anderen Bereichen der InformatikBetriebssysteme

• Sind große Programme, die entsprechend den Prinzipien des Software Engineering konstruiert wer-den sollten.

Datenbanksysteme

• Sind auch große Programme.

• Die Trennung von Modellbildung und Implementierung hat hier seine Ursprunge.

Der Begriff ”Modell“ wird hier jedoch nicht immer konsistent verwendet.

• Datenbanksysteme konnen zur Integration verschiedener Software-Entwicklungswerkzeuge dienen.

Beziehungen zu anderen Bereichen der InformatikTheoretische Informatik

• Entwicklung von Modellen zur formalen Spezifikation

• Problem: Reale Systeme sind so komplex, dass sie praktisch nicht vollstandig formal beschriebenwerden konnen.

• In der Praxis werden daher uberwiegend semi-formale Methoden eingesetzt (z.B. die UML).

• Formale Methoden spielen bei der Entwicklung sicherheits-kritischer Systeme eine wichtige Rolle.

Kunstliche Intelligenz

• Wissensbasierte Systeme sind auch komplex, konnen jedoch kaum entsprechend den Prinzipien derSoftwaretechnologie konstruiert werden.

Hauptproblem: Das Wissen aus den Experten herausbekommen.

• KI-Einsatz in der Software-Entwicklung, z.B. als Unterstutzung der Wiederverwendung von Ent-wurfswissen.

21

Beziehungen zu anderen DisziplinenWirtschaftswissenschaften

• Betriebswirtschaftliche Aspekte

Lohnt sich EDV finanziell?

• Volkswirtschaftliche Aspekte

Welche informationstechnische Infrastruktur benotigt die Republik?

• Muss die Softwareindustrie durch den Staat bzw. die EU subventioniert werden?

Psychologie

• Nutzungsschnittstellen, Ergonomie

• Organisation, Personalfuhrung, Projektmanagement

• Personliche Qualifikation (Soft Skills): Kommunikation, Diskussionsleitung, Projektleitung, Vor-tragsprasentation

Unterschiede zu klassischen IngenieurdisziplinenIngenieure (Bau, Elektro, Maschinenbau)

• Haben zumeist prazise Anforderungen an die zu entwickelnden Systeme,

z.B. Motorleistung.

• Verwenden Mathematik,

z.B. Differentialgleichungen.

• Arbeiten nach uber viele Jahrzehnte etablierten Prinzipien und Prozessen.

Die Informatik kommt sowohl aus der Mathematik als auch aus den Ingenieurwissenschaften:

• Mathematik: Produktbezogene Strukturwissenschaft

• Ingenieurwesen: Eher Prozessbezogen

Ingenieurmaßige Entwicklungnach Shaw and Garlan [1996]

Handwerk• Talent und Erfahrung

IndustrielleEntwicklung

• Arbeitsteilig

• Strukturierter Prozess

• Spezialisten-ausbildung

• Nutzung spezialisierter Werk-zeuge von Drittherstellern

Ingenieur-maßigeEntwicklung

• Optimierung der Qualitat vonProdukten und Prozessen

Benotigt:

• Wissenschaftliche Grundla-gendisziplin

• Wissenschaftliche Anwen-dungsdisziplin

Stellung des Software Engineering im Kontext verschiedener Disziplinennach Broy and Rombach [2002]

22

ElektrotechnikMaschinenbau Software Engineering

Physik Informatik Betriebswirtschaft Psychologie

Mathematik

Ingenieur−wissenschaften

Grundlagen−wissenschaften

Hilfswissenschaften

1.6 Professionelle Verantwortung

Professionelle VerantwortungSoftware-Entwickler sollten sich nicht nur mit technischen Fragestellungen beschaftigen.

Sie haben auch ethische, soziale und professionelle Verantwortung.

Fur viele Tatigkeiten gibt es keine klaren Vorgaben:

• Entwicklung von militarischen Systemen

• Entwicklung von Systemen zur Uberwachung

• Was ist das beste fur die Profession?

SE Code of Ethics and Professional Practice (1)ACM / IEEE:

• Software engineers shall act consistently with the public interest.

• Software engineers shall act in a manner that is in the best interests of their client and employerconsistent with the public interest.

• Software engineers shall ensure that their products and related modifications meet the highestprofessional standards possible.

• Software engineers shall maintain integrity and independence in their professional judgment.

• Software engineering managers and leaders shall subscribe to and promote an ethical approach tothe management of software development and maintenance.

SE Code of Ethics and Professional Practice (2)

• Software engineers shall advance the integrity and reputation of the profession consistent with thepublic interest.

• Software engineers shall be fair to and supportive of their colleagues.

• Software engineers shall participate in lifelong learning regarding the practice of their professionand shall promote an ethical approach to the practice of the profession.

Quelle: http://www.acm.org/constitution/code.htmlhttp://www.ieee.org/about/whatis/code.html

23

Verantwortung von Software-Ingenieuren

1983: SDI (Strategic Defense Initiative von Reagan) ⇒ ”Software ist die Achillesferse von SDI“ David L.

Parnas (SDI-Software-Berater bis 1985)

Seit 2001: ”National Missile Defence“ (NMD) bzw. ”Ballistic Missile Defence“ (BMD) – Nationale Ra-ketenabwehr der USA ⇒ Kann das gut gehen?

2007ff Planungen zur Installation einer Raketenabwehr in Polen etc.

Wie ist das mit Lizenzierung / Zertifizierung von Software-Ingenieuren?IEEE:

• http://www.computer.org/certification/

• Software Engineering Body of Knowledge http://www.swebok.org

Lernziele

• Lernen aus den Fehlern der Vergangenheit

• Wurdigen, dass ein planmaßiges Vorgehen bei der Entwicklung komplexer Softwaresysteme imTeam sinnvoll ist. Bei der Entwicklung kleiner ”Programmchen“ ist das i.A. nicht erforderlich.

• Wissen, dass die Fahigkeit zur Zerlegung komplexer Probleme schon Teil der Losung ist. Insbeson-dere den Unterschied verstehen zwischen

– Programmieren im Kleinen,

– Programmieren im Großen.

• Erkennen, dass vielfaltige Beziehungen zu anderen Bereichen der Informatik und zu anderen Dis-ziplinen existieren.

• Software-Entwickler haben auch Verantwortung.

• Ein Verstandnis der Prinzipien ist wichtiger als das Kennen konkreter Methoden.

• Die konkreten Methoden andern sich schnell, die Prinzipien bleiben.

Trotzdem sehen wir uns im Folgenden einige konkrete Methoden an . . .

Lernziele

ZielQualitat ist das Ziel.

HerausforderungKomplexitat und Evolution.

24

2 Vorgehensmodelle

2.1 Prozessmodell und Vorgehensmodell

Prozessmodell und VorgehensmodellNach [Ludewig and Lichter 2006]

Definition 1 (Vorgehensmodell). Ein aktivitatsorientiertes Vorgehensmodell gibt fur jede Aktivitat an,was das Ziel der Aktivitat ist, welche Resultate dabei erarbeitet werden sollen und wer (im Sinne einerRolle, nicht einer Person) die Aktivitat ausfuhren soll.

Die Aktivitaten konnen weiter in Teilaktivitaten untergliedert werden.

Definition 2 (Prozessmodell). Ein (Software) Prozessmodell ist die Beschreibung eines Softwareprozes-ses als praskriptives Modell fur die Durchfuhrung der Projekte.

Uberall, wo das Prozessmodell keine (genauen) Vorgaben macht, mussen diese fur jedes Projekt oder fur eineGruppe sehr ahnlicher Projekte zugefugt werden. Diesen Vorgang bezeichnet man als Prozessauspragung (Tay-loring).

Vom Vorgehensmodell zum ProzessmodellEin Vorgehensmodell ist geeignet, dem Projektleiter und den Entwicklern Hinweise zu geben, welche

Tatigkeit als nachste auszufuhren ist. Es macht aber keine Aussagen uber

• die personelle Organisation

• die Gliederung der Dokumentation

• die Organisation und Verantwortlichkeiten fur die Prufungen

Nimmt man diese Punkte zur Vorgabe des Ablaufs hinzu, so entsteht aus dem Vorgehensmodell einProzessmodell.

Ziele

• Beherrschung des komplexen Prozesses der Softwareentwicklung,

• Optimierung des Entwicklungsprozesses,

• Erhohung der Prozessqualitat,

• Zertifizierbarkeit des Entwicklungsprozesses.

Elemente von VorgehensmodellenEin Vorgehensmodell . . .

• legt die Reihenfolge der Aktivitaten (Phasen) der Entwicklung und der Evolution von Softwarefest.

• legt die Ubergangskriterien zwischen den Phasen fest.

• ist Grundlage fur das Management von Projekten.

Grundlegende Elemente:

• Aktivitaten

• Dokumente

• Werkzeuge

• Rollen (fur Personen)

25

Das 0. Vorgehensmodell der Software-Entwicklungcode & fix

1. Schreibe ein Programm!

2. Finde und behebe die Fehler in dem Programm!

Nachteile:

• Bei der Behebung von Fehlern wird das Programm haufig so umstrukturiert, dass es schlechterverstandlich wird und weitere Fehlerbehebungen immer teurer werden.

• Dies fuhrt zu der Erkenntnis, dass eine Entwurfsphase vor der Programmierung benotigt wird.

Erweiterte Vorgehensmodelle mit EntwurfsphaseWeiterhin Probleme:

• Selbst gut entworfene Software wird vom Endbenutzer oft nicht akzeptiert.⇒ Dies fuhrt zu der Erkenntnis, dass eine Anforderungsdefinition vor dem Entwurf benotigt wird.

• Fehler sind schwierig zu finden, da Tests schlecht vorbereitet und Anderungen unzureichend durch-gefuhrt werden.⇒ Dies fuhrt zu einer separaten (Integrations-) Testphase.

• Auch nach der Fertigstellung muss die Software weiterentwickelt werden.

Dies fuhrt uns zum Wasserfallmodell.

2.2 Das Wasserfallmodell

Das Wasserfallmodell

Machbarkeits-studie

Anforderungs-analyse

System-entwurf

Codieren &Modultest

Integrations-& Systemtest

Auslieferung &Installation

Wartung

Entwicklung

Das Wasserfall-Modell ist als erstes umfassendes Modell fur das Software Engineering zu bezeichnenund basiert auf dem stagewise model Benington [1956]. Weiterentwickelt wurde es u.a. durch Royce undBoehm, die die ursprungliche lineare Abfolge von Aktivitaten um Rucksprungmoglichkeiten erganztenund dem Modell den durch dessen Form begrundeten und noch heute verwendeten Namen Wasserfall-Modell gaben Royce [1987], Boehm [1981]. Das Modell lasst sich durch die obige Abbildung beschreiben.

26

Charakteristika des Wasserfallmodells

• Software wird in sukzessiven Stufen entwickelt.

• Jede Aktivitat ist in der richtigen Reihenfolge und in der vollen Breite vollstandig durchzufuhren.

• Der Entwicklungsablauf ist sequentiell. Jede Aktivitat muss beendet sein, bevor die nachste anfangt.

• Ruckkopplungsschleifen zwischen den Stufen sind begrenzt moglich.

• Nutzerbeteiligung ist nur in den ersten Phasen vorgesehen.

• Einfach, verstandlich und benotigt relativ wenig Managementaufwand.

• Name Wasserfallmodell: Produkte einer Phase ”fallen“ wie bei einem Wasserfall in die nachstePhase.

Das Wasserfallmodell: ProdukteAm Ende jeder Aktivitat stehen fertige Dokumente

Machbarkeits-studie

Anforderungs-analyse

System-entwurf

Codieren &Modultest

Integrations-& Systemtest

Auslieferung &Installation

Wartung

Lastenheft

Pflichtenheft

Pflichtenheft und Anforderungsspezifikation

Softwarearchitektur undFeinentwurf

Software-Komponenten

Handbücher

MachbarkeitsstudieDie einzelnen Aktivitaten / Phasen

• Prufen der fachlichen und technischen Durchfuhrbarkeit,

– Softwaretechnische Realisierbarkeit,

– Verfugbarkeit von Entwicklungs- und Zielmaschinen.

• Prufen alternativer Losungsvorschlage,

– Beispiel: Kauf und Anpassung von Standardsoftware vs. Individualentwicklung.

• Prufen der personellen Durchfuhrbarkeit.

• Prufen der okonomischen Durchfuhrbarkeit.

• Produkt u.a.: Das Lastenheft

27

– reprasentiert die fachlichen, wirtschaftlichen, technischen und organisatorischen Erwartungendes Auftraggebers und

– dient als Grundlage zur Erstellung des Pflichtenheftes durch den Auftragnehmer.

Anforderungsanalyse und EntwurfDie einzelnen Aktivitaten / Phasen

• Anforderungsanalyse → Pflichtenheft Das ”was“

– basiert evtl. auf einer Machbarkeitsstudie,

– produziert funktionale und nicht-funktionale Systembeschreibung, Zeitverhalten der einzelnenFunktionen, Schnittstellen, Ziel-Hardwareumgebung, etc.

– Eine der schwierigsten Aufgaben in der Software-Entwicklung besteht darin, die tatsachlichenAnforderungen der Anwender zu ermitteln.

– Interaktion zwischen Anwender und Entwickler ist notig.

• Entwurf → Systemarchitektur Das ”wie“

– produziert z.B. Spezifikation der Komponenten fur die Implementierung, d.h. Schnittstellenmit Definition der Import- / Export-Beziehungen zwischen Komponenten

– Der detaillierte Entwurf spezifiziert dann die Eigenschaften der einzelnen Komponenten.

Implementierung und TestDie einzelnen Aktivitaten / Phasen

• Implementierung → Software-Komponenten

– Produziert Modulrumpfe in einer ausfuhrbaren Sprache (Programmiersprache) nach Vorgabeder Systemarchitektur,

– Test einzelner Module,

– Programmdokumentation,

– genannt: ”programming-in-the-small“.

• Test und Integration → Softwaresystem, Testplane und Testergebnisse

– Zusammenfugen der einzelnen Module zum System,

– Produziert Testplane, Testtreiber, Testergebnisse fur Gruppen von Modulen (Teilsysteme,Komponenten) und das Gesamtsystem,

– genannt: ”programming-in-the-large“.

Installation, Inbetriebnahme und AbnahmeDie einzelnen Aktivitaten / Phasen

• Installation, Inbetriebnahme und Abnahme → Technische Handbucher, Benutzungshandbucher

– produziert Installation der lauffahigen Software auf der Zielmaschine, Installationsanleitung,Uberfuhrung vorhandener Daten, Schulung, Nutzungsbeschreibung

• Die Abnahmephase: Tatigkeiten

– Mit der Ubernahme verbunden ist im Allgemeinen ein Abnahmetest.

– Innerhalb einer Abnahme-Testserie ist es auch sinnvoll, Belastungstests durchzufuhren.

– Ab diesem Zeitpunkt unterliegt das Produkt dann der Wartung & Pflege.

28

Wartung und PflegeDie einzelnen Aktivitaten / Phasen Wartung → verandertes Softwaresystem

• Produziert Veranderungen (neue Versionen) aller Ergebnisse aus allen vorigen Phasen je nachAnforderung,

• Zweierlei Arten der Wartung (Maintenance):

progressiv Modifikation funktionaler und nicht-funktionaler Aspekte: Pflegekorrektiv Fehlerbehebung, Optimierung

Software altert [Parnas 1994].

Aufteilung der Wartungskosten

%-Anteil der Wartungskosten an den Entwicklungskosten [Pressman and Ince 2000]

Qualitatsmerkmale fur Produktnutzung bzw. Wartung/Pflege

• Produktnutzung

– Die Qualitatsmerkmale Zuverlassigkeit, Verfugbarkeit, Effizienz, Korrektheit, Sicherheit (Sa-fety und Security) und Ergonomie sind zentral.

– Im Wesentlichen geht es hier um externe Qualitatsmerkmale.

• Wartung & Pflege

– Die Merkmale Anderbarkeit, Modularitat, Portierbarkeit, Testbarkeit und Verstandlichkeitkommen hinzu.

– Im Wesentlichen geht es hier um interne Qualitatsmerkmale.

• Verbesserung der Wartung durch Sanierung

– Ziel: Verbesserung der internen Qualitatsmerkmale∗ Aufwand fur Veranderungen verringern,∗ Wirtschaftlichkeit steigern.

– Stichwort: Refactoring [Fowler et al. 1999, Kerievsky 2004, Roock and Lippert 2004].

Phasenubergreifende Aspekte

Dokumentation: Alle Phasen produzieren Dokumente, zumeist verschiedenen Typs.

Verifikation: Die Ergebnisse mussen auf Korrektheit gegen die Spezifikation der Anforderungen uber-pruft werden.

Validation: Die Ergebnisse mussen gegen die tatsachlichen Anforderungen uberpruft werden.

Management: Projektorganisation, Prozesskontrolle, Konfigurationsverwaltung, etc.

29

Probleme mit dem Wasserfallmodell

• Es ist nicht immer sinnvoll

– alle Entwicklungsschritte in der vollen Breite und vollstandig durchzufuhren und

– alle Entwicklungsschritte sequentiell durchzufuhren.

• Haufig sind Ruckschritte notig weil:

– Falsche Anforderungsdefinition: falsch verstanden oder gesagt, nicht realisierbar,

– Tatsachliche Anforderungen konnen oft nur durch den praktischen Einsatz eines Systems uber-pruft und ermittelt werden.

• Die Anforderungen andern sich haufig.

• I.A. kann eine Phase nicht komplett abgeschlossen werden, bevor die nachste beginnt.

• Bestenfalls geeignet, wenn die Anforderungen tatsachlich vollstandig bekannt sind.

Probleme mit dem Wasserfallmodell (Forts.)

• Gefahr, dass die Dokumentation wichtiger wird als das eigentliche System,

• Risikofaktoren werden u.U. zu wenig berucksichtigt, da der einmal festgelegte Entwicklungsablaufdurchgefuhrt wird. Nur die (optionale) Machbarkeitsstudie dient der einmaligen Risikoabschatzung.

• In der Praxis werden die einzelnen Phasen daher nicht streng sequentiell, sondern nebenlaufigdurchlaufen.

• Trotzdem: Manager lieben es!

2.3 Iterative, Inkrementelle und Evolutionare Entwicklung

Iterative, Inkrementelle und Evolutionare Entwicklung als Verbesserung des Wasserfallm-odells[Sommerville 2007] Existierende Systeme mussen berucksichtigt werden:

Definiere System-anforderungen

Bewerte existierendeSysteme

Schlage System-änderungen vor

ÄndereSystem

ExistierendeSysteme

Neue Systeme

Typische Probleme mit evolutionarer EntwicklungProbleme:

• Der Prozess ist nicht wirklich ”sichtbar“ Systeme sind oft schlecht strukturiert.

• Besondere Programmierkenntnisse sind evtl. notig.

• Vertragsgestaltung

30

– Festpreise bei Vertragsabschluss (Werkvertrage)

– Dienstleistungsvertrage konnen eine Losung darstellen, erfordern aber eine gute Vertrauens-basis zwischen Auftraggeber und -nehmer.

Anwendbarkeit

• fur kleine bis mittelgroße (interaktive) Systeme,

• fur Teile von großeren Systemen (z.B. die Benutzungsschnittstelle),

• Prioritaten fur Anforderungen,

• Fur Systeme mit kurzer Lebensdauer → weiß man das vorher?

2.4 Software-Prototypen

Software-Prototypen

Definition 3 (Evolutionare Prototypen). • Ziel ist, mit den Anwendern/Kunden von einer initialenVersion per ”Evolution“ zu einem nutzbaren System zu kommen.

• Das sollte mit einigermaßen gut verstandenen (Teil-) Anforderungen starten.

Definition 4 (Throw-away Prototyping (explorativ)). • Ziel ist, (ausschließlich) die Anforderungenbesser zu verstehen.

• Wenn man denn gar nicht weiß, wo es hin gehen soll.

Definition 5 (Experimentelle Prototypen). • Dienen zum Erkunden der technischen Machbarkeit.

Horizontale vs. vertikale Prototypen

Definition 6 (Horizontaler Prototyp). • Realisiert nur spezifische Ebenen des Systems.

• Die betreffende Ebene wird moglichst vollstandig realisiert.

Definition 7 (Vertikaler Prototyp). • Implementiert ausgewahlte Teile des Zielsystems vollstandigdurch alle Ebenen hindurch.

• Dort geeignet, wo die Funktionalitats- und Implementierungsoptionen noch offen sind.

Horizontaler und vertikaler Prototyp

31

vertikalerPrototyp

vertikalerPrototyp

horizontalerPrototyp

horizontalerPrototypBenutzungsoberfläche

Anwendung

Netzanbindung Datenhaltung

Systemsoftware

Unterscheiden lassen sich Prototypen in diesem Modell in horizontale und vertikale Prototypen. Ineinem horizontalen Prototypen werden nur spezifische Ebenen der zukunftigen Software realisiert, bspw.die Benutzeroberflache. Die entsprechende Ebene wird dabei moglichst vollstandig realisiert, die mit die-ser Ebene verknupften Funktionalitaten sind jedoch nicht vorhanden. Durch diese Moglichkeit eignensich horizontale Prototypen besonders fur Demonstrationszwecke, bei denen das optische Erscheinungs-bild der Software im Vordergrund steht. Bezogen auf die Benutzerschnittstelle bedeutet dies, dass dieProgrammoberflache sichtbar ist, die Funktionalitat jedoch fehlt. In einem vertikalen Prototypen werdendagegen einzelne Aspekte der Software uber alle Ebenen hinweg realisiert. Dies kann notwendig sein,um die Umsetzbarkeit bestimmter technischer Anforderungen zu testen. Vertikale Prototypen sind daherfur Labormuster oder die Entwicklung von Pilotsystemen geeignet Bischofberger and Pomberger [1992],Pomberger and Blaschek [1996].

In der Literatur nicht genannt, aber fur die Praxis vorstellbar, sind auch Kombinationen beiderTypen, die begrenzte Ausschnitte des Zielsystems uber mehrere Ebenen hinweg enthalten. Zwischeneinem Prototypen und der fertig gestellten Software kann es daruber hinaus mehrere Beziehungen gebenFloyd [1984]:

Explorativer Prototyp Dieser Prototyp wird entwickelt, um neue Erkenntnisse zu gewinnen und Ideenzu uberprufen. Es besteht nicht das vorrangige Ziel, eine marktfahige Software zu entwickeln. DieBeziehung zwischen Prototyp und fertiger Software ist nicht festgelegt. Diese Form von Prototypenwird haufig in Universitaten und Forschungseinrichtungen verwendet.

Experimenteller Prototyp Dieser Prototyp wird verwendet, um fur bereits bekannte Zielsetzungenund feststehende Anforderungen Losungsmoglichkeiten zu untersuchen, zu bewerten und zu ver-gleichen. Der Prototyp ist dabei nicht Teil der zu entwickelnden Software, sondern dient nur zuTestzwecken. Die Entwicklung erfolgt unter Vernachlassigung von Qualitatsanforderungen mit sogeringem Aufwand wie moglich, da er nur fur diesen einen Einsatz dient und anschließend nichtmehr verwendet wird.

Evolutionarer Prototyp Dieser Prototyp wird in mehreren inkrementellen Schritten zu einem voll-standigen Produkt weiterentwickelt. Basis fur Weiterentwicklungen sind die Ergebnisse, die aus derErprobung des Prototypen hervorgehen und vom Auftraggeber gewunschte Eigenschaften. Wesent-lich ist bei dieser Art der Prototypenerstellung die konsequente Beachtung von Entwicklungs- undQualitatsstandards.

Die sehr verschiedenen Kategorisierungsmoglichkeiten von Prototypen machen deutlich, dass eine genaueDefinition des Diskussionsgegenstandes erforderlich ist, um Missverstandnisse zu vermeiden.

32

Prototyp vs. fertiges Softwaresystem

• Prototypen dienen primar zur Klarung von Problemen �I can’t tell you what I want, but I’ll knowit when I see it�

• Neuere Entwicklungen z.B.: Extreme Programming & Agile Methoden [Beck and Andres 2004,Eckstein and Josuttis 2004] Basiert u.a. auf sehr kleinen Inkrementen, standiger Code-Verbesserung,testgetriebener Entwicklung, Nutzer-Involvierung in das Entwicklungsteam, Paar-Programmierung,etc.

Software-Prototyp vs. Konventioneller Prototyp

• Ein Software-Prototyp ist nicht das erste Muster einer großen Serie von Produkten.

– Gegenbeispiel: Massenproduktion in der Autoindustrie

• Ein Software-Prototyp zeigt ausgewahlte Eigenschaften des Zielproduktes im praktischen Einsatz.

– Analoges Beispiel: Pappmodell einer Brucke

Probleme mit Prototypen

• Anwender haben oft Schwierigkeiten, zwischen Prototyp und Produktionssystem zu unterschieden.

• Gefahr, dass in nachfolgenden Versionen die komplette Systemarchitektur uberarbeitet werdenmuss.

⇒ Refactoring / Sanierung (siehe oben).

Betrachtete VorgehensmodelleIn LE 2):

• Das Wasserfallmodell

• Iterative, Inkrementelle und Evolutionare Entwicklung

Spater:

• Rational Unified Process ⇒ LE 4)

• Das V-Modell ⇒ LE 9)

Weitere interessante Modelle, die hier nicht betrachtet werden:

• Spiral-Modell [Boehm 1988, Boehm et al. 1998]

• Catalysis [D’Souza and Wills 1998]

Das Spiralmodell wurde von Boehm beschrieben Boehm [1988]. Es handelt sich um ein Metamodell,dessen Konzept die Entwicklung von Software in Teilprodukte und Verfeinerungsebenen zerlegt. In jederVerfeinerungsebene sind dabei vier Schritte zu durchlaufen:

1. Identifikation der Ziele, die fur die Erstellung des Teilprodukts erforderlich sind. Entscheidung uberalternative Losungsmoglichkeiten zur Erstellung des Teilprodukts. Ermittlung von Randbedingun-gen, die bei der Wahl der Alternativen zu beachten sind.

2. Evaluation der Alternativen unter Berucksichtigung der Ziele und Randbedingungen. Sofern Risikenfur die Durchfuhrung von Alternativen identifiziert wurden, sind Strategien zur Uberwindung derRisken zu entwickeln, z.B. Prototypenerstellung, Simulationen oder Benutzerbefragungen.

3. Je nach verbliebenem Risiko wird ein geeignetes Vorgehensmodell fur die Durchfuhrung diesesSchrittes gewahlt, z.B. Wasserfall-Modell, V-Modell oder Rapid Prototyping. Zur Risikominimie-rung ist auch die Kombination mehrerer Vorgehensmodelle moglich.

33

4. Uberprufung der vorhergehenden drei Schritte. Planung von Zielen und Ressourcen fur den nachstenZyklus. Darin enthalten kann auch eine Aufteilung der Ergebnisse in Teilprodukte sein, die dannseparat weiterentwickelt werden. Einverstandnis uber den nachsten Zyklus sicherstellen.

Das mehrfache Durchlaufen dieser vier Schritte wird als Spirale dargestellt.Das Spiralmodell ist ein risikogetriebenes Modell, das als Hauptziel die Minimierung von Risiken

definiert. Die Ziele fur einen Zyklus werden aus den Ergebnissen des vorherigen Zyklus abgeleitet. Einweiteres Ziel ist die Reduzierung der Entwicklungskosten. Dafur wird die Entwicklung zunachst mit dengrundlegenden Konzepten begonnen und die Erstellung der Software mit moglichst eng aneinander lie-genden Spiralzyklen durchgefuhrt. Die Fertigstellung der Entwicklung wird durch Analysen des erreichtenProdukts definiert. Durch die kritische Betrachtung von Zielsetzung und Anforderungen kann die teureEntwicklung unnotiger Funktionen vermieden werden.

LernzieleLernen, dass

• ein Vorgehensmodell eine Reprasentation des Entwicklungsprozesses darstellt,

nicht das Software-Produkt.

• die grundsatzlichen Aktivitaten Anforderungsanalyse, Entwurf, Implementierung, Integration/Testund Wartung sind.

• inkrementelle/iterative/evolutionare Modelle den Prozess als Zyklus von Aktivitaten beschreiben.

• es verschiedene Arten von Prototypen gibt.

Fur vorgegebene Szenarien (grob) ein Prozess-Modell oder eine Kombination von Prozess-Modellen vor-schlagen und begrunden konnen.

34

LiteraturD. Alur, J. Crupi, and D. Malks. Core J2EE Patterns: Best Practices and Design Strategies. Prentice Hall, 2nd edition, 2003.

K. Barclay and J. Savage. Object Oriented Design with UML and Java. Elsevier Buttorworth-Heinemann, 2004. http://www.dcs.napier.ac.uk/ kab/jeRo-me/jeRome.html.

D. Barnes and M. Kolling. Java lernen mit BlueJ. Pearson, 2006. ISBN 13:978-3-8273-7152-2.

K. Beck and C. Andres. Extreme Programming Explained: Embrace Change. The XP Series. Addison-Wesley Professional, 2nd edition, 2004. ISBN 0321278658.

H. Benington. Production of large computer programs. In Proceedings of the ONR Symposium on Advanced Program Methods for Digital Computers, 1956.

C. Berry, J. Carnell, M. Juric, M. Kunnumpurath, N. Nashi, and S. Romanosky. J2EE Design Patterns Applied. Wrox Press, 2002.

A. Bien. J2EE Patterns. Addison-Wesley, 2002.

W. Bischofberger and G. Pomberger. Prototyping oriented software development concepts and tools. Springer-Verlag, Berlin, 1992.

B. Boehm. Software Engineering Economics. Prentice-Hall, 1981.

B. Boehm. Verifying and validating software requirements and design specifications. IEEE Software, 1(1):75–88, 1984.

B. Boehm. A spiral model of software development and enhancement. IEEE Computer, 21(5):61–72, 1988.

B. Boehm, B. Clark, E. Horowitz, C. Westland, R. Madachy, and R. Selby. Cost models for future software life cycle processes: Cocomo 2.0. Annals ofSoftware Engineering, 1, 1995.

B. Boehm, A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. Using the WinWin spiral model: a case study,. IEEE Computer, 31(7):33–44, 1998.

G. Booch. Object-Oriented Analysis and Design with Applications. Benjamin/Cummings, 2nd edition, 1994.

G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998.

G. Booch, R. Maksimchuk, M. Engel, B. Young, J. Conallen, and K. Houston. Object-Oriented Analysis and Design with Applications. Addison-Wesley, 3ndedition, 2007. ISBN 0-201-89551-X.

D. Broemmer. J2EE Best Practices: Java Design Patterns, Automation, and Performance. Wiley, 2002.

A.-P. Brohl and W. Droschel. Das V-Modell, der Standard fur die Softwareentwicklung mit Praxisleitfaden. Oldenbourg, Munchen, Wien, 1993.

F. Brooks. The Mythical Man Month. Addison-Wesley, 2nd edition, 1995. (First edition 1975).

M. Broy and D. Rombach. Software engineering. Informatik Spektrum, 25(6):438–451, 2002.

M. Broy, M. Jarke, M. Nagl, and D. Rombach. Manifest: Strategische Bedeutung des Software Engineering in Deutschland. Informatik-Spektrum, 29(3):210–221, 2006. .

B. Brugge and A. DUTOIT. Object-Oriented Software Engineering Using UML, Patterns, and Java. Prentice Hall, 2nd edition, 2004.

B. Brugge and A. Dutoit. Objektorientierte Softwaretechnik mit UML, Entwurfsmustern und Java: Bafog-Ausgabe. Pearson, 2006. ISBN 13:978-3-8273-7261-1.

Bundestag. Verfugbarkeit der webbasierten hartz-iv-software a2ll, 2006. http://www.heise.de/newsticker/meldung/88318,http://dip.bundestag.de/btd/16/049/1604938.pdf.

F. Buschmann et al. Pattern-orientierte Software-Architektur – Ein Pattern-System. Addison-Wesley, 2002. ISBN: 3827312825.

J. Caumanns, H. Weber, A. Fellien, H. Kurrek, O. Boehm, J. Neuhaus, J. Kunsmann, and B. Struif. Die eGK-Losungsarchitektur Architektur zurUnterstutzung der Anwendungen der elektronischen Gesundheitskarte. Informatik-Spektrum, 29(5):341–348, Oct. 2006.

T. DeMarco. Controlling Software Projects. Yourdon Press, New York, 1982.

Detienne. Software-Design: Cognitive Aspects. Springer-Verlag, 2002.

E. Dijkstra. Notes on structured programming. In O. Dahl et al., editors, Structured Programming, pages 1–82. Academic Press, London, 1972.

Douglas Schmidt et al. Pattern-orientierte Software-Architektur. Muster fur nebenlaufige und vernetzte Objekte. dpunkt Verlag, 2002. ISBN: 3898641422.

D. F. D’Souza and A. C. Wills. Objects, Components, and Frameworks with UML: The Catalysis Approach. Addison-Wesley Professional, 1998. ISBN 0201310120.

J. Eckstein and N. M. Josuttis. Agile Softwareentwicklung im Großen: Ein Eintauchen in die Untiefen erfolgreicher Projekte. dpunkt Verlag, 2004.

A. Endres and D. Rombach. A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories. Addison Wesley, 2003.

E. A. Euler, S. D. Jolly, and H. Curtis. The failures of the mars climate orbiter and mars polar lander: A perspective from the people involved. InProceedings of Guidance and Control 2001, AAS 01-074, 2001.

M. S. Fisher. Software Verification and Validation: An Engineering and Scientific Approach. Springer-Verlag, 2007. ISBN 978-0-387-32725-9.

C. Floyd. A systematic look at prototyping. In R. Budde, K. Kuhlenkamp, L. Mathiassen, and H. Zullighoven, editors, Approaches to Prototyping, pages1–18. Springer-Verlag, 1984.

M. Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, third edition edition, 2003.

M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts. Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional, 1999. ISBN0201485672.

M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, and R. Stafford, editors. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.

E. Freeman and E. Freemann. Entwurfsmuster von Kopf bis Fuß. O’Reilly, 2006.

E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley, 1996.

C. Ghezzi, M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering. Prentice Hall, 2nd edition edition, 2003.

T. Gilb and D. Graham. Software Inspection. Addison-Wesley, 1993.

R. L. Glass. Facts and Fallacies of Software Engineering. Addison-Wesley, 2002. ISBN 0321117425.

210

Goldberg and Rubin. Succeeding with Objects: Decision Frameworks for Project Management. Addison-Wesley, 1995.

T. Grams. Denkfallen und Programmierfehler. Springer-Verlag, Berlin, 1990.

D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–274, June 1987.

W. Hasselbring and R. Reussner. Toward trustworthy software systems. IEEE Computer, 39(4):91–92, Apr. 2006.

B. Hindel, K. Hormann, M. Muller, and J. Schmied. Basiswissen Software-Projektmanagement. dpunkt.verlag, Heidelberg, 2004.

M. Hitz, G. Kappel, E. Kapsammer, and W. Retschitzegger. UML@Work: Objektorientierte Modellierung mit der UML 2. dpunkt Verlag, 3. auflage edition,2005.

D. Hoffman and D. Weiss, editors. Software Fundamentals, Collected Papers by David L. Parnas. Addison-Wesley, 2001.

IEEE. Standard Glossary of Software Engineering. The Institute of Electrical and Electronics Engineers, New York, ieee std 610.12-1990 edition, 1990.

ISO/IEC 9126-1. Iso/iec 9126-1: Software engineering – product quality – part 1: Quality model, June 2001.

I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering. Addison-Wesley, 1992.

I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison-Wesley, 1999.

R. Jesse. Das Einsteigerseminar JavaBeans. Vmi Buch, 2002. ISBN 3826672151.

H.-W. Jung, S.-G. Kim, and C.-S. Chung. Measuring software product quality: A survey of ISO/IEC 9126. IEEE Software, 21(5):88–92, 2004. .

J. Kerievsky. Refactoring to Patterns. Addison-Wesley Professional, 2004. ISBN 0321213351.

J. Kramer. Is abstraction the key to computing? Commun. ACM, 50(4):36–42, 2007. .

P. Kruchten. The 4+1 view model of architecture. IEEE Software, 12(6):42–50, Nov. 1995.

D. Lea. Concurrent Programming in Java: Design Principles and Patterns. Addison-Wesley, 2nd edition, 2000.

J. Link. Unit Tests mit Java: Der Test-First-Ansatz. dpunkt Verlag, 2002.

J. Ludewig and H. Lichter. Software Engineering: Grundlagen, Menschen, Prozesse, Techniken. dpunkt.verlag, 2006.

F. Marinescu. EJB Design Patterns: Advanced Patterns, Processes, and Idioms. Wiley, 2002.

B. Meyer. Object-oriented Software Construction. Prentice Hall, 2nd edition edition, 2001.

R. Mugrudge and W. Cunningham. FIT for developing software: framework for integrated tests. Prentice Hall, 2005.

P. Naur and B. Randell, editors. Software Engineering: Report on a Conference, NATO Scientific Affairs Division, 1968.

A. Noordvyk. Therac-tivity: Data-entry errors kill five patients in Panama. Software Engineering Notes, 26(6):8, Nov. 2001.

B. Oestereich. Analyse und Design mit der UML 2.1. Oldenbourg, 8. auflage edition, 2006.

A. Pais, P. Oliveira, and P. Leite. Robustness diagram: a bridge between business modelling and system design. In Y. Wang, S. Patel, and R. Johnston,editors, Proc. 7th International Conference on Object-Oriented Information Systems, Lecture Notes in Computer Science, pages 530–539, London, Aug. 2001.Springer-Verlag.

D. L. Parnas. Software Engineering or Methods for the Multi-Person Construction of Multi-Version Programs, volume 23 of Lecture Notes in Computer Science, ProgrammingMethodology. Springer-Verlag, 1974. ISBN 3-540-07131-8.

D. L. Parnas. Software aging. In Proceedings of the 16th international conference on Software engineering (ICSE 1994), pages 279–287, Los Alamitos, CA, USA,1994. IEEE Computer Society Press. ISBN 0-8186-5855-X.

D. Paulish. Architecture-Centric Software Project Management. Addison-Wesley, 2002.

C. Piemont. Komponenten in Java. dpunkt.verlag, 1999.

D. Pilone and N. Pitman. UML 2.0 in a Nutshell. O’Reilly, 2006.

K. Pohl. Requirements Engineering. dpunkt Verlag, 2007.

G. Pomberger and G. Blaschek. Object-Orientation and Prototyping in Software Engineering. Prentice Hall, 1996.

R. Pooley and P. Wilcox. Applying UML: Advanced Application. Elsevier Buttorworth-Heinemann, 2004. http://www.macs.hw.ac.uk/ umlbook/.

G. Popp. Konfigurationsmanagement mit Subversion, Ant und Maven. dpunkt Verlag, 2. edition, 2008. ISBN 13 978-3-89864-487-7.

R. S. Pressman and D. Ince. Software Engineering: A Practitioner’s Approach. McCraw-Hill, London, 5th edition, 2000. European Adaption.

S. Prowell, C. Trammell, and R. Linger. Cleanroom software engineering: Technology and Process. The SEI series in software engineering. Addison-Wesley,Reading, MA, 1999.

A. Rausch, R. Hohn, M. Broy, K. Bergner, and S. Hoppner. Das V-Modell XT: Grundlagen, Methodik und Anwendungen. dpunkt.verlag, Heidelberg, 2007.

S. Roock and M. Lippert. Refactorings in großen Softwareprojekten: Komplexe Restrukturierungen erfolgreich durchfuhren. dpunkt Verlag, 2004. ISBN 13 978-3-89864-207-1.

Royce. Software Project Management: A Unified Framework. Addison-Wesley, 1998.

W. Royce. Managing the development of large software systems: concepts and techniques. In Proceedings of the Ninth International Conference on SoftwareEngineering, pages 328–338, 1987.

J. Rumbaugh, G. Booch, and I. Jacobson. The Unified Modeling Language Reference Manual. Addison-Wesley, 1998.

B. Rumpe. Modellierung mit der UML. Springer-Verlag, 2004.

C. Rupp, S. Queins, and B. Zengler. UML 2 glasklar: Praxiswissen fur die UML-Modellierung. Hanser, 3. auflage edition, 2007. ISBN 978-3-446-41118-0.

J. Schlierf and R. Weber. Programmieren mit Swing. Hanser, 1999.

211

M. Shaw and D. Garlan. Software architecture: perspectives on an emerging discipline. Prentice Hall, 1996.

Shneiderman. Designing the User Interface. Addison-Wesley, 3rd edition, 1999.

H. M. Sneed. Software-Management. Muller, Koln, 1987.

H. M. Sneed and M. Winter. Testen objektorientierter Software. Hanser Verlag, 2002.

I. Sommerville. Software Engineering. Addison-Wesley, 8th edition edition, 2007.

I. Sommerville. Software Engineering (deutsch). Addison-Wesley, 8. auflage edition, 2008. ISBN 13:978-3-8273-7257-4.

H. Stachowiak. Allgemeine Modelltheorie. Springer-Verlag, Wien, 1973.

P. Stevens and R. Pooley. Using UML: software engineering with objects and components. Addison-Wesley, 1999.

H. Storrle. UML 2 erfolgreich einsetzen. Addison-Wesley, 2005.

C. Szyperski. Component Software: Beyond Object-Oriented Programming. Adiison-Wesley, Second 2002. ISBN 0-201-74572-0.

C. Thilmany. .NET Patterns: Architecture, Design, and Process. Addison-Wesley, 2003.

W. F. Tichy. RCS – A system for version control. Software – Practice and Experience, 15(7):637–654, July 1985.

W. F. Tichy. Tools for software configuration management. In J. F. H. Winkler, editor, Proceedings of the International Workshop on Software Version andConfiguration Control (SCM), January 27-29, 1988, Grassau, Germany, volume 30 of Berichte des German Chapter of the ACM, pages 1–20. Teubner, Jan. 1988.ISBN 3-519-02671-6.

Vorgehensweise bei der Erstellung von Lasten/Pflichtenheften. VDI, Berlin, vdi richtlinie 2519 edition, 2001.

M. Volter, A. Schmid, and E. Wolff. Server Component Patterns: Component Infrastuctures illustrated with EJB. Wiley, 2002.

J. Warmer and A. Kleppe. The Object Constraint Language: Getting Your Models Ready for MDA. Addison-Wesley, second edition, 2003.

Weinberg. The Psychology of Computer Programming. Dorset House, 1973 / 1998.

F. Westphal. Testgetriebene Entwicklung mit JUnit & FIT for developing software: framework for integrated tests. dpunkt.verlag, 2006.

K. Wiegers. Peer Reviews in Software. Addison-Wesley, 2002.

M. Winter. Methodische objektorientierte Softwareentwicklung. dpunkt.verlag, 2005. 3-89864-273-9.

H. Wußing and W. Arnold. Biographien bedeutender Mathematiker. Aulis Verlag Deubner & Co., Koln, 1975.

A. Zeller and J. Krinke. Open-Source-Programmierwerkzeuge: Versionskontrolle - Konstruktion - Testen - Fehlersuche. dpunkt Verlag, 2. edition, 2003.

212