13hannes11/bachelor_thesis
1
0
Fork 0
mirror of https://github.com/13hannes11/bachelor_thesis.git synced 2024-09-04 01:11:00 +02:00
Code Issues Projects Releases Wiki Activity

renamed folders to allow inserting folders in between

Browse Source
This commit is contained in:
hannes.kuchelmeister
2020-01-22 13:52:31 +01:00
parent 4b2a438868
commit f1782b8242
55 changed files with 581 additions and 519 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
20_Proposal/sections/00_introduction.tex Normal file
View File

@@ -0,0 +1,16 @@
\chapter{Introduction}
\label{ch:Introduction}
\section{Motivation}
\label{sec:Introduction:Motivation}
Product configuration supports companies in their sales process, it reduces costs and decreases time needed to produce an offer for a product \cite{shafieeCostBenefitAnalysis2018}. Usually configuration is done by one user but for complex decisions the risk that a single user will make mistakes increases therefore making the decision in a group can yield better results \cite{felferningGroupBasedConfiguration2016, felfernigGroupDecisionSupport2011}. Unfortunately groups are not immune to group biases and group dynamics that can reduce the benefits of group decisions \cite{kerrBiasJudgmentComparing1996}.
There exists work on recommender systems for configuration and there are recommender systems for groups but there has not been any work on how to combine these. A recommender system, can help reduce influence of group behaviour and thereby increases the benefit of groups making more rational decisions than individuals \cite{charnessGroupsMakeBetter2012}.
\section{Research Question}
\label{sec:Introduction:ResearchQuestion}
\begin{enumerate}
\item How can decision-making in group configuration processes be supported (through recommender systems)? (central question)
\item Which requirements do configuration systems for collaborative decision-making have and how could such a system look like?
\item How does group hierarchy and structure influence the decision-making process in group based configuration scenarios?
\end{enumerate}

136
20_Proposal/sections/10_foundations.tex Normal file
View File

