1926050: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
Zeile 15: | Zeile 15: | ||
==Termine== | ==Termine== | ||
==Termine== | |||
<dl> | |||
<dt> 17. April 2016:</dt> | |||
<dd>1. Zwischenabgabe: Projektthema und Grobkonzept für die Studienarbeit | |||
(via [https://moodle.hs-augsburg.de/course/view.php?id=1169 Moodle]) | |||
</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 | 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, 18: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):
- den Autor/die Autoren der Anwendung
- den Namen der Anwedung
- eine aussagekräftige Kurzbeschreibung der Anwendung
- eine kurze Installationsanleitung (falls notwendig)
- eine kurze Bedienungsanleitung
- ein technisches Konzept der Anwendung
- Inhalt: Strukturierung/Aufbau des Codes, angewendete Programmiertechniken, verwendete Technologien und Begründungen für sämtliche Entscheidungen
- Umfang: ca. eine Seite Text, bei Verwendung von Grafiken entsprechend mehr
- UML-Diagramme dürfen gerne verwendet werden, sind aber kein Pflichtbestandteil
- Quellenangaben zu allen für die Arbeit verwendete Quellen: Software, fremde Bibliotheken, fremde Algorithmen, Literatur (Nachschlagewerke) etc.
- 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
- Angewendete Programmiertechniken
- 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).