Design Review Checkliste

Design Inspektions/“Walkthrough“
Checkliste
Nummer: xxxxxxx
Wirksamkeitsdatum: tt.mm.jjjj
Verfallsdatum: tt.mm.jjjj
Geprüft
Name: Barbara Mustermann
Title: Prozessmanager
Verantwortlich: Prozesseigner Implementierung
Titel: Design Inspektions/“Walkthrough“ Checkliste
Ergebnistyp: Checkliste
PAL Nummer: nnnn
Design Inspektions/“Walkthrough“ Checkliste
Die Design Inspektions/“Walkthrough“ Checkliste prüft eine Reihe von Maßnahmen, die für die SoftwareEntwicklung von Bedeutung sind. Diese Maßnahmen charakterisieren strukturelle Faktoren und beurteilen,
wie angemessen oder unangemessen sie sind, anstatt quantitative Kenngrößen gegen einen absoluten
Standard zu prüfen.
Es wird vorgeschlagen alle Design-Elemente gegen folgende Punkte zu prüfen:

1
Kommentare
Vollständigkeit – Die Design-Spezifikation ist auf der
niedrigsten noch angemessenem Ebene vollständig.

Review gemäß der AnforderungsTraceabilitity-Matrix um sicherzustellen, dass
alle Komponenten die aufgrund von
Anforderungen erstellt wurden, geprüft werden
Abdeckung zu folgenden Punkte sicherstellen:
Anforderungen zu Antwortzeiten
Performance Probleme (Speicher- und
Zeitprobleme)
Speicherplatz Freigabe (Hauptspeicher
und Festplattenspeicher)
Wartbarkeit
Verständlichkeit
Datenbankanforderunden
Laden und initialisieren der Anwendung
Fehlerhandling und Neustarteigenschaften
Anwenderschnittstellen-Probleme
Auslieferung der Software
Wiederverwendung von
Softwarekomponenten
COTS
Alle Ein- und Ausgabeschnittstellen
Klarheit und Korrektheit der identifizierten
Schnittstellen
Alle Funktionen sind klar, korrekt und im
angemessem Detaillierungsgrad beschrieben
Die Datenstrukturen sind angemessen
beschrieben
Alle Fehler sind dokumentiert.
Design Review Checkliste
Version 0.9
Seite 1 of 3
07.04.2017
2
Praxistauglichkeit – Das Design ist „gut“.

Abweichungen von den Anforderungen sind
dokumentiert und freigegeben.
“Annahmen” sind dokumentiert.
Wichtige Design-Entscheidungen sind
dokumentiert.
Das Design ist eindeutig und präzise
beschrieben.
Abhängigkeiten von anderen Funktionen,
Betriebssystemen, Hardware, etc. sind
dokumentiert.
Das Design folgt allgemeinen
Notationskonventionen.
3
Korrektheit – Das Design führt zu „guter“ Software.

4
5
Die Logik ist korrekt.
Speicher- und Zeitvorgaben sind sinnvoll und
erreichbar.
Fehlermeldungen sind hilfreich und
verständlich.
Das Design ist verständlich (leicht zu lesen,
die Logik ist nachvollziehbar)
Das Design ist wartbar (keine abskure Logik).
Es ist testbar.
Es ist konsistent (Programmablauf und
Datenformate sind zwischen sendenden und
empfangenen Komponenten/Software
konsistent).
Das Design ist systematisch (Gruppierungen
von Komponenten und Funktionen sind
sinnvoll gewählt).
Das Design schließt Fehler aus. It is mutually
suspicious (i.e., the components/software units
check each other for errors in parameters or
other exchanged data)
Kaufsoftwarekomponenten sind verifiziert.
Einfachheit – Das Design ist nicht komplexer als
notwendig.
Qualität – Ein hochqualitatives Design.

Wurde alternative Design-Ansätze geprüft und
der optimalste Ansatz ausgewählt?
Wurden Bildschirmmaskenentwürfe vom
Endanwender abgenommen?
Sind alle “tbd” Aktivitäten beseitigt?
Design Review Checkliste
Version 0.9
Seite 2 of 3
07.04.2017
Hinweise zu Aktivitäten
Nr. Aktivität
Referenzen
ÄnderungsHistorie
Verantwortlich
Datum

Version
0.9
Design Review Checkliste
Version 0.9
Datum
Beschreibung der Verbesserung der Checkliste
tt.mm.jjjj
Seite 3 of 3
07.04.2017