PM.2.1. Herstellung Großer Softwaresysteme Für Hängebrücken gibt es keine Bastler-Bausätze.

Transkript

1 PM.2 Über die Herstellung großer Softwaresysteme Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden Version , ) Große Systeme 2) Was heißt Software Engineering? 3) Vorgehensmodelle Obligatorisches Lesen Zuser Kap. 1-3 oder Ghezzi Chapter 1 oder Pfleeger Chapter 1; Chap The first International Conference on Software Engineering (ICSE) S. Garfunkel Die schönsten Software-Fehler Peter G. Neumann Das Risk Digest sammelt voller Akribie Softwarefehler Softwaretechnologie Softwaretechnologie, Prof. Uwe Aßmann 1 Prof. Uwe Aßmann, Softwaretechnologie 2 PM.2.1. Herstellung Großer Softwaresysteme Für Hängebrücken gibt es keine Bastler-Bausätze. Michael Jackson, IEEE Software 1/1998 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) Prof. Uwe Aßmann, Softwaretechnologie 3 Softwaretechnologie, Prof. Uwe Aßmann 4

2 Was heißt hier "groß"? Riesige Systeme Klassifikation nach W. Hesse: Klasse Anzahl Code-Zeilen Personenjahre zur Entwicklung sehr klein bis bis 0,2 klein ,2-2 mittel groß Mio sehr groß über 1 Mio. über 200 Telefonvermittlungssoftware EWSD (Version 8.1): 12,5 Mio. Code-Zeilen ca Personenjahre ERP-Software SAP R/3 (Version 4.0) ca. 50 Mio. Code-Zeilen Gesamtumfang der verwendeten Software (Anfang 2000): Credit Suisse 25 Mio. Code-Zeilen Chase Manhattan Bank: 200 Mio. Code-Zeilen Citicorp Bank: 400 Mio. Code-Zeilen AT&T: 500 Mio. Code-Zeilen General Motors: 2 Mrd. Code-Zeilen Prof. Uwe Aßmann, Softwaretechnologie 5 Komplexitätswachstum und Fehlerrate Abkürzungen: EWSD = Elektronisches Wählsystem Digital (Siemens-Produkt) ERP = Enterprise Resource Planning SAP: Deutscher Software-Konzern Prof. Uwe Aßmann, Softwaretechnologie 6 Human Problems 20 0, Anzahl Fehler auf 1000 LOC Programmgröße (1000 LOC) Echte Qualitätsverbesserungen sind nur möglich, wenn die Steigerung der Programmkomplexität überkompensiert wird! Programmers are not educated well To develop To communicate Software construction is a social process It s hard to organize people Software stays, the people go Software evolves, many versions Projects run out of time How to control? Resultierende absolute Fehleranzahl Prof. Uwe Aßmann, Softwaretechnologie 7 Prof. Uwe Aßmann, Softwaretechnologie 8

