Universität zu Köln Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. phil. Manfred Thaller

Transkript

1 Universität zu Köln Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. phil. Manfred Thaller Simone Kollmann Christian Weitz

2 Buch Christof Ebert: Systematisches Requirements Engineering Anforderungen ermitteln, spezifieren, analysieren und verwalten 2010³, dpunkt.verlag 2

3 Was ist eine Anforderung? (Ebert 2010, 21) Eigenschaft oder Bedingung, die zur Erreichung eines Ziels benötigt wird Eigenschaft oder Bedingung, die ein System erfüllen muss, um einen Vertrag, eine Norm, oder eine Spezifikation zu erfüllen Dokumentierte Repräsentation einer Eigenschaft oder Bedingung Eine Anforderung ist keine Lösung 3

4 Sichten auf Anforderungen (Ebert 2010, 24ff) Marktanforderungen = Anforderungen aus Sicht des Kunden Produktanforderungen = Anforderungen aus Sicht der Realisierung einer späteren Lösung Komponentenanforderung = Anforderung an eine Komponente eines Produkts 4

5 Arten von Anforderungen (Ebert 2010, 28) Anforderungen Benutzersicht Benutzerschnittstelle Anwendungsfälle Dienstleistungen Funktionale Anforderung Entwicklungssicht Architektur Lastbalancierung Stromversorgung Benutzersicht Performanz Sicherheit Benutzbarkeit Qualitätsanforderung Entwicklungssicht Testbarkeit Wartbarkeit Portierbarkeit Randbedingung Kosten Marketing Durchlaufzeit Vertrieb und Verteilung Organisation Dokumentation 5

6 Was ist Requirements Engineering? (Ebert 2010, 33ff) Systematisches Vorgehen zur Ermittlung, Spezifikation, Analyse, Vereinbarung, Validierung und Verwaltung von Anforderungen Kerndisziplin der Ingenieurwissenschaften Nicht auf Beginn der Entwicklungsphase beschränkt, sondern begleitet den Entwicklungsprozess 6

7 Ziel und Zweck von RE (Ebert 2010, 33) Ziel: Qualitativ gute nicht perfekte Anforderungen zu generieren, die es erlauben, das Projekt mit einem akzeptablen Risiko zu beginnen Zweck: Einverständnis zwischen dem Kunden und dem Softwareprojekt über jene Anforderungen zu erreichen, die durch das Projekt abgedeckt werden 7

8 Standards und Normen (Ebert 2010, 41) 8

9 Herausforderungen im Requirements Engineering (Ebert 2010, 52) Zeitraum bis zur Nutzbarkeit der Software Zeitraum bis zum wirtschaftlichen Nutzen der Software Produktqualität der erstellten Software Umsetzungskosten der Anforderungen in der Entwicklung Kosten der Anforderungen über den gesamten Produklebenszyklus Anpassbarkeit der Software an neue Herausforderungen 9

10 Methodik des Requirements Engineerings (Ebert 2010, 54) Bedürfnisse, Vision, Einschränkungen Ermittlung Abhängigkeiten Markt-, Produkt- Anforderungen, Modelle Spezifikation Status Analyse Einflüsse, Aufwand, Risiko Vereinbarung Validierung Marktanforderungen Komponenten- Anforderungen Spezifikationen, Testfälle Prioritäten Zeitpunkte Status Projekt, Produkt Verwaltung 10

11 Produktlebenszyklus (Ebert 2010, 58ff) Beschreibt alle wichtigen Aktivitäten oder Prozessschritte, um ein Produkt zu definieren, zu entwickeln, zu produzieren, zu betreiben, zu pflegen, zu warten, zu erweitern und schließlich zu beenden. Wird in Phasen aufgeteilt, die durch Meilensteine getrennt werden Eine neue Phase kann erst begonnen werden, wenn die vorhergehende beendet ist Lebenszyklus setzt keine bestimmte Abfolge der Phasen voraus 11

12 Vorgehensmodell (Ebert 2010, 56ff) 1. Strategie und Konzeption = Upstream -Phase, bevor das Projekt begonnen wird Inhalte, Ziele und Meilensteine werden vereinbart Business-Case wird vereinbart Wichtig: gesamten weiteren Zyklus beachten 12

