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 Hauptaktivität begleiten Produkte abnehmen Hauptaktivität abschließen Werkabnahme 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 PROZESS Merkmale und Eigenschaften des Produktes 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