Was bei der Modellierung komplexer Systeme bedacht werden sollte

Präsentation zum Thema: "Was bei der Modellierung komplexer Systeme bedacht werden sollte"—  Präsentation transkript:

1 Was bei der Modellierung komplexer Systeme bedacht werden sollte
Projektvorbereitung Mitarbeiterentwicklung Fehlerverfolgung Vorgehensmodell(e) Ressourcenplanung Standardnotation und Programmierrichtlinien Inkrementelles Vorgehen ABR-System Kooperation mit Projektpartnern und Kunden Risikomanagement Spezifikation, Anforderungs- und Änderungsmanagement Konfigurations- und Versionsmanagement Projektcontrolling und -Steuerung Gemeinsames Vokabular

2 Vorgehensmodelle in ABRKFUe
Zu Beginn des Projektes V-Modell in Kombination mit Wasserfallmodell (Vorgabe strukturierte Analyse) Im Laufe des Projektes Wechsel zu V-Modell in Kombination mit einer iterativ-inkrementellen Vorgehensweise (in Anlehnung an RUP). Dadurch wurden viele Spezifikationsarbeiten wertlos, es konnten aber in einer endlichen Zeit experimentierbare Ergebnisse erzielt werden Das V-Modell kam über den gesamten Projektlebenszyklus zum Einsatz. Dies ergab hohe Transparenz, jedoch musste die Handhabung geändert werden, um die Prozessbeteiligten nicht durch eine Flut von Informationen lahmzulegen.

3 Submodell Projektmanagement
Projekt initialisieren Auftrag erteilt Hauptaktivität initialisieren Aufgaben verteilt Produkte abnehmen Hauptaktivität begleiten Werkabnahme Hauptaktivität abschließen Projekt abschließen Schlussrechnung

4 Planung von Projekten bei iterativ-inkrementellem Vorgehen (PM)
Was soll geplant werden? Grobe Festlegung der Iterationen während Antragstellung Meilensteine Was soll wann erreicht werden Feinplanung mit Aufwandsabschätzung (nur) der nächsten Iteration während Projektdurchführung Wer plant? Projektleiter Architekt ggf. weitere Fachleute aber auf keinen Fall Jeder und was gefällt

5 Rollen im Projekt (Das Team)
Zentrale Rollen Fachwissen Architekt Technologie Domänenexperte Anwenderungsbereiche Projektleiter Organisation Qualitätsmanager Projektziele Weitere Rollen Fachwissen Systemanalytiker Designer Programmierer ....

6 Besetzung der Rollen Alle als projektnotwendig identifizierte Rollen müssen mit geeignet qualifiziertem Personal besetzt werden. Eine Person kann gleichzeitig mehrere Rollen übernehmen. Ggf. muss benötigtes Know-How durch Weiterbildung geschaffen oder zugekauft werden. Die Zuordnung von Rollen zu Mitarbeitern kann frei erfolgen mit zwei Ausnahmen: Personen mit QS-Rollen dürfen nicht an der Erstellung der von ihnen zu prüfenden Produkte beteiligt sein (dies ist abhängig von der Kritikalität unterschiedlich streng zu handhaben). Zu trennen ist auch die Rolle des Projektmanagers von QS- und SWE-Rollen. Es ist somit eine Mindestanzahl von zwei bis drei Personen an einem Projekt beteiligt. Besetzung der Rollen kann Aufwände bis zu einem Faktor 10 variieren lassen oder Projekte sogar ganz zum Scheitern bringen.

7 Anpassung des V-Modells an Projekte - Tailoring
Das V-Modell soll sowohl für kleine als auch sehr große Projekte geeignet sein. Demzufolge definiert es alle Aspekte, die in diesen Projekten auftreten können. Das Tailoring sieht vor, aus dem V-Modell durch Streichungen ein an das Projekt angepasstes Modell zu erstellen. Für das Tailoring stehen kommerzielle Werkzeuge zur Verfügung. Die Projects Web-Seiten von Andreas Kitz helfen bei der Erstellung des Projekthandbuches. Vorschläge für IKE Projekthandbücher werden hier bereitgestellt: IKE-Projekthandbuch Antrag IKE Projekthandbuch Durchführung IKE Muster Abschlussbericht

8 Stufen des Tailoring Generisches V-Modell

9 Grundaufgaben der Planung
Welche Aufgaben sind durchzuführen (Iterations-Planungs-Matrix) Welche Ziele sollen erreicht werden Wie können diese überprüft werden Welche Randbedingungen sind zu beachten Abgrenzung - was wird nicht getan Bestimmung der Verantwortlichen Zuteilung der Mitarbeiter zu den Aufgaben Aufwandsschätzung

