qs-doc
This commit is contained in:
M.Scholz
parent
4668bab538
commit
dcdcb08ac6
Binary file not shown.
@ -16,7 +16,11 @@
|
||||
\makeglossaries
|
||||
|
||||
%\newglossaryentry{}{name={},description={}}
|
||||
\newglossaryentry{Agile Softwareentwicklung}{{name=Agile Softwareentwicklung},plural={Agilen Softwareentwicklung},description={Softwareentwicklungsprozess, welcher auf sich ändernde Anforderungen flexibel eingeht.}}
|
||||
\newglossaryentry{SVN}{name={SVN},description={Subversion ist eine freie Software zur zentralisierten Versionsverwaltung}}
|
||||
\newglossaryentry{Git}{name={Git},description={Freie Anwendung zur verteilten Versionsverwaltung}}
|
||||
\newglossaryentry{SQL-Injection}{name={SQL-Injection}, plural={SQL-Injections},description={Angriff auf Datenbank mit dem Ziel eigenen SQL-Code auszuführen und Daten auszulesen bzw. zu ändern}}
|
||||
\newglossaryentry{Propel}{name={Propel},description={Datenbankschnittstellte, die eine einfache Interaktion mit der vorhandenen Datenbank bietet. Mehr Informationen unter: \href{http://www.propelorm.org/}{http://www.propelorm.org/}}}
|
||||
\newglossaryentry{Agile Softwareentwicklung}{{name=Agile Softwareentwicklung},plural={Agilen Softwareentwicklung},description={Softwareentwicklungsprozess, welcher auf sich ändernde Anforderungen flexibel eingeht}}
|
||||
\newglossaryentry{API}{name={API},description={Application Programming Interface: Programmteil, durch den andere Programme die Funktionalität des eigentlichen Programmes nutzen können}}
|
||||
\newglossaryentry{User-Front-End}{name={User-Front-End},description={Für den Benutzer sichtbarer Teil der Anwendung}}
|
||||
\newglossaryentry{CO}{name={CO},description={Kohlenstoffmonoxid (chemische Verbindung)}}
|
||||
@ -30,7 +34,7 @@
|
||||
\newglossaryentry{Unit-Test}{name={Unit-Test},description={Softwaretest zur Überprüfung von Programmteilen (Methoden, Klassen)}}
|
||||
\newglossaryentry{Use-Case}{name={Use-Case},description={Anwendungsfall: Modellelement in der UML-Sprache}}
|
||||
\newglossaryentry{Webservice}{name={Webservice},description={Schnittstelle zur Interaktion mit anderen Anwendungen via XML-basierter Nachrichten}}
|
||||
\newglossaryentry{Webinterface}{name={Webinterface},plural={Webinterfaces},description={grafische Benutzeroberfläche.}}
|
||||
\newglossaryentry{Webinterface}{name={Webinterface},plural={Webinterfaces},description={grafische Benutzeroberfläche}}
|
||||
\newglossaryentry{Waspmotes Sensoren}{name={Waspmotes Sensoren},description={Wireless Sensoren, welche auf Straßenbahnen installiert werden und der Datenerfassung dienen. Mehr unter: \href{http://www.libelium.com/products/waspmote}{http://www.libelium.com/products/waspmote}}}
|
||||
\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}}
|
||||
@ -91,16 +95,20 @@ Der Themenbereich umfasst die Umstellung der \gls{API} auf eine neue Datenbank u
|
||||
Funktionalität beschreibt das Vorhandensein von geforderten Funktionen mit festgelegten Eigenschaften, die von den Funktionen erfüllt werden \cite{ISO/IEC 9126}. \\
|
||||
Die Funktionalität lässt sich in die folgenden Punkte gliedern:
|
||||
\begin{itemize}
|
||||
\item Angemessenheit: \\
|
||||
\textit{Eignung von Funktionen für spezielle Aufgaben.}
|
||||
\item Richtigkeit: \\
|
||||
\textit{Die Funktionen liefern die richtigen bzw. erwarteteten Ergebnisse.}
|
||||
% \item Angemessenheit:
|
||||
% \textit{Eignung von Funktionen für spezielle Aufgaben.}
|
||||
\item Richtigkeit: \\
|
||||
\textit{Die Funktionen liefern die richtigen bzw. erwarteteten Ergebnisse.} \\
|
||||
Die Funktionen werden von uns auf einem Testserver im Livebetrieb getestet, bevor sie im \gls{Git} den übrigen Entwicklern zur Verfügung gestellt werden. Somit befinden sich im \gls{Git} nur bereits getestet Funktionen und somit eine lauffähige Version der Website.
|
||||
\item Interoperabilität: \\
|
||||
\textit{Fehlerfreie Kooperation mit vorhandenen Systemen.}
|
||||
\textit{Fehlerfreie Kooperation mit vorhandenen Systemen.} \\
|
||||
Es gilt zu gewährleisten, das die Website mit allen gängigen Webbrowsern (Firefox, Chrome, Internet Explorer ab Version 7, Safari) im vollen Funktionsumfang erreichbar ist. Da uns hierfür kein Testwerkzeug bekannt ist, werden wir die Tests nur manuell durchführen können. Zudem wird uns hierbei die Benutzerstudie Informationen zu den einzelnen Webbrowsern beschaffen (Vgl. Abschnitt \ref{fragebogen} Frage 3).
|
||||
\item Sicherheit: \\
|
||||
\textit{Blockierung von unberechtigtem Zugriff auf vertraulichen Daten (Datenbank).}
|
||||
\textit{Blockierung von unberechtigtem Zugriff auf vertraulichen Daten (Datenbank).} \\
|
||||
Um dieses Ziel zu gewährleisten, nutzen wir die Datenbankschnittstelle \gls{Propel}, die \glspl{SQL-Injection} verhindert und übersichtliche Datenbankinteraktionen erlaubt.
|
||||
\item Ordnungsmäßigkeit: \\
|
||||
\textit{Einhaltung von anwendungsspezifisch Normen und gesetzlichen Bestimmungen.}
|
||||
\textit{Einhaltung von anwendungsspezifisch Normen und gesetzlichen Bestimmungen.} \\
|
||||
Hier ist als Beispiel die datenschutzkonforme Nutzung von Google Analytics im Abschnitt \ref{subsubsec:datenschutz} zu nennen.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
@ -120,31 +128,15 @@ Die Benutzbarkeit l
|
||||
\item Konformität: \\
|
||||
\textit{Beschreibt den Grad, in dem die Software Normen zur Benutzbarkeit erfüllt.}
|
||||
\end{itemize}
|
||||
|
||||
\parindent 0pt
|
||||
Um dies zu gewährleisten werden wir am Ende des Projekts eine Benutzerstudie durchführen, die uns eine Rückmeldung über die gennanten Punkte liefern soll. Der Ablauf der Studie ist in Abschnitt \ref{subsec:aktionBenutzbarkeit} beschrieben.
|
||||
|
||||
|
||||
\subsection{Codequalität}
|
||||
>>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 Projekt erstellt wird, soll offen für Erweiterungen sein 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.
|
||||
Die folgenden Anforderungen und Vereinbarungen sollen diese Merkmale erfüllen:
|
||||
\begin{itemize}
|
||||
\item Kommentare: \\
|
||||
Jede von uns geschriebene, nicht triviale Funktion muss einen Kommentarkopf der folgenden Form besitzen:\\
|
||||
/** \\
|
||||
* \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.
|
||||
\item Struktur: \\
|
||||
Der Code soll folgenden Standards gerecht werden: \\
|
||||
\begin{itemize}
|
||||
\item \gls{XHTML} in Version 1.1, standardisiert vom W3C 2010, \href{http://www.w3.org/TR/xhtml11/}{http://www.w3.org/TR/xhtml11/}
|
||||
\end{itemize}
|
||||
\item Namenskonventionen: \\
|
||||
Als Konvention nutzen wir CamelCase, welche in Java als Standard gilt und zu einer besseren Lesbarkeit von Bezeichnern beiträgt.
|
||||
\end{itemize}
|
||||
Der Quellcode, der im Rahmen des Projekt erstellt wird, soll offen für Erweiterungen sein 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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -157,9 +149,9 @@ Im folgenden Abschnitt werden die Ma
|
||||
\subsection{Qualitätswerkzeuge}
|
||||
\begin{itemize}
|
||||
\item FireBug: \\
|
||||
Dient der Fehlersuche, Bearbeitung und Monitoring des \gls{Webinterface}.
|
||||
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 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.
|
||||
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:\\
|
||||
@ -172,7 +164,7 @@ Diagnose-Werkzeug (PHP-Debugger). Dient dem Auffinden von Fehlern und Code-Cover
|
||||
|
||||
|
||||
\subsection{Funktionalität}
|
||||
\textbf{Noch nicht fertig!!} \\
|
||||
\textbf{Dieser Abschnitt ist noch nicht fertig!!} \\
|
||||
Nach Rücksprache mit unserem Auftraggeber wird in diesem Dokument der Testablauf der folgenden zwei Use-Cases ausführlicher beschrieben:
|
||||
|
||||
\begin{itemize}
|
||||
@ -190,7 +182,7 @@ Nach R
|
||||
\label{subsec:aktionBenutzbarkeit}
|
||||
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 Probanten Bögen ausgeteilt, welche der Bewertung der einzelnen Kriterien (aus Abschnitt \ref{subsec:zielBenutzbarkeit}) 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. \\
|
||||
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 Probanten gesucht. Zudem können durch die Studie unvorhersehbare Probleme entdeckt werden, da ein Benutzer anders mit der Website umgeht als wir. \newline \\
|
||||
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}
|
||||
\item Ist die Visualisierung einfach zu verstehen und ansprechend?
|
||||
@ -211,6 +203,7 @@ Bei der Beobachtung gilt es folgende Stichpunkte zu beachten:
|
||||
\end{itemize}
|
||||
|
||||
\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:
|
||||
\begin{itemize}
|
||||
\item Informationen über den Nutzer
|
||||
@ -233,7 +226,16 @@ Durch Punkt eins und zwei k
|
||||
\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)}
|
||||
|
||||
@ -296,6 +298,7 @@ Hierdurch erlangen wir einen
|
||||
\parindent 0pt
|
||||
\paragraph{Datenschutz}
|
||||
Um eine datenschutzkonforme Nutzung von Google Analytics zu gewährleisten, müssen folgende Vorgaben erfüllt werden \cite{DBA}:
|
||||
\label{subsubsec:datenschutz}
|
||||
|
||||
\begin{itemize}
|
||||
\item Vertrag zur Auftragsdatenverarbeitung mit Google (§ 11 BDSG - Vertrag)
|
||||
@ -309,8 +312,29 @@ Der anpasste Datenschutzhinweis findet sich im Impressum durch folgende Vorlage:
|
||||
>> Diese Website benutzt Google Analytics, einen Webanalysedienst der Google Inc. (\glqq Google\grqq). Google Analytics verwendet sog. \glqq Cookies\grqq, Textdateien, die auf Ihrem Computer gespeichert werden und die eine Analyse der Benutzung der Website durch Sie ermöglichen. Die durch den Cookie erzeugten Informationen über Ihre Benutzung dieser Website werden in der Regel an einen Server von Google in den USA übertragen und dort gespeichert. Im Falle der Aktivierung der IP-Anonymisierung auf dieser Webseite, wird Ihre IP-Adresse von Google jedoch innerhalb von Mitgliedstaaten der Europäischen Union oder in anderen Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum zuvor gekürzt. Nur in Ausnahmefällen wird die volle IP-Adresse an einen Server von Google in den USA übertragen und dort gekürzt. Im Auftrag des Betreibers dieser Website wird Google diese Informationen benutzen, um Ihre Nutzung der Website auszuwerten, um Reports über die Websiteaktivitäten zusammenzustellen und um weitere mit der Websitenutzung und der Internetnutzung verbundene Dienstleistungen gegenüber dem Websitebetreiber zu erbringen. Die im Rahmen von Google Analytics von Ihrem Browser übermittelte IP-Adresse wird nicht mit anderen Daten von Google zusammengeführt. Sie können die Speicherung der Cookies durch eine entsprechende Einstellung Ihrer Browser-Software verhindern; wir weisen Sie jedoch darauf hin, dass Sie in diesem Fall gegebenenfalls nicht sämtliche Funktionen dieser Website vollumfänglich werden nutzen können. Sie können darüber hinaus die Erfassung der durch das Cookie erzeugten und auf Ihre Nutzung der Website bezogenen Daten (inkl. Ihrer IP-Adresse) an Google sowie die Verarbeitung dieser Daten durch Google verhindern, indem sie das unter dem folgenden Link (\href{http://tools.google.com/dlpage/gaoptout?hl=de}{http://tools.google.com/dlpage/gaoptout?hl=de}) verfügbare Browser-Plugin herunterladen und installieren. Nähere Informationen hierzu finden Sie unter \href{http://tools.google.com/dlpage/gaoptout?hl=de}{http://tools.google.com/dlpage/gaoptout?hl=de} bzw. unter
|
||||
\href{http://www.google.com/intl/de/analytics/privacyoverview.html}{http://www.google.com/intl/de/analytics/privacyoverview.html} (allgemeine Informationen zu Google Analytics und Datenschutz). Wir weisen Sie darauf hin, dass auf dieser Webseite Google Analytics um den Code \glqq gat.\_anonymizeIp();\grqq erweitert wurde, um eine anonymisierte Erfassung von IP-Adressen (sog. IP-Masking) zu gewährleisten. << \cite{DBA}
|
||||
\subsection{Codequalität}
|
||||
\textbf{Noch nicht fertig!!} \\
|
||||
Maßnahmen zur Sicherung der Codequalität....
|
||||
Die folgenden Anforderungen und Vereinbarungen sollen dem Ziel eines gut strukturierten und gut lesbaren Codes beitragen:
|
||||
|
||||
\begin{itemize}
|
||||
\item Kommentare: \\
|
||||
Jede von uns geschriebene, nicht triviale Funktion muss einen Kommentarkopf der folgenden Form besitzen:\\
|
||||
/** \\
|
||||
* \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.
|
||||
\item Struktur: \\
|
||||
Der Code soll folgenden Standards gerecht werden: \\
|
||||
\begin{itemize}
|
||||
\item \gls{XHTML} in Version 1.1, standardisiert vom W3C 2010, \href{http://www.w3.org/TR/xhtml11/}{http://www.w3.org/TR/xhtml11/}
|
||||
\end{itemize}
|
||||
\item Namenskonventionen: \\
|
||||
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 eine Wiki gepflegt, die im \gls{Git} abrufbar ist und somit der besseren Verständlichkeit des Projekts durch andere Gruppen beiträgt.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
56
ws2011/BP/QS-Dokument/QS-Kommentare-Dominik-17-12-11.txt
Normal file
56
ws2011/BP/QS-Dokument/QS-Kommentare-Dominik-17-12-11.txt
Normal file
@ -0,0 +1,56 @@
|
||||
> 1.1.enumeration
|
||||
Die Formulierung mit Infinitiven passt wahrscheinlich besser. ("Umstrukturierung der Datenbank für neue Sensortypen")
|
||||
|
||||
> 1.1.
|
||||
> Da das Projekt auf insgesamt drei Gruppen aufgeteilt wurde, werden in diesem Dokument ausschließlich die Bereiche der Gruppe 1b behandelt.
|
||||
Passt irgendwie nicht so ganz mangels kausalem Zusammenhang. Vielleicht eher: "Das Projekt wurde auf insgesamt drei Gruppen aufgeteilt. In diesem Dokument werden ausschließlich die Bereiche der Gruppe 1b behandelt."
|
||||
|
||||
> 2.
|
||||
Schreibt nicht so häufig, was ihr da beschreibt, sondern macht es einfach. Eher weniger "In diesem Kapitel soll...". Das ist zwar beliebter Stil in der wissenschaftlichen Schreibpraxis, soll aber, soweit ich weiß, bei uns eher vermieden werden.
|
||||
Funktionalität wird also vom Auftraggeber gefordert. Benutzbarkeit nicht? Habt ihr die euch also ausgedacht? Vermeidet diesen Eindruck, der momentan noch entsteht.
|
||||
Die Codequalität taucht da noch überhaupt nicht auf, weiter unten dann allerdings als Kapitel, was den Leser wundert.
|
||||
|
||||
> 2.1. und 2.2. Definitionen nach ISO.
|
||||
Eine löbliche Verwendung von Referenzen. Momentan stehen die aber bloß einfach so da. Macht etwas mit diesen Informationen, erläutert, was ihr für die Angemessenheit, Richtigkeit, Sicherheit, Verständlichkeit, Erlernbarkeit, et cetera, tut, oder lasst sie weg.
|
||||
|
||||
> 2.3. Zitat
|
||||
Keine Ahnung, ob zitieren gut ist. Lassen wir es drinnen, geben es am 18. ab und warten gespannt, was die Projektbetreuung spricht. Mir persönlich gefällt es, man müsste es thematisch bloß noch mehr an den Inhalt anketten. Beispiel:
|
||||
"»Any fool can write code that a computer can understand. Good programmers write code that humans can understand.« [FBBOR+1999]. Der Quellcode, welcher im Rahmen dieses Projektes erstellt wird, soll offen für Erweiterungen sein und wird von weiteren Gruppen und Arbeiten genutzt. Daher muss darauf geachtet werden, dass sämtliche Codebausteine auch für Außenstehende lesbar und verständlich sind."
|
||||
Ihr könntet auch bemerken, dass euer Code schon während der Entwicklung im Laufe des Projektes von anderen, parallel arbeitenden Gruppen verwendet wird. Das erhöht die Wichtigkeit dieses Zieles weiter.
|
||||
|
||||
> 2.3.enumeration
|
||||
Alles tolle Sachen, jedoch: Wie dienen sie den Qualitätszielen? Alle Aufzählungspunkte sind Maßnahmen zur Sicherung der Codequalität und keine Selbstzwecke.
|
||||
|
||||
> 3.1.
|
||||
Hier ebenso: tolle Tools, aber was bringt es denn für Funktionalität und Benutzbarkeit, dass ihr Fehler etwa gerade mit FireBug meldet, und nicht mit Post-Its?
|
||||
|
||||
> 3.2.
|
||||
Wieso fiel die Auswahl gerade darauf?
|
||||
Wann werden diese Tests durchgeführt?
|
||||
Wie sind sie aufgebaut?
|
||||
Was passiert, wenn sie fehlschlagen?
|
||||
Welche Metrik stellt einen Fehler fest?
|
||||
Wer ist dafür verantwortlich?
|
||||
|
||||
> 3.3.
|
||||
Tippfehler: "deshalb" ohne "des", quasi nicht ganz sondern nur "halb".
|
||||
Sonst schön.
|
||||
|
||||
> 3.3.1.
|
||||
Viellicht noch ein Paar Worte zu den Metriken. Auf was wollt ihr beim Beobachten achten?
|
||||
|
||||
> 3.3.2.
|
||||
> Der folgende Fragebogen kann sich im Laufe des Projekts ändern. Es können neue Fragen hinzukommen oder aber bereits
|
||||
> vorhandene geändert bzw. herausgenommen werden.
|
||||
Prima. Wann? Wieso? Durch wen? Wie?
|
||||
Was liegt dem Fragebogen zugrunde? Wieso sieht der gerade so aus? Wer wertet den aus? Wann findet die Studie statt?
|
||||
|
||||
> 3.3.3. Datenschutz
|
||||
Gut!
|
||||
Wieso GoogleAnalytics?
|
||||
|
||||
> 4.
|
||||
Dampft das besser ein, indem ihr die Seitenumbrüche herausnehmt. Das ist zwar gut gemeint und gefällt mir so auch besser, ich weiß allerdings nicht, ob das Dokument zur Lektüre gedruckt wird, möglicherweise sogar mehrfach. Dann könnte die Zahl leerer Seiten sauer aufstoßen.
|
||||
|
||||
> 5.
|
||||
Anders herum. Das früheste Datum steht ganz oben.
|
||||
Loading…
x
Reference in New Issue
Block a user