qs dokument
This commit is contained in:
M.Scholz
parent
d5fea92e2e
commit
34aaa37187
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-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{MVC}{name={Model-View-Controller-Pattern}, description={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.}}
|
||||
|
||||
|
||||
@ -148,7 +148,7 @@ Jede von uns geschriebene Funktion besitzt einen Kommentarkopf der folgenden For
|
||||
**/ \\
|
||||
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: \\
|
||||
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.
|
||||
Wir trennen im Quellcode strikt HTML, JavaScript und PHP. Die Trennung erhöht die Lesbarkeit, vereinfacht die Fehlersuche und reduziert die Fehlerrate. Zur Trennung von Daten- und Präsentationsebene wird das \gls{MVC} verwendet. Hierdurch wird eine sinnvolle Codestrukturierung erreicht.
|
||||
|
||||
\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.
|
||||
@ -187,24 +187,14 @@ Die Ma
|
||||
Zur Sicherung der einzelnen Funktionalitätsmerkmale werden die folgenden Maßnahmen ergriffen:
|
||||
\begin{itemize}
|
||||
\item Richtigkeit: \\
|
||||
|
||||
Zur Sicherstellung der Richtigkeit werden Whiteboxtest mit PHPUnit und Blackboxtests mit Selenium durchgeführt. Die korrekten Datenbankinteraktionen werden durch die Einhaltung der Vorgaben von Propel sichergestellt. PHPUnit erlaubt duch die integrierten Funktionen das einfache Testen von PHP-Methoden. Somit können auftretende Fehler schnell beseitigt werden. 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 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 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} \\
|
||||
\hline Firefox & Batu \\
|
||||
\hline Chrome & Murati \\
|
||||
\hline Internet Explorer & Gebhardt \\
|
||||
\hline Safari & Scholz \\
|
||||
\hline
|
||||
\end{tabular} \newline
|
||||
|
||||
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.
|
||||
\item Interoperabilität (noch nicht fertig!!): \\
|
||||
Um die Interoperabilität mit den einzelnen Webbrowsern sicherzustellen,... .\\
|
||||
Zudem erhalten wird 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}
|
||||
|
||||
@ -212,8 +202,8 @@ Zudem erhalten wir durch die Auswertung des Fragenbogens, der im Rahmen der Benu
|
||||
|
||||
\subsection{Benutzbarkeit}
|
||||
\label{Masnahme:Benutzbarkeit}
|
||||
Eine von uns durchgeführte Benutzerstudie stellt das Qualitätsmerkmal der Benutzbarkeit des neuen \glspl{Webinterface} sicher. Dieser Teil des Projekts wird erst am Ende des Projektzeitraums fertig. Aus diesem Grund kann auch die Benutzerstudie erst am Ende von uns durchgeführt werden. \\
|
||||
Zur Benutzerstudie werden freiwilligen Probanden Bögen ausgeteilt, welche der Bewertung der einzelnen Kriterien (aus Abschnitt \ref{Ziel:Benutzbarkeit}) der Benutzbarkeit des \glspl{Webinterface} dienen. Zudem werden einzelne Aktionen aller User auf der Webseite protokolliert, um im Anschluss durch eine Logdaten Analyse die Benutzerinteraktionen auswerten zu können. Durch die Benutzerstudie können somit Defizite des \glspl{Webinterface} aufgespürt und beseitigt werden. \\
|
||||
Eine von uns durchgeführte Benutzerstudie stellt das Qualitätsmerkmal der Benutzbarkeit des neuen \glspl{Webinterface} sicher. Die Studie wird in der ersten Märzwoche 2012 (Kalenderwoche 9) durchgeführt. Somit bleibt uns genug Zeit die Ergebnisse auszuwerten und in die Endabgabe des Praktikums einfließen zu lassen.
|
||||
Zur Benutzerstudie werden freiwilligen Probanden Bögen ausgeteilt, welche der Bewertung der einzelnen Kriterien (aus 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 soll, ist es wichtig, dass die Benutzerstudie möglichst viele verschiedene Personengruppen umfasst. Das heißt, es werden Personen mit wenig bis viel Interneterfahrung bzw. junge bis ältere Personen als Probanden gesucht. Zudem können durch die Studie unvorhersehbare Probleme entdeckt werden, da ein Benutzer anders mit der Website umgeht als ein Entwickler. \newline \\
|
||||
\textbf{Was wollen wir wissen?}
|
||||
\begin{itemize}
|
||||
@ -222,7 +212,7 @@ Das Ziel der Benutzerstudie ist es eine R
|
||||
\item Wie lange braucht der Nutzer um sich einen Überblick zu verschaffen?
|
||||
\item Treten unerwartete Fehler auf?
|
||||
\end{itemize}
|
||||
Die Benutzerstudie setzt sich aus den drei Teilen \textit{Beobachtung}, \textit{Fragebogen} und \textit{Logdaten Analyse} zusammen. Somit erhalten wir drei unterschiedliche Informationsquellen, welche in Korrelation zueinander stehen sollten.
|
||||
Die Benutzerstudie setzt sich aus den zwei Teilen \textit{Beobachtung} und \textit{Fragebogen} zusammen. Somit erhalten wir drei unterschiedliche Informationsquellen, welche in Korrelation zueinander stehen sollten.
|
||||
|
||||
\subsubsection{Beobachtung}
|
||||
Die Beobachtung des Probanden beim Bedienen der Website ist die einfachste Methode zur Evaluation. Hierbei bleibt der Entwickler in der Position des Beobachters und protokolliert. Der Proband surft frei nach seinem Willen durch die Website oder bekommt konkrete Aufgaben gestellt, die er lösen muss. \\
|
||||
@ -236,7 +226,7 @@ Bei der Beobachtung gilt es folgende Stichpunkte zu beachten:
|
||||
|
||||
\subsubsection{Fragebogen}
|
||||
\label{fragebogen}
|
||||
Der Fragebogen wird von uns Anfang März 2012 an die teilnehmenden Probanden ausgeteilt. Der genaue Termin wird sich an der Fertigstellung der neuen Visualisierung orientieren. Mit Hilfe des Fragebogens wollen wir Informationen von den verschiedensten Personengruppen aus Sicht eines Nutzers erhalten. Somit ist es möglich auf nutzerspezifische Anforderungen in der letzten Iteration des Projekts einzugehen. Die Fragen sind in drei Kategorien aufteilbar:
|
||||
Mit Hilfe des Fragebogens wollen wir Informationen von den verschiedensten Personengruppen aus Sicht eines Nutzers erhalten. Somit ist es möglich auf nutzerspezifische Anforderungen in der letzten Iteration des Projekts einzugehen. Die Fragen sind in drei Kategorien aufteilbar:
|
||||
\begin{itemize}
|
||||
\item Informationen über den Nutzer
|
||||
\item Bewertung der aktuellen Website
|
||||
@ -245,7 +235,7 @@ Der Fragebogen wird von uns Anfang M
|
||||
Durch Punkt eins und zwei können wir nach der Auswertung verschiedene Personengruppen identifizieren und bei ihnen aufgetauchte Probleme analysieren und beseitigen. Punkt drei erlaubt die Anpassung der Website an die nutzerspezifischen Anforderungen. \\
|
||||
|
||||
|
||||
\subsection{Codequalität}
|
||||
\subsection{Quellcode (noch nicht fertig)}
|
||||
\label{Masnahme:Codequalitaet}
|
||||
...
|
||||
|
||||
|
||||
@ -8,19 +8,26 @@ QS-Dokument - Verbesserungsvorschläge:
|
||||
- Und wie wird im Fehlerfall reagiert?
|
||||
|
||||
|
||||
3.1 Funktionalität: -> "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."
|
||||
3.1 Funktionalität:
|
||||
|
||||
Richtigkeit (Datenbankinteraktionen und Darstellung der Visualisierung):
|
||||
|
||||
|
||||
|
||||
|
||||
Sicherheit:
|
||||
|
||||
|
||||
|
||||
Interoperabilität:
|
||||
|
||||
|
||||
|
||||
|
||||
------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
3.2 Benutzbarkeit:
|
||||
bb
|
||||
|
||||
|
||||
3.2.1 Beobachtung:
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user