From: Bernhard Urban Date: Sun, 18 Apr 2010 22:17:24 +0000 (+0200) Subject: get(reviews): irgendwie lustig wie unterschiedlich die reviews ausgefallen sind! *g* X-Git-Tag: spec_final~14 X-Git-Url: http://wien.tomnetworks.com/gitweb/?p=hwmod.git;a=commitdiff_plain;h=3a6d5d79b39c3c9c2b785e1589368b05aa2092b7 get(reviews): irgendwie lustig wie unterschiedlich die reviews ausgefallen sind! *g* --- diff --git a/spec/review/1.txt b/spec/review/1.txt new file mode 100644 index 0000000..1cea282 --- /dev/null +++ b/spec/review/1.txt @@ -0,0 +1,83 @@ +Korrektheit: Enthält die Spezifikation inhaltiche Fehler, widersprüchliche Aussagen oder werden + falsche Annahmen getroffen? Vergeben Sie eine Note (1-5) und begründen Sie! + + +Aufgrund der schlechten Verständlichkeit, ist ein genaues Überprüfen auf Korrektheit nur bedingt +möglich. Aufgefallen sind dennoch folgende Punkte: + +- Seite 2: Die History soll via RS232 nur ausgegeben werden und nicht "importiert" +- Seite 10: Copy & Paste Fehler bei Parser-History-Schnittstelle => Richtungskonflikt +- Seite 15: TC1: 50^B00 ist keine gültige Eingabe lt. angegebener Grammatik siehe Req2 +- Seite 18: read stopbit: Es muss detektiert werden, dass ein Stoppbit gesendet wurde, d.h. das Ende + des Frames muss erkannt werden und durch diesen Zustand dargestellt werden. + +Bei allen State-Machines wird bei Datenleitungen auf Flanken getriggert. Dies ist zwar möglich, aber +es werden ziemlich begrenzte Ressourcen (z.B. Clock-Netze) verschwendet. + +- Seite 24: Wenn eine Priorisierung erfolgen soll, sollte auch definiert werden, wie dies zu + erfolgen hat (Konfliktauflösung). + +Note: 3 +================================================================= +Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des + Designs? Vergeben Sie eine Note (1-5) und begründen Sie! + + +Es gibt keinen Testcase der auf Underflow überprüft. TC6 prüft richtigerweise auf Overflow. + +Der Vollständigkeit halber gehört der PLL und eine Power on Reset(POR) Schaltung beschrieben. + +Sonst wurden keine Auslassungen gefunden. + +Note: 1 +================================================================= +Verständlichkeit: Ist das Dokument klar und verständlich geschrieben? Besitzt das Dokument eine + ordentliche Struktur? Vergeben Sie eine Note (1-5) und begründen Sie! + + +Generell ist die Strukturierung, die Formulierungen und der Satzbau schlecht. + +Das Dokument ist zwar klar gegliedert, jedoch unübersichtlich. Wenn man die Funktionalität eines +Modules verstehen möchte, muss man über 3-4 Textstellen den Überblick behalten, bzw. ständig hin- +und herblättern. + +Die meisten Sätze und auch ganze Absätze sind verschachtelt und dadurch schwer verständlich. Auch +die Eindeutigkeit leidet darunter. Vorgänge werden umgangssprachlich formuliert und sind dadurch +unscharf definiert. + +Die Statemachines sind gar nicht verständlich, da sie einerseits sehr viele Details beinhalten, aber +andererseits fehlen die Zusammenhänge der Details mit dem Verhalten des Moduls. + +Requirements sollen im Aktiv beschrieben werden, d.h. es muss eindeutig erkennbar sein, auf wen das +Requirement zutrifft. +Bsp: Req 3 Dabei soll Punkt- vor Strichrechnung gelten. (wobei und für wen soll dies gelten?) +Req 5 Die Eingabe darf aus 70 Zeichen bestehen. +darf => soll; darf drückt kein Requirement aus. +aus 70 Zeichen => aus bis zu 70 Zeichen; oder sind genau 70 Zeichen gemeint? + +Req6 ... 'Enter' schließt die Eingabe ab und berechnet das Ergebnis, ... (Die Enter-Taste berechnet +das Ergebnis?) +Req9 ist referenziert auf eine "zuvor angegebene Methode" => Welche soll dies sein? Warum überhaupt +eine Methode als Requirement spezifiziert + +Note: 4 +================================================================= +Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes + Feedback über die Qualität ihres Spezifikations-Dokumentes! + + +Eine Spezifikation soll die Teile definieren, die nötig sind um ein Projekt zu modularisieren und +die Teile weglassen, die nicht beschrieben werden müssen, um eine bestimmte Aufgabe zu lösen. + +In eurer Spezifikation sind viel zu viele Implementationsdetails vorhanden. Dadurch würdet ihr bei +einem korrekten Workflow, entweder die Implementierung an die Spezifikation binden oder die +Spezifikation muss, bei einer abweichenden Implementierung, erneut verändert werden. + +In der jetzigen Fassung ist es, unserer Meinung nach, nicht möglich die Spezifikation als Vorlage +für eine Implementierung zu verwenden. +Stellt euch die Frage, was jemandem mitgeteilt werden muss, damit er eine (Teil-)Aufgabe/Problem +lösen kann. +Es ist nicht relevant das Projekt mit euer Lösung zu präsentieren. + +Note: 3 + diff --git a/spec/review/2.txt b/spec/review/2.txt new file mode 100644 index 0000000..ed6d736 --- /dev/null +++ b/spec/review/2.txt @@ -0,0 +1,36 @@ +Korrektheit: Enthält die Spezifikation inhaltiche Fehler, widersprüchliche Aussagen oder werden + falsche Annahmen getroffen? Vergeben Sie eine Note (1-5) und begründen Sie! + +1 + +Zwei wiederspruechliche Aussagen sind mir aufgefallen, fallen aber wohl unter Fluechtigkeitsfehler: + +Einleitung: Hier wird geschrieben, dass die Moeglichkeit besteht, die History per +RS232-Schnittstelle zu importieren. Im Rest des Dokuments wird jedoch nicht beschrieben wie. + +Req 10 widerspricht 3.2, "Fehlermeldungen", indem es festlegt dass nur korrekte Eingaben in die +History aufgenommen werden. +================================================================= +Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des + Designs? Vergeben Sie eine Note (1-5) und begründen Sie! + +2 + +Weitere Testcases, die andere Requirements als die der Zahlenbereiche abdecken, waeren noch gut. +Beispielsweise die leere Eingabe, die Eingabe von "3^B^B" oder "-5 - - 2". +================================================================= +Verständlichkeit: Ist das Dokument klar und verständlich geschrieben? Besitzt das Dokument eine + ordentliche Struktur? Vergeben Sie eine Note (1-5) und begründen Sie! + +2 + +Absatz 3.1 haette ich ans Ende des Dokuments gegeben, sonst wird man von Tabellen "erschlagen", +bevor man deren Verhalten kennt. +================================================================= +Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes + Feedback über die Qualität ihres Spezifikations-Dokumentes! + +1 + +Das Dokument hat mir vor allem wegen der Statemachine Diagramme samt ausfuehrlichen Erklaerungen gut +gefallen. Es ist aber auch ansonsten alles drin, was man sich erwartet.