qs
This commit is contained in:
M.Scholz
parent
1ea97d21ae
commit
7cf7f36a17
Binary file not shown.
@ -76,24 +76,24 @@ Version: 0.9.0 vom 24.01.2012}
|
||||
\textbf{Auftraggeber:} & \textbf{Immanuel Schweizer} \\
|
||||
& Telecooperation Group TU Darmstadt \\
|
||||
& Büro: S2|02 A216 \\
|
||||
& mail: \href{mailto:schweizer@tk.informatik.tu-darmstadt.de}{schweizer@tk.informatik.tu-darmstadt.de} \\
|
||||
& E-Mail: \href{mailto:schweizer@tk.informatik.tu-darmstadt.de}{schweizer@tk.informatik.tu-darmstadt.de} \\
|
||||
& \\
|
||||
& \\
|
||||
\textbf{Teamleiter:} & \textbf{Dominik Fischer} \\
|
||||
& mail: \href{mailto:dfischer@stud.tu-darmstadt.de}{dfischer@stud.tu-darmstadt.de} \\
|
||||
& E-Mail: \href{mailto:dfischer@stud.tu-darmstadt.de}{dfischer@stud.tu-darmstadt.de} \\
|
||||
& \\
|
||||
& \\
|
||||
\textbf{Gruppe:} & \textbf{Murat Batu} \\
|
||||
& mail: \href{mailto:wu07hufy@rbg.informatik.tu-darmstadt.de}{wu07hufy@rbg.informatik.tu-darmstadt.de} \\
|
||||
& E-Mail: \href{mailto:wu07hufy@rbg.informatik.tu-darmstadt.de}{wu07hufy@rbg.informatik.tu-darmstadt.de} \\
|
||||
& \\
|
||||
& \textbf{Ulf Gebhardt} \\
|
||||
& mail: \href{mailto:hu56nifa@rbg.informatik.tu-darmstadt.de}{hu56nifa@rbg.informatik.tu-darmstadt.de} \\
|
||||
& E-Mail: \href{mailto:hu56nifa@rbg.informatik.tu-darmstadt.de}{hu56nifa@rbg.informatik.tu-darmstadt.de} \\
|
||||
& \\
|
||||
& \textbf{Lulzim Murati} \\
|
||||
& mail: \href{mailto:l\_murati@rbg.informatik.tu-darmstadt.de}{l\_murati@rbg.informatik.tu-darmstadt.de} \\
|
||||
& E-Mail: \href{mailto:l\_murati@rbg.informatik.tu-darmstadt.de}{l\_murati@rbg.informatik.tu-darmstadt.de} \\
|
||||
& \\
|
||||
& \textbf{Michael Scholz} \\
|
||||
& mail: \href{mailto:mi48azih@rbg.informatik.tu-darmstadt.de}{mi48azih@rbg.informatik.tu-darmstadt.de} \\
|
||||
& E-Mail: \href{mailto:mi48azih@rbg.informatik.tu-darmstadt.de}{mi48azih@rbg.informatik.tu-darmstadt.de} \\
|
||||
\end{tabular}
|
||||
|
||||
|
||||
@ -123,9 +123,16 @@ Der Themenbereich umfasst die Umstellung der \gls{API} auf eine neue Datenbank u
|
||||
\section{Qualitätsziele}
|
||||
|
||||
|
||||
\subsection{Benutzbarkeit}
|
||||
\label{Ziel:Benutzbarkeit}
|
||||
Die Benutzbarkeit unterteilen wir, wie vom Auftraggeber im zweiten Teil des Praktikums gefordert, in die drei Qualitätsmerkmale \textit{Verständlichkeit}, \textit{Bedienbarkeit} und \textit{Attraktivität}, welche wir nach \cite{ISO/IEC 9126} definieren. \\ \\
|
||||
Eine intuitive und leicht bedienbare Benutzeroberfläche steigert die Aufmerksamkeit des Besuchers und verhilft dem Projekt zu einem höheren Bekanntheitsgrad. Hierbei kommt eine moderne und attraktive Visualisierung der Daten zum Einsatz, die die Informationserfassung unterstützt. Durch das Bekanntwerden des Projekts erhofft sich unser Auftraggeber eine breite Verteilung der kommenden da-sense Android-App, mit der Benutzer Daten sammeln und in die Datenbank transferieren können. Die Daten sind anschließend über die Webapplikation abrufbar.
|
||||
|
||||
|
||||
|
||||
\subsection{Funktionalität}
|
||||
\label{Ziel:Funktionalitaet}
|
||||
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.
|
||||
Die Funktionalität unterteilen wir, wie vom Auftraggeber gefordert, in die drei Qualitätsmerkmale \textit{Richtigkeit}, \textit{Interoperabilität} und \textit{Sicherheit}, welche wir nach \cite{ISO/IEC 9126} definieren.
|
||||
\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.
|
||||
@ -135,16 +142,12 @@ Das Merkmal der Sicherheit wird beim Datenaustausch zwischen Smartphones bzw. \g
|
||||
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. Wir beschränken uns bei den angegebenen Browsern auf die jeweilige aktuelle Version. Dies ist notwendig, da die neue Visualisierung auf \gls{HTML5} basiert.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Benutzbarkeit}
|
||||
\label{Ziel:Benutzbarkeit}
|
||||
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. Hierbei kommt eine moderne und attraktive Visualisierung der Daten zum Einsatz, die die Informationserfassung unterstützt. Durch das Bekanntwerden des Projekts erhofft sich unser Auftraggeber eine breite Verteilung der kommenden da-sense Android-App, mit der Benutzer Daten sammeln und in die Datenbank transferieren können. Die Daten sind anschließend über die Webapplikation abrufbar.
|
||||
|
||||
|
||||
\subsection{Erweiterbarkeit}
|
||||
\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 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. Es werden die Open Standards nach \cite{opensource.org} angewandt. Diese schließen den Einsatz von kommerziellen Tools im Projekt aus.
|
||||
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. Es werden die Open Standards nach \cite{opensource.org} angewandt. Diese schließen unter anderem den Einsatz von kommerziellen Tools im Projekt aus.
|
||||
|
||||
|
||||
|
||||
@ -155,44 +158,9 @@ Der Quellcode des Projektes ist offen f
|
||||
\section{Maßnahmen zum Erreichen der Qualitätsziele}
|
||||
|
||||
|
||||
%\subsection{Qualitätswerkzeuge}
|
||||
%\label{Masnahme:Qualitaetswerkzeuge}
|
||||
%\begin{itemize}
|
||||
%\item FireBug: \\
|
||||
%Dient der Fehlersuche, Bearbeitung und Monitoring des \gls{Webinterface}. FireBug ermöglicht uns die Ladezeiten einzelner Seitenelemente zu analysieren. Dies wird bei der neuen Visualisierung, deren Berechnung mittels HTML5 clientseitig ablaufen soll, von Bedeutung sein.
|
||||
%\item Git: \\
|
||||
%Als Versionsverwaltung dient \gls{Git}. Hierdurch ist ein einfacher Codeaustausch mit den übrigen Gruppen von da-sense möglich, wodurch jede Person stets über den aktuellen Code verfügt. Der Vorteil des \gls{Git} gegenüber einem \gls{SVN} ist für uns die Möglichkeit des lokalen commits, wodurch eine lokale Versionierung vorliegt. Somit kann jedes Gruppenmitglied seine Änderungen rückgängig machen.
|
||||
%\item Netbeans:\\
|
||||
%Als integrierte Entwicklungsumgebung (IDE) wird Netbeans verwendet, wodurch Syntaxfehler vermieden werden.
|
||||
%\item PHPUnit:\\
|
||||
%Testframework für PHP. Es beinhaltet eine Testumgebung für Datenbankinteraktionen, was für unser Projekt von Vorteil ist. Zudem arbeitet es mit XDebug zusammen und ermöglicht die Erstellung von CodeCoverage Analysen.
|
||||
%\item soapUI:\\
|
||||
%Freies Werkzeug, welches dem Testen des Webservices dient. Hierdurch ist es möglich manuelle Anfragen an den Webservice zu stellen und die Antworten auszuwerten. Zudem beinhaltet soapUI eine umfangreiche Testsuite.
|
||||
%\item XDebug:\\
|
||||
%Diagnose-Werkzeug (PHP-Debugger). Dient dem Auffinden von Fehlern und Code-Coverage Tests bei Ausführung des Programms.
|
||||
%\end{itemize}
|
||||
|
||||
|
||||
\subsection{Funktionalität}
|
||||
\label{Masnahme:Funktionalitaet} % ß wird von LaTex nicht akzeptiert als Label
|
||||
Zur Sicherung der einzelnen Funktionalitätsmerkmale werden die folgenden Maßnahmen ergriffen:
|
||||
\begin{itemize}
|
||||
\item Richtigkeit: \\
|
||||
Zur Sicherstellung der Richtigkeit werden \glspl{whitebox} mit \gls{PHPUnit} und \glspl{blackbox} mit \gls{Selenium} durchgeführt. Die korrekten Datenbankinteraktionen werden durch die Einhaltung der Vorgaben von \gls{Propel} sichergestellt. \gls{PHPUnit} erlaubt durch die integrierten Funktionen das einfache Testen von \gls{PHP}-Methoden. Somit können auftretende Fehler schnell beseitigt werden. \gls{Selenium} testet automatisiert die Anbindung der Daten an die Visualisierung. Hierzu wird eine Benutzereingabe aufgezeichnet, die nun im weiteren Entwicklungsprozess durch Selenium wiederholt ausgeführt werden kann.
|
||||
|
||||
\item Sicherheit: \\
|
||||
Das von uns verwendete \gls{ORM} \gls{Propel} nutzt \glspl{PreparedStatement}, mit denen sich \glspl{SQL-Injection} wirksam unterbinden lassen. Hierbei werden \gls{SQL}-Code und Daten getrennt. Zudem erfordert Propel keine \gls{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 mit den einzelnen Webbrowsern sicherzustellen, werden manuelle Tests durchgeführt. Hierzu wird jeweils die aktuelle Version des Webbrowsers verwendet. Jeder Browser wird mit denselben Benutzereingaben ausgeführt. Die jeweiligen Ausgaben erlauben einen direkten Vergleich. Außerdem werden im Rahmen der Benutzerstudie Fragebögen an Probanden ausgegeben. Die Auswertung dieser Fragebögen ermöglicht es uns, Rückschlüsse auf eventuell auftretende Fehler in der Visualisierung zu ziehen und zu beseitigen.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\subsection{Benutzbarkeit}
|
||||
\label{Masnahme:Benutzbarkeit}
|
||||
% TODO: -> Die Benutzerstudie kann das Qualitätsmerkmal nicht sicherstellen. Sie kann nur Grundlage für anschließende Maßnahmen sein!
|
||||
Die Benutzerstudie wird in der ersten Märzwoche 2012 (Kalenderwoche 9) durchgeführt. Somit bleibt uns genug Zeit die Ergebnisse auszuwerten und Schwachstellen in der Benutzeroberfläche zu beseitigen.
|
||||
In der ersten Märzwoche 2012 (Kalenderwoche 9) wird eine Benutzerstudie durchgeführt. Somit bleibt uns genug Zeit die Ergebnisse auszuwerten und Schwachstellen in der Benutzeroberfläche zu beseitigen.
|
||||
Zur Benutzerstudie werden freiwilligen Probanden Fragebögen ausgeteilt, welche der Bewertung der einzelnen Kriterien (Abschnitt \ref{Ziel:Benutzbarkeit}) der Benutzbarkeit des \glspl{Webinterface} dienen. Durch die Benutzerstudie können somit Defizite des \glspl{Webinterface} aufgespürt und beseitigt werden. \\ \\
|
||||
Das Ziel der Benutzerstudie ist es eine Rückmeldung zu erhalten, ob und wie sich der Benutzer auf der Website zurechtfindet. Es gilt herauszufinden, ob der User in einer für ihn angemessenen Zeit die gewünschten Informationen abrufen kann. Da das fertige Projekt eine breite Masse an Personen erreichen wird, ist es wichtig, dass die Benutzerstudie möglichst viele verschiedene Personengruppen umfasst. Das heißt, es werden Personen unterschiedlichen Alters und mit unterschiedlicher Interneterfahrung ausgewählt. Zudem können durch die Studie unvorhersehbare Probleme entdeckt werden, da ein Benutzer auf eine andere Art und Weise mit der Website interagiert als ein Entwickler. \newline \\
|
||||
\textbf{Was wir wissen wollen:}
|
||||
@ -212,16 +180,32 @@ Die Beobachtung des Probanden w
|
||||
\item Vergangene Zeit bis zum Erhalt der gewünschten Informationen
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsubsection{Fragebogen}
|
||||
\label{fragebogen}
|
||||
Mit Hilfe des Fragebogens (siehe Anhang) erhalten wir Informationen von verschiedenen Personengruppen. Der Fragebogen lässt sich in die folgenden drei Kategorien unterteilen:
|
||||
Mit Hilfe des Fragebogens erhalten wir Informationen von verschiedenen Personengruppen. Der Fragebogen lässt sich in die folgenden drei Kategorien unterteilen:
|
||||
\begin{itemize}
|
||||
\item Informationen über den Nutzer
|
||||
\item Bewertung der aktuellen Website
|
||||
\item Verbesserungsvorschläge
|
||||
\end{itemize}
|
||||
Durch Punkt eins können wir die Probanden in verschiedene Personengruppen einteilen. Die Einteilung der Personen in Gruppen erfolgt durch die Merkmale Alter und Interneterfahrung. Anschließend werden die gesammelten Ergebnisse aus Punkt zwei den einzelnen Personengruppen zugeteilt. Unterscheiden sich die Ergebnisse der einzelnen Gruppen stark, so muss der Auftraggeber entscheiden, für welche Zielgruppe die Benutzeroberfläche optimiert werden soll. Punkt drei erlaubt die Anpassung der Steuerungsoptionen der Website. \\
|
||||
Durch Punkt eins können wir die Probanden in verschiedene Personengruppen einteilen. Die Einteilung der Personen in Gruppen erfolgt durch die Merkmale Alter und Interneterfahrung. Anschließend werden die gesammelten Ergebnisse aus Punkt zwei den einzelnen Personengruppen zugeteilt. Unterscheiden sich die Ergebnisse der einzelnen Gruppen stark, so muss der Auftraggeber entscheiden, für welche Zielgruppe die Benutzeroberfläche optimiert werden soll. Punkt drei erlaubt die Anpassung der Steuerungsoptionen der Website. Der Fragebogen ist im Anhang zu finden und kann sich noch bis zur Durchführung der Benutzerstudie ändern. Dies hängt mit dem von uns verwendeten Prozess der Agilen Softwareentwicklung zusammen. Es können Fragen hinzukommen oder aber bereits vorhandene geändert bzw. herausgenommen werden. Die Entscheidung über die zu stellenden Fragen obliegt dem gesamten Team.\\
|
||||
|
||||
|
||||
|
||||
\subsection{Funktionalität}
|
||||
\label{Masnahme:Funktionalitaet} % ß wird von LaTex nicht akzeptiert als Label
|
||||
Zur Sicherung der einzelnen Funktionalitätsmerkmale werden die folgenden Maßnahmen ergriffen:
|
||||
\begin{itemize}
|
||||
\item Richtigkeit: \\
|
||||
Zur Sicherstellung der Richtigkeit werden \glspl{whitebox} mit \gls{PHPUnit} und \glspl{blackbox} mit \gls{Selenium} durchgeführt. Die korrekten Datenbankinteraktionen werden durch die Einhaltung der Vorgaben von \gls{Propel} sichergestellt. \gls{PHPUnit} erlaubt durch die integrierten Funktionen das einfache Testen von \gls{PHP}-Methoden. Somit können auftretende Fehler schnell beseitigt werden. \gls{Selenium} testet automatisiert die Anbindung der Daten an die Visualisierung. Hierzu wird eine Benutzereingabe aufgezeichnet, die nun im weiteren Entwicklungsprozess durch Selenium wiederholt ausgeführt werden kann.
|
||||
|
||||
\item Sicherheit: \\
|
||||
Das von uns verwendete \gls{ORM} \gls{Propel} nutzt \glspl{PreparedStatement}, mit denen sich \glspl{SQL-Injection} wirksam unterbinden lassen. Hierbei werden \gls{SQL}-Code und Daten getrennt. Zudem erfordert Propel keine \gls{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 mit den einzelnen Webbrowsern sicherzustellen, werden manuelle Tests durchgeführt. Hierzu wird jeweils die aktuelle Version des Webbrowsers verwendet. Jeder Browser wird mit denselben Benutzereingaben ausgeführt. Die jeweiligen Ausgaben erlauben einen direkten Vergleich. Außerdem werden im Rahmen der Benutzerstudie Fragebögen an Probanden ausgegeben. Die Auswertung dieser Fragebögen ermöglicht es uns, Rückschlüsse auf eventuell auftretende Fehler in der Visualisierung zu ziehen und zu beseitigen.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\subsection{Erweiterbarkeit}
|
||||
@ -229,7 +213,7 @@ Durch Punkt eins k
|
||||
Um das Ziel der Erweiterbarkeit sicherzustellen, treffen wir folgende Vereinbarungen:
|
||||
\begin{itemize}
|
||||
\item Codedokumentation: \\
|
||||
Jede von uns geschriebene Funktion besitzt einen Kommentarkopf der folgenden Form: \\
|
||||
Jede von uns geschriebene Funktion besitzt einen vom geläufigen Javadoc-Format inspirierten Kommentarkopf der folgenden Form: \\
|
||||
/** \\
|
||||
* \textit{Description} \\
|
||||
* @param \textit{paramtype} \\
|
||||
@ -259,8 +243,6 @@ Die aufgef
|
||||
|
||||
|
||||
\subsubsection{Fragebogen}
|
||||
Der folgende Fragebogen kann sich während des gesamten Projekts ändern, da wir uns für den Prozess der \glspl{Agile Softwareentwicklung} entschieden haben und somit gut auf sich änderte Anforderungen reagieren können. 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.
|
||||
|
||||
\begin{enumerate}
|
||||
\item Wie alt sind Sie?
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user