13 Vorgehensmodell 2. Entwicklung = Umsetzung der Anforderungen Bedürfnisse Lösung Anforderungsermittlung Anforderungen, Lastenheft Freigabetest, Abnahme System in Produktion Systemanalyse Systemmodell, Pflichtenheft Systemtest System in Entwicklung System- und Softwareentwurf Architektur, Entwurf Integrationstest Implementierung und Verifikation Legende: Xxx Entwicklungsphase Überlappungen und Iterationen sind möglich Yyy Entwicklungsergebnis 13

14 Vorgehensmodell So viel Prozess wie nötig, um die Geschäftsziele anhaltend zu erreichen, und so wenig Prozess wie möglich, um Flexibilität, Kreativität und Innovationskraft nicht einzuschränken. 14

15 Vorgehensmodell 3. Markteintritt Akzeptanz eines Produkts variiert in ihrem Zeitpunkt und in ihrer Dauer abhängig von Externen Einflüssen 15

16 Vorgehensmodell 4. Evolution/ Wartungsphase Beginnt mit Ende der Entwicklung oder mit Markteinführung Zwei Änderungsarten am existierenden Produkt: Fehlerkorrekturen und Erweiterungen 16

17 Interessensvertreter im RE (Ebert 2010, 90ff) Auftraggeber/ Kunde: erwartet eine Lösung innerhalb bestimmter Rahmenbedingungen Benutzer: benutzen oder betreiben das System Projektmanager: sorgt dafür, dass Anforderungen, Zeitdauer und Aufwand mit den vorhandenen Ressourcen korrespondieren Produktmanager: verantwortlich über den gesamten Produktlebenszyklus, verantwortet den Business-Case eines Produkts. 17

18 Umgang mit Interessensvertretern (Ebert 2010, 86) 1. Identifizieren von Interessensvertretern 2. Beziehungen der Interessensvertreter zum Projekt und untereinander feststellen 3. Beziehungen zwischen Interessensvertretern ausarbeiten, irrelevante Gruppen ausklammern 4. Mögliche Konfliktpotentiale analysieren 5. Win-Win-Möglichkeiten für Schlüsselpersonen entwickeln 6. An Realisierung der Win-Win-Möglichkeiten arbeiten 7. Relevante Perspektiven der Interessensvertreter zur Anforderungsentwicklung feststellen 8. Bild der Interessenssphären vervollständigen 18

19 Anforderungen ermitteln (Ebert 2010, 125ff) Produktvision Was wird das Produkt verändern? Warum ist das Produkt für die Kunden nötig? Welche Erfahrung soll der Kunde damit machen? Wer wird durch das Produkt profitieren? Wie? Wie wird durch das Produkt Geld verdient? Welche Kosten und Risiken sind wir bereit zu tragen? 19

20 Anforderungen ermitteln Einflüsse auf Produktvisionen Kunden Strategie Wettbewerb Produkte Technologien Verfügbare Ressourcen als Restriktion 20

21 Anforderungen ermitteln Schlüsselfrage an Produktvision Was wird bei den Kunden oder Benutzern oder in meinem eigenen Unternehmen anders sein, wenn das Projekt ausgeführt ist? 21

22 Techniken zur Entwicklung der Anforderungen (Ebert 2010, 131ff) 1. Schritt: Mögliche Anforderungen erfassen = Verstehen von Kundenbedürfnissen, Märkten, Wettbewerben und Technologien 2. Schritt: Vision und Umfang festlegen = Abklären, was der Kunde möchte und braucht und was man selbst zur Realisierung braucht. 22

23 Techniken zur Entwicklung der Anforderungen 3. Schritt: Unbekannte Anforderungen und Randbedingungen identifizieren schwierig zu ermitteln 4. Schritt: Methodische Vervollständigung der Anforderungen durch Erarbeiten einer Liste mit potentiellen Funktionen 23

24 Techniken zur Entwicklung der Anforderungen 5.Schritt: Erste Analyse der Anforderungen, um Zusammenhänge und Einschränkungen zu verstehen. bezieht sich sowohl auf Produktmanagement, als auch auf technische Ebene 24

25 Techniken zur Entwicklung der Anforderungen 6. Schritt Priorisierung der Anforderungen wirtschaftliche Entscheidung 7. Schritt: Entscheidung für die getroffenen Annahmen, akzeptierte Randbedingungen, Einschränkungen und Prioritäten Festlegungen müssen in Form einer Vereinbarung dokumentiert werden werden zum Bestandteil der Anforderungen 25

26 Qualitätsanforderungen: ISO/IEC 9126 (Ebert 2010, 139ff) Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Portierbarkeit 26

