1926050: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 15: Zeile 15:
==Termine==
==Termine==


*    2.10.2015: Anmeldung zum Kurs (https://moodle.hs-augsburg.de/course/view.php?id=1171) und Nennung der RZ-Kennung
==Termine==
*    16.10.2015: Abgabe von Thema und Grobkonzept für die Studienarbeit (via Moodle)
<dl>
*    21.-23.10.2015: Zwischenpräsentationen der Studienarbeit (via Praktikum)
  <dt> 17. April 2016:</dt>
*    1.11.2015 (23:59 Uhr): Abgabe der Studienarbeit, plus Dokumentation und Erstellungserklärung (via Commit im SVN)
  <dd>1. Zwischenabgabe: Projektthema und Grobkonzept für die Studienarbeit
*    5.11.2015: Prüfungspraktikum
      (via [https://moodle.hs-augsburg.de/course/view.php?id=1169 Moodle])
*    4. und 6.11.2015 November: Präsentation der Studienarbeiten
  </dd>
  <dt>31. Mai 2015:</dt>
  <dd>2. Zwischenabgabe: Präsentation der Zwischenergebnisse
    (via [https://moodle.hs-augsburg.de/course/view.php?id=1169 Moodle])
  </dd>
  <dt>10. Juli  2016:</dt>
  <dd>Abgabe der vollständigen Studienarbeit
      einschließlich einer [[Erstellungserklärung]]
      (via [https://moodle.hs-augsburg.de/course/view.php?id=1169 Moodle])
  </dd>
<dt> Juli  2016:</dt>
  <dd>Präsentation der Studienarbeit
  </dd>
</dl>


==Studienarbeit==
==Studienarbeit==
Zeile 129: Zeile 142:
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 Erstellungserklärung fehlt'''.


Die Arbeit wird als unvollständig und damit als '''nicht abgegeben''' gewertet, wenn '''die grobe Enstehungsgeschichte 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 jeder Zwischenabgabe und anschließend mindestens 10 einschlägige Updates vor der Endabgabe).
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 jeder Zwischenabgabe und anschließend mindestens 10 einschlägige Updates vor der Endabgabe).
|kürzel=
|kürzel=
}}
}}

Version vom 10. März 2016, 19:44 Uhr


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

Termine

17. April 2016:
1. Zwischenabgabe: Projektthema und Grobkonzept für die Studienarbeit (via Moodle)
31. Mai 2015:
2. Zwischenabgabe: Präsentation der Zwischenergebnisse (via Moodle)
10. Juli 2016:
Abgabe der vollständigen Studienarbeit einschließlich einer Erstellungserklärung (via Moodle)
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-Mohrhun
  • 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 jeder Zwischenabgabe und anschließend mindestens 10 einschlägige Updates vor der Endabgabe).