Requirements Dokumentation

Größe: px

Ab Seite anzeigen:

Download "Requirements Dokumentation"

Pia Günther
vor 8 Jahren
Abrufe

1 Software Engineering i - Requirements Dokumentation Wolfgang Henhapl, Andreas Kaminski et al.

2 Bemerkungen zu den Projektplänen Überraschendes Engagement Verständnis für das geplante Spiel Auftraggeber: Kaminski Auftragnehmer: Sie Business Case (eigene Ideen zur Perfektion)? Requirements und Validierung im Haus Programmierung an externe Entwicklungsfirma: Henhapl Benutzer: Hartle & Co

Business Case (eigene Ideen zur Perfektion)?

3 Bemerkungen zu den Projektplänen Hauptprobleme aus meiner Sicht Virtuelles reales Projekt Interesse an Software-Praktikum 4SWS WS08/09? Aufgabe: Realisierung und Einsatz? Dienstleistungsentwicklung Produktentwicklung Passendes Prozessmodell Wasserfall? V- Modell? Agile Prozesse? UP?

4 Bemerkungen zu den Projektplänen Hauptprobleme aus meiner Sicht Zeitschätzung Prophetie Bauchgefühl Kenntnis des Preises Kenntnis der Ressourcen Basis Ihrer Schätzung? Expertenschätzung Delphimethode Analogieschätzung Validierung der Schätzungen Schätzverfahren Constructive ti COst- Model Function Point Use Case Points Erfordert die Kenntnis der UC s!!! Erfordert Kennzahlen des Teams Schätzung bei XP?

Expertenschätzung Delphimethode Analogieschätzung Validierung der Schätzungen Schätzverfahren

5 Übung: Dokumentation Dokumentation ti ist abhängig Problem Mathematische Probleme Technische Probleme Web-Auftritte Prozess XP V-Modell Übung: Entscheidung welche Dokumentation Protokollierung und Ausarbeiten der geeigneten Dokumentationsstruktur

Prozess XP V-Modell Übung: Entscheidung welche Dokumentation

6 Kommunikation Beteiligte Jeder mit jedem? Auftraggeber Sie Externe Realisierung Benutzer

7 Kommunikation Beteiligte Ihr Vorschlag Auftraggeber Sie Externe Realisierung Benutzer

8 Was wird kommuniziert? Auftraggeber SEP-Muster: Kurzbeschreibung Geplantes System Systembeschreibung Systemumgebung Prozessinformation Rechte Kosten Glossar Sie

9 Management SEP-Muster: Kurzbeschreibung Auftraggeber Sie Geplantes System Systembeschreibung Systemumgebung Prozessinformation Rechte Kosten Glossar

10 Benutzer SEP-Muster: Kurzbeschreibung Auftraggeber Geplantes System Systembeschreibung Benutzer Sie Systemumgebung Prozessinformation Rechte Kosten Glossar

11 Auftraggeber SEP-Muster: Kurzbeschreibung Auftraggeber Geplantes System Systembeschreibung Systemumgebung Prozessinformation Sie Rechte Kosten Glossar

12 Sie als Gruppe SEP-Muster: Kurzbeschreibung Geplantes System Systembeschreibung Sie Systemumgebung Prozessinformation Rechte Kosten Glossar

13 Externer Partner SEP-Muster: Kurzbeschreibung Geplantes System Systembeschreibung Systemumgebung Sie Externe Realisierung i Prozessinformation Rechte Kosten Glossar

14 SEP-Muster Visioni Zu erreichende Geschäftsziele Interessengruppen (stakeholders) Vorteile und Veränderungen durch die Einführung für die Interessensgruppen Grobe Skizze des geplanten Systems Soll-Ist ItVergleich lih Aktuelle Probleme Lösungsvorschläge Neue Funktionen (Feature List): Name und Kurzbeschreibung Gegenüberstellung alter und neuer Funktionen Liste der Einschränkungen bzw. nichtfunktionalen Anforderungen Erforderliche Veränderungen bei Einführung des Systems Abgrenzung zu bestehenden Geschäftsprozessen Nichtfunktionale Anforderungen

(Feature List): Name und Kurzbeschreibung Gegenüberstellung alter und neuer Funktionen Liste der Einschränkungen bzw.

