Post on 03-Oct-2020
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 1
Überblick und EinführungGroße, betriebliche Informationssysteme
Vorlesung: Software-Engineering für große, betriebliche Informationssysteme
für Universität Leipzig, Sommersemester 2004Institut 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)
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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, AachenAMB Generali Informatik Services GmbH
• rund 1250 EDV Mitarbeiter• davon ca. 800 Entwickler im weitesten Sinne
• Abteilungsleiter „Architektur & IT Governance“ für AMB-Informatik
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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, WienGenerali VIS Informatik Ges.m.b.H
• rund 210 EDV Mitarbeiter (nur Softwareentwicklung)• Leiter Architektur
für Generali VIS* Informatik * Vienna Insurance System
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 6
Generali GroupKennzahlen 2002
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 7
Generali Group170 Jahre Geschichte
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 8
Generali ist die viertgrößte Versicherungsgruppe in Europa
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 9
Generali Vienna Group
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 10
AMB Generali Gruppe
Volksfürsorge(Hamburg)
Generali(Munich)
Cosmos(Saarbrücken)
Aachener undMünchener(Aachen)
AdvoCardAM Generali
InvestBadeniaCentralDialog
Specialbrands
AMB Generali GroupAMB 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, 2002Total 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
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 11
Germany
Austria
Netherlands
Slovenia
Croatia
EC candidate
EC member
Hungaria
Czech Republic
Slovakia
Romania
AMB Generali Informatik also acts as an international service provider for data center services within IT Region Central East
Poland
others
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 12
AMB Generali Informatik: The AMB Generali Group‘s central provider of IT services
Number:
- 15.000 MIPS CPU mainframe capacity- 20 Mio. online transactions per day- 40.000 batch jobs per day- 270 Mio. pages printed per year- 55 Mio. item mailed per year- 16.000 PCs for back-offices managed- 18.000 PCs for sales force managed- 20.000 telecom devices managed
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 13
TätigkeitsgebietGenerali 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
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 14
Generali Vienna GroupArchitekturverantwortung
InformatikLand 1
LokaleInformatik
E-Labsfür
Gruppe
InformatikLand n
LokaleInformatik
E-Labsfür
Gruppe
Beratung Architektur undAnwendungsportfoliomanagement
Verantwortung Architekturund Softwareentw.-Prozess
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 15
Generali Vienna GroupRegelkreise
Strategie
VGI
Entwicklung
E-Lab
ImplementierungCustomizing
Lokale Informatik
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 16
Was sindBetriebliche 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
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 17
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 18
Lufthansa-Reservierung in den 60ern
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 19
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 20
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 21
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 22
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 23
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 24
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 25
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 26
Das Verfahren der Lufthansa-Reservierung in den 60ern war auch ein betriebliches Informationssystem, allerdings nicht
rechnergestützt.
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 27
Betriebliche Informationssystemesind• 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, transaktionsverarbeitendeSoftwaresysteme.
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 28
Beispiele betrieblicher InformationssystemeBranche SystemeAllgemein Buchhaltung, Lohn / GehaltAutomobil Produktionsplanung und -steuerung (PPS)
AuftragsabwicklungHandel WarenwirtschaftTelekommunikation BillingBanken Kontoführung (Geld, Wertpapiere)
ZahlungsverkehrWertpapierhandel
Versicherungen BestandsverwaltungLuftverkehr Buchungssystem
Kundenbindung (CRM)Öffentl. Verwaltung EinwohnermeldewesenÖffentl. Personenverkehr Fahr- / Umlauf- / DienstplanungVereine Mitgliederverwaltung
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 29
Betriebliche Informationssysteme sind Investitionsgüter
• Sie sind groß, teuer, langlebig – schwergewichtig.
Ihre Hersteller sind Investitionsgüterproduzenten und nicht nur Dienstleister.
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 30
Worüber werden Sie in dieser Vorlesung etwas hören?
Überblick über die gesamte Vorlesung
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 31
Abgrenzung
Product Claims Sales
Partner Object Cash Other..
Technical Infrastructure
POA ISCD
PDFS
PVS
PVS various
VIS Technical Base
Policy
SLS
VVS
Gegenstand:Wie baut man einen
einzigen dieser Kästen?
Nicht Gegenstand:Wie managed man den
ganzen Schrank
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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.
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 33
Hier Gegenstandeinzelne Anwendungssysteme
Benutzungsschnittstelle
Anwendungskern
Datenhaltung (Datenbank) Que
rsch
nitts
funk
tione
n
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 34
XP
RUP V-Modell
VL02 – ProzeßmodelleWie geht man beim Bau vor?
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 35
VL03 ArchitekturenWas sind die „großen Strukturen“?
siehe auch Übung 3+4
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 36
VL04 Spezifikation IWie spezifiziert man Anwendungskerne?
Benutzungsschnittstelle
Anwendungskern
Datenhaltung (Datenbank) Que
rsch
nitts
funk
tione
n
agdjhgsfhkgskhgfhshfkjhagdjhgsfhkgskhgfhshfkjh
siehe auch Übung 1
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 37
VL05 Architektur II, EntwurfsmusterWo finde ich nützliche Muster für Details?
siehe auch Übung 3+4
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 38
VL06 Spezifikation II: Wie spezifiziert man Benutzungsschnittstellen?
Benutzungsschnittstelle
Anwendungskern
Datenhaltung (Datenbank) Que
rsch
nitts
funk
tione
n
agdjhgsfhkgskhgfhshfkjhagdjhgsfhkgskhgfhshfkjh
siehe auch Übung 2
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 39
VL07: Transaktionsmonitore und Anwendungscontainer
EJB Container
Basisdienste: Zum BeispielTransaktionen, Persistenz, ..
KundeEJB
ArtikelEJB
Anwendung(AW)
OriginatorAnwendung
(AW)Originator
Anwendung(AW)
Originator
Transaktions-manager
(TM)OTS
RessourceManager
(RMi)
begincommitrollback
prepare, commitrollbackjoin
Aufrufe
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 40
VL08: Persistenz
Benutzungsschnittstelle
Anwendungskern
Datenhaltung (Datenbank) Que
rsch
nitts
funk
tione
n
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 41
VL09 QuerschnittsfunktionenFehlerbehandlung, Datentypen
Benutzungsschnittstelle
Anwendungskern
Datenhaltung (Datenbank) Que
rsch
nitts
funk
tione
n
Ariane 5: Ein Problem in der Fehlerbehandlung
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 42
VL10: Qualitätssicherung
(Folie in der WebVersion ohne den „Dilbert“ wegen ©-Right)
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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.
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 44
Große Softwaresysteme
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 45
ÜberblickGroße Softwaresysteme• Was ist groß?
• Function Points• Ein großes Projekt – Fallstudie Phoenix• Einzelprojekte und Anwendungsportfolio• Projektlaufzeiten früher und heute• Death March Projekte
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 46
Großes SoftwaresystemWie 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
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 47
LoC bei gleicher „Programmgröße“
Table 1: Function Point and Source Code Sizes for 10 Versionsof 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,500 1 250 375,000 C 1,500 3 127 190,500 CHILL 1,500 3 105 157,500 PASCAL 1,500 4 91 136,500 PL/I 1,500 4 80 120,000 Ada83 1,500 5 71 106,500 C++ 1,500 6 55 82,500 Ada95 1,500 7 49 73,500 Objective C 1,500 11 29 43,500 Smalltalk 1,500 15 21 31,500
Average 1,500 6 88 131,700
Quelle [Jones1997]
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 48
ein Einflußfaktor ist die Projektgröße
Quelle [Jones1996]
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 49
Gemessene Produktivitäten unterscheiden sich stark
Distribution of Software Productivity Results
0
20
40
60
80
100
120
140
160
180
200
0.5 1 2 3 4 5 6 7 8 9 10 15 20 40 50 100
150
Function Points per Staff Month
Num
bers
of P
roje
cts
Series1
Quelle [Jones1998]
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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 13.64 60.00 300.00 277.78 40.54 89.95 781.91C 13.64 60.00 152.40 141.11 40.54 53.00 460.69CHILL 13.64 60.00 116.67 116.67 40.54 45.18 392.69PASCAL 13.64 60.00 101.11 101.11 40.54 41.13 357.53PL/I 13.64 60.00 88.89 88.89 40.54 37.95 329.91Ada83 13.64 60.00 76.07 78.89 40.54 34.99 304.13C++ 13.64 68.18 66.00 71.74 40.54 33.81 293.91Ada95 13.64 68.18 52.50 63.91 40.54 31.04 269.81Objective C 13.64 68.18 31.07 37.83 40.54 24.86 216.12Smalltalk 13.64 68.18 22.50 27.39 40.54 22.39 194.64
Average 13.64 63.27 100.72 100.53 40.54 41.43 360.13
Quelle [Jones1997]
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 51
Function Points• sind ein Maß für die „Größe“ und Komplexität von Software, das
von der Programmiersprache unabhängig ist
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 52
Function PointsGrundformel• 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)
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 53
Function PointsGewichte
einfach mittel komplex WerteEingabefunktionen EF 3 4 5Ausgabefunktionen AF 4 5 7Abfragefunktionen AF 3 4 6Dateneinheiten DE 7 10 15Schnittstellen SES 5 7 10
Summe
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 54
Function PointsKomplexitätsfaktor• es gibt einen Katalog mit Zu- und Abschlägen, die einen
Systemkomplexitätsfaktor ergeben (SCF)• FP = UFP * SCF
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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 nahekommt…
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 56
• durch Messen der Lines of Code• und Division durch den entsprechenden Konversionsfaktor der
jeweiligen Programmiersprache
Wie „zählt“ man Function Points?ex post
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 57
Function PointsVorteile• 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
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 58
Function PointsWeitere 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 2.500 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)
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 59
Führt uns zurück zur Frage ..Was ist groß?• Durchschnittliches Projekt in der Finanzindustrie
• 2.000 FP• 1-2 Jahre Durchlaufzeit• ca. 10 MitarbeiterInnen
• ab solchen Größen lohnen sich die Methoden, die in dieser Vorlesung beschrieben werden ...
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 60
Projektrisiko als Funktion der Projektgröße
Quelle [Jones1996]
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 61
Ein großes ProjektFallstudie Phoenix
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 62
Schulungen an der
Hausversion
Schulungen an der
Hausversion
Produktiv-einsatz
Produktiv-einsatz
Zeitlicher Abriß
3maliger Neuanfang durch Weiter-entwicklung der Technologien
3maliger Neuanfang durch Weiter-entwicklung der Technologien
Verantwortung für die Phoenix Plattformdurch agens Consulting
Verantwortung für die Phoenix Plattformdurch agens Consulting
Vorbereitung Produktiv-
einsatz
Vorbereitung Produktiv-
einsatz
“Die Zukunft ist so drängend, daß sie schon Gegenwart ist”
Friedrich Nietzsche
4/98 9/98
„Das“ Projekt Phoenix sind effektiv
3 Projekte
„Das“ Projekt Phoenix sind effektiv
3 Projekte
1/89 1/95
Durch welche markanten Eckwerte kann das Projekt
beschrieben werden?
Durch welche markanten Eckwerte kann das Projekt
beschrieben werden?
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 63
0
1
2
3
4
5
6
7
Projektlaufzeit
Indu
strie
stan
dard
für P
roje
kte
dies
er G
röße
Phoe
nix
Dev
.Ph
oeni
x Te
st
Cus
tom
izin
g 1.
M.
Dau
er in
Kal
ende
rjahr
en
Durch welche markanten Eckwerte kann das Projekt
beschrieben werden?
Durch welche markanten Eckwerte kann das Projekt
beschrieben werden?
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 64
Function PointsDurch welche markanten
Eckwerte kann das Projekt beschrieben werden?
Durch welche markanten Eckwerte kann das Projekt
beschrieben werden?
Größe von Phoenix: Function Points
Dies entspricht ca. 450.000 Lines of Code (Smalltalk)
Die Größe eines durchschnittlichen Softwareprojekts in Checkpoint* beträgt ca. 2.000 Function Points!
Checkpoint ist ein Produkt der SPR
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 65
Bewertung der ProduktgrößeDurch welche markanten
Eckwerte kann das Projekt beschrieben werden?
Durch welche markanten Eckwerte kann das Projekt
beschrieben werden?
0%
10%
20%
30%
40%
50%
60%
10 20 40 80 160
320
640
1280
2560
5120
1024
020
480
Projektgröße in Function Points
Wah
rsch
einl
ichk
eitd
es S
chei
tern
sProjektrisiko
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 66
0
2
4
6
8
10
12
14
16
18
10 20 40 80 160
320
640
1280
2560
5120
1024
020
480
Bewertung der ProduktgrößeDurch welche markanten
Eckwerte kann das Projekt beschrieben werden?
Durch welche markanten Eckwerte kann das Projekt
beschrieben werden?
Projektgröße in Function Points
Prod
uktiv
itäti
n FP
/Per
sone
nmon
aten
Produktivität
PersMonateFP3,44
rMitarbeite100*Monate48PointsFunktion 16.500
=
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 67
Bewertung der ProduktgrößeDurch welche markanten
Eckwerte kann das Projekt beschrieben werden?
Durch welche markanten Eckwerte kann das Projekt
beschrieben werden?
60708090
100110120130140150
1/95 2/95 1/96 2/96 1/97 1/98 1/98 2/98
Entwicklung der Mitarbeiteranzahl (nach Köpfen)
Anzahl Mitarbeiter
Zeit (Halbjahre)
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 68
Projektorganisation
Mit welcher Projekt-organisation kann man
solche Großprojekte managen?
Mit welcher Projekt-organisation kann man
solche Großprojekte managen?
VirtuellerMandant
OPEN1M
OPEN1M
Projekt-management
Qualitäts-management
Plattform-management
TechnischeBasis-Sys.
Produktion
Test-management
Portierung
Projekt-management
Team
Controlling Internes Kontroll-Sys.
SAP IS-IS/CDSAP IS-IS/CDProjektSESAM
ProjektSESAM
Aktuariat1. Mandant
Aktuariat1. MandantIT BereichIT BereichTestzentrum
IBM
TestzentrumIBM
Testzentrum1. Mandant
Testzentrum1. Mandant
ErsteAllgemeine
Interunfall
GeneraliMünchen
Entwicklungslabors
Qualitäts-Sicherung
Architektur
Testzentrum
Datenbank Berechtigung Workflow
CCM Batch Druck/Akt-Archiv
Frameworks
Geschäfts-prozesse Vertrag
Leistung
SubsystemTechnik
Produkt
Tech. Best.führung
ManagementInform. Sys.
Dokument.
Konto
Entwicklungsteams
Partner
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 69
Death March Projekte
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 70
Death March ProjekteDefinition 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]
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 71
Death Marches nach Größe ..• Klein: <= 10 Teammitglieder mit einer Durchlaufzeit von ca. 3-6
Monaten• Mittel: 20-30 Bearbeiter mit einer Durchlaufzeit von 1-2 Jahren• Groß: 100 - 300 Mitarbeiter, 3-5 Jahre Durchlaufzeit• Gigantisch: 1000+ Mitarbeiter, 7-10 Jahre Durchlaufzeit
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 72
Death March Arten
Kamikaze Mission Impossible
Suicide Ugly
Chances of Success
Happiness
[Yourdon2002]
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 73
Einzelprojekt und AnwendungsportfolioPhoenix hat „einige Schrankfächer“ gefüllt - bei weitem nicht alle
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 74
Alles auf einmal machen führt mit Sicherheit zu Desaster oder Death March
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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 ...
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 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
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 77
Abschluss heute ...
• 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
Force CounterForce
Zeit , Kosten Qualität
Your Project
Vorlesung „Software Engineering für große, betriebliche Informationssysteme“, © 2004 Hans Hartmann, Wolfgang Keller, all rights reserved, Universität Leipzig, SS2004 78
Quellen• [Garmus+2000] David Garmus, David Herron: Fuction Point Analysis,
Addison-Wesley 2000.• [Jones1996] Capers Jones, Applied Software Measurement, 2nd Edition,
McGraw Hill 1996• [Jones1997] Capers Jones, The Economics of Object-Oriented Software,
White Paper, spr.com 1997.• [Jones 1998] Capers Jones, Positive and Negative Factors that Influence
Software Productivity, White Paper, spr.com 1998.• [Yourdon1997] Ed Yourdon: Death March, The Complete Software
Developer‘s Guide to Surviving Mission Impossible Projects, Prentice Hall 1997.
• [Yourdon2002] Ed Yourdon: Managing High Intensity Internet Projects, Prentice Hall 2002