• Hauptseite
• Material
• Organisation
• Literatur
• Software, Technik, Links
• Übungen
• Projekt

Projektnoten

Bemerkungen zur Benotung:

• Um das Projekt zu bestehen, muss die abgegebene Software lauffähig sein.  (Achtung: Das bedeutet nicht im Umkehrschluss, dass eine x-beliebige lauffähige Software als Abgabe automatisch zum bestehen führt!)

• Als Bewertungskriterien werden hauptsächlich
  

  • die Abgabe (inkl. aller Dokumente) und
  • die Präsentation der lauffähigen Software, inkl. der spezifizierten Anwendungsfälle
  herangezogen.

Häufige Fehler/Kritikpunkte:

• Mangelnde Codekommentierung. Kommentare sind dazu da zu erklären, wie der Code funktioniert. Daher ist klar, dass die DAO-Klassen keine Kommentare brauchen, oder zumindest fast keine. Aber der Rest des Codes erledigt selbstverständlich nichttriviale Aufgaben, sonst könnte man ihn sich ja sparen. Hier sind gute Kommentare unerlässlich. Lesetip: „Code tells you how, comments tell you why“ von Jeff Atwood.

• Zu wenige Testdaten.  Datenbanken lassen sich nur dann sinnvoll testen, wenn man mit realistischen Lasten arbeitet, also z.B. anhand einer vollständig modellierten WM. Offensichtlich ist es viel zu mühselig, solche Datenmengen per Hand einzutragen, aber dafür gibt es ja Skripte, entweder zum zufälligen Generieren von Daten, oder zum Auslesen aus anderen Datenquellen, z.B. aus der Wikipedia oder von der offiziellen FIFA-Webseite. In jedem Fall ist es vollkommen unzureichend, wenn man nur drei Teams mit je zwei Spielern als Testdaten verwendet. Welche Invarianten lassen sich denn hier schon sinnvoll verletzen?

• Fremdschlüssel im Entity-Relationship-Model. Fremdschlüssel gehören nicht in das ER-Modell, auf dieser Ebene wird mit Relationen gearbeitet.  Fremdschlüssel sind ein Implementierungsdetail, nicht Teil des Modells.

• Präsentation mangelhaft. Ihr habt 15 Minuten Zeit, um euer komplettes Projekt mitsamt aller Anwendungsfälle erfolgreich vorzuführen. Das ist wenig Zeit, daher gilt: Aufs Wesentliche konzentrieren! Konzentriert euch auf die relevanten Teile der Präsentation und lasst Unwichtiges weg. Übt die Präsentation vorher! – Jeder erfolgreiche Redner tut das.

  Die Zeit reicht einfach nicht, um jedes Objektmodell und jede Designentscheidung zu erläutern, oder auch nur sie zu erwähnen. Es ist daher sinnvoll, sich vorher zu überlegen, was ihr wirklich sagen und somit betonen wollt, und dann überlegt euch, warum ihr es nicht zu sagen braucht. Nur, wenn euch hier keine Gründe einfallen, solltet ihr diesen Punkt (vielleicht) erwähnen.

  Folien sind dafür nicht erforderlich – und bei einer 15-minütigen technischen Präsentation vielleicht auch gar keine gute Idee: sie helfen eventuell bei der Gliederung, kosten aber auch Zeit.

Tipp fürs nächste Projekt:

• Das i-Tüpfelchen auf dem Projekt wäre ein vollautomatisches Build- und Testskript gewesen (auf Englisch unter dem Schlagwort „build automation“ bekannt). Der Vorteil für euch liegt auf der Hand: ihr müsst zu Beginn der Präsentation nur einen Knopf drücken oder ein Kommando ausführen, und der Rest der „Präsentation“ läuft von alleine – und zwar egal, auf welchem System. Das Skript setzt die Datenbank auf, lädt die Testdaten, kompiliert und startet den Code und führt die Anwendungsfälle aus. Dieses Skript habt ihr natürlich ausführlich getestet und schließt dadurch enorm viele Fehlerquellen von vornherein aus. Das Ergebnis ist, dass ihr euch bei der Präsentation viel weniger gestresst fühlt.

  Es gibt diverse Firmen, die bei Softwareprjekten nur noch build automation verwenden: Projekte, die sich nicht mit einem einzigen Kommando komplett kompilieren, verteilen, installieren, testen und ausführen lassen, wird es in wenigen Jahren in der Industrie nicht mehr geben.