1926050

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg


Diese Prüfung wird nicht mehr angeboten.
 

Nummer 1926050
Studiengang Interaktive Medien (IAM 2006)
Modul Multimedia-Anwendungen
Lehrveranstaltung Multimedia-Anwendungen/Programmierung
Alternativname Multimedia-Programmierung, MMProg
Kürzel i4.MM
Prüfer
Zweitprüfer
Prüfung Diese Prüfung wird nicht mehr angeboten.
Prüfungsart Studienarbeit, Präsentation
Details
Hilfsmittel

Termine

29. März 2016:
Anmeldung zur Teilnahme an der Wiederholungsprüfung (via Moodle).
Achtung: Sie müssen sich im Mai auch noch über den Verwaltungsserver der HS-Augsburg zur Prüfung anmelden.
17. April 2016:
1. Zwischenabgabe: Projektthema und Grobkonzept für die Studienarbeit (via Moodle)
29. Mai 2016:
2. Zwischenabgabe: Erster Prototyp (via Moodle)
31. Mai – 3. Juni 2016:
Präsentation des Konzepts und des Prototyps (J2.10). Die genauen Präsentationstermine werden am 30. Mai festgelgegt und unter https://mmprog.hs-augsburg.de/semester/termine/ veröffentlicht.
10. Juli 2016:
Abgabe der vollständigen Studienarbeit einschließlich einer Erstellungserklärung (via Moodle). Die genauen Präsentationstermine werden nach dem 10. Juli festgelgegt und unter https://mmprog.hs-augsburg.de/semester/termine/ veröffentlicht.
Juli 2016:
Prüfungspraktikum (Teilnahme nur erforderlich, falls Sie dieses nicht bereits erfolgreich absolviert haben.)
Juli 2016:
Präsentation der Studienarbeit

Studienarbeit

Als Teilnehmer der Lehrveranstaltung „Multimedia-Anwendungen/Programmierung“ (MMProg) sollen Sie nachweisen, dass Sie in der Lage sind, eine interaktive Web-Anwendung mit Hilfe von HTML 5 und JavaScript (ECMAScript 5) zu erstellen.

Sie müssen daher im Rahmen einer Studienarbeit eine derartige Anwendung gemäß den in der Vorlesung vermittelten Prinzipien realisieren. Am Ende des Semesters müssen Sie diese Arbeit präsentieren. Sie können sich das Thema (in Absprache mit dem Professor/Dozent) selbst aussuchen.

Da sich die Vorlesung und das Praktikum an dem Thema Spiele orientieren ist es sinnvoll ein Spiel als Studienarbeit zu programmieren.

Anbei finden Sie eine exemplarische und unvollständige Liste mit Themenvorschlägen:

  • Mini-Billard
  • Mini-Mohrhuhn
  • Geschicklichkeitsspiel: herabfallende Gegenstände sammeln, Ballerspiel, ...
  • Snake
  • Memory
  • Vier gewinnt, Fünf gewinnt, Reversi ... (zwei Spieler, evtl. auch ein Spieler + KI)
  • Point-and-Click (2D)
  • Jump-and-Run
  • Spielephysik
  • Tic Tac Toe
  • Pong
  • Doodle Jump
  • Flappy Bird
  • Bubble Worlds

Es ist empfehlenswert und in den meisten Fällen auch einfacher die Studienarbeit alleine anzufertigen. Sie können die Studienarbeit allerdings auch als Zweier- oder Dreier-Teams realisieren. In diesem Fall muss die Arbeit aus klar erkennbar eigenständig angefertigen Teilen bestehen. Jedes Teammitglied muss einen angemessenen Teil dieser Anwendung implementieren.

Beachten Sie, dass Sie im Falle einer Wiederholungsprüfung eine vollkommen neue Arbeit erstellen müssen.

Wiederverwendung von Code

