Wie ist der prinzipielle Ablauf von Prüfungen aufgebaut? (S.13)
Vorgaben werden umgesetzt, anschließend wird nachvollzogen, ob das Ist dem Soll entspricht, danach erfolgt der Vergleich und das Prüfergebnis.
Was sind die vier möglichen Prüfergebnisse? (S.14)
Richtig positiv/ Falsch positiv/ Richtig negativ/ Falsch negativ.
Was bedeutet "richtig positiv" bei einer Prüfung? (S.14)
Ein tatsächlich vorhandener Fehler wurde gefunden.
Was bedeutet "falsch positiv" bei einer Prüfung? (S.14)
Es wurde ein vermeintlicher Fehler gefunden, der in Wirklichkeit nicht existiert.
Was bedeutet "richtig negativ" bei einer Prüfung? (S.14)
Es wurde kein Fehler gefunden, und es lag auch tatsächlich keiner vor.
Was bedeutet "falsch negativ" bei einer Prüfung? (S.14)
Es wurde kein Fehler gefunden, obwohl tatsächlich ein Fehler vorlag.
Welche Hinweise gelten für jede Prüfung? (S.15)
Alles Geforderte muss geprüft werden
Sowohl Ist-Ergebnis als auch Soll-Vorgabe beachten
Fehler nur erkennbar, wenn Soll vom Ist abweicht
Falsch negativ bedeutet, dass nicht gesucht wurde oder das Soll falsch war.
Was sind die wichtigsten Prinzipien der Software-Prüfung? (S.16)
Nur gegen Vorgaben prüfen
Prüfungen planen
Prüfverfahren definieren
Alle Ergebnisse dokumentieren
Ausgangsbasis dokumentieren
Fehler beheben.
Warum muss die Prüfung von der Korrektur getrennt werden? (S.17)
Veränderungen während der Prüfung verfälschen das Ergebnis, Grundmängel werden sonst übersehen, Änderungen können neue Fehler verursachen, sofort behobene Fehler werden oft nicht dokumentiert.
Warum sollten Prüfer und Entwickler unterschiedliche Personen sein? (S.17)
Um objektive Ergebnisse zu gewährleisten und Rollenkonflikte zu vermeiden.
Welchen Sinn und Zweck haben Prüfungen? (S.18)
Definition von Qualitätskriterien
Aufzeigen von Schwächen
Keine direkte Qualitätsverbesserung
Einfluss auf Autor durch Erwartung der Prüfung
Offenlegung besonders guter oder schlechter Prüflinge.
Was versteht man unter Inspektionen? (S.20)
Menschliche Prüfung lesbarer Softwareteile anhand von Referenzunterlagen wie Prüfling und Vorgaben.
Welche Arten der Inspektion gibt es? (S.20)
Durchsicht
Stellungnahme
Structured Walkthrough
Technisches Review
Design & Code Inspections.
Was ist eine Durchsicht? (S.21)
Selbstständige Prüfung der eigenen Arbeit, meist vom Entwickler selbst, idealerweise nicht direkt am Monitor, um Abstand zu gewinnen.
Warum sollte immer eine Durchsicht erfolgen? (S.21)
Offensichtlich fehlerhafte Arbeitsergebnisse sollten nicht an andere weitergegeben werden.
Wie läuft eine Stellungnahme ab? (S.22)
Entwickler sendet Arbeit an andere Entwickler/ Diese geben Stellungnahmen ab/ Autor kann sie einarbeiten.
Was sind Vorteile einer Stellungnahme? (S.22)
Intuitiv/ Geringer Organisationsaufwand.
Was sind Nachteile einer Stellungnahme? (S.23)
Aufwand ist ungeplant
Autor ist Moderator und filtert Stellungnahmen
Änderungen während Einarbeitung lassen Stellungnahmen ins Leere laufen
Kein Protokoll
Bearbeitung hängt vom Autor ab.
Was ist ein Structured Walkthrough? (S.24)
Autor präsentiert Prüfling Schritt für Schritt, Gutachter stellen kritische Fragen, Autor entdeckt oft selbst Fehler.
Was sind Nachteile eines Structured Walkthrough? (S.25)
Keine klaren Kompetenzen/ Fehlerbehebung unkontrolliert/ Vorbereitungszeit wird oft nicht eingeplant/ Autor bestimmt Verlauf und agiert wie Verkäufer.
Was ist ein technisches Review? (S.27)
Standardprüfung für Software, effektiv und effizient, mit klaren Phasen: Initiierung, Vorbereitung, Sitzung, Nacharbeit, Freigabe.
Welche Rollen gibt es im technischen Review? (S.28)
Autor/ Moderator/ Gutachter/ Notar/ Manager (nimmt nicht teil, entscheidet aber über Freigabe).
Warum erhalten Gutachter konkrete Prüfaufträge? (S.29)
Um gezielt nach bestimmten Mängeln zu suchen und häufige Fehler wahrscheinlicher zu entdecken.
Was sind wichtige Spielregeln im Review? (S.31)
Moderator organisiert
Sitzung max. 2 Stunden
Unvorbereitete Gutachter → Abbruch
Prüfling wird geprüft, nicht Autor
Keine Verbesserungsvorschläge, nur Befunde
Rollen nicht vermischen.
Jeder Gutachter erhält die Möglichkeit, seine Befunde
angemessen zu präsentieren.
Der Konsens der Gutachter zu einem Befund wird im Review-
Protokoll dokumentiert.
Die Befunde werden gewichtet
Das Review-Team gibt am Ende eine Empfehlung ab.
Am Schluss unterschreiben alle Teilnehmer das Protokoll.
Stilfragen außerhalb der Richtlinien werden nicht diskutiert.
Auch Autoren können an Reviews teilnehmen.
Autoren dürfen sich nicht ungefragt zu Wort melden – Sie dürfen
nur etwas sagen, wenn sie gefragt werden.
Verteidigt ein Autor seinen Prüfling, muss der Moderator
eingreifen!
Wie werden Befunde im Review gewichtet? (S.34)
Gut
Nebenfehler
Hauptfehler
Kritischer Fehler
Unbewertet.
Welche Empfehlungen können Gutachter am Ende eines Reviews abgeben? (S.35)
Akzeptiert ohne Änderungen/ Akzeptiert mit Änderungen/ Nicht akzeptiert.
Welche Werkzeuge zur Review-Unterstützung gibt es laut Folien? (S.38)
RevAger/ RevAger Lite.
Was ist RevAger? (S.39)
Open-Source-Review-Tool, Sieger eines Uni-Wettbewerbs 2009, läuft nicht mit Java 11+, benötigt ältere JVM 8.
Was ist RevAger Lite? (S.41)
Moderne PWA, läuft im Browser, weniger Features, Quellcode auf GitLab, produktiv erprobt, jedoch werden teils RevAger empfohlen.
Welche Rollen müssen in der Review-Übung verteilt werden? (S.46)
Moderator/ Notar/ Gutachter (3–7 Personen).
Was sind die Aufgaben des Notars in der Review-Übung? (S.47)
Werkzeug einrichten/ Beamer anschließen können/ Review-Datei öffnen können.
Was sind die Aufgaben der Gutachter in der Review-Übung? (S.47)
Nach Prüfauftrag vorbereiten und vorbereitet erscheinen.
Wie läuft ein Review im Detail ab? (S.52)
Begrüßung/ Anwesenheit und Vorbereitungszeiten abfragen/ Eindruck der Gutachter einholen/ Abschnitt für Abschnitt prüfen/ Bewertung festlegen/ Protokoll exportieren.
Welche Tipps gibt es für die Rollen im Review? (S.53)
Rolle einhalten/ Moderator holt Konsens ein/ Notar stoppt bei zu hohem Tempo/ Gutachter argumentieren stichhaltig/ Autor bleibt passiv.
Was sind Tipps zur Protokollierung? (S.54)
Befunde notargerecht vortragen/ Keine Verbesserungsvorschläge oder Prüfaspekte protokollieren/ Befunde so formulieren, dass der Autor sie versteht.
Wie läuft der Ablauf einer Prüfung praktisch ab? (S.13)
Prüfer erhält Vorgaben, prüft Umsetzung, vergleicht Ist mit Soll und dokumentiert das Ergebnis.
Wie kann man Prüfergebnisse in der Praxis klassifizieren? (S.14)
Durch Vergleich von gefundenen Fehlern mit der tatsächlichen Fehlerlage – dabei entstehen richtig/falsch positiv und richtig/falsch negativ.
Wie erkennt man ein richtig positives Ergebnis? (S.14)
Der festgestellte Fehler kann objektiv nachgewiesen werden und entspricht einer Soll-Ist-Abweichung.
Wie erkennt man ein falsch positives Ergebnis? (S.14)
Die Prüfung meldet einen Fehler, der sich bei Überprüfung als nicht existent herausstellt.
Wie erkennt man ein richtig negatives Ergebnis? (S.14)
Das Ergebnis ist fehlerfrei und stimmt mit der Soll-Vorgabe überein.
Wie erkennt man ein falsch negatives Ergebnis? (S.14)
Durch spätere Feststellung eines Fehlers, der während der Prüfung übersehen wurde.
Wie stellt man sicher, dass eine Prüfung vollständig ist? (S.15)
Indem man alle geforderten Punkte systematisch prüft, Ist- und Sollwerte vergleicht und keine Vorgaben auslässt.
Wie setzt man die Prinzipien der Software-Prüfung um? (S.16)
Indem man klare Vorgaben nutzt, Prüfplan erstellt, Ergebnisse protokolliert und die geprüfte Basis eindeutig festhält.
Wie trennt man Prüfung und Korrektur in der Praxis? (S.17)
Erst vollständige Prüfung abschließen, Ergebnisse dokumentieren, danach Korrektur in separater Phase durchführen.
Wie sorgt man für eine klare Rollentrennung zwischen Prüfer und Entwickler? (S.17)
Durch feste Zuordnung der Aufgaben und Vermeidung von Personalüberschneidungen im Prüfprozess.
Wie wirken sich Prüfungen auf die Qualität aus? (S.18)
Sie decken Schwächen auf, definieren Qualitätsmaßstäbe und beeinflussen indirekt das Verhalten der Entwickler.
Wie werden Inspektionen durchgeführt? (S.20)
Prüfer vergleichen Dokumente oder Code mit Vorgaben, um Abweichungen zu identifizieren.
Wie unterscheiden sich die Inspektionsarten? (S.20)
Sie variieren in Organisation, Beteiligung, Dokumentation und Verantwortlichkeiten.
Wie führt man eine Durchsicht effektiv durch? (S.21)
Arbeit ausdrucken oder in anderem Medium prüfen, Abstand zum Erstellungszeitpunkt einhalten, Fehler systematisch suchen.
Wie verhindert die Durchsicht die Weitergabe von Fehlern? (S.21)
Indem sie grobe Fehler vor der Weitergabe erkennt und korrigiert.
Wie organisiert man eine Stellungnahme effizient? (S.22)
Durch gezielte Auswahl der Reviewer, klare Fristen und strukturiertes Feedback.
Wie kann man die Vorteile einer Stellungnahme optimal nutzen? (S.22)
Indem man sie für schnelle, unkomplizierte Feedbackschleifen einsetzt.
Wie minimiert man die Nachteile einer Stellungnahme? (S.23)
Durch klare Rollenverteilung, Protokollierung und geplante Feedback-Zeiten.
Wie läuft ein Structured Walkthrough ab? (S.24)
Autor führt durch das Material, Gutachter fragen kritisch nach, alle notieren mögliche Fehler.
Wie kann man die Nachteile eines Structured Walkthrough reduzieren? (S.25)
Durch klare Rollen, feste Zeitplanung und Moderation durch neutrale Person.
Wie läuft ein technisches Review ab? (S.27)
In den Phasen Initiierung, Vorbereitung, Sitzung, Nacharbeit, abschließend Freigabeentscheidung durch Manager.
Wie arbeiten die Rollen im technischen Review zusammen? (S.28)
Moderator organisiert, Gutachter prüfen, Notar protokolliert, Autor liefert Prüfling, Manager entscheidet.
Wie formuliert man einen Prüfauftrag für Gutachter? (S.29)
Konkret, prüfbar und auf häufige Fehlerquellen ausgerichtet.
Wie sorgt man für die Einhaltung der Review-Spielregeln? (S.31)
Durch klare Ansage vor Beginn, strikte Moderation und Abbruch bei Regelverstößen.
Wie erfolgt die Gewichtung eines Befunds im Review? (S.34)
Gutachter stufen jeden Befund nach Auswirkung auf Nutzbarkeit ein.
Wie beeinflussen die Empfehlungen die Freigabeentscheidung? (S.35)
Sie dienen dem Manager als Grundlage zur Freigabe oder Ablehnung des Prüflings.
Wie unterstützen Werkzeuge den Review-Prozess? (S.38)
Sie helfen bei Organisation, Protokollierung und Verwaltung der Review-Sitzung.
Wie setzt man RevAger ein? (S.39)
Installation unter JVM 8, Erstellen und Verwalten von Review-Sitzungen, Dokumentation der Befunde.
Wie nutzt man RevAger Lite? (S.41)
Über Browser starten, Review-Daten importieren, Sitzungen online oder lokal durchführen.
Wie läuft eine Review-Übung ab? (S.44)
Review-Teams bilden, Rollen verteilen, Prüfling untersuchen, Ergebnisse protokollieren.
Wie erfolgt die Rollenzuteilung in der Review-Übung? (S.46)
Team wählt innerhalb der Gruppe die Rollen selbstständig.
Wie setzt der Moderator seine Aufgaben praktisch um? (S.47)
Er erstellt eine Einladung mit Prüfaspekten und sendet Dateien an Notar.
Wie bereitet sich der Notar auf das Review vor? (S.47)
Technik testen, Datei prüfen, Beameranschluss vorbereiten.
Wie bereiten sich Gutachter auf ein Review vor? (S.47)
Prüfling gründlich lesen, auf zugewiesene Prüfaspekte fokussieren.
Wie wird die Weitergabe von Teamdaten organisiert? (S.48)
Zustimmung der Teilnehmer einholen und Daten nur intern weitergeben.
Wie führt man ein Review Schritt für Schritt durch? (S.52)
Start mit Begrüßung und Anwesenheit, Abschnittsprüfung, Konsensbildung, Export.
Wie wendet man die Tipps für die Rollen im Review an? (S.53)
Indem jeder seine Zuständigkeit kennt und aktiv auf deren Einhaltung achtet.
Wie erstellt man ein effektives Review-Protokoll? (S.54)
Kurz, präzise, objektiv formulieren und nur relevante Befunde erfassen.
Zuletzt geändertvor 17 Tagen