3 Structural Problems The following figures are taken from the Goose Reengineering Tool, analysing a Java class system [Goose, FZI Karlsruhe, Prof. Uwe Aßmann, Softwaretechnologie 9 Prof. Uwe Aßmann, Softwaretechnologie 10 Partially Collapsed Totally Collapsed Prof. Uwe Aßmann, Softwaretechnologie 11 Prof. Uwe Aßmann, Softwaretechnologie 12

4 Permanente Softwarekrise? The Industry "Software-Krise": Fehler in Computersystemen sind fast immer Softwarefehler. Software wird nicht termingerecht und/oder zu höheren Kosten als geschätzt fertiggestellt. Software entspricht oft nicht den Anforderungen ihrer Benutzer. Begriff der Software-Krise existiert seit 1968 bis heute! 70er Jahre:. Mangelhafte Beherrschung der Basistechnologie 90er Jahre und Milennium:. Grosse (software-)technologische Fortschritte. Mangelhafte Beherrschung des Wachstumstempos und des Anpassungsdrucks We We undoubtedly produce produce software software by by backward backward techniques. D. D. McIlroy, McIlroy, ICSE ICSE Prof. Uwe Aßmann, Softwaretechnologie 13 Life Time of Software Top Players: IBM, Microsoft, HP, Hitachi, Computer Associates, Oracle, Fujitsu, SAP, Bull HN, Novell About 10% of the national turnaround of the US 5% of employees, about the size of car industry PC-game equates Hollywood film ($50 mill. in first week) 2/3 standard software : 1/3 individual software (with growing rate) Im 'Quartal erwirtschaftet Microsoft Umsatz im Bereich von Milliarden US-Dollar. operativer Gewinn: 3-6 Milliarden US-Dollar bewegen. Für das gesamte Geschäftsjahr Umsatz: 59,9 Milliaren bis 60,5 Milliarden US-Dollar operativen Gewinn: 24,2 Milliarden bis 24,4 Milliarden US-Dollar. Prof. Uwe Aßmann, Softwaretechnologie 14 Costs Average: 5 15y max > 35 y (control software, certified systems, data bases) Development time: 1-3y Microsoft (1994): 50% turnaround from products of the last 12 months 50 Products/y new version every months 2/3 of a new version are new Contrary to Grosch s Law, Hardware speed doubles every 2 years Software productivity increases only about < 5% /y. Costs acad. Prototype / acad. Product / Product = 1 : 3 : 3 Commercialization is rather difficult Relation of development and maintenance 40:60 up to 20:80 Development and maintenance are done by different departments Prof. Uwe Aßmann, Softwaretechnologie 15 Prof. Uwe Aßmann, Softwaretechnologie 16

5 Costs: Extreme Requirements Cost Example: The Year 2000 Problem Telecommunication: Failure < 1 h./40 y., working rate % One second failure may cost $5Mio Certification Insurance: certified software must be executable after 40 years German pension rules of the 50s must be processed today. Nobody knows the details anymore!. Solution: write an interpreter for the old assembler. This has happened twice.. COBOL programmers saved space and stored only the last two digits of the year In the 70s, programs should only live 20 years In 2000, catastrophes were prophesied Power plants? Pension insurances (birth dates) From 1996 on, the industry panicked Spent enormous amounts to update software New systems got installed SAP R/3 with date data type Rewriting didn t work Programmers didn t trust the rewrites Solution: sliding window technique Prof. Uwe Aßmann, Softwaretechnologie 17 Cost Example: The Euro Introduction Prof. Uwe Aßmann, Softwaretechnologie 18 Cost Example: Telecommunication End of 2001, many countries introduced the Euro Too bad: on paper, the Euro was introduced 2 years before Some companies had to maintain double booking for 2 years At least for some months in 2002 Double booking was very costly: accounts had to be printed in two currencies How to test the transition? In May 2001, the Dresdner bank ran a test Which failed,.. And produced many wrong money transfers! Many people worked day and night One of my friends was responsible for the ATM machines Telecommunication software product line Module of 1000 loc (lines of code) Single product has modules Necessary: 5000 persons/7years. Costs ca. 7 billion. Size of world market 50 billion How many suppliers can exist? Prof. Uwe Aßmann, Softwaretechnologie 19 Prof. Uwe Aßmann, Softwaretechnologie 20

6 Programmer Productivity Rules of Thumb System software: loc/y System like Software: 5000 loc/y Application software: loc/y Master s thesis: loc/thesis Individual differences up to factor 5 Has not changed in the last 30 years Differences by programming language and reuse mechanisms PM.2.2 "Software-Engineering" Softwaretechnologie <= Software-Engineering = Softwareingenieurswesen Softwaretechnik: Unterbegriff von Softwaretechnologie software engineering: Die Entdeckung und Anwendung solider Ingenieur-Prinzipien mit dem Ziel, auf wirtschaftliche Weise Software zu bekommen, die zuverlässig ist und auf realen Rechnern läuft. (F.L. Bauer, NATO-Konferenz Software-Engineering 1968) Prof. Uwe Aßmann, Softwaretechnologie 21 What is Software Engineering? Softwaretechnologie, Prof. Uwe Aßmann 22 The (Software) Engineer's Toolkit It teaches the production of software with engineering techniques (the engineer's toolkit) Analysis Construction (development, invention) Validation Improvement Analyze (measure) Measuring Searching and finding Controlling Describe the world with descriptive models Construct (design, development, invent, build) Modelling: prescribe the form of a system with a prescriptive model Describing the infinite and the unknown with finite descriptions Structuring (making the model more clear) Refinement (making the model more precise and detailed) Engineers Engineers measure, measure, build, build, validate, validate, and and improve improve Elaboration (adding more details) DomainTransformation (changing representation of model) Prof. Uwe Aßmann, Softwaretechnologie 23 Prof. Uwe Aßmann, Softwaretechnologie 24