@@ -0,0 +1,136 @@
\chapter{Foundations}
\label{ch:Foundations}
Since this thesis focuses on recommender systems to support group decisions in the context of group based configuration it is important to define what we mean by these terms. This chapter describes foundations that sow what a recommender system is, approaches that can be taken and how it is possible to build with these approaches a group recommender. Additionally configuration and group configuration are defined. In group decisions biases can have an effect of the groups decision making ability and some of these are presented here to consider their effect on group decisions.
\section{Recommender System}
\label{sec:Foundations:RecommenderSystem}
A recommender system is a system that gives individualized recommendations to users to guide them through a large space of objects \cite[~ p. 331]{burkeHybridRecommenderSystems2002}.
There are several approaches to recommender systems presented in \cite{felfernigGroupRecommenderSystems2018}, these are: collaborative filtering, content-based filtering, critiquing-based filtering, constraint-based, hybrid recommendation.
\begin{table}
\centering
\begin{tabular}{ l | c | c | c | c | c }
& The Matrix & Titanic & Die Hard & Forest Gump & Wall-E \\ \hline
John & 5 & 1 & & 2 & 2 \\
Lucy & 1 & 5 & 2 & 5 & 5 \\
Eric & 2 & ? & 3 & 5 & 4 \\
Diane & 4 & 3 & 5 & 3 & \\
\end{tabular}
\caption{An example showing users ratings for movies by \citeauthor{ningComprehensiveSurveyNeighborhoodBased2015} \cite{ningComprehensiveSurveyNeighborhoodBased2015}.}
\label{tab:Foundations:RecommenderSystem:MoviePreferences}
\end{table}
\subsection{Collaborative Filtering}
In collaborative filtering a users rating for unknown items is predicted by finding similar users who have rated it. Their rating is used as prediction
\cite[~ pp. 7, 8]{felfernigDecisionTasksBasic2018}.
Collaborative Filtering can not only be done using users, it can also be item-based. Hereby the similarity between items is used for a recommendation and not similar users \cite{ricciRecommenderSystemsHandbook2015}. In the context of configuration the similarity to other historic configurations can be used which makes it an item based approach.
\autoref{tab:Foundations:RecommenderSystem:MoviePreferences} shows an example rating matrix. A simple user-based way to calculate rating would be now to use a k-nearest neighbour (kNN) algorithm and then take the average of those ratings. Using this method with $k := 2$ and euclidean distance our closest neighbours are \textit{Lucy} and \textit{Diane} therefore giving us a predicted rating of $4$. If we use item based illustration instead, we will try to find similar items based on the users rating. An example of similar items here would be \textit{Forest Gump} and \textit{Wall-E} as John and Lucy each have given them the sane rating and Eric's rating is off by one. Using again kNN with $k := 2$ we find that \textit{Forest Gump} and \textit{Wall-E} are the most similar to \textit{Titanic} thereby having a predicted rating of $4.5$.
However this simple similarity and prediction function does not take into account different distances. For example Lucy's ratings are more similar compared to Eric's than Diane's but Diane's and Lucy's rating is valued the same amount.
\subsection{Content-Based Filtering}
Items and users are assigned to categories. Based on consumption and rating of items a user will have implicit ratings for categories. Predictions are now made based on a categories of the new item \cite[~ pp. 10, 11]{felfernigDecisionTasksBasic2018}.
Using our example from \autoref{tab:Foundations:RecommenderSystem:MoviePreferences} and using an additional category matrix (see \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringCategories}) we can derive a rating matrix per category (using the average rating of the user of each movie contained in this category). The result can be seen in \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringProfiles}. To predict Eric's rating of Titanic we now can use the categories of \textit{Titanic} and average out Eric's implicit rating per category. Titanic is only in the category romance and as Eric's rating of \textit{Forest Gump} is $5$ the prediction is a rating of $5$. Categories don't have to be the genre, they could be any kind of data about a movie.
\begin{table}
\centering
\begin{tabular}{ l | c | c | c | c | c }
& The Matrix & Titanic & Die Hard & Forest Gump & Wall-E \\ \hline
Action & x & & x & & \\
Sci-Fi & x & & & & \\
Thriller & & & x & & \\
Romance & & x & & x & \\
Family & & & & x & x \\
\end{tabular}
\caption{Showing example categories for movies in \autoref{tab:Foundations:RecommenderSystem:MoviePreferences}.}
\label{tab:Foundations:RecommenderSystem:ContentBasedFilteringCategories}
\end{table}
\begin{table}
\centering
\begin{tabular}{ l | c | c | c | c | c }
& Action & Sci-Fi & Thriller & Romance & Family \\ \hline
John & 5 & 5 & & 1.5 & 2 \\
Lucy & 1.5 & 1 & 2 & 5 & 5 \\
Eric & 2.5 & 2 & 3 & 5 & 4.5 \\
Diane & 4.5 & 4 & 5 & 3 & 3 \\
\end{tabular}
\caption{User profiles generated from categories and rating from \autoref{tab:Foundations:RecommenderSystem:MoviePreferences} and \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringCategories}.}
\label{tab:Foundations:RecommenderSystem:ContentBasedFilteringProfiles}
\end{table}
\subsection{Critiquing-Based Recommendation}
Items are recommended and a user can then critique on attributes of the recommendation. Based on that a similar item which does not have those critiques can be recommended. User preferences are implicitly collected this way \cite{knijnenburgEachHisOwn2011}.
With a critique based approach Eric sees a suggestion of watching \textit{The Island} and its attributes. He then can say that he finds this movie has too much action. The critique based recommender will now present a movie that has similar attributes as \textit{The Island} but with less action. For example \textit{Titanic} could be the next suggestion.
\subsection{Constraint-Based Recommendation}
Hereby filter rules are defined which filter out items that don't fulfil specified rules. A user models their requirements with these rules and thereby gets a list of recommended items. This approach requires deep knowledge about a product because it needs a detailed description of features \cite[~ p. 12]{felfernigDecisionTasksBasic2018}.
Our movie example (see \autoref{tab:Foundations:RecommenderSystem:MoviePreferences}) needs have additional information for example about plot structure, pacing, length and other attributes of the movie. Now the user could give as filter, that the movie should be no longer than 120 minutes, be categorized as action or thriller and have a fast pacing. The system will only recommend movies that fit into these categories.
\subsection{Hybrid Recommendation}
A hybrid recommender combines different recommendation approaches to use the strengths of each individual one and to reduce effects of weaknesses \cite{burkeHybridRecommenderSystems2002}.
\section{Group Recommender System}
A group recommender system is a recommender system aimed at making recommendations for a group instead of a single user. To make recommendations group members preferences have to be aggregated. This can be done by either aggregating single user recommendations or by merging preferences of each user into a group preference model. Based on this model recommendation strategies as described in \autoref{sec:Foundations:RecommenderSystem} can be used to generate recommendations \cite{jamesonRecommendationGroups2007}.
\section{Product Configuration}
\label{sec:Foundations:ProductConfiguration}
Product configuration is a process consisting of a series of decision tasks whereby a product is constructed of components which interact with each other. During a configuration process no new components are created. Their interplay and specification is defined beforehand \cite[~ pp. 42, 43]{sabinProductConfigurationFrameworksa1998}.
Formally a configuration problem can be specified as a \emph{constraint satisfaction problem (CSP)} \cite{tsangFoundationsConstraintSatisfaction1993} as
\[
CSP(V,D,C)
\]
where \( V = \{v_1,\dots, v_n\} \) is a set of variables, \( D = dom : V \mapsto X \) is a relation of variables and their corresponding domain definitions \( X \), and \( C = C_{PREF} \cup C_{KB} \) is a set of constraints with customer preferences \( C_{PREF} \) and configuration knowledge base \( C_{KB} \) \cite{felferningGroupBasedConfiguration2016, felfernigOpenConfiguration2014}.
\section{Group-Based Product Configuration}
\label{sec:Foundations:GroupBasedProductConfiguration}
If instead of a single person configuring a product we would like to have a group of people which can be useful in multi-stakeholder decisions, it needs mechanisms for describing the preferences of multiple people. Therefore we extend the definition of product configuration from (\autoref{sec:Foundations:ProductConfiguration}) to
\[
C_{PREF} = \bigcup
PREF_i \]
with preferences of user \( i \) as \( PREF_i \) \cite{ felferningGroupBasedConfiguration2016}.
\section{Group-Based Configuration-Solution}
\label{sec:Foundations:GroupBasedConfigurationSolution}
\autoref{sec:Foundations:ProductConfiguration} and \autoref{sec:Foundations:GroupBasedProductConfiguration} expand to a solution of a group-based configuration with the addition of variable assignments
\[
C_{CONF} = \bigcup_{v_i \in V} \{ v_i = x_i \}, \ x_i \in dom(v_i)
\]
and where \( C_{CONF} \cup C_{PREF} \cup C_{KB} \) is consistent \cite{ felferningGroupBasedConfiguration2016}.
\section{Group Bias}
\label{sec:Foundations:GroupBias}
Groups have biases same as individuals. Some of these stem from individual biases that are transferred to a group and others only occur in group settings. This section covers some of those effects. These effects are described by \citeauthor{felfernigBiasesGroupDecisions2018} \cite{felfernigBiasesGroupDecisions2018}.
\subsection{GroupThink}
The bias called GroupThink occurs, when group members prefer to avoid conflicts instead of being mainly interested in getting the best decision outcome. Alternative options are in these circumstances not analysed close enough \cite{janis1982groupthink}.
An avoidance strategy for this effect is for leaders to delay stating there opinion until all alternatives have been viewed in detail \citeauthor{felfernigBiasesGroupDecisions2018}. Recommender systems can aid group decision quality through encouraged information exchange as discussed by \citeauthor{atasItemRecommendationUsing2017} in \cite{atasItemRecommendationUsing2017}.
\subsection{Anchoring}
The first information provided is relied upon to heavily. In a group setting this can be triggered by the group member to first express their opinion. Often this is triggered if group members see preferences of others too early, therefore recommender systems should not show the rating of other users \cite{cosley2003seeing}.
\subsection{Serial Position Effects}
The serial positioning effects is the effect that users have a higher retention rate of items in a list that are presented first or last and these items are more closely examined \cite{felfernigPersuasiveRecommendationSerial2007,murphyPrimacyRecencyEffects2006}. Additionally to remembering and examining items at the start and the end of a list also the order of items can change the option the user chooses in the end \cite{felfernigBiasesGroupDecisions2018}.

