#+TITLE: Casestudy Webtechnologien
#+SETUPFILE: ~/git_repos/notes/settings/html_theme/setup/theme-readtheorg.setup
#+AUTHOR: Ivan Hörler Andreas Zweili
#+LaTeX_CLASS: article
#+LATEX_CLASS_OPTIONS: [a4paper,11pt]
#+LaTeX_HEADER: \input{style}

* Über dieses Dokument

Im nachfolgenden Abschnitt finden Sie allgemeine Informationen zu
diesem Dokument. Bei der Erstellung dieses Dokuments haben wir das
Versionierungs-Tool "Git" mit dem passenden Client "magit" verwendet
und das Dokument auf unseren Laptops lokal mit dem Emacs Plugin
org-mode bearbeitet.

** Titel der Dokumentation

Die Gruppe hat verschiedene Varianten gelistet und sich für die
lustigste entschieden.

- Marktplatz
- Shopshop
- Barewahre-Shop
- Didgeridoo-Shop

** 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
Ereigniss, und nach Kapiteln getrennt.

** Über die Autoren

Dieses Dokument wurde von Ivan Hörler und Andreas Zweili im Auftrag
der IBZ erstellt und darf ohne Einverständniss der Autoren kopiert und
vervielfälltigt werden. Erwähnung der Autoren vorausgesetzt.

* Projektanalyse und Planung
** Projektziele

Der Student erarbeitet in einer Zweiergruppe einen selbstentwickelten
Web-Shop. Die einzusezenden Technologien sollen Opensource sein. Die
zur verfügungstehende Zeit ist pro Student mit 80h zu veranschlagen.
Am Ende dieser Zeitspanne soll ein funktionaler Web-Shop mit minimalem
graphischen Userinterface entstehen, die dazugehörige Dokumentation
umfasst alle Aspekte um die gewählte Lösung nachzuvollziehen.

| Nr. | Beschreibung                                                       | Priorität |
|-----+--------------------------------------------------------------------+-----------|
|  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    |
#+CAPTION: Projektziele

** Mittel und Methoden
*** Werkzeuge

Als Testumgebung wurde eine VM Lösung mit Vagrant gewählt. Diese über
eine MIT-Lizenz frei verfügbare Lösung für Containerautomation eignet
sich durch seine crossplattform Anwendung hervorragend um die
Entwicklung schnellstmöglich ohne lästige Einzelkonfigurationen auf
die Beine zu bringen. Der Hypervisor für Vagrant war dabei Virtualbox.

*** 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 itterative 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-Kolegen.

*** Vorkenntnisse

Die benötigten Vorkenntnisse wurden in den vorangeganenen 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 im 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.

** TODO 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.

| Stärken                                                                                | Schwächen                                                                    | Chancen | Gefahren |
|----------------------------------------------------------------------------------------+------------------------------------------------------------------------------+---------+----------|
| Wir als Programmierer haben ein gutes Know-How im Bereich Datenbanken                  | Wir als Programmierer haben keine Erfahrung im Konsumsegment unseres Nutzers |         |          |
|----------------------------------------------------------------------------------------+------------------------------------------------------------------------------+---------+----------|
| Die Umsetzung der graphischen Anwendungsoberfläche könnte sich als schwierig erweisen. | Die Umsetzungszeit ist knapp bemessen                                        |         |          |
|----------------------------------------------------------------------------------------+------------------------------------------------------------------------------+---------+----------|
#+CAPTION: SWOT-Analyse

** 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 dieser Tabelle wurden die Anforderungen und Wünsche mit
Einschätzung der Wahrscheinlichkeit der Einflussnahme aufgenommen.

| Nr. | Stakeholder   | Einfluss | Anforderung/Wünsche                           | Warscheinlichkeit |
|-----+---------------+----------+-----------------------------------------------+-------------------|
|  1. | Auftraggeber  | hoch     | - Innovatives Produkt auf dem Markt anbieten. | hoch              |
|     |               |          | - Einhaltung von Terminen und Qualität.       | hoch              |
|-----+---------------+----------+-----------------------------------------------+-------------------|
|  2. | Nutzer        | gering   | - Einfache Lösung die anpassungsfähig ist.    | hoch              |
|     |               |          | - Schnell anfangen können.                    | hoch              |
|     |               |          | - Viele Arbeitsschritte Automatisieren        | mittel            |
|-----+---------------+----------+-----------------------------------------------+-------------------|
|  3. | Nachfrager    | gering   | - Intuitiv bedienbare Webseite                | hoch              |
|     |               |          | - schnell finden was gesucht wird.            | hoch              |
|-----+---------------+----------+-----------------------------------------------+-------------------|
|  4. | Projektleiter | hoch     | - Gutes Innovatives Produkt erschaffen.       | mittel            |
|     |               |          | - Anerkennung im fachlichen Umfeld            | hoch              |
|     |               |          |                                               |                   |
#+CAPTION: Umwelt-Analyse

** TODO Umweltgrafik

#+CAPTION: Stakeholder Diagramm
#+ATTR_LATEX: :width .9\textwidth
[[file:diagrammes/stakeholder_diagramm.eps]]

** TODO Risikomanagement
*** TODO Risikobeschreibung

