Chapter 3 - Static Test-1

Requirements Engineering und Testen
Kapitel 3 –
Statischer
Test
Statischer Test
▪ Grundlagen des statischen Tests
▪ Review-Prozess
▪ Werkzeuggestützte statische Analyse

Grundlagen des statischen Tests
Begriffe
Grundlagen Dynamischer Test
Statischen Tests
Statischer Test
Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 3

Einordnung
Software-Qualitätssicherung
Konstruktiv
Analytisch
Richtlinien, Methoden, Modelle, etc.
Programm Programm
wird nicht wird
ausgeführt ausgeführt
Statischer Test Dynamischer Test
Black-Box/White-Box,
Simulation,
Prototyp, etc.
Statische Analyse Review
werkzeug-
gestützt manuell

Statischer Test vs. Dynamischer Test
Statischer Test Dynamischer Test
▪ Keine Ausführung von Code notwendig ▪ Ausführung von Code notwendig
▪ Finden von Fehlerzuständen ▪ Finden von Fehlerwirkungen
▪ Fokus kann auf Konsistenz und interne Qualität ▪ Fokus liegt vor allem auf funktionalen und nicht-
gesetzt werden funktionalen Qualitätsmerkmalen
▪ Kostengünstiger als dynamischer Test ▪ Kostenintensiver als statischer Test

Definitionen
Statische Tests dienen der Qualitätssicherung:
▪ Ziel:
▪ Frühes Finden von Fehlerzuständen in Arbeitsergebnissen der Softwareentwicklung
Positive Folgewirkungen:
▪ Prävention von Fehlern → Kostenersparnis
▪ Optimierung des Entwicklungsprozesses
Die statischen Testverfahren können bei allen Ergebnissen (z.B. Spezifikationen in Fließtext, Modelle,
Quellcode) angewendet werden, die bei der Erstellung von Software relevant sind.
Dabei wird kein Code ausgeführt! (im Gegensatz zum dynamischen Testen)

Unterscheidung
Statische Tests werden unterteilt nach der Untersuchung des Testobjekts durch:
▪ Menschen:
▪ Strukturierte Gruppenprüfungen
▪ z.B. Review → jedes beliebiges Arbeitsergebnis
▪ Maschinelle Werkzeuge:
▪ Statische Analysen
▪ z.B. Compiler → jedes Arbeitsergebnis mit einer formalen Struktur

Vorteile des statischen Tests
▪ Frühzeitig im Softwareentwicklungslebenszyklus einsetzbar
▪ Dadurch frühzeitiges Erkennen von Fehlerzuständen möglich (z.B. durch Anforderungsreview, Productrefinement etc.)
▪ Sehr kostengünstige Qualitätssicherungsmaßnahme (nur Anpassung der Reviewobjekte z.B. Anforderungen notwendig
– keine Testaufwände)
▪ Identifikation von Fehlerzuständen, die im dynamischen Test schwerer zu finden sind (z.B. Inkonsistenzen,
Mehrdeutigkeiten, Auslassungen …)
▪ Verhinderung von Fehlerzuständen in Entwurf, Implementierung und Test
▪ Erhöhung der Entwicklungsproduktivität
▪ Reduzierung von Entwicklungs- und Testkosten, sowie deren Durchlaufzeiten → Reduktion der SW-Gesamtkosten
▪ Verbesserung der Kommunikation im Team
→ Die Grundidee ist Prävention!

Typische Testobjekte
▪ Spezifikationen, z. B. Fachanforderungen, technische Anforderungen und IT-Sicherheitsanforderungen
▪ Epics, User-Stories und Abnahmekriterien
▪ Architektur und Entwurfsspezifikationen
▪ Benutzeranleitungen, Handbücher
▪ Verträge, Projektpläne, Zeitpläne und Budgetpläne
▪ Modelle wie Aktivitätsdiagramme oder Zustandsdiagramme
▪ Programmquellcode
▪ Testkonzepte, Testspezifikationen, Testskripte, Testberichte
▪ Webseiten
▪ Aufsetzen der Konfiguration und Infrastruktur

