SPE.pdf

PROJEKT ENGINEERING Analyse Herwig Mayr Fakultät für Informatik, Kommunikation und Medien Fachhochschule OÖ, Hagenberg © Herwig M...

PROJEKT ENGINEERING Analyse Herwig Mayr Fakultät für Informatik, Kommunikation und Medien Fachhochschule OÖ, Hagenberg © Herwig Mayr, Fachhochschule OÖ, Hagenberg So darf es nicht sein: (Bild: www.gamasutra.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 2  Anforderungsanalyse © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 3  Anforderungsanalyse Ziel © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 4 Anforderungsanalyse – Ziel (I) Grundlage Prinzip der hierarchischen Strukturierung (Rene Descartes, 1637): „Man soll jede schwierige Frage in so viele Teilfragen wie möglich zerlegen, damit man jede einzelne lösen kann.“ (Bild: explorephilosophy.org) Ziel Problemzerlegung (Analyse); unterscheide: ▪ funktionale Anforderungen und ▪ nichtfunktionale Anforderungen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 5 Beispiel: Was sind Anforderungen in unserem LEGO Projekt? Funktionale Anforderungen: Nichtfunktionale Anforderungen: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 6 Anforderungsanalyse – Ziel (II) Definitionen im Bereich der Softwareentwicklung ▪ „Studieren eines Problems, noch bevor Aktionen getätigt werden.“ (T. DeMarco, 1978) ▪ „Studieren eines Problemraumes zur Beschreibung des externen Systemverhaltens.“ (P. Coad & E. Yourdon, 1990) -> WAS/WIE-Trennung ist entscheidend! (Bild: www.beobachter.ch) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 7 Beispiel: Wer stellt/liefert in einem Projekt Anforderungen? Funktionale Anforderungen: Nichtfunktionale Anforderungen: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 8  Anforderungsanalyse Aufgaben © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 9 Anforderungsanalyse – Aufgaben (I) Tätigkeiten lösungsorientierte Erhebung von Ist- und Sollzustand 1 Skizzierung der Systemarchitektur 2 Feststellung der Machbarkeit 3 grobe Abschätzung des Umfanges 4 Verifikation und Validierung der Anforderungen sind wichtig! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 10 Anforderungsanalyse – Aufgaben (II) Eigenschaften einer guten Anforderungsanalyse ▪ Abgrenzen des Projektumfanges ▪ Achten auf Modularität ▪ Achten auf Änderbarkeit ▪ Festlegen der Schnittstellen ▪ Festlegen von Rahmenbedingungen („constraints“) ▪ Prüfen der Realisierbarkeit (Bild: „Anforderungsanalyse mit LEGO; www.learnical.de) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 11 Beispiel: Gute Anforderungen für das LEGO Projekt ▪ Abgrenzen des Projektumfanges: ▪ Achten auf Modularität: ▪ Achten auf Änderbarkeit: ▪ Festlegen der Schnittstellen: ▪ Festlegen von Constraints: ▪ Prüfen der Realisierbarkeit: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 12 Anforderungsanalyse – Aufgaben (III) Schwierigkeiten ▪ Verständnis für das Anwendungsgebiet ▪ zwischenmenschliche Kommunikation ▪ sich ständig ändernde Anforderungen ▪ Wiederverwendbarkeit der Ergebnisse (Bild: level-pro.de) („Eine neu erarbeitete Lösung rechnet sich erst nach drei Projekten!“) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 13  Anforderungsanalyse Techniken © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 14 Anforderungsanalyse – Techniken (I) Das Beherrschen der Komplexität Unterstützende Konzepte (stammen aus der Soziologie!): ▪ Abstraktion (prozedurale Abstraktion, ▪ Organisationsmethoden Datenabstraktion) ▪ Objekt / Eigenschaften ▪ Objekt / Bestandteile ▪ Kapselung (Information Hiding) ▪ Klassifikation von Objekten ▪ Vererbung (Aufbau von Taxonomien) ▪ Verhaltenskategorien ▪ Assoziation ▪ unmittelbare Verursachung ▪ Nachrichtenkommunikation ▪ ähnliche Evolution ▪ ähnliche Funktionalität © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 15 Beispiel: Komplexitätstechniken im LEGO Projekt ▪ Abstraktion: ▪ Kapselung: ▪ Vererbung: ▪ Assoziation: ▪ Nachrichtenkommunikation: ▪ Organisationsmethoden: ▪ Verhaltenskategorien: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 16 Anforderungsanalyse – Techniken (II) Zerlegungstechniken Zerlegungstechnik Komplexitätskriterium Funktionale Strukturierte Information Objektorientierte Dekomposition Analyse Modeling Zerlegung Abstraktion ✓ ✓ ✓ ✓ Kapselung ✓ ✓ ✓ ✓ Vererbung ✓ Assoziation ✓ ✓ ✓ Nachrichtenkommunikation ✓ Organisationsmethodik ✓ ✓ © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 17  (Grafiken: wikipedia.org) Techniken – Zerlegungstechniken (I) Funktionale Dekomposition ▪ hierarchisches Zerlegen in Schritte und Unterschritte (Funktionen, Unterfunktionen, Schnittstellen) ▪ erfordert vom Menschen Transformieren des Problems in „funktionalen“ Raum und Rücktransformieren des Ergebnisses ▪ Darstellung mittels Flussdiagrammen und Struktogrammen ▪ Probleme: ▪ mangelnde Genauigkeit und Vollständigkeit der Beschreibung ▪ einseitiges (rein funktionales) Problemverständnis ▪ indirekte Abbildung ins Modell ▪ schlechte Wiederverwendbarkeit © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 18  (Grafik: info.uni-karlsruhe.de) Techniken – Zerlegungstechniken (II) Strukturierte Analyse ▪ Zerlegen eines Problems anhand der Daten (Datenflussanalyse): ▪ Datenflüsse, -transformationen und –speicher ▪ Prozessbeschreibungen und –randbedingungen ▪ Datenlexikon ▪ „Verfolgen eines Datenflusses“ schwierig für den Menschen ▪ Vorteile gegenüber funktionaler Zerlegung: ▪ für größere Probleme geeignet ▪ komplexere (Daten-)Strukturen möglich © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 19 Techniken – Zerlegungstechniken (III) Strukturierte Analyse mit Datenflussdiagrammen Darstellung mit Datenflussdiagrammen (DFD): ▪ Knoten stellen Daten dar ▪ Kanten stellen Transformationen dar Moderne strukturierte Analyse mit Kontrollflussdiagrammen (Grafik: yourdon.com) Darstellung mit Kontrollflussdiagrammen (CFD): ▪ Knoten stellen Ereignisse (events) dar ▪ Kanten stellen beteiligte Daten dar Reine Datenflussanalysen konnten sich in der Praxis kaum durchsetzen (Daten wurden lange als „Hilfsgrößen“ betrachtet). (Grafik: Jingke Chen, Proc. ESRI) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 20 Techniken – Zerlegungstechniken (IV) Information Modeling ▪ grundsätzlich datenorientierte Zerlegung, aber unter Verwendung komplexer Datentypen (Objekte bzw. Entitäten): ▪ Entitäten und Attribute, ▪ Relationen und andere Assoziationen ▪ Klassifikationsstruktur ▪ Darstellung mittels Entity-Relation- ship-Diagrammen (ERD), erweitert zu semantischen Datenmodellen (z.B. logische Beziehungen) (Grafik: www.edrawsoft.com) ▪ „Objekt“ wird im Sinn abstrakter Datentypen verwendet © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 21 Techniken – Zerlegungstechniken (V) Objektorientierte Zerlegung ▪ Klassifikation von Begriffen bereits durch Aristoteles (350 v. Chr.!). ▪ Auswahl von Klassen/Objekten und deren Hierarchien ist nicht trivial (vgl. Klassifizierung von Tieren und Pflanzen) ▪ Bausteine: ▪ Klassen / Objekte (enthalten Attribute und Methoden) ▪ Klassifikationsstruktur mit Vererbung (Generalisierung / Spezialisierung) ▪ Aggregationsstruktur (Gesamt- / Teilstrukturen) ▪ Kommunikation mittels Nachrichten (Grafik: wikipedia.org) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 22 Techniken – Objektorientierte Zerlegung (I) Die Methode von Abbot zur Bestimmung einer guten Objektstruktur 1. Erstellung einer verbalen Problembeschreibung 2. Identifikation von ▪ Objekten (Hauptwörter) ▪ Attributen (Eigenschaftswörter, Hauptwörter im Genitiv) ▪ Methoden (Zeitwörter) 3. Suche nach geeigneten Basisklassen 4. Vereinfachung und Vervollständigung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 23 Beispiel: Abbot-Methode anhand von 2 Anforderungen (LEGO Projekt) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 24 Techniken – Objektorientierte Zerlegung (II) Vorteile der objektorientierten Zerlegung ▪ Umsetzung aller Konzepte zur Beherrschung der Komplexität ▪ direkte Abbildung des Problems ▪ klare Trennung zwischen Autor und Anwender ▪ Verschmelzung von (Zielerforschung), Analyse, Design, (Implementierung) ▪ standardisierte Darstellung mittels der „Unified Modeling Language“ (UML) – Werkzeug- unterstützung möglich und sehr sinnvoll © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 25 Techniken – Trends bei der Zerlegung Aktuelle Trends Komponentenorientierte Softwareentwicklung ▪ Verteilung von Systemen in möglichst entkoppelte Komponenten Aspektorientierte Softwareentwicklung ▪ separate Betrachtung gewisser Eigenschaften (Aspekte) der Software (z.B. Fehlerverhalten, Systemverteilung) ▪ Anwendung bewährter Praktiken für diese Eigenschaften Anwendungs-Lebenszyklus-Management ▪ Gleichbehandlung von Anforderungen und Änderungswünschen ▪ Verknüpfung von Anforderungen mit Tests und Design/Code © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 26 Techniken – Erstellen von Prototypen (I) Unterstützung der WAS/WIE-Trennung Vorteile: Beschränkung auf Entwicklungsziel Weglassen von Realisierungsdetails Freiheit der Entwickler Nachteile: Vollständigkeit und Widerspruchsfreiheit der Analyse nur schwer prüfbar nur statische Beschreibung der Anforderungen möglich -> Verbesserung durch prototypingorientierte Analyse © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 27 Techniken – Erstellen von Prototypen (II) Arten von Prototypen ▪ vollständige vs. unvollständige Prototypen ▪ breite und flache vs. enge und tiefe Prototypen ▪ revolutionäre vs. evolutionäre Prototypen (Grafik: shop.educatec.ch) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 28 Beispiel: Einsatzgebiete für Prototypen ▪ vollständige Prototypen: ▪ unvollständige Prototypen: ▪ breite und flache Prototypen: ▪ enge und tiefe Prototypen: ▪ revolutionäre Prototypen: ▪ evolutionäre Prototypen: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 29 Techniken – Sprechdisziplin Die moderne, agile Vorgehensweise macht oft das Springen zwischen einzelnen Phasen notwendig. Daher neu eingeführte Begriffe festlegen, verwenden und jeweils Phase dazu angeben. Gedächtnisstützen: ▪ Zielerforschung: Was ist das Ziel? ▪ Analyse: Was ist zu erstellen? ▪ Design: Wie soll das Ergebnis aussehen? ▪ Implementierung: Wie wird das Ergebnis realisiert? © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 30  Anforderungsanalyse Werkzeuge © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 31 Anforderungsanalyse – Werkzeuge Class Papierbasierte Werkzeuge Responsibilities Collaborators ▪ CRC-Karten ObjectName [:Class] Attribute [:Type] ▪ Haftnotizen-Objekte Method () [:Type] ▪ Scripting (textuelle Beschreibung durch Szenarien) Computerbasierte Werkzeuge ▪ UML-Werkzeuge © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 32 Werkzeuge – UML (I) Diagramme der UML für die Analyse Klassendiagramm (class diagram) Statische Strukturdiagramme Strukturmodell (static structure diagrams) Objektdiagramm (object diagram) Analysemodell Sequenzdiagramm (sequence diagram) Interaktionsdiagramme (interaction diagrams) Kollaborationsdiagramm (collaboration diagram) Verhaltensmodell Zustandsdiagramm (state [chart] diagram) Ablaufdiagramme (process diagrams) Aktivitätsdiagramm (activity diagram) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 33 Werkzeuge – UML (II) Vorgehen bei der Analyse unter Verwendung der UML 1. Entwickeln des Strukturmodells 2. Entwickeln des Verhaltensmodells 3. inkrementelles Verfeinern der Modelle © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 34 Werkzeuge – Prototyping (I) Werkzeuge des Prototyping ▪ Generatorsysteme (bestehen aus Editor und Generator; benutzen formale Spezifikationssprachen, z.B. VDM, Z) ▪ datenbankbasierte Systeme (4GL-Systeme, OODB) ▪ Hypertextsysteme (HTML-, XML-basiert) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 35 Werkzeuge – Prototyping (II) Kriterien zur Beurteilung von Prototyping-Werkzeugen ▪ erforderliche Benutzerkenntnisse ▪ Zeitaufwand bis zum ersten Prototyp ▪ zu Grunde liegende Benutzerschnittstellen ▪ Spezifikation der Benutzerschnittstellen ▪ Verwendung des erzeugten Prototypen ▪ Unterstützung von Erweiterungen ▪ Art der funktionalen Erweiterungen ▪ Entwicklungsumgebung ▪ Qualität des Prototypingwerkzeugs ▪ Implementierung des Prototypingwerkzeugs © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 36  Anforderungsanalyse Ergebnisse © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 37 Anforderungsanalyse – Ergebnisse Ergebnisse ▪ Analysebericht ▪ Lastenheft ▪ Machbarkeitsstudie © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 38 Ergebnisse – Analysebericht Analysebericht ▪ Dokumentation der Analyse durch den Auftragnehmer für den Auftraggeber (speziell wenn bereits ein Lastenheft existiert) ▪ dient als Basis für die Erstellung eines Angebots bzw. für die Einreichung bei einer Ausschreibung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 39 Ergebnisse – Lastenheft (I) Lastenheft (bei IEEE: „System Requirements Specification“ – SRS) ▪ ist „die Zusammenstellung aller Anforderungen des Auftraggebers hinsichtlich Liefer- und Leistungsumfang“ (VDI). ▪ Es wird also definiert, WAS WOFÜR zu lösen ist. Das Lastenheft ist vom Auftraggeber vollständig und widerspruchsfrei zu erstellen. In der Praxis wird jedoch vielfach der Auftragnehmer mit der Erstellung beauftragt. Der Auftraggeber prüft das Lastenheft nur und gibt es frei. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 40 Ergebnisse – Lastenheft (II) Gliederungsvorschlag (gemäß VDI 3694): 1. Einführung in das Projekt, Projektziele 2. Beschreibung des Istzustandes 3. Beschreibung des Sollzustandes 4. Schnittstellen 5. Systemanforderungen 6. Anforderungen für Inbetriebnahme und Einsatz 7. Qualitätsanforderungen 8. Anforderungen an die Projektentwicklung 9. Anhang © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 41 Ergebnisse – Lastenheft (III) Checkliste für das Lastenheft Vorprüfung durch den Auftragnehmer auf: ▪ Machbarkeit ▪ Vollständigkeit ▪ Minimalität ▪ Konsistenz ▪ Eindeutigkeit ▪ Plausibilität ▪ Überprüfbarkeit ▪ Modifizierbarkeit (Grafik: www.dilbert.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 42 Beispiel: Erstellen eines Lastenhefts für das LEGO Projekt -> Übung! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 43 Ergebnisse – Machbarkeitsstudie Machbarkeitsstudie ▪ Teilmenge des Lastenhefts, wird bei unsicherer Machbarkeit vorab erstellt ▪ konzentriert sich auf technische und wirtschaftliche Durchführbarkeit des Projekts oder definiert ein machbares Teilprojekt ▪ Oftmals ist auch die personelle Machbarkeit zu überprüfen. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 44  Planung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 45 Man kann zu wenig und zu viel planen! „Man verliert die meiste Zeit damit, dass man Zeit gewinnen will.“ (John Steinbeck) „Wenn du nicht gut planen kannst, plane häufig.“ (Watts Humphrey) (Grafik: 123rf.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 46  Planung Ziel © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 47  ANALYSE Planung – Ziel Vorgaben festlegen für F P E Projektorganisation Planung ▪ Führung (Planning) Entwicklung ▪ Aufgaben (Management) (Development) Ingenieurmäßige ▪ Aufwände Projektentwicklung ▪ Termine (Project Engineering) ▪ Ressourcen Ü D ▪ Kosten Überprüfung Durchführung (Checking) (Production) ▪ Finanzierung ▪ begleitende Maßnahmen K ▪ vorsorgende Maßnahmen Kontrolle Planung bzw. Pläne müssen mit Projektfort- (Monitoring) schritt kontinuierlich verfeinert und aktualisiert werden. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 48  Planung Aufgaben © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 49 Planung – Aufgaben 1 Organisationsplanung 2 Ziel- und Aufgabenplanung 3 Zeitplanung 4 Ablauf- und Terminplanung 5 Ressourcenplanung (Sachmittel, Personal) 6 Kosten- und Finanzplanung 7 begleitende und vorsorgende Planung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 50 Aufgaben – Organisationsplanung Planung der Aufbauorganisation: ▪ Teamorganisation (Mitglieder, Führung) ▪ Kommunikationskonzept (intern, zu AG) ▪ organisatorische Vorgaben (Normen – z.B. QS, Richtlinien) Planung der Ablauforganisation: ▪ Prozesse ▪ Vorgehensmodelle und –methoden ▪ organisatorische Vorgaben (Normen, Richtlinien; analog zu Aufbauorganisation) (Grafik: wirtschaftslexikon.gabler.de) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 51 Aufgaben – Ziel- und Aufgabenplanung Zielplanung: Festlegung der Zielwerte inkl. Ausmaß und Termin der geplanten Zielerreichung Aufgabenplanung: Gliederung und Schätzung von Teilaufgaben, Festlegen der Aufgabenübergänge („Abnahmen“) -> Aufgabenplan (Bild: „Aufgabenplan für Kinder“, www.flickr.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 52 Aufgaben – Zeitplanung Ermittlung des Zeitbedarfs für die Aufgaben (bzgl. Schwierigkeit, Sachmittel, Personal) mittels Aufwandsschätzungen auch Aufwandsplanung genannt; basiert auf Aufgabenplan! Wichtig: Freiraum (slack) einplanen! Aber Achtung (Parkinsonsches Gesetz): (Bild: www.zazzle.de) „Man braucht immer (mindestens) so viel Zeit, wie man hat!“ © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 53 Aufgaben – Ablauf- und Terminplanung auch Meilensteinplanung genannt; basiert auf Aufgaben- und Zeitplan! ▪ Ablaufplanung: Erstellen eines Ablaufgraphen durch Verknüpfung der Aufgaben ▪ Terminplanung: Festlegung von Anfangs- und Endterminen für jede Aufgabe; Meilensteine = wichtige Zwischentermine (Abnahme unter Beisein des AG) (Grafik: www.uke.de) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 54 Beispiel: Meilensteinplanung des LEGO Projekts © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 55 Aufgaben – Ressourcenplanung auch Kapazitätsplanung genannt ▪ termingerechte Zuteilung von Ressourcen (Sachmittel und Personal) ▪ Entscheidung von Eigenfertigung und Zukauf (Bild: Peter Heiligenbrunner, www.goesser.at) Kapazitätsabgleich: gegenseitige Abstimmung von Ablauf- und Terminplanung mit Ressourcenplanung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 56 Aufgaben – Kosten- und Finanzierungsplanung Kostenplanung Ermittlung und terminliche Zuordnung von Kosten (aus verplanten Ressourcen) Finanzierungsplanung Budgetierung, Steuerung der Finanzmittelbereitstellung (aus Kostenplan) (Bild: www.n-tv.de; www.twitter.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 57 Aufgaben – Begleitende und vorsorgende Maßnahmen Begleitende Maßnahmen (Planung für erwünschte Ereignisse): ▪ Testplanung ▪ Installationsplanung, Schulungsplanung ▪ Qualitätssicherungsplanung ▪ Berichtswesenplanung, Dokumentationsplanung, … Vorsorgende Maßnahmen (Planung für unerwünschte Ereignisse): ▪ Gewährleistungsplanung, Wartungsplanung ▪ Sicherheitsplanung, Sicherungsplanung ▪ Notfallplanung, Katastrophenplanung, … Projektplanung muss durch die Ergebnisse der Projektkontrolle aktuell gehalten werden! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 58 Beispiel: Notfallplanung vs. Katastrophenplanung (Bsp. Studium) Notfälle: Katastrophen: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 59  Planung Techniken © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 60 Planung – Techniken Techniken ▪ Aufwandsschätzung ▪ Netzplantechnik ▪ Balkenplantechnik (Grafik: www.spiegel.de) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 61 Techniken – Aufwandsschätzung Verfahren sehr umstritten bzgl. Genauigkeit und Sinnhaftigkeit Beispiele: ▪ Software Lifecycle Management (SLIM) ▪ Consolidated Cost Model v. 2 (COCOMO II) ▪ Function Points (FP) ▪ Object Points (OP) (Bild: pascaldufour.wordpress.com) ▪ Proxy-based Engineering (ProBE) Aufwandsschätzung nach Faustregeln („Planning Poker“, „Magic Estimation“ etc.) ist zumindest gleich gut! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 62 Techniken – Netzplantechnik Eigenschaften: (Grafik : medieninformatik.wikispaces.com/Projektmanagement) ▪ Einteilung in Vorgänge und Ereignisse ▪ Zuordnung von Zeit und Ressourcen ▪ Erstellung eines Vorgänger-/Nachfolgergraphen; spezielle Abhängigkeiten: Ende-Anfang (EA), AA, EE, [AE] Bekannte Beschreibungsmethoden: ▪ Metra-Potenzial-Methode (MPM) (nach Fa. Metra, heute Atos) ▪ Critical Path Method (CPM ) ▪ Program Evaluation and Review Technique (PERT) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 63 Techniken – Balkenplantechnik tabellarische, grafische Darstellung von Aufwänden durch: ▪ Balkendiagramme ▪ Histogramme ▪ Gantt-Charts (nach H. L. Gantt) Eigenschaften: ▪ gut für Ressourcenplanung ▪ schlecht für komplexe Zusammenhänge (Grafik: http://en.wikipedia.org/wiki/Gantt_chart) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 64  Planung Werkzeuge © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 65 Planung – Werkzeuge Projektplanungssysteme (auch: Projektmanagementsysteme) gut zur Dokumentation und zur Planadaptierung Allgemeine Vorgehensweise : 1. neues Projekt anlegen (Name, Beginn, Kalender,...) 2. Vorgänge eingeben und gruppieren (Aufgabenplanung) 3. Dauer zuordnen (Zeitplanung) 4. Vorgänge verknüpfen (Ablaufplanung) 5. Meilensteine festlegen (Terminplanung) 6. Ressourcen zuordnen (Ressourcenplanung) 7. Ressourcen- und Terminkonflikte auflösen (Kapazitätsabgleich) 8. Kosten eingeben (Kostenplanung) 9. Kostenüberschreitungen und Finanzierungslücken beseitigen (Finanzierungsplanung) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 66  Planung Ergebnisse © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 67 Planung – Ergebnisse Interne Ergebnisse : ▪ Aufgabenplan ▪ Terminplan ▪ Ressourcenplan ▪ Kosten- und Finanzplan Externe Ergebnisse : ▪ Meilensteinliste © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 ANA # 68  PROJEKT ENGINEERING Analyse Herwig Mayr Fakultät für Informatik, Kommunikation und Medien Fachhochschule OÖ, Hagenberg © Herwig Mayr, Fachhochschule OÖ, Hagenberg  PROJEKT ENGINEERING Risikobehandlung Herwig Mayr Fakultät für Informatik, Kommunikation und Medien Fachhochschule OÖ, Hagenberg © Herwig Mayr, Fachhochschule OÖ, Hagenberg  Risiko ? …oder bereits Problem ? © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 2 Risikobegriff (I) Risiko = Auswirkungen von Unsicherheiten auf die Ziele eines Systems [ISO 31000:2018] Risiko (Risk) Chance Gefahr (Opportunity) (Threat) In Österreich (ugs.): Risiko = negative Auswirkungen von Unsicherheiten auf die Ziele (positive Auswirkungen = „Chance“!). Aber per 1.1.2021 ÖNORM D 4900 an ISO 31000 angeglichen! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 3 Risikobegriff (II) Gefahr (in Ö/D/CH „Risiko“) = Möglichkeit eines zukünftigen Verlusts oder Schadens (ein potenzielles Problem) Problem = eingetretene Gefahr vorhersehbares Problem = unausweichliche negative zukünftige Konsequenz Chance = Möglichkeit, Erwartungen (an das System) zu übertreffen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 4 Beispiel: Risiken – Chancen und Gefahren im LEGO Projekt Chancen : Gefahren: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 5  Risikobehandlung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 6 Risikobehandlung – Definition Risikobehandlung = proaktive Berücksichtigung wahrscheinlicher Probleme "Softwareentwicklung ohne Überraschungen" → reife Projektorganisation Situierung der Risikobehandlung in der Projektentwicklung ▪ Risikobehandlung ist proaktiv. ▪ Auch viele Techniken der Projektentwicklung reduzieren das Projektrisiko, aber reaktiv. Unterscheide: ▪ allgemeine Risiken ▪ projektspezifische Risiken -> Risikobehandlung nur für projektspezifische Risiken © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 7  Risikobehandlung Ziel © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 8 Risikobehandlung - Ziel ▪ vorab Überlegen der Reaktionen auf potenzielle Probleme inkl. Treffen der vorbereitenden Maßnahmen ▪ Abwägen von Gefahren und Chancen; Eingehen der Risiken mit bestem Chancenpotenzial ▪ quantitatives Bewerten der Risiken zur Auswahl der für die Behandlung sinnvollsten © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 9 Ziel – Die Notwendigkeit von Risiken Existierende Produktionsmittel erreichen bessere wirtschaftliche Performanz nur durch größere Unsicherheit, i.e. größeres Risiko. [Gesetz von Böhm-Bawerk, zit. in „Principles of Software Engineering Management“, T. Gilb] Risiken sind oft wirtschaftliche Chancen, daher die richtigen auf sich nehmen! [„Management“, P. Drucker] Ein erfolgreiches Projekt behandelt – die richtigen! – Risiken erfolgreich. Risikoprofil = Summe der Einzelrisiken eines Projektes © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 10 Ziel – Bestimmung des Risikofaktors Risikoeigenschaften: ▪ Wahrscheinlichkeit („Erwartungswert“) ▪ Auswirkung („Schadenskoeffizient“) ▪ Zeitrahmen ▪ Behandlungsmöglichkeit ▪ Kopplung Risikofaktor = Erwartungswert * Schadenskoeffizient © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 11 Beispiel: Risikofaktor für Risiken im LEGO Projekt © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 12 Ziel – Die 10 wichtigsten Risiken bei Softwareprojekten Top 10-Risikoelemente 1980er Jahre [B. Boehm] 1990er Jahre [B. Boehm] 21. Jhdt. [Pare et al., 2008] 1 personelle Defizite personelle Defizite Fehlen von Projekt-Champions unrealistische Termin- und unrealistische Termin- und Fehlende Unterstützung des 2 Kostenvorgaben, ungenügende Kostenvorgaben oberen Managements Beachtung des Prozesses Entwicklung falscher Defizite bei zugekauften Schlecht verstandener 3 Produkteigenschaften Komponenten (COTS) Systemnutzen schlecht gestaltete falsch verstandene 4 Zweideutigkeiten im Projekt Benutzerschnittstelle Produkteigenschaften „Vergolden“ (Realisieren unnötiger schlecht gestaltete Abweichen des Systems von 5 Eigenschaften) Benutzerschnittstelle lokalen Praktiken und Prozessen schleichende Änderungen der schlechte Architektur, Performanz, Politische Spielereien oder 6 Funktionalitäten Qualität allgemein Konflikte Defizite bei zugekauften Entwicklung falscher Fehlen von erworbenem Wissen 7 Komponenten Produkteigenschaften oder Fähigkeiten Defizite bei extern vergebenen Aufbau auf oder Einbeziehung 8 Personelle Änderungen im Team Aufgaben von Legacy-Software Defizite bei extern vergebenen 9 (Echt-)Zeitperformanz Instabilität der Organisation Aufgaben 10 Überfordern der Technologie Überfordern der Technologie Ungenügende Ressourcen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 13 Beispiel: Behandlung der Risiken im LEGO Projekt © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 14  Risikobehandlung Aufgaben © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 15  Risikobehandlung – Aufgaben Risiko-Identifikation Risiko-Bewertung Risiko-Analyse Risiko-Evaluierung Risiko-Vorsorgeplanung Risiko-Beherrschung Risiko-Überwachung (Grafik: www.safetyhealthtraining.com) Risiko-Überwindung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 16 Aufgaben – Risiko-Identifikation Ermittlung der relevanten projektspezifischen Risikokriterien Quellen: ▪ Analysebericht, Lastenheft, Projektplan ▪ "lessons learned" aus ähnlichen Projekten ▪ unsicher abschätzbare Attribute, ungenaue Schätzwerte ▪ "intelligent" diskutieren Vorgehen: ▪ Bottom-up: Risikonennung durch (alle) Mitarbeiter; führt zu langen Listen, hoher Konsolidierungsaufwand! ▪ Top-down: Risikoermittlung aus der Bilanz und den Unternehmenskennzahlen; dabei wird leicht Wichtiges übersehen! Oft wird nicht angegeben, wie unsicher die Angaben in Dokumenten sind! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 17 Aufgaben – Risiko-Analyse ▪ Ermittlung der Schadenswahrscheinlichkeit und des potenziellen Schadensausmaßes (+ Kopplungen) ▪ durch mehrere Mitglieder in einem Treffen ▪ am besten quantitativ © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 18 Aufgaben – Risiko-Evaluierung ▪ Reihung der Risikoelemente entsprechend ihres Projekteinflusses (Risikofaktor!, Hausverstand anwenden) ▪ Entscheidend ist das Vertrauen in die Zahlen! ▪ Ergebnis: „watch list“ (Top-n-Liste) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 19 Aufgaben – Risiko-Vorsorgeplanung ▪ Festlegung eines Aktivitätenplans ▪ für jedes behandelnswerte Risiko © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 20 Aufgaben – Risiko-Überwachung ▪ Überprüfen der Risiken und Vorsorgepläne auf notwendige Aktivitäten und Planadaptierungen ▪ periodisch und bei Anlass ▪ Oft wird nicht rechtzeitig eingestanden, dass ein Risiko zu einem Problem wird! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 21 Aufgaben – Risiko-Überwindung ▪ Anwenden der im Vorsorgeplan festgelegten Technik der Risikobehandlung ▪ Auftraggeber mit einbeziehen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 22  Risikobehandlung Techniken © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 23 Techniken – Abschätzen des Risikoverhaltens Risikoverhalten von Auftraggeber und Auftragnehmer (sind risikofreudig, risikoindifferent oder risikoscheu) Risikoverhalten bestimmt die Strategie der Risikomitigation Risikomitigation = Risikobehandlung (im engeren Sinn „Risikominderung“; to mitigate = mindern; aber: nicht alle Strategien verringern das Risiko!) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 24 Beispiel: persönliches Risikoverhalten vs. Gruppe im LEGO Projekt © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 25 Techniken – Strategien der Risikomitigation ▪ Risiko-Vermeidung: Elimination eines Risikos durch Wahl eines alternativen Vorgehens (erhöht oft Risiko in einem anderen Bereich) ▪ Risiko-Reduktion: Verringerung des Risikos nach genauer Untersuchung der Risikoursachen (evtl. durch Aneignung zusätzlichen Wissens) ▪ Risiko-Annahme: bewusste Entscheidung, die Konsequenzen im Fall eines Problems zu tragen (schriftlich begründen und unterweisen: Warnung, Instruktion, Ausbildung) ▪ Risiko-Übertragung: Transfer des Risikos auf andere Verantwortungsbereiche (inkl. Zuständigkeit für Problemlösung) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 26 Beispiel: Risikomitigation im LEGO Projekt ▪ Risiko-Vermeidung: ▪ Risiko-Reduktion: ▪ Risiko-Annahme: ▪ Risiko-Übertragung: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 27 Techniken – Mitigation der wichtigsten Risikoelemente Risikoelement Behandlung (Beispiel) 1 personelle Defizite gutes Personal vertraglich binden unrealistische Termin- und Kostenvorgaben, 2 Entwicklung inkrementell durchführen ungenügende Beachtung des Prozesses Defizite bei zugekauften Komponenten 3 Qualifikationstests institutionalisieren (COTS) 4 falsch verstandene Produkteigenschaften Benutzerdokumentation früh liefern 5 schlecht gestaltete Benutzerschnittstelle Prototypen erstellen schlechte Architektur, Performanz, Qualität 6 Systemrahmen verwenden allgemein 7 Entwicklung falscher Produkteigenschaften Hemmschwelle des AG erhöhen Aufbau auf oder Einbeziehung von Legacy- 8 Designmuster anwenden Software 9 Defizite bei extern vergebenen Aufgaben Zwischenergebnisse reviewen 10 Überfordern der Technologie externe Peers einbeziehen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 28 Techniken – Verwenden von Standardprodukten Standardprodukte (“Commercial-off-the-Shelf"-Produkte – COTS) können ebenfalls Risiken reduzieren. Vorteile: Nachteile: sofort verfügbar, kalkulierbar Abhängigkeit von Zulieferer; Lizenzgebühren reife Technologie, umfangreiche zu Beginn Unterstützung nicht optimale Ausnützung des Zielsystems Beschränkungen (benötigter) Funktionalität plattformunabhängig/-übergreifend schwer skalierbar → Produkt "immer" groß kein Wartungspersonal nötig oft inkompatibel zu anderen zugekauften Komponenten → Entscheidung für oder gegen COTS immer schriftlich begründen! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 29 Techniken – Fehlerbaumanalyse (FTA) Fault-Tree Analysis (FTA): [nach: EN ISO 14971:2019; Details: IEC 61025:2006] ▪ Ziel: Einschätzung der Fehlerwahrscheinlichkeiten ▪ Zweck: Systematischer Ansatz zur Gefährdungsanalyse ▪ Fragestellung: deduktiv („Was verursacht…?“) ▪ Vorgehen: Postulierung einer unerwünschten Hauptfolge („Top Event“), rekursive Ursachensuche auf der jeweils nächst niedrigeren Ebene bis zu den „Blackbox“- Komponenten ▪ Darstellung: als Baum; Fehlerkombination mittels UND/ODER © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 30 Techniken – Fehler-Möglichkeiten- und -Einfluss-Analyse (FMEA) (I) Failure Mode and Effects Analysis (FMEA): [nach: EN ISO 14971:2019; Details: IEC 60812:2006] ▪ Ziel: Einschätzung des Schadensausmaßes ▪ Zweck: Systematischer Ansatz zur Untersuchung und Bewertung der Auswirkungen einzelner Fehler („System-FMEA“); auch für Prozesse („Prozess- FMEA“), Endanwender-Verhalten („Anwendungs-FMEA“) etc. ▪ Fragestellung: induktiv („Was geschieht, wenn…?“); wenn kein Fehler erkannt: „Sabotage-Methode“ ▪ Vorgehen: Untersuchung jeweils einer Komponente zu einem Zeitpunkt, Verfolgung der Auswirkungen rekursiv auf der jeweils nächsthöheren Ebene ▪ Darstellung: als Tabelle © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 31 Techniken – Fehler-Möglichkeiten- und -Einfluss-Analyse (FMEA) (II) Beispiel: (Quelle: „Qualitätsmanagement von A bis Z „, F.G. Kamiske u. J.-P. Brauer, Hanser 1995) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 32 Techniken – Fehler-Möglichkeiten- und -Einfluss-Analyse (FMEA) (III) Beispiel: Berechnung der Risikoprioritätszahl (RPZ): RPZ = A * B * E, wobei A = Auftrittswahrscheinlichkeit [1-10], B = Bedeutung („Schadensausmaß“) [1-10] E = Entdeckungswahrscheinlichkeit [1-10] (Quelle: „Qualitätsmanagement von A bis Z „, F.G. Kamiske u. J.-P. Brauer, Hanser 1995) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 33 Techniken – Stärken-Schwächen-Chancen-Risiken-Analyse (SWOT) Strengths-Weaknesses-Opportunities-Threats-Analyse (SWOT) ▪ Ziel: Erarbeitung des Schlüsselprofils eines Unternehmens zur Strategieentwicklung (auch im Bereich Risiko) ▪ Zweck: Chancen- und Risikenanalyse, um sich der eigenen Stärken und Schwächen bewusst zu werden ▪ Entstehung: entwickelt in den 1960er Jahren an der Harvard Business School ▪ Positionierung: im strategischen Management ▪ Darstellung: als Matrix „externe Analyse“ vs. „interne Analyse“ (Quelle: W. Petz, THM Business School) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 34  Risikobehandlung Werkzeuge © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 35 Risikobehandlung – Werkzeuge ▪ eigene (manchmal Web-basierte) Risikomanagement-Werkzeuge (z.B. JPL Defect Detection and Prevention System des NASA Jet Propulsion Lab) ▪ Erweiterung von Projektplanungswerkzeugen (z.B. MS Project) ▪ Anwendung/Erweiterung von Qualitätsmanagement-Verfahren (z.B. Balanced Scorecard) ▪ Planer für alternative Projektverläufe (Critical Path Analyzer) ▪ Tabellenkalkulationsprogramme ▪ "einfache" Listen ("Hauptsache schriftlich") © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 36 Werkzeuge – Excel-Tabelle (Quelle: H. Russegger, Quality Austria) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 37 Werkzeuge – Risiko-Fieberkurve Bewertung nach Checkliste (z.B. GoDV – Grundsätze ordnungsgemäßer Daten- verarbeitung) Erstellung einer „Fieberkurve“: (Quelle: H. Russegger, („GoDV-Handbuch“, Quality Austria) Beck Verlag 2007) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 38  Werkzeuge – Risiko-Hitzekarte Risiko-Portfolioanalyse mittels Risk Heat/Fever Chart: visualisiert Risikoelemente in einer 2D-Karte „Wahrscheinlichkeit vs. Schadensausmaß“ Beispiele: (Quelle: H. Russegger, Quality Austria) (NASA JPL DDP Tool, http://ddptool.jpl.nasa.gov – dzt. offline) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 39  Risikobehandlung Ergebnisse © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 40 Risikobehandlung – Ergebnisse Ergebnisse (Cartoon: www.babs.admin.ch) ▪ Risiko-Top-N-Liste ▪ Risiko-Vorsorgeplan © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 41 Ergebnisse – Risiko-Top-N-Liste Top-N-Liste der Risikoverfolgung: Liste der N wichtigsten identifizieren Risikoelemente, nach Risikofaktor gereiht Ein Eintrag enthält: ▪ Beschreibung des Risikoelements ▪ Risikofaktor ▪ aktuellen Rang ▪ vorherigen Rang ▪ Dauer (wie lange in der Liste) ▪ Fortschritt bei der Behandlung Top-N-Liste regelmäßig (und im Anlassfall) aktualisieren, vor allem neue und aufsteigende Risiken rasch behandeln! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 42 Beispiel: Erstellen einer Risiko-Top-5-Liste für das LEGO Projekt -> Übung! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 43 Ergebnisse – Risiko-Vorsorgeplan (I) Der Risiko-Vorsorgeplan legt die Vorgehensweise zur Risikoüberwachung und -überwindung fest. Er enthält: ▪ zuständiges Personal ▪ Risiko-Bewertungsprozess ▪ Risiko-Überwachungsprozess ▪ Aktualisierungsvorschriften für Top-N-Liste und Vorsorgeplan selbst ▪ Trigger für außerplanmäßige Aktualisierungen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 44 Ergebnisse – Risiko-Vorsorgeplan (II) Der Risiko-Vorsorgeplan enthält für jedes relevante Risikoelement: ▪ Beschreibung des Risikoelementes mit Annahmen und Beschränkungen ▪ Schadenswahrscheinlichkeit und potenzielles Schadensausmaß ▪ Risiko-Kopplung ▪ Alternativen im Projektplan ▪ empfohlene Behandlungstechnik mit Arbeitsschritten ▪ notwendige Einbeziehung des Auftraggebers ▪ Auswirkungen auf den Projektplan ▪ Trigger zur Erkennung des Eintretens des Problems ▪ Kriterien zur Risikoelimination (Bilder: techpinions.com & americanhistory.si.edu) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 45  Risikobehandlung als strategische Aufgabe: Risikomanagement © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 46 Risikomanagement Risikomanagement = Risikoplanung + Risikobehandlung + Monitoring, Review & Verbesserung der Risikobehandlung (eigentl. Risikoentwicklung – Begriff aber wenig gebräuchlich) Integration in das (Qualitäts-)Management des Unternehmens: [gemäß ONR 49000:2014; Darstellung nach H. Russegger, Quality Austria] © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 47 Risikomanagement – Motivation Risikomanagement ist eine Führungsaufgabe! ▪ zur Sicherstellung der Zielerreichung von Organisationen ▪ zur Umsetzung von Sicherheitsanforderungen ▪ zum rechtzeitigen Erkennen (negativer) externe Einflüsse ▪ zur Absicherung externer Erwartungen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 48 Risikomanagement – Basis Risikopolitik (I) Die Risikopolitik muss Aussagen über ▪ die Ziele, ▪ die Strategien und ▪ die Ressourcen für den Umgang mit Risiken in einer Organisation enthalten! Weiters sollen in der Risikopolitik Aussagen über ▪ die Faktoren, die den Erfolg und die Erfolgspotenziale der Organisation bedrohen und ▪ die Kernrisiken, die die Organisation bewusst eingeht, enthalten sein! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 49 Risikomanagement – Basis Risikopolitik (II) Risiko versus Sicherheit: Sicherheit (dt.) = Security + Safety (en.): ▪ Security = Systemsicherheit, ▪ Safety = Betriebssicherheit Kompetenz Sicherheit = Komplexität © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 50 Risikomanagement – Prozess Situierung des Risikomanagements: [ISO 31000:2018, §5.1] ▪ als integraler Teil des Managements, ▪ eingebettet in die Unternehmenskultur und -praktiken, und ▪ maßgeschneidert auf die Geschäftsprozesse der Organisation. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 51 Risikomanagement – Stellen (I) Risikobeauftragter (Risk Representative): verantwortlich für das Risikomanagement; benannt von der obersten Leitung Aufgaben: ▪ Benennung von Risikoeigner und Risikomanager ▪ Sicherstellung der operativen Umsetzung der Risikopolitik inkl. Kommunikation und Ressourcen ▪ Koordination der Aufgaben des Risikomanagementprozesses ▪ Überwachung des Risikomanagementsystems (auf Eignung, Effektivität, Effizienz) (Zusammenfassung aus: ISO 31000:2018 „Risk Management – Principles and Guidelines“) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 52 Risikomanagement – Stellen (II) Risikoeigner (Risk Owner): Führungskraft, kann Risiken beeinflussen; verantwortlich für seine/ihre Risiken Risikomanager (Risk Manager): kann Risiko nicht selbstständig beeinflussen; nicht für Risiko, aber für Durchführung des Risikomanagements verantwortlich (Zusammenfassung aus: ISO 31000:2018 „Risk Management – Principles and Guidelines“) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 RIB # 53  PROJEKT ENGINEERING Risikobehandlung Herwig Mayr Fakultät für Informatik, Kommunikation und Medien Fachhochschule OÖ, Hagenberg © Herwig Mayr, Fachhochschule OÖ, Hagenberg  PROJEKT ENGINEERING Design Herwig Mayr Fakultät für Informatik, Kommunikation und Medien Fachhochschule OÖ, Hagenberg © Herwig Mayr, Fachhochschule OÖ, Hagenberg Design – zwischen Anforderungsanalyse und Implementierung (Grafik: www.dilbert.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 2  Design Ziel © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 3 Design – Ziel Design legt fest, WIE die Anforderungen für die Implementierung aufbereitet werden. -> Codieren soll möglichst klar strukturiert und in einfachen Schritten möglich sein! (Grafik: geekandpoke.typepad.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 4  Design Aufgaben © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 5 Design – Aufgaben Erstellung des Designmodells, das die physische Sicht (Aufbau) und logische Sicht (Verhalten) des zu entwickelnden Systems beschreibt Das Designmodell umfasst: ▪ Systemmodell ▪ Komponentenmodell Dementsprechende Aufgaben: ▪ Erstellen des Systemdesigns ▪ Erstellen des Komponentendesigns Vorgehen nach schrittweiser Verfeinerung (Wirth) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 6 Aufgaben – Designmodell System Architektur Komponente Benutzer Struktur Komponente Verhalten Datenhaltung Komponenten- (extern) Komponente schnittstellen Systemschnittstellen (nach außen) (innerhalb des Systems) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 7 Aufgaben – Gliederung Design Systemdesign Komponentendesign Komponenten- Architektur struktur Komponenten- Schnittstellen verhalten Datenhaltung -> Prioritäten festlegen, Kompromisse schließen! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 8 Beispiel: Designaufgaben im LEGO Projekt ▪ Architektur: ▪ Schnittstellen: ▪ Datenhaltung: ▪ Komponentenstruktur: ▪ Komponentenverhalten: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 9 Systemdesign – Modellierung der Architektur auch Architekturdesign; vielfach durch evolutionäre Prototypen Erweiterung des Strukturmodells ▪ Entwickeln der Systemarchitektur aus dem Strukturmodell der Analyse (Analysebeschränkungen und Implementierungsvorgaben beachten) ▪ wiederzuverwendende Komponenten/Untersysteme einplanen Erweiterung des Verhaltensmodells ▪ Zerlegung in Untersysteme inkl. deren zeitlichem Zusammenspiel (logische Systemgliederung in physische Untersysteme umsetzen -> verteilte Systeme) ▪ danach Abbildung auf Prozesse (Nebenläufigkeiten, Echtzeitverhalten beachten!) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 10 Systemdesign – Modellierung der Schnittstellen Systemschnittstellen werden nur durch Aufbau und Protokoll beschrieben (Details in der Implementierung). Ausnahme: Echtzeitsysteme („Embedded Systems“) Sonderstellung für Benutzerschnittstellen: ▪ Die vollständige Beschreibung aller Interaktionsabläufe erfolgt bereits im Design. ▪ Wegen dynamischer Abhängigkeiten ist Benutzerschnittstellen-Prototyping sehr sinnvoll. ▪ Die Ergonomie der Benutzerschnittstellen („Usability“) ist sehr wichtig (vgl. Qualitätsmerkmale für „Quality-in-Use“). © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 11 Systemdesign – Modellierung der Datenhaltung Organisation des Ressourcenmanagements – v. a. saubere Modellierung der Datenhaltung und -ablage wichtig: (Grafik: Rob Cottingham) ▪ Datenstrukturen im Hauptspeicher ▪ Dateien im Dateisystem / Netzwerk / Cloud ▪ Datenbanken inkl. Anbindung (zentral / verteilt) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 12 Komponentendesign – Modellierung der Struktur Festlegung der Komponentenstruktur: 1. zuerst Abhängigkeiten und Schnittstellen zwischen den Komponenten festlegen und Kontrollfluss spezifizieren 2. wieder zu verwendende Komponenten auswählen 3. Komponentendefinition aus Analyse vervollständigen (wenn notwendig Strukturen ergänzen) 4. iterativ Strukturmodell adaptieren (abstrakte Komponenten einführen) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 13 Komponentendesign – Modellierung des Verhaltens Festlegung des Komponentenverhaltens: ▪ Beschreibung der Abläufe (Methoden) ▪ normalerweise im Design nur deklarativ, z. B.: ▪ uses: Eingabeparameter ▪ changes: Ausgabe-/Übergabeparameter ▪ informs: erzeugte Nachrichten ▪ invariant: Invarianten ▪ requires: Vorbedingungen ▪ ensures: Nachbedingungen ▪ produces: Rückgabewerte ▪ nur bei schwierigen Algorithmen oder Performanzproblemen funktionale Beschreibung ▪ zusätzlich Schnittstellenbeschreibung (in UML Schnittstellenklassen – „Interfaces“ – und Lollipop-Notation) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 14  Design Techniken © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 15 Design – Techniken Techniken ▪ Erweitern der Analysemodelle ▪ Erstellen von Prototypen ▪ Modellgesteuertes Entwickeln ▪ Endbenutzer-Entwicklung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 16 Techniken – Erweitern der Analysemodelle Zweck: Analysemodell vom Problemraum in den Lösungsraum übertragen Vorgehen: ▪ traditionelles Vorgehen: „vollständige“ Erstellung des Designs ▪ modernes, agiles Vorgehen: möglichst einfaches Design – aber Achtung auf gutes Design-Grundgerüst (Big-Picture-Design) ▪ Generalisierung und Promotion von Wissen (erzeugt Taxonomien) ▪ Topdown-Design versus Bottomup-Design – in der Praxis gemischt © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 17 Beispiel: Designalternativen im LEGO Projekt Topdown-Design: Bottomup-Design: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 18 Techniken – Erstellen von Prototypen vor allem experimentelles Prototyping und evolutionäres Prototyping für ▪ Architekturdesign und ▪ Benutzerschnittstellendesign (Grafik: marketoonist.com) Prototyping ist Grundlage aller iterativ- inkrementellen Vorgehensmethoden! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 19 Beispiel: Einsatz von Prototyping Experimentelles Prototyping: Evolutionäres Prototyping: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 20 Techniken – Modellgesteuertes Entwickeln (I) „Model-Driven Development“ (MDD): reales System wird durch reine Transformationen aus einem Modell erzeugt Basis: Model-Driven Architecture (MDA); diese ist Teil des UML2-Standards. Bedenke: UML2 ist eine vollständige Programmiersprache! Vorteile: ▪ plattformunabhängige Entwicklung ▪ Simulation auf Modellbasis möglich ▪ Plattform-Deployment automatisierbar © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 21 Techniken – Modellgesteuertes Entwickeln (II) Vorgehensweise: 1. Erfasse Anforderungen, Modelle und Prozesse in einem plattformunabhängigen Modell (Platform-Independent Model – PIM). 2. Lege Rahmenbedingungen als Metadaten fest (Meta Object Facility – MOF). 3. Erzeuge daraus ein plattformspezifisches Modell (Platform-Specific Model – PSM). 4. Generiere ausführbaren Code vollautomatisch. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 22 Techniken – Endbenutzer-Entwicklung engl. End User Development vor allem durch Maßschneidern und Befüllen von Systemrahmen (Application Frameworks) führt vielfach zu schlechten Ergebnissen (Unerfahrenheit der Benutzer bzgl. gutem Designs, speziell bei Architektur, aber auch bei Richtlinien zur Benutzerinteraktion) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 23 Techniken – Wiederverwendung (I) „Development by Investment“ – Wiederverwendbarkeit muss gegeben sein! Vorgehen: ▪ Wiederverwenden von Bausteinen ▪ Abwandeln von Mustern ▪ Verwenden von Schablonen ▪ Konkretisieren von Systemrahmen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 24 Techniken – Wiederverwendung (II) Wiederverwenden von Bausteinen = unverändertes Verwenden vorhandener Komponenten: ▪ Toolkits ▪ Modulbibliotheken ▪ Klassenbibliotheken Abwandeln von Mustern = Anwenden schematischer Lösungsvorschläge: ▪ Designmuster ▪ Analysemuster ▪ Prozessmuster © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 25 Techniken – Wiederverwendung (III) Verwenden von Schablonen = Erzeugen von Klassen/Objekten mittels ▪ abstrakter Klassen ▪ Schnittstellenklassen Komponente = Zusammenstellung von eng gekoppelten Klassen (z.B. JavaBeans); aktive Komponenten besitzen eigene Intelligenz („intelligente Agenten“) Konkretisieren von Systemrahmen = Erweitern/Adaptieren einer Sammlung von Objekten, die die Grundfunktionalität einer Anwendung bieten („generische Anwendung“) -> ermöglicht Wiederverwendung des Systemdesigns und Kontrollflusses © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 26 Beispiel: Arten der Wiederverwendung ▪ Bausteine: ▪ Muster: ▪ Schablonen: ▪ Systemrahmen: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 27 Techniken – Empfehlungen für ein gutes Design ▪ Entwickle modulare Systeme. ▪ Eine Klasse, eine Abstraktion; eine Methode, eine Funktionalität. ▪ Befolge das Geheimnisprinzip. ▪ Begrenze die Tiefe von Vererbungsbäumen. ▪ Betreibe sinnvolle Wiederverwendung. ▪ Verwende Designmuster und Systemrahmen. ▪ Halte die Anzahl der Objektinteraktionen gering. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 28  Design Werkzeuge © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 29 Design – Werkzeuge Werkzeuge ▪ Computergestützte Designwerkzeuge ▪ Unified Modeling Language (UML) ▪ Prototyping © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 30 Werkzeuge – Computergestützte Designwerkzeuge Die meisten Software-Entwicklungssysteme unterstützen auch das Design (sowie die Analyse). vgl. Forward Engineering – Reverse Engineering – Roundtrip Engineering Forward Engineering Design Roundtrip Engineering Code Reverse Engineering © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 31 Werkzeuge – Diagramme der UML für das Design (vereinfacht) Verteilungsdiagramm Systemmodell (deployment diagram) Designmodell Komponentendiagramm Komponentenmodell (component diagram) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 32 Werkzeuge – Vorgehen beim Design unter Verwendung der UML (I) Entwickeln des Systemmodells: 1. Implementierungsbeschränkungen festlegen 2. Architektur mit Hardware/Systemsoftware abstimmen (Verteilungsdiagramm) 3. Datenhaltung organisieren; Persistenz! (Verteilungsdiagramm) 4. Nebenläufigkeit festlegen (Sequenzdiagramm) 5. Benutzerschnittstelle gestalten (Prototypen) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 33 Werkzeuge – Vorgehen beim Design unter Verwendung der UML (II) Entwickeln des Komponentenmodells: 1. Komponentenschnittstellen festlegen (Komponentendiagramm) 2. wiederverwendete Komponenten festlegen (Komponentendiagramm) 3. Strukturmodell verfeinern (Klassen-/Objektdiagramm) 4. Attribute/Operationen ergänzen (Klassen-/Objektdiagramm) 5. Gemeinsamkeiten ableiten (Klassen-/Objektdiagramm) 6. Abhängigkeiten realisieren (Klassen-, Kollaborationsdiagramm) 7. Kontrollfluss festlegen (Kollaborationsdiagramm) 8. Steuer-/Zustandsvariablen eintragen (Klassendiagramm) 9. Operationen spezifizieren (Zustands-/Aktivitätsdiagramm) Wichtig: Festlegen von Designkompromissen und Designprioritäten nötig! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 34 Werkzeuge – (Benutzerschnittstellen-)Prototyping ▪ Beschreibungssprachen für Benutzerschnittstellen: textuelle Beschreibung des statischen Teils einer Benutzeroberfläche ▪ Werkzeuge des Compilerbaus: vielfach ist Programmablauf durch Strom der Eingabedaten gesteuert; Compilerbauwerkzeuge erstellen Parser etc. ▪ Grafische Werkzeuge zur Erstellung von Benutzerschnittstellen: interaktive Eingabemöglichkeiten; oft kann Ablauf bereits simuliert werden © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 35  Design Ergebnisse © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 36 Design – Ergebnisse Ergebnisse ▪ Designbericht ▪ Pflichtenheft ▪ Benutzerdokumentation © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 37 Ergebnisse – Designbericht Designbericht ▪ Erweiterung des Analyseberichts um die Designmodelle und um die Prototypen ▪ normalerweise intern © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 38 Ergebnisse – Pflichtenheft (I) Pflichtenheft (bei IEEE: „System/Software Design Specification“ – SDS) ▪ ist „die Beschreibung der Realisierung aller Anforderungen des Lastenhefts“ (VDI). ▪ Es wird also definiert, WIE und WOMIT die Anforderungen zu reali- sieren sind. Das Pflichtenheft wird vom Auftraggeber abgenommen; – bei agilem Vorgehen ggf. Alternativen überlegen (Abnahme von Zwischenprodukten, Protokollen etc.). © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 39 Ergebnisse – Pflichtenheft (II) Pflichtenheft Gliederungsvorschlag (gemäß VDI): ▪ wie Lastenheft, nur Adaptierung und Ergänzung um das Kapitel „Design“ Checkliste für das Pflichtenheft zur Vorprüfung durch den Auftragnehmer (auch Lastenheft-Checkliste durchgehen!): ▪ Kompatibilität ▪ technische Qualität ▪ Realisierbarkeit © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 40 Beispiel: Erstellen eines Pflichtenhefts für das LEGO Projekt -> Übung! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 41 Ergebnisse – Benutzerdokumentation (I) Benutzerdokumentation ▪ erste Version bereits während des Designs erstellt, um die Designergebnisse bei der Implementierung leicht zugänglich zu halten ▪ bereits Reviews mit dem Auftraggeber möglich (Grafik: www.cosc.canterbury.ac.nz) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 42 Ergebnisse – Benutzerdokumentation (II) Komponenten ▪ Allgemeine Produktbeschreibung ▪ Installationsanleitung ▪ Anweisungen zur Inbetriebnahme ▪ Kurzeinführung (Tutorial) ▪ Benutzerhandbuch ▪ Referenzhandbuch ▪ Referenzkarte (Quick Reference Guide) ▪ Online-Hilfe ▪ Supplement, Readme-Datei © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 43 Ergebnisse – Benutzerdokumentation (III) Checkliste für die Benutzerdokumentation ▪ Vollständigkeit ▪ Verständlichkeit ▪ Strukturiertheit ▪ Modularität ▪ Benutzbarkeit ▪ Aktualität Unstimmigkeiten zwischen System und Dokumentation werden vom Auftraggeber am raschesten erkannt und sind kaum zu dementieren. -> Sorgfältig prüfen! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 44 Beispiel: Eine Benutzerdokumentation kann nicht zu einfach sein! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 DES # 45  PROJEKT ENGINEERING Design Herwig Mayr Fakultät für Informatik, Kommunikation und Medien Fachhochschule OÖ, Hagenberg © Herwig Mayr, Fachhochschule OÖ, Hagenberg  PROJEKT ENGINEERING Implementierung Herwig Mayr Fakultät für Informatik, Kommunikation und Medien Fachhochschule OÖ, Hagenberg © Herwig Mayr, Fachhochschule OÖ, Hagenberg  Codieren © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 2  Codieren Ziel © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 3 Codieren – Ziel 1. Umsetzen der Designergebnisse in Programmcode (Quellcode) -> Codieren des Designs soll möglichst klar strukturiert und in einfachen Schritten möglich sein! 2. Übersetzen (lassen) des Quellcodes in geeigneten Code für das Zielsystem (Grafik: www.motor-talk.de) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 4  Codieren Aufgaben © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 5 Codieren – Aufgaben Schrittweises, korrektes Umsetzen des Designs: 1. Umsetzen des Systemdesigns 2. Umsetzen des Komponentendesigns 3. (komponentenweises) Übersetzen des Quellcodes in Zielcode 4. Einzeltest jeder Komponente 5. Zusammenbau zum Gesamtsystem (Grafik: geekandpoke.typepad.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 6 Codieren – Geschichte der Programmierung Grundlegende Entwicklungsschritte der Programmierung: (Bild: www.technikimbuero.at ▪ um 1940 große Maschinennähe (Assembler) ) ▪ um 1960 Unterprogramme (erster Abstraktionsschritt) ▪ um 1970 strukturierte Programmierung ▪ um 1980 modulorientierte Programmierung ▪ um 1990 objektorientierte Programmierung ▪ um 2000 komponentenorientierte und agentenorientierte Programmierung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 7  Codieren Techniken © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 8 Codieren – Techniken ▪ Transformieren des Designs ▪ Einfügen logischer Bedingungen ▪ Instrumentieren des Codes ▪ Kontinuierliche Integration ▪ Code-Restrukturierung („Refactoring“) ▪ Erstellen von Testrahmen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 9 Techniken – Transformieren des Designs Transformieren des Designs klassische Kernaufgabe der Programmierung -> Literatur, z. B. (Grafik: maximotimes.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 10 Techniken – Einfügen logischer Bedingungen Einfügen logischer Bedingungen Assertionen sind logische Aussagen, die Bedingungen im Programm entsprechen: ▪ Vorbedingungen ▪ Nachbedingungen ▪ Invarianten © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 11 Beispiel: Assertionen (Bedingungen in Programmen) ▪ Vorbedingungen: ▪ Nachbedingungen: ▪ Invarianten: © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 12 Techniken – Instrumentieren des Codes Instrumentieren des Codes Versehen des Codes mit zusätzlichen Codeteilen zum ▪ Feststellen der Codelokalität zur Laufzeit ▪ Prüfen der Pfadabdeckung ▪ dynamischen Analysieren (Profiling) ▪ Prüfen der Testqualität (Bebuggen, Mutieren) Hauptprobleme: ▪ neue Codeteile können zusätzliche Fehler enthalten ▪ neue Codeteile verändern manchmal das Programmverhalten © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 13 Techniken – Kontinuierliche Integration engl. „continuous integration“ (CI): Jeder Entwickler pflegt kleine Codeänderungen laufend ein (früher „daily build“, jetzt „continuous build“). Voraussetzungen: ▪ eine gemeinsame Codebasis ▪ Übersetzen und Binden auf Knopfdruck ▪ funktionale Tests hoch automatisiert ▪ neueste Programmversion laufend zugänglich -> In der Praxis nur Werkzeug-gestützt sinnvoll möglich (z.B. Apache Ant, CruiseControl, Jenkins)! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 14 Techniken – Code-Restrukturierung („Refactoring“) (I) Code-Restrukturierung = „disziplinierte Änderung eines existierenden Codes zur Designverbesserung ohne Verhaltensänderung“ [Fowler] ▪ stammt aus Smalltalk (~1980); ab ~2000 eng mit eXtreme Programming (und später anderen agilen Vorgehensmethoden) verknüpft ▪ Erkennen restrukturierungsbedürftigen Codes durch Muster („bad smells“) ▪ positiv: einleuchtende Muster mit detaillierten Vorschlägen zur Restrukturierung (teilweise sogar automatisierbar, vgl. z.B. Eclipse) ▪ negativ: Kommentare werden auch als Zeichen eines schlechten Codes gewertet! (eher missverstandener Zweck der Kommentierung) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 15 Beispiel: Ursachen restrukturierungsbedürftigen Codes © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 16 Techniken – Code-Restrukturierung („Refactoring“) (II) Restrukturierung darf Lauffähigkeit nicht verändern! ▪ nur lauffähige Programme restrukturieren ▪ automatisierte Tests verwenden (Test-driven Development) Weiteres Problem: Bei unerfahrenen Programmierern steigt Restrukturierungsaufwand überproportional! [Boehm] Restrukturierung kann Architekturprobleme nicht lösen! ->sinnvollste Anwendung zur Verbesserung des Komponentendesigns © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 17 Techniken – Erstellen von Testrahmen Zweck: Erstellen temporärer Programm(teil)e und Daten zu Testzwecken ▪ Programmierumfang kann umfangreich sein (bis zu gleich viel wie der zu testende Code) ▪ Code von Testrahmen nicht löschen, sondern nur ausblenden Komponenten von Testrahmen: ▪ Stumpf („stub“): Testcode für gerufene Routine ▪ Treiber („driver “): Testcode für rufende Routine ▪ Attrappe („mock-up“, „mock object“): Testcode für Komponenten („mock-up“ wird oft für nichtausführbare Benutzerschnittstellen-Prototypen verwendet) ▪ Dummydatei („dummy file“): Datei mit Testdaten © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 18  Einschub: Testgesteuerte Entwicklung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 19 Testgesteuerte Entwicklung – Idee Idee (engl. Test-driven Development – TDD): Testfälle werden vor dem entsprechenden Programm(teil) erstellt (eigentlich programmiert)! Zweistufiges Vorgehen: 1. Erstellen von Systemtests für Anwendungsfälle (idealerweise durch AG) 2. Erstellen von daraus abgeleiteten Komponententests (durch AN) In der iterativ-inkrementellen Entwicklung oft Ersatz für genaue Produktspezifikation: ▪ Produkt erfüllt immer genau die spezifizierten Testfälle. ▪ Jeder neue Testfall führt zu einer (möglichst kleinen) Produkterweiterung (ggf. Code-Restrukturierung). © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 20 Testgesteuerte Entwicklung – Ablauf Traditionelle Entwicklung Testgesteuerte Entwicklung Analyse Analyse Design Test-Erstellung Implementieren Design Testen Implementieren/Testen Produkteinführung Produkteinführung © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 21 Testgesteuerte Entwicklung – Konsequenz Testgesteuerte Entwicklung beeinflusst Art des Designs und der Implementierung und ist daher keine Technik des Testens! (Bild: www.pathfindersolns.com) -> Big-Picture Design notwendig Testgesteuerte Entwicklung ist eine Entwicklungsmethode! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 22 Beispiel: Testgesteuerte Entwicklung (Beispielcode: R. Ramler, SCCH Hagenberg) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 23 Testgesteuerte Entwicklung – Vorgehen Testfälle werden jeweils zu Beginn der Entwicklung eines Bausteins bzw. Inkrements („Features“ aus Kundensicht) erstellt. Strategien: 1. Starte nicht mit Objekten, starte mit Tests! 2. Erstelle Systemtests für Anwendungsfälle … 3. … und daraus Komponententests für dein Design! 4. Führe die Tests laufend (automatisch) aus! 5. Mache kleine Inkremente. Bewahre den Überblick! 6. Verfahre nach „Red-Green-Refactor “ (*Unit)! Testfälle werden jeweils auch während der Entwicklung auf Basis des Big-Picture-Designs (aus Entwicklersicht) erstellt. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 24 Testgesteuerte Entwicklung – Vorteile Tests sind automatisch ausführbar und daher leicht wiederholbar. Tests werden vor der Realisierung erstellt -> Erzeugung testbaren Codes. Tests dienen als Spezifikation und Dokumentation („besser als nichts“). Die Implementierung wird in jedem Inkrement getestet (einfaches Regressionstesten). Code-Änderungen sind (auch lokal) rasch überprüfbar. Fehler sind rasch lokalisierbar; Folgefehler rasch erkennbar. Fehler bei der Code-Restrukturierung werden normalerweise rasch erkannt. Man verliert weniger Zeit mit Debuggen. Zeit für die Testfallentwicklung wird zu Beginn investiert. Damit fällt eine Belastung zu Iterationsende weg. ;-) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 25 Testgesteuerte Entwicklung – Herausforderungen Testfallerstellung und -auswahl werden nicht unterstützt. Testfallqualität ist schwer beurteilbar. Testfälle hängen teils voneinander und auch von (geänderten) Anforderungen ab. Notwendige Änderungen an Testfällen sind schwer erkennbar. Eine große Anzahl von Einzeltests ersetzen nicht Integrations- und Systemtests. Techniken der systematischen Testfallerstellung werden oft vernachlässigt. „Einige“ korrekt verlaufene Testfälle „sichern“ die Programm-Korrektheit! Testen kann nur die Anwesenheit von Fehlern zeigen, aber nicht deren Abwesenheit! [Dijkstra] © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 26 Testgesteuerte Entwicklung – Weitere Erkenntnisse (optimistisch) Testklassen sind gleichzeitig Testimplementierung und -dokumentation der zu implementierenden Klassen. Testklassen können als Ersatz für eine nicht vorhandene Spezifikation dienen. Tester und Entwickler arbeiten enger zusammen. Es gibt keinen Code ohne Test. Testklassen liefern Sicherheit bei der Code-Restrukturierung. Man entwickelt nicht zu viel und nicht zu wenig Code auf einmal. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 27 Testgesteuerte Entwicklung – Weitere Erkenntnisse (pessimistisch) Die Implementierung wird eher nach hinten verschoben. Man versucht, durch viele, einfache Tests die unangenehmen, komplizierten Tests zu ersetzen. Man glaubt, dass ein Testfall, der einmal passt, auch immer passt. Eine große Anzahl von Einzeltests ersetzt nicht Integrations- und Systemtests. Testgesteuerte Entwicklung verleitet zu Einstellungen wie „Warum denn weitertesten, wenn es eh schon läuft?“. Größtes Problem: Wer testet die Tests? Testfallqualität  Testqualität  Softwarequalität! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 28  Codieren Werkzeuge © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 29 Codieren – Werkzeuge Entwicklungsumgebungen, auch Programmierumgebungen genannt für Codieren benötigt: ▪ Editor ▪ Compiler / Linker ▪ Versions- und Konfigurationsverwaltungssystem © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 30  Codieren Ergebnisse © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 31 Codieren – Ergebnisse Ergebnisse ▪ Quellcode ▪ Systemdokumentation © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 32 Ergebnisse – Quellcode Quellcode ▪ Gestaltung muss bestimmten Regeln unterworfen werden ▪ Kommentierung muss Design widerspiegeln (Grafik: stackoverflow.com) Tipp: Möglichst früh entscheiden, ob Quellcode dem Auftraggeber übergeben wird! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 33 Beispiel: Was ändert sich, wenn der Code dem AG übergeben wird? © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 34 Ergebnisse – Systemdokumentation (I) Systemdokumentation („Software/System Reference Manual“) Zweck: ▪ Erklärung der Implementierung (Grafik: wikipedia.org) ▪ Dokumentation des Know-hows ▪ Grundlage für Wartung ▪ Unterstützung der Kommunikation im Entwicklerteam (zusätzlich Entwicklerkollegen als Kontrollleser) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 35 Ergebnisse – Systemdokumentation (II) Systemdokumentation („Software/System Reference Manual“) Komponenten: ▪ Beschreibung der Systemstruktur ▪ Beschreibung des dynamischen Verhaltens (Grafik: www.boschrexroth-us.com) ▪ Beschreibung der Komponenten ▪ Beschreibung der verwendeten externen Datenhaltung ▪ Beschreibung der zentralen Begriffe ▪ Beschreibung der Installation (Detaillierung des Installationshandbuchs) Die Systemdokumentation darf nicht nur Ergebnisse, sondern muss auch die Gründe dafür (WARUM) dokumentieren. © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 36  Debuggen © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 37  Debuggen Ziel © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 38 Debuggen – Ziel Finden der Ursachen von Fehlern und Mängeln inkl. deren Behebung meist vom Codeersteller selbst durchgeführt (Grafik: www.dilbert.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 39  Debuggen Aufgaben © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 40 Debuggen – Aufgaben Sechs Schritte für effizientes Debuggen: 1. Fehler stabilisieren 2. Fehler lokalisieren 3. Korrektur ausarbeiten 4. Korrektur durchführen u. dokumentieren 5. Korrektur testen 6. auf ähnliche Fehler prüfen Unterschiede beim (Blackbox-)Testen: ▪ andere Person testet ▪ Fehler nicht (genau) lokalisiert ▪ Fehler nicht behoben (Grafik: geekandpoke.typepad.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 41  Debuggen Techniken © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 42 Debuggen – Techniken Debuggen Statische Programmanalyse Dynamische Programmanalyse Fehlersuche mit Programmausführung Fehlersuche ohne Programmausführung Desk Checking Postmortem-Analyse Technisches Review Singlestepping Komplexitätsanalyse Topdown-/Bottomup-Test Strukturanalyse Whitebox-Test Datenflussanalyse © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 43 Techniken – Statische Programmanalyse (I) Desk Checking („Schreibtischtest“) manuelles Durchgehen „am Schreibtisch“, oft anhand konkreter Beispiele (Bild: www.stupidedia.org) Aber: Fachverständnis (Domänenwissen) ist wichtig! © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 44 Beispiel: Fachverständnis – Wer kann schon Gälisch? „Nid wyf yn y swyddfa ar hyn o bryd. Anfonwch unrhyw waith i'w gyfieithu.“ (Bild: bbc.co.uk) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 45 Techniken – Statische Programmanalyse (II) Technisches Review Präsentation von Code in einer Gruppe („First do reviews, then compile!”) Arten: ▪ Walkthrough: Implementierer präsentiert Programm Schritt für Schritt (Alternative: anderes Gruppenmitglied präsentiert) ▪ Codeinspektion: Gruppe prüft Code gegen (verschiedene) Checklisten ▪ Codereview: Gruppe prüft Code vorab und diskutiert ihn mit Implementierer Zeitlimit ist wichtig! (Bild: http://www.jeetesh.net) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 46 Techniken – Statische Programmanalyse (III) Komplexitätsanalyse Bewertung mittels Komplexitätszahlen Beispiele: ▪ Lines of Code (LOC) ▪ Software Sciences (Halstead) ▪ Cyclomatic Complexity (McCabe) Viele Maße beruhen auf keinem realistischen Modell. Es wird eher das gemessen, was leicht zu messen ist! Aber: Eine schlechte Messung ist (meist) besser als gar keine! (Grafik: whiteboxtest.com) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 47 Techniken – Statische Programmanalyse (IV) Strukturanalyse Finden von Strukturanomalien (z.B. unerreichbarem, „totem“ Code) Datenflussanalyse Finden von Datenflussanomalien (Ausgegrauter „toter“ Code; Grafik: www.absint.com) (z.B. verwendeten Variablen ohne Wert) beides oft werkzeugunterstützt (z.B. AbsInt) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 48 Techniken – Dynamische Programmanalyse Postmortem-Analyse („Leichenbeschau“) Auswerten der Ausgaben eines instrumentierten Codes (auch nach Absturz) Singlestepping schrittweises Durchgehen eines Programms, z.B. mit Debugger Topdown-/Bottomup-Test Verwendung (von Teilen) des Testrahmens Whitebox-Test Programmlauf mit verfügbarem Quellcode (vielfach mittels Debugger) © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 49 Effizienz der Techniken beim Finden von Fehlern aus einer Studie von Bob Grady (Hewlett-Packard, ~2000): Testart gefundene Fehler / h / Person Reguläre Verwendung (Kunde) 0,21 Blackbox-Test 0,28 Whitebox-Test 0,32 Technisches Review 1,06 © Herwig Mayr, Fachhochschule OÖ, Hagenberg SPE2 IMP # 50 Beispiel: Effizienz der Techni