Softwaretechnologie II 4. Juni 1996: Erster Start der "Ariane-5"

Transcrição

Softwaretechnologie II 4. Juni 1996: Erster Start der "Ariane-5"
Softwaretechnologie II
Heinrich Hußmann
Wintersemester 2000 / 2001
Technische Universität Dresden
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
4. Juni 1996: Erster Start der "Ariane-5"
• Kosten des Ariane-5-Programms
bis 1996:
ca. 8 Milliarden US-$
• Wert des zerstörten Satelliten:
ca. 500 Millionen US-$
Technische Universität Dresden
• Während des Flugs läuft ein
unnötiges Kalibrierungsprogramm für die
Trägheitssensoren.
• Die gemessenen Werte der
Ariane-5 überschreiten die in
der Ariane-4-Software
vorgesehehen Bereiche.
• Die (Ada-)Exception wird
durch Anhalten des
Steuerungscomputers
behandelt, um auf ein
zweites redundantes System
umzuschalten.
• Im zweiten System tritt der
gleiche Software-Fehler auf
und wird identisch
behandelt.
Prof. Hußmann
Seite 1
Softwaretechnologie II
Software-Katastrophe: Kein Einzelfall
• Finanzielle Katastrophen, Tendenz "steigend":
– 1981: US Air Force Command&Control Software überschreitet
Kostenvoranschlag fast um den Faktor 10 (3,2 Mio US-$)
– 1987: Integration der kalifornischen Systeme zur Führerschein- und
KFZ-Registrierung abgebrochen: 44 Mio US-$
– 1992: Integration des Reservierungssystems SABRE mit anderen
Reservierungsystemen abgebrochen: 165 Mio. US-$
– 1997: Entwicklung des Informationssystems SACSS für den Staat
Kalifornien abgebrochen: 300 Mio US-$
• Terminkatastrophen:
– 1994: Eröffnung des Denver International Airport um 9 Monate
verzögert wegen Softwareproblemen im Gepäcktransport-System
• Technik-Katastrophen:
– März 1999: Fehlstart einer Titan/Centaur-Rakete wegen falscher
Software-Version
– September 1999: Verlust der Sonde "Mars Climate Orbiter" wegen
falscher Einheitenumrechnung
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Die permanente Softwarekrise ?
• 1965: Der Begriff der Softwarekrise etabliert sich in Industrie und
Wissenschaft.
– Fehler in Computersystemen sind fast immer auf Softwarefehler
zurückzuführen.
– Software wird nicht termingerecht und/oder zu höheren Kosten als
geschätzt fertiggestellt.
– Software entspricht oft nicht den Anforderungen ihrer Benutzer.
• Studie von 1979 zu Softwareprojekten (USA):
– 75% der Ergebnisse nie eingesetzt
– 19% der Ergebnisse stark überarbeitet
– 6% benutzbar.
• Studie von 1994 zu Software-Großprojekten (IBM Consulting):
– 55% Kostenüberschreitung
– 68% Terminüberschreitung
– 88% Bedarf für starke Überarbeitung
Technische Universität Dresden
Prof. Hußmann
Seite 2
Softwaretechnologie II
Lehrstuhl Softwaretechnologie
Prof. Dr. Heinrich Hußmann
Dürerstr. 26, 2. OG, Raum 258
Telefon 463-8464
Email [email protected]
Sprechzeit: nach Vereinbarung
Übungsleitung:
Mike Fischer
Dürerstr. 26, 2. OG, Raum 259
Telefon 463-8555
Email [email protected]
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Voraussetzungen, Übungen zur Vorlesung
• Voraussetzungen:
– Softwaretechnologie I
– Praktikum Softwaretechnologie
» Basiserfahrung mit Team-Projekten
– generell gute Programmierkenntnisse
» Wissen über Programmiersprachen wird hier nicht vermittelt !
» Übungsaufgaben im wesentlichen an Java orientiert
• Übungsbetrieb:
– Anzahl der Übungsgruppen?
– Übungsaufgaben im WWW
– Eine Praktikumsaufgabe je Teilnehmer
Technische Universität Dresden
Prof. Hußmann
Seite 3
Softwaretechnologie II
Literatur
• Ian Sommerville: Software Engineering, 6th edition,
Addison-Wesley 2000.
• Helmut Balzert: Lehrbuch der Software-Technik (2 Bände),
Spektrum Akademischer Verlag 1996 und 1998.
• Pankaj Jalote: An Integrated Approach to Software Engineering,
2nd edition, Springer 1997.
• Scott W. Ambler: Building Object Applications That Work.
SIGS/Cambridge University Press 1998.
• Weitere Literatur bei den einzelnen Kapiteln
• Folien im PDF-Format im WWW
• Laufende Informationen zur Vorlesung:
http://www-st.inf.tu-dresden.de/st2
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
1.1
Softwaresysteme und Softwaretechnologie
Literatur:
Technische Universität Dresden
Sommerville 1.1
Balzert Band 1, LE 1
Jalote Kap. 1
Prof. Hußmann
Seite 4
Softwaretechnologie II
Softwaresysteme
software: computer programs, procedures, rules, and possibly
associated documentation and data pertaining to the operation of a
computer system.
(IEEE Standard Glossary of Software Engineering)
• Softwaresystem: Ein System (oder Teilsystem), dessen
Komponenten aus Software bestehen:
• Klassifikation von Software:
– Generisches Produkt oder Einzelanfertigung (vereinbartes Produkt)?
– Systemsoftware (Betriebssystem, Compiler, Editor, ...) oder
Anwendungssoftware (application software)?
– Produktintegriert (embedded) oder für reine Computersysteme?
– Realzeitanforderungen oder flexiblere Zeitanforderungen?
– Datenintensiv oder berechnungsintensiv?
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Wirtschaftliche Bedeutung von
Informations- und Kommunikationstechnik
3000
Weltweite
Leitindustrien
2500
(Umsatz 1994 in
Milliarden US-$)
2000
1500
1000
500
Quelle: Balzert, Bd. 1
Technische Universität Dresden
Prof. Hußmann
Seite 5
Tourismus
Inform. - und
Komm.-technik
Textilindustrie
Chemieindustrie
Autoindustrie
Militär &
Verteidigung
Maschinenbau
0
ICT =
Information and
Communication
Technology
Softwaretechnologie II
Wirtschaftliche Bedeutung von Software (1)
Westeuropäischer IT-Markt (Volumen in Mio. US-$):
450,000
400,000
350,000
300,000
250,000
Services
200,000
Software
150,000
Hardware
100,000
50,000
0
1998 1999 2000 2001 2002 2003 2004
Quelle: IDC
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Wirtschaftliche Bedeutung von Software (2)
Westeuropäischer IT-Markt (= 29 % Weltmarkt):
Volumen 1999: ca. 212 Mrd. EUR
Jährliche Wachstumsraten (Angaben in%):
16
14
12
10
8
6
4
2
0
Hardware
Software
1997
1998
1999
2000
Services
Quelle: EITO
Technische Universität Dresden
Prof. Hußmann
Seite 6
Softwaretechnologie II
Besonderheiten von Software
Software is a hybrid, halfway between an abstract idea and a physical,
tangible thing. Software is neither land nor sea, but swamp: a hybrid too
thin for the army (software engineering) and too thick for the navy
(computer science).
Brad Cox
•
•
•
•
•
•
•
•
Software ist immateriell.
Software wird nicht durch physikalische Gesetze begrenzt.
Software unterliegt keinem Verschleiß.
Es gibt keine Software-Ersatzteile:
Defekte sind immer Konstruktionsfehler.
Software ist schwer zu vermessen
(„Technische Daten“ von Software?).
Software gilt als relativ leicht änderbar
(im Vergleich zu materiellen technischen Produkten).
Software unterliegt einem ständigen Anpassungsdruck.
Software altert.
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Angestrebte Eigenschaften von Software
• Zuverlässigkeit
– Software darf im Fall des Versagens keine physischen oder
ökonomischen Schäden verursachen.
• Benutzbarkeit
– Software muß sich nach den Bedürfnissen der Benutzer richten.
– Die Benutzerschnittstelle muß ergonomisch und selbsterklärend sein.
– Dokumentation muß in allen Detaillierungsgraden ausreichend zur
Verfügung stehen.
• Wartbarkeit
– Software muß anpaßbar an neue Anforderungen sein.
– Software sollte möglichst plattformunabhängig sein.
• Effizienz
– Software muß ökonomischen Gebrauch von Ressourcen des
unterliegenden Systems machen.
Technische Universität Dresden
Prof. Hußmann
Seite 7
Softwaretechnologie II
Softwaretechnik/Softwaretechnologie
software engineering: The establishment and use of sound engineering
principles in order to obtain economically software that is reliable and
runs on real machines.
(F.L. Bauer, NATO-Konferenz Software-Engineering 1968)
• Prinzipien einer Ingenieursdisziplin: Bereitstellung und
systematische Verwendung von Methoden,Verfahren und
Werkzeugen zur Lösung von Problemstellungen
• Softwaretechnologie, Softwaretechnik:
– Meist als deutsche Synonyme für software engineering gebraucht.
• „Technologie“: Lehre von der Herstellung technischer Produkte
• Terminologie an der TU Dresden:
– Softwaretechnik:
Oberbegriff für alle technischen Aspekte von Software
– Softwaretechnologie: synonym zu 'software engineering',
d.h. Lehre von der Software-Herstellung
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Wachsende Komplexität (1)
• Siemens EWSD V8.1: 12,5 Millionen LOC, ca.190.000 S.
Dokumentation
Technische Universität Dresden
Prof. Hußmann
Seite 8
Softwaretechnologie II
Wachsende Komplexität (2)
• Enterprise-Resource-Planning Software R/3® von SAP
Jahr
Lines of Code
1994
1997 (Rel. 3.1)
1999 (Rel. 4.5)
7 Millionen
30 Millionen
50 Millionen
Anzahl
Funktionsbausteine
14 000
200 000
400 000
• Weitere Zahlen zu R/3 Release 4:
– 11 000 externe Tabellen (Datenbank)
– 500 000 Tabellenfelder (extern und intern)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Zunehmende Qualitätsanforderungen
• Gefundene Defekte in 1000 Zeilen Quellcode
(M. Cusumano, MIT 1990):
– 1977:
– 1994:
7 - 20 Defekte
0,05 - 0,2 Defekte
• Steigerung des Qualitätsniveaus um den Faktor 100 in 13 Jahren.
• Aber: Komplexitätssteigerung muß kompensiert werden !
– Komplexitätssteigerung ca. Faktor 10 in 5 Jahren
• Zunehmende „Altlasten“:
– Anwendungssoftware wird oft 20 Jahre und länger eingesetzt.
– In manchen Betrieben 2/3 der Softwarekosten für Anpassung von
Altsoftware !
Technische Universität Dresden
Prof. Hußmann
Seite 9
Softwaretechnologie II
Aufgabenstellung der Softwaretechnologie
• Softwareentwicklung ist viel mehr als Programmieren.
• Dazu gehören:
– Management großer und extrem komplexer Projekte
– Präzise Erfassung und Erreichung von Kunden- und
Marktanforderungen
– Effizienzsteigerung in der Softwareentwicklung
– Sicherstellung eines hohen Qualitätsniveaus
– Berücksichtigung von Wartbarkeit und existierenden Altsystemen
• Es gehören aber auch dazu:
– Guter Programmierstil
– Effizienter Einsatz leistungsfähiger Programmiersprachen
– Entwicklungswerkzeuge
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
1.2
Phasenmodelle
Literatur:
Technische Universität Dresden
Sommerville 1.2
Jalote Kap. 2
Prof. Hußmann
Seite 10
Softwaretechnologie II
Begriff “Phasenmodell”
• Phasenmodell
(engl. process model oder software development life cycle SDLC)
– Einteilung des Herstellungsprozesses für ein (Software-) Produkt in
definierte und abgegrenzte Abschnitte
» Grobgliederung: Phasen (phases)
» Feingliederung: Schritte (stages, steps)
– Vorgabe einer Reihenfolge in der Bearbeitung der Phasen
– Richtlinie für die Definition von Zwischenergebnissen
» Detailliertes Phasenmodell + Zwischenergebnisdefinition
= „Vorgehensmodell“
• Grundaktivitäten:
–
–
–
–
–
Analyse
Entwurf
Implementierung
Validation (v.a. Test, Integration)
Evolution (v.a. Wartung)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Wasserfall-Modell
Produktdefinition
Analyse
Entwurf
EntwurfsSpezifikation
Implementierung
Code
Test,
Integration
Änderungswünsche
geprüfter
Code
Wartung
W. Royce (1970)
Technische Universität Dresden
Prof. Hußmann
Seite 11
Softwaretechnologie II
Ungefähre Verteilung des Arbeitsaufwandes
10 %
Analyse
Entwurf
20 %
20 %
Implementierung
50 %
Test,
Integration
Wartung
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Parallelität im Entwicklungsprozeß
Ergebnisse
"Makro-Phasen"
Analyse/Entwurf/
Implementierung
Anforderungsspezifikation
Produktdefinition
Entwurfsspezifikation
Subsystem 1
Subsystem 2
Subsystem 3
"Mikro-Phasen"
Analyse/Entwurf/
Implementierung
Code
Subsystem 1
Subsystem 2
Subsystem 3
Zeit
Technische Universität Dresden
Prof. Hußmann
Seite 12
Softwaretechnologie II
Qualitätssicherung im V-Modell
Testfälle
Analyse
Abnahmetest
Testfälle
Grobentwurf
Feinentwurf
Systemtest
Testfälle
Implementierung
Integrationstest
Modultest
Boehm 1979 („V-Modell“)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
V-Modell des BMI (vereinfacht)
Abnahme-Test
Analyse
Subsystem-Test
Test &
Integration
Grobentwurf
Feinentwurf
Implementierung
Prüfaktivitäten
Bröhl/Dröschel 1993
Technische Universität Dresden
Prof. Hußmann
Seite 13
Softwaretechnologie II
Evolutionäre Entwicklung
Aufgabe
Analyse
Prototypen,
Vorversionen
Entwurf
Validation
Implementierung
• Typisch für kleinere Projekte oder experimentelle Systeme
• Bei Objektorientierung auch für größere Projekte anwendbar ?
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
eXtreme Programming (XP)
• Aktuelle, kontrovers diskutierte Entwicklungsmethodik (Kent Beck)
– Konsequente evolutionäre Entwicklung
– Der Programmcode ist das Analyseergebnis, das Entwurfsdokument
und die Dokumentation.
– Code wird permanent (Tagesrhythmus) lauffähig gehalten
– Diszipliniertes und automatisiertes Testen als Qualitätssicherung
– Diverse weitere innovative Techniken (z.B. Paar-Programmierung)
• XP
– wird manchmal als Gegenbewegung zu sauberem Softwareenturf
mißverstanden
– ist nur geeignet für relativ überschaubare, isolierte Anwendungen
– liefert schnell Ergebnisse, aber u.U. auf Kosten der Langlebigkeit
– kann prinzipiell mit traditionelleren Analyse- und Entwurfstechniken
kombiniert werden
Technische Universität Dresden
Prof. Hußmann
Seite 14
Softwaretechnologie II
Spiralmodell
Risikoanalyse
Zielbestimmung,
Beurteilung von
Alternativen
Prototypen
P2
P1
P3
P4
Anfor- Grob- Feinderun- ententgen
wurf wurf
V&V
Code
Integration
V&V
Planung der
nächsten Phase
Abnahme
B. Boehm (1988)
Entwicklung
nächstes
Teilprodukt
Test
V&V = Verifikation & Validation
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Objektorientiertes Spiralmodell
Entwurf
Implementierung
Test
Analyse
Produkte (Releases)
einschl. Prototypen
Technische Universität Dresden
Prof. Hußmann
Seite 15
Softwaretechnologie II
Zweidimensionales Modell
Zeit
Entstehung Ausarbeitung Erstellung
Übergang
(inception) (elaboration) (construction) (transition)
Analyse
Entwurf
Implementierung
Test
Konfigurationsmanagement
Projektmanagement
Tätigkeit
Rational Unified Process 1999 (Jacobson et al., Kruchten)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Aufwandsverteilung und Schwerpunkte
Zeit
Entstehung Ausarbeitung Erstellung
Übergang
(inception) (elaboration) (construction) (transition)
Analyse
Entwurf
Implementierung
Test
Konfigurationsmanagement
Projektmanagement
Tätigkeit
Rational Unified Process 1999 (Jacobson et al., Kruchten)
Technische Universität Dresden
Prof. Hußmann
Seite 16
Softwaretechnologie II
Teilprojekte und Überlappungsgrade
„konservativ“ I1 E1 C1 T1
Teilprojekt 1
Release 1
I2 E2 C2 T2
Release 2
Teilprojekt 2
„aggressiv“
I1 E1 C1 T1
Teilprojekt 1
Release 1
Release 2
I2 E2 C2 T2
Teilprojekt 2
„Standard“
Release 1
I1 E1 C1 T1
Teilprojekt 1
I2 E2 C2 T2
Teilprojekt 2
Technische Universität Dresden
Release 2
Prof. Hußmann
Seite 17
I
E
C
T
Inception
Elaboration
Construction
Transition
Softwaretechnologie II