27 Anforderungen spezifizieren (Ebert 2010, 154ff) Anforderungen strukturieren, dokumentieren und in Zusammenhang bringen durch: Klare und konsistente Spezifikation Vorlagen und Templates Strukturierung Verwenden von Attributen 27

28 Vielen Dank! 28

29 Anforderungsanalyse und -verbesserung (Ebert 2010, 185ff) Sind Anforderungen eindeutig beschrieben? Wie müssen sie ggf. abgeändert werden? Projekt in Modellen beschreiben 29

30 Methoden der Anforderungsanalyse (Ebert 2010, 194ff) 30

31 Kontextanalyse (Ebert 2010, 199f) Systemabgrenzung Schnittstellen erkennen Ggf. Teilsysteme definieren Benutzer Aufzug Servicetechniker 31

32 Glossar (Ebert 2010, 207f) Beschreibt die im Projekt verwendeten Begriffe Hilft dabei, Missverständnisse zu vermeiden 32

33 Use Cases / Anwendungsfälle (Ebert 2010, 200ff) Modellierung wichtiger funktionaler Szenarien Deckt grundlegende Unklarheiten und logische Widersprüche auf 33

34 Funktionale Dekomposition Beschreibt Systemkomponenten Erster Schritt um Teilprojekte zu identifizieren 34

35 Funktionale Dekomposition (Ebert 2010, 202) Aufzug Hardware Software Sensorik Aktorik Kabinen-Controller Alarm- und Fehlerdetektion Tür-Controller Lichtschranke Tür Kabinenmotor Verwaltung offener Fahranforderungen Feuermelder Rauchsensor Türmotor Fahrzielverwaltung Stockwerkskonsole Motorsteuerung Geschwindigkeitsmesser 35

36 Zustandsübergangsmodell (Ebert 2010, 204f) Stockwerk erreicht Fahranforderung oben Bewege Kabine aufwärts Feueralarm Fahranforderung Feueralarm quittiert Feueralarm Stockwerk erreicht Fahranforderung unten Bewege Kabine abwärts Feueralarm 36

37 Zustandsübergangsmodell Formalisierbar Erkennen von Blockaden Ausschluss kritischer Zustände 37

38 CRC-Karten, UML-Klassendiagramm (Ebert 2010, 208ff) Class Responsibility Collaboration Unified Modeling Language Nähe zur Implementationsebene 38

39 CRC-Karten, UML-Klassendiagramm Class Aufzugskabine Responsibilities Fahre Kabine nach oben Fahre Kabine nach unten Kabine auf nächstem Stockwerk anhalten Nothalt im Alarmfall Collaboration Rauchmelder Aufzugskonsole... Aufzugskabine -Betriebszustand : int +FahreAufwärts() +FahreAbwärts() +Stop() +Nothalt() Rauchmelder -Alarm : bool Aufzugskonsole -Stockwerk : int 39

40 Risikomanagement (Ebert 2010, 220ff) Erweiterbarkeit / Modularität Striktes und systematisches Änderungsmanagement Priorisieren von Anforderungen Zwei Prioritäten: hoch und niedrig Verhältnis 75% zu 25% für (Zeit-)Budget 40

41 Qualitätskriterien von Anforderungen (Ebert 2010, 235ff) Eindeutigkeit Realisierbarkeit Konsistenz Prüfbarkeit Relevanz/Geschäftsnutzen 41

42 Qualitätsverbesserung von Anforderungen (Ebert 2010, 240ff) Standards und Vorlagen Reviews und Inspektionen Missbrauchsszenarien Linguistische Analyse Benutzerdokumentation 42

43 Änderungsmanagement (Ebert 2010, 285ff) Anforderungen ändern sich Unklarheiten in Anforderungen Falsche Annahmen und Unsicherheiten Sich ändernde Kundenanforderungen oder Marktbedürfnisse Projekte nicht länger als Monate 43

44 Aufwandschätzung (Ebert 2010, 213ff) Geld Zeit Produktivität Umfang SlimControl KnowledgePlan 44

45 Werkzeugunterstützung (Ebert 2010, 319ff) OSRMT DOORS easee IRqA MKS Integrity Reqtify RequisitePro RMTrak TruereqPLM 45

46 Requirements Engineering (Ebert 2010, 351ff) ~10% des Projektaufwands Kein Selbstzweck Planungsphase kleiner als 50% Projektdauer 46

47 Vielen Dank! 47