1926050: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
{{Prüfungsnummer
{{Prüfungsnummer
|vererbung=
|nummer=
|studiengang=IAM 2006
|studiengang=IAM 2006
|lehrveranstaltung=Multimedia-Anwendungen/Programmierung
|lehrveranstaltung=Multimedia-Anwendungen/Programmierung
|pruefungsart=Onlineklausur
|kuerzel=
|details=Dauer: 120 min
|pruefung=
|pruefungsart=Prüfungspraktikum, Studienarbeit
|details=Prüfungspraktikum: 3 h
|hilfsmittel=
|pruefer=
|zweitpruefer=Sabine Müllenbach
|zweitpruefer=Sabine Müllenbach
|inhalte===Termine==
<dl>
<!--
  <dt>5. November 2017:</dt>
  <dd>(Nachträgliche) Anmeldung zur Teilnahme an der Lehrveranstaltung über [https://moodle.hs-augsburg.de/course/view.php?id=866 Moodle]. '''Achtung''': Zur eigentlichen Prüfung müssen Sie sich außerdem noch zwischen dem 3. 11. und 17. 11. 2017 über den [https://www.hs-augsburg.de/Pruefungen.html Verwaltungsserver der HS Augsburg] anmelden.</dd>
-->
  <dt>14. April 2019:</dt>
  <dd>Abgabe der Anwendungsfälle (Use-Cases) via [https://gitlab.multimedia.hs-augsburg.de:8888/ACCOUNT/ Git-Repository] und Link in [https://moodle.hs-augsburg.de/course/view.php?id=2297 Moodle]</dd>
  <dt>19. Mai 2019:</dt>
  <dd>Abgabe des Datenmodells: UML-Klassendiagramm (einschließlich textueller Beschreibung) sowie zugehöriger JavaScript-Dateien, die dieser Struktur genügen (die Implementierungen der Klassen und Funktionen dürfen noch fehlen)<br />
      Datenmodell als PDF-Datei sowie JavaScript-Dateien im [https://gitlab.multimedia.hs-augsburg.de:8888/ACCOUNT/ Git-Repository], Link auf den Ordner im Repository in [https://moodle.hs-augsburg.de/course/view.php?id=2297 Moodle]
  </dd>
  <dt>Nach der 2. Zwischenabgabe (die genauen Termine werden nach der Abgabe bekannt gegeben):</dt>
<dd>Zwischenpräsentation der Studienarbeiten
</dd>
  <dt>4. Juli 2019, 16:30 – 18:00 (Termin noch ohne Gewähr):</dt>
  <dd>Prüfungspraktikum
</dd>
  <dt>7. Juli 2019:</dt>
  <dd>Abgabe der vollständigen Studienarbeit
      einschließlich einer [https://moodle.hs-augsburg.de/course/view.php?id=2297 Erstellungserklärung]
      (via  [https://gitlab.multimedia.hs-augsburg.de:8888/ACCOUNT/ Git-Repository] und Link in [https://moodle.hs-augsburg.de/course/view.php?id=2297 Moodle])
  </dd>
<dt>10./11./12. Juli 2019, J2.10 (die genauen Termine werden nach der Endabgabe bekanntgegeben):</dt>
  <dd>Präsentation der Ergebnisse.
      Sie müssen Ihre Anwendung erklären und Ihre Anwendung demonstrieren können.
      Sie brauchen keine Präsentationsfolien vorzubereiten.
  </dd>
</dl>
Beachten Sie, dass in dem Dokument [https://moodle.hs-augsburg.de/course/view.php?id=2297 Erstellungserklärung] auch eine Abgabeliste enthalten ist, in der genau aufgelistet wird, was Sie in welcher Form abgeben müssen.
Darüber hinaus müssen Sie im Laufe des Semesters regelmäßig den aktuellen Stand Ihrer Arbeit im Git-Repository, das Ihnen am Anfang des Semesters zur Verfügung gestellt wurde, zwischenspeichern. Das heißt, vor jeder Zwischenabgabe müssen mindestens 5 Versionen der abzugebenden Dokumente ins Repository eingefügt werden. Von der eigentlichen Implementierung der Studienarbeit müssen vor der Endabgabe jeweils mindestens 30 substanziell verschiedene Versionen ins Repository eingefügt werden.
==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 6) 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 Dozenten) 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 (2-dimensional oder 3-dimensional)
#    Pong
#    Doodle Jump
#    Flappy Bird
#    Bubble Worlds
#  ...
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.
Ihre Studienarbeit kann als '''mangelhaft''' bewertet werden, wenn der Eigenanteil an der Arbeit zu gering ist,
{{dh}}, wenn Sie überwiegend vorgefertigten Code zur Realisierung der Arbeit einsetzen.
==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:
*    Studienarbeit
**        Angewendete Programmiertechniken
***            Klassen, Objekte, Objektbuilder
***            Event-Listener, Verarbeitung von Events
***            Modularisierung (Datei- und Code-Ebene)
***            Timer (setTimeout, setInterval)
**        Qualität
***            Qualität der Modularisierung (Datei- und Code-Ebene)
***            Sinnvolle Benennung, Aussagekraft
***            Wiederverwendbarkeit, Konfigurierbarkeit
***            Korrektheit, keine Fehler
***            Keine Redundanz (DRY)
***      Logic-Data-View-Controller(-Service)-Prinzip
****            Qualität der Model-Module
****            Qualität der View-Module
****            Qualität der Controller-Module
****            Qualität der Logik-Module
**        Tiefe
***            Komplexität des selbst erstellten Codes
**        Dokumentation (Use-Cases, Klassendiagramm samt Beschreibungen)
***            Vollständigkeit
***            Verständlichkeit
***            Korrektheit
***            Inline-Kommentare (im Sourcecode)
***            Quellenangaben
*    Prüfungspraktikum
**        Qualität und Korrektheit der Lösungen
Die Bewertung '''einer der Hauptkategorien''' „Programmiertechniken“, „Qualität“, „Umfang“, „Dokumentation“, „Prüfungspraktikum“ als '''mangelhaft''' führt dazu, dass die '''gesamte Arbeit''' als '''mangelhaft bewertet''' wird. Eine Arbeit, die nicht gemäß einen Pattern wie MVC oder LDVC strukturiert ist, wird höchstens als
''ausreichend'' bewertet. 
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 ein wesentlicher Bestandteil fehlt, d.h., wenn '''in der Abgabeliste''' im Anschluss an die Erstellungserklärung '''eine wesentliche Frage mit nein beantwortet wurde oder wenn die Erstellungserklärung samt Abgabeliste 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  20 einschlägige Updates vor der Endabgabe).
|kürzel=
}}
}}

Version vom 27. September 2019, 16:55 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

14. April 2019:
Abgabe der Anwendungsfälle (Use-Cases) via Git-Repository und Link in Moodle
19. Mai 2019:
Abgabe des Datenmodells: UML-Klassendiagramm (einschließlich textueller Beschreibung) sowie zugehöriger JavaScript-Dateien, die dieser Struktur genügen (die Implementierungen der Klassen und Funktionen dürfen noch fehlen)
Datenmodell als PDF-Datei sowie JavaScript-Dateien im Git-Repository, Link auf den Ordner im Repository in Moodle
Nach der 2. Zwischenabgabe (die genauen Termine werden nach der Abgabe bekannt gegeben):
Zwischenpräsentation der Studienarbeiten
4. Juli 2019, 16:30 – 18:00 (Termin noch ohne Gewähr):
Prüfungspraktikum
7. Juli 2019:
Abgabe der vollständigen Studienarbeit einschließlich einer Erstellungserklärung (via Git-Repository und Link in Moodle)
10./11./12. Juli 2019, J2.10 (die genauen Termine werden nach der Endabgabe bekanntgegeben):
Präsentation der Ergebnisse. Sie müssen Ihre Anwendung erklären und Ihre Anwendung demonstrieren können. Sie brauchen keine Präsentationsfolien vorzubereiten.

Beachten Sie, dass in dem Dokument Erstellungserklärung auch eine Abgabeliste enthalten ist, in der genau aufgelistet wird, was Sie in welcher Form abgeben müssen.

Darüber hinaus müssen Sie im Laufe des Semesters regelmäßig den aktuellen Stand Ihrer Arbeit im Git-Repository, das Ihnen am Anfang des Semesters zur Verfügung gestellt wurde, zwischenspeichern. Das heißt, vor jeder Zwischenabgabe müssen mindestens 5 Versionen der abzugebenden Dokumente ins Repository eingefügt werden. Von der eigentlichen Implementierung der Studienarbeit müssen vor der Endabgabe jeweils mindestens 30 substanziell verschiedene Versionen ins Repository eingefügt werden.

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 6) 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 Dozenten) 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:

  1. Mini-Billard
  2. Mini-Mohrhuhn
  3. Geschicklichkeitsspiel: herabfallende Gegenstände sammeln, Ballerspiel, ...
  4. Snake
  5. Memory
  6. Vier gewinnt, Fünf gewinnt, Reversi ... (zwei Spieler, evtl. auch ein Spieler + KI)
  7. Point-and-Click (2D)
  8. Jump-and-Run
  9. Spielephysik
  10. Tic Tac Toe (2-dimensional oder 3-dimensional)
  11. Pong
  12. Doodle Jump
  13. Flappy Bird
  14. Bubble Worlds
  15. ...

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. Ihre Studienarbeit kann als mangelhaft bewertet werden, wenn der Eigenanteil an der Arbeit zu gering ist, d. h., wenn Sie überwiegend vorgefertigten Code zur Realisierung der Arbeit einsetzen.

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:

  • Studienarbeit
    • Angewendete Programmiertechniken
      • Klassen, Objekte, Objektbuilder
      • Event-Listener, Verarbeitung von Events
      • Modularisierung (Datei- und Code-Ebene)
      • Timer (setTimeout, setInterval)
    • Qualität
      • Qualität der Modularisierung (Datei- und Code-Ebene)
      • Sinnvolle Benennung, Aussagekraft
      • Wiederverwendbarkeit, Konfigurierbarkeit
      • Korrektheit, keine Fehler
      • Keine Redundanz (DRY)
      • Logic-Data-View-Controller(-Service)-Prinzip
        • Qualität der Model-Module
        • Qualität der View-Module
        • Qualität der Controller-Module
        • Qualität der Logik-Module
    • Tiefe
      • Komplexität des selbst erstellten Codes
    • Dokumentation (Use-Cases, Klassendiagramm samt Beschreibungen)
      • Vollständigkeit
      • Verständlichkeit
      • Korrektheit
      • Inline-Kommentare (im Sourcecode)
      • Quellenangaben
  • Prüfungspraktikum
    • Qualität und Korrektheit der Lösungen

Die Bewertung einer der Hauptkategorien „Programmiertechniken“, „Qualität“, „Umfang“, „Dokumentation“, „Prüfungspraktikum“ als mangelhaft führt dazu, dass die gesamte Arbeit als mangelhaft bewertet wird. Eine Arbeit, die nicht gemäß einen Pattern wie MVC oder LDVC strukturiert ist, wird höchstens als ausreichend bewertet.

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 ein wesentlicher Bestandteil fehlt, d.h., wenn in der Abgabeliste im Anschluss an die Erstellungserklärung eine wesentliche Frage mit nein beantwortet wurde oder wenn die Erstellungserklärung samt Abgabeliste 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 20 einschlägige Updates vor der Endabgabe).