LeoCode

‏ ‏ ‎ ‏ ‏ ‎ ‏ ‏ ‎

1. Pflichtenheft

1.1. Ausgangssituation

Die HTL Leonding ist eine HTL mit ungefähr 1000 Schülern und den Abteilungen Medientechnik, Informatik, Medizintechnik sowie Elektronik.

1.2. Istzustand

In allen Zweigen spielt das praktische Programmieren eine mehr oder weniger große Rolle, besonders in den Medientechnik- bzw. Informatik-Zweigen. Bei den ersten Klassen sind meistens viele Schüler dabei, die noch keine Erfahrung mit Programmieren hatten.

1.3. Problemstellung

Viele Schüler haben aber durch den Lehrplan nicht genug praktische Übung im Unterricht und kennen sich meistens nicht bei den Hausübungen aus. Noch dazu haben die ersten Klassen öfters Probleme mit den IDE’s. Meistens haben sie keinen Zugriff oder andere Probleme.

1.4. Aufgabenstellung

Zu entwickeln ist eine Plattform, die Folgendes kann:

Die Plattform gibt den Schülern die Möglichkeit verschiedene Programmiersprachen mit einfachen Übungen zu üben.
Die Plattform stellt den Schülern die Lösungen der Aufgaben zur Verfügung.
Die Plattform gibt den Schülern ein Feedback zu den gelösten Aufgaben mithilfe von Unit Tests.
Die Plattform ermöglicht den Lehrern Aufgaben, Quizzes und/oder Tests zu erstellen und diese dann den Schülern bereitzustellen.

1.4.1. Funktionale Anforderungen

Use-Case Diagramm (Professor)

Use-Case Diagramm (Student and Guest)

Use-Cases von der Schülerperspektive:

Der Schüler hat die Möglichkeiten:

sich anzumelden (nicht zwingend)
Aufgaben und Tests zu sehen
Aufgaben und Tests zu absolvieren
Feedback zu den Aufgaben und Tests anzuschauen (Unit Tests)

Ein Schüler hat die Möglichkeit sich anzumelden, aber eine Verwendung ohne Anmeldung ist auch möglich.
Der Schüler hat die Möglichkeiten sich seine Aufgaben anzuschauen und die Aufgaben zu erledigen. Noch dazu hat der Schüler auch Zugriff auf die vom Professor vorgefertigten Tests, die er auch absolvieren kann.
Zu den jeweiligen Aufgaben oder Tests bekommt jeder Schüler ein kleines Feedback, welches sich der Schüler jederzeit durchlesen kann.

Use-Cases von der Professorperspektive:

Der Professor hat die Möglichkeiten:

sich anzumelden
Aufgaben und Tests zu veröffentlichen/bearbeiten.
Aufgaben und Tests einzusehen (auf Freigabe des Schülers)
Anonyme Statistiken von Aufgaben (Anzahl erledigt,Anzahl geschafft …)

Ein Professor hat die Möglichkeit sich anzumelden. Falls der Professor einen Test für eine Klasse erstellt hat, kann er diesen ebenfalls veröffentlichen.
Nachdem der Schüler die Tests und Aufgaben absolviert hat, ist der Professor in der Lage sich diese anzuschauen, falls der Schüler es für den Lehrer freigibt. Dazu kann er die anonyme Statistik der Aufgaben einsehen.

Use-Cases von der Gastperspektive:

Der Gast hat die Möglichkeiten:

Aufgaben und Tests zu sehen
Aufgaben und Tests zu absolvieren

Ein Gast-User hat begrenzte Möglichkeiten im Gegensatz zum Schüler und Professor.

1.4.2. Nichtfunktionale Anforderungen

Benutzerfreundlichkeit
Verlässlichkeit
Effizienz
Performance
Wartbarkeit

1.4.3. Process-diagram for the student and Professor

1.4.4. UI for program

Figure 1. Login View

Figure 2. Upload Teacher View

Figure 3. Teacher Example View

Figure 4. Code Editor View

Figure 5. Student Report View

Figure 6. Student Test Code View

Figure 7. Student Exercise View

Figure 8. Student Detail View

1.5. Ziele

Schüler bekommen eine Vielfalt von Beispielen inklusive Unterrichtsbeispielen bereitgestellt.
Eine verstärkte Koordination des Unterrichts in den jeweiligen Schulstufen und auch zwischen Parallelklassen.
Das Vermitteln von Programmiermethoden an die Schüler wird dem Lehrer erleichtert.

1.6. Mengengerüst

Hunderte von Schülern bekommen eine Auswahl von Programmierbeispielen, die sie absolvieren können. Diese Aufgaben werden gleichzeitig kompiliert und mit Unit Tests getestet. Die Aufgaben und Tests werden in einer Datenbank gespeichert. Die WebApp läuft über einen RestClient.