7 The (Software) Engineer's Toolkit Der Softwareingenieur als Problemlöser Form hypotheses and validate them Probleme identifizieren (beobachten) Experimentation (empirical software engineering) Checking (consistency, completeness, soundness) Testing Proving (formal software engineering) Theorie und Verbesserungshypothesen entwickeln Lösungen entwickeln (Techniken, Methoden u. Werkzeuge) Empirisches Testen (danach Iteration) Statistics Improve Reverse engineer Merke: Fehlt eine Aktivität, liegt kein ingenieursmässiges Arbeiten vor! Optimize with regard to a value model Prof. Uwe Aßmann, Softwaretechnologie 25 Another Important Aspect of Software Engineering Prof. Uwe Aßmann, Softwaretechnologie 26 A Little History It teaches the production of software with languages for Analysis Design Validating and experimenting Improvement On different abstraction levels Imprecise (sketching information) Precise (such that code can be generated from the specifications) In different syntaxes Informal, formal, diagrammatic, high-level NATO Conference on Software Engineering in Garmisch-Patenkirchen. Oct 7-10, 1968 "The whole trouble comes from the fact that there is so much tinkering with software. It is not made in a clean fabrication process. What we need is Software Engineering." Friedrich L. Bauer, 1968 Hence the conference was called "on Software Engineering" [in Thayer&McGettrick IEEE Press] "Software Crisis" Component Software Both on the technical and on the process (management) level Prof. Uwe Aßmann, Softwaretechnologie 27 Prof. Uwe Aßmann, Softwaretechnologie 28

8 Photos of Famous People [Courtesy Brian Randell s Web Site] Photos of Famous People [Courtesy Brian Randell s Web Site] E. Dijkstra K. Samuelson (Stack) D. McIlroy Mass-produced Software Components W. van der Poel A. Perlis J. Feldman C. Strachey B. Randell D. Gries T. Hoare 3 rd from right: G. Goos Prof. Uwe Aßmann, Softwaretechnologie 29 Definitions N. Wirth P. Brinch Hansen Prof. Uwe Aßmann, Softwaretechnologie 30 Lehman's Classes of Programs Program: Sources, object files, libraries Software: Program with user and developer documentation, requirement specification, design descriptions, implementation description Product: Ripe software. Good, simple, and pedagogic documentation. Simple Installation. Support guaranteed Note: Companies like products Product line (product family): A group of products, having a common framework and product-specific extensions. Note: every product is sold independently Specification programs (S-programs) A formal problem specification exists, describing problem and solution The specification allows for checking the solution on validity (formal checks or formal proofs) Problem solving programs (P-programs) Can be formalized and checked Have requirements for usability and appropriate Embedded programs (E-programs) Embedded in a social context The specification is a social process; the functionality depends on the involved people No correctness proofs possible Prof. Uwe Aßmann, Softwaretechnologie 31 Prof. Uwe Aßmann, Softwaretechnologie 32

