Erstellung eines Pflichtenhefts (I)

Transkript

1 2. Anforderungsanalyse Erstellung eines Pflichtenhefts (I) Annahme: Es liegt ein "gutes" Lastenheft vor Was fehlt noch? Details... gemeinsame Sprache Glossar gemeinsames Verständnis der Funktion Funkt. Anf. gemeinsames Verständnis der Randbedingungen n.-funkt. Anf. gemeinsame Vorstellung über das Zielsystem GUI Wie kommt man dahin? Extrahieren Spezifizieren Validieren und Verifizieren Verhandeln nach K. Pohl "Process- Centered Requiremens Engineering", 1996 Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 47

2 2. Anforderungsanalyse Erstellung eines Pflichtenhefts (II) Extrahieren Validieren und Verifizieren Extrahieren (Extraction / Elicitation) Verborgene Anforderungen zu Tage bringen Diskussionen, Anwenderbefragungen, Literaturstudium Spezifizieren (Specification) Thema verständlich und kommunizierbar machen Dokumentieren, kommunizieren Validieren Erwartungen der Benutzer / Auftraggeber werden erfüllt Diskussionen von Auftragnehmer & Auftraggeber Verifizieren Konsistenz der Einzelspezifikationen prüfen Technische Überprüfung z.b. durch Test-Team Verhandeln (Negotiation) Spezifizieren Einigung auf Reihenfolge, Priorität, Umfang etc. einer Realisierung Diskussionen mit allen Stakeholdern Verhandeln Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 48

3 2. Anforderungsanalyse Bestandteile eines Pflichtenhefts Funktionale Anforderungen konkrete Anwendungsfälle und Abläufe (evtl. Use Cases, Sequ. diagramme) Benutzer, Akteure Nicht-funktionale Anforderungen Systematische Betrachtung der Qualitätseigenschaften Priorisierung der Qualitätseigenschaften Benutzungsschnittstelle (GUI / HMI) Skizzen und Snapshots Navigationskonzepte, Dialogführung Glossar Zentrale Sammlung der Definitionen aller wichtigen Dinge der Problemwelt den Auftraggeber nicht mit neuen Begriffen "beglücken"! Universalausdrücke vermeiden / genau spezifizieren: (System, Komponente, ) Sonstiges (je nach Bedarf im Projekt) Alle Beschreibungen beziehen sich auf den Problemraum! Lösungen im Detail sind hier noch nicht von Interesse! Die konkrete Art der Dokumentation wird mit dem Geschäftspartner festgelegt! z.b. Modellierung der Daten des interessierenden Realweltausschnitts Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 49

4 2. Anforderungsanalyse Tätigkeiten bei der Anforderungsanalyse und Dokumentationsformen Definition der Funktionalität siehe SWT I: Use Cases, Aktivitätsdiagramme Definition der nichtfunktionalen Anforderungen siehe SWT I: Qualitätseigenschaften als Text dokumentieren Erstellung von HMI-Skizzen und Navigation Vorlesung graphische Benutzeroberflächen Glossar Normale alphabetische Definitionsliste (evtl. mit Index) Sonstiges z.b. Modellierung der Anwendungsdomäne: siehe SWT I: Analyseklassenmodell Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 50

5 2. Anforderungsanalyse Analyseklassenmodell Bei der Beschreibung der Anwendungsfälle stößt man auf materielle und immaterielle Dinge (Objekte!) mit zu verwaltenden Informationen Modelliere diese Objekte der Domäne als Klassen mit Eigenschaften und Beziehungen "Analyseklassenmodell" Identifizieren von Objekten, Klassen, Attributen, Assoziationen, Aggregationen nur Klassen und Attribute, d. h. keine Operationen keine Navigationsrichtungen evtl. Gemeinsamkeiten als Generalisierungsbeziehungen evtl. weitere Eigenschaften der Klassen, die nicht in Diagrammform ausdrückbar sind, in Textform Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 51

