ws
This commit is contained in:
M.Scholz
parent
af9e600509
commit
022387806c
Binary file not shown.
@ -37,7 +37,7 @@
|
||||
\newglossaryentry{WSDL}{name={WSDL},description={Web Services Description Language: Beschreibungssprache für Webservices}}
|
||||
\newglossaryentry{XML}{name={XML},description={Extensible Markup Language: Auszeichnungssprache zur hierarchisch struktierten Darstellung von Daten in Textdatenform}}
|
||||
\newglossaryentry{XHTML}{name={XHTML},description={Extensible Hypertext Markup Language: Auszeichnungssprache zur strukturierten Darstellung von Texten, Bildern und Hyperlinks in Textform}}
|
||||
\newglossaryentry{MVC}{name={MVC-Designprinzip}, plural={MVC-Designprinzipes}, description={Model-View-Controller. Architekturmuster zur Strukturierung von Softwareentwicklung. Mehr unter: \href{http://de.wikipedia.org/wiki/Model_View_Controller}{http://de.wikipedia.org/wiki/Model_View_Controller}}}
|
||||
\newglossaryentry{MVC}{name={MVC-Pattern}, description={Model-View-Controller. Entwurfsmuster zur Strukturierung von Softwareentwicklung. Mehr unter: \href{http://de.wikipedia.org/wiki/Model_View_Controller}{http://de.wikipedia.org/wiki/Model_View_Controller}}}
|
||||
\newglossaryentry{Browser-Sandbox}{name={Browser Sandbox}, description={Browser Sandbox in ein Onlinetool, welches über die Seite \href{http://spoon.net/browsers/}{http://spoon.net/browsers/} erreichbar ist.}}
|
||||
|
||||
|
||||
@ -115,30 +115,34 @@ Der Themenbereich umfasst die Umstellung der \gls{API} auf eine neue Datenbank u
|
||||
|
||||
\subsection{Funktionalität}
|
||||
\label{Ziel:Funktionalitaet}
|
||||
Die Funktionalität gliedern wir in die drei Qualitätsmerkmale \textit{Richtigkeit}, \textit{Interoperabilität} und \textit{Sicherheit}, welche wir nach \cite{ISO/IEC 9126} definieren. Diese Punkte werden von unserem Auftraggeber gefordert.
|
||||
Die Funktionalität unterteilen wir in die drei Qualitätsmerkmale \textit{Richtigkeit}, \textit{Interoperabilität} und \textit{Sicherheit}, welche wir nach \cite{ISO/IEC 9126} definieren. Diese Punkte werden von unserem Auftraggeber gefordert.
|
||||
\begin{itemize}
|
||||
\item Richtigkeit: \\
|
||||
Da an dem gesamten Projekt da-sense viele Studenten mitwirken, können wir nicht für jede existierende Funktion die Richtigkeit garantieren. Wir beschränken uns hierbei auf die Funktionen der Datenbankinteraktionen und der Darstellung der neuen Visualisierung, welche von uns selbst implementiert werden.
|
||||
\item Sicherheit: \\
|
||||
Das Merkmal der Sicherheit wird beim Datenaustausch zwischen Smartphones bzw. \gls{Waspmote Sensoren} und der API gefordert. Hierbei muss die Anwendung resistent gegenüber Angriffen, z.B. in Form einer \gls{SQL-Injection}, sein.
|
||||
Das Merkmal der Sicherheit wird beim Datenaustausch zwischen Smartphones bzw. \gls{Waspmote Sensoren} und der API gefordert. Hierbei muss die Anwendung resistent gegenüber Angriffen, z.B. in Form von \glspl{SQL-Injection}, sein.
|
||||
\item Interoperabilität: \\
|
||||
Das Merkmal der Interoperabilität wird im zweiten Teil des Praktikums, bei der Visualisierung der gesammelten Daten, gewährleistet. Die Darstellung der Daten muss in allen gängigen Webbrowsern (Firefox, Chrome, Internet Explorer und Safari) fehlerfrei sein.
|
||||
Das Merkmal der Interoperabilität wird im zweiten Teil des Praktikums, bei der Visualisierung der gesammelten Daten, gewährleistet. Die Darstellung der gesammelten Daten muss in allen gängigen Webbrowsern (Firefox, Chrome, Internet Explorer und Safari) fehlerfrei sein.
|
||||
\end{itemize}
|
||||
Die Maßnahmen, die wir ergreifen, um die beschriebenen Qualitätsmerkmale zu erreichen, sind in Abschnitt \ref{Masnahme:Funktionalitaet} beschrieben.
|
||||
Die Maßnahmen, die wir ergreifen, um die beschriebenen Qualitätsmerkmale zu erreichen, sind in Abschnitt \ref{Masnahme:Funktionalitaet} aufgeführt.
|
||||
|
||||
\subsection{Benutzbarkeit}
|
||||
\label{Ziel:Benutzbarkeit}
|
||||
Die Benutzbarkeit gliedern wir in die drei Qualitätsmerkmale \textit{Verständlichkeit}, \textit{Bedienbarkeit} und \textit{Attraktivität}, welche wir nach \cite{ISO/IEC 9126} definieren. Diese Punkte werden von unserem Auftraggeber im zweiten Teil des Praktikums gefordert. \\
|
||||
Der Hintergrund, warum diese Merkmale gewählt werden, ist der Folgende:\\
|
||||
Durch eine leicht verständliche, attraktive Visualisierung der gesammelten Daten und einer einfachen Bedienbarkeit der Benutzeroberfläche, wird der Bekanntheitsgrad von da-sense weiter steigen. Durch den höheren Bekanntheitsgrad erhofft sich unser Auftraggeber eine breite Verteilung der kommenden Android-App von da-sense, mit welcher die Nutzer selbst Daten sammeln können. Diese werden schließlich in die Datenbank transferiert und sind somit über die Webapplikation abrufbar. \\
|
||||
Die Maßnahmen, die wir ergreifen, um die beschriebenen Qualitätsmerkmale zu erreichen, sind in Abschnitt \ref{Masnahme:Benutzbarkeit} beschrieben.
|
||||
Die Benutzbarkeit unterteilen wir in die drei Qualitätsmerkmale \textit{Verständlichkeit}, \textit{Bedienbarkeit} und \textit{Attraktivität}, welche wir nach \cite{ISO/IEC 9126} definieren. Diese Punkte werden von unserem Auftraggeber im zweiten Teil des Praktikums gefordert. \\
|
||||
Eine intuitive und leicht bedienbare Benutzeroberfläche steigert die Aufmerksamkeit des
|
||||
Besuchers und verhilft dem Projekt zu einem höheren Bekanntheitsgrad. Ebenso kommt hierbei
|
||||
eine moderne und attraktive Visualisierung der Daten zum Einsatz, die die Informations-
|
||||
erfassung unterstützt. Durch das Bekanntwerden des Projekts erhofft sich unser Auftrag-
|
||||
geber eine breite Verteilung der kommenden da-sense Android-App, mit der Benutzer Daten
|
||||
sammeln und auf die Datenbank transferieren können. Die Daten sind über die Webapplikation
|
||||
abrufbar.\\
|
||||
Die Maßnahmen, die wir ergreifen, um die beschriebenen Qualitätsmerkmale zu erreichen, sind in Abschnitt \ref{Masnahme:Benutzbarkeit} aufgeführt.
|
||||
|
||||
|
||||
\subsection{Quellcode (TODO überarbeiten)} % TODO subsection überarbeiten
|
||||
\subsection{Quellcode}
|
||||
\label{Ziel:Codequalitaet}
|
||||
>>Any fool can write code that a computer can understand. Good programmers write code that humans can understand.<< \cite{fowler}. \\
|
||||
Der Quellcode, der im Rahmen des Projektes erstellt wird, ist offen für Erweiterungen und wird von weiteren Gruppen genutzt. Daher muss darauf geachtet werden, dass sämtliche Codebausteine auch für Außenstehende lesbar und verständlich sind. Zudem ist davon auszugehen, dass das Projekt in Zukunft als Open Source Projekt veröffentlicht wird, so dass auch unifremde Entwickler Zugriff haben und von der bestehenden Codequalität profitieren werden. \\
|
||||
Um dieses Ziel erreichen zu können, treffen wir die folgende Vereinbarungen:
|
||||
Der Quellcode des Projektes ist offen für Erweiterungen und wird von weiteren Gruppen genutzt. Daher muss darauf geachtet werden, dass sämtliche Codebausteine auch für Außenstehende lesbar und verständlich sind. Geplant ist die Veröffentlichung des Quellcodes, so dass auch unifremde Entwickler Zugriff haben und von der bestehenden Codequalität profitieren. Um dieses Ziel erreichen zu können, treffen wir folgende Vereinbarungen:
|
||||
\begin{itemize}
|
||||
\item Codedokumentation: \\
|
||||
Jede von uns geschriebene Funktion besitzt einen Kommentarkopf der folgenden Form: \\
|
||||
@ -148,15 +152,12 @@ Um dieses Ziel erreichen zu k
|
||||
* @return \textit{returntype} \\
|
||||
* @tested \textit{boolean} \\
|
||||
**/ \\
|
||||
Wobei \textit{Description} durch einen funktionsbeschreibenden Text, \textit{paramtype} durch den Parametertyp, \textit{returntype} durch den Rückgabewert und \textit{boolean} durch den Wahrheitswert \glqq true\grqq\ bzw. \glqq false\grqq\ zu ersetzen sind.\\
|
||||
Somit erhalten die weiteren Entwickler schnell einen Überblick über die vorliegende Funktion und ihre Auswirkung.
|
||||
Wobei \textit{Description} durch einen funktionsbeschreibenden Text, \textit{paramtype} durch den Parametertyp, \textit{returntype} durch den Rückgabewert und \textit{boolean} durch den Wahrheitswert \glqq true\grqq\ bzw. \glqq false\grqq\ zu ersetzen sind. Somit erhalten die weiteren Entwickler schnell einen Überblick über die vorliegende Methode und ihre Funktionsweise.
|
||||
\item Struktur: \\
|
||||
Eine gute Codestruktur dient ...
|
||||
Wir trennen im Quellcode strikt HTML, JavaScript und PHP. Die Trennung erhöht die Lesbarkeit, vereinfacht die Fehlersuche und reduziert die Fehlerrate. Zusätzlich nutzen wir das \gls{MVC} zur sinnvollen Codestrukturierung.
|
||||
|
||||
\item Namenskonvention: \\
|
||||
Als Konvention nutzen wir CamelCase, welche in Java als Standard gilt und zu einer besseren Lesbarkeit von Bezeichnern beiträgt.
|
||||
\item Wiki: \\
|
||||
Zusätzlich zu den Kommentaren im Code wird ein Wiki gepflegt, das im \gls{Git} abrufbar ist und somit der besseren Verständlichkeit des Projekts durch andere Gruppen beiträgt.
|
||||
\item Namenskonvention: \\ %Glossareintrag zu CamelCase schreiben
|
||||
Wir benutzen die CamelCase Konvention, welche unter anderem in Java als Standard gilt und zu einer besseren Lesbarkeit von Bezeichnern beiträgt.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
@ -188,16 +189,16 @@ Um dieses Ziel erreichen zu k
|
||||
|
||||
\subsection{Funktionalität}
|
||||
\label{Masnahme:Funktionalitaet} % ß wird von LaTex nicht akzeptiert als Label
|
||||
Die Maßnahmen zur Sicherung der einzelnen Funktionalitätmerkmale lassen sich wie folgt gliedern:
|
||||
Zur Sicherung der einzelnen Funktionalitätsmerkmale werden die folgenden Maßnahmen ergriffen:
|
||||
\begin{itemize}
|
||||
\item Richtigkeit: \\
|
||||
|
||||
|
||||
\item Sicherheit: \\
|
||||
Um resistent gegenüber \glspl{SQL-Injection} zu sein, nutzen wir die freie Bibliothek \gls{Propel}. Diese nutzt Preparestatements, wodurch SQL-Code und Daten getrennt werden. Der Eintrag der Daten über die \gls{API} erfolgt mittels HTTP-GET Parameter. Um zu verhindern, dass ein unberechtigter Nutzer Daten einfügen kann, muss sich dieser vor der Datenübermittlung authentifizieren. Die Implementierung der Authentifizierung ist jedoch nicht Bestandteil unserer Aufgaben.
|
||||
Das von uns verwendete ORM-Framework \gls{Propel} nutzt Prepared Statements, mit denen sich \glspl{SQL-Injection} wirksam unterbinden lassen. Hierbei werden SQL-Code und Daten getrennt. Zudem erfordert Propel keine SQL Kentnisse, wodurch für neue Entwickler der Einstieg erleichtert wird. Der Eintrag der Daten über die \gls{API} erfolgt mittels HTTP-GET Parameter. Bevor die Aufnahme neuer Daten in die Datenbank erfolgen kann, ist eine Authentifizierung des Nutzers notwendig. Die Implementierung der Authentifizierung unterliegt nicht unserem Aufgabenbereich.
|
||||
|
||||
\item Interoperabilität: \\
|
||||
Um die Interoperabilität der einzelnen Webbrowser sicherzustellen, bekommt jedes Teammitglied einen Browser zugewiesen, den er testet. Hierbei haben wir uns auf folgende Aufteilung geeinigt: \newline
|
||||
Um die Interoperabilität mit den einzelnen Webbrowsern sicherzustellen, bekommt jedes Teammitglied einen Browser zugewiesen, den er testet. Hierbei haben wir uns auf folgende Aufteilung geeinigt: \newline
|
||||
|
||||
\begin{tabular}{| l | l |}
|
||||
\hline \textbf{Webbrowser} & \textbf{Verantwortliche Person} \\
|
||||
@ -208,7 +209,7 @@ Um die Interoperabilit
|
||||
\hline
|
||||
\end{tabular} \newline
|
||||
|
||||
Zudem erhalten wir durch die Auswertung des Fragenbogens, der im Rahmen der Benutzerstudie an Probanten ausgegeben wird, eine Rückmeldung über eventuell auftrettende Fehler der Visualisierung.
|
||||
Zudem erhalten wir durch die Auswertung des Fragenbogens, der im Rahmen der Benutzerstudie an Probanden ausgegeben wird, eine Rückmeldung über eventuell auftretende Fehler der Visualisierung.
|
||||
% Benutzerstudie, manueles Testen
|
||||
\end{itemize}
|
||||
|
||||
@ -288,98 +289,97 @@ Der angepasste Datenschutzhinweis findet sich im Impressum durch folgende Vorlag
|
||||
|
||||
% % % % % % % % % % % % % % % %% % % % % % % % % % % ANHANG % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
|
||||
\newpage
|
||||
\section{Anhang}
|
||||
Der Anhang wird erst in der finalen Version, die am 31.03.2012 abgegeben werden muss, komplett sein.
|
||||
|
||||
\subsection{Testdokumentation}
|
||||
Auf den folgenden Seiten findet sich die Dokumentation über die von uns durchgeführten Tests im Laufe des Praktikums.
|
||||
\subsubsection{Funktionalität}
|
||||
\section{Anhang (Abgabe am 31.03.2012)}
|
||||
|
||||
|
||||
\subsubsection{Benutzerstudie}
|
||||
Wie in Abschnitt \ref{subsec:aktionBenutzbarkeit} beschrieben, wird die Benutzerstudie erst am Ende des Projekts durchgeführt, da das Webinterface zum jetzigen Zeitpunkt noch nicht fertiggestellt ist. Die Testdokumentation erfolgt somit im Anschluss und wird sich in der finalen Version dieses Dokuments (Abgabedatum 31.03.2012) befinden. \\
|
||||
|
||||
\textit{Der folgende Fragebogen kann sich während des gesamten Projekts ändern, da wir uns für den Prozess der \glspl{Agile Softwareentwicklung} entschieden haben. Es können neue Fragen hinzukommen oder aber bereits vorhandene geändert bzw. herausgenommen werden. Die Entscheidung über die zu stellenden Fragen obliegt dem gesamten Team. Hierdurch erhoffen wir uns, dass wir möglichst viele Bereiche des Projekts abfragen können.}
|
||||
|
||||
\begin{enumerate}
|
||||
\item Wie alt sind Sie?
|
||||
|
||||
\begin{tabular}{| p{1.5cm} |}
|
||||
\hline \\ \\\hline
|
||||
\end{tabular}
|
||||
|
||||
\item Wie viel Zeit verbringen Sie pro Tag im Internet?
|
||||
\begin{itemize}[label={\Square}]
|
||||
\item weniger als 1 Stunde
|
||||
\item zwischen 3 und 5 Stunden
|
||||
\item mehr als 5 Stunden
|
||||
\end{itemize}
|
||||
|
||||
\item Welchen Webbrowser nutzen Sie?
|
||||
\begin{itemize}[label={\Square}]
|
||||
\item Firefox
|
||||
\item Chrome
|
||||
\item Internet Explorer (Version 7 oder höher)
|
||||
\item Safari
|
||||
\item nicht aufgeführt
|
||||
\end{itemize}
|
||||
|
||||
\item Wie finden Sie die Visualisierung der Website? \\
|
||||
\small{(1 = nicht ansprechend; 10 = sehr ansprechend)}
|
||||
|
||||
\begin{tabular}{l c c c c c c c c c c r}
|
||||
& \tiny{1} & \tiny{2} & \tiny{3} & \tiny{4} & \tiny{5} & \tiny{6} & \tiny{7} & \tiny{8} & \tiny{9} & \tiny{10} &\\
|
||||
nicht ansprechend & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & sehr ansprechend
|
||||
\end{tabular}
|
||||
|
||||
|
||||
\item Wie beurteilen Sie die Übersichtlichkeit der Website? \\
|
||||
\small{(1 = nicht übersichtlich; 10 = sehr übersichtlich)}
|
||||
|
||||
\begin{tabular}{l c c c c c c c c c c r}
|
||||
& \tiny{1} & \tiny{2} & \tiny{3} & \tiny{4} & \tiny{5} & \tiny{6} & \tiny{7} & \tiny{8} & \tiny{9} & \tiny{10} &\\
|
||||
nicht übersichtlich & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & sehr übersichtlich
|
||||
\end{tabular}
|
||||
|
||||
|
||||
\item Hatten Sie Bedienprobleme beim Besuch der Website?
|
||||
\begin{itemize}[label={\Square}]
|
||||
\item Nein
|
||||
\item Ja, folgende:
|
||||
\end{itemize}
|
||||
\begin{tabular}{| p{15cm} |}
|
||||
\hline \\ \vspace{2cm} \\ \hline
|
||||
\end{tabular}
|
||||
|
||||
|
||||
\item Haben Sie Verbesserungsvorschläge?
|
||||
\begin{itemize}[label={\Square}]
|
||||
\item Nein
|
||||
\item Ja, folgende:
|
||||
\end{itemize}
|
||||
\begin{tabular}{| p{15cm} |}
|
||||
\hline \\ \vspace{2cm} \\ \hline
|
||||
\end{tabular}
|
||||
|
||||
\item Werden Sie die Website nochmals besuchen?
|
||||
\begin{itemize}[label={\Square}]
|
||||
\item Nein
|
||||
\item Ja
|
||||
\end{itemize}
|
||||
|
||||
\end{enumerate}
|
||||
%\subsection{Testdokumentation}
|
||||
%Auf den folgenden Seiten findet sich die Dokumentation über die von uns durchgeführten Tests im Laufe des Praktikums.
|
||||
%\subsubsection{Funktionalität}
|
||||
%
|
||||
%
|
||||
%\subsubsection{Benutzerstudie}
|
||||
%Wie in Abschnitt \ref{subsec:aktionBenutzbarkeit} beschrieben, wird die Benutzerstudie erst am Ende des Projekts durchgeführt, da das Webinterface zum jetzigen Zeitpunkt noch nicht fertiggestellt ist. Die Testdokumentation erfolgt somit im Anschluss und wird sich in der finalen Version dieses Dokuments (Abgabedatum 31.03.2012) befinden. \\
|
||||
%
|
||||
%\textit{Der folgende Fragebogen kann sich während des gesamten Projekts ändern, da wir uns für den Prozess der \glspl{Agile Softwareentwicklung} entschieden haben. Es können neue Fragen hinzukommen oder aber bereits vorhandene geändert bzw. herausgenommen werden. Die Entscheidung über die zu stellenden Fragen obliegt dem gesamten Team. Hierdurch erhoffen wir uns, dass wir möglichst viele Bereiche des Projekts abfragen können.}
|
||||
%
|
||||
%\begin{enumerate}
|
||||
%\item Wie alt sind Sie?
|
||||
%
|
||||
%\begin{tabular}{| p{1.5cm} |}
|
||||
%\hline \\ \\\hline
|
||||
%\end{tabular}
|
||||
%
|
||||
%\item Wie viel Zeit verbringen Sie pro Tag im Internet?
|
||||
% \begin{itemize}[label={\Square}]
|
||||
% \item weniger als 1 Stunde
|
||||
% \item zwischen 3 und 5 Stunden
|
||||
% \item mehr als 5 Stunden
|
||||
% \end{itemize}
|
||||
%
|
||||
%\item Welchen Webbrowser nutzen Sie?
|
||||
% \begin{itemize}[label={\Square}]
|
||||
% \item Firefox
|
||||
% \item Chrome
|
||||
% \item Internet Explorer (Version 7 oder höher)
|
||||
% \item Safari
|
||||
% \item nicht aufgeführt
|
||||
% \end{itemize}
|
||||
%
|
||||
%\item Wie finden Sie die Visualisierung der Website? \\
|
||||
% \small{(1 = nicht ansprechend; 10 = sehr ansprechend)}
|
||||
%
|
||||
% \begin{tabular}{l c c c c c c c c c c r}
|
||||
% & \tiny{1} & \tiny{2} & \tiny{3} & \tiny{4} & \tiny{5} & \tiny{6} & \tiny{7} & \tiny{8} & \tiny{9} & \tiny{10} &\\
|
||||
% nicht ansprechend & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & sehr ansprechend
|
||||
% \end{tabular}
|
||||
%
|
||||
%
|
||||
%\item Wie beurteilen Sie die Übersichtlichkeit der Website? \\
|
||||
% \small{(1 = nicht übersichtlich; 10 = sehr übersichtlich)}
|
||||
%
|
||||
% \begin{tabular}{l c c c c c c c c c c r}
|
||||
% & \tiny{1} & \tiny{2} & \tiny{3} & \tiny{4} & \tiny{5} & \tiny{6} & \tiny{7} & \tiny{8} & \tiny{9} & \tiny{10} &\\
|
||||
% nicht übersichtlich & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & \Square & sehr übersichtlich
|
||||
% \end{tabular}
|
||||
%
|
||||
%
|
||||
%\item Hatten Sie Bedienprobleme beim Besuch der Website?
|
||||
% \begin{itemize}[label={\Square}]
|
||||
% \item Nein
|
||||
% \item Ja, folgende:
|
||||
% \end{itemize}
|
||||
% \begin{tabular}{| p{15cm} |}
|
||||
% \hline \\ \vspace{2cm} \\ \hline
|
||||
% \end{tabular}
|
||||
%
|
||||
%
|
||||
%\item Haben Sie Verbesserungsvorschläge?
|
||||
% \begin{itemize}[label={\Square}]
|
||||
% \item Nein
|
||||
% \item Ja, folgende:
|
||||
% \end{itemize}
|
||||
% \begin{tabular}{| p{15cm} |}
|
||||
% \hline \\ \vspace{2cm} \\ \hline
|
||||
% \end{tabular}
|
||||
%
|
||||
%\item Werden Sie die Website nochmals besuchen?
|
||||
% \begin{itemize}[label={\Square}]
|
||||
% \item Nein
|
||||
% \item Ja
|
||||
% \end{itemize}
|
||||
%
|
||||
%\end{enumerate}
|
||||
%
|
||||
%
|
||||
%
|
||||
%\subsubsection{Logdaten Analyse}
|
||||
%Die Logdaten Analyse steht in Zusammenhang mit der Benutzerstudie und wird somit auch erst am Ende des Projekts durchgeführt. Die Testdokumentation erfolgt somit im Anschluss und wird sich in der finalen Version dieses Dokuments (Abgabedatum 31.03.2012) befinden.
|
||||
%
|
||||
%
|
||||
%\subsubsection{Codequalität}
|
||||
|
||||
|
||||
|
||||
\subsubsection{Logdaten Analyse}
|
||||
Die Logdaten Analyse steht in Zusammenhang mit der Benutzerstudie und wird somit auch erst am Ende des Projekts durchgeführt. Die Testdokumentation erfolgt somit im Anschluss und wird sich in der finalen Version dieses Dokuments (Abgabedatum 31.03.2012) befinden.
|
||||
|
||||
|
||||
\subsubsection{Codequalität}
|
||||
|
||||
|
||||
|
||||
\subsection{User-Stories}
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,67 +1,16 @@
|
||||
QS-Dokument - Verbesserungsvorschläge:
|
||||
|
||||
2.1 "Funktionalität":
|
||||
|
||||
-> "Richtigkeit" ersetzen durch "Korrektheit" (???)
|
||||
|
||||
-> "Sicherheit" "Der Datenaustausch zwischen Smartphones bzw. Waspmote-Sensoren
|
||||
und der API muss gegen Angriffe, wie etwa SQL-Injections geschützt
|
||||
werden."
|
||||
|
||||
-> "Interoperabilität" "soll" ersetzen ;
|
||||
"Die Darstellung der gesammelten Daten muss in allen gängigen Webbrowsern
|
||||
(Firefox, Chrome, Internet Explorer und Safari) fehlerfrei sein"
|
||||
|
||||
"Die Maßnahmen zur Erreichung der beschriebenen Qualitätsmerkmale, werden in Abschnitt 3.1
|
||||
erläutert"
|
||||
|
||||
2.2 "Benutzbarkeit":
|
||||
-> Bei jeder Maßnahme muss aufgeführt werden: Was wird gemacht? Wann wird es gemacht? Wer macht es? Und was wird im Fehlerfall gemacht?
|
||||
|
||||
-> "Im Hinblick auf die Benutzbarkeit sind uns folgende Qualitätsmerkmale wichtig:
|
||||
|
||||
- Verständlichkeit
|
||||
- Bedienbarkeit
|
||||
- Attraktivität
|
||||
|
||||
Diese Punkte werden von unserem Auftraggeber im zweiten Teil des Praktikums gefordert
|
||||
und sind nach [ISO/IEC 9126] definiert.
|
||||
|
||||
Eine intuitive und leicht bedienbare Benutzeroberfläche steigert die Aufmerksamkeit des
|
||||
Besuchers und verhilft dem Projekt zu einem höheren Bekanntheitsgrad. Ebenso kommt hierbei
|
||||
eine moderne und attraktive Visualisierung der Daten zum Einsatz, die die Informations-
|
||||
erfassung unterstützt. Durch das Bekanntwerden des Projekts erhofft sich unser Auftrag-
|
||||
geber eine breite Verteilung der kommenden da-sense Android-App, mit der Benutzer Daten
|
||||
sammeln und auf die Datenbank transferieren können. Die Daten sind über die Webapplikation
|
||||
abrufbar.
|
||||
|
||||
Die Maßnahmen zur Erreichung der beschriebenen Qualitätsmerkmale, werden in Abschnitt 3.2
|
||||
erläutert."
|
||||
|
||||
2.3 "Quellcode"
|
||||
|
||||
-> "Der Quellcode des Projektes ist offen für Erweiterungen und wird von weiteren Gruppen
|
||||
genutzt."
|
||||
|
||||
"Geplant ist die Veröffentlichung des Source Codes", um die... // TODO
|
||||
|
||||
3.1 "Funktionalität"
|
||||
|
||||
-> "Zur Sicherung der einzelnen Funktionalitätsmerkmale werden folgende Maßnahmen ergriffen:"
|
||||
|
||||
-> "Sicherheit"
|
||||
|
||||
"Das von uns verwendete ORM-Framework 'Propel' bietet die Verwendung von Prepared
|
||||
Statements, mit denen sich SQL-Injection Angriffe wirksam unterbinden lassen.
|
||||
Hierzu wird zwischen SQL-Code und Daten getrennt. Letzteres wird mithilfe
|
||||
des HTTP-Protokolls in die Datenbank aufgenommen.
|
||||
|
||||
"Bevor die Aufnahme neuer Daten in die Datenbank erfolgen kann, ist eine Authentifizierung des Nutzers notwendig. Die Implementierung der Authentifizierung
|
||||
unterliegt nicht unserem Aufgabenbereich."
|
||||
|
||||
-> "Interoperabilität"
|
||||
2.3: MVC-Pattern, strikte Trennung von php, javscript und html.
|
||||
|
||||
|
||||
3.1: -> "Interoperabilität"
|
||||
|
||||
"Um die Interoperabilität mit den einzelnen Webbrowsern sicherzustellen..."
|
||||
|
||||
"Während der Benutzerstudie werden Fragebögen an die Testpersonen ausgegeben. Die
|
||||
Auswertung dieser Fragebögen ermöglicht es uns, Rückschlüsse auf eventuell auftretende
|
||||
Fehler in der Visiualisierung zu ziehen und zu beseitigen."
|
||||
|
||||
|
||||
Binary file not shown.
@ -0,0 +1,5 @@
|
||||
<span><strong>
|
||||
<a href="http://24timezones.com/de_weltzeit/san_francisco_aktuelle_zeit.php" style="text-decoration: none" target="_BLANK" title="lokalzeit San Francisco">Zeit San Francisco</a> - <span id="tzTimeSpan_ee4f192d157fb06"></span>
|
||||
<script type="text/javascript" src="http://24timezones.com/js/de/time_24_1_1.js"></script>
|
||||
<script src="http://24timezones.com/timescript/gettime.js.php?city=224&hourtype=24&showdate=1&showseconds=1&id=597908&elem=ee4f192d157fb06" language="javascript"></script>
|
||||
</strong></span>
|
||||
Loading…
x
Reference in New Issue
Block a user