QS update
This commit is contained in:
M.Scholz
parent
9801966785
commit
bda81e857c
Binary file not shown.
@ -2,12 +2,16 @@
|
||||
\usepackage[latin9]{inputenc} %unter Linux muss latin9 durch utf8 ersetzt werden!!
|
||||
\usepackage[ngerman]{babel}
|
||||
\usepackage{enumitem}
|
||||
\usepackage{wasysym}
|
||||
%reihenfolge von "hyperref" und "glossaries" ist wichtig!!!! nicht ändern!
|
||||
\usepackage[pdftitle={Qualitätssicherungsdokument}]{hyperref}
|
||||
\usepackage[style=altlist]{glossaries}\makeglossaries
|
||||
|
||||
|
||||
% % GLOSSAR % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
|
||||
|
||||
|
||||
|
||||
% % % % % % % % % % % % % % % %% % % % % % % % % % % GLOSSAR % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
|
||||
\makeglossaries
|
||||
|
||||
%\newglossaryentry{}{name={},description={}}
|
||||
@ -24,12 +28,13 @@
|
||||
\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{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}}
|
||||
\newglossaryentry{XHTML}{name={XHTML},description={Extensible Hypertext Markup Language: Auszeichnungssprache zur strukturierten Darstellung von Texten, Bildern und Hyperlinks in Textform}}
|
||||
|
||||
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{Qualitätssicherungsdokument\\
|
||||
@ -49,54 +54,34 @@ Teamleiter: Dominik Fischer
|
||||
\tableofcontents
|
||||
|
||||
|
||||
|
||||
|
||||
% % % % % % % % % % % % % % % %% % % % % % % % % % % EINLEITUNG % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
|
||||
\newpage
|
||||
\section{Einleitung}
|
||||
In diesem Dokument werden Tests und Prozesse beschrieben, dokumentiert und ausgewertet. Ziel der Qualitätssicherung ist die Sicherstellung sowohl der angestrebten Softwarequalität als auch der Qualität der Prozesse und Dokumente. Dazu werden verschiedene Testmethoden angewandt, um Kernpunkte wie etwa Funktionalität, Richtigkeit und in Teilbereichen auch Interoperabilität zu überprüfen. Des weiteren wird auf die verwendeten Ansätze zur konstruktiven Qualitätssicherung eingegangen. In den kommenden Kapiteln werden zuerst die zu prüfenden Module von da-sense vorgestellt und deren Funktionsweise kurz erläutert. Im Anschluss wird auf die verwendeten Methoden, Werkzeuge sowie die eigentlichen Prüfprozesse eingegangen. Weiterhin werden die jeweiligen Testspezifikationen dargelegt sowie die Beschreibung der Tests und deren Ergebnisse vorgestellt.
|
||||
|
||||
In diesem Dokument werden Tests und Prozesse beschrieben, dokumentiert und ausgewertet. Ziel der Qualitätssicherung ist die Sicherstellung sowohl der angestrebten Softwarequalität als auch der Qualität der Prozesse. Dazu werden verschiedene Testmethoden angewandt, um Kernpunkte wie etwa Funktionalität, Richtigkeit und in Teilbereichen auch Interoperabilität zu überprüfen. Des weiteren wird auf die verwendeten Ansätze zur konstruktiven Qualitätssicherung eingegangen. In den kommenden Kapiteln wird auf die verwendeten Methoden, Werkzeuge sowie die eigentlichen Prüfprozesse eingegangen.
|
||||
% Weiterhin werden die jeweiligen Testspezifikationen dargelegt sowie die Beschreibung der Tests und deren Ergebnisse vorgestellt.
|
||||
|
||||
|
||||
\subsection{Das Projekt}
|
||||
Das Projekt da-sense ist ein großflächiges Sensornetzwerk in Darmstadt. Es besteht aus einer Webapplikation, die dem Nutzer in Zukunft erlauben soll verschiedene Naturerscheinungen wie z.B. Lautstärkepegel (\gls{dB}), \gls{CO}- und \gls{CO2}-Konzentration einzusehen. Die Daten hierfür stammen aus verschiedenen Quellen (Smartphones und Sensoren) und werden in eine Datenbank transferiert, die schließlich über die Webapplikation visualisiert abgerufen werden können. Bisher konnten die Datenbank und die Webapplikation nur mit den von Smartphones gesendeten Daten umgehen. Im Rahmen des Bachelorpraktikums im Wintersemester 2011/2012 sollen folgende Funktionalitäten hinzukommen:
|
||||
\begin{itemize}
|
||||
\item Datenbank für neue Sensortypen umstrukturieren
|
||||
\item Installation von Waspmotes Sensoren auf Straßenbahnen
|
||||
\item API auf neue Datenbank anpassen und neue Visualisierung des User-Font-End erstellen
|
||||
\item Installation von \gls{Waspmotes Sensoren} auf Straßenbahnen
|
||||
\item \gls{API} auf neue Datenbank anpassen und neue Visualisierung des \gls{User-Front-End} erstellen
|
||||
\item Android-App
|
||||
\end{itemize}
|
||||
Da das Projekt auf insgesamt drei Gruppen aufgeteilt wurde, werden in diesem Dokument ausschließlich die Bereiche der Gruppe 1b behandelt. Der Themenbereich umfasst die Umstellung der \gls{API} auf eine neue Datenbank und die Erstellung einer neuen Visualisierung des \gls{User-Front-End}.
|
||||
|
||||
|
||||
|
||||
|
||||
% % % % % % % % % % % % % % % %% % % % % % % % % % % QUALITÄTSZIELE % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
|
||||
\section{Qualitätsziele}
|
||||
In diesem Abschnitt werden die zu testenden Qualitätsziele genauer spezifiziert
|
||||
|
||||
\subsection{Codequalität}
|
||||
>>Any fool can write code that a computer can understand. Good programmers write code that humans can understand.<< \cite{fowler}. \\
|
||||
Die folgenden Anforderungen und Vereinbarungen sollen ein gut lesbaren und gut strukturierten Code zur Folge haben.
|
||||
\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 ''true'' bzw. ''false'' 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: \\
|
||||
Welche Konventionen legen wir hier fest?
|
||||
\item Begrenzung der Zeilenlänge: \\
|
||||
Hab ich im Internet gefunden, finde ich aber für sinnfrei ;)
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
In diesem Abschnitt werden die zu testenden Qualitätsziele genauer spezifiziert. Dabei werden die Qualitätsmerkmale Funktionalität und Benutzbarkeit besonderst hevorgehoben, da sie für unser Projekt von höchster Priorität sind. Das Merkmal der Funktionalität wird von unserem Auftraggeber gefordert. Die Benutzbarkeit ist unabdingbar, da die neue Visualisierung des \gls{User-Front-End} nach erfolgreichen Abschluss des Projekts einer großen Personengruppe zur Verfügung stehen soll.
|
||||
%Hier ein zitat mit verweis: >>Damit nur hochwertiges Wissen erzeugt und als Grundlage für weitere Arbeiten nutzbar gemacht wird, gibt es internationale Standards für wissenschaftliche Qualität<< \cite{bss+:2008}
|
||||
|
||||
|
||||
\subsection{Funktionalität}
|
||||
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:
|
||||
@ -113,72 +98,185 @@ Die Funktionalit
|
||||
\textit{Einhaltung von anwendungsspezifische Normen und gesetzlichen Bestimmungen.}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Benutzbarkeit}
|
||||
\label{subsec:zielBenutzbarkeit}
|
||||
Als Benutzbarkeit wird der Aufwand definiert, der zum Einsatz der Software von den Benutzer aufgebracht werden muss. Zudem bedarf es einer individuellen Beurteilung der Benutzung durch eine vorher bestimmte Benutzergruppe.\cite{ISO/IEC 9126}. \\
|
||||
Die Benutzbarkeit lässt sich in die folgenden Punkte gliedern:
|
||||
\begin{itemize}
|
||||
\item Verständlichkeit: \\
|
||||
\textit{Aufzubringender Aufwand des Benutzers, damit sich dieser auf der Weboberfläche zurechtfindet, z.B. verständliche Menüführung.}
|
||||
\item Erlenbarkeit: \\
|
||||
\textit{Aufzubringender Aufwand des Benutzers um die Anwendung korrekt zu nutzen.}
|
||||
\item Bedienbarkeit: \\
|
||||
\textit{Aufzubringender Aufwand des Benutzers die Anwendung zu bedienen.}
|
||||
\item Attraktivität: \\
|
||||
\textit{Beschreibt die Anziehungskraft der Anwendung auf den Benutzer.}
|
||||
\item Konformität: \\
|
||||
\textit{Beschreibt den Grad, in dem die Software Normen zur Benutzbarkeit erfüllt.}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\subsection{Codequalität}
|
||||
>>Any fool can write code that a computer can understand. Good programmers write code that humans can understand.<< \cite{fowler}. \\
|
||||
Die folgenden Anforderungen und Vereinbarungen sollen einen gut lesbaren und gut strukturierten Code zur Folge haben.
|
||||
\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 ''true'' bzw. ''false'' 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}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Geschwindigkeit?}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Dokumente ?????}
|
||||
dokumentqulität
|
||||
|
||||
\subsection{Prozess}
|
||||
prozessqualität
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
% % % % % % % % % % % % % % % %% MAßNAHMEN ZUM ERREICHEN DER QUALITÄTSZIELE % % % % % % % % % % % % % % % %% % % % % % % % % %
|
||||
\section{Maßnahmen zum Erreichen der Qualitätsziele}
|
||||
Im folgenden Abschnitt werden die Maßnahmen zum Erreichen der oben genannten Qualitätsziele und die von uns dafür verwendeten Werkzeuge genauer beschrieben. Auch hier werden die Maßnahmen zur Sicherung von Funktionalität und Benutzbarkeit in den Vordergrund gestellt.
|
||||
|
||||
\subsection{Qualitätswerkzeuge}
|
||||
\begin{itemize}
|
||||
\item FireBug: \\
|
||||
Dient der Fehlersuche, Bearbeitung und Monitoring des \gls{Webinterface}.
|
||||
\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.
|
||||
\item Netbeans:\\
|
||||
Als integrierte Entwicklungsumgebung (IDE) wird Netbeans verwendet, wodurch Syntxfehler 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 Anallysen.
|
||||
\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.
|
||||
\item soapUI:\\
|
||||
...
|
||||
\item PHPUnit:\\
|
||||
...
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Code}
|
||||
maßnahmen für codequalität
|
||||
\subsection{Funktionalität}
|
||||
\textbf{Noch nicht fertig!!} \\
|
||||
Nach Rücksprache mit unserem Auftraggeber wird in diesem Dokument der Testablauf der folgenden zwei Use-Cases ausführlicher beschrieben:
|
||||
|
||||
\subsection{Dokumente}
|
||||
maßnahmen für dokumentqulität
|
||||
\begin{itemize}
|
||||
\item Anfordern der Daten als XML-Datei
|
||||
\item Integration der Daten der \gls{Waspmotes Sensoren} in die Datenbank
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Prozess}
|
||||
maßnahmen für prozessqualität
|
||||
\subsubsection{Use-Case: Anfordern der Daten als XML-Datei}
|
||||
|
||||
|
||||
\subsubsection{Use-Case: Integration der Daten der \gls{Waspmotes Sensoren} in die Datenbank}
|
||||
|
||||
|
||||
\subsection{Benutzbarkeit}
|
||||
\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, weshalb auch die Benutzerstudie erst am Ende von uns durchgeführt werden kann. \\
|
||||
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 heisst 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 \\
|
||||
\textbf{Was wollen wir wissen?}
|
||||
\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 drei Teilen \textit{Beobachtung}, \textit{Fragebogen} und \textit{Logdaten Analyse} zusammen. Somit erhalten wir drei unterschiedliche Informationsquellen, welche in Korrelation zueinander stehen sollten.
|
||||
|
||||
\subsubsection{Beobachtung}
|
||||
Die Beobachtung des Probanten beim Bedienen der Website ist die einfachste Methode zur Evaluation. Hierbei bleibt der Entwickler in der Position des Beobachters und protokoliert. Der Probant surft frei nach seinem Willen durch die Website oder bekommt konkrete Aufgaben gestellt, die er lösen muss.
|
||||
|
||||
\subsubsection{Fragebogen}
|
||||
\textit{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.}
|
||||
|
||||
|
||||
\begin{enumerate}
|
||||
\item Wie alt sind Sie?
|
||||
|
||||
\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 Wie finden Sie die Visualisierung der Website? (0 = nicht ansprechend; 10 = sehr ansprechend) \\
|
||||
|
||||
nicht ansprechend \Square \Square \Square
|
||||
|
||||
\textbf{Noch nicht fertig!!!}
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection{Logdaten Analyse}
|
||||
Zur Analyse der Logdaten wird das Tool Google Analytics verwendet. Hiermit ist es möglich verschiedenste Statistiken zu erhalten. \\
|
||||
Für uns sind die folgenden Statistiken von großer Bedeutung:
|
||||
\begin{itemize}
|
||||
\item Besucherzahlen
|
||||
\item am meisten aufgerufene Seiten
|
||||
\item Pfad der besuchten Seiten
|
||||
\item Ausstiegsseiten
|
||||
\item ''Absprungsrate''
|
||||
\item Besuchszeit der einzelnen Seiten
|
||||
\item ...
|
||||
\end{itemize}
|
||||
Hierdurch erlangen wir einen Überblick wie das \gls{Webinterface} von den Nutzern bedient wird und können daraus schließen welche Funtionalitäten intutiv und welche nicht intuitiv sind.
|
||||
|
||||
|
||||
\subsection{Codequalität}
|
||||
\textbf{Noch nicht fertig!!} \\
|
||||
maßnahmen zur sicherung der codequalität....
|
||||
|
||||
|
||||
|
||||
|
||||
\section{Testmethoden}
|
||||
% % % % % % % % % % % % % % % %% % % % % % % % % % % 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}
|
||||
|
||||
|
||||
\newpage
|
||||
\section{Testprotokolle}
|
||||
\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.
|
||||
|
||||
\newpage
|
||||
\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.
|
||||
|
||||
\newpage
|
||||
\subsubsection{Codequalität}
|
||||
|
||||
|
||||
\newpage
|
||||
\subsection{User-Stories}
|
||||
|
||||
|
||||
|
||||
|
||||
% % % % % % % % % % % % % % % %% % % % % % % % % % % VERSIONSHISTORIE % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
|
||||
\newpage
|
||||
\section{Versionshistorie}
|
||||
Für eine bessere Nachvollziehbarkeit sind die Änderungen in diesem Dokument tabellarisch festgehalten.
|
||||
|
||||
\begin{tabbing}
|
||||
\begin{tabular}{||p{5.4cm}||p{11cm}||}
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} Noch eine version & test \\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} test & hier soll ein Link zu \gls[hyper]{CO2} und \gls{CO2} stehen \\
|
||||
%\hline \rule[-2ex]{0pt}{5.5ex} Noch eine version & test \\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.0.9 - 14.12.2011 - MS & Benutzerstudie \\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.0.1 - 09.12.2011 - MS & Einleitung, Qualitätsziele (Codequalität, Funktionalität), Qualitätswerkzeuge\\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.0.0 - 01.12.2011 - MS & Dokument angelegt\\
|
||||
\hline
|
||||
@ -189,7 +287,7 @@ F
|
||||
%fügt elemenmte dem toc hinzu
|
||||
\addcontentsline{toc}{section}{Glossar}
|
||||
|
||||
\glsaddall %somit werden alle Glossareinträge geprinted. Ansonten nur die, die auch im Text verwendet werden.
|
||||
% \glsaddall %somit werden alle Glossareinträge geprinted. Ansonten nur die, die auch im Text verwendet werden.
|
||||
\printglossary[title=Glossar]
|
||||
|
||||
|
||||
@ -198,11 +296,15 @@ 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[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[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[ISO9001]{iso:9001} International Organization for Standardization. \emph{ISO 9001}, 12.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[WIKI2011]{wiki:2011} Wikipedia, die freie Enzyklopädie. \emph{WIKIPEDIA}, Stand: 12.12.2011
|
||||
|
||||
% \bibitem[WIKI2011]{wiki:2011} Wikipedia, die freie Enzyklopädie. \emph{WIKIPEDIA}, Stand: 12.12.2011
|
||||
\end{thebibliography}
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user