|
|
# Projektdurchführung
|
|
|
|
|
|
Vor Projektbeginn fertigten wir einen [QA-Report](qa-report) an, um uns darüber im klaren zu werden, welchen Schwierigkeiten wir uns entgegen stellen mussten.
|
|
|
Dieser [QA-Report](qa-report) zeigte uns sehr schnell die Schwierigkeiten und Hindernisse auf, mit denen wir während dem Projektverlauf, zu kämpfen haben sollten. Trotz all dieser Problematiken, war der uns von der Master-Gruppe zur Verfügung gestellte Code, dennoch in Teilbereichen nutzbar. Mit den erlangten Kenntnissen im Hinterkopf, konnten wir uns frisch ans Werk machen!
|
|
|
|
|
|
## Probleme
|
|
|
|
|
|
Besonders im Hinblick auf die Lesbarkeit und Strukturierung des Codes, im Zusammenhang mit der Nutzung einer Versionsverwaltung wie GitLab, gab es zu überwindende Stolpersteine. So wurden wir im Verlauf der Herrichtung des Codes auf auskommentierte Bereiche aufmerksam, die es in die Versionierung schafften. Deren Notwendigkeit aufgrund der Versionierung allerdings gar nicht gegeben war.
|
|
|
|
|
|
Des weiteren fand eine partielle Umstrukturierung des Codes statt, welche als neue Commits ihren Weg in die Versionierung fanden. Das verwenden einzelner Teilbereiche wurde somit erschwert!
|
|
|
|
|
|
Die Darstellung der Entwicklungen im Frontend waren für uns erst nach einiger Zeit erkennbar, sodass man nicht gleich darauf schließen konnte, dass eine Anpassung erfolgte. Dies mündete zunächst in einer Ernüchterung im Hinblick auf den vorhandenen Code, lies uns dann aber mit neuen Erkenntnissen fortfahren.
|
|
|
|
|
|
## Durchführung
|
|
|
|
|
|
Zu Beginn unserer Durchführung sind wir dem wohlbekannten Pattern "read the code in one hour" gefolgt um damit ein erstes weitergehendes Verständnis für den uns bereitgestellten Code zu entwickeln. Auf dieser Basis folgte eine fokussierte Sichtung des Codes, um die kritischen Stellen der nachfolgenden Entwicklung, ausfindig zu machen. Hierbei konnten wir bestimmte, bereits integrierte Kernelemente ausfindig machen und diese für die weitere Entwicklung aufbereitet nutzen.
|
|
|
|
|
|
Da bereits Nutzbares in diesem zweiten Abschnitt der Durchführung vorhanden war, musste dieses einer ersten Use-Case Prüfung unsererseits standhalten. Hierbei wurden essentielle Kernfunktionalitäten abgefragt und mit dem eingeforderten Verhalten abgeglichen. Sofern es hierbei zu Abweichungen kam, wurden diese für den weiteren Verlauf festgehalten um diese in der fortgehenden Entwicklung integrieren zu können.
|
|
|
|
|
|
Die durch die vorangehenden Schritte erworbenen Kenntnisse, konnten folglich ihren Weg, in die Umsetzung finden. Hierbei wurde besonders darauf geachtet, bereitgestellte Funktionalitäten durch ARSnova weiterzunutzen und nicht durch Eigenentwicklungen aufzublähen. Dies wurde auch besonders bei der Umsetzung des erforderlichen Features beachtet und floss somit als Kerngedanke der Entwicklung mit ein.
|
|
|
|
|
|
## Ergebnis
|
|
|
|
|
|
Die Funktionalitäten des Projekts lassen sich folgendermaßen zusammenfassen:
|
|
|
|
|
|
1. Bepunktung von Freitext-Fragen
|
|
|
2. Prüfung von Freitext-Fragen auf strikte Einhaltung der Vorgaben
|
|
|
3. Integrieren von Ausnahmen der strikten Prüfung (Case-Sensitive / Interpunction / Spaces)
|
|
|
4. Prüfung von Freitext-Fragen auf einfache Einhaltung der Vorgaben
|
|
|
5. Studierende können ihre Antworten auf Korrektheit prüfen
|
|
|
6. Dozent besitzt Übersicht, über eingereichte Antworten
|
|
|
|
|
|
Weiterhin werden vorhandene Datensätze in der Datenbank integriert. Informationen sind somit nicht auf den "Local-Storage" begrenzt, sondern auch übergreifend verfügbar! |
|
|
\ No newline at end of file |