Überblick und Einführung Große Software-Systeme

Transkript

1 Überblick und Einführung Große Software-Systeme Vorlesung: Software-Engineering für große Informationssysteme TU-Wien, Sommersemester 2002 Wolfgang Keller 1

2 Überblick Kurze Vorstellung Überblick über die gesamte Vorlesung Große Softwaresysteme Was ist groß? -> Function Points Ein großes Projekt Fallstudie Phoenix Death March Projekte Einzelprojekte und Anwendungsportfolio Projektlaufzeiten früher und heute 2

3 Wo kommt der Mensch her, der diese Vorlesung macht? 3

4 Kurze Vorstellung Wolfgang Keller seit 10 Jahren aus der Uni raus und im Job Dipl.-Inform. (Technische Universität München) bei EDV Dienstleister der Generali Vienna Group Generali Office Service & Consulting AG 450 EDV Mitarbeiter davon ca. 300 Entwickler im weitesten Sinne Abteilungsleiter Plattform-Management für Generali Vienna Group 4

5 Kennzahlen zur Generali Group weltweit Bruttoprämien 2000: 611,2 Mrd. ATS/44,4 Mrd. EUR Leben Nicht-Leben 62% 38% 27,7 Mrd. EUR 16,7 Mrd. EUR Bruttoprämien 1. Halbjahr 2001: 316,5 Mrd. ATS/23,3 Mrd. EUR (+6,4%) Kapitalanlagen per : 2.683,3 Mrd. ATS/195,5 Mrd. EUR Mitarbeiter per : Unternehmenssitz: Triest (Italien) 5

6 Kennzahlen zur Generali Vienna-Gruppe Bruttoprämien 2000: 32,0 Mrd. ATS/2,3 Mrd. EUR Bruttoprämien 1. Halbjahr 2001: Nicht-Leben 18,6 Mrd. ATS/1,4 Mrd. EUR (+9,0%) Leben 70% 30% 22,3 Mrd. ATS 9,7 Mrd. ATS Kapitalanlagen per : ATS/8,1 Mrd. EUR Mitarbeiter per : Unternehmenssitz: Wien 111,6 Mrd. 6

7 Struktur der Generali Vienna- Gruppe Generali Holding Vienna AG, Wien (Stand 2000; vereinfachte Darstellung) Generali Versicherung, Wien Generali-Providencia Biztosito, Budapest Generali SKB Zavarovalnica, Ljubljana Generali Finanz, Wien Generali Office-Service und Consulting, Wien Interunfall Versicherung, Wien Európai Utazási Biztosito, Budapest Generali Asigurari S.A., Bukarest Generali Capital, Wien Generali Marketing- Services, Wien Europäische Reiseversicherung, Wien Generali Pojistovna a.s., Prag Generali Towarzystwo Ubezpieczen, Warschau 3 Banken-Generali Investment, Wien Risk-Aktiv, Wien Generali Poistovna, Bratislava Generali Zycie Towarz. Ubezpieczen, Warschau Allgemeine Immobilien Verwaltung, Wien Europ Assistance, Wien Holdux Beteiligungs - gesellschaft, Basel Versicherungsgesellschaften in Österreich Versicherungsgesellschaften in Mittelosteuropa Finanzgesellschaften B.V. Algemene Holding en Financ., Amsterdam Servicegesellschaften 7

8 Tätigkeitsgebiet Plattform-Management EINE Informatik tätig in Österreich Niederlande Ungarn,Tschechische Republik, Polen, Slowakei, Slowenien, Rumänien 8

9 Architekturverantwortung Beratung Architektur und Anwendungsportfoliomanagement Informatik Land 1 Lokale Informatik Informatik Land n Lokale Informatik Verantwortung Architektur und Softwareentw.-Prozess E-Labs für Gruppe E-Labs für Gruppe 9

10 Regelkreise VGI Strategie E-Lab Entwicklung Implementierung Customizing Lokale Informatik 10

11 Ein Beispiel für ein Anwendungsportfolio Technical Infrastructure Phoenix Technical Base Partner Object Cash Other.. POA PVS ISCD VVS Product Policy Claims Sales PDFS PVS SLS various 11

12 Analogie : Eine Facharchitektur definiert Schrankfächer für komplette, große Softwaresystems 12

13 Worüber werden Sie in dieser Vorlesung etwas hören? 13

