367 lines
15 KiB
Org Mode
367 lines
15 KiB
Org Mode
#+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}
|