- Note taken on [2017-10-31 Tue 22:09] \\
  Tönt noch sehr nach DB Case Study

| Nr. | Beschreibung                                                                   | Massnahmen                                                                                                                | W^1 | A^2 |
|-----+--------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-----+-----|
|  1. | Die Datenbank ist schlecht modeliert.                                          | 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, Arbeitgeber, 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 zuviel Zeit                              | Beider Projektplanung genau definieren was die GUI Applikation beinhalten muss. Ziele definieren, abgrenzungen treffen.   |   3 |   1 |
|-----+--------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-----+-----|
#+CAPTION: Risikobeschreibung

*** TODO Risikobewertung

| Bewertung  | Beschreibung: Warscheinlichkeit (W) |
|------------+-------------------------------------|
| 1 = gering | Unwarscheinlich, <20%               |
| 2 = mittel | Mässig warscheinlich, 20-50%        |
| 3 = hoch   | Hohe warscheinlichkeit > 50%        |
#+CAPTION: Risikobewertung Wahrscheinlichkeit

| Bewertung  | Beschreibung: Auswirkung (A)                    |
|------------+-------------------------------------------------|
| 1 = gering | geringe auswirkungen auf das Gesammtergebniss   |
| 2 = mittel | Arbeitsumstellung oder grösserer Arbeitsaufwand |
| 3 = hoch   | Projekt erfüllt nicht alle Anforderungen        |
#+CAPTION: Risikobewertung Auswirkung

--> Graphik einfügen!!!

** TODO Projektabgrenzung

Am ende des Projekts die nicht lauffähigen teile ausgrenzen. :-)

* Projektmanagement
** Organigram
** Projektstrukturplan
** Varianten erarbeiten
** Architektur vorbereiten
** Arbeitspakete definieren

* Umsetzung
** Spezifikation
*** Mockup
#+ATTR_LATEX: :width 18cm
#+CAPTION: a early Mockup of the shop
[[file:pictures/mockup-full-snipet.png][file:pictures/mockup-full-snipet.png]
*** Anwendungsfälle
*** Klassendiagramme der Models

**** Category

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Kategorien
[[file:pictures/class_category.png]]

**** Option

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Optionen
[[file:pictures/class_option.png][file:pictures/class_option.png]]

**** Setting

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Einstellungen
[[file:pictures/class_setting.png][file:pictures/class_setting.png]]

**** ArticleStatus

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Artikelstatus
[[file:pictures/class_articlestatus.png][file:pictures/class_articlestatus.png]]

**** ExchangeRate

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Wechselkurse
[[file:pictures/class_exchangerate.png][file:pictures/class_exchangerate.png]]

**** Article

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Artikel
[[file:pictures/class_article.png][file:pictures/class_article.png]]

**** OrderStatus

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Bestellstatus
[[file:pictures/class_orderstatus.png][file:pictures/class_orderstatus.png]]

**** OrderOfGoods

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Warenbestellungen
[[file:pictures/class_orderofgoods.png][file:pictures/class_orderofgoods.png]]

**** Picture

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Bilder
[[file:pictures/class_picture.png][file:pictures/class_picture.png]]

**** Order

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Bestellungen
[[file:pictures/class_order.png][file:pictures/class_order.png]]

**** ShoppingCart

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Warenkörbe
[[file:pictures/class_shoppingcart.png][file:pictures/class_shoppingcart.png]]

**** City

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Städte
[[file:pictures/class_city.png][file:pictures/class_city.png]]

**** Salutation

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Anreden
[[file:pictures/class_salutation.png][file:pictures/class_salutation.png]]

**** Person

#+ATTR_LATEX: :width 9cm
#+CAPTION: Klassenmodel für Personen
[[file:pictures/class_person.png][file:pictures/class_person.png]]

** Datenbank
*** Anforderungsanalyse
*** Relationen Model
*** Relationen Diagramm
*** SQL Create DB
*** SQL Insert Testdaten
*** SQL Restriktionen erarbeiten
*** SQL Views erstellen
*** SQL Prozeduren und Funktionen erarbeiten

** Benutzerinterface
*** Mockup skizzieren
*** Frontend Umsetzung
*** Backend Umsetzung
*** TODO Testing
**** Test Cases

* Fazit
** Projektmanagement
** Umsetzung
** Gelerntes

* TODO samples [to be deleted]
*** Subsubsection

- List
- List
- List

*** TODO Subsubsection

1. Numbered List
2. Numbered List
3. Numbered List

**** NEXT Subsubsubsection

Diese Section müssten man dann zuerst abschliesen damit die
übergeordnete abgeschlossen werden kann.

*** Table

| Name | Funktion | Beschreibung |
|------+----------+--------------|
|      |          |              |
|      |          |              |
|      |          |              |

*** Code Block

#+CAPTION: Python Code Block
#+BEGIN_SRC python
for var in collection:
    while variable = True:
#+END_SRC

#+CAPTION: SQL Code Block
#+BEGIN_SRC sql
create FUNCTION functionname()
RETURNS varchar(100)
AS BEGIN
END
go
#+END_SRC

#+LATEX: \begin{sexylisting}{SQL Code Block}
create FUNCTION functionname()
RETURNS varchar(100)
AS BEGIN
END
go
#+LATEX: \end{sexylisting}