diff --git a/docs/doku.org b/docs/doku.org index ed27b46..4076637 100644 --- a/docs/doku.org +++ b/docs/doku.org @@ -6,6 +6,7 @@ #+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 @@ -13,6 +14,7 @@ und das Dokument auf unseren Laptops lokal mit emacs org-mode bearbeitet. ** Titel der Dokumentaion + Die Gruppe hat verschiedene Varianten gelistet und sich für die lustigste entschieden. - Marktplatz @@ -21,25 +23,29 @@ lustigste entschieden. - Didgeridoo-shop ** Beschreibung + Planung und erstellung eines konfigurierbaren Webshops 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 soriert, 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. * 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. @@ -59,6 +65,7 @@ umfasst alle aspekte um die gewälte Lösung nachzuvollziehen. ** 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 @@ -66,6 +73,7 @@ Entwicklung schnellstmöglich ohne lästige einzelkonfigurationen auf die Beine zu bringen. *** 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 @@ -76,12 +84,14 @@ 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 Webshop mit geeigneter Software erstellen. Dabei setzen wir nur frei verfügbare Software ein. (Frei in form der Freien Meinungsäuserung). Wir untersuchen die Anforderung und wählen die uns @@ -90,6 +100,7 @@ Zeiteinsparung durch vorgefertigte Entwicklungen werden angenommen und dennoch wollen wir keine fertigen Software Produkte einsetzen. ** 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. @@ -101,9 +112,10 @@ haben. | Chancen | Wir als Programmierer haben ein gutes Know-How im Bereich Datenbanken | Wir als Programmierer haben keine Erfahrung im Konsumsegment unseres Nutzers | |----------+----------------------------------------------------------------------------------------+------------------------------------------------------------------------------| | Gefahren | Die Umsetzung der Graphischen Anwendungsoberfläche könnte sich als schwierig erweisen. | Die Umsetzungszeit ist knapp bemessen | -| | | | +|----------+----------------------------------------------------------------------------------------+------------------------------------------------------------------------------| ** 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 @@ -128,10 +140,14 @@ Einschätzung der Wahrscheinlichkeit der Einflussnahme aufgenommen. | 4. | Projektleiter | hoch | - Gutes Innovatives Produkt erschaffen. | mittel | | | | | - Anerkennung im fachlichen Umfeld | hoch | | | | | | | + ** TODO Umweltgrafik + -wie zeichnen?? + ** Risikomanagement *** Risikobeschreibung + | 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 | @@ -144,7 +160,9 @@ Einschätzung der Wahrscheinlichkeit der Einflussnahme aufgenommen. |-----+--------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-----+-----| | 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 | |-----+--------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-----+-----| + *** TODO Risikobewertung + | Bewertung | Beschreibung: Warscheinlichkeit (W) | |------------+-------------------------------------| | 1 = gering | Unwarscheinlich, <20% | @@ -158,7 +176,9 @@ Einschätzung der Wahrscheinlichkeit der Einflussnahme aufgenommen. | 3 = hoch | Projekt erfüllt nicht alle Anforderungen | --> Graphik einfügen!!! + ** TODO Projektabgrenzung + Am ende des Projekts die nicht lauffähigen teile ausgrenzen. :-) * Projektmanagement @@ -167,6 +187,7 @@ Am ende des Projekts die nicht lauffähigen teile ausgrenzen. :-) ** Varianten erarbeiten ** Architektur vorbereiten ** Arbeitspakete definieren + * Umsetzung ** Datenbank *** Anforderungsanalyse @@ -177,6 +198,7 @@ Am ende des Projekts die nicht lauffähigen teile ausgrenzen. :-) *** SQL Restriktionen erarbeiten *** SQL Views erstellen *** SQL Prozeduren und Funktionen erarbeiten + ** Benutzerinterface *** Mockup skizzieren *** Frontend Umsetzung @@ -184,15 +206,12 @@ Am ende des Projekts die nicht lauffähigen teile ausgrenzen. :-) *** Testing **** Anwendungsfälle ***** Szenarienanalyse + * Fazit ** Projektmanagement ** Umsetzung ** Gelerntes - - - - * TODO samples [to be deleted] *** Subsubsection