47
20_Proposal/sections/20_related_work.tex Normal file
View File

@@ -0,0 +1,47 @@
\chapter{Related Work}
\label{ch:Related_Work}
\section{Group Recommender Systems}
\label{sec:Related_Work:GroupRecommender}
\begin{description}[style=unboxed, leftmargin=0cm, font=\normalfont]
\item[\citeauthor{choudharyMulticriteriaGroupRecommender2020}] propose a multi-criteria group recommender system. An analytical hierarchy process is used to learn priorities for film features like story, action, direction and to then make a number of best recommendations for a group of users. Their approach works well for film selection and they observe that it is easier to make recommendations for homogenous groups than for random groups. Also small groups receive better recommendations compared to large ones\cite{choudharyMulticriteriaGroupRecommender2020}.
\item[\citeauthor{chenInterfaceInteractionDesign2011}] looks at interface and interaction designs that supports the overall group and does not only consider each user individually. Chen design a music recommendation system \emph{GroupFun} with a focus on groups that tries to enhance mutual awareness and transparency. \citeauthor{chenInterfaceInteractionDesign2011}'s assessment is that this work is still in a preliminary stage \cite{chenInterfaceInteractionDesign2011}. Further work in that area was conducted by \citeauthor{chenEmpatheticonsDesigningEmotion2014} looking at emotional awareness in groups and how that can be visualised in a user interface \cite{chenEmpatheticonsDesigningEmotion2014}.
\end{description}
\section{Group-Based Configuration}
\label{sec:Related_Work:GroupBasedConfiguration}
\begin{description}[style=unboxed, leftmargin=0cm, font=\normalfont]
\item[\citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019}] builds a collaborative configurator based on the CAS Merlin Configurator. Here groups of people are able to simultaneously configure a product. If there are any conflicts a conflict resolution process is started. However the prototype only allows a majority voting approach and does not provide any group decision support \cite{raabKollaborativeProduktkonfigurationEchtzeit2019}.
\item[\citeauthor{felferningGroupBasedConfiguration2016}] introduces basic definitions of group based configuration tasks, shows what conflicts can occur, how to deal with inconsistencies in preferences among group members and how to integrate different decision heuristics into this process \cite{felferningGroupBasedConfiguration2016}.
\item[\citeauthor{velasquez-guevaraMultiSPLOTSupportingMultiuser2018}] implement a web based simultaneous group-based configuration system that uses constraint programming. Hereby each user configures according to their own preferences and the system proposes a configuration according to different strategies \cite{velasquez-guevaraMultiSPLOTSupportingMultiuser2018}.
\end{description}
\section{Recommender Systems for Configuration}
\label{sec:Related_Work:RecommenderSystemsForConfiguration}
\begin{description}[style=unboxed, leftmargin=0cm, font=\normalfont]
\item[\citeauthor{rubinshteynEntwicklungHybridenRecommender2018}] looks at different approaches to recommendation and implements a prototype with CAS Merlin Configurator which uses a hybrid recommender system. His prototype combines constraint-based filtering with collaborative filtering \cite{rubinshteynEntwicklungHybridenRecommender2018}.
\item [\citeauthor{benzMoeglichkeitenIntelligenterEmpfehlungssysteme2017}] uses a constraint based recommender that uses fuzzy logic to relax constraints and thereby reducing the amount of times where the recommender is unable to make recommendations. With his approach a product manager has direct influence on the recommendations. Rules for recommendations hereby are not automatically learned but only manually created and relate to predefined user interest categories \cite{benzMoeglichkeitenIntelligenterEmpfehlungssysteme2017}.
\item [\citeauthor{ullmannEntwurfUndUmsetzung2017}] implements a recommendation engine that is able to estimate customer budgets, a k-nearest neighbour classifier for finding a base configuration and non-negative matrix factorization combines with nearest neighbour to find configurations for specific users \cite{ullmannEntwurfUndUmsetzung2017}. \par
\item[\citeauthor{wetzelPersonalisierterUndLernender2017}] combines collaborative filtering and click-stream analysis. For collaborative filtering he implements three filtering algorithms: k-nearest neighbour, weighted majority voting and non-negative matrix factorization. Collaborative filtering is used to find configurations that are similar to the current configuration. Click-stream analysis is done by using n-grams and the Smith-Waterman algorithm. \citeauthor{wetzelPersonalisierterUndLernender2017} also tries to use click-stream data in combination with Markov chains to give recommendations on how configuration options should be ordered in a configuration form \cite{wetzelPersonalisierterUndLernender2017}.
\item[\citeauthor{falknerRecommendationTechnologiesConfigurable2011}] provide an overview of recommendation approaches for configuration to improve usability of configuration systems. They look at feature recommender to recommend which features in a configuration would be useful to have and at value recommender for these features. Additionally they discuss approaches for ranking and recommending explanations for inconsistencies between customers requirements and product rules \cite{falknerRecommendationTechnologiesConfigurable2011}.
\end{description}
\section{Group Dynamics and Bias}
\label{sec:Related_Work:GroupDynamicsAndBias}
\begin{description}[style=unboxed, leftmargin=0cm, font=\normalfont]
\item[\citeauthor{charnessGroupsMakeBetter2012}] study group decision-making in the context of classical game-theoretic games. They find that groups act more rational in these contexts but also note that this can lead to decisions that sacrifice social welfare towards individual gain. They also note that diversity increases effectiveness of the group if the environment is of participatory nature in an environment that allows expression of diverse ideas \cite{charnessGroupsMakeBetter2012}.
\item[\citeauthor{bonnerEffectsMemberExpertise2002}] study the effects of expertise on group decision-making and performance. The look at an easy and a moderately difficult version of the game Mastermind. The results show that provided performance ratings for each group members helped groups use that expertise as group members gave more weight to high performing member's opinions. This effect was only visible when looking at the moderately difficult task. Using experts in groups caused them to perform significantly better than individuals. In their conclusion \citeauthor{bonnerEffectsMemberExpertise2002} note that expertise should be taken into account when modelling group decision-making \cite{bonnerEffectsMemberExpertise2002}.
\item[\citeauthor{atasItemRecommendationUsing2017}] look at how the diversity of recommendations in a group decision scenario effects information exchange among group members. In the conducted study participants chose exam topics in a group. They had support by a system that aids group decisions. A noticeable result was that increased recommendation diversity lead to greater information exchange in groups \cite{atasItemRecommendationUsing2017}.
\item[\citeauthor{felfernigBiasesGroupDecisions2018}] give an overview over biases that occur in groups. Additionally they provide some measures to reduce these biases. The presented biases range from biases that are also prevalent in individuals to biases that only effect groups \cite{felfernigBiasesGroupDecisions2018}.
\end{description}