6 2. Anforderungsanalyse Analyseklassenmodell (II) Ergebnis Klassendiagramm - mit rudimentären Klassen, - die zu Objekten gehören, die ein Anwender wahrnimmt Erstellungsregeln - jede Klasse muss in mindestens einem Anwendungsfall vorkommen - jede Domainklasse sollte mindestens ein Attribut haben - Klassen enthalten keine Realisierungsdetails einer potentiellen Lösung Das Analyseklassenmodell stellt einen ganz groben ersten Wurf für das Systemdesign dar Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 52

7 2. Anforderungsanalyse Anforderungsanalyse - Was ist eigentlich daran so schwer? Nette Gesprächsrunden (viel Kaffee, viele Kekse) gemeinsames Verständnis finden Aufschreiben der Ergebnisse und fertig??? Nicht ganz, denn in der Regel können nicht alle Anforderungen umgesetzt werden - Priorisierung, Planung und Verhandlung erforderlich - Ablehnung von Anforderungen nötig die Anforderungen ändern sich mit der Zeit - Umgang mit neuen / geänderten Anforderungen - Konsistenz der Anforderungen erhalten - Verwaltung der Anforderungen Change Request Management Requirements Engineering Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 53

8 2. Anforderungsanalyse Kontrollfragen zur Anforderungsanalyse Welches Ziel verfolgt die Anforderungsanalyse? Was wird in der Anforderungsanalyse gemacht? Warum ist die Anforderungsanalyse so schwierig? Welche Arten von Anforderungen gibt es? Welche Dokumente gehören zu einer Anforderungs-Spezifikation? Welche Methode eignet sich zur Dokumentation von funktionalen Anforderungen? Was geschieht, wenn man ein Projekt ohne aufwändige Anforderungsanalyse angeht? Welchen Sinn hat ein Analyseklassenmodell? Könnten Sie jetzt ein System so spezifizieren, dass es beauftragt oder entwickelt werden könnte? Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 54

9 Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 3. Abnahmetest

10 V-Modell Anwendungsszenarien Testfälle Abnahmetest Systemtest Testfälle Integrationstest Testfälle Grobentwurf Anforderungsdefinition Feinentwurf Modul-Implementierung Modultest Quelle: H. Balzert, Lehrbuch der Softwaretechnik, Band 2 Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 56

11 Lernziel Abnahmetest Sie sollen in diesem Kapitel verstehen, Was ein Abnahmetest ist Warum ein Abnahmetest wichtig ist Wie man Testfälle für die Abnahme findet Anschließend können Sie ausgehend von einer Spezifikation die Abnahmetests spezifizieren. Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 57

12 Was ist ein Abnahmetest und wie führe ich ihn durch Was ist ein Abnahmetest? Prüfung, ob erstelltes System = spezifiziertes System die Abnahmetests sind Bestandteil des Vertrags Nach erfolgreicher Abnahme wird bezahlt Wie führe ich einen Abnahmetest durch? Zusammen mit dem Auftragsgeber Mit formeller Protokollierung Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 58

13 Was muss getestet werden? gemäß FURPS-Modell: Functonality (Funktionalität) Usability (Benutzbarkeit) Reliability (Zuverlässigkeit) Performance (Leistung) Supportability (Wartbarkeit)... Funktionstests Überprüfung auf korrekte Funktion des Systems (siehe nächste Folien) Benutzbarkeitstests Überprüfung der Bedienoberfläche durch Endanwender Zuverlässigkeitstests Überprüfung des Systems auf Absturzsicherheit Leistungstests Überprüfung der Schnelligkeit, d. h. Erfüllung der Zeitvorgaben Funktionstests auch bei maximaler Last, maximaler Durchsatz, hohem Datenaufkommen etc. (Stresstests, Lasttests) Wartbarkeitstest Überprüfung von Code und Dokumentation auf Verständlichkeit Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 59

