Überblick und Einführung Große, betriebliche Informationssysteme

Transkript

1 Überblick und Einführung Große, betriebliche Informationssysteme Vorlesung: Software-Engineering für große, betriebliche Informationssysteme für Universität Leipzig, Sommersemester 2004 Institut für Software- und Systementwicklung Professur Wirtschaftsinformatik, insbes. Informationsmanagement Hans Hartmann (Generali VIS Informatik Ges.m.b.H., Wien) Wolfgang Keller (AMB Generali Informatik Services GmbH, Aachen) 1

2 Überblick Kurze Vorstellung Wer sind wir? Für wen arbeiten wir? Was sind Betriebliche Informationssysteme? Überblick über die gesamte Vorlesung Große, betriebliche Informationssysteme Was charakterisiert ein betriebliches Informationssystem? 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 kommen die Leute her, die diese Vorlesung machen? Wer sind wir? Generali Gruppe weltweit Generali Vienna Group AMB Generali Deutschland Informatik Dienstleister Infrastruktur für Region Central East Generali VIS Informatik AMB Generali Informatik 3

4 Kurze Vorstellung Wolfgang Keller seit 13 Jahren aus der Uni raus und im Job Dipl.-Inform. (Technische Universität München) bei EDV Dienstleister der AMB Generali Gruppe, Aachen AMB Generali Informatik Services GmbH rund 1250 EDV Mitarbeiter davon ca. 800 Entwickler im weitesten Sinne Abteilungsleiter Architektur & IT Governance für AMB-Informatik 4

5 Kurze Vorstellung Hans Hartmann seit 30 Jahren aus der Uni raus und im Job Also im Prinzip waren das schon ganz nette Sachen, die da programmiert wurden und über lange Jahre hing meine Programmierung in erster Linie mit Real Time Programming und mit Ethical Goods (Medizin, Forschung) zusammen. Als ich 1999 fix zur Generali ging, war ich begeistert, wie komplex die eigentlich sehr einfach aussehenden fachlichen Zusammenhänge, speziell im Bereich der Lebensversicherung, waren. Bis heute weiß ich nicht, ob diese Komplexität nicht doch etwas vereinfacht werden kann. Daher ist meine heutige Architekturtätigkeit nach wie vor hochinteressant. bei EDV Dienstleister der Generali Vienna Group, Wien Generali VIS Informatik Ges.m.b.H rund 210 EDV Mitarbeiter (nur Softwareentwicklung) Leiter Architektur für Generali VIS* Informatik * Vienna Insurance System 5

6 Generali Group Kennzahlen

7 Generali Group 170 Jahre Geschichte 7

8 Generali ist die viertgrößte Versicherungsgruppe in Europa 8

9 Generali Vienna Group 9

10 AMB Generali Gruppe AMB Generali Group AMB Generali founded in 1824 in Aachen, Germany Since 1998 German subsidiary of Generali Group (equity stake Generali: 65.2%) Listed in MDAX Second place in Germany in terms of life and non-life premium volume Market leader in unit-linked and term life insurance Financial key figures, 2002 Total premiums German GAAP 11.7 bn Assets under management 68 bn Number of staff * 21,700 Market capitalization (08/04/03) 2.9 bn Network of AMB Generali Group Aachener und Münchener (Aachen) Cosmos (Saarbrücken) Generali (Munich) Volksfürsorge (Hamburg) Special brands AdvoCard AM Generali Invest Badenia Central Dialog 10

11 AMB Generali Informatik also acts as an international service provider for data center services within IT Region Central East Poland Germany Czech Republic Netherlands Slovakia Austria Hungaria Romania EC member Slovenia EC candidate Croatia others 11

12 AMB Generali Informatik: The AMB Generali Group s central provider of IT services Number: MIPS CPU mainframe capacity - 20 Mio. online transactions per day batch jobs per day Mio. pages printed per year - 55 Mio. item mailed per year PCs for back-offices managed PCs for sales force managed telecom devices managed 12

13 Tätigkeitsgebiet Generali VIS Informatik Ges.m.b.H EINE Informatik tätig in Österreich Niederlande Ungarn,Tschechische Republik, Polen, Slowakei, Slowenien, Rumänien, Kroatien mit möglichst redundanzarmen Softwaresystemen 13