14 Abgrenzung Gegenstand: Wie baut man einen einzigen dieser Kästen? Technical Infrastructure Phoenix Technical Base Partner Object Cash Other.. POA PVS ISCD VVS Product Policy Claims Sales PDFS PVS SLS various Nicht Gegenstand: Wie managed man den ganzen Schrank 14

15 Gegenstand Betriebliche Informationssysteme Benutzungsschnittstelle Anwendungskern Datenhaltung (Datenbank) Querschnittsfunktionen 15

16 VL02 Prozeßmodelle Wie geht man beim Bau vor? XP RUP V-Modell 16

17 VL03 Architekturen Was sind die großen Strukturen? siehe auch Übung

18 VL04 Spezifikation I Wie spezifiziert man Anwendungskerne? Benutzungsschnittstelle Anwendungskern Datenhaltung (Datenbank) Querschnittsfunktionen agdjhgsf hkgskhgf hshfkjha gdjhgsfh kgskhgfh shfkjh siehe auch Übung 1 18

19 VL05 Architektur II, Entwurfsmuster Wo finde ich nützliche Muster für Details? siehe auch Übung

20 VL06 Spezifikation II: Wie spezifiziert man Benutzungsschnittstellen? Benutzungsschnittstelle Anwendungskern Datenhaltung (Datenbank) Querschnittsfunktionen agdjhgsf hkgskhgf hshfkjha gdjhgsfh kgskhgfh shfkjh siehe auch Übung 2 20

21 VL07: Transaktionsmonitore und Anwendungscontainer EJB Container Kunde EJB Artikel EJB Basisdienste: Zum Beispiel Transaktionen, Persistenz,.. Anwendung Anwendung (AW) Anwendung Originator (AW) Originator (AW) Originator begin commit rollback join Transaktionsmanager (TM) OTS prepare, commit rollback Aufrufe Ressource Manager (RM i ) 21

22 VL08: Persistenz Benutzungsschnittstelle Anwendungskern Datenhaltung (Datenbank) Querschnittsfunktionen 22

23 VL09 Querschnittsfunktionen Fehlerbehandlung, Datentypen Benutzungsschnittstelle Anwendungskern Datenhaltung (Datenbank) Querschnittsfunktionen Ariane 5: Ein Problem in der Fehlerbehandlung 23

24 VL10: Qualitätssicherung (Folie in der WebVersion ohne den Dilbert wegen -Right) 24

25 Worüber werden Sie in dieser Vorlesung etwas hören? Vorsicht: Diese Vorlesung versetzt Sie nicht in die Lage, ein großes Projekt zu managen Dazu brauchen Sie auch Erfahrung und Praxis Sie werden nur schneller lernen und ein paar Deja Vus haben. 25

26 Große Softwaresysteme 26

27 Überblick Große Softwaresysteme Was ist groß? Function Points Ein großes Projekt Fallstudie Phoenix Einzelprojekte und Anwendungsportfolio Projektlaufzeiten früher und heute Death March Projekte 27

28 Großes Softwaresystem Wie kann man das messen Lines of Code Problem: Assembler!= C++!= Smalltalk Aufwand für die Erstellung Problem: Produktivität von Projekten sehr unterschiedlich Anzahl der Masken, Eingabefelder, Datenbanktabellen, Ausdrucke.. nicht immer akkurat, aber besser, als LoC 28

29 LoC bei gleicher Programmgröße Table 1: Function Point and Source Code Sizes for 10 Versions of the Same Project (A PBX Switching System of 1,500 Function Points in Size) Language Size in Lang. LOC per Size in Func. Pt. Level Func. PT. LOC Assembly 1, ,000 C 1, ,500 CHILL 1, ,500 PASCAL 1, ,500 PL/I 1, ,000 Ada83 1, ,500 C++ 1, ,500 Ada95 1, ,500 Objective C 1, ,500 Smalltalk 1, ,500 Average 1, ,700 Quelle [Jones1997] 29

30 ein Einflußfaktor ist die Projektgröße Quelle [Jones1996] 30

31 Gemessene Produktivitäten unterscheiden sich stark Distribution of Software Productivity Results Numbers of Projects Function Points per Staff Month Series1 Quelle [Jones1998] 31

32 Arbeit in verschiedenen Programmiersprachen ist nicht gleich produktiv Table 2: Staff Months of Effort for 10 Versions of the Same Software Project (A PBX Switching System of 1,500 Function Points in Size) Language Req. Design Code Test Doc. Mgt. TOTAL (Months) (Months) (Months) (Months) (Months) (Months) (Months) Assembly C CHILL PASCAL PL/I Ada C Ada Objective C Smalltalk Average Quelle [Jones1997] 32

