115 KiB
Case Study Webtechnologien
- Über dieses Dokument
- Projektanalyse und Planung
- Projektmanagement
- Umsetzung
- Fazit
Über dieses Dokument
Im nachfolgenden Abschnitt finden Sie allgemeine Informationen zu diesem Dokument.
Titel der Dokumentation
Die Gruppe hat verschiedene Varianten gelistet und sich für die Lustigste entschieden.
- Marktplatz
- Shopshop
- Barewahre-Shop
- Didgeridoo-Shop
Aufgrund des eher lustigen Namens dieses Instruments, haben wir uns entschieden diesen Titel zu verwenden. Die Ursprünge des Instruments liegen weit zurück. Die Forscher sagen bis zu 2000 Jahre, und die Aborigines sogar bis 40.000 Jahre.
Zitat: …Als das Traumzeitvolk die Erde verliess, hinterliess es den Menschen ein Geschenk: Ein Horn, das ein Klangfeld zwischen ihrer Welt und unserer erzeugt…\footcite{didgeridoo}
Beschreibung
Planung und Erstellung eines konfigurierbaren Web-Shops für Didgeridoo's.
Zweck und Inhalt
Zweck dieses Dokuments ist die vollständige und nachvollziehbare Dokumentation zu unserer Case Study Webtechnologie 3.
Aufbau
Alle Inhalte sind chronologisch sortiert, vom ältesten zum jüngsten Ereignis, und nach Kapiteln getrennt.
Lizenz
Dieses Dokument sowie der dazugehörige Code wurde von Ivan Hörler und Andreas Zweili im Rahmen einer Arbeit an der IBZ Schule erstellt und steht unter einer GPLv3\footcite{gplv3} Lizenz. Dadurch darf die Arbeit unter Einhaltung der Regeln der GPLv3 kopiert und weiterverarbeitet werden.
Projektanalyse und Planung
Projektziele
Der Student erarbeitet in einer Zweiergruppe einen selbst entwickelten Web-Shop. Die einzusetzenden Technologien sollen Open-Source sein. Die zur Verfügung stehende Zeit ist pro Student mit 80h zu veranschlagen. Am Ende dieser Zeitspanne soll ein funktionaler Web-Shop mit minimalem graphischen User Interface entstehen, die dazugehörige Dokumentation umfasst alle Aspekte um die gewählte Lösung nachzuvollziehen. Die Projekte wurden in der Tabelle: (tab:projektziele) zusätzlich noch nach Prioritäten gewichtet.
| Nr.\cellcolor[HTML]{C0C0C0} | Beschreibung\cellcolor[HTML]{C0C0C0} | Priorität\cellcolor[HTML]{C0C0C0} |
| 1. | Das Datenmodel muss korrekt konzipiert sein. | Hoch |
| 2. | Alle Vorgehen müssen in diesem Dokument erläutert werden. | Mittel |
| 3. | Die Arbeitsstunden müssen eingehalten werden. | Tief |
| 4. | Der Shop muss funktionstüchtig sein. | Mittel |
| 5. | Die Applikation muss vor der Übergabe vollständig getestet werden. | Hoch |
| 6. | Problemstellungen müssen ersichtlich dokumentiert werden. | Mittel |
| 7. | Die Punkte der Bewertung werden erfüllt. | Hoch |
Methoden
Die Methodik, die die Gruppe wählt, ist aufgrund der nur zwei Personen im Team beschränkt. Da jedoch Fehler und Rückschläge erwartet werden, ist eine iterative Methodik unabdingbar. Daher wandte die Gruppe eine angepasste Version von Scrum an. In dieser wird jeweils während Sitzungen die Position des Product Owners und des Scrum Masters eingenommen und die Backlog-Tasks dementsprechend erstellt, resp. verteilt. Während der Woche arbeiten beide Team-Mitglieder an der Arbeit als Team-Kollegen
Vorkenntnisse
Die benötigten Vorkenntnisse wurden in den vorangegangenen Semestern erarbeitet und sind in der Basis gefestigt. Diese Arbeit wird vorwiegend weiterführende Elemente wie Frameworks neu einbringen, deren Verhalten letztendlich nicht abgeschätzt werden kann.
Vision
Wir wollen einen Web-Shop mit geeigneter Software erstellen. Dabei setzen wir nur freie Software ein (frei, in Bezug auf Freiheit, nicht Preis). Wir untersuchen die Anforderung und wählen die uns als geeignet erscheinenden Frameworks. Jede noch so kleine Zeiteinsparung durch vorgefertigte Entwicklungen werden angenommen und dennoch wollen wir keine fertigen Software Produkte einsetzen.
Um einen ersten Anhaltspunkt zu haben, haben wir ein Mindmap gezeichnet in welchem wir unsere ersten Ideen erfassten. Zusehen ist dies in der Abbildung(fig:mindmap).
#+LATEX:≠wpage #+LATEX:\begin{landscape}
#+LATEX:\end{landscape}
#+LATEX:≠wpage
SWOT-Analyse
Die SWOT-Analyse ist eine Methode, die Stärken, Schwächen, Chancen und Gefahren zu erkennen, indem eine 4-Felder-Matrix ausgefüllt wird.
Wichtig vor dem Ausfüllen der SWOT-Analyse ist es, ein klares Ziel zu haben. Die ausgefüllte SWOT-Analyse für dieses Projekt ist in der Abbildung:(\ref{fig:swot}) zu sehen.
Umweltanalyse
Die Projektumwelt-Analyse ist eine Methode, die Beziehungen, Erwartungshaltungen und Einflüsse auf das Projekt durch interne und externe soziale Umwelten zu betrachten und zu bewerten. Auf Grundlage der Analyseergebnisse werden erforderliche Massnahmen zur Gestaltung der Umweltbeziehungen abgeleitet. Die Gestaltung der Projektumweltbeziehungen ist eine Projektmanagementaufgabe. In der Tabelle:(tab:umweltanalyse) wurden die Anforderungen und Wünsche mit Einschätzung der Wahrscheinlichkeit der Einflussnahme aufgenommen. Zusätzlich ist die Beziehung der Stakeholder zum Projekt noch in der Abbildung:(fig:umweltgrafik) grafisch dargestellt.
#+LATEX:≠wpage #+LATEX:\begin{landscape}
| Nr.\cellcolor[HTML]{C0C0C0} | Stakeholder\cellcolor[HTML]{C0C0C0} | Einfluss\cellcolor[HTML]{C0C0C0} | Anforderung/Wünsche\cellcolor[HTML]{C0C0C0} | Wahrscheinlichkeit\cellcolor[HTML]{C0C0C0} |
| 1. | Auftraggeber | hoch | - Innovatives Produkt auf dem Markt anbieten. | hoch |
| - Einhaltung von Terminen und Qualität. | hoch | |||
| 2. | Kunden | gering | - Einfache Lösung die anpassungsfähig ist. | hoch |
| - Schnell anfangen können. | hoch | |||
| - Viele Arbeitsschritte automatisieren | mittel | |||
| 3. | Interessenten | gering | - Intuitiv bedienbare Webseite | hoch |
| - schnell finden, was gesucht wird. | hoch | |||
| 4. | Projektleiter | hoch | - Gutes innovatives Produkt erschaffen. | mittel |
| - Anerkennung im fachlichen Umfeld | hoch |
#+LATEX:\end{landscape}
/ibz/web_AI-5/src/branch/master/docs/diagrammes/stakeholder_diagramm.eps
Risikomanagement
Risikobeschreibung
| Nr.\cellcolor[HTML]{C0C0C0} | Beschreibung\cellcolor[HTML]{C0C0C0} | Massnahmen\cellcolor[HTML]{C0C0C0} | W^1\cellcolor[HTML]{C0C0C0} | A^2\cellcolor[HTML]{C0C0C0} |
| 1. | Die Datenbank ist schlecht modelliert | Das ERM, nach dessen Erstellung, gründlich auf Fehler prüfen, falls nötig extern prüfen lassen. | 2 | 3 |
| 2. | Viel Arbeit an der Arbeitsstelle, dabei bleibt weniger Zeit für die Casestudy. | Die Zeit die einem zur Verfügung steht, nutzen und fixe Tage definieren. Projektplanung machen. | 1 | 2 |
| 3. | Know-How zur Umsetzung ist nicht vollständig vorhanden. | Gute Informationsbeschaffung im Internet, Mitschülern, Arbeitgebern, Dozenten etc. | 2 | 2 |
| 4. | Kommunikation innerhalb des Teams. | Klare Arbeitsaufteilung innerhalb des Teams und alle 2 Wochen Besprechungen über offene Aufgaben oder Problembehandlungen. | 1 | 1 |
| 5. | Die Programmierung des Shops benötigt zu viel Zeit. | Bei der Projektplanung genau definieren was die GUI Applikation beinhalten muss. Ziele definieren, Abgrenzungen treffen. | 3 | 1 |
Risikobewertung
| Bewertung | Beschreibung: Wahrscheinlichkeit (W) |
|---|---|
| 1 = gering | Unwahrscheinlich, <20% |
| 2 = mittel | Mässig wahrscheinlich, 20-50% |
| 3 = hoch | Hohe Wahrscheinlichkeit > 50% |
| Bewertung | Beschreibung: Auswirkung (A) |
|---|---|
| 1 = gering | Geringe Auswirkungen auf das Gesamtergebnis |
| 2 = mittel | Arbeitsumstellung oder grösserer Arbeitsaufwand |
| 3 = hoch | Projekt erfüllt nicht alle Anforderungen |
/ibz/web_AI-5/src/branch/master/docs/diagrammes/risk_analysis.eps
Projektabgrenzung
Der Webshop wird nur zum Teil aufgebaut. Funktionen wie die Bezahlung , das Versenden von Email Benachrichtigungen und einen automatisierte Aktualisierung der Warenbestände sind nicht Teil der Umsetzung. Aufgrund des hohen Mehraufwandes der für die Umsetzung nötig gewesen wäre, ist es zur Zeit nur möglich einen Artikel einem Bild zuzuweisen und nicht die Bilder direkt auf dem Aritkel hochzuladen.
Projektmanagement
Organigramm
Varianten
Wir haben uns 3 mögliche Varianten in Bezug auf die zu verwendende Software überlegt. Die Varianten wurden bewertet und die Variante mit den meisten Punkten dann schlussendlich ausgewählt. Bei jeder Variante wurden die gleichen Kriterien mit der gleichen Gewichtung bewertet. Die Punktzahl pro Kriterium wird nach der folgenden Formel berechnet:
\begin{equation} G * EP = KE \end{equation}Also die Gewichtung(G) multipliziert mit der erreichten Punktzahl(EP) ergibt das Kriteriumsergebnis(KE).
ASP.NET und SQL Server
ASP.NET und SQL Server, Tabelle:(tab:asp-net), haben vor allem viele Punkte verloren, da C# nur in Teilen und SQL Server gar nicht unter einer freien Lizenz steht. Des weiteren läuft .NET Core zwar auch auf Unix Systemen, allerdings ist das verhältnismässig ein relativ kleiner Teil der gesamten Sprache. SQL Server läuft hingegen nur unter Windows und Linux. Des weiteren ist es sehr schwierig C# Applikationen ohne Visual Studio zu entwickeln. Es geht in der Theorie, in der Praxis ist es jedoch eher umständlich. Die Vorkenntnisse wurden mit 6 von 10 Punkten bewertet, da wir C# zwar im Rahmen der Ausbildung lernen, allerdings noch nicht das Gefühl haben sonderlich gut mit C# umgehen zu können.
| Kriterium\cellcolor[HTML]{C0C0C0} | Gewichtung\cellcolor[HTML]{C0C0C0} | max. Punktzahl\cellcolor[HTML]{C0C0C0} | erreichte Punktzahl\cellcolor[HTML]{C0C0C0} | Kriteriums- ergebnis\cellcolor[HTML]{C0C0C0} |
| Freie Software | 5 | 10 | 5 | 25 |
| Cross Plattform nutzbar | 5 | 10 | 6 | 30 |
| Lesbarkeit des Codes | 5 | 5 | 4 | 20 |
| Einfachheit des Setups | 3 | 5 | 5 | 15 |
| Ohne spezielle Tools nutzbar | 3 | 5 | 1 | 3 |
| Vorkenntnisse | 3 | 10 | 6 | 18 |
| Lernfaktor | 5 | 10 | 6 | 30 |
| Total | 141 |
PHP und MySQL
Die Variante PHP und MySQL, Tabelle:(tab:php), hat insgesamt eine sehr gute Bewertung erhalten. Beide Projekte sind zumindest teilweise unter einer freien Lizenz verfügbar und sind sowohl unter Windows, wie auch Mac und Linux einsetzbar. Allerdings gibt es von MySQL noch eine proprietäre Enterprise Variante, weshalb wir hier nicht die volle Punktzahl vergeben konnten. Abstriche gab es bei der Lesbarkeit des Codes. Da PHP insgesamt eine ziemlich inkonsistente und ausschweifende Sprache ist. Dafür ist das Setup sehr einfach und man kann eine PHP basierte Applikation ohne spezielle Werkzeuge entwickeln. Da wir jedoch bereits sehr intensiv mit PHP und MySQL in Berührung kamen, haben wir beim Lernfaktor Abstriche gemacht. In Zusammenhang mit einem Framework hätten wir sicher auch viel dazugelernt. Im Vergleich zu den anderen Varianten jedoch auf jeden Fall weniger.
| Kriterium\cellcolor[HTML]{C0C0C0} | Gewichtung\cellcolor[HTML]{C0C0C0} | max. Punktzahl\cellcolor[HTML]{C0C0C0} | erreichte Punktzahl\cellcolor[HTML]{C0C0C0} | Kriteriums- ergebnis\cellcolor[HTML]{C0C0C0} |
| Freie Software | 5 | 10 | 8 | 40 |
| Cross Plattform nutzbar | 5 | 10 | 8 | 40 |
| Lesbarkeit des Codes | 5 | 5 | 2 | 10 |
| Einfachheit des Setups | 3 | 5 | 5 | 15 |
| Ohne spezielle Tools nutzbar | 3 | 5 | 5 | 15 |
| Vorkenntnisse | 3 | 10 | 7 | 21 |
| Lernfaktor | 5 | 10 | 4 | 20 |
| Total | 161 |
Django(Python) und MariaDB
Diese Variante, Tabelle:(tab:django), hat am meisten Punkte erhalten. Wie bei der Variante "PHP und MySQL" sind auch hier beide Komponenten freie Software. Im Gegensatz zu der vorherigen Variante gibt es bei diesen Komponenten nur eine mögliche Lizenzform. Womit sie die volle Punktzahl in dieser Kategorie erreichten.
Beide Projekte laufen unter Windows, Linux sowie Mac. Wobei das Setup für Django(Python) unter Windows etwas komplizierter ausfällt als wir gerne hätten, weshalb wir hier bei der Cross Plattform Kompatibilität und dem Setup einen Abstrich gemacht haben. Python kann ohne spezielle Tools programmiert werden und gilt als eine der Sprachen mit der leserlichsten Syntax. Die Vorkenntnisse haben wir hier als eher niedrig eingestuft dafür den Lernfaktor umso höher.
| Kriterium\cellcolor[HTML]{C0C0C0} | Gewichtung\cellcolor[HTML]{C0C0C0} | max. Punktzahl\cellcolor[HTML]{C0C0C0} | erreichte Punktzahl\cellcolor[HTML]{C0C0C0} | Kriteriums- ergebnis\cellcolor[HTML]{C0C0C0} |
| Freie Software | 5 | 10 | 10 | 50 |
| Cross Plattform nutzbar | 5 | 10 | 9 | 45 |
| Lesbarkeit des Codes | 5 | 5 | 5 | 25 |
| Einfachheit des Setups | 3 | 5 | 3 | 9 |
| Ohne spezielle Tools nutzbar | 3 | 5 | 5 | 15 |
| Vorkenntnisse | 3 | 10 | 4 | 12 |
| Lernfaktor | 5 | 10 | 8 | 40 |
| Total | 196 |
Ergebnis
Aufgrund der erreichten Punktzahl, Tabelle:(tab:result), bei den vorhergehenden Variantenbewertungen, haben wir uns dafür entschieden, die Variante "Django(Python) und MariaDB" umzusetzen. In der Sektion /ibz/web_AI-5/src/branch/master/docs/Werkzeuge beschreiben wir noch die weiteren Mittel, welche beim Erstellen der Case Study verwendet wurden und erklären, wenn möglich auch, weshalb wir uns dafür entschieden haben.
| Variante\cellcolor[HTML]{C0C0C0} | Erreichte Punktzahl\cellcolor[HTML]{C0C0C0} |
| ASP.NET und SQL Server | 141 |
| PHP und MySQL | 161 |
| Django und MariaDB | 196 |
#+LATEX:≠wpage #+LATEX:\begin{landscape}
Zeitplanung
In der Tabelle:(tab:time) ist die Zeitplanung für das Projekt zu sehen. Die einzelnen Phasen wurden dabei gegenüber ihren Subtasks hervorgehoben.
| ID\cellcolor[HTML]{C0C0C0} | Subject\cellcolor[HTML]{C0C0C0} | Type\cellcolor[HTML]{C0C0C0} | Status\cellcolor[HTML]{C0C0C0} | Estimated time\cellcolor[HTML]{C0C0C0} | Spent time\cellcolor[HTML]{C0C0C0} |
| 201 | Projektanalyse und Planung | Phase | Closed | ||
| 202 | Projektziele | Task | Closed | 1 | 0.5 |
| 203 | Vision | Task | Closed | 1 | 0.5 |
| 204 | SWOT-Analyse | Task | Closed | 3 | 0.5 |
| 205 | Umweltanalyse | Task | Closed | 3 | 1.5 |
| 206 | Risikomanagement | Task | Closed | 2 | 2.5 |
| 207 | Projektabgrenzung | Task | Closed | 2 | 2 |
| 259 | Meeting 1 | Milestone | Closed | 3 | 6 |
| 200 | Kickoff | Milestone | Closed | 4 | 8 |
| 301 | Meeting 2 | Milestone | Closed | 3 | 3 |
| 306 | Meeting 3 | Milestone | Closed | 1.5 | 3 |
| 313 | Meeting 4 | Milestone | Closed | 1 | 1 |
| 314 | Meeting 5 | Milestone | Closed | 1 | 1 |
| 208 | Projektmanagement | Phase | Closed | ||
| 218 | Architektur vorbereiten | Phase | Closed | ||
| 219 | Architektur Grafik | Task | Rejected | 6 | 0 |
| 220 | Use Case Grafiken | Task | Closed | 6 | 3 |
| 221 | User Stories | Task | Closed | 1 | 1 |
| 310 | Use Case Beschreibungen | Task | Closed | 10 | 9 |
| 254 | Test Cases benennen | Task | Closed | 10 | 10 |
| 222 | Organigramm | Task | Closed | 0.5 | 0.5 |
| 223 | Projektstrukturplan | Task | Closed | 1.5 | 1.5 |
| 224 | Arbeitspakete definieren | Task | Closed | 4 | 1 |
| 225 | Datenbank | Phase | Closed | ||
| 226 | Anforderungsanalyse | Task | Closed | 0.5 | 0 |
| 227 | Relationen Model | Task | Closed | 2 | 0.5 |
| 228 | Relationen Diagramm | Task | Closed | 4 | 5.25 |
| 229 | SQL Create DB | Task | Closed | 0.5 | 0.5 |
| 230 | SQL Insert Testdaten | Task | Closed | 10 | 7 |
| 231 | SQL Restriktionen erarbeiten | Task | Rejected | 0.5 | 0.1 |
| 232 | SQL Views erstellen | Task | Rejected | 2 | 0.1 |
| 233 | SQL Prozeduren und Funktionen erarbeiten | Task | Rejected | 2 | 0.1 |
| 304 | SQL Create Tables | Task | Rejected | 2 | 0.1 |
| 234 | Benutzerinterface | Phase | Closed | ||
| 235 | Mockup skizzieren | Task | Closed | 1 | 1 |
| 236 | Frontend Umsetzung | Phase | Closed | ||
| 237 | Login | Task | Closed | 0.5 | 2.75 |
| 315 | BUG: Eine zu lange Strassenummer wirf einen Fehler | Task | Closed | 0.5 | 0.25 |
| 238 | Artikel | Task | Closed | 0.25 | |
| 312 | BUG, Preise können negativ sein. | Task | Closed | 0.25 | |
| 239 | Artikelliste | Task | Closed | 5 | 5 |
| 240 | Warenkorb | Task | Closed | 5 | 12 |
| 241 | Checkout | Task | Closed | 5 | 5 |
| 242 | Backend Umsetzung | Phase | Closed | ||
| 243 | Login | Task | Closed | 5 | 5 |
| 244 | Artikel | Task | Closed | 5 | 1 |
| 247 | Artikelliste | Task | Closed | 2.5 | 0.5 |
| 302 | Artikel Erstellung | Task | Closed | 2.5 | 0.5 |
| 245 | Kategorien | Task | Closed | 5 | 1 |
| 248 | Kategorie Liste | Task | Closed | 2.5 | 0.5 |
| 303 | Kategorie erstellen | Task | Closed | 2.5 | 0.5 |
| 246 | Artikel Attributte | Task | Closed | 4 | 1.5 |
| 249 | Atributt Liste | Task | Rejected | 1 | 0 |
| 305 | Bilder hochladen | Task | Closed | 3 | 1.5 |
| 250 | Kunden Liste | Task | Closed | 1 | 0.5 |
| 308 | Models | Task | Closed | 3 | 5 |
| 309 | Währungskurse | Task | Closed | 5 | 18 |
| 252 | Testing | Phase | Closed | ||
| 255 | Test Cases Durchführung | Task | Closed | 10 | 10 |
| 257 | Dokumentations Styling | Task | Closed | 2 | 2.5 |
| 258 | Präsentation | Milestone | In progress | 2 | 0 |
| 263 | Vorprojekt | Task | Closed | 28.25 | 35.5 |
| 209 | Tools vorbereiten | Phase | Closed | ||
| 210 | GIT-Workspace | Task | Closed | 0.5 | 0.5 |
| 211 | Development Container | Task | Closed | 2 | 7.25 |
| 261 | Domain reservieren | Task | Closed | 0.25 | 0.25 |
| 262 | Produktions Server aufsetzen | Task | Closed | 2 | 4 |
| 212 | Technologien abklären | Phase | Closed | ||
| 213 | C# | Task | Closed | 1 | 1 |
| 214 | Django | Task | Closed | 5 | 5 |
| 215 | MariaDB | Task | Closed | 0.5 | 0.5 |
| 216 | SQL Server | Task | Closed | 1 | 1 |
| 217 | Laravel | Task | Closed | 5 | 5 |
| 316 | MySQL | Task | Closed | 1 | 1 |
| 264 | Architektur Tests | Task | Closed | 6 | 6 |
| 307 | Machbarkeitsanalyse | Task | Closed | 2 | 2 |
| 251 | Varianten Erarbeiten | Task | Closed | 2 | 2 |
| 265 | Abgabetermin | Milestone | Scheduled | 0.5 | 0 |
| 266 | Zwischenbericht ablieferen | Task | Closed | 0.5 | 0 |
| Total | 218.50 | 214.65 |
#+LATEX:\end{landscape}
Umsetzung
Werkzeuge
Während dem Erstellen dieser Arbeit wurde eine Vielzahl an Werkzeugen eingesetzt. Nachfolgend werden diese Werkzeuge kurz beschrieben sowie ihre Verwendung begründet. Wir haben dabei darauf geachtet soviel Open-Source Software wie möglich zu verwenden. Nicht nur für den Web-Shop an sich sondern generell für alle Tasks im Projekt.
Versionskontrolle
Eine Versionskontrollsoftware erschien uns als notwendig, um den Code auf einfache und zuverlässige Weise untereinander austauschen zu können. Andere Lösungen wie Dropbox, etc. hätten es uns nicht erlaubt Konflikte zu vermeiden.
Als Software für die Versionskontrolle wurde Git \footcite{git} gewählt. Git wurde aus diversen Gründen gewählt:
- Ist der de facto Standard bei Versionskontrollsoftware
- Läuft auf allen gängigen Betriebssystemen
- Es gäbe gratis Services die man nutzen könnte (Github, Gitlab)
- Man kann offline arbeiten und Commits erstellen
- Das Team hat bereits einen eigenen Git Server zur Verfügung
- Das Team ist bereits mit Git aus vorhergehenden Projekten vertraut, dadurch muss man keine Ressourcen aufwenden eine neue Software zu lernen. Zusätzlich hat sich Git in den vorhergehenden Projekten als robuste und schnelle Software erwiesen.
- Git ist freie Software unter GNU Public License v2.
Entwicklungsumgebung
Damit beide Studenten auf der gleichen Basis arbeiten, haben wir uns dazu entschieden, den Web-Shop in einer virtuellen Maschine zu entwickeln. Dies führt jedoch in der Regel zum Problem, dass die Änderungen in der virtuellen Maschine miteinander abgesprochen und ausgetauscht werden müssen. Um dieses Problem zu beheben, haben wir uns dazu entschieden Vagrant\footcite{vagrant} zu verwenden. Vagrant ist freie Software unter der MIT Lizenz.
Vagrant erlaubt es einem den Zustand einer virtuellen Maschine in einer Text Datei zu beschreiben und diese dann gemäss der Beschreibung automatisiert aufzusetzen. Dies hat den Vorteil, dass die Konfiguration der virtuellen Maschine auch ohne Weiteres mit dem restlichen Code in der Versionskontrollsoftware gepflegt werden kann.
Des weiteren hilft das automatisierte Aufsetzen, das Vermeiden von menschlichen Fehlern. Somit kann davon ausgegangen werden, dass das System in der virtuellen Maschine immer den korrekten Stand zum Entwickeln hat. Sollte dies nicht mehr der Fall sein, lässt sich die virtuelle Maschine mit einem, maximal zwei Befehlen wieder in den Ursprungszustand zurücksetzen.
Als Hypervisor der virtuellen Maschine wurde Virtualbox\footcite{virtualbox} eingesetzt. Virtualbox ist im Kern freie Software unter der GNU Public License v2. Das unter einer proprietären Lizenz erhältliche Erweiterungspaket ist für unser Setup nicht notwendig.
Hostsystem
Als Hostsystem für unseren Web-Shop haben wir die Linux Distribution Debian\footcite{debian} in der Version 9 (Stretch) gewählt. Für Debian haben wir uns vor allem aus folgenden Gründen entschieden:
- Stabiles Betriebsystem
- Sehr guter Paketmanager, was einem das Scripting vereinfacht
- Gilt als sehr sicher
- Hat sich in vorhergehenden Projekten bereits als gute Basis bewiesen
- Enthält in der Grundkonfiguration nur freie Software (nicht freie Software muss aktiv hinzugefügt werden)
- In der Linux Welt sehr verbreitet
- Im Gegensatz zu Ubuntu nicht von einer Firma abhängig
Deployment Software für Produktionsserver
Auch auf dem produktiven Server haben wir uns für Debian entschieden. Um diesen aufzusetzen, hatten wir in etwa die ähnlichen Anforderungen wie für die Entwicklungsumgebung. Also einen Weg um das System möglichst automatisch und reproduzierbar aufzusetzen. Die für die Entwicklungsumgebung verwendete Software Vagrant ist für produktive Systeme allerdings eher weniger geeignet.
Für solche Fälle bietet sich eine Software Namens "Ansible"\footcite{ansible} an. Diese bietet einem, ähnlich wie Vagrant, die Möglichkeit, den Zustand eines Systems in Textdateien zu beschreiben. Allerdings bietet einem Ansible noch zusätzliche Möglichkeiten und vor allem ein standardisiertes Interface, um unterschiedliche Systeme auf dieselbe Weise zu konfigurieren.
Der Vorteil gegenüber anderen System ist, dass Ansible mit sehr wenig Abhängigkeiten für das zu konfigurierende System daherkommt. Auf einem Linux System ist nur SSH Zugriff und Python notwendig. Einen Client braucht man nicht zu installieren. Ansible ist freie Software unter der GNU Public License v3.
Framework
Um die Entwicklung der Applikation zu vereinfachen, haben wir uns dazu entschlossen ein Framework einzusetzen. Frameworks bringen einem in der Entwicklung diverse Vorteile. Unter anderem bieten sie Hilfen bei sich wiederholenden Programmieraufgaben und bieten je nachdem die Möglichkeit, die Applikation in einer einzigen Sprache zu schreiben, da sich das Framework auch um die Datenbank kümmert. In der Webentwicklung helfen sie einem insbesondere auch dabei Sicherheitslücken wie Cross Site Scripting und SQL Injections abzufangen.
Wir haben uns dabei für das Framework Django\footcite{django} entschieden. Django ist ein Python basiertest Framework. Django ist freie Software unter der drei Klauseln BSD Lizenz. Wir haben uns aus folgenden Gründen für ein Python basiertes Framework gegenüber einem PHP basierten Framework entschieden:
- Python gilt als die Sprache mit der schöneren Syntax.
- Wir wollten im Bezug auf das Programmieren etwas Neues ausprobieren was sich im Rahmen einer Case Study sehr gut machen lässt, da man ein "realistisches" Szenarium erhält und dieses in einem relativ kontrollierten Rahmen ausführen kann.
- Python ist in dem von uns gewählten Hostsystem wie in den meisten Linux Distributionen bereits integriert.
- Des weiteren hat Django bei einer Variantenbewertung das beste Ergebnis geholt.
Die verwendete Version war dabei 1.10.7-2 aus dem Debian Stretch Repository.
Webserver
Als Webserver verwenden wir ganz klassisch Apache\footcite{apache}. Dies vor allem desswegen weil wir Apache aus diversen vorhergehenden Projekten bereits sehr gut kennen und sich der Webserver dort sehr gut bewährt hat. Apache wird dabei auch noch gut von Django unterstützt. Der Apache Webserver ist freie Software unter der Apache License 2.0 und gehört der gemeinnützigen Organisation "Apache Foundation".
Datenbank
Bei der Datenbank haben wir uns für MariaDB\footcite{mariadb} entschieden. Auch hier hauptsächlich weil wir MariaDB bereits aus vorhergehenden Projekt kennen. MariaDB ist ein Fork von MySQL welcher gegenüber MySQL rückwärts kompatibel ist. MariaDB ist dabei jedoch viel Community näher als MySQL und wird dabei auch sehr demokratisch entwickelt\footcite{mariadbgov}. MariaDB gehört dabei keiner einzelnen Firma oder Person sondern der gemeinnützigen Organisation "MariaDB Foundation". Was für zusätzliche Stabilität sorgen sollte. MariaDB ist freie Software unter GNU Public License v2. Des weiteren hat MariaDB bei einer Variantenbewertung das beste Ergebnis geholt.
Editoren
Das Hauptwerkzeug von jedem Entwickler ist sein Text Editor. Dabei hat jeder meistens seine ganz eigene Präferenzen, wenn es um die Wahl des Editors geht.
- Atom
- Ivan hat während der Case Study hauptsächlich mit Atom\footcite{atom} gearbeitet. Atom wird von Github Inc. entwickelt und basiert auf dem Electron Framework, welches seinerseits auf Webtechnologien wie Node.js und Chromium basiert. Atom ist freie Software unter der MIT Lizenz.
- GNU Emacs
- Andreas arbeitet hauptsächlich mit dem Editor GNU Emacs\footcite{emacs}. GNU Emacs ist mit 32 Jahren (obwohl seine Wurzeln bis ins Jahre 1976 zurückgehen) wohl eines der ältesten noch "aktiven" Software Projekte. Emacs ist freie Software unter der GNU Public License v3.
Dokumentation
Diese Dokumentation wurde in Org-mode\footcite{orgmode}, einer Erweiterung für den Text Editor Emacs, geschrieben. Anschliessend wurde die Dokumentation in LaTeX\footcite{latex} Code konvertiert und finalisiert. Der Zwischenschritt über Org-mode wurde gewählt, weil Org-mode etwas einfacher zu schreiben ist als reines LaTeX.
LaTeX ist eine Software, welche einem die Benutzung des Textsatzsystems TeXs vereinfacht. Wir haben LaTeX gegenüber einem "What You See Is What You Get", Editor gewählt weil es einem mit seiner Markup Sprache erlaubt das Dokument in Text Dateien zu erstellen, was wir als Programmierer sehr angenehm finden. Dadurch, dass LaTeX auch nur aus reinen Textdateien besteht, kann man die Dokumente auch ohne weiteres in die Versionskontrollsoftware einchecken und somit auf einfache Weise zusammen daran arbeiten und die Entwicklung im Log zurückverfolgen. LaTeX ist freie Software unter der LaTeX Project Public License.
Die Grafiken in diesem Dokument wurden hauptsächlich mit dem Vektor Grafik Editor Inkscape\footcite{inkscape} erstellt. Inkscape ist freie Software unter der GNU Public License v3. Für das Entity Relation Diagramm in /ibz/web_AI-5/src/branch/master/docs/Models haben wir jedoch Dia\footcite{dia} verwendet. Dia ist freie Software unter der GNU Public License v2.
Die Klassendiagramme haben wir mit der Django Erweiterung "Django-Extensions"\footcite{djangoextensions} erstellt. Django-Extensions ist freie Software unter der MIT Lizenz.
Spezifikation
User Stories
User Stories sind in Alltagssprache geschriebene Software-Anforderungen. Sie sind bewusst kurz gehalten und beschreiben die Wünsche und Ziele der Rollen, welche die Software verwenden.\footcite{userstory}
Auftraggeber/Verwaltung
Als Anbieter möchte ich…
- Artikel in Kategorien strukturieren, damit Kunden sich orientieren können.
- Bilder zu meinen Artikeln hinzufügen, damit sich Kunden das Produkt anschauen können.
- Artikel aktiv oder versteckt schalten können, damit ich Produkte auch temporär aus dem Verkauf nehmen kann.
- Lagerbestände verwalten können, damit ich rechtzeitig nachbestellen kann.
- Nachbestellungen von Artikeln erfassen können, damit ich weiss, was bestellt wurde.
- eine komplette Liste meiner Artikel einsehen können, damit ich einen Überblick über meine Produkte habe.
- eine Liste aller Bestellungen einsehen können, um allenfalls Anpassungen vornehmen zu können.
- Produkte und Kategorien in einer Admin Seite editieren können, um diese einfach administrieren zu können.
Kunde
Als Kunde möchte ich…
- durch Kategorien zu den Produkten navigieren um diese einfacher zu finden.
- Artikel einem Warenkorb hinzufügen können, damit ich ungestört stöbern kann und erst am Schluss den administrativen Teil erledigen muss.
- meinen Warenkorb anzeigen und editieren können um allenfalls Korrekturen vornehmen zu können.
- die Artikel in meinem Warenkorb bestellen können.
- vor dem Abschluss des Kaufs eine Zusammenstellung der Bestellung einsehen um die Richtigkeit der Daten zu überprüfen.
- mich registrieren können, damit ich meine Adresse nicht jedes Mal neu eingeben muss.
- in einem Bereich der Webseite meine Profildaten zur Überprüfung einsehen können.
- Artikel in meiner bevorzugten Währung kaufen können, damit ich die Preise nicht umrechnen muss.
Interessenten
Als Interessent möchte ich…
- die angebotenen Artikel einsehen können um mir ein Bild über das Angebot machen zu können.
- die Preise in einer anderen Währung anzeigen können um die Preise in einer mir bekannten Währung vergleichen zu können.
Use Cases
Ein Use Case sammelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes Ziel zu erreichen. Dabei beschreibt er, was beim Versuch der Zielerreichung passieren kann. Je nach Ablauf kann auch ein Fehlschlag ein Ergebnis eines Anwendungsfalls sein (e.g. falsches Passwort beim Login). Dabei wird die technische Lösung nicht konkret beschrieben. Die Detailstufe kann dabei sehr unterschiedlich sein.\footcite{usecase}
Anwendungsfalldiagramm
"Ein Anwendungsfalldiagramm … ist eine der 14 Diagrammarten der Unified Modelling Language (UML), einer Sprache für die Modellierung der Strukturen und des Verhaltens von Software- und anderen Systemen. Es stellt Anwendungsfälle und Akteure mit ihren jeweiligen Abhängigkeiten und Beziehungen dar."\footcite{usecasediagramm}
Das Anwendungsfalldiagramm für unseren Webshop ist in der Abbildung: (fig:usecase) zu sehen. Wir haben uns dabei auf die Hauptaspekte des Webshops beschränkt.
#+LATEX:≠wpage #+LATEX:\begin{landscape}
/ibz/web_AI-5/src/branch/master/docs/diagrammes/use_case.eps #+LATEX:\end{landscape} #+LATEX:≠wpage
Use Cases Detailbeschreibung
Use Cases werden in der Regel mit Hilfe einer sogenannten Use Case Schablone im Detail beschrieben, damit klar ist, wie der Ablauf jeweils genau aussieht. Die von uns verwendete Schablone wurde von Alistair Cockburn definiert.
Da ein Web-Shop eine sehr umfangreiche Applikation ist, gibt es sehr viele Use Cases, welche beschrieben und umgesetzt werden müssen. Aus zeitlichen Gründen haben wir nur einen kleinen Teil der Use Cases im Detail ausgearbeitet. Insbesondere diese, welche wir selber ausprogrammiert haben. Die gesamte Liste an Use Cases sieht wie folgt aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
| - 1.0 Artikel durchstöbern | - Kategorie erfassen (Admin Funktion) |
| - 2.0 Registration | - Kategorie ändern (Admin Funktion) |
| - 2.1 User Login | - Kategorie löschen (Admin Funktion) |
| - User Profil ansehen | - Bild hochladen (Admin Funktion) |
| - 3.0 Artikel in Warenkorb legen | - Bild ändern (Admin Funktion) |
| - 3.1 Währung ändern | - Bild löschen (Admin Funktion) |
| - Währung aktualisieren (Admin Funktion) | - Bestellung erfassen (Admin Funktion) |
| - 3.2 Checkout | - 7.0 Bestellung ändern/korrigieren (Admin Funktion) |
| - 4.0 User Passwort ändern (Admin Funktion) | - Bestellung löschen (Admin Funktion) |
| - 5.0 Artikel erfassen (Admin Funktion) | - 6.0 max_pictures Option anpassen (Admin Funktion) |
| - 5.1 Artikel ändern (Admin Funktion) | - max_pictures Option deaktivieren (Admin Funktion) |
| - Artikel löschen (Admin Funktion) | - User erfassen (Admin Funktion) |
| - Materialbestellung erfassen (Admin Funktion) | - User/Personen Daten ändern (Admin Funktion) |
| - Materialbestellung ändern/korrigieren (Admin Funktion) | - User löschen (Admin Funktion) |
| - Materialbestellung löschen (Admin Funktion) | - User Berechtigungen anpassen (Admin Funktion) |
| - Stadt hinzufügen (Admin Funktion) | |
| - Stadt ändern (Admin Funktion) | |
| - Stadt löschen (Admin Funktion) |
#+LATEX:}
#+latex:≠wpage 1.0 Artikel durchstöbern
#+LATEX:{\footnotesize
#+ATTR_LATEX::environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
| Identifier + Name | 1.0 Artikel durchstöbern |
| Description | Durchklicken der verschiedenen Kategorien und ansehen der Artikel, Details und Bilder. |
| Actors | Kunden, Interessenten |
| Status | Freigegeben |
| Includes | - |
| Trigger | User möchte Artikel einsehen |
| Preconditions | Website aufgerufen |
| Postconditions | - |
| Normal Flow | 1. Website aufrufen |
| 2. Kategorien durchsehen | |
| 3. Artikel anklicken | |
| Alternative Flow | - |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
2.0 Registration
#+LATEX:{\footnotesize
| Identifier + Name | 2.0 Registration |
| Description | Ein User registriert sich einen Account. |
| Actors | Interessent |
| Status | Freigegeben |
| Includes | - |
| Trigger | User möchte einen Account erstellen. |
| Preconditions | Email Adresse vorhanden |
| Postconditions | Account wurde erfolgreich erstellt. |
| Normal Flow | 1. User klickt auf den Link "Go to registration.". |
| 2. User füllt das Registrations Formular aus. | |
| 3. User schliesst die Registrierung mit Klick auf "Register" ab. | |
| 4. Die Website leitet ihn in den Login Bereich um. | |
| Alternative Flow | 1. User klickt auf den Link "Go to registration.". |
| 2. User füllt das Registrationsformular mir falschen Daten aus. | |
| 3. Die Website gibt die entsprechenden Fehler aus. | |
| 4. Der User korrigiert die Angaben. | |
| 5. User schliesst die Registrierung mit Klick auf "Register" ab. | |
| 6. Die Website leitet ihn in den Login Bereich um. | |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
2.1 User Login
#+LATEX:{\footnotesize
| Identifier + Name | 2.1 User Login |
| Description | Ein Kunde logt sich auf der Website ein. |
| Actors | Kunde |
| Status | Freigeben |
| Includes | - |
| Trigger | Ein Kunde möchte sich einloggen. |
| Preconditions | UC 2.0 erfolgreich abgeschlossen. |
| Postconditions | User hat sich erfolgreich eingeloggt. |
| Normal Flow | 1. User klickt in der Navigation auf "Login". |
| 2. User gibt Zugangsdaten ein. | |
| 3. User beendet Login mit Klick auf "Login". | |
| 4. Die Website leitet ihn auf die Index Seite um und zeigt neu eine "Profil" und "Logout" Schaltfläche. | |
| Alternative Flow | 1. User klickt in der Navigation auf "Login". |
| 2. User gibt falsche Zugangsdaten ein. | |
| 3. User beendet Login mit Klick auf "Login". | |
| 4. Die Website gibt entsprechende Fehlermeldungen aus. | |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
3.0 Artikel in Warenkorb legen
#+LATEX:{\footnotesize
| Identifier + Name | 3.0 Artikel in Warenkorb legen |
| Description | Ein Kunde legt einen Artikel in den Warenkorb. |
| Actors | Kunde |
| Status | Freigeben |
| Includes | - |
| Trigger | Ein Kunde möchte einen Artikel kaufen. |
| Preconditions | UC2.1 erfolgreich abgeschlossen. |
| Postconditions | Artikel wurde im Warenkorb gespeichert. |
| Normal Flow | 1. User klickt einen Artikel an. |
| 2. User klickt auf "Add to cart". | |
| 3. Die Website speichert den Artikel im Warenkorb. | |
| Alternative Flow | 1. User klickt einen Artikel mit Stock "0.0" an. |
| 2. User klickt auf "Add to cart". | |
| 3. Die Website meldet "We are sorry but this item is out of stock.". | |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
3.1 Währung ändern
#+LATEX:{\footnotesize
| Identifier + Name | 3.1 Währung ändern |
| Description | Ein User ändert die Währung für die Preise. |
| Actors | Kunde, Interessent |
| Status | Freigeben |
| Includes | - |
| Trigger | Ein User möchte sich die Preise in einer anderen Währung anzeigen lassen. |
| Preconditions | - |
| Postconditions | Die Preise werden in der gewünschten Währung angezeigt. |
| Normal Flow | 1. Der User wählt im Drop-Down die gewünschte Währung aus. |
| 2. Die Website aktualisiert und zeigt die neu berechneten Preise an. | |
| Alternative Flow | - |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
3.2 Checkout
#+LATEX:{\footnotesize
| Identifier + Name | 3.2 Checkout |
| Description | User gibt seinen Warenkorb als Bestellung auf. |
| Actors | Kunde |
| Status | Freigeben |
| Includes | - |
| Trigger | Ein Kunde möchte seine Artikel im Warenkorb bestellen. |
| Preconditions | UC2.1 und UC3.0 erfolgreich abgeschlossen. |
| Postconditions | Die Bestellung wurde von der Website gespeichert. |
| Normal Flow | 1. Der User klickt in der Navigation auf "Cart". |
| 2. Die Website leitet ihn zum Warenkorb um. | |
| 3. Der User klickt dort auf "Checkout". | |
| 4. Die Website gibt ihm eine komplette Übersicht der Bestellung sowie der Empfängeradresse. | |
| 5. User klickt auf "Send order". | |
| Alternative Flow | 1. Der User klickt in der Navigation auf "Cart". |
| 2. Die Website leitet ihn zum Warenkorb um. | |
| 3. Der User klickt dort auf "Checkout". | |
| 4. Die Website gibt ihm eine komplette Übersicht der Bestellung sowie der Empfängeradresse. | |
| 5. Der User bricht die Bestellung mit Klick auf "Cancel" ab. | |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
4.0 User Passwort ändern
#+LATEX:{\footnotesize
| Identifier + Name | 4.0 User Passwort ändern |
| Description | Ein Administrator ändert ein User Kennwort. |
| Actors | Verwaltung |
| Status | Freigeben |
| Includes | - |
| Trigger | Ein Administrator möchte ein Passwort zurücksetzen, weil es vergessen wurde. |
| Preconditions | Account mit Administrationsrechten vorhanden. |
| Postconditions | Auf dem User Account wurde ein neues Passwort gesetzt. |
| Normal Flow | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| 2. Admin klickt auf "Users". | |
| 3. Admin wählt den passenden Account aus. | |
| 4. Klickt unterhalb des Passwort Hashes auf "this form". | |
| 5. Gibt zweimal das neue Passwort ein und klickt "Change password". | |
| 6. Die Website leitet den Admin zurück zu den User Details. | |
| Alternative Flow | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| 2. Admin klickt auf "Users". | |
| 3. Admin wählt den passenden Account aus. | |
| 4. Klickt unterhalb des Passwort Hashes auf "this form". | |
| 5. Gibt zweimal ein invalides Passwort ein und klickt "Change password". | |
| 6. Die Website gibt eine entsprechende Fehlermeldung aus. | |
| 7. Der Admin korrigiert die Passwörter und klickt auf "Change password". | |
| 8. Die Website leitet den Admin zurück zu den User Details. | |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
5.0 Artikel erfassen
#+LATEX:{\footnotesize
| Identifier + Name | 5.0 Artikel erfassen |
| Description | Ein Administrator erfasst einen neuen Artikel mit Bildern. |
| Actors | Verwaltung |
| Status | Freigeben |
| Includes | - |
| Trigger | Um das Sortiment zu erweitern, möchte der Administrator einen neuen Artikel erfassen. |
| Preconditions | Account mit Administrationsrechten vorhanden. |
| Postconditions | Der Artikel wird im Webshop angezeigt. |
| Normal Flow | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| 2. Admin klickt neben "Articles" auf "+ Add". | |
| 3. Admin füllt das Formular aus und lädt ein Bild hoch. | |
| 4. Klickt unten rechts auf "Save". | |
| 5. Die Website speichert den Artikel in der Datenbank. | |
| Alternative Flow | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| 2. Admin klickt neben "Articles" auf "+ Add". | |
| 3. Admin füllt das Formular aus und lädt zu viele Bilder hoch. | |
| 4. Klickt unten rechts auf "Save". | |
| 5. Die Website gibt eine entsprechende Fehlermeldung aus. | |
| 6. Der Admin entfernt die überzähligen Bilder. | |
| 7. Die Website speichert den Artikel in der Datenbank. | |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| 1.1 AZ Rechtschreibung korrigiert | |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
5.1 Artikel ändern
#+LATEX:{\footnotesize
| Identifier + Name | 5.1 Artikel ändern |
| Description | Ein Administrator ändert den Status eines Artikels. |
| Actors | Verwaltung |
| Status | Freigeben |
| Includes | - |
| Trigger | Ein Artikel wird vorübergehend aus dem Sortiment genommen. |
| Preconditions | Account mit Administrationsrechten vorhanden. |
| Postconditions | Der Artikel wird im Webshop nicht mehr angezeigt. |
| Normal Flow | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| 2. Admin wählte in der Kategorie Articles einen "Artikel" aus. | |
| 3. Der Admin ändert den Artikel Status von "active" auf "hidden". | |
| 4. Klickt unten rechts auf "Save". | |
| 5. Die Website speichert den Artikel in der Datenbank. | |
| Alternative Flow | - |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 18.02.2018 |
#+LATEX:}
6.0 max_pictures Option anpassen
#+LATEX:{\footnotesize
| Identifier + Name | 6.0 max_pictures Option anpassen |
| Description | Ein Administrator ändert die max_pictures Option. |
| Actors | Verwaltung |
| Status | Freigeben |
| Includes | - |
| Trigger | Ein Administrator möchte die maximale Anzahl Bilder pro Artikel anpassen. |
| Preconditions | Account mit Administrationsrechten vorhanden. |
| Postconditions | Der neue Wert wurde von der Website gespeichert. |
| Normal Flow | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| 2. Admin klickt auf "Options" und anschliessend auf "max_pictures". | |
| 3. Admin ändert den Wert "Value" zu einer Ganzzahl seiner Wahl. | |
| 4. Klickt unten rechts auf "Save". | |
| 5. Die Website speichert den Wert in der Datenbank. | |
| Alternative Flow | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| 2. Admin klickt auf "Options" und anschliessend auf "max_pictures". | |
| 3. Admin ändert den Wert "Value" zu einer Gleitzahl seiner Wahl. | |
| 4. Klickt unten rechts auf "Save". | |
| 5. Die Website gibt eine entsprechende Fehlermeldung aus. | |
| 6. Der Admin korrigiert den Wert und klickt "Save". | |
| 7. Die Website speichert den Wert in der Datenbank. | |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
7.0 Bestellung ändern/korrigieren
#+LATEX:{\footnotesize
| Identifier + Name | 7.0 Bestellung ändern/korrigieren |
| Description | Ein Administrator korrigiert eine Bestellung. |
| Actors | Verwaltung |
| Status | Freigeben |
| Includes | - |
| Trigger | Administrator ändert auf Wunsch eines Kunden eine Bestellung. |
| Preconditions | Account mit Administrationsrechten vorhanden. |
| Postconditions | Die Bestellung hat eine angepasste Artikelmenge. |
| Normal Flow | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| 2. Admin klickt auf "Orders" und anschliessend auf die passende Order ID. | |
| 3. Admin ändert den Wert "Amount" des ersten Artikels zu 0. | |
| 4. Klickt unten rechts auf "Save". | |
| 5. Die Website speichert die Bestellung in der Datenbank. | |
| Alternative Flow | - |
| Notes | - |
| UC History | 1.0 Draft erstellt durch AZ |
| Author | A. Zweili & I. Hörler |
| Date | 16.01.2018 |
#+LATEX:}
Models
Wie bereits in /ibz/web_AI-5/src/branch/master/docs/Framework beschrieben, übernimmt das Framework die Erstellung der Tabellen in der Datenbank. Für den Aufbau der Anwendung und der Kommunikation im Team ist es jedoch von absoluter Notwendigkeit, dass man sich über die Beziehung zwischen den Objekten Gedanken macht. Insbesondere, wenn die Anwendung nach wie vor auf einer relationalen Datenbank basiert. Aus diesem Grund haben wir vor Beginn der Arbeit ein klassisches Entity Relation Diagramm aufgezeichnet. Während der Entwicklung haben wir es dann kontinuierlich erweitert und korrigiert. Das finale Ergebnis ist in der Abbildung:(fig:erd) zu sehen.
Django übernimmt dann jedoch das Erstellen und Benennen der Tabellen, weshalb das Resultat in der Datenbank etwas anders aussieht. Zusätzlich kommt Django auch noch mit eigenen Tabellen daher. Der finale Aufbau der Datenbank ist in der Abbildung:(fig:final_erd) zu sehen. Dieses ERD wurde mit der Django Erweiterung "Django-Extensions"\footcite{djangoextensions} erstellt.
Nachfolgend werden wir die von uns erstellten Modells im Detail beschreiben und auf jeweils spezifische Probleme eingehen.
#+LATEX:≠wpage #+LATEX:\begin{landscape}
/ibz/web_AI-5/src/branch/master/docs/diagrammes/erd.eps #+LATEX:\end{landscape} #+LATEX:≠wpage
#+LATEX:≠wpage #+LATEX:\begin{landscape}
#+LATEX:\end{landscape}
#+LATEX:≠wpage
Category
Das "Category" Modell, Abbildung:(fig:category), ist der Kernpunkt der Artikelnavigation und vom Aufbau her eigentlich eher simpel. Allerdings hatten wir etwas Mühe, die hierarchische Darstellung im Template sauber abzubilden. Hier half uns ein Artikel\footcite{tree} von Stackoverflow auf die richtige Lösung zu kommen mit dem Hinweis, dass sich das ganze um zwei in einander verschachtelte Dictionaries handelt. Somit konnten wir dann über die Kategorie iterieren.
Option
Gemäss der Anforderung FA_1.4 muss es möglich sein für einen Artikel 0-5 Bilder hochzuladen. Wir stellen dies über eine Variabel im "Option" Modell ( Abbildung:(fig:option) ) sicher, gegen welche beim Speichern geprüft wird. Die Variabel ist als Option im Admin Interface hinterlegt. Dadurch ist es möglich den Wert auch nachträglich noch zu ändern oder ganz zu deaktivieren.
Da diese Variabel jedoch essentiell für die Funktion des Webshops ist, mussten wir sicherstellen, dass sie von einem Administrator nicht aus Versehen gelöscht oder umbenannt wird. Des Weiteren macht es in der Applikation momentan wenig Sinn, wenn der User selber Optionen hinzufügen kann. Aus diesen Gründen haben wir für das "Option" Modell den "Add" Button\footcite{removeadd} und die "Delete" Option\footcite{removedelete} entfernt sowie den Namen im Admin Interface nur lesbar gemacht\footcite{readonly}. Somit ist nur noch der Wert editierbar.
ArticleStatus
Das Modell "ArticleStatus", Abbildung:(fig:articlestatus), wird über einen Fremdschlüssel mit dem "Article" Modell verbunden und gibt diesem verschiedene Status. Gemäss der Anforderung FA_1.4 muss ein Artikel die Status "active" und "hidden" haben. Wir haben dies in der Applikation dann auch gleich so umgesetzt damit nur die Artikel angezeigt werden welche nicht den Status "hidden" haben.
ExchangeRate
Wir legen die Wechselkurse im Modell "ExchangeRate", Abbildung:(fig:exchangerate), ab. Um Manipulationen aufs Datum und den Namen einfacher zu machen, werden diese beiden Attribute als Fremdschlüssel hinterlegt. Die Wechselkurse werden dabei aus dem RSS Feed\footcite{snb} der Schweizerischen Nationalbank stündlich abgeholt. Vor dem Ablegen in der Datenbank wird dann noch überprüft, ob sich die Werte geändert haben oder nicht. Wir haben uns für die Daten der SNB entschieden, da sie einerseits die benötigten Wechselkurse anbieten und anderseits bereits von unserer Basiswährung CHF ausgehen. Dadurch müssen wir nicht zuerst aus einer anderen Währung zurückrechnen.
ExchangeRate_name
Im Modell ExchangeRate_name, Abbildung:(fig:exchangerate_name), ist nur eine Liste mit allen möglichen Währungsnamen abgelegt.
ExchangeRate_date
Damit die Wechselkurse des Tages einfacher auf einer Zeile angezeigt werden können, haben wir das Datum in ein eigenes Modell, Abbildung:(fig:exchangerate_date), ausgelagert. Dabei wird das Datum als Standardwert mitgegeben. Wir hatten dies zu Beginn noch falsch implementiert und das Datum als Funktion übergeben. Das führte jedoch dazu, dass die Funktion einmal beim Starten des Servers ausgeführt wurde und alle Wechselkurse immer das gleiche Datum hatten. Auf Stackoverflow fanden wir dann die Lösung\footcite{timezone}, die Datumsfunktion als Variabel zu übergeben damit sie bei jedem Erstellen des Objektes evaluiert wird.
Article
Das Modell "Article", Abbildung(fig:article), ist als solches nicht sehr komplex und widerspiegelt einen Artikel aus der realen Welt. Gemäss der Anforderung FA_1.4 hat er eine eindeutige ID (den Primärschlüssel), einen Namen von maximal 200 Zeichen, eine Beschreibung von maximal 2000 Zeichen, Status sowie 0 - 5 Produktbilder, welche vom Modell "Picture" über einen Fremdschlüssel zugewiesen werden.
OrderStatus
Damit nachvollzogen werden kann in welchen Zustand sich eine Bestellung gerade befindet, haben wir ein Modell "OrderStatus", Abbildung:(fig:orderstatus), erstellt. Für dieses Modell sind folgende Status angedacht:
- ordered -> vom Kunden bestellt
- delivered -> Bestellung wurde versandt
- cancelled -> Bestellung storniert
- on hold -> Bestellung pausiert
Der "OrderStatus" wird vom "Order" sowie auch dem "OrderOfGoods" Modell verwendet.
OrderOfGoods
Das Modell "OrderOfGoods", Abbildung:(fig:orderofgoods), bildet die Nachbestellungen fürs Warenlager ab. Dabei wird es hauptsächlich für die Verwaltung verwendet um die Nachbestellungen im Griff zu haben.
Picture
Über das Modell "Picture", Abbildung:(fig:picture), können Bilder für einen Artikel hochgeladen werden. Grundsätzlich kann man Bilder relativ einfach über das Attribut "models.ImageField" zu einem Modell hinzufügen. Wir hatten allerdings noch einige Probleme mit dem Konfigurieren von Django damit der Upload funktionierte und wir die Bilder in den Templates verwenden konnten. Die Lösungen für den Upload fanden wir in einem Stackoverflow Post\footcite{upload}. Auch für das verwenden der Bilder in den Templates fanden wir in einem Post auf Stackoverflow\footcite{images} die Lösung.
Order und OrderPosition
Bestellungen der Kunden werden im Modell "Order", Abbildung:(fig:order), erfasst. Wobei im Modell "Order" nur die Kunden ID gespeichert wird, sowie, gemäss der Anforderung FA_3.3, der Foreign Key zum "ExchangeRate" Modell. Über den Foreign Key wird eine Beziehung auf den für die Bestellung aktuellen Wechselkurs der Währung hergestellt.
Da es sich bei der Beziehung zwischen den Artikeln und dem Kunden um eine "Viele zu Viele" Beziehung handelt, braucht es noch ein zusätzliches Modell, welches die Beziehung abbildet. Dies realisieren wir über das Modell "OrderPostion", Abbildung:(fig:orderposition).
In diesem Modell werden dann noch zusätzlich die bestellte Menge sowie der Preis zur Zeit der Bestellung in Schweizer Franken des jeweiligen Artikels erfasst. Somit kann auch später noch nachvollzogen werden zu welchem Preis die Ware bezogen wurde.
ShoppingCart und ShoppingCartPosition
Bevor die Bestellungen erfasst werden, kann der Kunde die Artikel in einem Warenkorb sammeln. Dieser funktioniert sehr ähnlich wie die Bestellungen. Über das Modell "ShoppingCart", Abbildung:(fig:shoppingcart), und das Modell "ShoppingCartPosition", Abbildung:(fig:shoppingcartposition), werden die ausgewählten Artikel sowie ihre Mengen einem User zugewiesen. Im Gegensatz zur Bestellung wird im Artikel jedoch der Preis nicht gespeichert, da sich der Preis vor der Bestellung noch ändern könnte. Wenn die Verwaltung etwa die Preise anpasst oder die Währungskurse ändern.
City
Das "City" Modell speichert Städtenamen und die dazugehörige Postleitzahl. Die Städte werden als Teil der Adresse auf dem "Person" Modell hinterlegt. Im aktuellen Zustand der Applikation enthält die Tabelle die Daten aller Schweizer Städte.
Salutation
"Salutation", zu Deutsch Anrede, ist das Modell, welches die möglichen Anreden beinhaltet, die ein User für sich hinterlegen kann. Für den Moment haben wir die folgenden Auswahlmöglichkeiten hinterlegt:
- Herr
- Frau
- Dr.
Person
Das "Person" Modell dient dazu Informationen über einen User zu speichern die nicht relevant sind für die Authentifizierung.
Es gibt mehrere Möglichkeiten wie man das "User" Modell in Django erweitern kann. In einem Post\footcite{usermodel} von Vitor Freitas werden die möglichen vier Varianten aufgeführt und erklärt. Eine davon ist nicht dafür gemacht zusätzliche Informationen zu speichern. Zwei weitere Varianten bauen darauf auf von einer Basis "User" Klasse abzuleiten. Die erste Variante war für unsere Zwecke nicht geeignet, da wir zwingend zusätzliche Informationen speichern wollten. Die Varianten mit Vererbungen erschienen uns ungeeignet, da die Möglichkeit besteht, die Sicherheit der Authentifizierung zu schwächen. Aus diesem Grund wird in der Django Dokumentation eher davor abgeraten diese Varianten zu verwenden, wenn man nicht genau weiss, was man macht.
Die verbleibende Variante erweitert das "User" Modell über eine "One-to-One" Beziehung, ein sogenanntes "Profil". Dadurch bleibt das "User" Modell intakt und man kann zusätzliche Informationen über den User speichern. Man sollte im Profil jedoch nur Daten speichern, welche nicht sicherheitsrelevant sind. Der Nachteil dieser Variante ist, dass die Datenbank mit zusätzlichen Anfragen belastet werden kann.
Wir haben uns hier auch dazu entschieden nur Einkäufe nach erfolgter Registrierung zu erlauben. Dies einerseits weil wir sowieso bereits eine "One-to-One" Beziehung zwischen einem User und einer Person ermöglichen. Zum anderen da es auch aus Sicht der Shop Betreiber, Kunden die bereits einen Account haben kommen öfters wieder, wie auch aus Sicht der Kunden, ein Account kann einem viele Vorteile bringen wie etwa einfachere Garantieabwicklung oder Bestellungsübersichten, absolut Sinn macht.
#+LATEX:≠wpage
Benutzerinterface
Mockup Skizze
Mit Hilfe eines Hand gezeichneten Mockups, Abbildung:(/ibz/web_AI-5/src/branch/master/docs/mockup), haben wir eine erste Skizze des Webshop Interfaces erstellt. Damit hatten wir eine Diskusionsgrundlage wie wir das Interface weiter entwickeln könnten.
#+LATEX:≠wpage
Frontend Umsetzung
Die Umsetzung des Frontends mittels Django integrierter Template Funktionen sind geprägt vom einstmals eigenständigen Jinja Template Framework das auch in Python programmiert wurde. Mittlerweile ist es integrierter Bestandteil vom Django Framework. Dieses Snippet erklärt deren Nutzung:
Backend Umsetzung
Django ist ein modellbasiertes Framework, das die Programmierung der Datenbank gleich selbst regelt. Dadurch lässt sich backend seitig durchgängig in Python arbeiten. Die Umsetzung gliedert sich vereinfacht in 3 Bereiche:
- Einem Frontend, das für den Benutzer gemacht ist und das mehrere Submodule wie Categories oder Warenkorb beinhaltet.
- Ein Backend, welches zum Bearbeiten/Erstellen von Produkten dient.
- Currencies, die täglich abgeholt werden #+LATEX:≠wpage
Testing
Um die Funktionalität des Webshops sicherzustellen, haben wir die Applikation kontinuierlich gemäss den Testfällen unter /ibz/web_AI-5/src/branch/master/docs/Testf%C3%A4lle getestet und geprüft. Bei den Testfällen haben wir uns wie auch bei den Use Cases hauptsächlich auf die Funktionen beschränkt, welche wir selber ausprogrammiert haben. Auch sehr hilfreich war das Admin Interface von Django. Damit konnten wir die Modells sehr gut auf ihre Funktionalität überprüfen, bevor wir sie im Frontend verwendeten.
Fixtures
Django hat eine Funktion\footcite{fixtures}, genannt "Fixtures", welche es einem erlaubt, fixe Daten in die Datenbank zu schreiben. Dabei werden die Daten in YAML Syntax in eine .yaml Datei geschrieben und mittels folgendem Befehl dann in die Datenbank geladen:
Wir haben diese Funktion verwendet um Testdaten in der Datenbank zu speichern. Somit mussten wir etwa nicht von Hand Artikel oder User erfassen. Zumindest nicht mehr, als wir sicher waren, dass die dazugehörige Funktionen korrekt funktionieren.
#+LATEX:≠wpage #+LATEX:\begin{landscape}
Testfälle
Alle Testfälle werden von der Index Seite aus gestartet. Dies wird in den Test Cases nicht noch einmal explizit erwähnt. Die Tabelle: (tab:testcases) zeigt dabei die Resultate des letzten Testlaufs. Dabei wurden keine Probleme mehr mit der Applikation entdeckt.
#+LATEX:{\footnotesize
| Testcase ID\cellcolor[HTML]{C0C0C0} | Objective\cellcolor[HTML]{C0C0C0} | Precondition\cellcolor[HTML]{C0C0C0} | Steps\cellcolor[HTML]{C0C0C0} | Testdata\cellcolor[HTML]{C0C0C0} | Expected Result\cellcolor[HTML]{C0C0C0} | Postcondition\cellcolor[HTML]{C0C0C0} | Result\cellcolor[HTML]{C0C0C0} |
| TC-01 | Artikel durchstöbern | - | 1. Auf "First Parent Category" klicken. | - | Die Artikel der "Parent Category 1" werden angezeigt. | Eine gefilterte Artikelliste wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-02 | User Registration | - | 1. Auf "LOGIN" klicken.≠wline 2. Auf "Go to registration." klicken.≠wline 3. Die Personaldaten eintragen.≠wline 4. Auf "Register" klicken. | Username: max≠wline Password: TestPasswort≠wline Email: max@gmail.com≠wline Salutation: Herr≠wline Firstname: Max≠wline Lastname: Muster≠wline Streetname: Musterstrasse≠wline Streetnumber: 13≠wline ZIP Code: 1000≠wline City: Lausanne | User wurde erfolgreich registriert. | Die Login Form wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-03 | User Registration | TC-02≠wline ausgeführt | 1. Auf "LOGIN" klicken.≠wline 2. Auf "Go to registration." klicken.≠wline 3. Die Personaldaten eintragen.≠wline 4. Auf "Register" klicken. | Username: max≠wline Password: TestPasswort≠wline Email: max@gmail.com≠wline Salutation: Herr≠wline Firstname: Max≠wline Lastname: Muster≠wline Streetname: Musterstrasse≠wline Streetnumber: 13≠wline ZIP Code: 1000≠wline City: Lausanne | Fehlermeldung: "A user with that username already exists." | Die Registrierungsform wird wieder angezeigt werden. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-04 | User Registration | - | 1. Auf "LOGIN" klicken.≠wline 2. Auf "Go to registration." klicken.≠wline 3. Die Personaldaten eintragen.≠wline 4. Auf "Register" klicken. | Username: max≠wline Password: TestPasswort≠wline Email: max@gmail.com≠wline Salutation: Herr≠wline Firstname: Max≠wline Lastname: Muster≠wline Streetname: Musterstrasse≠wline Streetnumber: 13≠wline ZIP Code: 1000≠wline City: Lausanne | Fehlermeldung: "The two password fields didn't match." | Die Registrierungsform wird wieder angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-05 | User Registration | - | 1. Auf "LOGIN" klicken.≠wline 2. Auf "Go to registration." klicken.≠wline 3. Die Personaldaten eintragen.≠wline 4. Auf "Register" klicken. | Username: max≠wline Password: TestPasswort≠wline Email: max@gmail.com≠wline Salutation: Herr≠wline Firstname: Max≠wline Lastname: Muster≠wline Streetname: Musterstrasse≠wline Streetnumber: 13≠wline ZIP Code: 1000≠wline City: Lausanne | Fehlermeldung: "The zip code and the city don't match." | Die Registrierungsform wird wieder angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-06 | User Login | TC-02≠wline ausgeführt | 1. Auf "LOGIN" klicken.≠wline 2. Login Daten eingeben.≠wline 3. Auf "Login" Button klicken. | Username: max≠wline Password: TestPasswort | Der User wird zum Index weitergeleitet. | Die Index Seite wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-07 | User Login | - | 1. Auf "LOGIN" klicken.≠wline 2. Login Daten eingeben.≠wline 3. Auf "Login" Button klicken. | Username: FakeUser≠wline Password: FakePassword | Fehlermeldung: "Please enter a correct username and password. Note that both fields may be case-sensitive." | Die Login Form wird wieder angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-08 | Artikel in Warenkorb legen | - | 1. Auf "Article of First Parent Category" klicken. | - | Meldung "please login to fill your basket…" | Die Artikel Details werden angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
| TC-09 | Artikel in Warenkorb legen | TC-02≠wline ausgeführt | 1. Auf "Article of First Parent Category"≠wline 2. In das "Amount in piece" Feld Die Menge eintragen.≠wline 3. Auf den "Add to Cart" Button klicken.≠wline 4. Auf "CART" klicken. | Menge: 5 | Der Artikel wird als Warenkorb Position in der Datenbank gespeichert. | Der Cart mit dem Artikel wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
| TC-10 | Währung ändern | - | 1. Auf das Dropdown "Currencies" klicken.≠wline 2. Den Eintrag "EUR" auswählen.≠wline 3. Auf den Button "Select" klicken. | - | Die Artikel Preise werden in Euro angezeigt. | Die Index Seite wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
| TC-11 | Checkout | TC-09≠wline ausgeführt | 1. Auf den Button "CHECKOUT" klicken.≠wline 2. Die TOS annehmen.≠wline 3. Auf den "Order" Button klicken. | - | Die Bestellung wird gespeichert. | Die Bestellbestätigung wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
| TC-12 | Checkout | TC-09≠wline ausgeführt | 1. Auf den Button "CHECKOUT" klicken.≠wline 2. Auf den "Cancel" Button klicken. | - | Die Bestellung wird nicht ausgeführt. | Der Warenkorb wird wieder angezeigt. | Erfolgreich durchgeführt 19.02.2018 I.H. |
| TC-13 | Artikel erfassen | - | 1. Die URL http://localhost:8000/admin aufrufen.≠wline 2. Userdaten eingeben.≠wline 3. Neben "Articles" auf "+ Add" klicken.≠wline 4. Artikel Daten eingeben.≠wline 5. Auf den "SAVE" Button klicken. | Username: admin≠wline Password: password≠wline Name: Test Artikel≠wline Description: Test Description≠wline Stock: 10≠wline Status: active≠wline Price in chf: 23 | Der Artikel wird in der Datenbank gespeichert. | Die Artikelliste wird mit dem Artikel "Test Artikel" angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-14 | Artikel erfassen | - | 1. Die URL http://localhost:8000/admin aufrufen.≠wline 2. Userdaten eingeben.≠wline 3. Neben "Articles" auf "+ Add" klicken.≠wline 4. Artikel Daten eingeben.≠wline 5. Auf den "SAVE" Button klicken. | Username: admin≠wline Password: password≠wline Name: Test Artikel≠wline Description: Test Description≠wline Stock: 10≠wline Status: active | Fehlermeldung: "This field is required." | Die Artikel Form wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-15 | Artikel löschen | TC-13≠wline ausgeführt | 1. Die URL http://localhost:8000/admin aufrufen.≠wline 2. Userdaten eingeben.≠wline 3. Auf "Articles" klicken.≠wline 4. Den Artikel "Test Artikel" markieren.≠wline 5. Im Dropdown "Action" die Aktion "Delete selected articles" auswählen.≠wline 6. Auf den "Go" Button klicken. | Username: admin≠wline Password: password | Der Artikel und die Bilder dazu werden aus der Datenbank gelöscht. | Die Artikelliste wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-16 | Bilder hochladen | TC-13≠wline ausgeführt | 1. Die URL http://localhost:8000/admin aufrufen.≠wline 2. Userdaten eingeben.≠wline 3. Neben "Pictures" auf "+ Add" klicken.≠wline 4. Bild Daten eingeben.≠wline 5. Auf den "Browse…" Button klicken.≠wline 6. Ein beliebiges Bild hochladen.≠wline 7. Auf den "SAVE" Button klicken.≠wline 8. Die URL http://localhost:8000/details/1/ aufrufen. | Username: admin≠wline Password: password≠wline Name: Test Bild≠wline Article: Article of First Parent Category | Das Bild ist in den Artikel Details zu sehen. | Die Artikel Details werden angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-17 | Bilder hochladen | TC-13≠wline ausgeführt | 1. Die URL http://localhost:8000/admin aufrufen.≠wline 2. Userdaten eingeben.≠wline 3. Neben "Pictures" auf "+ Add" klicken.≠wline 4. Bild Daten eingeben.≠wline 5. Auf den "Browse…" Button klicken.≠wline 6. Ein beliebiges Bild hochladen.≠wline 7. Auf den "SAVE" Button klicken.≠wline 8. Die Schritte 1 - 7 5 mal wiederholen. | Username: admin≠wline Password: password≠wline Name: Test Bild[1-5]≠wline Article: Article of First Parent Category | Fehlermeldung: "Only 5 pictures per article allowed." | Die "Picture" Form wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
| TC-18 | Artikel Status ändern | TC-13≠wline ausgeführt | 1. Die URL http://localhost:8000/admin aufrufen.≠wline 2. Userdaten eingeben.≠wline 3. Auf "Articles" klicken.≠wline 4. Auf den Artikel "Test Artikel" klicken.≠wline 5. Im Dropdown "Status" den Status "Hidden" auswählen.≠wline 6. Auf den "SAVE" Button klicken.≠wline 7. Die URL http://localhost:8000 aufrufen. | - | Der Artikel wird im Webshop nicht mehr angezeigt. | Die Index Seite wird angezeigt. | Erfolgreich durchgeführt 19.02.2018 A.Z. |
#+LATEX:} #+LATEX:\end{landscape} #+LATEX:≠wpage
Fazit
Projektmanagement
Eine sorgfälltige Planung ist wichtig um ein Projekt erfolgreich zum Abschluss zu bringen. Insbesondere wenn es im Projekt gewisse Unbekannte gibt hilft einem eine gute Planung das Ziel nicht aus den Augen zu verlieren.
Eine gute Planung ist auch für die Kommunikation im Team wichtig damit jeder Projektmitarbeiter den aktuellen Stand kennt, weiss was geplannt ist und welche Schritte als nächstes gemacht werden müssen.
Eine gutes Beispiel für diese Kommunikation ist ein Missverständiss dass Zwischen Andreas und Ivan entstand als die Positionen in der Bestellung das erste mal abgefragt wurden. Ivan hatte den preis in CHF pro Stück abgelegt und Andreas hatte die Summe der Stückzahl mal Preis in CHF erwaret. Das fürte zu verwirrung als die Positionen plötzlich x-fach teurer Angezeigt wurden als sie Gekauft wurden.
Umsetzung
Ein Framework ist nahezu immer eine komplexe Angelegenheit und braucht viel Einarbeitungszeit wenn man sich zuvor noch nie damit beschäftigt hat. Dabei macht es nicht einmal einen grossen Unterschied ob man die jeweilige Programmiersprache bereits kennt. Das Framework bringt in der Regel viele eigene Wege und Lösungen mit um Probleme anzugehen.
Wir haben jedoch festgestellt das eine Framework eine grosse Hilfe sein kann, bei Aufgaben welche immer wieder kommen. Zusätzlich empfanden wir es als sehr angenehm uns nicht gross mit der Datenbank auseinander setzen zu müssen. Leider kann ein Framework das Sprachenchaos bei einer Webanwendung nur bedingt vereinfachen da man am Schluss dann doch immer mindestens drei Sprachen einsetzt.
Gelerntes
Wir haben bei dieser Case Study einmal mehr gemerkt das eine gute Vorbereitung und Planung in einem Projekt von grosser Wichtigkeit ist. Spezifikationen sollten früh ausgearbeitet werden und auch konstant nachgeführt werden damit man im Team immer auf dem gleichen Wissensstand ist und von der gleichen Sache redet.
Im Bezug auf die Umsetzung haben wir die Vorzüge eines Systems wie Vagrant schätzen gelernt welches jedem Entwickler die gleiche Umgebung zur Verfügung stellt. Somit hatten wir nahezu nie das Problem, dass ein Code Update bei einem Entwickler nicht funktionierte und wenn es mal auftrat war es dann jeweils sehr schnell behoben. Zusätzlich haben wir gelernt das ein Framework zwar die Arbeit enorm vereinfachen kann aber durchaus auch seine Tücken hat und zuerst einmal verstanden werden muss bevor man es korrekt einsetzen kann.
Insgesamt war es eine sehr interessante Case Study bei welcher wir zum ersten Mal das Gefühl hatten das wir über eine genügende Wissensbasis verfügten um das Projekt in Angriff zu nehmen.