Seminar Messbarkeit von Anforderungen. Betreuer: Eric Knauss. Gennadi Mirmov

Größe: px

Ab Seite anzeigen:

Download "Seminar Messbarkeit von Anforderungen. Betreuer: Eric Knauss. Gennadi Mirmov"

Ralph Schulz
vor 8 Jahren
Abrufe

1 Just Enough Requirements Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss Gennadi Mirmov

2 Gliederung Einleitung Anforderungen Requirements Management Just Enough Requirements Elicitation Requirements Triage 2

3 Einleitung Softwareprojekt Akzeptable Ergebnisse Qualität des Produktes Zeitplan ist fest Budget ist begrenzt Wenig Zeit mit Anforderungen Unzufriedene Kunden Fehlerhaftes System Viel Zeit mit Anforderungen Verspätung des Projektes Überlastung des Budgets 3

Anforderungen Unzufriedene Kunden Fehlerhaftes System Viel Zeit

4 Fragen zu Anforderungen Wann handelt es sich tatsächlich um eine Anforderung und wann nicht bzw. welche Anforderungen sind überhaupt gültig? Welche Anforderungen sind für den Kunden ausschlaggebend? Wie viele Anforderungen müssen überhaupt gesammelt werden? 4

5 Fragen zu Anforderungen (2) Wie viel Zeit muss in die Ansammlung von Anforderungen investiert werden? Wie viele Anforderungen müssen bzw. können später erfüllt werden? Welche Anforderungen müssen zuerst, aufgrund des möglichen Zeitplans, erfüllt werden? Wlh Welche Anforderungen lässt das verfügbare Budget zu? 5

6 Anforderungen Definition: Eine Anforderung ist eine äußerlich wahrnehmbare Charakteristik eines gewünschten Systems. Test auf Gültigkeit 1. Die Auswirkung und die Erfüllung einer Anforderung muss von einem Punkt außerhalb eines Systems beobachtbar sein 2. Die Anforderung muss helfen den Bedürfnissen des Kunden gerecht zu werden. 6

Die Auswirkung und die Erfüllung einer Anforderung muss von einem Punkt außerhalb

7 Beispiel: Anforderungen Maus für ein Notebook Anforderung Die Maus soll drei Knöpfe haben. Äußerlich beobachtbarb b Ja Gewünscht Unklar 7

8 Requirements Management Menge von Aktivitäten Requirements Management Requirements Requirements Requirements Elicitation Triage Specification Erhebung von Anforderungen Auswahl von Anforderungen Dokumentation von Ergebnissen 8

Requirements Elicitation Triage Specification Erhebung

9 Requirements Prozess Kontinuierliche Aktivität Kunden werden immer wieder befragt Neu Anforderungen hinzufügen / entfernen Anforderungen erweitern Anforderungen prüfen / korrigieren Requirements Management Software Entwicklungen Software Entwicklungen Software Entwicklungen 9

Anforderungen erweitern Anforderungen prüfen / korrigieren

10 Just Enough Requirements Prozess? Flugzeugsteuerung Software 0 10 keine Prozesse viele Prozesse keine Standards genaue Standards keine Dokumentation viel Dokumentation keine Reviews strenge Reviews keine Requirements viele Requirements schnelle Entwicklung langsame Entwicklung Hohes Risiko für Fehleranfälligkeit Geringes Risiko für Fehleranfälligkeit 10

Standards keine Dokumentation viel Dokumentation keine Reviews strenge Reviews keine

11 Just Enough (2) Sowohl zu wenig, als auch zu viel Investition in Anforderungen kann gefährlich sein 11

12 Studie der NASA Wie viel Zeit sollte man in Anforderungen investieren? Prozent der Projekt Ko ostenübers schreitung Prozent der Projekt Kosten für Planung (einschließlich Anforderungen) 12

13 Beispiel: Anforderungszeit und Kostenüberschreitung Softwareprojekt 5 Leute 4 Monate Zeit 3200 (5 * 4 * 4 * 40h) Personenstunden stehen zur Verfügung Anforderungen im Softwareprojekt 3 Leute 1 Woche lang 120 (3 * 40h) von 3200 Personenstunden ca. 4 Prozent des Gesamtbudgets Gestützt auf NASA Studie Im besten Fall 1280 ( ca. 1,5 Monate) Personenüberstunden, 40 %Kostenüberschreitung Im schlechtesten Fall 5440 (ca. 7 Monate) Personenüberstunden, 170 %Kostenüberschreitung 13

