LE3-1-5-1 Inhalt und Vorbemerkungen

V - Modell Anwendung auf grosse Projekte Inhalt Kurze Beschreibung des Projektes ABRKFUe: Grobkonzept Grundlagen: Management großer technischer Projekte Vorgehensmodell Submodell Softwareentwicklung (SE) und das ABR-System Softwareentwicklung eines Dienstes im ABR-System Risikomanagement - Erfahrungen aus dem Projekt ABRKFUe

Das sollten Sie heute lernen Es wird die Anwendung des V-Modells für die Erstellung großer Software Pakete erläutert. Basis ist Erstellung eines Softwareproduktes am Beispiel des Projektes ABRKFUe. Als Prozessmodell war zu Beginn ein Wasserfallprozess vorgegeben, im Läufe des Projektes wurde zu einem iterativ-inkrementellen Vorgehen in Anlehnung an dem Rational Unified Prozess (RUP) übergegangen. Es werden Beschreibungsmuster für wichtige Produkte solcher Projekte vorgegeben. Sie sind auf die speziellen Anforderungen des IKE zugeschnitten, können aber leicht auf die Erfordernisse anderer Institutionen angepasst werden (Tayloring).

LE3-1-5-2 V-Modell für grosse Projekte

V-Modell für grosse Projekte Der Entwicklungsstandard des Bundes für IT-Systeme besteht aus drei Teilen: Vorgehensmodell (Was ist zu tun?), Methodenzuordnung (Wie ist etwas zu tun?) Funktionale Werkzeuganforderungen (Womit ist etwas zu tun?) Für eine Gruppe wie sie an Universitäten möglich ist, ist zusätzlich die Frage der Rollen von Bedeutung (Wer muss was tun? ) Im V-Modell wird der Entwicklungsprozess als eine Folge von Tätigkeiten, den Aktivitäten, und deren Ergebnisse, den Produkten, beschrieben. Sie werden im Folgenden für Projekte angegeben, die wir am IKE durchgeführt haben. Der Projektbudget betrug dabei zwischen 0.1 und 1.5 MEuro

Beispielprojekt: Kernreaktor- Fernüberwachung BW Die Kernreaktor- Fernüberwachung (KFÜ) ist ein Entscheidungshilfesystem, welches im Rahmen des Notfallschutzes eingesetzt wird. Es ist wesentliche Grundlage, um im Ernstfall die richtigen Entscheidungen zu treffen Dazu muss es die Entscheider unterstützen bei der zeitnahen Erfassung der Lage ( Messdaten ) der Interpretation der Ereignisse ( GIS-Bezug und Grenzwerte ) der vorsorgenden Untersuchung möglicher Handlungsalternativen und der Beurteilung Ihrer Konsequenzen ( Simulation )

Simulation im Notfallschutz Ziel der Simulation ist es, vorherzusagen, wie sich radioaktive Emmissionen ausbreiten und welcher Belastung die Bevölkerung dadurch ausgesetzt wird. Ziel des Notfallschutzes ist es, diese Belastung so gering wie möglich zu halten. Kern der Simulation sind daher Ausbreitungs- (ABR) und Dosisberechnungsprogramme

Das physikalische Modell einer Ausbreitungsrechnung

Das Simulationsmodell der Komponente ABR Mit welchem Problemen haben wir es zu tun? Numerische Simulation Verschiedene Simulationsprogramme Komplexität nicht darstellbar Verwaltungsinfos Daten durch Benutzer manipulierbar Daten aus externen Quellen Ausfallsicherheit 15.45

Die Komponente ABR als komplexes System System besteht aus vielen Anwendungssystemen, die durch eigene Workflows beschrieben werden Entwicklung des Systems erforderte Basisentwicklungen im Hinblick auf die Anwendungsentwicklung Entwicklung des Systems erforderte Integration vorhandener Soft- und Hardware und die Vergabe von Unteraufträgen System muss unter Echtzeitbedingungen laufen und Ergebnisse von hoher Verlässlichkeit liefern

Klassische Lösung - Verarbeitung des Wissens durch menschliche Agenten

Die Vision - Entscheidungsunterstützung auf hoher Ebene

LE3-1-5-3 Das ABR-System

Das ABR-System im Projekt ABRKFUe Anwendung und Kontext Die ABR ist ein Simulationssystem welches im Rahmen des Notfallschutzes eingesetzt wird Problembereich Die ABR ist eine wesentliche Grundlage, um im Ernstfall die richtigen Entscheidungen zu treffen

Anforderungen im ABRKFUe Höchste Qualitätsansprüche da Einsatzbereich Notfallschutz Sehr hohe Verfügbarkeit und Ausfallsicherheit im Ernstfall Auch unter Stress sichere Verwendung Berücksichtigung aktuellster Messdaten Im Ernstfall automatische Simulation Integration in das Rest-KFÜ Wartungsfreundlich Leicht und kostengünstig erweiterbar

Architektur des KFÜ Messdaten Simulationen Auswertungen Darstellungen

Architektur des ABR-Systems (1) Flache Struktur Aufgaben sind auf einzelne Dienste verteilt Zur Kommunikation zwischen den Diensten wird ein Kommunikationsframework verwendet Basis für das Kommunikationsframework ist Corba Kopplung von Einzeldienstleistung zu Gesamtdienstleistungen mittels Workflows Schnittstellen nach außen verwenden DCOM bzw. SQL*NET für die Kommunikation Trennung zwischen Daten und Metadaten Austausch der Daten erfolgt über ein Repository

Architektur des ABR-Systems (2) Client Interface Client Manager Alarm Service 9 Simulation Services Klientendienste Simulationsdienste Datenbeschaffungs- dienste ZDH Service Emissions- daten Service Stammdaten Service Calculator Service Ersatzwert Service Kommunikationsframework Service Agent Layer (SAL), Corbabasierte Middleware Strategie Service Archiv Service Workflow Service Protokoll Service Ressource Service ABR Watchdog Repository Service Admin Service Systemdienste sonstige Dienste

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

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.

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

LE3-1-5-4 Planung von Projekten

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

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

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.

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

Stufen des Tailoring Generisches V-Modell

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

LE3-1-5-5 Qualitätsmanagement als Basis des Erfolges

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

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

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

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

Submodell Softwareentwicklung (SE)

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

Diese Fragen sollten Sie jetzt beantworten können Welche Schritte sind bei Planung und Durchführung eines Projektes am IKE zu beachten Wo findet man geeignete Vorlagen Warum ist Qualitätssicherung eine Aufgabe, die zu Beginn des Projektes angegangen werden sollte Welche Rollen müssen besetzt werden und wie ertüchtigt man vorhandene Mitarbeiter/innen