Typische Fehlerzustände
▪ Anforderungsfehler (z.B. Inkonsistenzen, Mehrdeutigkeiten, Widersprüche, Auslassungen, Ungenauigkeiten und
Redundanzen
▪ Entwurfsfehler (z.B. ineffiziente Algorithmen oder Datenbankstrukturen, hohe Koppelung, geringe Kohärenz)
▪ Programmierfehler (z.B. Variablen mit nicht definierten Werten, Variablen, die deklariert, aber nie genutzt werden,
unerreichbarer Code, doppelter Code)
▪ Abweichungen von Standards (z.B. fehlende Einhaltung von Programmierrichtlinien)
▪ Falsche Schnittstellenspezifikationen (z.B. unterschiedliche Maßeinheiten im aufrufenden und im aufgerufenen
System)
▪ Schwachstellen in der Zugriffssicherheit (z.B. Neigung zu Pufferüberlauf)
▪ Lücken oder Ungenauigkeiten in der Rückverfolgbarkeit oder dem Überdeckungsgrad der Testbasis (z.B. fehlende
Tests für ein Abnahmekriterium

Typische Fehlerzustände
▪ Anforderungsfehler (z.B. Inkonsistenzen, Mehrdeutigkeiten, Widersprüche, Auslassungen, Ungenauigkeiten und
Redundanzen
▪ Entwurfsfehler (z.B. ineffiziente Algorithmen oder Datenbankstrukturen, hohe Koppelung, geringe Kohärenz)
▪ Programmierfehler (z.B. Variablen mit nicht definierten Werten, Variablen, die deklariert, aber nie genutzt werden,
unerreichbarer Code, doppelter Code)
▪ Abweichungen von Standards (z.B. fehlende Einhaltung von Programmierrichtlinien)
▪ Falsche Schnittstellenspezifikationen (z.B. unterschiedliche Maßeinheiten im aufrufenden und im aufgerufenen
System)
▪ Schwachstellen in der Zugriffssicherheit (z.B. Neigung zu Pufferüberlauf)
▪ Lücken oder Ungenauigkeiten in der Rückverfolgbarkeit oder dem Überdeckungsgrad der Testbasis (z.B. fehlende
Tests für ein Abnahmekriterium

Kognitive Ebenen
▪ Arten von Softwarearbeitsergebnissen erkennen können, die durch die verschiedenen statischen Testverfahren
geprüft werden können
(K1)
▪ Beispiele nennen können, um den Wert des statischen Tests zu beschreiben
(K2)
▪ Den Unterschied zwischen statischen und dynamischen Verfahren unter Berücksichtigung der Ziele, der zu
identifizierenden Fehlerzustände und der Rolle dieser Verfahren innerhalb des Softwarelebenszyklus erklären können
(K2)
K1: erinnern
K2: verstehen
K3: anwenden

Statischer Test
▪ Review-Prozess

Review-Prozess
Begriffe
Statische Eingangskriterien Formales Review
Prüftechniken im Gutachter Informelles Review
Testprozess
Inspektion Metrik
Moderator Peer Review
Protokollant Technisches Review
Walkthrough

Review-Prozess
Begriffsdefinition
Review
Eine Bewertung eines Software-Produkts oder eines Projektstatus zur Aufdeckung von Diskrepanzen der
geplanten Arbeitsergebnisse und der Identifizierung von Verbesserungspotenzialen.
Review ist ein Oberbegriff für Management Review, informelles Review, technisches Review, Inspektion
und Walkthrough. [nach IEEE 1028]
Review
Eine Art statischer Test, bei dem ein Arbeitsergebnis oder -prozess von einer oder mehreren Personen
bewertet wird, um Fehlerzustände zu erkennen oder Verbesserungen zu erzielen. [ISTQB-Glossar]
Review, der, die oder das

kritische Besprechung eines [künstlerischen] Produkts o. Ä [Duden]

Review-Prozess
Was kann explizit einem Review unterzogen werden?
Anforderungs- Design-
spezifikation dokumente
Benutzer-
Quellcode
dokumentation
Zu reviewende
Dokumente
Test-
Testkonzept
spezifikation
Testplan etc.

Review-Prozess
Was kann explizit einem Review unterzogen werden?
Im Prinzip können alle Arbeitsergebnisse gereviewt werden
▪ Spezifikationen, u.a. fachliche Anforderungen, Fachanforderungen, funktionale Anforderungen, und IT-

Sicherheitsanforderungen
▪ Epics, User-Stories und Abnahmekriterien
▪ Architektur und Entwurfsspezifikationen
▪ Code
▪ Testmittel einschließlich Testkonzepten, Testfällen, Testablauf und automatisierten Testskripten
▪ Benutzeranleitungen
▪ Webseiten
▪ Verträge, Projektpläne, Zeitpläne und Budgetplanung
▪ Etc.

Review-Prozess
Was ist der Review?
▪ Der Mensch besitzt Analyse- und Denkfähigkeit (meistens)
▪ Methode:
▪ Intensives Lesen und Nachvollziehen der Dokumentation = Review
▪ Reviews werden auch in Gruppen gleichgestellter Kollegen (gleiche organisatorische Ebene) genutzt, um gegenseitige
Stellungnahmen abzugeben (Peer-Review)
▪ Reviews sind oft die einzige Möglichkeit einer Überprüfung der Semantik

Review-Prozess
Was ist das Ziel des Reviews?
▪ Das Ziel eines Reviews ist im Reviewobjekt

▪ Fehlerzustände
▪ Mängel
▪ Ungenauigkeiten
▪ Abweichungen
von/in Anforderungen zu suchen und zu erkennen sowie diese zu korrigieren (lassen)
▪ Die klare Zielsetzung des Reviews muss von „passenden“ Personen unterstützt und begleitet werden.

Review-Prozess
Der Review
▪ Aktivitäten eines formalen Reviews
▪ Reviewverfahren
▪ Rollen und Verantwortlichkeiten
▪ Reviewarten
▪ Erfolgsfaktoren von Reviews

Aktivitäten eines formalen Reviews
Sechs Phasen des formalen Reviews
Die Abwicklung eines formalen Reviews erfolgt in sechs Phasen:
1. 2. 3.
Planung Kick-Off Individuelle
Vorbereitung
4. 5. 6.
Review- Über- Nach-
sitzung arbeitung bereitung

Fünf Schritte des formalen Reviews gemäß ISO/IEC 20246
Die Abwicklung eines formalen Reviews in Anlehnung an ISO/IEC 20246 erfolgt in fünf Phasen:
3. 4.
1. 2. 5.
Individuelle Befund-
Planung Reviewbeginn kommunikation Fehlerbehebung
Vorbereitung und Analyse und Bericht

Planung (und Vorbereitung) eines formalen Reviews
▪ Definition des Reviewumfangs („review scope“)
▪ Was wird einem Review unterzogen?
▪ Zweck des Reviews?
▪ Unterstützenden Informationen (z.B. Standards) verfügbar?
▪ Qualitätsmerkmale bewerten? Welche?
▪ Eingangs- und Endekriterien (für formalere Reviewarten)
▪ Schätzung von Aufwand und Zeitbedarf
▪ Identifiziere die Reviewmerkmale und –Charakteristiken
▪ Reviewarten (Informelles Review, Walkthrough, Inspektion)
▪ Reviewrollen (Autor, Reviewleiter, ...)
▪ Reviewaktivitäten (Planung, …, Fehlerbehebung und Bericht)
▪ Auswahl und Festlegung geeigneter Reviewer
▪ Auswahl der Teilnehmer des Reviews
▪ Klärung Verfügbarkeit der Teilnehmer
▪ Klärung Reviewrollen und Fokus (mit jedem Reviewer)

Reviewbeginn/-initierung (Kick-Off) eines formalen Reviews
▪ Verteilung der Reviewdokumente (so früh wie möglich)
▪ Arbeitsergebnis, welches einem Review unterzogen werden soll
▪ Checklisten oder Listen von Prüfkriterien
▪ Dokumentvorlage für Reviewbefunde
▪ Verteilung physisch oder elektronisch
▪ KICK-OFF / Überblicksmeeting
▪ Moderator
▪ präsentiert Umfang und Schwerpunkte des Reviews
▪ erläutert Umfang, Ziele, Prozess, Rollen und Arbeitsergebnisse
▪ beantwortet Fragen der Teilnehmer
▪ Gutachter
▪ notwendiger Aufwand für Review erbringbar?
▪ geben formales Commitment ab

Individuelles Review (Individuelle Vorbereitung)
▪ Teilnehmer des Reviewteams bereiten sich individuell vor
▪ Reviewer: intensiv mit zur Verfügung gestellten Dokumenten auseinandersetzen
▪ Beschränkung auf bestimmte Aspekte ratsam
(z.B. Testbarkeit einer Anforderung)
▪ Einteilung des Prüfobjekts ratsam
(z.B. gezielte Auswahl verwendeter Checklisten)
▪ Notieren von erkannten potenziellen Fehlerzuständen, Empfehlungen, Fragen oder sonstigen Kommentaren

Individuelles Review - Reviewverfahren
▪ unterschiedliche Reviewverfahren für alle Reviewarten anwendbar
▪ Effektivität der Verfahren variiert in Abhängigkeit von genutzter Reviewart
▪ Reviewverfahren nach ISO 20246:2017:

▪ Ad-hoc-Review
▪ checklistenbasiertes Review
▪ szenariobasiertes Review
▪ perspektivisches Lesen
▪ rollenbasiertes Review

Befundkommunikation und -analyse
▪ Kommunikation identifizierter potenzieller Fehlerzustände (z.B. in einer Reviewsitzung)
▪ Analyse potenzieller Fehlerzustände, Zuweisung von Zuständigkeit (z.B. Autor, …) und Status (z.B. abgelehnt, …)
▪ Bewertung und Dokumentation von Qualitätsmerkmalen
▪ Bewertung der Reviewbefunde gegenüber den Endekriterien, um Reviewentscheidung bzgl. Reviewobjekt zu treffen
▪ annehmen, ablehnen, umfangreiche Änderungen notwendig, geringfügige Änderungen notwendig

Befundkommunikation und –analyse (Reviewsitzung)
▪ Vom Moderator geführt
▪ Kann (und sollte?) die Reviewsitzung absagen oder abbrechen wenn (mindestens ein) Reviewer nicht erschienen
oder ungenügend vorbereitet ist
▪ Der Moderator ist kein Reviewer
▪ In der Regel feste Zeitrahmen mit fester Agenda
▪ Wenn notwendig weitere Sitzung(en) ansetzen
▪ Frühestens am nächsten Tag
▪ Das Prüfobjekt steht zur Diskussion nicht der Autor!
▪ Objektive Ausdrucksweise der Reviewer
▪ Der Autor soll nicht sich oder das Prüfobjekt verteidigen
▪ Aber Erläuterungen zu Entscheidungen können hilfreich sein
▪ Keine allgemeinen Silfragen diskutieren!

▪ Entwicklung von Lösungen ist nicht Aufgabe des Reviewteams
▪ Jeder Reviewer muss Gelegenheit haben, seine Befunde zu präsentieren
▪ Befunde (z.B. Fehlerzustände) nicht in Form von Anweisungen an den Autor protokollieren
▪ Anweisungen in Form konkreter Korrekturvorschläge allerdings teilweise durchaus sinnvoll und hilfreich für
Qualitätsverbesserung
▪ Die Bewertung der einzelnen Befunde und die Gesamtbeurteilung sollte von allen Reviewern getragen werden
▪ Der Konsens der Reviewer zu einem Befund ist zu protokollieren
Gewichtung der Befundungen:
• Kritischer Fehler
Prüfobjekt nicht brauchbar → muss vor Freigabe behoben werden
• Hauptfehler
Nutzbarkeit eingeschränkt → sollte vor Freigabe behoben werden
• Nebenfehler
geringfügige Abweichung, Nutzbarkeit kaum eingeschränkt → kann
behoben werden
• Kein Fehler
fehlerfrei → keine Überarbeitung
Aktivitäten eines formalen Reviews Review
Laufzettel
und Ergeb

nisz us ammen
fass ung
Projekt
Autor:
▪ Reviewteam gibt Empfehlung über die Annahme des Prüfobjekts ab:

Dok umen
t:
Version:
▪ Akzeptieren → ohne Änderungen

Review-A
Pla nung rt
▪ Akzeptieren mit geringen Änderungen → kein weiteres Review

Verantwor
tlich für di
e Durchfü
hrung des
Review
Unterlage
▪ Nicht akzeptieren → weiteres Review oder andere Prüfmaßnahme Unterlage
n
n
geprüft:
verteilt: Ja
Datum:
(1)
erforderlich Vorbe re Ja
itung Datum: Nein
Inspek tor Nein
1
▪ Protokoll enthält Liste aller Befunde (z.B. Fehlerzustände), die in der Sitzung Inspek tor
Inspek tor
2
Dauer:
h (2)
diskutiert wurden, und zusätzlich
3
Dauer:
Inspek tor h (2)
4
Dauer:
▪ Informationen zum Prüfobjekt und den verwendeten Dokumenten Inspek tor
Inspek tor
5
Dauer:
h (2)
h (2)
▪ Beteiligte Personen und ihre Rollen
6
Re vie w -S Dauer:
itzung h (2)
Dauer:
▪ Kurze Zusammenfassung der wichtigen Punkte Moderator
Datum:
: h (2)
▪ Ergebnis der Reviewsitzung mit der Empfehlung der Reviewer Erge bnis
Teilnehm
er:
Dauer:
Summe A h
Schwere ufwand:
▪
Fehler:
Am Schluss geben alle Sitzungsteilnehmer das Protokoll frei Leic hte F
Unk larhei
ehler: Reins pekt
ion erford
h (3)
ten: erlic h: Ja
Vorsc hläg Nein
e: Nac harbei
Dok umen t erledigt bi
t-Fehler: s:
Abschluss
Arbeits er Ges amta
gebnis O ufwand:
k, Nac ha
rbeit fertig. =(2)+(3)
Datum:
Untersc hr
ift (1):

Fehlerbehebung und Bericht
▪ Beheben von im geprüften Arbeitsergebnis gefundenen Fehlerzuständen (üblicherweise durch den Autor)
▪ Kommunikation von Fehlerzuständen an zuständige Personen, wenn sie in einem Dokument gefunden wurden, das zu
dem Prüfobjekt in Beziehung steht
▪ Aufzeichnung des aktualisierten Status der Fehlerzustände (in formalen Reviews)
▪ Sammeln von Metriken (formalere Reviewarten)
▪ Prüfen, ob Endekriterien erfüllt sind (formalere Reviewarten)
▪ z.B. Fehlerzustände vollständig und korrekt behoben?
▪ Abnahme von Arbeitsergebnis, wenn Endekriterien erreicht
▪ ggf. Folgereview ansetzen, das aber oft kürzer ausfällt

Review-Prozess
Der Review
▪ Reviewverfahren
▪ Reviewarten

Reviewverfahren
Ad-hoc-Review
▪ wenige / gar keine Vorgaben für Durchführung
▪ oft genutztes Verfahren
▪ Reviewer/Gutachter
▪ Lesen Prüfobjekt von vorne nach hinten
▪ identifizieren und dokumentieren Befunde erfolgt sofort
▪ Erwartung: Reviewer erfassen möglichst viele Befunde & Fehlerzustände
▪ Vorteile:
▪ Erfordert wenig Vorbereitung
▪ Nachteile:
▪ Erfolg hängt stark von den Fähigkeiten der Reviewer ab
▪ Es kann zu vielen doppelt berichteten Befunden kommen

Reviewverfahren
Checklistenbasiertes Review
▪ systematische Vorgehensweise
▪ Reviewer/Gutachter nutzt Checklisten
▪ Reviewbeginn: Verteilung und Zuordnung der Checklisten zu Reviewern
▪ Fragen der Checkliste
▪ Fokus auf potenzielle Fehlerzustände
▪ aus Erfahrungen abgeleitet
▪ auf Art des Prüfobjekts zugeschnitten
▪ identifizierte und bekannte Risiken abdecken
▪ regelmäßig überarbeiten (neue Erfahrungen einfließen lassen)
▪ Vorteile:
▪ Systematische Abdeckung typischer Fehlerarten
▪ Nachteile:
▪ Fehlerzustände außerhalb der Checkliste können übersehen werden
▪ zeitintensiver als ein informelles Ad-hoc Review

Reviewverfahren
Szenariobasiertes Review
▪ Reviewer bekommen strukturierte Richtlinien für Review
▪ Bewertung des Prüfobjekts bzgl. der Eignung für vorgegebene Szenarien
▪ Verwendung des Prüfobjekts durch Endkunden
▪ Weitere Entwicklung auf Basis des Prüfobjekts
▪ Ableiten von Testfällen aus dem Prüfobjekt
▪ …
▪ Probeläufe ("Dry Runs") mit dem Prüfobjekt auf Basis der erwarteten Nutzung
▪ Vorteile:
▪ Systematische Abdeckung der vorgegebenen Szenarien
▪ Nachteile:
▪ Fehlerzustände außerhalb der Szenarien können übersehen werden

Reviewverfahren
Rollenbasiertes Review
▪ Reviewer/Gutachter bewerten das Prüfobjekt aus der Perspektive individueller Stakeholder-Rollen, z.B.
▪ spezifische Arten von Endanwendern (erfahren, unerfahren, Senioren, Kinder usw.)
▪ spezifische Rollen innerhalb einer Organisation (Benutzeradministrator, Systemadministrator, Performanztester
usw.)
▪ perspektivisches Lesen ist ein Spezialfall des rollenbasierten Reviews
(→ nächste Folie)
▪ Vorteile:
▪ Stakeholder-spezifische Fehlerzustände können gefunden werden
▪ Nachteile:
▪ Fehlerzustände außerhalb der Rollen können übersehen werden
▪ Manche Reviewer haben Schwierigkeiten, andere Perspektiven einzunehmen

Reviewverfahren
perspektivisches Lesen
▪ effektivstes Reviewverfahren für technische Dokumente
▪ Gutachter (syn. Reviewer) übernehmen Standpunkte unterschiedlicher Stakeholder
▪ Endanwender, Marketing, Designer, Tester, Betrieb, Regulierer
▪ Prüfobjekt so nutzen, wie es der Stakeholder tun würde
▪ Tester leitet Testfälle ab
▪ Endnutzer bedienen die entworfene Benutzungsschnittstelle
▪ Wichtig: angemessenes Einbeziehen der unterschiedlichen Standpunkte, basierend auf Risiken
▪ Vorteile:
▪ mehr Tiefe im individuellen Review
▪ weniger Doppelungen von Befunden
▪ Nachteile:
▪ Annahme anderer Perspektiven schwierig (passende Checklisten?)

Reviewverfahren
perspektivisches Lesen (perspective-based reading [PBR])
Stakeholder
identifizieren
Beschreibt die Rolle des Stakeholders,
PBR -Szenario
PBR -Szenario
welche der Reviewer für diesen Review
PBR -Szenario
View
View
point
PBRpoint Description
-Szenario
PBRpoint Description
-Szenario
einnimmt und das Interesse welches der
View
PBR Description
-Szenario
View point Description
View point Description Reviewer für dieses Arbeitsergebnis hat
PBR-Szenarien View point Description
Work Product
Work Product
Work Product
identifizieren / Work Product
Work Product Grobe Beschreibung des
Work Product
erzeugen Work Product Questions Arbeitsergebnisses,
Work Product Questions
Work Product Questions welches der Stakeholder
Work Product Questions entwickelt haben möchte
Eine Checkliste von Fragen

spezifisch für das zu
entwickelnde Arbeitsergebnis
Review durchführen
• Die Sicht des Stakeholders verstehen
• Anforderungen an das Arbeitsergebnis erzeugen
• Benutzung der Checkliste

Review-Prozess
Der Review
▪ Reviewverfahren
▪ Reviewarten

Rollen und Verantwortlichkeiten
beteiligte Rollen
Entscheidet über die Durchführung von Reviews, stellt das Budget (Zeit und Kosten) zur Verfügung und
Manager
überprüft ob die Reviewziele erreicht wurden
Verantwortet den Review und plant diesen (Auswahl der Gutachter, Zeit, Ort, Art), Bereitstellung des
Reviewleiter
Reviewobjekts
Leitet die Reviewsitzung, falls notwendig greift er zwischen Standpunkten vermittelnd ein, der Erfolg
Moderator
eines Reviews hängt häufig vom Moderator ab
Hauptverantwortlicher für die Erstellung des Reviewobjekts, verantwortet die Überarbeitung des
Autor
Reviewobjekts nach erfolgtem Review
(Prüfer,Reviewer oder Inspektoren) identifizieren im Prüfobjekt Befunde (z.B. Fehlerzustände);
Gutachter haben spezifischen technischen oder fachlichen Hintergrund, können unterschiedliche Perspektiven
vertreten, z.B. Tester, Entwickler
dokumentiert alle Ergebnisse, Probleme und offene Punkte, die im Verlauf der Sitzung identifiziert
Protokollant
werden

Review-Prozess
Der Review
▪ Reviewverfahren
▪ Reviewarten

Reviewarten
Unterscheidung und Formalisierungsgrad
Grobunterscheidung aufgrund des Prüfobjekts
▪ Reviews, die sich auf Produkte und Teilprodukte beziehen, die während des Entwicklungsprozesses erstellt werden.
▪ Reviews, die den Projektablauf oder den Entwicklungsprozess als solches analysieren. Sie werden auch
Managementreviews oder Projektreviews genannt.
niedrig Kein formaler Prozess, keine/wenige

▪ Präzisierung der Reviewarten [nach IEEE 1028] Vorgaben
▪ Informell Informell an Reviewer
▪ Informelles Review Hauptziel:
Formalisierungsgrad
Kostengünstig Nutzen erzielen
▪ Formal Walkthrough
▪ Walkthrough
▪ Technisches Review
▪ Inspektion Technisches Review Einbinden eines Review-Teams,
dokumentierte Ergebnisse und Abläufe,
formaler Prozess
Inspektion Hauptziele:
Fehlerzustände finden,
hoch Lernen, Verständnis erwerben

Reviewarten
Informelles Review
Informelles Review
ist ein Review ohne festgelegten formalen (dokumentierten) Ablauf.
Ziele [nach IEEE 1028]:

▪ Fehlerzustände aufdecken
▪ Verbesserungsvorschläge anmerken

Reviewarten
Informelles Review
Hauptmerkmale:
▪ Kein formaler Prozess
▪ Abgeschwächte Form in stark vereinfachter Art und Weise
▪ Planung beschränkt sich auf Gutachterwahl und Abgabetermin
▪ Entspricht Autor-Leser-Zyklus, Gegenlesen von (mehreren) Kollegen
▪ (Zumeist) schriftliche Gegenmeldung mit Anmerkungen
▪ Beispiele: "pair programming", "code swaps", "buddy testing"

Reviewarten
Informelles Review
PRO KONTRA
☺ Geringer Aufwand und hohe Akzeptanz  Nutzen stark von Gutachtern abhängig, diese
zeichnen informelle Reviews aus müssen sich gut mit der Materie auskennen
☺ Kann kurzfristig erfolgen  Review-Protokoll nicht zwingend notwendig

Reviewarten
Walkthrough
Walkthrough
Eine schrittweise Präsentation eines Dokuments durch den Autor, um Informationen zu sammeln und ein gemeinsames
Verständnis des Inhalts aufzubauen. [Freedman und Weinberg]

▪ Verteilung des Know-How über das Prüfobjekt auf alle Beteiligten
▪ Aufbau eines gemeinsamen Verständnisses für den Inhalt
▪ Verbesserung des Produkts
▪ Diskussion von Lösungsalternativen
▪ Prüfung der Einhaltung der Spezifikation und von Standards

Reviewarten
Walkthrough
Hauptmerkmale:
▪ Schwerpunkt bildet die Sitzung mit Open-End
▪ Leitung durch den Autor, ablauforientiert
▪ Meist handelt es sich um das Durchgehen von typischen Benutzungssituationen (ohne Vorbereitung) in einer Sitzung
vor Gutachtern. Diese stellen spontane, kritische Fragen.
▪ Geeignet für kleine Entwicklungsteams (bis zu 7 Personen)
▪ Geringer Umfang von Vor- und Nachbereitung
→ wenig Aufwand
▪ In der Praxis existiert eine breite Spannweite vom informellen bis zum formalen Walkthrough: z.B. mit Vorbereitung der
Gutachter vor dem Treffen, Reviewbericht und Protokollierung der Ergebnisse (aber nicht durch den Autor)

Reviewarten
Reviewarten
Walkthrough
Walkthrough
PRO KONTRA
☺ Sinnvoll für kleine Entwicklergruppen  Der Autor, zugleich Sitzungsleiter, kann die
(bis 7 Personen), verursacht wenig Aufwand Diskussion führen und so eine kritische
(in Vor- und Nachbereitung) Diskussion unterdrücken bzw. verhindern
☺ Know-How-Aufbau, Verständnis erzielen  Nur für geringe Dokumentenmenge geeignet
☺ Fehlerzustände finden
☺ Kurzfristige Einberufung möglich

Reviewarten
technisches Review
Technisches Review
Eine Diskussion in einer Gruppe gleichgestellter qualifizierter Mitarbeiter, die sich darauf konzentriert, eine Überein-
stimmung über technische Vorgehensweisen zu erreichen.[Gilb und Graham, nach IEEE610, IEEE 1028]

▪ Diskussion, Entscheidungen treffen, Alternativen bewerten
▪ Fehlerzustände finden, technische Probleme lösen
▪ prüfen, ob Übereinstimmung mit Spezifikationen und Standards existiert

Reviewarten
technisches Review
Hauptmerkmale:
▪ Prüfobjekt, wird im Vorfeld von Experten geprüft
▪ Wichtig: Nicht im Projekt involviert → unabhängig
▪ Prüfung nur gegen „offizielle“ Spezifikation!
▪ Anmerkungen der Expertengutachter vorab schriftlich an den geschulten Moderator übergeben, priorisiert und in der
Sitzung besprochen
▪ Kann als Peer Review ohne Teilnahme des Managements ausgeführt werden
▪ Protokollant erfasst Aussagen bei Prüfung und erstellt Dokumentation
▪ Ergebnis durch Einigung eindeutig im Gesamturteil
→ Umsetzungsentscheidung beim Management
▪ Der Formalisierungsgrad kann von hoch bis niedrig reichen
▪ Bei der Prüfung ist der Autor nicht anwesend

Reviewarten
technisches Review
PRO KONTRA
☺ Fachexperten bewerten Prüfobjekt  Hoher Vorbereitungsaufwand
☺ Effiziente Fehlerzustandsfindung  Sehr spezialisiertes Personal & Moderator
nötig
 Keine Umsetzungs-entscheidungen im
Review

Reviewarten
Inspektion
Inspektion
Eine Reviewart, die Mängel durch die Sichtprüfung von Dokumenten finden soll. Solche Mängel können sein: Nicht-
Einhaltung von Entwicklungsstandards, Nicht-Konformität gegenüber zugrundeliegenden Dokumenten.
Es ist die formalste Reviewtechnik und sie folgt deshalb einem dokumentierten Vorgehen. [nach IEEE610, IEEE 1028]
Häufig wird diese Reviewart auch als Design- oder Code-/Softwareinspektion bezeichnet.

▪ Aufdeckung von Unklarheiten, möglichen Fehlerzuständen und Defekten
▪ Bestimmung der Qualität des Prüf- und des Entwicklungsprozesses

Reviewarten
Inspektion
▪ Vor der eigentlichen Inspektion erfolgt formale Überprüfung des Testobjektes (reviewfähig, Eintrittskriterien) sowie
Erstellen der Checklisten
▪ Ein geschulter Moderator leitet die Inspektion, die mit der Vorstellung der beteiligten Rollen und Einführung in die
Thematik des Prüfobjekts beginnt
▪ Frage: Wie gut kennen sich Gutachter aus? Gemeinsames Durchgehen der Checklisten sichert ausreichende
Vorbereitung. Unstimmigkeiten werden protokolliert und diskutiert
▪ Ein Gutachter trägt kritisch, aber auch straff und logisch die Inhalte des Prüfobjekts vor
(Einfluss des Autors auf den Inhalt der Diskussion nicht möglich)
▪ Ausgewählte Aspekte werden intensiv diskutiert und Fragen an den Autor gestellt
▪ Unstimmigkeiten werden erst nur erfasst, eventuelle Diskussion zwischen Gutachter und Autor findet am Ende statt
▪ Der Moderator leitet die Diskussion und verhindert Abschweifung
▪ Eine abschließende, umfassende Bewertung beendet die Inspektion und legt fest, ob eine Überarbeitung des
Prüfobjekts notwendig ist

Reviewarten
technisches Review
PRO KONTRA
☺ Kontrolle führt zu Verbesserung des  Viel Fachkompetenz und Vorbereitungszeit
Entwicklungsprozess nötig
☺ Leistungsfähige manuelle Technik  Relativ teuer und zeitaufwändig
☺ Entscheidung über Umgang mit Mängeln
durch Reviewteam

Reviewarten
Auswahlkriterien
Projektumfeld und verfügbares Budget (Zeit, Aufwand, Kosten) beeinflussen die Auswahl des Reviews!
Fragestellungen:
▪ Erlaubt der Formalisierungsgrad des Prüfobjekts werkzeuggestützte Analysen?
▪ Ja → Zunächst Werkzeuge einsetzen
▪ Nein → Eine der Review-Arten einsetzen
▪ Wie ist der geforderte Formalisierungsgrad des Prüfungsergebnisses?
▪ Ausführliche formalisierte Dokumentation → Inspektion oder technisches Review
▪ Undokumentierte Umsetzung der Prüfergebnisse → Walkthrough oder Informelles Review
▪ Ist Fachwissen aus mehreren Gebieten erforderlich?
▪ Ja → Technisches Review
▪ Nein → Walkthrough oder Inspektion
▪ Wie viel zusätzliches Fachwissen über das Prüfobjekt benötigen die Reviewer?
▪ Viel → Zunächst Walkthrough durchführen
▪ Wenig → Direkt mit Inspektion oder technischem Review beginnen

Reviewarten
Auswahlkriterien
Weitere Fragestellungen:
▪ Terminkoordination einfach oder schwierig?
(Fünf bis sieben Fachkräfte für einen oder mehrere Termine zu verpflichten kann sehr aufwändig sein)
▪ Einfach → Inspektion oder Technisches Review
▪ Schwierig → Walkthrough oder Informelles Review
▪ Steht der Vorbereitungsaufwand in einem angemessenen Verhältnis zum erwarteten Ergebnis?
▪ Ja → Inspektion oder Technisches Review
▪ Nein → Walkthrough oder Informelles Review
▪ Wie hoch ist das Engagement der vorgesehenen Reviewer?
▪ Hoch → Inspektion oder Technisches Review
▪ Niedrig →Walkthrough
(oder: gar kein Review durchführen, weil bei wenig Engagement meist auch wenig herauskommt)

Reviewarten
Übersicht formaler Reviewsarten
Charakteristik Walkthrough Technisches Review Inspektion
Prüfziel Fehlerzustände finden; Übereinstimmung mit Fehlerzustände finden;

Alternativen abwägen; Spezifikationen und Standards; Lösungsweg bewerten;
Produkt verbessern; Forum zum Auswirkungen von Änderungen Produktqualität bewerten
Lernen prüfen
Entscheidung über Abstimmung im Team Empfehlung an das Bewertung durch das Team;
Änderungen Management oder die Fehler müssen ausgebessert
technische Leitung werden
Gruppengröße 2 bis 7 Personen 3 oder mehr Personen 3 bis 6 Personen

Reviewarten
Übersicht formaler Reviewsarten
Charakteristik Walkthrough Technisches Review Inspektion
Teamleitung Moderator oder Autor Führender Technikexperte oder Geschulter Moderator

geschulter Moderator
Materialumfang relativ gering mittel bis groß Relativ gering
Vortragender Autor Teammitglied Gutachter
Datenerhebung empfohlen Keine Anforderung → nach Bedarf sehr empfohlen
Verwendung von Nein Nein Ja

Checklisten
Management- Nein Optional Nein
teilnahme

Review-Prozess
Der Review
▪ Reviewverfahren
▪ Reviewarten

Erfolgsfaktoren von Reviews
Einteilung der Erfolgsfaktoren
Organisatorisch Personell
▪ Klare Zieldefinition ▪ Auswahl des „richtigen“ Personenkreises (Sichten und
▪ Auswahl der geeigneten Reviewtechnik Rollen berücksichtigen)
▪ Große Reviewobjekte → Zerlegen in kleinere Teile und ▪ Konstruktive Kritikfähigkeit (gefundene Fehlerzustände
ggf. bereits die Einzelteile reviewen objektiv besprechen)
▪ Zeitplanung für Reviews berücksichtigen ▪ Psychologische Aspekte (vor allem positive Erfahrung
▪ Vereinigung von Kultur, Lernen und für den Autor)
Prozessverbesserung ▪ Den Details die entsprechende Zeit widmen
▪ Auswahl eines geschulten Moderators
▪ Unterstützung des Reviewprozesses durch das
Management
▪ Implementierung von Reviews in der Testrichtlinie der
Organisation

Risiken
▪ Erfordern klar definierte Ziele und objektive Bewertung
▪ Bedingen (meistens) qualifiziertes Personal und hohe fachliche Fähigkeiten
▪ Zeit ist ein wichtiger Faktor bei Reviews. Fehlt sie, stehen nicht alle Arten von Reviews zur Verfügung
▪ In der Vorbereitung ist eine richtige Auswahl der Gutachter essentiell
▪ Können vom Autor als persönlichen Angriff gewertet werden
▪ Der Ressourcenbedarf bedingt die volle Unterstützung durch das Management, nur dies kann eine Prozessoptimierung
sicherstellen

Potentiale
▪ Sind eine einfache & wirkungsvolle Maßnahme für Qualitätssicherung
▪ Ermöglichen in frühen Phasen des SWE Zyklus Fehlerzustände zu finden und deren Korrektur
▪ Ermöglichen das Finden von Fehlerzuständen, welche beim dynamischen Testen schwer/nicht gefunden werden
einzige Möglichkeit semantische Fehlerzustände zu finden
▪ Verbessern die Entwicklungsproduktivität
▪ Helfen Kosten- und Entwicklungszeit zu sparen
▪ Sind Ideenlieferanten
▪ Erlauben unmittelbare Feedbackmöglichkeiten für den Autor und sind eine Darstellungsplattform

Auswirkungen auf Budget
Reviews kosten und sparen Geld!
▪ Kosten für Reviews: ca. 10%-15% des Entwicklungsbudgets

▪ Einsparungen zwischen 14% und 25% möglich
(nach Abzug der Mehrkosten für die Reviews)
▪ Bei effektiver Nutzung: bis zu 70% der Fehler in einem Dokument finden
▪ Reduzierung der Fehlerkosten bis zu 75%

Reviewprozess
Kognitive Ebenen
▪ Die Aktivitäten des Reviewprozesses für Arbeitsergebnisse zusammenfassen können
(K2)
▪ Die unterschiedlichen Rollen und Verantwortlichkeiten in einem formalen Review erkennen können
(K1)
▪ Unterschiede zwischen den verschiedenen Reviewarten (informelles Review, technisches Review, Walkthrough und
Inspektion) erklären können.
(K2)
▪ Ein Reviewverfahren auf ein Arbeitsergebnis anwenden können, um Fehlerzustände zu finden
(K3)
▪ Faktoren für die erfolgreiche Durchführung eines Reviews erklären können.
(K2)
K1: erinnern
K2: verstehen
K3: anwenden

Statischer Test
▪ Review-Prozess

Werkzeuggestützte statische Analyse
Was ist das?
▪ Analyse ohne Programmausführung
▪ Werkzeuge überprüfen durch Mustererkennung, sind allerdings auf das Einhalten von Formalismen angewiesen
▪ Es können verschiedene Werkzeuge miteinander kombiniert werden

▪ Statische Analyse vorbereitend zum Review
Erkannt werden fehleranfällige Programmstrukturen, Nichteinhaltung von Programmierstandards (aber keine

Laufzeitfehler) und Fehlerzustände (z.B. nicht initiierte Variablen, Architektur-Verletzungen)

Vorteile
▪ Fehlerzustände werden früh erkannt (vor der Testdurchführung)
▪ Verdächtige Aspekte im Code und/oder Design werden früh erkannt
▪ Es können Fehlerzustände gefunden werden, die durch dynamisches Testen nicht so effektiv und effizient ermittelt
werden können
▪ Abhängigkeiten und/oder Inkonsistenzen im Code werden aufgedeckt
▪ Wartbarkeit des Codes/Designs wird besser (besonders dann, wenn die gemachten Erfahrungen bei künftigen
Entwicklungen berücksichtigt werden!)

Anforderungen für statische Analyse
▪ Durchführung generell nur mit Werkzeug sinnvoll → Verfügbarkeit entsprechender Werkzeuge
▪ Das zu analysierende Objekt muss eine formale Struktur haben
▪ Informeller Text kann unterhalb der Oberflächenstruktur (Rechtschreibung und elementare Grammatik) nur mit
Methoden der KI (künstliche Intelligenz) analysiert werden
▪ Linguistische semantische Analyse ist aktueller Forschungsgegenstand
▪ Aber: Einführung einer Normsprache ermöglicht auch hier einfachere Analysen

typische Fehlerzustände
Folgende Fehlerzustände werden typischerweise mittels statischer Werkzeuge erkannt bzw. gefunden:
▪ falsche Referenzierungen von Variablen
▪ inkonsistente Schnittstellen zwischen Modulen
▪ unerreichbarer Code („dead code“)
▪ Endlosschleifen
▪ zu komplexe Programmstrukturen
▪ Verletzung von Programmier-Konventionen
▪ Sicherheitsschwachstellen
▪ Syntaxverletzungen

typische Werkezuge
Analysatoren
▪ überprüfen die Einhaltung von Programmier-Konventionen
▪ es entstehen dabei große Datenmengen („Warnungen“), die analysiert und ggf. umgesetzt werden müssen.
▪ Beispiele für Laufzeit-Probleme, die von Analysatoren erkannt werden:
▪ Division durch 0
▪ Out of Boundary Exceptions
▪ sind üblicherweise in Compilern integriert.
Automatische Prüfung motiviert Programmierer zur Einhaltung von Konventionen

Datenflussanalyse
Datenflussanalyse
▪ Im Mittelpunkt stehen die Daten, die auf den Programmpfaden verändert werden
▪ Ziel: Aufdecken von Anomalien
▪ Verwenden einer Variable ohne vorhergehende Initialisierung
▪ Einer Variable wird zwei mal hintereinander ein Wert zugewiesen, ohne dass der erste Wert verwendet wurde
▪ Einer Variablen wird ein Wert zugewiesen, dieser wird aber anschließend nicht mehr verwendet
Eine Anomalie ist keine garantiert fehlerhafte Stelle, aber eine potentielle Fehlerquelle.

Exkurs: Anomalien
void berechne (int A, int B)

{ int C;
if (A>B){
B=C; // ur: C hat unbestimmten Wert
B=A; // dd, erste Zuweisung überflüssig, prinzipiell aber kein Fehler
C=A; // du, überflüssig, C wird nur innerhalb dieser Fkt verwendet

}
}

Kontrollflussanalyse
Kontrollflussanalyse
▪ (Sequenzen von) Anweisungen werden mit Knoten dargestellt, zur Verbindung mit möglichen nachfolgenden
Anweisung(sblöcken) dienen Pfeile
▪ Kontrollflüsse veranschaulichen Programmabläufe und helfen Anomalien aufzudecken. Darstellungsmittel sind
Kontrollflussgraphen
▪ Automatisierte Erstellung gewährleistet 1:1 Abbildung von Programmtext und Graph

Übung
Erstelle den Kontrollflussgraphen und berechne die zyklomatische Komplexität
void berechne (int A, int B)
Zyklomatische Zahl M
{ int C; 1.) 𝑀 = 𝑏 + 𝑝
C = 0; b = Anzahl Binärverzweigungen (Entscheidungen)
if ( A > B){ p = Anzahl der Kontrollflussgraphen
C = A - B;
} else if (B > A) { 2.) 𝑀 = 𝑒 − 𝑛 + 2𝑝
C = B – A; e = Anzahl der Kanten im Kontrollflussgraphen
}
n = Anzahl der Knoten im Kontrollflussgraphen
if (A = B) {
p = Anzahl der Knoten ohne ausgehende Kanten im Graphen
C = 0;
}
system.out.println(„Das Ergebnis ist: %d“,C);
} Lösung

Statischer Test
Zusammenfassung

Zusammenfassung
▪ Mehrere Augenpaare sehen mehr als eines - auch in der Softwareentwicklung → Reviews dienen
der Kontrolle und Qualitätssteigerung
▪ Neben den Reviews lassen sich auch eine ganze Reihe von werkzeuggestützten Analysen
durchführen (die einen gewissen Formalisierungsgrad haben), diese werden unter dem
Oberbegriff statische Analysen zusammengefasst
▪ Reviews und statische Analysen lassen sich gut kombinieren
▪ Statische Analysen sind für die Vorbereitung von Tests ideal, um kostengünstig Fehlerzustände
und Unstimmigkeiten zu entdecken. Sie können die Dauer eines Reviews verkürzen!

Statischer Test
Wiederholungs-
fragen

Wiederholungsfragen
1. Welche Arbeitsergebnisse der Softwareentwicklung, die mit den verschiedenen statischen
Prüftechniken geprüft werden, gibt es?
2. Was für einen Nutzen bzw. eine Bedeutung haben statische Methoden für die Bewertung von
Arbeitsergebnissen?
3. Welches sind die Rollen, Aktivitäten und Verantwortlichkeiten eines formalen Reviews?

Wiederholungsfragen
4. Was sind die Unterschiede zwischen den Reviewarten :
▪ Informelles Review
▪ Technisches Review
▪ Walkthrough
▪ Inspektion?
5. Welches sind die Faktoren für eine erfolgreiche Reviewdurchführung?
6. Welche Fehlerzustände und Fehler können durch eine statische Analyse identifiziert werden?
Vergleich dieser mit jenen der dynamischen Tests und Reviews.
7. Welchen Nutzen bringt die statische Analyse?
8. Welche Fehlerzustände im Quellcode und Entwurf können durch eine werkzeuggestützte
statische Analyse gefunden werden?

Kontakt.
René
Spengler
Vergabemanagement MC Public
Telekom MMS
+49 160 4654 680
rene.spengler@telekom.de

Chapter 3 - Static Test-1

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Chapter 3 - Static Test-1

Hochgeladen von

Copyright:

Verfügbare Formate

Requirements Engineering und Testen

▪ Grundlagen des statischen Tests

▪ Werkzeuggestützte statische Analyse

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 3

Statischer Test Dynamischer Test

Statische Analyse Review

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 4

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 5

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 6

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 7

→ Die Grundidee ist Prävention!

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 8

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 9

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 10

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 11

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 12

▪ Grundlagen des statischen Tests

▪ Werkzeuggestützte statische Analyse

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 14

Review, der, die oder das

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 15

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 16

▪ Spezifikationen, u.a. fachliche Anforderungen, Fachanforderungen, funktionale Anforderungen, und IT-

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 17

▪ Der Mensch besitzt Analyse- und Denkfähigkeit (meistens)

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 18

▪ Das Ziel eines Reviews ist im Reviewobjekt

von/in Anforderungen zu suchen und zu erkennen sowie diese zu korrigieren (lassen)

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 19

▪ Aktivitäten eines formalen Reviews

▪ Rollen und Verantwortlichkeiten

▪ Erfolgsfaktoren von Reviews

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 20

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 21

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 22

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 23

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 24

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 25

▪ Reviewverfahren nach ISO 20246:2017:

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 26

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 27

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 28

Befundkommunikation und –analyse (Reviewsitzung)

▪ Reviewteam gibt Empfehlung über die Annahme des Prüfobjekts ab:

▪ Akzeptieren → ohne Änderungen

▪ Akzeptieren mit geringen Änderungen → kein weiteres Review

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 30

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 31

▪ Aktivitäten eines formalen Reviews

▪ Rollen und Verantwortlichkeiten

▪ Erfolgsfaktoren von Reviews

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 32

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 33

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 34

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 35

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 36

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 37

Eine Checkliste von Fragen

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 38

▪ Aktivitäten eines formalen Reviews

▪ Rollen und Verantwortlichkeiten

▪ Erfolgsfaktoren von Reviews

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 39

Requirements Engineering und Testen | Kapitel 3 | 25.10.2023 40