10 Qualitätsmanagement als Basis des Erfolges
Vereinbarung der Ziele überprüfbar und realistisch verstehbar akzeptiert von allen Beteiligten Überprüfung des Erreichten Maßnahmen zur Beurteilung der Ergebnisse Beurteilung der Ergebnisse Hinweis auf Konsequenzen QM und Projekt QM hat moderierende und organisierende Rolle QM ist aktiv mit verantwortlichen Tätigkeiten verbunden QM unterstützt PM im Bestreben Projekt erfolgreich zu machen

11 Nachweis durch Prüfung Nachweis durch Zertifizierung
Softwarequalität Qualitätsziele werden während der Konzeptfindung vorgegeben. Der Entwicklungsprozeß bestimmt Eigenschaften und Qualität des Produktes. Die Qualität des Entwicklungsprozesses kann definiert gemessen und verbessert werden. Produktqualität Nachweis durch Prüfung Anforderungen und/oder Erwartungen an das Produkt Merkmale und Eigenschaften des Produktes PROZESS Anweisungen Ausführung Prozessqualität Nachweis durch Zertifizierung Produktqualität wird durch gute Prozeßqualität leichter erreicht QM meint daher Festlegung des Vorgehensmodelles und Prüfung der darin beschriebenen Produkte

12 Submodell Qualitätssicherung
QM in PH anlegen QS-Initialisierung Prüfung vorbereiten Testziele und Tests beschreiben Prozessprüfung von Aktivitäten Durchführungs- entscheidung Soll-ist Vergleich Produkt prüfen QS-Berichts- wesen Fertigprodukt prüfen Tests durchführen Abnahmetest

13 Das Projekthandbuch als Basis des QM
Das Projekthandbuch beschreibt die Ziele des Projektes die Regeln zur Überprüfung des Erreichten die Wege zum Erreichen der Ziele die zu erfüllenden Rand- und Nebenbedingungen durch projektspezifische Konkretisierung eines Vorgehensmodells. Das Projekthandbuch enthält daher Rahmenrichtlinien Prozessleitfaden Durchführungsrichtlinien und -hilfen Konkretisierungen werden oft erst im Laufe des Projektes möglich. Das Projekthandbuch ist also ein dynamisches Dokument. Das gilt insbesondere bei iterativem Vorgehen

14 Submodell Softwareentwicklung (SE)

15 Testgetriebene Entwicklung
Testgetriebene Software-Entwicklung (Thaller: ISO 9001) zeigt die Verbindung von Prozessmodell und Qualitätsicherung

16 Submodell SE 1(Anforderungsanalyse) im ABRKFUe
Erstellung einer Spezifikation des Gesamtsystems gemeinsam mit dem Kunden und den Projektpartnern als Word-Dokument Erstellung eines fachlichen Modells mittels eines SA-Werkzeuges (Promod) Spätere Abweichungen bzgl. der Anforderungen müssen mittels eines Change-Requests beantragt und von einem Projektkontrollgremium genehmigt werden Spec Change- Requests

17 Submodell SE 2 (Entwurf) im ABRKFUe
Grobentwurf der Architektur des ABR-Systems Erstellung der Rahmenkonzeption der Architektur als Word-Dokumente Entwurf der Architektur mittels UML und Rational Rose und Bestimmung der einzelnen Dienste Entwurf eines Kommunikationsmodells mittels UML und OCL Rahmen- konzeption I - III

18 Submodell SE 3 im ABRKFUe
Erstellung der Lastenhefte für die verschiedenen Dienste (Software-Komponenten) als Text-Dokumente Erstellung der Pflichtenhefte für die verschiedenen Dienste (Software-Komponenten) als Text-Dokumente Erstellung der Systemmodelle für die verschiedenen Dienste (Software-Komponenten) mittels Use-Cases in Rational Rose Lastenheft Dienst x Pflichtenheft Dienst x

19 Submodell SE 4(-SW) im ABRKFUe
Erstellung der Systemarchitektur der verschiedenen Dienste mittels UML, Powerpoint-Grafiken und Text-Dokumenten Erstellung der Dienstleistungs-beschreibungen aller Dienstleistungen der Dienste unter Verwendung des Kommunikations-modells als Text-Dokumente System- architektur Dienst x Dienstleistungs- beschreibung Dienst x

20 Submodell SE 5(-SW) im ABRKFUe
Entwurf der Dienste mittels UML und Rational Rose Erstellung der Komponenten-spezifikationen der Dienste als Text-Dokumente aus dem Entwurf Erstellung der Testspezifikation für die verschiedenen Dienste Komponenten- spezifikation Dienst x Test- spezifikation Dienst x

21 Submodell SE 6(-SW) im ABRKFUe
Implementierung der verschiedenen Komponenten der einzelnen Dienste in C++ und Fortran Durchführung von Tests für die jeweiligen Komponenten (Modultests)

22 Submodell SE 7(-SW) im ABRKFUe
Integration der einzelnen Komponenten zu Diensten Erstellung von Testprozeduren für alle Dienste entsprechend der Testspezifikation der Dienste Durchführung von Tests für alle Dienste entsprechend der Testspezifikation der Dienste Erstellung von Testprotokollen als Text-Dokumente Test- prozeduren Dienst x Test- protokoll Dienst x

