Category Archives: Software Engineering I

Examination Rules

Software Engineering I, WS1011

To make the grading system as transparent as possible we decided to publish our assessment criteria here. The final grade of each team member will be calculated as follows:

  • 50% individual- and 50% team effort, where
    • The individual effort is
      • 10% individual time
      • 15% presentation (each release) and
      • 25% role (perception of the role you had in the scrum process during the release)
    • The team effort is
      • 10% team time
      • 40% assessment of the releases (4 releases, each 10%)

What is individual and team time? What is important for the presentation and how do we assess the preception of your different roles? Here are the answers:

  • Individual and team time
    • At least one hour of each individual and team time to get a 4.0.
    • Two hours of each individual and team time to get a 1.0.
    • At the end of each weekly meeting you will get an assessment in the range (-2,…,+2) which will be summarized at the end of SE1 and build your individual/team grade.
    • Individual time
      • Starts counting if at least two team members start working on the project (two because we want to boost pair programming) in the SE lab.
    • Team time
      • Starts counting if at least 75% of the team comes together in the SE lab and start working on the project.
      • Team time also counts into individual time!
  • Presentation
    • Each release ends with the presentation of the results.
    • Present the new features which you developed within the last 4 weeks
    • 50% content. We assess how efficient you’ve worked within the last 4 weeks. Efficency is meant as the relation between the planned and realized features. However you’ll not get a bad grade if you have good arguments why the planned features didn’t get into the product.
    • 50% presentation style.
    • You will get feedback at the end of each presentation!
  • Roles
    • Dependent on the role you had within a release, we will asses as follows
      • Scrum Master
        • “The scrum master has to ensure that the team has everything it needs to get the work done.”
        • Contacts the SE experts and arranges the weekly meetings
        • We will asses how you did this job!
      • Product owner
        • Maintains the Agilo instance and writes “User Stories”.
        • Prioritizes the tasks in the product backlog
        • We will asses how you did this job by having a look at your agilo.
      • Developer
        • We will have a look at the Agilo burndown charts to get a picture what you did

Emails an den Kunden

Software Engineering I, WS1011

Bitte achtet darauf in den Emails an die Kunden euren Namen, eure Gruppe, einen (oder mehrere Terminvorschläge) und den Grund der Kontaktaufnahme zu nennen. Die Kunden beschäftigen nämlich mehrere Teams gleichzeitig und können anhand einer Email-Adresse nicht unterscheiden zu welchem Team ihr gehört, oder was ihr von ihm wollt.

Ingame JSON Protokoll Details

Software Engineering I, WS1011

Das Ingame JSON Protokoll kennt, wie bereits aus dem Chatprotokoll bekannt, in Serverrichtung Commands und in Clientrichtung Events.

Commands

Die Commands müssen mindestens ein action Attribut enthalten welches folgende Werte annehmen kann (keys in Klammern sind optional):

Action Keys Beispiel Bemerkung
CHOOSE_SECTOR sector {"@action":"CHOOSE_SECTOR","properties":{"entry":{"key":"sector","value":"Sector@1a3b6f"}}} Wählt den Startsektor aus. sector muss eine ID sein.
START_GAME keiner {"@action":"START_GAME"} Startet das spiel wenn jeder Spieler einen Startsektor gewählt hat.
LEAVE_GAME keiner {"@action":"LEAVE_GAME"} Verlässt das aktuelle Spiel.
TRANSFER_MEN source, target, amount {"@action":"TRANSFER_MEN","properties":{"entry":{"key":"source","value":"Tower@1a3b6f"},"entry":{"key":"target","value":"Invention@b54ddf"},"entry":{"key":"amount","value":"12"}}} Transferiert amount Men von einem Ort zum anderen, solange es keine Armee betrifft. source und target erwarten die ID eines Towers, einer Invention oder einer Resouorce
CREATE_ARMY tower, amount, (weapon), (target) {"@action":"CREATE_ARMY","properties":{"entry":{"key":"tower","value":"Tower@1a3b6f"},"entry":{"key":"weapon","value":"Invention@b54ddf"},"entry":{"key":"amount","value":"12"},"entry":{"key":"target","value":"Sector@1a3b6f"}}} Erzeug mit amount men aus dem per ID angegebenen tower eine neue Army. Die Army wird mit der per ID angegebenen weapon ausgerüstet, wenn genügend waffen im tower verfügbar sind, oder erstellt werden können. Als target kommen per ID angegebene Turrets oder angrenzende Sectoren in Frage.
MOVE_ARMY army, target {"@action":"MOVE_ARMY","properties":{"entry":{"key":"army","value":"Army@d54a23"},"entry":{"key":"target","value":"Sector@1a3b6f"}}} Versetzt die army an das angegebene target, welches ein Tower oder ein Sector sein kann.
RESEARCH tower, invention {"@action":"RESEARCH","properties":{"entry":{"key":"tower","value":"Tower@123abc"},"entry":{"key":"invention","value":"Invention@f45a3b"}}} Erforscht die per ID angegebene invention im per ID angegebenen tower. Es wird ein Research-Objekt erzeugt, dem per TRANSFER_MEN noch Forscher zugewiesen werden müssen.
MESSAGE message, (audience), (recipient) {"@action":"MESSAGE","properties":{"entry":{"key":"message","value":"Hallo"},"entry":{"key":"audience","value":"USER"},"entry":{"key":"recipient","value":"jfd"}}} Siehe Chatprotokoll.

Weitere Commands werden folgen 😉

Events

Der Server schickt Events in der Form

{"@ts":"199027638079229","@src":"Player@1f8882e","@prop":"name","@nv":"jfd","@ov":"jdr"}

In diesem Fall wurde zum Timestamp 199027638079229 von der source Player@1f8882e die property name von jdr (old value) auf jfd (new value) geändert.
Wer sich die Events vom Server genauer anschaut wird feststellen, dass Werte die null sind in JSON wegoptimiert werden.

Tipp: Das nötige Datenmodell lässt sich größtenteils aus dem Eventstream ableiten.