9 Themengebiet Software-Engineering Was ist eine Software- Entwicklungsmethode? Projektmanagement Vorgehensmodellierung Beschrieben in Lehrbüchern und Handbüchern Zweck: Hilfe bei der Erstellung von Software Bessere Planbarkeit der Entwicklung Bessere Struktur des Produkts Requirements Engineering Software-Entwicklungsmethoden Software- Architektur und -Entwurf Software- Wartung Qualitätssicherung (incl. Testverfahren) Re- Engineering (Sanierung) Darstellungsformen Syntax für Dokumente Diagrammtypen Verfahren Transformation Entwicklungs- Methode Werkzeugunterstützung Vorgehensmodell Schritte Reihenfolge Ergebnisse Werkzeugunterstützung (CASE) Prof. Uwe Aßmann, Softwaretechnologie 33 Prof. Uwe Aßmann, Softwaretechnologie 34 Your Career Career Planning First, you will be a designer and programmer in a team You will need design skills most urgently for your own and small-size projects In the software process, design flaws are most costly Afterwards, you will be project leader Without good knowledge in design, you will not be a good developer nor project leader And then manager But neither a good manager Basic Microsoft strategy: every manager must be able to program.. but some gamble instead... Softwaretechnologie, Prof. Uwe Aßmann 35 Prof. Uwe Aßmann, Softwaretechnologie 36