15 SEP-Muster Feature-List: t Priorisierte Warteschlange von nicht bearbeiteten Anforderungen (Use Case Facade) Abarbeitung von Iteration zu Iteration Beschreibung: Name Kurzbeschreibung Status Grob geschätzte Kosten Priorität Bedeutung (Risk) der Anforderung (für den Anwender)

Iteration zu Iteration Beschreibung: Name Kurzbeschreibung Status

16 SEP-Muster Use Case Model System, Systemgrenze und Aktoren (außerhalb des Systems) Beschreibung der Aktoren Rollenname Fähigkeiten & Rechte evt. Attribute Aufzählung der Use Cases, die sich aus der Feature-List t ergeben Beziehung zwischen Aktor und Use Cases Visualisierung durch Systemdiagramm. Graphisches Inhaltsverzeichnis In Tools: Links zu den einzelnen Beschreibungen Darstellung des Zusammenhangs Möglichkeit verschiedene Sichten (Inhaltsverzeichnisse) anbieten

Attribute Aufzählung der Use Cases, die sich aus der Feature-List t ergeben Beziehung zwischen Aktor und Use Cases

17 SEP-Muster Use Case Name Aktoren Status Kurzbeschreibung Ablauf Wichtigstes Scenarium (Schönwetter-Fall) Alternative Scenarien Include/Extension points Event Trigger Non Functional Requirements specific for the Use Case Preconditions & Postconditions UI-Prototyp

Include/Extension points Event Trigger Non Functional

18 SEP-Muster Prozessinformation Projektplanung Projektorganisation Projektablauf mindestens die Meilensteine Qualitätssicherungsplan QS-Merkmale Priorität Püf Prüfmethode Erfüllungskriterien QS-Organisation

Meilensteine Qualitätssicherungsplan QS-Merkmale

19 Andere Muster V-Modell XT Unified Process

20 Use Case Points Verfahren ( com/gen/design/usecasep asp ) Drei Faktoren: Anwendungsfaktor Technikfaktor Organisationsfaktor Anwendungsfaktor: Komplexitätsstufen der Use Cases + Gewichtete Aktoren Use Cases Einfach: 5 Einfaches Interface Ein Entity Objekt Erfolgsszenario <=3 Schritte Mittel: 10 Interface Design Mehrer Entity Objekte <= 7 Schritte Komplex: 15 Aktoren Klare API 1 Protokoll 2 Person 3

Anwendungsfaktor: Komplexitätsstufen der Use Cases + Gewichtete Aktoren Use Cases Einfach: 5 Einfaches Interface

21 Use Case Points Technik-Faktor: kt ( Einflussgröße * Gewicht)/100. Einflussgröße mit Wertebereich 0-5 mit 0 kein, 3 als Standardwert, 5 max. Wert Gewicht der Einflussgrößen: Verteiltes System 2 Performanz 1 Software Ergonomie 1 Komplexität des Verfahrens 1 Wiederverwendbarkeit des Codes 1 Installationsfreundlichkeit 0,5 Benutzerfreundlichkeit 0,5 Portabilität 2 Änderungsfreundlichkeit 1 Parallele Transaktionen 1 Sicherheitsanforderungen 1 Systemnutzung durch Dritte 1 Einschulungsaufwand 1

22 Use Case Points Organisationsfaktor: *( Einflussgröße*Gewicht). 03*( Ei *G i Wertebereich der Einflussgrößen wieder 0-5 Einflussgröße und Gewicht 1. Methodische h Kompetenz (UML/UP) 05 0,5 2. Kenntnis des Anwendungsbereichs 0,5 3. OO-Kompetenz 1 4. Kompetenz des Architekten 05 0,5 5. Motivation 1 6. Stabile Requirements 2 7. Teilzeit Komplexität der Sprache/ Entwicklungsumgebung -1

23 Use Case Points Ergebnis: Use Case Points: Anwendungsfaktor * Technikfaktor * Organisationsfaktor Hypothese: Projektaufwand ist proportional p zu Use Case Points Proportionalitätsfaktor nennt man: Produktivitätsfaktor Erfahrung: Prozessabhängig Volle Möglichkeiten des XP-Teams: Notwendige Strukturierung nach UP oder V: Abhängig vom Umfang bzw. Dauer Faktor sinkt bei späteren Zahl der Iterationen der UCPs Faktor steigt mit Anzahl der Use Cases ~20 Ph/UCP ~30 Ph/UCP Andere Use Case Points sdm Dissertation Schmitt

Ähnliche Dokumente

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management