Software Engineering Projekt. Pflichtenheft

Transkript

1 Software Engineering Projekt Pflichtenheft

2 Ziele eines Pflichtenheftes Festsetzung der Leistung und des Umfangs der Software Anforderungen Zugesicherter Funktionsumfang Zugesicherte Produktumgebung Risikovorbeugungsmaßnahme Vereinbarung zwischen Team und Auftraggeber Festlegung des gelieferten Produktes Festlegung eines Änderungsprotokolls während des Projektes Definition zu liefernder Ergebnisse des Auftraggebers

3 Überblick eines Pflichtenheftes Beschreibung des Projekts Funktionale Anforderungen Nicht-funktionale Anforderungen Anforderungen an Benutzerschnittstelle Technische Umgebung Deliverables Rechtliches Glossar

4 Beschreibung des Projekts Ist-/Sollzustand Aktualisierung aus dem Projektmanagement Dokument Teil des Pflichtenhefts (abgeschlossenes Dokument) Anwendungsszenarien Exemplarische Beschreibung komplexer Abläufe Begriffsklärung komplexer Konzepte der Domäne (vgl. Glossar)

5 Funktionale Anforderungen - Inhalt Kernstück des Pflichtenheftes Überblick über alle geplanten Features der Software Detaillierte Beschreibung der Produktfunktionen der Benutzerrollen des Datenmodels (Domänenmodels) Grobe Priorisierung der Features Jedes Feature benötigt ein Abnahmekriterium

6 Funktionale Anforderungen - Form Klar definierte Fachbegriffe Vollständig Genau Verständlich Konsistent strukturiert Nummeriert Referenzierbar Standard Notationen/Formalismen verwenden z.b. Use-Case Diagramme; User-Stories; ER-Diagramme Eigene Notation muss beschrieben werden

7 Nicht-funktionale Anforderungen Harte Anforderungen Immer mit Kriterium zur Erfüllung Nonfunctional Product Organizational External Portability Delivery Interoperability Reliability Implementation Ethical Performance Efficiency Standards Legislative Safety Space Usability Privacy

8 Anforderungen an die Benutzerschnittstelle Art der Schnittstelle Desktop Webbrowser Konsole Funktionen des UIs mit Referenz zu Use-Case/User Story Konkrete Anforderungen Mehrbenutzer Behindertengerecht

9 Technische Umgebung 1. Produktivumgebung 2. Testumgebung 3. Entwicklungsumgebung Software/Hardware immer mit genauen Angaben Produktname und/oder Hersteller Version(en) Evtl. benötigte Erweiterungen

10 Produktivumgebung Welche Konfigurationen sollen unterstützt werden Laufzeitumgebung Betriebssystem(e) Virtuelle Maschine, Application-Server etc. Datenbankserver, oder andere angebundenen Systeme Hardware Clientumgebung Betriebssystem Browser Zu installierende Bibliotheken

11 Testumgebung Welche Konfigurationen werden getestet; z.b. Oracle Database 11g + Apache Tomcat 7.0 Oracle Database 11g + Red Hat JBoss Application Server Beschreibung der Testdaten Art Auflistung der Eigenschaften Ursprung Verantwortlicher für Erstellung

12 Entwicklungsumgebung Für die Entwicklung verwendete Produkte Sicherstellung, das alle Entwickler gleiche Basis verwenden Anleitung für neue Entwickler Benötigte PlugIns Spezielle Tools für Programmiersprachen Programmierung auf dem Host Spezielle Hardware

13 Deliverables Auflistung aller dem Auftraggeber abzugebenden Artefakte Dokumentation Source Code Analysen Installationspakete Beschreibung des Inhalts und der Abgabeform

14 Rechtliches Abtretung der Verwertungsrechte an den Auftraggeber Ende des Projektes festlegen Abnahme Kriterien und Prozess Art der Abnahme Tests des Auftraggebers Fehlertoleranz Verpflichtungen; z.b. Festlegung eines Änderungsprotokolls

15 Glossar Begriffsklärung der Problemdomäne der technischen Domäne Zielgruppenorientiert Begriffe früh einführen und konsistent verwenden

16 Zusammenfassung Pflichtenheft Wichtige Inhalte Anforderungen (ca. 1/3 des Dokuments) Keine Anforderungen ohne Abnahmekriterium Abnahmeprozess des Kunden Unterschrift des Auftraggebers Organisatorisches Abgabe: Feedback bis einholen Unklarheiten frühzeitig beseitigen Anforderungen des Auftraggebers Inhalt/Form des Pflichtenhefts

17 Software Engineering Projekt Qualitätssicherungsplan Was, wann, wie, und wo (dokumentiert)?

18 Was wollt ihr (qualitäts-)sichern? Dokumente Quellcode Zulieferungen Präsentationen

19 Wie wollt ihr (qualitäts-)sichern? Prozesse Reviews Audits Entwicklungsstile (Pair Programming?)... Tools und Verfahren CI Metriken / Testabdeckung

20 Wann wollt ihr (qualitäts-)sichern? Meilensteine? Explizite Testphasen? CI (auch gute CI braucht mindestens explorative Tests) Wann werden spezielle Testgruppen ausgeführt? Wie oft? Komponententests Integrationstests Systemtests Lasttests

21 Wo dokumentiert ihr Erfolg/ Misserfolg? Testpläne und deren Fehler müssen dokumentiert sein Abnahmetests und deren Fehler müssen dokumentiert sein (stark vom Auftraggeber abhängig)

22 Gliederungsvorschlag (!) Qualitätsziele Qualitätsziele des Auftraggebers Qualitätsziele bei der Entwicklung (Teamziele) Objekte der Qualitätssicherung Qualitätssicherungsmaßnahmen (QSMs) Verantwortlichkeiten Rollen / Organisation QSMs bei Dokumenten Reviews Freigabekontrolle, Änderungskontrolle und Auslieferung Versionsführung QS-Maßnahmen bei Quellcode und Programmen Code Reviews Codefreigaben, Änderungskontrolle und Auslieferung Testen Test und Testdokumente Vorgaben für die Testpläne Vorgaben für die Testarten (wofür?) Vorgaben für die Testabdeckung Vorgaben zur Prolemklassifikation und Problemstatus Vorgaben für die Testberichte Versionsführung bei Klassen, Modulen und Gesamtsystem Kontrolle von Zulieferungen Parallele Entwicklung von Beistellungen des Auftraggebers Audits Verwaltung der QS Aufzeichnungen

23 Zusätzliche Informationen z.b.: _ss/sqm/2004s_sqm_v_02.pdf Keine Definitionen wieder geben. Qualität ist... Klarer Bezug zu eurem Projekt muss immer sichtbar sein. 10 Seiten max. Hardlimit.

24 Weitere QS Termine 01.03: Abgabe QS Plan ~Juni/Juli: Informelles QS Meeting Erfahrungsaustausch, CI System Demo ~ SC4 QS: was war bisher, wie läuft s aktuell, wie läuft die Abnahme? : QS Dokument final + Abnahmetests (unterschrieben) ~01.10 R3: QS & Projektabschluss