Personenstunden ca. 4 Prozent des Gesamtbudgets Gestützt auf NASA Studie Im besten Fall 1280 ( ca.

14 Beispiel (2): Anforderungszeit und Kostenüberschreitung Softwareprojekt 5 Leute 4 Monate Zeit 3200 (5 * 4 * 4 * 40h) Personenstunden stehen zur Verfügung Am besten, gestützt auf die NASA Studie Zwischen ca. 320 bis 640 Personenstunden für Anforderungsaktivitäten einplanen 3 Personen zwischen ca. 3 und 6 Wochen setzen sich mit Anforderungen auseinander Bei mehr als 6 Wochen steigt Projekt Kostenüberschreitung schnell an 14

320 bis 640 Personenstunden für Anforderungsaktivitäten einplanen 3 Personen zwischen ca.

15 Die Wichtigkeit von Requirements Management Fehler in der späteren Entwicklungsphase sind schwieriger und teurer zu identifizieren und zu korrigieren als in der früheren Anforderungsphase ist wichtig, um später Fehler zu vermeiden Sheldon s Verteilung der Fehlertypen Hall s Verteilung der Fehlertypen 15

korrigieren als in der früheren Anforderungsphase ist wichtig, um später

16 Requirements Elicitation Interessen der Stakeholder bestimmen bzw. einzufangen verteilt sich auf die Dauer des ganzen Projektes zwei Wege Interaktion zwischen dem Anforderungsteam und den Stakeholdern Anforderungsteam sollte folgende Leute einschließen Leute, die sich für den Erfolg der Firma interessieren Leute, die sich für den Erfolg der Stakeholder interessieren Elicitationi i Stakeholder Requirements Team 16

Anforderungsteam und den Stakeholdern Anforderungsteam sollte folgende Leute einschließen Leute, die

17 Die Wichtigkeit der Elicitation Phase Warum macht man Elicitation? Das zu lösende Problem muss erst verstanden werden Ohne Elicitation Es besteht hohe Wahrscheinlichkeit, falsches System zu entwickeln Unzufriedene Kunden 17

18 Elicitation Techniken Interview Stakeholder werden befragt Facilitated t dg Group Meetings Versammlung mit Stakeholdern Über Probleme wird laut diskutiert Alle Ideen und Meinungen werden notiert Computer-Supported pp CooperativeWork Kommunikation zwischen Gruppen von Leuten, die sich zur selben Zeit an verschieden Orten befinden, über den Computer Observation Stakeholder werden bei ihrer Arbeit passiv studiert Fragebogentechnik Prototyping 18

CooperativeWork Kommunikation zwischen Gruppen von Leuten, die sich zur selben Zeit an verschieden Orten

19 Requirements Triage Anforderungen werden eingeschränkt Balance finden Anforderungen Zeitplan Budget Risiken Triage ermöglicht ein System nach Zeitplan zu entwickeln, während dabei Qualität nicht zu vernachlässigen 19

Budget Risiken Triage ermöglicht ein System nach

20 Triage Techniken 20

21 Triage Entscheidung Ansätze Optimistisch Pessimistisch Realistisch 21

22 Triage Entscheidung (2) Vergleich des gewünschten Zeitplanes mit Zeitplänen aus vergleichbaren Projekten in der Vergangenheit 22

23 Triage Entscheidung (3) Vergleich des verfügbaren Budgets mit Budgets aus vergleichbaren Projekten in der Vergangenheit 23

24 Graph Konstruktion Projekt 27 Personenmonate 24

25 Requirements Triage Prozess Auswahl einer Menge von Anforderungen Budget und Zeitplan Graphen konstruieren Kosten-Risiko Akzeptabel? Zeitplan-Risiko akzeptabel Fertig Risiko zu hoch? Risiko zu hoch? Anforderungen hinzufügen Anforderungen entfernen oder Budget hinzufügen Anforderungen hinzufügen Anforderungen entfernen oder Auslieferung verzögern 25

26 Zusammenfassung Anforderungen sind als Ausgangsbasis für den Erfolg des Projektes maßgeblich Die meisten Fehler resultieren aus Anforderungen Sowohl zu wenig, als auch zu viel Investition in Anforderungen kann gefährlich sein In einem Projekt zuerst verfügbare Ressourcen feststellen Ausgewogenes Balance zwischen Anforderungen, Zeit, Budget und Risiken bestimmen Dadurch wird Wahrscheinlichkeit für Fehleranfälligkeit oder Misslingen eines Projektes minimiert 26

27 Literatur und Quellen Alan M. Davis, Just Enough Requirements Management, New York (2005) Boehm, Barry. Software Engineering. IEEE Transactions on Computers, 25, 12 (December 1976), pp Sheldon, F., et al. Reliability Measurement: From Theory to Practice. IEEE Software, 9, 4 (July 1992) Hall., T., et al. Requirements Problems in Twelve Software Companies: An Empirical Analysis. IEEE Proceedings-Software, 149, 5 (October 2002), pp

28 Ende Vielen Dank für Ihre Aufmerksamkeit! 28

Ähnliche Dokumente

IT-Unternehmensarchitektur Übung 01: IT-Strategie

IT-Unternehmensarchitektur Übung 01: IT-Strategie 29. April 2010 (Donnerstag) Fachgebiet Software-Architekturen, Prof. Dr. Robert Hirschfeld Dipl.-Math. Gernot Dern, Dipl.-Inform. (univ.) Wolfgang Keller,