-1. 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. 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!
-2. Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des Designs? Vergeben Sie eine Note (1-5) und begründen Sie!
+Wofuer sind die verschiedenen Clocks im Design da? Ein Multiclockdesign ist nicht wuenschenswert,
+ausserdem zu komplex? Wir glauben man sollte das durch Kontrollsignale ersetzen, also z.B. ein
+Requestsignal geht hoch wenn alle Daten ins Register geladen wurden und bis zur Fertigstellung der
+Arbeit bleibt das ACK-Signal niedrig. Es koennte sein, dass es so gemeint ist, dann ist aber die
+Bezeichnung '*_clk' sehr irrefuehrend gewaehlt.
-3. 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!
+Note: 2
+
+
+2. Vollständigkeit: Enthält das Spezifikations-Dokument alle wesentlichen Requirements/Module des
+ Designs? Vergeben Sie eine Note (1-5) und begründen Sie!
+
+Requirements jein: da auf die genaue art wie das alles funktioniert
+schlicht und ergreifend nicht eingegangen wird.
+
+> bernhard: also ich finde die schon recht detailiert. afaik sagen die Requirements nichts darueber
+> aus wie die komponenten zusammenhaengen, sondern nur wie sich das system gegenueber dem user
+> verhalten soll. (ich kann mich aber auch irren -- ich hasse dieses geschwafel ueber
+> spezifikationen ;))
+
+> alex: ich denke das hier nicht nur die vollstaendigkeit der requirements gemeint ist sondern auch
+> die vollstaendigkeit der module bzw. interfaces. also ist zu jedem interface mindestens ein modul
+> definiert und umgekehrt. Natuerlich gehort auch dazu ob die Module einen vollstaendigen
+> Taschenrechner erzeugen.
+
+Module: Ueberblicksmaessig wirkt es recht gut (abgesehen von den '*_clk'-Signalen, aber in der
+"Detailed Design Description" fehlen eben die Details. Ablaeufe werden zwar textuell kurz erklaert,
+aber sie werden nur sehr oberflaechig und abstrakt "angekratzt". Ausserdem fehlen grafische
+Darstellungen (z.B. State-Maschinen). Weiters waere eine Beschreibung wuenschenswert wie ihr die
+eigentliche Berechnung umsetzen wollt (z.B. mit Hilfe von Pseudocode).
+
+Testfaelle: Sind sehr gut!
+
+
+Note: 2
+
+
+3. 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!
+
+Ja, grundsaetzlich schon, bis auf die Schnittstellenbeschreibung.
+Verbesserungsvorschlaege:
+* eine Spalte zu welchen Module (oder externes Geraet, z.B. PS/2) die Signale fuehren.
+* einheitlichere Beschriftung der Signale (z.B. in "Calculator State Maschine", wo fuehren die
+ Signale "result_data" bzw. "result_clk" hin? Das ist am ersten Blick nicht klar ersichtlich)
+
+Note: 2
+
+
+4. Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes
+ Feedback über die Qualität ihres Spezifikations-Dokumentes!
+
+Wenn die nicht naeher beschriebenen Module funktionieren, schaut das Gesamtdesign recht
+zuversichtlich aus. (Sofern das mit den mehreren Clocksignalen beseitigt wird).
+
+Die "Detailed Design Description" muss unbedingt noch ueberarbeitet werden.
+
+Note: 2
-4. Gesamtbeurteilung: Vergeben Sie eine Gesamtnote (1-5) und geben Sie Ihren Kollegen ein kurzes Feedback über die Qualität ihres Spezifikations-Dokumentes!
projects / hwmod.git / blobdiff