From 3559aed149938c1228879adfab527f94b836acf9 Mon Sep 17 00:00:00 2001 From: schuler-henry <72646334+schuler-henry@users.noreply.github.com> Date: Thu, 5 Jan 2023 16:15:11 +0100 Subject: [PATCH] Small changes. --- chapter/AnforderungenUndNutzererwartungen.tex | 2 +- chapter/Einleitung.tex | 4 ++-- "chapter/FehlerKostenQualitaetsma\303\237nahmen.tex" | 8 ++++---- chapter/GrundwissenUndBegriffe.tex | 2 +- chapter/UmsetzungTests.tex | 8 ++++---- main.tex | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-) diff --git a/chapter/AnforderungenUndNutzererwartungen.tex b/chapter/AnforderungenUndNutzererwartungen.tex index 3c23c62..c214664 100644 --- a/chapter/AnforderungenUndNutzererwartungen.tex +++ b/chapter/AnforderungenUndNutzererwartungen.tex @@ -318,7 +318,7 @@ \subsubsection{Verborgene Erwartungen} Ein weiteres Beispiel, welches ebenfalls im Kontext \gqq{DEV-CHAT} relevant ist, ist die Unabhängigkeit der Applikation von dem Betriebssystem, beziehungsweise der Art der zugrundeliegenden Hardware. \subsubsection{Prägende Erwartungen} -Prägende Erwartungen ergeben sich aus der Erfahrungen mit der Benutzung bestimmter Applikationen. +Prägende Erwartungen ergeben sich aus der Erfahrungen mit der Benutzung bestimmter App\-li\-ka\-tio\-nen. Bestimmte Interaktionsmuster oder auch Designentscheidungen werden durch eine regelmäßige Benutzung verinnerlicht und als intuitiv empfunden. Ein Beispiel hierfür ist Social Media. Die meisten Nutzer sind mit der Benutzung von Social-Media-Plattformen vertraut und kennen den Sinn und Zweck der enthaltenen Interaktionselemente. diff --git a/chapter/Einleitung.tex b/chapter/Einleitung.tex index db444e1..cc32a7c 100644 --- a/chapter/Einleitung.tex +++ b/chapter/Einleitung.tex @@ -4,12 +4,12 @@ \section{Einleitung} Hierzu wird das Softwareprodukt \gqq{DEV-CHAT} aus der Vorlesung Software-Engineering 1 verwendet. \newparagraph %Beschreibung devchat -DEV-CHAT ist ein Chatportal mit mehreren Chatrooms, denen man über einen Schlüssel beitreten kann. +\gqq{DEV-CHAT} ist ein Chatportal mit mehreren Chaträumen, denen man über einen Schlüssel beitreten kann. Die Oberfläche ist schlicht im Informatik/Konsolen Stil gehalten und alle Operationen werden über eine Kommandozeile ausgeführt. Über die Kommandozeile lassen sich Befehle ausführen, um zum Beispiel Direktnachrichten zu senden oder Umfragen zu starten. \newparagraph %Aufgabenstellung Zu Beginn der Hausarbeit werden, wie bereits angekündigt, die Begriffe Softwarequalität und Qualität definiert und gegeneinander abgegrenzt, anschließend wird das Kano-Modell erläutert und begründet, wieso Requirements Engineering essenziell für eine hohe Softwarequalität ist. -Die Folgeschritte werden auf den DEV-CHAT angewandt, diese gliedern sich in drei Punkte. +Die Folgeschritte werden auf den \gqq{DEV-CHAT} angewandt, diese gliedern sich in drei Punkte. Zunächst werden die Anforderungen und Nutzerwartungen definiert, in einem weiteren Schritt werden Fehler, Kosten und Qualitätsmaßnahmen behandelt. Abschließend wird das Thema Umsetzung und Tests erörtert. \ No newline at end of file diff --git "a/chapter/FehlerKostenQualitaetsma\303\237nahmen.tex" "b/chapter/FehlerKostenQualitaetsma\303\237nahmen.tex" index 9fb4b10..eafee8d 100644 --- "a/chapter/FehlerKostenQualitaetsma\303\237nahmen.tex" +++ "b/chapter/FehlerKostenQualitaetsma\303\237nahmen.tex" @@ -20,7 +20,7 @@ \subsection{Faults und Defects} % Fehlerschwere (1-5) (Prio auch noch mit rein?) % Priorität % potentielle Fehlerkosten -Im folgenden Abschnitt werden die typischen Faults und Defects des DEV-CHAT's dargestellt. +Im folgenden Abschnitt werden die typischen Faults und Defects des \gqq{DEV-CHAT}'s dargestellt. Zusätzlich werden die Fehlerschwere, Priorität und potentielle Fehlerkosten identifizert und dargestellt. Dies ist in der Tabelle \ref{tab:FaultsAndDeffects} dargestellt. Die Fehlerschwere wird aus Nutzersicht beschrieben und teilt sich in fünf Kategorien die in der nachfolgenden Auflistung definiert werden. @@ -112,7 +112,7 @@ \subsection{Qualitätskostensenkung und Fehlertoleranz} \textbf{Check}: Vergleich Sollzustand und Istzustand.\\ \textbf{Act}: Abhängig davon, ob die Maßnahmen erfolgreich sind, werden diese als Standard definiert oder der Prozess wird erneut durchlaufen. \end{quote} -Da DEV-CHAT einmalig in der Vorlesung Software-Engineering entwickelt wurde, wird es einen weiteren Entwicklungsprozess mit dieser Teamkonstellation nicht geben, weshalb eine Prozessoptimierung nur theoretisch durchgeführt werden kann. +Da \gqq{DEV-CHAT} einmalig in der Vorlesung Software-Engineering entwickelt wurde, wird es einen weiteren Entwicklungsprozess mit dieser Teamkonstellation nicht geben, weshalb eine Prozessoptimierung nur theoretisch durchgeführt werden kann. Die Probleme und die zugeordneten Maßnahmen der Plan Phase werden in Tabelle~\ref{tab:pdca} dargestellt. \begin{table}[H] \centering @@ -154,7 +154,7 @@ \subsection{Qualitätskostensenkung und Fehlertoleranz} Alternativ zu der PDCA-Analyse kann auch \ac{CMMI} verwendet werden, auf welches in dieser Arbeit nicht tiefer eingegangen wird. \newparagraph Bei der Produktverbesserung wird die Qualität des tatsächlichen Produkts verbessert. -Da DEV-CHAT nur im Rahmen der Vorlesung entwickelt wurde und nicht veröffentlicht wird, ist eine Qualitätsoptimierung auch nur theoretisch durchführbar. +Da \gqq{DEV-CHAT} nur im Rahmen der Vorlesung entwickelt wurde und nicht veröffentlicht wird, ist eine Qualitätsoptimierung auch nur theoretisch durchführbar. Sollte eine Weiterentwicklung bzw. eine Veröffentlichung erfolgen, sollten die Untenstehenden Punkte abgearbeitet werden. \begin{itemize} \item Erweiterung der UnitTests, bisher nur Exemplarisch @@ -166,7 +166,7 @@ \subsection{Qualitätskostensenkung und Fehlertoleranz} \subsection{\acl{FMEA}} \label{sec:FMEA} % Failure Mode and Effects Analysis (FMEA) (realistische Annahme für Risikoprioritätszahl RPZ -Im folgenden wird für den DEV-CHAT eine \ac{FMEA} durchgeführt. +Im folgenden wird für den \gqq{DEV-CHAT} eine \ac{FMEA} durchgeführt. \gqq{ Ziel der FMEA ist es, bei der Entwicklung eines Produktes bzw. der Bearbeitung einer Aufgabe mögliche Fehler frühzeitig zu erkennen, um die Funktion sowie die Sicherheit und eine hohe Produkt- bzw. Prozessqualität gewährleisten zu können. Durch die frühzeitige Erkennung können sowohl die Anlaufkosten und die entstehenden Kosten infolge von Rückrufaktionen und Reklamationen reduziert werden als auch die Entwicklungszeit verkürzt werden diff --git a/chapter/GrundwissenUndBegriffe.tex b/chapter/GrundwissenUndBegriffe.tex index 73419ec..1f1ce63 100644 --- a/chapter/GrundwissenUndBegriffe.tex +++ b/chapter/GrundwissenUndBegriffe.tex @@ -45,7 +45,7 @@ \subsection{Kano-Modell} Die x-Achse definiert dabei den Grad der Erfüllung der Merkmale, wobei die y-Achse den Grad der Kundenzufriedenheit darstellt. Die rote Kurve in Abbildung~\ref{fig:kano-modell} zeigt die Charakteristik der Basismerkmale. -Während eine unzureichende Erfüllung des Merkmals eine negative Kundenzufriedenheit verursacht, führt eine übermäßige Erfüllung des Merkmals nicht zu einer positiven Kundenzufriedenheit, da diese Merkmale als absolutes Minimum (Must-be) angesehen werden. +Während eine unzureichende Erfüllung des Merkmals eine negative Kundenzufriedenheit verursacht, führt eine übermäßige Erfüllung des Merkmals nicht zu einer positiven Kundenzufriedenheit, da diese Merkmale als absolutes Minimum (must-be) angesehen werden. Im Gegensatz dazu stehen die Leistungsmerkmale, welche durch die blaue Kurve charakterisiert werden. Hierbei handelt es sich um einen linearen Zusammenhang zwischen dem Grad der Erfüllung eines Merkmals und der Kundenzufriedenheit. diff --git a/chapter/UmsetzungTests.tex b/chapter/UmsetzungTests.tex index b18199b..03a7f9f 100644 --- a/chapter/UmsetzungTests.tex +++ b/chapter/UmsetzungTests.tex @@ -172,7 +172,7 @@ \subsubsection*{Testumfang} In der Konzeptionsphase wurden die Use-Cases des Systems modelliert und Abläufe definiert. Mit den Systemtests werden diese Abläufe simuliert und überprüft, ob diese wie erwartet funktionieren. Abschließend werden Akzeptanz-Tests verwendet um die User-Storys zu verifizieren. -Während der Production werden Availability-Tests durchgeführt, um die Verfügbarkeit zu gewährleisten. +Während dem Betrieb des \gqq{DEV-CHAT} werden Availability-Tests durchgeführt, um die Verfügbarkeit zu gewährleisten. \subsubsection*{Teststrategie} Bei der Entwicklung wird der \ac{TDD} Ansatz verfolgt, d.h. dass die Tests vor der Entwicklung der Funktion geschrieben werden. Zusätzlich wird \ac{CI} verwendet, um einen automatisierten Build der Software zu erstellen und um die Tests auszuführen. @@ -190,7 +190,7 @@ \subsubsection{Testfall 1: Benutzer registrieren} % Testfall 1: Benutzer registrieren Bei diesem Test wird überprüft, ob ein Benutzer sich registrieren kann. \paragraph{Ablaufbeschreibung} \mbox{}\\ -Ausgangssituation: Instanz wird ausgeführt und mit dem Browser erreichbar. Der Benutzer ist noch nicht registriert. Folgende Schritte: +Ausgangssituation: Instanz wird ausgeführt und ist mit dem Browser erreichbar. Der Benutzer ist noch nicht registriert. Folgende Schritte: \begin{enumerate} \item Website Aufrufen. @@ -215,7 +215,7 @@ \subsubsection{Testfall 2: Nachrichten senden} % Testfall 2: Nachrichten senden Bei diesem Test wird überprüft, ob ein Benutzer Nachrichten senden kann. \paragraph{Ablaufbeschreibung} \mbox{}\\ -Ausgangssituation: Instanz wird ausgeführt und mit dem Browser erreichbar. Der Benutzer ist eingeloggt. Folgende Schritte: +Ausgangssituation: Instanz wird ausgeführt und ist mit dem Browser erreichbar. Der Benutzer ist eingeloggt. Folgende Schritte: \begin{enumerate} \item Website Aufrufen. @@ -241,7 +241,7 @@ \subsubsection{Testfall 3: Administrationsbereich aufrufen} % Testfall 3: Administrationsbereich aufrufen Bei diesem Test wird überprüft, ob ein Benutzer den Administrationsbereich aufrufen kann. \paragraph{Ablaufbeschreibung} \mbox{}\\ -Ausgangssituation: Instanz wird ausgeführt und mit dem Browser erreichbar. Der Benutzer ist eingeloggt. Folgende Schritte: +Ausgangssituation: Instanz wird ausgeführt und ist mit dem Browser erreichbar. Der Benutzer ist eingeloggt. Folgende Schritte: \begin{enumerate} \item Website Aufrufen. \item Den Button \gqq{Admin Settings} klicken. diff --git a/main.tex b/main.tex index 6679ead..2bc3476 100644 --- a/main.tex +++ b/main.tex @@ -162,7 +162,7 @@ \include{pages/abkuerzungsverzeichnis} \include{pages/abbildungsverzeichnis} \include{pages/tabellenverzeichnis} - \include{pages/listingsverzeichnis} + % \include{pages/listingsverzeichnis} % \include{pages/vorwort}