54
20_Proposal/sections/30_concept.tex Normal file
View File

@@ -0,0 +1,54 @@
\chapter{Concept}
\label{ch:Concept}
\section{CAS Configurator Merlin}
\label{sec:Concept:ConfiguratorMerlin}
\autoref{fig:Concept:ConfiguratorMerlin} shows the architecture of CAS Configurator Merlin.
\begin{description}
\item[M.Core] provides the base of the configurator it checks configuration against all rules in the database, provides possible alternatives on a change that invalidates other parts of a configuration.
\item[M.Model] is the editor to create products and rules. These rules can then be uploaded to M.Core.
\item[M.Customer] is the customer facing component. It allows a customer to configure a product.
\end{description}
\begin{figure}
\centering
\includegraphics{./figures/MerlinConfigurator.pdf}
\caption{Architecture of Configurator Merlin \cite[Fig. 4.1]{raabKollaborativeProduktkonfigurationEchtzeit2019}}
\label{fig:Concept:ConfiguratorMerlin}
\end{figure}
\section{CAS Group-Configurator}
\label{sec:Concept:GroupConfigurator}
\citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} extends CAS Merlin Configurator in his thesis to allow simultaneous configuration. The extended architecture is shown in \autoref{fig:Concept:CollaborativeConfiguratorMerlin}.
He only makes changes to M.Customer which is renamed to M.Collab-Customer and introduces a new component M.Collab.
\begin{description}
\item[M.Collab] is a node.js server application that communicates with M.Core via REST-API and with M.Collab-Customer via WebSocket. It sits in between M.Collab-Customer and M.Core and handles all processing regarding collaborative configuration.
\item[M.Collab-Customer] a modified version of M.Customer that does all communication via WebSocket and does communicate with M.Collab instead of M.Core.
\end{description}
\begin{figure}
\centering
\includegraphics{./figures/MerlinCollaborativeConfigurator.pdf}
\caption{Architecture of Collaborative Configurator Merlin \cite[Fig. 4.3]{raabKollaborativeProduktkonfigurationEchtzeit2019}}
\label{fig:Concept:CollaborativeConfiguratorMerlin}
\end{figure}
\section{Extended Configurator}
\label{sec:Concept:ExtendedConfigurator}
Extending \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} work a module called M.Recommender is added. Its aim is to provide a recommendation server that holds all the data needed for recommendations. M.Collab and M.Collab-Customer have to be modified to allow taking in preferences and to show recommendations. The recommender engine is set up to be in a separate system which allows the easier replacement and the usage of different technologies. The extended architecture is shown in \autoref{fig:Concept:RecommenderForCollaborativeConfiguratorMerlin}.
\begin{description}
\item[M.Recommender] is a new system that will get queried from M.Collab for recommendations, when the configuration changes. M.Recommender will return recommendations which then can be presented to users by M.Collab-Customer.
\end{description}
\begin{figure}
\centering
\includegraphics{./figures/MerlinCollabRecommender.pdf}
\caption{Architecture of Collaborative Configurator Merlin with an added recommender system.}
\label{fig:Concept:RecommenderForCollaborativeConfiguratorMerlin}
\end{figure}