14 Funktionstest Woher kennen wir die gewünschte Funktionalität? In der Anforderungsanalyse wurden die Funktionalität durch Eingaben und die darauf erwartete Reaktion des Systems beschrieben Annahme: Wir haben Anwendungsfälle beschrieben In Anwendungsfällen sind Eingaben ins System und Ausgaben vom System dokumentiert Beim Abnahmetest werden die einzelnen Anwendungsfälle ein- oder mehrmals durchgespielt Um nachzuprüfen, ob die - vom Anwendungsfall beschriebene - Funktionalität wie erwartet abläuft Wie extrahiert man die Testfälle und die dazugehörenden Daten aus Anwendungsfällen? Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 60

15 Ableiten von Funktionstests (I): Use Case Trigger Login-System fragt Kunden nach PIN Basic Course Step # 1 2 Action Kunde gibt PIN ein System validiert PIN Gefährlich! Wirklich immer? 3 System gibt Zugang frei Alternate Course Step # * Condition Kunde bricht ab Action 1a Keine Eingabe für 30 Sek 2a PIN stimmt nicht und Versuche <3 Goto 1 2b PIN stimmt nicht und Versuche >=3 System für 60 Sek. sperren, Goto1 Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 61

16 Ableiten von Funktionstests (II): Essentielle Aktivitäten Zur Anschauung: Darstellung als Aktivitätendiagramm PIN Eingabe PIN Validierung System gibt Zugang frei Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 62

17 Ableiten von Funktionstests (III): Aktivitäten mit Alternativen PIN falsch und <3 Fehlversuche keine Eingabe für 30 Sek Eingabe erfolgt PIN validiert PIN falsch und >=3 Fehlversuche 60 Sek gewartet Nicht immer! bel. Taste, Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 63

18 Funktionstests ableiten Jeder Weg im Use-Case ist zu durchlaufen (Normalfall und alle Ausnahmen) anschaulich zu sehen im Aktivitätendiagramm aber auch ohne Aktivitätendiagramm machbar Anzahl der Wege wird schnell zu groß ( Auswahl wichtiger Tests) PIN Eingabe keine Eingabe für 30 Sek. richtige PIN eingegeben richtige PIN eingegeben falsche PIN eingegeben PIN Validierung 60 Sek gesperrt Soll-Ergebnis Zugang frei 1x falsche PIN eingegeben erneute PIN Eingabe 2x falsche PIN eingegeben erneute PIN Eingabe 3x falsche PIN eingegeben System 60 Sek gesperrt 4x falsche PIN eingegeben System 60 Sek gesperrt 3x falsche PIN eingegeben, bel. Eingabe System 60 Sek gesperrt 3x falsche PIN eingegeben Nach 60 Sekunden erneute PIN Eingabe Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 64

19 Weitere Tests (URPS) Benutzbarkeitstests Überprüfung der Bedienoberfläche durch Endanwender - Intuitive Bedienung, Lesbarkeit, Reaktivität,... Zuverlässigkeitstests Zuverlässigkeit: Max. Anzahl der Abstürze/Fehlfunktionen in Zeitintervall T Beim Funktionstest bekommt man auch Hinweise auf die Zuverlässigkeit Eigentlicher Zuverlässigkeitstest erst im Einsatz Leistungstests Überprüfung der Nichtfunktionalen Anforderungen - Robustheit: Belastungs- oder Stresstest - Performance: Zeitvorgaben -... Wartbarkeitstest Sichtung der Dokumentation, des Codes z. B. durch Anwendung von Metriken (später in der Vorlesung) Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 65

20 Kontrollfragen zum Abnahmetest Welches Ziel haben Abnahmetests? Wann werden Abnahmetests festgelegt? Wie finden Sie Tests für funktionale Anforderungen? Was tun Sie, wenn es zu viele Testpfade gibt? Wie testen Sie nicht-funktionale Anforderungen? Welche Bedeutung hat der Abnahmetest im vertraglichen Sinn? Wie hängt der Abnahmetest mit den Anforderungen zusammen? Können Sie jetzt ausgehend von einer Spezifikation Abnahmetests spezifizieren? Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 66