14 Generali Vienna Group 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 14

15 Generali Vienna Group Regelkreise VGI Strategie E-Lab Entwicklung Implementierung Customizing Lokale Informatik 15

16 Was sind Betriebliche Informationssysteme wir danken Herrn Prof. Dr. Ernst Denert und dem Deutschen Museum München für den Lufthansa Fall auf den folgenden Folien #17-#29 16

17 17

18 Lufthansa-Reservierung in den 60ern 18

19 19

20 20

21 21

22 22

23 23

24 24

25 25

26 Das Verfahren der Lufthansa-Reservierung in den 60ern war auch ein betriebliches Informationssystem, allerdings nicht rechnergestützt. 26

27 Betriebliche Informationssysteme sind betriebswirtschaftlich: die Informationen, ihre Strukturen und Flüsse, die für die Geschäftstätigkeit eines Unternehmens nötig sind; technisch: IT-Anwendungen, die dazu dienen, die Geschäftsprozesse eines Unternehmens effizient zu organisieren und zu unterstützen. Es sind datenbankbasierte, transaktionsverarbeitende Softwaresysteme. 27

28 Beispiele betrieblicher Informationssysteme Branche Allgemein Automobil Handel Telekommunikation Banken Versicherungen Luftverkehr Öffentl. Verwaltung Öffentl. Personenverkehr Vereine Systeme Buchhaltung, Lohn / Gehalt Produktionsplanung und -steuerung (PPS) Auftragsabwicklung Warenwirtschaft Billing Kontoführung (Geld, Wertpapiere) Zahlungsverkehr Wertpapierhandel Bestandsverwaltung Buchungssystem Kundenbindung (CRM) Einwohnermeldewesen Fahr- / Umlauf- / Dienstplanung Mitgliederverwaltung 28

29 Betriebliche Informationssysteme sind Investitionsgüter Sie sind groß, teuer, langlebig schwergewichtig. Ihre Hersteller sind Investitionsgüterproduzenten und nicht nur Dienstleister. 29

30 Worüber werden Sie in dieser Vorlesung etwas hören? Überblick über die gesamte Vorlesung 30

31 Abgrenzung Gegenstand: Wie baut man einen einzigen dieser Kästen? Technical Infrastructure VIS 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 31

32 Hier nicht Gegenstand: Anwendungslandschaft Typische Größenordnung von Anwendungslandschaften: Hunderte von Anwendungen, bestehend aus (Zehn)Tausenden von Programmen mit Millionen Zeilen Code, entwickelt mit einem Aufwand von Tausenden von Bearbeiterjahren, Investitionsvolumen im zwei-/dreistelligen Mio-Bereich. 32

33 Hier Gegenstand einzelne Anwendungssysteme Benutzungsschnittstelle Anwendungskern Datenhaltung (Datenbank) Querschnittsfunktionen 33

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

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

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

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

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

39 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 ) 39

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

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

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

43 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. 43

44 Große Softwaresysteme 44

45 Ü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 45

46 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 46

47 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] 47

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

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

50 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] 50

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

52 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) 52

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

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

55 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 55

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

57 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 57

58 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) 58

59 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... 59

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

61 Ein großes Projekt Fallstudie Phoenix 61

62 Zeitlicher Abriß Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden? 3maliger 3maliger Neuanfang Neuanfang durch durch Weiterentwicklunentwicklungder der Technologien Technologien Weiter- Das Das Projekt Projekt Phoenix sind sind effektiv effektiv 3 Projekte 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 62

63 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 63

64 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 64

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

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

67 Bewertung der Produktgröße Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden? 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) 67

68 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 Interunfall Allgemeine Dokument. Generali München Konto Partner Testzentrum Testzentrum Mandant Mandant Testzentrum Aktuariat Projekt Testzentrum IT Aktuariat Projekt IT Bereich SAP SAP IS-IS/CD IBM Bereich 1. IS-IS/CD Vorlesung Software Engineering für große, betriebliche 1. Mandant SESAM IBM Mandant Informationssysteme, SESAM 68

69 Death March Projekte 69

70 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] 70

71 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 71

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

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

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

75 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... 75

76 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 76

77 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 77

78 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