Design Review Checkliste
Werbung
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
