1006 lines
36 KiB
TeX
1006 lines
36 KiB
TeX
\section{Situationsanalyse}
|
|
\subsection{Vision}
|
|
Wir möchten eine Plattform für Markthändler schaffen welche es ihnen
|
|
ermöglicht geeignete Standflächen an attraktiven Standorten zu mieten.
|
|
Zusätzlich sollen sie auf einer Plattform die Möglichkeit haben sich
|
|
zu präsentieren. Diese Plattform soll interessierten Kunden einen
|
|
Überblick über die verschieden Anbieter geben und somit Neugierde
|
|
wecken. Dies alles soll mit möglichst wenig Aufwand verwaltet
|
|
werden können.
|
|
|
|
\subsection{Stakeholder}
|
|
Folgende Stakeholder sind in diesem Projekt zu berücksichtigen:
|
|
\begin{itemize}
|
|
\item Plattforminhaber
|
|
\item Standbetreiber
|
|
\item Marktbesucher
|
|
\end{itemize}
|
|
|
|
Abbildung: (\ref{fig:stakeholder}) zeigt die Beziehung der Stakeholder
|
|
zum Projekt noch grafisch auf.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=0.9\textwidth]{diagrammes/stakeholder.png}
|
|
\caption{Stakeholder Diagramm\label{fig:stakeholder}}
|
|
\end{figure}
|
|
|
|
\subsection{Chancen und Risiken}
|
|
|
|
\subsubsection{Chancen}
|
|
\begin{itemize}
|
|
\item Zusammenhänge zwischen Programmierung und Datenbank Modellierung
|
|
besser verstehen.
|
|
\item Erfahrungen im Projekt-Management vertiefen
|
|
\item Umgang mit den Werkzeugen üben und verbessern
|
|
\end{itemize}
|
|
|
|
\subsubsection{Risiken}
|
|
Ein grosses Risiko ist das wir uns beim Erarbeiten der Datenbank sowie
|
|
beim schreiben der Applikation in Details verlieren die nicht
|
|
gefordert werden. Sowie unter Umständen Dinge einbauen welche wir nicht
|
|
genügend kennen. Dies könnte uns zu einem späteren Zeitpunkt zum Verhängnis
|
|
werden.
|
|
|
|
\newpage
|
|
\section{Zielsetzung}
|
|
|
|
\subsection{Mussziele}
|
|
\begin{itemize}
|
|
\item Das Geschäftsmodell wurde in ein ERM umgewandelt.
|
|
\item Das ERM wurde in eine SQL-Server Datenbank umgesetzt.
|
|
\item Die Arbeit wurde mittels eines Testplans überprüft.
|
|
\item Die zur Verfügung stehenden Stunden sind in einer Planung
|
|
den Aufgaben zugeordnet. Abweichungen wurden mittels einer
|
|
Abweichungsanalyse aufgezeichnet.
|
|
\item Die Lösung wurde dokumentiert.
|
|
\item Eine Teilfunktion des Geschäftsmodell wurde in einer C\# Applikation
|
|
abgebildet.
|
|
\end{itemize}
|
|
|
|
\subsection{Wunschziele}
|
|
\begin{itemize}
|
|
\item Die Datenbank enthält alle statische Daten Wie
|
|
etwa Länder, Städte, Postleitzahlen, Standorte.
|
|
\item Die Datenbank enthält ein Rechtekonzept.
|
|
\end{itemize}
|
|
|
|
\newpage
|
|
\section{User Stories}
|
|
User Stories sind sind eine in Alltagssprache geschriebenen
|
|
Software-Anforderungen. Sie sind bewusst kurz gehalten und
|
|
beschreiben die Wünsche und Ziele der Rollen welche die
|
|
Software verwenden.
|
|
|
|
\subsection{Verwaltung}
|
|
Als Plattforminhaber möchte ich,
|
|
\begin{itemize}
|
|
\item Kontrolle über die Anmeldungen haben.
|
|
\item Standbetreiber verwalten können (Standort und Termine).
|
|
\item Qualitätschecks bei den Mitgliedern machen können.
|
|
\item Inspektoren bezahlen können.
|
|
\item die Rechnungen an die Mitglieder verwalten können.
|
|
\item die Kontrolle über die Anzahl der Auftrittsanpassungen haben.
|
|
\item Abonnemente verwalten können.
|
|
\item sichergestellt haben das provisorische Mitglieder sich nur
|
|
an einem Standort einen Platz reservieren können.
|
|
\end{itemize}
|
|
|
|
\subsection{Anbieter (provisorisches Mitglied)}
|
|
Als provisorisches Mitglied möchte ich,
|
|
\begin{itemize}
|
|
\item mich registrieren können.
|
|
\item eine Standfläche mieten können.
|
|
\item einsehen können wie lange die Probezeit noch dauert.
|
|
\end{itemize}
|
|
|
|
\subsection{Anbieter (festes Mitglied)}
|
|
Als festes Mitglied möchte ich,
|
|
\begin{itemize}
|
|
\item ein Abonnement lösen können.
|
|
\item Standorte buchen können.
|
|
\item meinen Auftritt anpassen können.
|
|
\end{itemize}
|
|
|
|
\subsection{Nachfrager/ Marktbesucher}
|
|
Als Marktbesucher möchte ich,
|
|
\begin{itemize}
|
|
\item mich registrieren können.
|
|
\item einen Überblick über die Anbieterprofile haben.
|
|
\item einen Überblick der Standorte und Termine der Märkte haben.
|
|
\end{itemize}
|
|
|
|
\newpage
|
|
\section{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.
|
|
|
|
\subsection{Use Case Diagramm}
|
|
``Ein Anwendungsfalldiagramm ... ist eine der 14 Diagrammarten der
|
|
Unified Modeling 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.''\cite{dbcs7}
|
|
|
|
Wir verschafften uns dabei mit einem Use Case Diagramm, zu sehen in
|
|
Abbildung: (\ref{fig:use_case}), zuerst einen groben Überblick über
|
|
die Use Cases und wie sie zusammenhängen.
|
|
|
|
\subsection{Use Cases Detailbeschreibungen}
|
|
Für die Ausarbeitung der C\# Applikation haben wir uns für 5 Use Cases
|
|
entschieden und diese in einer Use Case Schablone von Alistair
|
|
Cockburn im Detail ausgearbeitet und beschrieben haben. Die Alistair
|
|
Cockburn Schablone gibt eine gute Vorgabe für den Inhalt der Use Case
|
|
Beschreibung.
|
|
|
|
\subsubsection{Lösungsvarianten}
|
|
|
|
Wir wollen hier auch noch darauf eingehen welche Varianten wir uns
|
|
überlegt haben und wieso wir uns am Ende für die nachfolgenden 5 Use
|
|
Cases entschieden haben. Dabei war es uns besonders wichtig das bei
|
|
den Use Cases, Daten aus der Datenbank ausgelesen sowie auch
|
|
geschrieben werden müssen.
|
|
|
|
Wir haben uns dabei zu Beginn die folgenden drei möglichen Szenarien
|
|
überlegt:
|
|
\begin{itemize}
|
|
\item Login und Registrierung einer Person.
|
|
\item Lösen eines Abonnements.
|
|
\item Mieten eines Standorts.
|
|
\end{itemize}
|
|
|
|
\paragraph{Login und Registrierung einer Person.}
|
|
|
|
Bei dieser Lösungsvariante würde der komplette Registrierungsprozess
|
|
abgebildet werden. Dabei würden auch die Adressdaten etc. der Person
|
|
erfasst werden.
|
|
\paragraph{Lösen eines Abonnements.}
|
|
|
|
Das Lösen eines Abonnements würde beinhalten das eine bestehende
|
|
Person eines der verschiedenen Abonnemente anschauen, auswählen und
|
|
anschliessend ``kaufen'' könnte.
|
|
|
|
\paragraph{Mieten eines Standorts.}
|
|
|
|
Beim Mieten eines Standortes könnte ein Mitglied die Marktstandorte
|
|
einsehen, auswählen und sich dort einen Spot reservieren.
|
|
|
|
\paragraph{Gewählte Variante}
|
|
|
|
Schlussendlich haben wir uns dafür entschieden einen Login und die
|
|
Registrierung umzusetzen. Allerdings haben wir beschlossen das wir uns
|
|
darauf beschränken ein Mitglied nur mit einer Email Adresse und einem
|
|
Passwort zu erfassen. Zusätzlich schien uns das Mieten eines Standorts
|
|
noch eine gute Funktion um eine Teilfunktion der Applikation
|
|
abzubilden.
|
|
|
|
\begin{landscape}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[height=0.9\textheight]{diagrammes/use_cases.png}
|
|
\caption{Use Case Diagramm\label{fig:use_case}}
|
|
\end{figure}
|
|
\end{landscape}
|
|
|
|
|
|
%% -- Begining of Use Case Template --
|
|
\subsubsection{User Registrierung}
|
|
{\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|}
|
|
\hline
|
|
%begin title row
|
|
{\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 1.0 User Registrierung} \\ \hline
|
|
%end title row
|
|
Description & Registrierung eines neuen User Accounts.\\
|
|
\hline
|
|
Actors & User\\
|
|
\hline
|
|
Status & Freigegeben\\
|
|
\hline
|
|
Includes & -\\
|
|
\hline
|
|
Trigger & User möchte sich registrieren.\\
|
|
\hline
|
|
Preconditions & Email Adresse vorhanden.\\
|
|
\hline
|
|
Postconditions & User hat sich einen Account erstellt.\\
|
|
\hline
|
|
Normal Flow & 1. User startet Registrierung\\
|
|
& 2. User füllt Form aus\\
|
|
& 3. User schliesst Registrierung ab\\
|
|
\hline
|
|
Alternative Flow & 1. User startet Registrierung\\
|
|
& 2. User füllt Form mit bereits vorhandener Email Adresse aus.\\
|
|
& 3. Applikation gibt Fehler aus\\
|
|
& 4. User verwendet einzigartige Email Adresse\\
|
|
& 5. User schliesst Registrierung ab\\
|
|
\hline
|
|
Notes & -\\
|
|
\hline
|
|
UC History & 1.0 Draft erstellt durch AZ\\
|
|
& 1.1 kleinere Anpassungen durch AZ\\
|
|
\hline
|
|
Author & A. Zweili \& I. Cadaroski\\
|
|
\hline
|
|
Date & 24. August 2017\\
|
|
\hline
|
|
\caption{Use 1.0 User Registrierung}
|
|
\end{longtable}}
|
|
\newpage
|
|
%% -- End of Use Case Template --
|
|
|
|
%% -- Begining of Use Case Template --
|
|
\subsubsection{User Login}
|
|
{\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|}
|
|
\hline
|
|
%begin title row
|
|
{\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 1.1 User Login} \\ \hline
|
|
%end title row
|
|
Description & Login eines Users am System.\\
|
|
\hline
|
|
Actors & User\\
|
|
\hline
|
|
Status & Freigegeben\\
|
|
\hline
|
|
Includes & -\\
|
|
\hline
|
|
Trigger & User möchte sich einloggen\\
|
|
\hline
|
|
Preconditions & UC 1.0 erfolgreich abgeschlossen\\
|
|
\hline
|
|
Postconditions & User befindet sich im geschützten Bereich.\\
|
|
\hline
|
|
Normal Flow & 1. User füllt Login Form korrekt aus\\
|
|
& 2. User quittiert Login\\
|
|
& 3. Applikation wechselt zum geschützten Bereich\\
|
|
\hline
|
|
Alternative Flow & 1. User füllt Login Form mit falschen Angaben aus.\\
|
|
& 2. Applikation gibt einen Error aus\\
|
|
\hline
|
|
Notes & -\\
|
|
\hline
|
|
UC History & 1.0 Draft erstellt durch AZ\\
|
|
& 1.1 kleinere Anpassungen durch AZ\\
|
|
\hline
|
|
Author & A. Zweili \& I. Cadaroski\\
|
|
\hline
|
|
Date & 24. August 2017\\
|
|
\hline
|
|
\caption{Use Case 1.1 User Login}
|
|
\end{longtable}}
|
|
\newpage
|
|
%% -- End of Use Case Template --
|
|
|
|
%% -- Begining of Use Case Template --
|
|
\subsubsection{Standorte auflisten/suchen}
|
|
{\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|}
|
|
\hline
|
|
%begin title row
|
|
{\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 2.0 Standorte auflisten/suchen} \\ \hline
|
|
%end title row
|
|
Description & Auflisten/suchen der
|
|
Standorte in der Applikation.\\
|
|
\hline
|
|
Actors & User\\
|
|
\hline
|
|
Status & Freigegeben\\
|
|
\hline
|
|
Includes & -\\
|
|
\hline
|
|
Trigger & User möchte Standorte suchen/auflisten.\\
|
|
\hline
|
|
Preconditions & UC 1.1 erfolgreich abgeschlossen\\
|
|
\hline
|
|
Postconditions & -\\
|
|
\hline
|
|
Normal Flow & 1. User gibt einen Suchbegriff ein.\\
|
|
& 2. Die Applikation gibt die passenden Resultate aus.\\
|
|
\hline
|
|
Alternative Flow & -\\
|
|
\hline
|
|
Notes & -\\
|
|
\hline
|
|
UC History & 1.0 Draft erstellt durch AZ\\
|
|
& 1.1 kleinere Anpassungen durch AZ\\
|
|
\hline
|
|
Author & A. Zweili \& I. Cadaroski\\
|
|
\hline
|
|
Date & 24. August 2017\\
|
|
\hline
|
|
\caption{Use Case 2.0 Standorte auflisten/suchen}
|
|
\end{longtable}}
|
|
\newpage
|
|
%% -- End of Use Case Template --
|
|
|
|
%% -- Begining of Use Case Template --
|
|
\subsubsection{Standorte mieten}
|
|
|
|
{\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|}
|
|
\hline
|
|
%begin title row
|
|
{\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 2.1 Standorte mieten} \\ \hline
|
|
%end title row
|
|
Description & Mieten eines Standortes als Test Member.\\
|
|
\hline
|
|
Actors & User mit ``test\_member'' Status\\
|
|
\hline
|
|
Status & Freigegeben\\
|
|
\hline
|
|
Includes & -\\
|
|
\hline
|
|
Trigger & \\
|
|
\hline
|
|
Preconditions & UC 1.1 und 2.0 erfolgreich abgeschlossen\\
|
|
\hline
|
|
Postconditions & Miete wurde erfolgreich in DB eingetragen.\\
|
|
\hline
|
|
Normal Flow & 1. User wählt einen Standort aus\\
|
|
& 2. User wählt das Datum aus an dem er den Standort gerne mieten möchte.\\
|
|
& 3. User bestätigt die Miete mit einem Klick auf den Insert Button.\\
|
|
\hline
|
|
Alternative Flow
|
|
& \textbf{Der Alternative Flow wurde in der Applikation nicht umgesetzt.}\\
|
|
& 1. User wählt einen Standort aus\\
|
|
& 2. User wählt das Datum an dem er den Standort gerne mieten möchte.\\
|
|
& 3. User bestätigt die Miete mit klick auf den Insert Button.\\
|
|
& 4. Die Applikation meldet zurück das der Standort an diesem Datum\\
|
|
& bereits besetzt ist.\\
|
|
\hline
|
|
Notes & -\\
|
|
\hline
|
|
UC History & 1.0 Draft erstellt durch AZ\\
|
|
& 1.1 kleinere Anpassungen durch AZ\\
|
|
\hline
|
|
Author & A. Zweili \& I. Cadaroski\\
|
|
\hline
|
|
Date & 24. August 2017\\
|
|
\hline
|
|
\caption{Use Case 2.1 Standorte Mieten}
|
|
\end{longtable}}
|
|
|
|
\newpage
|
|
%% -- End of Use Case Template --
|
|
|
|
%% -- Begining of Use Case Template --
|
|
\subsubsection{Mieten anzeigen}
|
|
|
|
{\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|}
|
|
\hline
|
|
%begin title row
|
|
{\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 2.2 Mieten anzeigen} \\ \hline
|
|
%end title row
|
|
Description & Betrachten der getätigten Mieten des aktuellen Users.\\
|
|
\hline
|
|
Actors & User mit ``test\_member'' Status\\
|
|
\hline
|
|
Status & Freigegeben\\
|
|
\hline
|
|
Includes & -\\
|
|
\hline
|
|
Trigger & User möchte sich seine Mieten anzeigen lassen\\
|
|
\hline
|
|
Preconditions & UC 1.1, 2.1 erfolgreich abgeschlossen\\
|
|
\hline
|
|
Postconditions & Applikation gibt die Mieten des aktuellen\\
|
|
& Users aus.\\
|
|
\hline
|
|
Normal Flow & 1. User klickt auf ``Show''\\
|
|
& 2. Die Applikation gibt die Details zu den\\
|
|
& Mieten des Users aus.\\
|
|
\hline
|
|
Alternative Flow & -\\
|
|
\hline
|
|
Notes & -\\
|
|
\hline
|
|
UC History & 1.0 Draft erstellt durch AZ\\
|
|
& 1.1 kleinere Anpassungen durch AZ\\
|
|
\hline
|
|
Author & A. Zweili \& I. Cadaroski\\
|
|
\hline
|
|
Date & 24. August 2017\\
|
|
\hline
|
|
\caption{Use Case 2.2 Mieten anzeigen}
|
|
\end{longtable}}
|
|
|
|
\newpage
|
|
%% -- End of Use Case Template --
|
|
|
|
\newpage
|
|
\begin{landscape}
|
|
\section{Stundenplanung}
|
|
|
|
Die grössten Differenzen in unserer Planung sind der C\# Applikation
|
|
nachzuführen. Da wir in diesem Aspekt noch nicht die nötige Erfahrung
|
|
besitzen, musste sehr viel Zeit in Wissensbeschaffung investiert
|
|
werden.
|
|
|
|
|
|
%% -- start Stundenplanung table --
|
|
\footnotesize
|
|
\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{4cm}|p{2.1cm}|p{1.8cm}|p{1.8cm}|p{1.8cm}|p{7cm}|}
|
|
\hline
|
|
%begin title row
|
|
{\cellcolor[HTML]{C0C0C0}\textbf{Aktivität}} &
|
|
{\cellcolor[HTML]{C0C0C0}\textbf{Definition}}
|
|
\footnote{Definition Arbeit ist grundlegend in Dokumentation (Doku) der Lösung
|
|
und erarbeiten des Codes (Code) der dazugehörigen Funktionen aufgebaut} &
|
|
{\cellcolor[HTML]{C0C0C0}\textbf{Planung}} &
|
|
{\cellcolor[HTML]{C0C0C0}\textbf{Leistung}} &
|
|
{\cellcolor[HTML]{C0C0C0}\textbf{Differenz}} &
|
|
{\cellcolor[HTML]{C0C0C0}\textbf{Erklärung}} \\ \hline
|
|
%endtitle row
|
|
Projekt Management & Doku & 10 & 20 & 10 & Wir hatten uns zu Beginn
|
|
darauf festgelegt alle zwei Wochen ein kurzes Meeting abzuhalten. Die
|
|
Meetings wurden dann aber mit durchschnittlich 1h länger als
|
|
ursprünglich angenommen. \\ \hline
|
|
|
|
Dokumentation & Doku & 25 & 45 & 20 & Wir haben bei dieser Arbeit
|
|
wesentlich mehr Zeit in die Dokumentation investiert. Ein Teil davon
|
|
ist sicher der Tatsache zu schulden das wir die Arbeit in LaTeX
|
|
geschrieben haben. \\ \hline
|
|
|
|
Vision & Doku & 1 & 1 & 0 & \ \\ \hline
|
|
|
|
User Stories & Doku & 2 & 2 & 0 & \ \\ \hline
|
|
|
|
ERM erstellen & Doku & 3 & 2 & -1 & Beim RM haben wir weniger Details
|
|
eingezeichnet sondern uns hauptsächlich darauf beschränkt uns eine
|
|
grobe Übersicht zu verschaffen. \\ \hline
|
|
|
|
ERD erstellen & Doku & 4 & 12 & 8 & Die Aufgabenstellung hat sich als
|
|
wesentlich komplizierter herausgestellt als wir angenommen hatten. \\ \hline
|
|
|
|
User Stories(Diagramm) erstellen & & 1 & 1 & 0 & \ \\ \hline
|
|
|
|
Testplan aufgebaut & Doku & 12 & 4 & -8 & Erwies sich als weniger
|
|
Aufwand, als ursprünglich gedacht. Da wir mit den Use Cases bereits
|
|
gute Vorlagen hatten. \\ \hline
|
|
|
|
SQL Code & & & & & \ \\ \hline
|
|
SQL Scripts erstellen & Code & 7 & 8 & 1 & Das erstellen der Testdaten
|
|
Scripts hat etwas mehr Zeit gebraucht als erwartet. Insbesondere da
|
|
wir zuerst versucht haben, die Länder und Städte Listen bereits
|
|
komplett zu erstellen. \\ \hline
|
|
|
|
C\# Code & & & & & \\ \hline
|
|
Frontend (GUI) erstellen & Code & 25 & 30 & 5 & Der Aufbau unseres GUI
|
|
zeigte sich um einiges komplizierte als wir es uns zu Anfang
|
|
vorgestellt haben. Ein grosser Anteil des Aufwanfes ging an die
|
|
Nachforschung des Codes verloren, da wir dies zu diesem Zeitpunkt noch
|
|
nicht angewendet Haben. \\ \hline
|
|
|
|
Datenbankverbindung & Code & 2 & 3 & 1 & Es entstand ein kleiner
|
|
Mehraufwand, da bei Applikation jeweils der Verbindungsstring
|
|
angepasst werden musste Wenn der Code auf einem anderen Computer
|
|
kompiliert wurde. \\ \hline
|
|
|
|
Konzept des Aufbaus & Code & 4 & 4 & 0 & Der Konzeptaufbau (Was
|
|
möchten wir darstellen?), wurde von uns öfters als geplant
|
|
umstrukturiert, hielt sich aber noch Im Zeitrahmen \\ \hline
|
|
|
|
Login und Registration & Code & 4 & 6 & -2 & Die ID- Vergabe und die
|
|
Verarbeitung benötigten mehr Aufwand als vorgesehen \\ \hline
|
|
|
|
Standort-Abfrage & Code & 6 & 9 & 3 & Durch Wissenslücken ging ein
|
|
Grossteil der Zeit in der Infromationssuche verloren \\ \hline
|
|
|
|
Rent-Reservation-Eingabe & Code & 20 & 32 & 12 & Die Übergabe der
|
|
verschiedenen ID`s in der Applikation warfen einige Probleme auf, die
|
|
in der Reservation besonders Zum vorschein gekommen sind \\ \hline
|
|
|
|
Rent-Abfrage & Code & 8 & 8 & 0 & \\ \hline
|
|
|
|
Coding (Verbinden der Funktionen) & Code & 20 & 40 & 20 & Da wir in
|
|
unserer Applikation gleich mehrere Funktionen abgebildet
|
|
haben(Login/Informationsabfrage/ Informationseingabe/Abfrage
|
|
eingefüllter Daten), war das darauffolgende Verbinden des Codes auch
|
|
ein grosser Aufwand \\ \hline
|
|
|
|
Test`s & & & & & \ \\ \hline
|
|
Testplan durchgeführt & Doku & 30 & 15 & -15 & Die Tests haben
|
|
wesentlich weniger Zeit gebraucht als angenommen und wurden meistens
|
|
on the fly gemacht. \\ \hline
|
|
|
|
\textbf{Total} & & \textbf{184} & \textbf{242} & & \\ \hline
|
|
|
|
\caption{Stundenplanung}
|
|
\end{longtable}
|
|
%% -- end Stundenplanung table --
|
|
\end{landscape}
|
|
|
|
\newpage
|
|
|
|
\section{Umsetzung}
|
|
|
|
\subsection{Zusammenarbeit}
|
|
Zur Zusammenarbeit am Code haben wir uns für Git entschieden. Dies
|
|
ermöglichte es uns gleichzeitig am Code zu arbeiten und zwischendurch
|
|
die Änderungen des anderen zu ``mergen''. Dies war von grossem Vorteil
|
|
da wir so unabhängig voneinander am Code weiterarbeiten konnten. So
|
|
entstanden insgesammt über 150 Commits.
|
|
|
|
Desweiteren haben wir uns die Arbeit so aufgeteilt damit wir möglichst
|
|
unabhängig voneinander arbeiten konnten und somit nicht aufeinander
|
|
warten mussten.
|
|
|
|
Andreas hat sich Hauptsächlich mit den SQL Scripts beschäftigt.
|
|
Parallel dazu konnte sich Ismail in das Schreiben einer grafischen C\#
|
|
Applikation einlesen. Sobald die SQL Skripte fertig waren konnte
|
|
Ismail diese nutzen um die Applikation fertig zu stellen.
|
|
|
|
Die Dokumentation wurde dabei fortlaufen erweitert. Da wir die
|
|
Dokumentation in \LaTeX geschrieben haben und somit auch nur aus
|
|
simplen Textdateien besteht konnten wir auch an dieser ohne Probleme
|
|
gleichzeitig arbeiten und über Git versionieren.
|
|
|
|
\subsection{ER Modell und ER Diagramm}
|
|
Gleich zu Beginn des Projektes haben wir den Text zur Aufgabenstellung
|
|
eingehend analysiert und daraus ein Entity-Relationship-Modell(ERM),
|
|
Abbildung: (\ref{fig:rm}) erstellt.
|
|
|
|
Wir haben dabei darauf verzichtet für jede Entität noch die jeweiligen
|
|
Attribute einzuzeichnen da wir uns mit dem ERM Hauptsächlich einen
|
|
Überblick über die Situation verschaffen wollten damit wir die
|
|
Abhängigkeiten zwischen den Entitäten besser nachvollziehen konnten.
|
|
|
|
Im Anschluss wurden dann das Entity-Relationship-Diagramm(ERD),
|
|
Abbildung: (\ref{fig:erm}) erstellt. Dies wurde mit allen Details
|
|
erstellt. Im ERD haben wir auch Eigenschaften von Attributen erfasst
|
|
welche in der exportieren Übersicht hier in der Dokumentation nicht
|
|
ersichtlich sind, wie etwa ``Unique'', ``Not Null'', etc. Aus dem ERD
|
|
konnten dann relativ schnell die SQL Scripts abgeleitet werden.
|
|
|
|
\subsection{SQL Datenbank}
|
|
|
|
Nachfolgend werden die Entitäten der Datenbank kurz beschrieben damit
|
|
das ERD Diagramm, Abbildung: (\ref{fig:erm}) besser verstanden werden
|
|
kann. Dabei wird zuerst der Name der Tabelle in der Datenbank
|
|
aufgelistet gefolgt von der deutschen Übersetzung.
|
|
|
|
\paragraph{persons / (Personen)}
|
|
Sind die Repräsentation einer realen Person in der Datenbank. Hier
|
|
werden auch die Adressdaten eines Mitgliedes gespeichert.
|
|
|
|
\paragraph{salutation / (Anreden)}
|
|
Enthält die möglichen Anreden für Personen.
|
|
|
|
\paragraph{cities / (Städte)}
|
|
Enthält Städtenamen sowie die dazugehörige Postleizahl und einem
|
|
Verweis zu welchem Land die jeweilige Stadt gehört.
|
|
|
|
\paragraph{countries / (Länder)}
|
|
Enthält eine Liste mit Ländernamen.
|
|
|
|
\paragraph{locations / (Standorte)}
|
|
Diese Tabelle enthält die Daten der Standorte wo die jeweiligen Märkte
|
|
abgehalten werden. Dabei wird auch erfasst wie viel Kapazität der
|
|
jeweilige Standort hat damit mein ein Überbuchen verhindern kann.
|
|
|
|
\paragraph{members / (Mitglieder)}
|
|
Sind die eigentlichen User im System. In der Regel verweisen sie auf
|
|
eine reale Person können zu Testzwecken aber auch ohne eine reale
|
|
Person im Hintergrund angelegt werden. Diese Entität wird dabei auch
|
|
mit den jeweiligen Käufen verbunden damit man nachvollziehen kann wer
|
|
diese getätigt hat. Hier wird auch gespeichert ob das Mitglied die
|
|
notwendigen Dokumente unterzeichnet und die Kreditüberprüfung bestanden
|
|
hat.
|
|
|
|
\paragraph{member\_status / (Mitgliedsstatus)}
|
|
Die Mitgliedsstatus Tabelle enthält die möglichen Stati die ein
|
|
Mitglied haben kann. Dabei werden hier auch Mitglieder Stati wie
|
|
Mitarbeiter oder Admin erfasst.
|
|
|
|
\paragraph{subscribtions / (Abonnemente)}
|
|
Beschreiben die Abonnementsarten welche von den Mitgliedern gekauft
|
|
werden können.
|
|
|
|
\paragraph{commercials / (Werbung)}
|
|
Diese Tabelle enthällt alle Daten zu Änderungen des Webauftritt eines
|
|
Mitgliedes. Diese Tabelle wird benötigt damit sichergestellt werden
|
|
kann das ein Mitglied nur nur die zugelassene Anzahl an Änderungen
|
|
beantragt.
|
|
|
|
Je nach Kundenwunsch könnte man diese noch erweitern um zusätzliche
|
|
Daten zu erhalten. Etwa eine Überprüfung auf die Grösse der Änderungen
|
|
um zu überprüfen wie fest die Funktion von den Mitgliedern genutzt
|
|
wird.
|
|
|
|
\paragraph{quality\_checks / (Qualitätschecks)}
|
|
Beschreibt die Beziehung zwischen zwei Mitglieder wobei eines der
|
|
Mitglieder der Prüfer und ein anderes Mitglied der Geprüfte ist.
|
|
Zusätzlich wird erfasst an welchem Tag der Check geplant ist und Ob
|
|
der Check bestanden wurde.
|
|
|
|
\paragraph{subscription\_orders / (Abonnementsbestellungen)}
|
|
Enthält die Abokäufe die ein Mitglied macht und welcher Standort dabei
|
|
gewählt wurde Sowie an welchem Tag der Kauf getätigt wurde. Das
|
|
Kaufdatum kann in der finalen Version dazu verwendet werden zu
|
|
berechnen ob das aktuelle Abo noch gültig ist oder nicht.
|
|
|
|
\paragraph{trial\_period / (Probezeit)}
|
|
Beinhaltet die Zeit wie lange die Probezeit ist damit diese nicht als
|
|
ein Fixwert im Code abgelegt werden muss. Diese sollte es ermöglichen
|
|
das die Dauer der Probezeit auch nachträglich noch einfach angepasst
|
|
werden kann.
|
|
|
|
\paragraph{rents / (Mieten)}
|
|
Beinhaltet die Mieten welche ein Mitglied in der Probezeit getätigt
|
|
hat. Dabei wird über den Mietpreis der Standort definiert der
|
|
gemietet wird und mit einem Datumsfeld wird angegeben an welchem Tag
|
|
der Platz reserviert wurde.
|
|
|
|
\paragraph{rent\_prices / (Mietpreise)}
|
|
Diese Tabelle weist jedem Standort einen Preis zu. Dies ermöglicht es die
|
|
Preise für jeden Standort flexibel zu halten und den regionalen
|
|
Interessengruppen anzupassen.
|
|
|
|
\paragraph{RentedLocations}
|
|
Damit wir die getätigten Mieten in der Applikation sauber ausgeben
|
|
können war es nötig eine View zu erstellen. Diese behinhaltet drei
|
|
``inner joins'' über die Tabellen ``members'', ``rents'',
|
|
``rent\_prices'' und ``locations''. Somit kann man einsehen welches
|
|
Mitglied an welchem Ort und zu welchem Preis einen Stand gemietet hat.
|
|
|
|
\begin{landscape}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[height=0.8\textheight]{diagrammes/rm.png}
|
|
\caption{Entity-Relationship-Modell\label{fig:rm}}
|
|
\end{figure}
|
|
\end{landscape}
|
|
|
|
|
|
\begin{landscape}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[scale=0.38]{diagrammes/erm.png}
|
|
\caption{Entity-Relationship-Diagramm\label{fig:erm}}
|
|
\end{figure}
|
|
\end{landscape}
|
|
|
|
\subsection{C\#}
|
|
|
|
In dieser Sektion wird das Erstellen einer kleiner Anwendung
|
|
beschrieben, in der wir gewisse Segmente unserer Datenbank abrufen und
|
|
bearbeiten können. Damit zeigen wir die Funktionalität und
|
|
Verarbeitung unsere Datenbank auf.
|
|
|
|
\subsubsection{Verbindung zur Datenbank}
|
|
|
|
Um die Verbindung ( connectionstring ) abrufen zu können, erstellen
|
|
wir eine ``Helper'' Klasse. Darin haben wir den Verbindungspfad
|
|
definiert der beim Verbindungsaufbau in App.config aufgerufen wird.
|
|
Den definitiven (connectionstring) haben wir in ``App.config'' bestimmt.
|
|
|
|
\subsubsection{grafische Oberfläche}
|
|
|
|
Die grafische Oberfläche (GUI) wurde beim Aufbauen des Projektes als
|
|
``Windows Form Application'' gestartet und ``Dashboard'' genannt. Nach
|
|
dem Anpassen der Grösse, haben wir eine ``ListBox'' eingesetzt und sie
|
|
umbenannt. Sie dient dazu, zukünftig gesuchte Daten darin aufzuführen.
|
|
Um die gesuchten Daten eingebe zu können, haben wir danach eine
|
|
``TextBox'' eingefügt. Sobald die gesuchten Daten in der ``TextBox''
|
|
eingegeben wurden, werden die Informationen aufgerufen und in der
|
|
``ListBox'' aufgezeigt.
|
|
|
|
\subsubsection{Definition der Klassen}
|
|
|
|
Hier werden alle eingesetzten Klassen der Applikation vorgestellt
|
|
und definiert.
|
|
|
|
Zu jeder Klasse gibt es eine passende Grafik welche ihre Methoden und
|
|
Attribute beschreibt. Nachfolgend habe wir eine Beispiel Grafik, Abbildung:
|
|
(\ref{fig:class_example}) eingefügt welche die Symbole und den Aufbau
|
|
beschreibt.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[scale=0.23]{diagrammes/example.png}
|
|
\caption{Beispiel Klassen\label{fig:class_example}}
|
|
\end{figure}
|
|
|
|
\paragraph{Programm}
|
|
Beinhaltet die Main Klasse von wo aus alle anderen Klassen und Funktionen
|
|
aufgerufen werden.
|
|
|
|
\paragraph{Helper}
|
|
Helper.cs dient dem Zweck, den Pfad der Datenbank nicht in jeder
|
|
Methode eingeben zu müssen. Dafür haben wir in dieser Klasse den
|
|
Verbindungsaufbau durch den Configuration.Manager definiert. Den Pfad
|
|
zur Datenbank muss dadurch nur ein einziges Mal in App.config
|
|
definiert werden und kann dann durch die Helper.cs Klasse simpel
|
|
aufgerufen werden.
|
|
|
|
\paragraph{LoginForm}
|
|
Diese Klasse, Abbildung: (\ref{fig:login_class}) wurde für das
|
|
Registrieren und Einloggen des Benutzers mit einem dazugehörigen GUI
|
|
von uns erstellt. Dadurch können sich Benutzer durch das Eingeben der
|
|
Email-Adresse und des Passwortes mit dem ``Register-Button''
|
|
Registrieren. Bei erfolgreicher Registrierung erhalten sie dann eine
|
|
entsprechende Meldung, Abbildung: (\ref{fig:register}). Durch ein
|
|
zweites Eingeben der Daten und betätigen des ``Login-Button'' können
|
|
sie sich dann auch gleich einloggen, Abbildung: (\ref{fig:login}).
|
|
Nach dem erfolgreichen Login wird der User dann auf das Dashboard
|
|
weitergeleitet.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[scale=0.23]{diagrammes/loginform.png}
|
|
\caption{LoginForm Klasse}
|
|
\label{fig:login_class}
|
|
\end{figure}
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\frame{\includegraphics[scale=0.7]{screenshots/register.png}}
|
|
\caption{Screenshot der Registrierung}
|
|
\label{fig:register}
|
|
\end{figure}
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\frame{\includegraphics[scale=0.7]{screenshots/login.png}}
|
|
\caption{Screenshot der LoginForm}
|
|
\label{fig:login}
|
|
\end{figure}
|
|
|
|
\newpage
|
|
|
|
\paragraph{Dashboard}
|
|
Auf dem Dashboard, Abbildung: (\ref{fig:dashboard_class}), haben wir
|
|
den Kern was Informationen herauslesen und wieder Eingeben belangt,
|
|
erstellt. In dieser Klasse werden die aus der Datenbank
|
|
herausgelesenen Daten der ``locations'' und ``rents'' Tabellen im GUI,
|
|
Abbildung: (\ref{fig:dashboard}) aufgezeigt und/ oder eingefügt. Damit
|
|
möchten wir einen Teil der finalen Applikation und Datenbank abbilden
|
|
mit dem, die Benutzer Standorte heraussuchen und den Mietbeginn
|
|
eingegeben können. Um einen Standort zu mieten muss ein User sich
|
|
zuerst einen Standort heraussuchen und diesen markieren. Anschliesend
|
|
kann er das passende Datum markieren und zum Abschluss die Miete mit
|
|
dem ``Rent-Button'' tätigen.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[scale=0.23]{diagrammes/dashboard.png}
|
|
\caption{Dashboard Klasse}
|
|
\label{fig:dashboard_class}
|
|
\end{figure}
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\frame{\includegraphics[width=0.9\textwidth]{screenshots/dashboard.png}}
|
|
\caption{Screenshot des Dashboards}
|
|
\label{fig:dashboard}
|
|
\end{figure}
|
|
|
|
\paragraph{DataAccess}
|
|
Mit der DataAccess Klasse, Abbildung: (\ref{fig:dataaccess}) konnten wir
|
|
nahezu alle Datenbank relevanten Funktionen, die in unserem GUI
|
|
ausgeführt werden, in einer einzigen Klasse abbilden. Darin haben wir
|
|
den Aufruf der Datenbanktabellen mit den dazu benötigten SQL -
|
|
Befehlen ausgeführt. Dadurch wird SQL- Code so gut wie nur in dieser
|
|
Klasse aufgerufen und diesbezüglich verwendet. Unter anderem wird auch
|
|
der Login des Benutzers darin geprüft.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[scale=0.23]{diagrammes/dataaccess.png}
|
|
\caption{DataAccess Klasse}
|
|
\label{fig:dataaccess}
|
|
\end{figure}
|
|
|
|
\paragraph{Get-``Klassen''}
|
|
|
|
Um Daten herauszulesen oder zur Datenbank zu schicken, haben wir in
|
|
C\# Klassen der ``locations'', ``rents'' und ``members'' erstellt, die
|
|
sie abbilden. Damit nehmen die dazu benötigten Spalten der jeweiligen
|
|
Tabellen entgegen. Danach werden die benötigten Datensätze mit den
|
|
``Methoden-Infos'' der derweiligen Klasse aufgerufen.
|
|
|
|
Die ``GetMembers'' Klasse, Abbildung: (\ref{fig:getmembers}), wird für
|
|
die Registration und den Login der Mitglieder benötigt:
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[scale=0.23]{diagrammes/getmembers.png}
|
|
\caption{GetMembers Klasse}
|
|
\label{fig:getmembers}
|
|
\end{figure}
|
|
|
|
Die ``GetLocations'' Klasse, Abbildung: (\ref{fig:getlocations}), für
|
|
das Herauslesen der Märkte um dem Mitglied alle im Moment
|
|
hinzugefügten Mietoptionen darzubieten:
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[scale=0.23]{diagrammes/getlocations.png}
|
|
\caption{GetLocations Klasse}
|
|
\label{fig:getlocations}
|
|
\end{figure}
|
|
|
|
Die ``GetRents'' Klasse, Abbildung: (\ref{fig:getrents}), für`s Mieten
|
|
und Abbilden der jeweiligen Märkte:
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[scale=0.23]{diagrammes/getrents.png}
|
|
\caption{GetRents Klasse}
|
|
\label{fig:getrents}
|
|
\end{figure}
|
|
|
|
\subsubsection{Probleme}
|
|
|
|
\begin{itemize}
|
|
\item Verbindungsaufbau
|
|
Der Verbindungsaufbau zur Datenbank musste immer an den jeweiligen
|
|
Test-Anwender der Datenbank angepasst werden.
|
|
|
|
\item Insert Data
|
|
Nach den ersten Test's wurde uns klar, dass wir ein Problem mit
|
|
der weitergabe der ID's hatten. Der Fehler kam erst ans Licht, als wir
|
|
anfingen die jeweiligen ``locations'' und ``members''- ID's durch das
|
|
GUI einzufügen. Gelöst wurde das ganze mit einer statischen Klasse.
|
|
|
|
\end{itemize}
|
|
|
|
\subsubsection{Addons/ Packages}
|
|
Dapper \cite{dbcs6} ist ein simpler ``object mapper'' für .NET. Wir
|
|
nutzen ihn anstelle von einem ADO.NET data reader da er nütziche
|
|
Erweiterungen bei unserer IDbConnection bietet, indem er
|
|
Erweiterungsmethoden zur Datenbankabfrage bietet.
|
|
|
|
Dapper erweitert unsere IDbConnection verwendung mit mehreren Methoden wie :
|
|
\begin{itemize}
|
|
\item Execute
|
|
\item Query
|
|
\item QueryFirst
|
|
\item QueryFirstOrDefault
|
|
\item QuerySingle
|
|
\item QuerySingleOrDefault
|
|
\item QueryMultiple
|
|
\end{itemize}
|
|
Weiter Infos unter : http://dapper-tutorial.net/dapper
|
|
|
|
\newpage
|
|
\begin{landscape}
|
|
\section{Testfälle}
|
|
|
|
%% -- start Test Case table --
|
|
\footnotesize
|
|
\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{1.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|}
|
|
\hline
|
|
%begin title row
|
|
\cellcolor[HTML]{C0C0C0}Testcase ID & \cellcolor[HTML]{C0C0C0}Objektive &
|
|
\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 \\ \hline
|
|
% end title row
|
|
|
|
TC-01 & Registrierung am System & - & 1. Öffnen des Programms \newline
|
|
2. Eingeben des Usernamens \newline
|
|
3. Eingeben des Passworts\newline
|
|
4. Klicken des ``Register'' Knopf & Username: muster@gmx.ch Passwort:
|
|
123456 & Pop-up mit ``Member Registered'' Text erscheint & User
|
|
registriert & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline
|
|
|
|
TC-02 & Registrierung am System & TC-01 ausgeführt. & 1. Öffnen des
|
|
Programms \newline
|
|
2. Eingeben des Usernamens \newline
|
|
3. Eingeben des Passworts \newline
|
|
4. Klicken des ``Register'' Knopf & Username: \newline
|
|
muster@gmx.ch Passwort: \newline
|
|
123456 & Fehlermeldung: \newline
|
|
“User already exists.” & Login / Registrierung Wird wieder
|
|
angezeigt & Beim ersten Durchführen fehlte Noch eine Try/Catch
|
|
Funktion Was die Applikation zum Abstürzen brachte. Erfolgreich
|
|
durchgeführt. 13.08.2017 I.C. \\ \hline
|
|
|
|
TC-03 & Anmeldung am System & TC-01 ausgeführt. & 1. Öffnen des Programms \newline
|
|
2. Eingeben des Usernamens \newline
|
|
3. Eingeben des Passworts \newline
|
|
4. Klicken des ``Login'' Knopf \newline
|
|
5. Quittieren des Pop-Up & Username: \newline
|
|
muster@gmx.ch Passwort: \newline
|
|
123456 & Der User wird zum Dashboard weitergeleitet & Dashboard wird
|
|
Angezeigt. & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline
|
|
|
|
TC-04 & Anmeldung am System & TC-01 ausgeführt. & 1. Öffnen des Programms \newline
|
|
2. Eingeben des Usernamens \newline
|
|
3. Eingeben des Passworts \newline
|
|
4. Klicken des ``Login'' Knopf \newline
|
|
5. Fehlermeldung quittieren & Username: \newline
|
|
muster@gmx.ch Passwort: \newline
|
|
WrongPassword & Fehlermeldung: \newline
|
|
``Username or Password Not correct.'' & Login / Registrierung Wird
|
|
wieder angezeigt & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline
|
|
|
|
TC-05 & Anmeldung am System & - & 1. Öffnen des Programms \newline
|
|
2. Eingeben des Usernamens \newline
|
|
3. Eingeben des Passworts \newline
|
|
4. Klicken des ``Login'' Knopf \newline
|
|
5. Fehlermeldung quittieren & Username: \newline
|
|
muster@gmx.ch Passwort: \newline
|
|
123456 & Fehlermeldung: \newline
|
|
``Username or Password Not correct.'' & Login / Registrierung Wird
|
|
wieder angezeigt & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline
|
|
|
|
TC-06 & Standorte anzeigen & TC-01 und TC-03 Ausgeführt & 1.
|
|
Suchbegriff eingeben 2. ``Search'' Knopf klicken & Suchbegriff: \newline
|
|
Markt & Suchresultat: \newline
|
|
``Markstrasse 300 Testmarkt'' erscheint & Suchresultat wird Angezeigt.
|
|
& Zuerst wurde mit ``equal'' gesucht was es sehr Schwierig machte zu
|
|
suchen. Wurde zu ``like'' korrigiert. Erfolgreich durchgeführt.
|
|
27.07.2017 A.Z. \\ \hline
|
|
|
|
TC-07 & Standorte anzeigen & TC-01 und TC-03 Ausgeführt & 1. keinen
|
|
Suchbegriff eingeben 2. ``Search'' Knopf klicken & & Suchresultat: \newline
|
|
``Markstrasse 300 Testmarkt Teststrasse 450 Testmark2'' Erscheint &
|
|
Suchresultat wird Angezeigt. & Erfolgreich durchgeführt. 27.07.2017
|
|
A.Z. \\ \hline
|
|
|
|
TC-08 & Standort mieten & TC-01, TC-03 und
|
|
TC-06 ausgeführt. & 1. keinen Suchbegriff eingeben \newline
|
|
2. ``Search'' Knopf klicken \newline
|
|
3. beliebigen Standort wählen \newline
|
|
4. Mietdatum auswählen \newline
|
|
5. ``Rent'' Knopf klicken & & Miete wird in Datenbank Verbucht. & &
|
|
Erfolgreich durchgeführt. 22.08.2017 I.C. \\ \hline
|
|
|
|
TC-09 & Mieten anzeigen & TC-01, TC-03, TC-06 Und TC-08 ausgeführt &
|
|
1. ``Refresh'' Knopf klicken & & Die ``Rents'' Liste wird Aktualisiert
|
|
und gibt Die in TC-08 getätigte Miete aus. & Mietliste wurde Befüllt.
|
|
& Erfolgreich durchgeführt. 22.08.2017 I.C. \\ \hline
|
|
|
|
% TC-11 & & & & & & & \\ \hline
|
|
\caption{Testfälle}
|
|
\end{longtable}
|
|
%% -- end test case table --
|
|
\end{landscape}
|
|
|
|
\section{Fazit}
|
|
|
|
Im Bezug auf die Planung verlief diese Case Study wesentlich besser
|
|
als die vorherige. Insbesondere die Zeitplanung lief sehr gut. Wir
|
|
hatten zwar geplant nach den Sommerferien mit der Arbeit fertig zu
|
|
sein was wir schlussendlich nicht erreicht hatten. Jedoch wurden wir
|
|
ca. einen Monat später, Anfangs September, mit dem grössten Teil der
|
|
Arbeit fertig und lagen somit immer noch sehr gut in der Zeit.
|
|
|
|
Durch die regelmässigen Meetings waren wir bezüglich dem Fortschritt
|
|
immer auf dem aktuellsten Stand. Zusätzlich ermöglichten uns die
|
|
Meetings frühzeitig Korrekturen bezüglich der Planung vorzunehmen und
|
|
somit allfällige Probleme zu umgehen.
|
|
|
|
Desweiteren hatten wir so auch ideal Zeit technische Schwierigkeiten
|
|
miteinander zu besprechen. Wie etwa wie wir gewisse Entitäten abbilden
|
|
wollen oder bei Problemen bei der C\# Applikation.
|
|
|
|
Die C\# Applikation war insgesamt der grösste Knackpunkt dieser
|
|
Casestudy. Die Anwendung funktioniert soweit wie geplant könnte in
|
|
dieser Form allerdings wohl eher nicht produktiv eingesetzt werden.
|
|
|
|
Der Aufbau der Datenbank hat uns dazu im Vergleich verhältnismässig
|
|
wenig Probleme bereitet. Das Hauptproblem dabei war hauptsächlich die
|
|
schwammige Beschreibung der Anforderung des Kunden.
|
|
|
|
Wie auch in der letzten Case Study hat sich das Arbeiten mit Git
|
|
wieder bewährt. Allerdings könnten wir uns die Funktionen von Git
|
|
stärker zu nutzen machen. Etwa Test Branches erstellen um schnell
|
|
etwas zu testen oder die Commits noch sauberer zu erstellen damit man
|
|
einfacher mit ihnen arbeiten kann.
|
|
|
|
Bezüglich der Dokumentation haben wir uns ein gute und stabile
|
|
Umgebung in \LaTeX aufgebaut welche wir so nun auch ohne weiteres in
|
|
späteren Arbeiten verwenden können. Insbesondere die Tabellen werden
|
|
wir sehr gut auch in späteren Projekten nutzen können.
|
|
|
|
%%% Local Variables:
|
|
%%% mode: latex
|
|
%%% TeX-master: "main"
|
|
%%% End:
|