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