Sie sind dazu berechtigt fremden Code in Ihrer eigenen Arbeit zu verwenden, solange dies durch dessen Lizenz erlaubt ist. Dazu zählen auch sämtliche Code-Beispiel und Musterlösungen aus der Lehrveranstaltung. Für jeglichen fremden Code müssen Sie die Quelle korrekt angeben. Übersteigt die Menge an fremden Code die des eigenen, kann Ihre Studienarbeit als mangelhaft bewertet werden.

Dokumentation

Die Dokumentation der Studienarbeit (ein PDF-Dokument) muss Folgendes enthalten (siehe auch die Abgabeliste im Anschluss an die Erstellungserklärung):

  1. den Autor/die Autoren der Anwendung
  2. den Namen der Anwedung
  3. eine aussagekräftige Kurzbeschreibung der Anwendung
  4. eine kurze Installationsanleitung (falls notwendig)
  5. eine kurze Bedienungsanleitung
  6. ein technisches Konzept der Anwendung
    1. Inhalt: Strukturierung/Aufbau des Codes, angewendete Programmiertechniken, verwendete Technologien und Begründungen für sämtliche Entscheidungen
    2. Umfang: ca. eine Seite Text, bei Verwendung von Grafiken entsprechend mehr
    3. UML-Diagramme dürfen gerne verwendet werden, sind aber kein Pflichtbestandteil
  7. Quellenangaben zu allen für die Arbeit verwendete Quellen: Software, fremde Bibliotheken, fremde Algorithmen, Literatur (Nachschlagewerke) etc.
  8. Bei mehreren Autoren: Eine Übersicht, welcher Autor für welche Teile der Arbeit verantwortlich ist.

Bewertung

Sie müssen bei der Erstellung der Arbeit darauf achten, dass Sie verständlichen, lesbaren, modularen und wiederverwendbaren Code nach anerkannten objektorientierten Programmierprinzipien schreiben. Die Anwendung muss mit mit HTML5 und JavaScript erstellt werden.

In die Bewertung fließen ein:

In die Bewertung der Studienarbeit fließen ein:

  • Studienarbeit
    • Angewendete Programmiertechniken
      • Timer (setTimeout, setInterval, requestAnimationFrame)
      • Event-Listener, Verarbeitung von Events
      • Objekte, Konstruktoren oder Factories
      • Rendering mit DOM oder SVG
      • Ergänzend: Anspruchsvolle Verwendung von Browser-APIs oder Libraries
    • Qualität
      • Modularisierung (Datei- und Code-Ebene)
      • Sinnvolle Benennung, Aussagekraft
      • Wiederverwendbarkeit, Konfigurierbarkeit
      • Korrektheit, keine Fehler
      • Keine Redundanz
    • Model-View-Controller
      • Sämtliche (Spiele-)Logik im Model
      • Sauberes Model
      • Saubere View
      • Sauberer Controller
    • Umfang
      • Angemessene Code-Menge
      • Höherer Eigenanteil als Fremdanteil
      • Aktivität im SVN-Repository
    • Dokumentation
      • Angemessener Umfang
      • Form
      • Technisches Konzept
      • Quellenangaben
  • Prüfungspraktikum
    • Qualität und Korrektheit der Lösungen

Bitte beachten Sie, dass die Studienarbeit im Vergleich zum Prüfungspraktikum wesentlich stärker gewichtet wird.

Die gesamte Arbeit wird als mangelhaft bewertet, sobald auch nur ein Plagiat enthalten ist.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn eine der Zwischenabgaben nicht erfolgt ist.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn die Erstellungserklärung fehlt.

Die Arbeit wird als unvollständig und damit als nicht abgegeben gewertet, wenn die grobe Entstehungsgeschichte der Arbeit nicht anhand der Besprechungen im Praktikum oder anhand der Versionen im SVN-Repository nachvollzogen werden kann (entweder regelmäßige Teilnahme am Praktikum oder mindestens 5 einschlägige Updates vor der 2. Zwischenabgabe und anschließend mindestens 10 einschlägige Updates vor der Endabgabe).