33 Function Points sind ein Maß für die Größe und Komplexität von Software, das von der Programmiersprache unabhängig ist 33

34 Function Points Grundformel Summe( Eingabefunktionen (EF) * Gewichte ) Summe( Zahl der Berechnungsfunktionen (BF) * Gewichte ) Summe( Zahl der Abfragefunktionen (AF) * Gewichte ) Summe( Zahl der gespeicherten Dateneinheiten (DE) * Gewichte) Summe( Zahl der ext. Schnittstellen (SES) * Gewichte ) ergeben Unadjusted Function Points (UFP) 34

35 Function Points Gewichte einfach mittel komplex Werte Eingabefunktionen EF Ausgabefunktionen AF Abfragefunktionen AF Dateneinheiten DE Schnittstellen SES Summe 35

36 Function Points Komplexitätsfaktor es gibt einen Katalog mit Zu- und Abschlägen, die einen Systemkomplexitätsfaktor ergeben (SCF) FP = UFP * SCF 36

37 Wie zählt man Function Points? ex ante benötigt wird eine Spezifikation mit Bildschirmmasken Datenbankentwürfen Funktionenmodell Schnittstellen Druckoutput-Entwürfen oder etwas, was einer solchen Spezifikation möglichst nahe kommt 37

38 Wie zählt man Function Points? ex post durch Messen der Lines of Code und Division durch den entsprechenden Konversionsfaktor der jeweiligen Programmiersprache 38

39 Function Points Vorteile Programmgröße ist messbar und damit vergleichbar unabhängig von Programmiersprache Methode kann man ausreichend schnell erlernen (1-2 Tage) Mit FP wird auch Produktivität ex post beurteilbar (FP / Personenmonat) Aus FPs kann man viele weitere Erfahrungsgrößen berechnen - zum Beispiel erwartete Fehler 39

40 Function Points Weitere Eigenschaften Man benötigt eine einigermaßen ergiebige Spezifikation - die ist oft nicht vorhanden Wiederverwendung ist problematisch einzubeziehen (wieviel FPs entspricht die Verwendung eines Moduls mit FP) Ausgelegt auf funktionale Technologie - für OO, Web,.. gibt es Erweiterungen Man muss die Methode seriös erlernen, um sie zu verwenden (Buch reicht allerdings) 40

41 Führt uns zurück zur Frage.. Was ist groß? Durchschnittliches Projekt in der Finanzindustrie FP 1-2 Jahre Durchlaufzeit ca. 10 MitarbeiterInnen ab solchen Größen lohnen sich die Methoden, die in dieser Vorlesung beschrieben werden... 41

42 Projektrisiko als Funktion der Projektgröße Quelle [Jones1996] 42

43 Ein großes Projekt Fallstudie Phoenix 43

44 Zeitlicher Abriß 3maliger 3maliger Neuanfang Neuanfang durch durch Weiterentwicklunentwicklungder der Technologien Weiter- Technologien Das Das Projekt Projekt Phoenix sind sind effektiv effektiv 3 Projekte Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden? Verantwortung Verantwortung für für die die Phoenix Phoenix Plattform Plattform durch durch agens agens Consulting Consulting Schulungen Schulungen an an der der Hausversion Hausversion Vorbereitung Vorbereitung Produktiveinsatz Produktiveinsatz 1/89 1/95 Die Zukunft ist so drängend, daß sie schon Gegenwart ist Friedrich Nietzsche 4/98 9/98 Produktiveinsatz Produktiveinsatz 44

45 Projektlaufzeit Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden? 7 Dauer in Kalenderjahren Industriestandard für Projekte dieser Größe Phoenix Dev. Phoenix Test Customizing 1. M. 0 45

46 Function Points Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden? Größe von Phoenix: Function Points Dies entspricht ca Lines of Code (Smalltalk) Die Größe eines durchschnittlichen Softwareprojekts in Checkpoint* beträgt ca Function Points! Checkpoint ist ein Produkt der SPR 46

47 Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden? Bewertung der Produktgröße Projektrisiko Wahrscheinlichkeit des Scheiterns 60% 50% 40% 30% 20% 10% 0% Projektgröße in Function Points

48 Bewertung der Produktgröße Produktivität in FP/Personenmonaten Produktivität Funktion Points? 3,44 FP 48 Monate *100 Mitarbeiter PersMonate Projektgröße in Function Points Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden?