10 Your Career (II) Your Career (III) - Consultant Some become entrepreneurs What is an entrepreneur? [Prof. R. Würth: Lecture notes on entrepreneurship A consultant teaches and employs modern technology at a customer site Must lead in knowledge and technology Individual software Outsourcing to Asia or MOE (Mittelosteuropa) is a trend how to manage distributed projects? Ein Ein Unternehmer Unternehmer ist ist ein ein Problemlöser. Problemlöser. Insbesondere Insbesondere sind sind ein ein Unternehmer Unternehmer und und ein ein Kapitalist Kapitalist zweierlei. zweierlei. Der Der Kapitalist Kapitalist sieht sieht den den Gewinn Gewinn im im Mittelpunkt, Mittelpunkt, aber aber der der Unternehmer Unternehmer findet findet seine seine Befriedigung Befriedigung nur nur im im Lösen Lösen von von Problemen Problemen seiner seiner Kunden Kunden und und seiner seiner Mitarbeiter. Mitarbeiter. Damit Damit kann kann er er zwar zwar auch auch Geld Geld verdienen, verdienen, im im Wesentlichen Wesentlichen lebt lebt er er aber aber nur nur einen einen grundlegenden grundlegenden Zug Zug des des Menschen Menschen aus: aus: für für Probleme Probleme befriedigende befriedigende Lösungen Lösungen zu zu finden. finden. Prof. Uwe Aßmann, Softwaretechnologie 37 Was haben wir gelernt? Der Ingenieur misst, entwirft, validiert und verbessert Keiner Ingenieur bleibt Programmierer, sondern muß sich entwickeln Prof. Uwe Aßmann, Softwaretechnologie 38 PM.2.3 Vorgehensmodelle (Phasenmodelle) Prof. Uwe Aßmann, Softwaretechnologie 39 Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden , Softwaretechnologie, Prof. Uwe Aßmann 40

11 Obligatorisches Lesen Wie gehe ich vor, um Software zu entwickeln? Zuser Kap. 1-3 oder Ghezzi Chapter 1 oder Pfleeger Chapter 1; Chap The first International Conference on Software Engineering (ICSE) Vorgehensmodell (engl. process model) Strukturiertes Modell zum Erstellen von Software Phasenmodell Vorgehensmodell, das den Herstellungsprozesses in defi nierte und abgegrenzte Phasen einteilt Vorgabe einer Reihenfolge in der Bearbeitung der Phasen Ad hoc Es lief schon oft schief... Denver International Airport, Krise Bahncard 50 Hamburger Güterbahnhof 1995 Gibt es nicht irgendwelche Hilfen, strukturiert vorzugehen? Prof. Uwe Aßmann, Softwaretechnologie 41 Vorgehen nach einem Phasenmodell Prof. Uwe Aßmann, Softwaretechnologie 42 Wasserfall-Modell (pur) 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: Entwurf Validation (v.a. Test, Integration) Evolution (v.a. Wartung) Prof. Uwe Aßmann, Softwaretechnologie 43 Entwurf Produktdefinition Entwurfs- Spezifikation Code Test, Integration Änderungswünsche W. Royce (1970) geprüfter Code Wartung Prof. Uwe Aßmann, Softwaretechnologie 44

12 Ungefähre Verteilung des Arbeitsaufwandes Entwurf 10 % 20 % Das Wasserfallmodell ist nicht realistisch. Für ein Produkt müssen, schon um des Geschäftsmodells willen, Verbesserungen (Lebenszyklen) eingeplant werden Ein Lebenszyklus dauert i.d. 2 Jahre Dennoch muss ein Softwareingenieur den Wasserfall beherrschen, denn viele andere Vorgehensmodelle setzen darauf auf 20 % 50 % Test, Integration Wartung Prof. Uwe Aßmann, Softwaretechnologie 45 Qualitätssicherung im V-Modell Prof. Uwe Aßmann, Softwaretechnologie 46 V-Modell des BMI (vereinfacht) Testfälle Abnahmetest Abnahme-Test Grobentwurf Feinentwurf Testfälle Testfälle Systemtest Integrationstest Grobentwurf Subsystem-Test Test & Integration Modultest Feinentwurf Boehm 1979 ( V-Modell ) Prof. Uwe Aßmann, Softwaretechnologie 47 Bröhl/Dröschel 1993 Prüfaktivitäten Prof. Uwe Aßmann, Softwaretechnologie 48

13 Inkrementelle (evolutionäre) Entwicklung Evolutionäre Entwicklung Typisch für kleinere Projekte oder experimentelle Systeme Bei Objektorientierung auch für größere Projekte anwendbar? Entwurf Aufgabe Prototypen, Vorversionen Evolution Entwurf Validation Modifikation Prof. Uwe Aßmann, Softwaretechnologie 49 extreme Programming (XP) Prof. Uwe Aßmann, Softwaretechnologie 50 Spiralmodell Aktuelle, kontrovers diskutierte Entwicklungsmethodik (Kent Beck) Konsequente evolutionäre Entwicklung Der Programmcode ist das ergebnis, 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) liefert schnell Ergebnisse, aber u.u. auf Kosten der Langlebigkeit kann prinzipiell mit traditionelleren - und Entwurfstechniken kombiniert werden Nachteile wird manchmal als Gegenbewegung zu sauberem Softwareentwurf mißverstanden ist nur geeignet für relativ überschaubare, isolierte Anwendungen "Agile" Softwareentwicklung ( weitere Ansätze, z.b. Crystal, Scrum Prof. Uwe Aßmann, Softwaretechnologie 51 Zielbestimmung, Beurteilung von Alternativen Planung der nächsten Phase B. Boehm (1988) V&V V&V Integration Abnahme Risikoanalyse P1 P2 P3 P4 Test Feinentwurf Code Anforderungen Grobentwurf V&V = Verifikation & Validation Prototypen Entwicklung nächstes Teilprodukt Prof. Uwe Aßmann, Softwaretechnologie 52

14 Objektorientiertes Spiralmodell Spiralmodell vs. evolutionäre Entwicklung Entwurf Produkte (Releases) einschl. Prototypen Test Langfristige Vorplanung der Zyklen-Durchläufe Prof. Uwe Aßmann, Softwaretechnologie 53 Parallelität im Entwicklungsprozeß Grundidee identisch: Zyklisches Durchlaufen von Entwicklungsaktivitätem Aufeinanderfolgende Prototypen Evolutionäre und agile Entwicklung: Reaktion auf Änderungen ist wichtiger als Verfolgung eines Plans Planung nur für sehr kurze Zeiträume (Tage, Wochen) im voraus Viele, häufige Durchläufe (z.b. Tagesrhythmus) Spiralmodell: Einsetzbar in verschiedener "Strenge" Vorausplanung von Durchläufen. Anzahl Durchläufe manchmal schon bei Projektbeginn festgelegt Wenige Durchläufe (z.b. Quartalsrhythmus) Kompromiß zwischen Planbarkeit und Agilität Prof. Uwe Aßmann, Softwaretechnologie 54 Zweidimensionales Modell Anforderungsspezifikation Produktdefinition Entwurfsspezifikation Subsystem 1 Subsystem 2 Subsystem 3 Code Subsystem 1 Subsystem 2 Subsystem 3 Ergebnisse "Makro-Phasen" /Entwurf/ "Mikro-Phasen" /Entwurf/ Prof. Uwe Aßmann, Softwaretechnologie 55 Zeit Rational Unified Process 1999 (Jacobson et al., Kruchten) mit Mikro- und Makrophasen Zeit Entwurf Test Konfi gurationsmanagement Projektmanagement Tätigkeit Entstehung (inception) Ausarbeitung (elaboration) Erstellung (construction) Übergang (transition) Prof. Uwe Aßmann, Softwaretechnologie 56

15 Aufwandsverteilung und Schwerpunkte Rational Unified Process (RUP) Rational Unified Process 1999 (Jacobson et al., Kruchten) Entstehung (inception) Ausarbeitung (elaboration) Erstellung (construction) Zeit Übergang (transition) von IBM Rational: Entwurf Test Konfi gurationsmanagement Projektmanagement Tätigkeit Prof. Uwe Aßmann, Softwaretechnologie 57 Teilprojekte und Überlappungsgrade Prof. Uwe Aßmann, Softwaretechnologie 58 Vorgehen im Softwarepraktikum 4. Semester konservativ I1 E1 C1 T1 Teilprojekt 1 Release 1 I2 E2 C2 T2 Teilprojekt 2 Release 2 Echte Kunden Vorgehensmodell: V-Modell mit Akzeptanztests Einfache Inkrementalität: Kunde hat einen Verbesserungswunsch frei, der erst zu einem späten Zeitpunkt bekanntgegeben wird Intern kann ein inkrementelle Vorgehensmodell gewählt werden aggressiv Release 1 I1 E1 C1 T1 Teilprojekt 1 Release 2 I2 E2 C2 T2 Teilprojekt 2 Release 1 Standard I1 E1 C1 T1 Teilprojekt 1 Release 2 I2 E2 C2 T2 Teilprojekt 2 Prof. Uwe Aßmann, Softwaretechnologie 59 I E C T Inception Elaboration Construction Transition Prof. Uwe Aßmann, Softwaretechnologie 60

16 Was haben wir gelernt? Referenz Vorgehen nach einem strukturierten Phasenmodell ist gewöhnlich besser als ad-hoc Vorgehen Realistische Vorgehensmodelle sind iterativ und inkrementell Die deutschen Folien der Softwaretechnologie-Vorlesung stammen zu grossen Teilen aus den Jahren und wurden von Prof. Dr. Heinrich Hussmann, jetzt LMU München, erstellt. Used by permission. Der Ingenieur misst, entwirft, validiert und verbessert Prof. Uwe Aßmann, Softwaretechnologie 61 Prof. Uwe Aßmann, Softwaretechnologie 62 Referenz Die deutschen Folien der Softwaretechnologie-Vorlesung stammen zu grossen Teilen aus den Jahren und wurden von Prof. Dr. Heinrich Hussmann, jetzt LMU München, erstellt. Used by permission. Prof. Uwe Aßmann, Softwaretechnologie 63