158
20_Proposal/sections/40_organisation.tex Normal file
View File

@@ -0,0 +1,158 @@
\chapter{Organisation}
\label{ch:Organisation}
This chapter provides an overview on time schedule, advisers and other organisational circumstances regarding this thesis.
\section{Advisers and Environment}
\label{sec:Organisation:AdvisersAndEnvironment}
The thesis is written in cooperation \emph{CAS Software AG}. A company located in Karlsruhe, Germany and founded in 1986. It is a market leader in Customer Relationship Management software for small and medium sized enterprises. Over 20,000 organisations and 400,000 people use software from \emph{CAS Software AG} \cite{CASSoftwareAG}. Among the offered products is also \emph{CAS Configurator Merlin} which this thesis builds upon. This thesis will be advised by Robert Heinrich from \emph{Institute for Program Structures and Data Organization} and Jonas Fegert from \emph{FZI Forschungszentrum Informatik}. Additional advisership is given by employees of \emph{CAS Future Labs}.
\section{Artefacts}
\label{sec:Organisation:Artefacts}
This thesis consist of multiple artefacts. Artefacts do not have to be separate documents but can be included in other documents. Those are:
\begin{itemize}
\item Proposal (this document)
\item Proposal presentation
\item Bachelor's thesis
\item Bachelor's thesis presentation
\item Development Related Artefacts
\begin{itemize}
\item Design documentation
\item Source code documentation
\item Source code
\item One or multiple sample configurations
\item A working Prototype
\end{itemize}
\item Evaluation data
\end{itemize}
\section{Process}
\label{sec:Organisation:Process}
A slightly reduced version of Scrum is used during the creation of this thesis. Scrum is the de-facto standard for agile software development \cite{glogerScrumPradigmenwechselIm2010}. Daily meetings with status updates and suggestions with advisory and colleagues at CAS are held every day. The Sprint length is one week but during later development this potentially will be lengthened to two weeks. Sprint reviews, retrospective and sprint planning are not explicitly done. Hereby the process is not used for coordination of a team that works on a single software project but to improve knowledge exchange and communication.
\section{Schedule}
\label{sec:Organisation:Schedule}
The planned schedule can be seen in \autoref{fig:Organisation:Schedule:Gant}. Documentation and of the thesis is planned to be written in parallel to \emph{Problem Identification}, \emph{Design and Implementation} and \emph{Demonstration and Evaluation} phases. The Design and Implementation Phase is grouped into iterations. Each iteration will consist of implementing one work package, described in \autoref{sec:Organisation:WorkPackages} and after each iteration the corresponding milestones are reached. These are not explicitly described in \autoref{fig:Organisation:Schedule:Gant}. After all these phases the thesis documentation will be finalized and corrected.
\begin{figure}
\begin{center}
\begin{ganttchart}[y unit title=0.7cm,
y unit chart=0.7cm,
x unit=0.25cm,
title height=1,
bar height=0.6,
group right shift=0,
group top shift=.6,
group height=.3
]{1}{36}
\gantttitle{2019}{4}
\gantttitle{2020}{32}\ganttnewline
\gantttitlelist{51,52,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}{2}\ganttnewline
\ganttgroup{Thesis}{1}{36}\ganttnewline
\ganttgroup{Problem Identification}{1}{6}\ganttnewline
\ganttbar{Literature Research}{1}{4}\ganttnewline
\ganttbar{Defintion of Objectives}{1}{6}\ganttnewline
\ganttgroup{Design and Implementation}{7}{22}\ganttnewline
\ganttgroup{Work Package 1}{7}{10}\ganttnewline
\ganttbar{Design}{7}{8}\ganttnewline
\ganttbar{Implementation}{8}{10}\ganttnewline
\ganttgroup{Work Package 2}{11}{14}\ganttnewline
\ganttbar{Design}{11}{12}\ganttnewline
\ganttbar{Implementation}{12}{14}\ganttnewline
\ganttmilestone{Code Review}{14}\ganttnewline
\ganttgroup{Work Package 3}{15}{18}\ganttnewline
\ganttbar{Design}{15}{16}\ganttnewline
\ganttbar{Implementation}{16}{18}\ganttnewline
\ganttmilestone{Fully Working Prototype}{18}\ganttnewline
\ganttbar{Buffer}{19}{22}\ganttnewline
\ganttgroup{Demonstration and Evaluation}{23}{26}\ganttnewline
\ganttbar{Demonstration}{23}{24}\ganttnewline
\ganttbar{Evaluation}{25}{26}\ganttnewline
\ganttgroup{Documentation}{1}{34}\ganttnewline
\ganttbar{Write Documentation}{1}{26}\ganttnewline
\ganttmilestone{First Draft}{26}\ganttnewline
\ganttbar{Finalize Thesis}{28}{30}\ganttnewline
\ganttmilestone{Final Draft}{30}\ganttnewline
\ganttbar{Proof Reading and Corrections}{31}{34}\ganttnewline
\ganttmilestone{Finished Thesis}{34}\ganttnewline
\ganttbar{Buffer}{35}{36}\ganttnewline
\ganttmilestone{Thesis Submission (\printfdate{british})}{36}
\ganttvrule{}{6}
\ganttvrule{}{22}
\ganttvrule{}{26}
\ganttvrule{}{34}
\end{ganttchart}
\end{center}
\caption{Gantt chart representing the schedule of this thesis.
}
\label{fig:Organisation:Schedule:Gant}
\end{figure}
\section{Work Packages}
\label{sec:Organisation:WorkPackages}
\begin{enumerate}[label=Work Package \arabic*:, align=left]
\item Basic Preference Aggregation and Voting Recommendation
\begin{description}
\item[Preference Aggregation] The system needs to have a user interface for collecting preferences and to be able to process them.
\item[Voting Recommender UI] A basic user interface that displays recommendations for voting which were returned by the recommender.
\item[REST-Api for Voting Recommendations] Define a rest api that gives recommendations for configurations and user preferences.
\item[Voting Recommender] Implementation of the actual recommender for voting.
\item[Milestone M1] The collaborative configuration prototype can aggregate preferences and gives recommendations for voting.
\end{description}
\pagebreak[3]
\item Recommender for Configuration Attributes
\begin{description}
\item[Attribute Recommendation UI] There
\item[REST-Api for Attribute Recommendations]
\item[Attribute Recommender] The voting recommender extended to allow recommendations for attributes.
\item[Milestone M2] The collaborative configuration prototype can give suggestions for Attributes that should be build into the configuration.
\end{description}
\pagebreak[3]
\item Hybridisation of Recommender
\begin{description}
\item[Other recommender types] Implement other recommender types.
\item[Milestone M3] The collaborative configuration prototype can give recommendations by combining multiple recommender.
\end{description}
\pagebreak[3]
\end{enumerate}
\section{Risks Assessment}
\label{sec:Organisation:RiskAssessment}
\begin{enumerate}[label=Risk \arabic*:, align=left, leftmargin=*]
\item Underestimation of effort for \emph{Design and Implementation} phase
\begin{description}
\item[Explanation:] Tasks might take more effort then expected and therefore cannot be completed in the planned time. This is especially problematic for the \emph{Design and Implementation} phase as the \emph{Demonstration and Evaluation} phase requires a working prototype.
\item[Mitigation:] There are planned explicit buffers. One for the \emph{Design and Implementation} phase and one general buffer. This amounts to two weeks of buffer. Additionally it is possible to shorten \emph{Finalize Thesis} and \emph{Proof Reading and Corrections} phases as the time planned for these phases is overestimated. Overall in a worst-case scenario it is possible to extend \emph{Design and Implementation} by up to four weeks.
\end{description}
\pagebreak[3]
\item Delay due to unforeseen circumstances outside of the author's control
\begin{description}
\item[Explanation:] Outside influence could delay the thesis. An example of that is sickness.
\item[Mitigation:] According to "Prüfungsordnung" §14.6 it is possible to extend the period of the thesis of up to a month \cite[~ p. 724]{StudienUndPrufungsordnung2015}.
\end{description}
\pagebreak[3]
\item Bugs and architectural problems in prototype
\begin{description}
\item[Explanation:] Bugs in the prototype that this thesis will extend could delay implementation of features. Also architectural problems could make it harder then expected to extend the prototype.
\item[Mitigation:] To reduce work in such a case less features could be implemented or some features could just use a mock implementation.
\end{description}
\pagebreak[3]
\end{enumerate}