49 Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden? Bewertung der Produktgröße Entwicklung der Mitarbeiteranzahl (nach Köpfen) Anzahl Mitarbeiter /95 2/95 1/96 2/96 1/97 1/98 1/98 2/98 Zeit (Halbjahre) 49

50 Projektorganisation Mit Mit welcher welcher Projektorganisation Projektorganisation kann kann man man solche solche Großprojekte Großprojekte managen? managen? Virtueller Mandant OPEN OPEN 1M 1M Technische Basis-Sys. Produktion Portierung Projektmanagement Qualitätsmanagement Plattformmanagement Testmanagement Projektmanagement Team Controlling Qualitäts- Sicherung Architektur Internes Kontroll-Sys. Datenbank Berechtigung Workflow Geschäftsprozesse Testzentrum CCM Vertrag Leistung Batch Subsystem Technik Druck/ Akt-Archiv Frameworks Produkt Tech. Best. führung Management Inform. Sys. Entwicklungsteams Entwicklungslabors Erste Allgemeine Dokument. Generali München Konto Interunfall Partner Testzentrum Testzentrum Mandant Mandant Testzentrum Testzentrum IBM IBM IT IT Bereich Bereich Aktuariat Aktuariat Mandant Mandant Projekt Projekt SESAM SESAM SAP SAP IS-IS/CD IS-IS/CD 50

51 Death March Projekte 51

52 Death March Projekte Definition nach Yourdon sind Projekte, die um den Faktor 50% von der Norm abweichen, zum Beispiel Wurde die Projektzeit um 50% gekürzt, gegenüber dem normal errechneten Wert oder die Mannschaft halbiert, gegenüber normaler Teamstärke oder aber das Budget halbiert (entsprich halber Mannschaft) andere Faktoren liegen um den Faktor 2 neben den normalen Werten [Yourdon1997] 52

53 Death Marches nach Größe.. Klein: <= 10 Teammitglieder mit einer Durchlaufzeit von ca. 3-6 Monaten Mittel: Bearbeiter mit einer Durchlaufzeit von 1-2 Jahren Groß: Mitarbeiter, 3-5 Jahre Durchlaufzeit Gigantisch: Mitarbeiter, 7-10 Jahre Durchlaufzeit 53

54 Death March Arten Happiness Kamikaze Suicide Mission Impossible Ugly Chances of Success [Yourdon2002] 54

55 Einzelprojekt und Anwendungsportfolio Phoenix hat einige Schrankfächer gefüllt - bei weitem nicht alle 55

56 Alles auf einmal machen führt mit Sicherheit zu Desaster oder Death March 56

57 Vermeidung von Death Marches und hohen Risiken Projekte möglichst klein schneiden (<2000 FP) Begründung: VL heute dafür erforderlich ein Generalbebauungsplan Architekturmanagement, sie VL 03 Projekte ordentlich schätzen Begründung: VL heute Und im Projekt professionell arbeiten Rest der Vorlesungsreihe... 57

58 Trend kürzere Projektlaufzeiten 90er Jahre Projektlaufzeiten von 3 Jahren waren normal erste Software nach 1,5-2 Jahren Heute am liebsten Software nach 3-6 Monaten Beispiel: Web Banken - < 1 Jahr ist normal Pay Off nach 2 Jahren Erste Software nach 3 Monaten 58

59 Abschluss heute... Force Zeit, Kosten Your Project Counter Force Qualität in dieser Vorlesung lernen sie primär Dinge, wie man gute Qualität bekommt Wenn Sie sich die nicht leisten können, müssen Sie wenigstens wissen, wo Sie die Kunst verletzen um die Folgen abschätzen zu können 59

60 Quellen [Garmus+2000] David Garmus, David Herron: Fuction Point Analysis, Addison-Wesley [Jones1996] Capers Jones, Applied Software Measurement, 2nd Edition, McGraw Hill 1996 [Jones1997] Capers Jones, The Economics of Object-Oriented Software, White Paper, spr.com [Jones 1998] Capers Jones, Positive and Negative Factors that Influence Software Productivity, White Paper, spr.com [Yourdon1997] Ed Yourdon: Death March, The Complete Software Developer s Guide to Surviving Mission Impossible Projects, Prentice Hall [Yourdon2002] Ed Yourdon: Managing High Intensity Internet Projects, Prentice Hall