QS-Doc
This commit is contained in:
M.Scholz
parent
553d8b1e85
commit
4fd1af85f6
Binary file not shown.
@ -37,9 +37,12 @@
|
||||
\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={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{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.}}
|
||||
|
||||
\newglossaryentry{whitebox}{name={Whiteboxtest}, plural={Whiteboxtests}, description={Softwareentwickler hat während der Tests Kenntnisse über die innere Funktionsweise der zu testenden Module.}}
|
||||
\newglossaryentry{blackbox}{name={Blackboxtest}, plural={Blackboxtests}, description={Softwareentwickler hat während der Tests keine Kenntniss über die innere Funktionsweise der zu testenden Module}}
|
||||
\newglossaryentry{Selenium}{name={Selenium}, description={Selenium ist ein Tool, mit dem Benutzereingaben automatisiert werden können. Mehr unter: \href{http://seleniumhq.org/}{http://seleniumhq.org/}}}
|
||||
\newglossaryentry{PHPUnit}{name={PHPUnit}, description={Mittels PHPUnit können Whiteboxtests von PHP-Code durchgeführt werden. Dies geschieht vergleichbar mit dem bekannten JUnit Testframework in Java.}}
|
||||
|
||||
\begin{document}
|
||||
|
||||
@ -133,27 +136,11 @@ Eine intuitive und leicht bedienbare Benutzeroberfl
|
||||
Die Maßnahmen, die wir ergreifen, um die beschriebenen Qualitätsmerkmale zu erreichen, sind in Abschnitt \ref{Masnahme:Benutzbarkeit} aufgeführt.
|
||||
|
||||
|
||||
\subsection{Quellcode}
|
||||
\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. 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: \\
|
||||
/** \\
|
||||
* \textit{Description} \\
|
||||
* @param \textit{paramtype} \\
|
||||
* @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 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. 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.
|
||||
\end{itemize}
|
||||
Die Maßnahmen, die wir ergreifen, um die beschriebenen Qualitätsmerkmale zu erreichen, sind in Abschnitt \ref{Masnahme:Codequalitaet} aufgeführt.
|
||||
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. Damit das Projekt in Zukunft in der Open-Source-Szene anerkannt wird, werden die Open Standards nach \cite{opensource.org} angewendet. Hierbei hat es höchste Priorität, keine kommerziellen Tools im Projekt einzusetzen.\\\\
|
||||
Die Maßnahmen, die wir ergreifen, um das beschriebene Qualitätsziel zu erreichen, sind in Abschnitt \ref{Masnahme:Erweiterbarkeit} aufgeführt.
|
||||
|
||||
|
||||
|
||||
@ -187,12 +174,12 @@ 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.
|
||||
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 duch die integrierten Funktionen das einfache Testen von 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 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 (noch nicht fertig!!): \\
|
||||
\item Interoperabilität (\textbf{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
|
||||
@ -205,14 +192,14 @@ Zudem erhalten wird durch die Auswertung des Fragenbogens, der im Rahmen der Ben
|
||||
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?}
|
||||
\textbf{Was wir wissen wollen:}
|
||||
\begin{itemize}
|
||||
\item Ist die Visualisierung einfach zu verstehen und ansprechend?
|
||||
\item Wie lange braucht der Nutzer um die gewünschten Informationen zu erhalten?
|
||||
\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 zwei Teilen \textit{Beobachtung} und \textit{Fragebogen} 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 zwei unterschiedliche Informationsquellen, welche in Korrelation zueinander stehen.
|
||||
|
||||
\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. \\
|
||||
@ -226,19 +213,35 @@ Bei der Beobachtung gilt es folgende Stichpunkte zu beachten:
|
||||
|
||||
\subsubsection{Fragebogen}
|
||||
\label{fragebogen}
|
||||
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 erhalten wir Informationen von den verschiedensten Personengruppen aus Sicht eines Nutzers. Somit können wir auftauchende Fehler in der letzten Iteration beseitigen. Die Fragen sind in drei Kategorien aufteilbar:
|
||||
\begin{itemize}
|
||||
\item Informationen über den Nutzer
|
||||
\item Bewertung der aktuellen Website
|
||||
\item Verbesserungsvorschläge
|
||||
\end{itemize}
|
||||
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. \\
|
||||
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 Steuerungsoptionen der Website. \\
|
||||
|
||||
|
||||
\subsection{Quellcode (noch nicht fertig)}
|
||||
\label{Masnahme:Codequalitaet}
|
||||
...
|
||||
\subsection{Erweiterbarkeit (\textbf{noch nicht fertig})}
|
||||
\label{Masnahme:Erweiterbarkeit}
|
||||
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: \\
|
||||
/** \\
|
||||
* \textit{Description} \\
|
||||
* @param \textit{paramtype} \\
|
||||
* @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 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. 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.
|
||||
\end{itemize}
|
||||
Das Testen dieses Zieles....
|
||||
|
||||
|
||||
|
||||
@ -376,14 +379,18 @@ F
|
||||
%fügt elemenmte dem toc hinzu
|
||||
\addcontentsline{toc}{section}{Literatur}
|
||||
\begin{thebibliography}{------}
|
||||
% \bibitem[BSS+2008]{bss+:2008} Helmut Balzert, Christian Schäfer, Marion Schröder, Uwe Kern: \emph{Wissenschaftliches Arbeiten - Wissenschaft, Quellen, Artefakte, Organisation, Präsentation}, Witten: W3L, 2008
|
||||
|
||||
\bibitem[FBBOR+1999]{fowler} Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts: \emph{Refactoring: Improving the Design of Existing Code}, Written: 1999
|
||||
|
||||
\bibitem[ISO/IEC 9126]{ISO/IEC 9126} International Organization for Standardization \emph{ISO/IEC 9126} \\Auszug: Wikipedia, \href{http://de.wikipedia.org/wiki/ISO/IEC_9126}{http://de.wikipedia.org/wiki/ISO/IEC\_9126}
|
||||
|
||||
% \bibitem[ISO9001]{iso:9001} International Organization for Standardization. \emph{ISO 9001}, 12.2008
|
||||
\bibitem[OSI]{opensource.org} Open Source Initiative: \href{http://www.opensource.org/}{http://www.opensource.org/}
|
||||
|
||||
\bibitem[FBBOR+1999]{fowler} Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts: \emph{Refactoring: Improving the Design of Existing Code}, Written: 1999
|
||||
|
||||
|
||||
|
||||
|
||||
% \bibitem[BSS+2008]{bss+:2008} Helmut Balzert, Christian Schäfer, Marion Schröder, Uwe Kern: \emph{Wissenschaftliches Arbeiten - Wissenschaft, Quellen, Artefakte, Organisation, Präsentation}, Witten: W3L, 2008
|
||||
% \bibitem[ISO9001]{iso:9001} International Organization for Standardization. \emph{ISO 9001}, 12.2008
|
||||
% \bibitem[WIKI2011]{wiki:2011} Wikipedia, die freie Enzyklopädie. \emph{WIKIPEDIA}, Stand: 12.12.2011
|
||||
\end{thebibliography}
|
||||
|
||||
|
||||
@ -1 +1 @@
|
||||
Um das Glossar zu erstellen muss die .text-Datei einmal kompiliert, dann mittel Konsole und "makeglossaries Qs-Dokument" die Glossardateien erstellt und anschließend die .text-Datei nochmals kompiliert werden.
|
||||
Um das Glossar zu erstellen muss die .text-Datei einmal kompiliert, dann mittels Konsole und "makeglossaries Qs-Dokument" die Glossardateien erstellt und anschließend die .text-Datei nochmals kompiliert werden.
|
||||
Loading…
x
Reference in New Issue
Block a user