23 Submodell SE 8 im ABRKFUe
Integration der Dienste zum ABR-System Test des ABR-Systems standalone Bereitstellung einer Abnahmetest-spezifikation (ATS) des ABR-Systems für den Auftraggeber als Text-Dokument ATS für das ABR-System

24 Submodell SE 9 im ABRKFUe
Installation des Systems im Umfeld beim Auftraggeber Durchführung und Protokollierung der Abnahme auf der Basis der ATS Einführung des Auftraggebers in den Umgang mit dem System Erstellung von System- und Benutzerhandbuch Wartung und Pflege (Fehlerbeseitigung, ...) Globaler Testbericht Test- protokoll Testfall x.x ATS-Fehlerliste Abnahme- erklärung Benutzer- handbuch System- handbuch

25 Handhabung des Submodells SE in ABRKFUe
SE 1 als Wasserfallprozess, Änderungen mittel Change-Requests SE 2 begonnen als Wasserfallprozess, spätere Erweiterungen des Kommunikationsprozesses erfolgten iterativ-inkrementell SE 3 begonnen als Wasserfallprozess, spätere Modifikationen erfolgten iterativ SE 4 begonnen als Wasserfallprozess, spätere Modifikationen erfolgten iterativ-inkrementell SE 5 begonnen als Wasserfallprozess, spätere Modifikationen erfolgten iterativ-inkrementell SE 6 erfolgte zum Teil als Wasserfallprozess, als auch zum Teil iterativ-inkrementell SE 7 erfolgte iterativ-inkrementell SE 8 erfolgte iterativ-inkrementell SE 9 als Abschluss entsprechend den Notwendigkeiten

26 Was wir heute anders machen würden Die SE Umgebung des Jahres 2003 am IKE
Elemente der SE Umgebung Omondo als Casetool zur Erstellung von UML Diagrammen Eclipse als Entwicklungsumgebung für Java Junit testframework CVS zum Produktmanagement und zur Integration Framework SIMPLAT als Basis der Implementierung Cocoon zur Publikation im Netz Eine Einführung in die SE Umgebung am IKE liefert Ihnen das Praktikum Simulation komplexer technischer Anlagen Es ist primär dafür gedacht, Sie in diese Umgebung und ihre Tools einzuführen und Ihnen das Finden und Beherrschen Ihrer Rolle zu ermöglichen

27 Submodell Konfigurationsmanagement
KM erfolgt am IKE durch CVS Durch Anlegen der Projektstruktur werden die weiteren Aufgaben weitgehend automatisch erledigt KM-Initialisierung Konfigurations- verwaltung Änderungs- management KM-Berichts- wesen Datensicherung

28 KM am IKE Konfigurationsmanagement erfolgt am IKE auf Basis von CVS
Folgende Projektstruktur hat sich bewährt

29 Risikomanagement - Beispiele aus ABRKFUe
Risiken: Fachlicher Art Aufwand, Termine Kosten Äußere Einflüsse Fachlicher Art: Zu optimistische Einschätzung bzgl. Umsetzbarkeit und Tragfähigkeit von Konzepten Aufwand, Termine, Kosten: Der Aufwand bis zur entgültigen Fertigstellung einer SW-Einheit wird unterschätzt (95% fertig Problem) Von außen vorgegebene Termine passen nicht zur Umsetzung Mitarbeiterfähigkeiten und Kenntnisse passen nicht zu den Aufgaben Äußere Einflüsse: Konkurs von Unterauftragnehmer Einstellung des Supports für Basistechnologien und Plattformen

30 Risikomanagement - Erfahrungen aus ABRKFUe
Risikoorientierte Vorgehensweise: Risiken sichtbar machen über den gesamten Projektlebenszyklus Risikoanalyse in regelmäßigen Abständen, ab Beginn eines Projektes aktuelle Planzahlen und Plandaten mit regelmäßigen Messungen vergleichen Die größten Risiken frühzeitig angehen Regelmäßige Beobachtung der Entwicklungen im Umfeld des eigenen Tätigkeitsbereiches Verwendung eines geeigneten Vorgehensmodells Regelmäßige Weiterqualifizierung des Mitarbeiterstammes

31 Templates für Produkte
Im folgenden werden bewährte Strukturen für typische Produkte angegeben. Sie müssen sowohl an die Anforderungen der Auftraggeber als auch an die Technologieentwicklung am IKE angepasst werden. Alle Produkte können sowohl ins Intranet als auch bei Bedarf ins web gestellt werden: Spezifikation - oft Arbeitsprogramm aus Antrag Projekthandbuch Change Request Komponenten Lastenheft Pflichtenheft Spezifikation Testspezifikation Testprozedur Testprotokoll Abnahmetests Spezifikation Protokoll Fehlerliste Testbericht Abnahmeerklärung Benutzerhandbuch Systemhandbuch Abschlussbericht