Compare commits
12 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| c550a7ff89 | |||
| 0e5b9250c2 | |||
| 1bd15a2408 | |||
| 8d96f69ef2 | |||
| cfe8cb6da4 | |||
| d92b963da2 | |||
| b3b44786a7 | |||
| e9a8077d6f | |||
| b86686e5b3 | |||
| fd315c0078 | |||
| 85457ce8af | |||
| f3d9b07143 |
@ -1,38 +1,33 @@
|
||||
@article{einstein,
|
||||
author = "Albert Einstein",
|
||||
title = "{Zur Elektrodynamik bewegter K{\"o}rper}. ({German})
|
||||
[{On} the electrodynamics of moving bodies]",
|
||||
journal = "Annalen der Physik",
|
||||
volume = "322",
|
||||
number = "10",
|
||||
pages = "891--921",
|
||||
year = "1905",
|
||||
DOI = "http://dx.doi.org/10.1002/andp.19053221004",
|
||||
keywords = "physics"
|
||||
@article{hevner2004dsr,
|
||||
Abstract = {Two paradigms characterize much of the research in the Information Systems discipline: behavioral science and design science. The behavioral science paradigm seeks to develop and verify theories that explain or predict human or organizational capabilities by creating new and innovative artifacts. Both paradigms are foundational to the IS discipline, positioned as it is at the confluence of people, organizations, and technology. Our objective is to describe the performance of design-science research in Information Systems via a concise conceptual framework and clear guidelines for understanding, executing, and evaluating the research. In the design-science paradigm, knowledge and understanding of a problem domain and its solution are achieved in the building and application of the designed artifact. Three recent exemplars in the research literature are used to demonstrate the application of these guidelines. We conclude with an analysis of the challenges of performing high-quality desi},
|
||||
Author = {Hevner, Alan R. and March, Salvatore T. and Park, Jinsoo and Ram, Sudha},
|
||||
ISSN = {02767783},
|
||||
Journal = {MIS Quarterly},
|
||||
Keywords = {Information science, Information resources, Organizational behavior, RESEARCH, Database searching, Industrial efficiency, Standard operating procedure, Psychology, Work environment, Research methodology, Information technology research, business environment, creativity, design artifact, design science, experimental methods, Information Systems research methodologies, search strategies, technology infrastructure},
|
||||
Number = {1},
|
||||
Pages = {75 - 105},
|
||||
Title = {DESIGN SCIENCE IN INFORMATION SYSTEMS RESEARCH.},
|
||||
Volume = {28},
|
||||
URL = {https://zuyd.idm.oclc.org/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=12581935&lang=nl&site=eds-live},
|
||||
Year = {2004},
|
||||
}
|
||||
|
||||
@book{dirac,
|
||||
title={The Principles of Quantum Mechanics},
|
||||
author={Paul Adrien Maurice Dirac},
|
||||
isbn={9780198520115},
|
||||
series={International series of monographs on physics},
|
||||
year={1981},
|
||||
publisher={Clarendon Press},
|
||||
keywords = {physics}
|
||||
@article{hevner2007three,
|
||||
title = {A three cycle view of design science research},
|
||||
author = {Hevner, Alan R},
|
||||
journal = {Scandinavian journal of information systems},
|
||||
volume = {19},
|
||||
number = {2},
|
||||
pages = {4},
|
||||
year = {2007}
|
||||
}
|
||||
|
||||
@online{knuthwebsite,
|
||||
author = "Donald Knuth",
|
||||
title = "Knuth: Computers and Typesetting",
|
||||
url = "http://www-cs-faculty.stanford.edu/~uno/abcde.html",
|
||||
keywords = "latex,knuth"
|
||||
@misc{beck2001agile,
|
||||
author = {Beck, Kent and Beedle, Mike and van Bennekum, Arie and Cockburn, Alistair and Cunningham, Ward and Fowler, Martin and Grenning, James and Highsmith, Jim and Hunt, Andrew and Jeffries, Ron and Kern, Jon and Marick, Brian and Martin, Robert C. and Mellor, Steve and Schwaber, Ken and Sutherland, Jeff and Thomas, Dave},
|
||||
booktitle = {Manifesto for Agile Software Development},
|
||||
description = {Manifesto for Agile Software Development},
|
||||
title = {Manifesto for Agile Software Development},
|
||||
url = {http://www.agilemanifesto.org/},
|
||||
year = 2001
|
||||
}
|
||||
|
||||
@inbook{knuth-fa,
|
||||
author = "Donald E. Knuth",
|
||||
title = "Fundamental Algorithms",
|
||||
publisher = "Addison-Wesley",
|
||||
year = "1973",
|
||||
chapter = "1.2",
|
||||
keywords = "knuth,programming"
|
||||
}
|
||||
@ -1 +1,56 @@
|
||||
\chapter{Achtergrond}
|
||||
|
||||
|
||||
Het project wordt uitgevoerd in het Expert Team Networking ('ETN') van KEMBIT. Dit team is verantwoordelijk voor het ontwerpen en beheren van netwerken voor diverse klanten. ETN beheerd onder andere klein-, middel-, en grote bedrijfsnetwerken, campusterreinen en cloudnetwerken. Onderling verschillen deze sterk in grootte en complexiteit.
|
||||
|
||||
KEMBIT bestaat uit circa 125 medewerkers verspreid over gespecialiseerde teams (waaronder ETN). Zie afbeelding \ref{fig:organogram} voor de structuur van de organisatie.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\begin{tikzpicture}
|
||||
% \draw[step=1.5,gray,very thin] (0,0) grid (15,10);
|
||||
|
||||
\node[draw,align=center](ms) at (7.5,9) {Manager Services};
|
||||
|
||||
\node[draw,align=center](tm) at (4,7) {Technisch Manager};
|
||||
|
||||
\node[draw,align=center](pk) at (4,5) {Process en Kwaliteit};
|
||||
|
||||
|
||||
|
||||
\node[draw,align=center](mcs) at (12,7) {Manager Commercïele\\Services};
|
||||
|
||||
\node[draw,align=center](sm) at (12,5.75) {Service Manager};
|
||||
|
||||
\node[draw,align=center](dm) at (10,4.5) {Delivery\\Management};
|
||||
\node[draw,align=center](smt) at (14,4.5) {Service\\Management};
|
||||
|
||||
\node[draw,align=center](om) at (7.5,3) {Operationeel\\Manager};
|
||||
|
||||
\node[draw,align=center](om) at (7.5,3) {Operationeel\\Manager};
|
||||
|
||||
\node[draw,align=center](ets) at (0,1) {Expertteam\\Security};
|
||||
\node[draw,align=center](etn) at (3,1) {Expertteam\\Netwerkbeheer};
|
||||
\node[draw=purple,thick,align=center](eti) at (6,1) {Expertteam\\Infrastructuur};
|
||||
\node[draw,align=center](bt) at (9,1) {Beheerteam};
|
||||
\node[draw,align=center](msc) at (12,1) {Managed Services\\Center};
|
||||
\node[draw,align=center](mc) at (15.25,1) {Monitoring \&\\Control};
|
||||
|
||||
\draw (om) -- (ms);
|
||||
\draw (mcs) -- (7.5,7);
|
||||
\draw (mcs) -- (sm);
|
||||
\draw (sm) -| (dm);
|
||||
\draw (sm) -| (smt);
|
||||
\draw (tm) -- (7.5,7);
|
||||
\draw (pk) -- (7.5,5);
|
||||
|
||||
\draw (om) -| (ets);
|
||||
\draw (om) -| (etn);
|
||||
\draw (om) -| (eti);
|
||||
\draw (om) -| (bt);
|
||||
\draw (om) -| (msc);
|
||||
\draw (om) -| (mc);
|
||||
\end{tikzpicture}
|
||||
\caption{Organogram KEMBIT Services \textit{(afdeling waar het project word uitgevoerd aangegeven met paars)}}
|
||||
\label{fig:organogram}
|
||||
\end{figure}
|
||||
@ -14,13 +14,35 @@ Het netwerkteam van KEMBIT heeft vastgesteld dat sommige onderhoudsprocessen zee
|
||||
\begin{enumerate}
|
||||
\item Welke netwerk gerelateerde werkzaamheden verricht KEMBIT?
|
||||
\item Welke netwerk gerelateerde werkzaamheden zijn het meest tijdrovend?
|
||||
\item Waarom zijn deze werkzaamheden tijdrovend?
|
||||
\item Welke mogelijkheden/oplossingen kunnen worden toegepast om het netwerkbeheer efficiënter te maken?
|
||||
\item Wat zijn de belangen en eisen van de stakeholders aan de (geautomatiseerde) uitvoering van de werkzaamheden?
|
||||
\item Hoe past automatisering in de bedrijfsvoering van het networking team?
|
||||
\item Hoe kunnen deze werkzaamheden geautomatiseerd worden?
|
||||
\item Hoe kunnen de vastgestelde mogelijkheden/oplossingen het best ingezet worden, rekening houdend met de wensen/eisen van KEMBIT?
|
||||
\end{enumerate}
|
||||
|
||||
\section{Doelstelling}
|
||||
De primaire doelstelling van het project is om de opdrachtgever te adviseren in mogelijke oplossingen en/of vervolgstappen met betrekking tot de hoofd- en/of deelvragen.
|
||||
De primaire doelstelling van het project is om de opdrachtgever te adviseren in mogelijke oplossingen en/of vervolgstappen met betrekking tot het efficiënter maken van werkzaamheden door automatisering.
|
||||
|
||||
\section{Producten}
|
||||
|
||||
Het resultaat van het project bevat meerdere producten. Deze producten worden in dit hoofdstuk beschreven.
|
||||
|
||||
\subsection*{Tussenresultaten}
|
||||
|
||||
Tussenresultaten worden gemaakt om het project zelf beschrijven (bijvoorbeeld het plan van aanpak) of dienen als fundering voor de eindresultaten (bijvoorbeeld het onderzoeksrapport voor het extended abstract).
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Prestatieplan} \\ Dit document beschrijft de prestatie-indicatoren waarop de student beoordeeld wordt.
|
||||
\item \textbf{Plan van Aanpak} \\ Het plan van aanpak documenteert de doelstelling, methodes en stakeholders die relevant zijn om het project in een gestructureerde manier uit te voeren.
|
||||
\item \textbf{Onderzoeksrapport} \\ Dit document beschrijft de toegepaste onderzoeksmethodes en resultaten om de vraag- en/of probleemstelling van de opdrachtgever te beantwoorden.
|
||||
\end{enumerate}
|
||||
|
||||
\subsection*{Eindresultaten}
|
||||
|
||||
Eindresultaten zijn resultaten waarmee hoofd- en deelvragen worden beantwoord.
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Ontwerp} \\ Een document waarin een technische oplossing wordt beschreven voor het oplossen van de opdrachtgevers probleem- en/of vraagstelling. Wordt gebaseerd op het onderzoek.
|
||||
\item \textbf{Advies} \\ Beschrijft vervolgstappen die de opdrachtgever kan ondernemen met als uiteindelijke doelstelling om het probleem en/of vraag op te lossen.
|
||||
\item \textbf{Extended Abstract} \\ Hierin wordt de uitvoer en de resultaten van het gehele project samengevat in een redelijk beknopt document.
|
||||
\end{enumerate}
|
||||
@ -1 +1,80 @@
|
||||
\chapter{Projectactiviteiten}
|
||||
|
||||
|
||||
\section{Onderzoeksaanpak}
|
||||
|
||||
Dit hoofdstuk beschrijft de methodes die worden toegepast om elke deelvraag te beantwoorden met een korte toelichting.
|
||||
|
||||
\begin{table}[h]
|
||||
\caption{Onderzoeksaanpak}
|
||||
\label{tbl:onderzoeksaanpak}
|
||||
\begin{tabular}{ p{0.15\linewidth} p{0.2\linewidth} p{0.55\linewidth} }
|
||||
\toprule
|
||||
\textbf{Onderzoek-vraag} & \textbf{Methode} & \textbf{Toelichting}\\
|
||||
\midrule
|
||||
|
||||
\multirow{2}{*}{1} &
|
||||
Interview &
|
||||
Er worden interviews gehouden met betrokkenen om inzichten te krijgen in welke werkzaamheden zij uitvoeren. \\
|
||||
|
||||
\cmidrule{2-3}
|
||||
|
||||
&
|
||||
Data Analytics &
|
||||
Er worden analyses gemaakt van de gegevens in het IT-servicemanagement Systeem om inzichten te krijgen in de soorten activiteiten. \\
|
||||
|
||||
\hline
|
||||
|
||||
\multirow{2}{*}{2} &
|
||||
Interview &
|
||||
Er wordt een interview uitgevoerd met de teamleider van het Expert Team Networking om inzichten te krijgen in welke activiteiten als het meest tijdrovend worden beschouwd. \\
|
||||
|
||||
\cmidrule{2-3}
|
||||
|
||||
&
|
||||
Data Analytics &
|
||||
Er zal een analyse worden gemaakt van de tijdsbesteding aan bepaalde activiteiten uit het IT-servicemanagement systeem. \\
|
||||
|
||||
\hline
|
||||
|
||||
\multirow{2}{*}{3} &
|
||||
Root Cause Analysis &
|
||||
Er wordt een Root Cause Analysis toegepast om vast te stellen waar in het proces de meeste tijd wordt besteed.\\
|
||||
|
||||
\cmidrule{2-3}
|
||||
|
||||
&
|
||||
Literatuurstudie &
|
||||
Bestaande oplossingen en geassocieerde eigenschappen worden in kaart gebracht. \\
|
||||
|
||||
|
||||
|
||||
\hline
|
||||
|
||||
\multirow{2}{*}{4 \& 5} &
|
||||
Survey &
|
||||
Er wordt een enquête gemaakt en afgenomen binnen het Expert Team Networking om een beeld te krijgen van de wensen en eisen van de werknemers \\
|
||||
|
||||
\cmidrule{2-3}
|
||||
|
||||
&
|
||||
Interview &
|
||||
Er wordt een interview gehouden met de teamleider van het Expert Team Networking om wensen en eisen te verkrijgen \\
|
||||
|
||||
\hline
|
||||
|
||||
\multirow{2}{*}{6} &
|
||||
Design &
|
||||
Er wordt een oplossing ontworpen op basis van de wensen, eisen en situatie van het Expert Team Networking. \\
|
||||
|
||||
\cmidrule{2-3}
|
||||
|
||||
&
|
||||
Proof of Concept&
|
||||
Er wordt op iteratieve wijze een oplossing gerealiseerd waarmee de werkzaamheden efficiënter kunnen worden uitgevoerd. \\
|
||||
|
||||
|
||||
\bottomrule
|
||||
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
@ -1,3 +1,114 @@
|
||||
\chapter{Kwaliteit}
|
||||
|
||||
Om de kwaliteit van de producten en de uitvoering te handhaven worden projectmethodes gebruikt en worden kwaliteitseisen gesteld aan de projectresultaten. Deze methodes en kwaliteitseisen zullen in dit hoofdstuk behandeld worden.
|
||||
|
||||
\section{Projectuitvoering}
|
||||
|
||||
Om de kwaliteit aan de projectuitvoering te handhaven zullen bepaalde methodes worden gebruikt. Deze worden in dit hoofdstuk beschreven.
|
||||
|
||||
\subsection{Hevner Design Science Research}
|
||||
|
||||
Design Science research (afgekort \textit{'DSR'}) is een framework waarmee iteratief onderzoek kan worden uitgevoerd met als doel om een nieuwe dienst of product te creëren \cite{hevner2004dsr}. De doelstelling van het gebruiken van deze methode is een basis werkstructuur aan te houden die de combinatie tussen onderzoek en het produceren van producten en/of diensten benadrukt. Hierdoor wordt de uiteindelijke kwaliteit van het artifact verhoogd.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics{figures/hevner-dsr-cycle.pdf}
|
||||
\caption{Design Science Research Cycles \cite{hevner2007three}}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{The Relevance Cycle}
|
||||
|
||||
De Relevance Cycle zet design research in gang met de omgeving van het probleem en/of vraagstelling. Deze omgeving geeft niet alleen requirements als input aan het project, maar ook acceptatie criteria voor de uiteindelijke resultaten. De output van de Relevance Cycle (artifacts) worden weer terug in deze omgeving geëvalueerd. Uit het resultaat van deze Cyclus moet blijken hoeveel verdere iteraties nodig zijn. Middels deze cyclus wordt gerarandeerd dat het geproduceerde artifact past bij de omgeving (probleemstelling/requirements).
|
||||
|
||||
\subsubsection*{The Rigor Cycle}
|
||||
|
||||
In de Rigor Cycle wordt informatie van een uitgebreid kennisnetwerk verzameld om te garanderen dat het project innovatief is (in tegenstelling tot routine). Deze informatie kan bestaan uit:
|
||||
|
||||
\begin{itemize}
|
||||
\item Reeds uitgevoerd onderzoek
|
||||
\item Ervaringen en expertise die de 'state of the art' definiëren in het toepassingsdomein van het onderzoek.
|
||||
\end{itemize}
|
||||
|
||||
Deze cyclus zorgt ervoor dat kennis, afkomstig van buiten het project, kan worden ingezet \textit{in} het project. Op deze manier wordt voorkomen dat gedurende het project het wiel opnieuw wordt uitgevonden
|
||||
|
||||
\subsubsection*{The Design Cycle}
|
||||
|
||||
De interne design cyclus is het hart van elk design science research project. Deze cyclus van onderzoeksactiviteiten itereert snel tussen het realiseren en evalueren van een artifact.
|
||||
|
||||
\subsection{Agile}
|
||||
|
||||
Agile definieert een iteratieve aanpak voor het oplossen van problemen en/of realiseren van producten. Dit betekent dat er over het algemeen geen vaste volgorde wordt aangehouden met het afronden van taken en dat de resultaten van deze taken beschreven worden in meerdere verschillende documenten.
|
||||
|
||||
Naast een iteratieve aanpak definieert het Agile Manifesto 12 principes \cite{beck2001agile}. Van deze twaalf zullen voornamelijk de volgende worden gehanteerd (de overige zijn grotendeels niet van toepassing op dit project):
|
||||
|
||||
\begin{itemize}
|
||||
\item De hoogste prioriteit is het tevredenstellen van de opdrachtgever.
|
||||
\item Requirements kunnen veranderen zelfs laat in de ontwikkeling.
|
||||
\item Lever frequent nieuwe resultaten.
|
||||
\item Bouw projecten rond gemotiveerde individuen en voorzie deze van de omgeving en ondersteuning die ze nodig hebben, en vertrouw erop dat ze de klus klaren.
|
||||
\item Eenvoud is essentieel.
|
||||
\item Continue aandacht voor het verbeteren van het artifact.
|
||||
\end{itemize}
|
||||
|
||||
De doelstelling met het inzetten van een Agile werkhouding is het continu verbeteren van het artifact, de stakeholders tevreden houden en het projectteam tevreden houden. Dit complementeert de Design Science Research methode.
|
||||
|
||||
|
||||
\section{Projectresultaten}
|
||||
|
||||
Elk product heeft bepaalde eisen waaraan deze moet voldoen om succesvol te zijn. De eisen worden beschreven in tabel \ref{tbl:kwaliteitseisen_producten}.
|
||||
|
||||
\begin{table}[h]
|
||||
\label{tbl:kwaliteitseisen_producten}
|
||||
\caption{Kwaliteitseisen aan producten}
|
||||
\begin{tabular}{ m{0.2\linewidth} p{0.7\linewidth} }
|
||||
|
||||
\toprule
|
||||
\textbf{Product} & \textbf{Kwaliteitseisen} \\
|
||||
\midrule
|
||||
|
||||
Plan van Aanpak &
|
||||
\begin{enumerate}
|
||||
\item Beschrijft de probleemstelling en/of vraag die beantwoord dient te worden.
|
||||
\item Beschrijft de methode en aanpak om deze probleemstelling en/of vragen te beantwoorden.
|
||||
\item Beschrijft partijen welke invloed hebben op het project.
|
||||
\end{enumerate} \\
|
||||
|
||||
\hline
|
||||
|
||||
Onderzoeksrapport &
|
||||
\begin{enumerate}
|
||||
\item Conclusies zijn onderbouwd door verwijzingen naar bronnen.
|
||||
\item Beschrijft onderzoeksmethodes waarmee de onderzoeksvragen beantwoord worden.
|
||||
\item Beschrijft de uitvoer en resultaten van deze methodes.
|
||||
\item Beschrijft de conclusie inclusief het beantwoorden van de onderzoeksvragen.
|
||||
\item Stelt de resultaten ter discussie indien nodig.
|
||||
\end{enumerate} \\
|
||||
|
||||
\hline
|
||||
|
||||
Ontwerp &
|
||||
\begin{enumerate}
|
||||
\item Beschrijft een systeem welke kan worden ingezet om het probleem op te lossen.
|
||||
\item Ontwerpkeuzes zijn gebaseerd op onderzoek.
|
||||
\item Systeem voldoet aan de requirements.
|
||||
\end{enumerate} \\
|
||||
|
||||
\hline
|
||||
|
||||
Advies &
|
||||
\begin{enumerate}
|
||||
\item Identificeert concrete punten voor de opdrachtgever om actie op te ondernemen om de probleemstelling (gedeeltelijk) op te lossen en/of volledig te voorkomen.
|
||||
\item Adviezen zijn gebaseerd op artifacten van het project.
|
||||
\end{enumerate} \\
|
||||
|
||||
\hline
|
||||
|
||||
Extended Abstract &
|
||||
\begin{enumerate}
|
||||
\item Er word geen nieuwe informatie behandeld en is (dus) volledig gebaseerd op de andere producten van het project.
|
||||
\end{enumerate} \\
|
||||
|
||||
\bottomrule
|
||||
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
@ -1,5 +1,122 @@
|
||||
\chapter{Organisatie}
|
||||
|
||||
\section{Projectleden}
|
||||
\section{Stakeholder analyse}
|
||||
|
||||
\section{Stakeholders}
|
||||
Om een beeld te krijgen van alle partijen welke betrokken zijn in het project worden deze in dit hoofdstuk gedocumenteerd en wordt vastgesteld wat de belangen/eisen deze hebben. De stakeholders zijn te zien in \ref{tbl:stakeholders}
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\caption{Stakeholders}
|
||||
\label{tbl:stakeholders}
|
||||
\begin{tabular}{@{} p{0.2\linewidth} p{0.2\linewidth} p{0.2\linewidth} p{0.3\linewidth} @{}}
|
||||
\toprule
|
||||
\textbf{Stakeholder} & \textbf{Vertegenwoordiger} & \textbf{Functie} & \textbf{Belang} \\
|
||||
\midrule
|
||||
|
||||
Martijn Remmen &
|
||||
- &
|
||||
studentstagiaire &
|
||||
Succesvol afronden van de afstudeerstage \\
|
||||
|
||||
\hline
|
||||
|
||||
Patrick Kuepers &
|
||||
KEMBIT Services &
|
||||
Bedrijfsbegeleider, Teamleider Expert Team Networking &
|
||||
Succesvol oplossen van de probleemstelling \\
|
||||
|
||||
\hline
|
||||
|
||||
Jos van den Bergh &
|
||||
Zuyd Hogeschool &
|
||||
Schoolbegeleider &
|
||||
De opgeleverde resultaten van de student voldoen aan kwaliteitseisen \\
|
||||
|
||||
\bottomrule
|
||||
|
||||
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
Vervolgens kan worden vastgesteld in hoeverre rekening moet worden gehouden met elke van de stakeholders en in hoeverre deze worden betrokken gedurende het project. Hier wordt een afweging gemaakt tussen de \textit{invloed} en \textit{interesse} van een stakeholder op/in het project, zie figuur \ref{fig:stakeholder_matrix}.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\begin{tikzpicture}
|
||||
\draw[step=3,gray,very thin] (0,0) grid (6,6);
|
||||
\draw[thick,->] (0,0) -- (6,0) node[midway, below] {Interesse};
|
||||
\draw[thick,->] (0,0) -- (0,6) node[midway, left] {Invloed};
|
||||
|
||||
\node[align=center] at (1.5,1.5) {\textbf{Monitor}\\Minimum effort};
|
||||
|
||||
\node[align=center] at (4.5,1.5) {\textbf{Consult}\\Keep informed};
|
||||
|
||||
\node[align=center] at (1.5,4.5) {\textbf{Inform}\\Keep satisfied};
|
||||
|
||||
\node[align=center] at (4.5,4.5) {\textbf{Manage closely}\\Work together};
|
||||
|
||||
\end{tikzpicture}
|
||||
\caption{Stakeholder matrix}
|
||||
\label{fig:stakeholder_matrix}
|
||||
\end{figure}
|
||||
|
||||
\subsection*{Patrick Kuepers}
|
||||
|
||||
Patrick is de opdrachtgever van het project en heeft dus zowel veel invloed op het project als zeer veel interesse in het eindresultaat omdat deze in potentie een probleem oplost voor de werkvoering van het Expert Team Networking. Patrick wordt dus nauw betrokken bij het project.
|
||||
|
||||
\begin{tabular}{ r l }
|
||||
|
||||
\textbf{Invloed} & Hoog\\
|
||||
\textbf{Interesse} & Hoog\\
|
||||
|
||||
\hline
|
||||
|
||||
\textbf{Resultaat} & Manage Closely
|
||||
|
||||
\end{tabular}
|
||||
|
||||
\subsection*{Jos van den Bergh}
|
||||
|
||||
Jos is de procesbegeleider en heeft interesse in de manier waarop het project wordt uitgevoerd maar niet per se in de daadwerkelijke oplossing van de probleem- en/of vraagstelling van de opdrachtgever. Jos vertegenwoordigt daarnaast de belangen van Zuyd Hogeschool waaraan voldaan moet worden om succesvol af te studeren. Het doel is om Jos tevreden te houden.
|
||||
|
||||
\begin{tabular}{ r l }
|
||||
|
||||
\textbf{Invloed} & Hoog\\
|
||||
\textbf{Interesse} & Laag\\
|
||||
|
||||
\hline
|
||||
|
||||
\textbf{Resultaat} & Keep satisfied
|
||||
|
||||
\end{tabular}
|
||||
|
||||
|
||||
\section{Contactdetails}
|
||||
|
||||
\begin{table}[h]
|
||||
\begin{tabular}{ p{0.2\linewidth} p{0.4\linewidth} p{0.2\linewidth} }
|
||||
\toprule
|
||||
\textbf{Naam} & \textbf{Email} & \textbf{Telefoon} \\
|
||||
|
||||
\midrule
|
||||
|
||||
Martijn Remmen &
|
||||
1857088remmen@zuyd.nl &
|
||||
+31 6 29 328 917\\
|
||||
|
||||
\hline
|
||||
|
||||
Patrick Kuepers &
|
||||
pkuepers@kembit.nl &
|
||||
+31 6 15 044 204 \\
|
||||
|
||||
\hline
|
||||
|
||||
Jos van den Bergh &
|
||||
jos.vandenbergh@zuyd.nl &
|
||||
+31 6 51 645 936 \\
|
||||
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\caption{Contactgegevens stakeholders}
|
||||
\end{table}
|
||||
@ -10,12 +10,12 @@ Zaken die deel uitmaken of onderdeel zijn van het project:
|
||||
\item Stakeholders analyseren.
|
||||
\item Wensen en eisen van de stakeholders.
|
||||
\item Ontwerpen van een oplossing.
|
||||
\item Gedeeltelijk realiseren van een oplossing door Proof of Concept.
|
||||
\item realiseren van een Proof of Concept met als doelstelling om het ontwerp te valideren.
|
||||
\end{itemize}
|
||||
|
||||
\subsection*{Out of Scope}
|
||||
|
||||
Per definitie valt alles dat niet genoteerd is in de scope (hoofdstuk \ref{scope}) buiten de scope. Dit hoofdstuk noteerd echter enkele zaken expliciet als out of scope.
|
||||
Per definitie valt alles wat niet genoteerd is in de scope (hoofdstuk \ref{scope}) buiten de scope. Dit hoofdstuk noteert echter enkele zaken uitdrukkelijk als out of scope.
|
||||
|
||||
\begin{itemize}
|
||||
\item Het procesmatig analyseren en verbeteren van processen en werkzaamheden. De focus van dit project is het inhoudelijk verbeteren van deze processen.
|
||||
@ -38,6 +38,6 @@ Eisen aan de omgeving waarin in het project wordt uitgevoerd om succesvol te kun
|
||||
\item Het stagebedrijf voorziet de stagiaire van documentatie over de relevante werkzaamheden.
|
||||
\item Het stagebedrijf voorziet de stagiaire van toegang tot eventuele omgevingen en/of systemen.
|
||||
\item Het stagebedrijf voorziet de stagiaire van eventueel benodigde hulpmiddelen voor het uitvoeren van het project.
|
||||
\item De bedrijfsbegeleider is in staat om begeleiding te bieden aan de student gedurende de stage indien nodig (minimaal 3 uren per week).
|
||||
\item De schoolbegeleider is in staat om begeleiding te bieden aan de student gedurende de stageperiode indien nodig (minimaal 3 uren per week).
|
||||
\item De bedrijfsbegeleider is in staat om begeleiding te bieden aan de student gedurende de stage indien nodig (uitgangspunt is minimaal 3 uren per week).
|
||||
\item De schoolbegeleider is in staat om begeleiding te bieden aan de student gedurende de stageperiode indien nodig (uitgangspunt is minimaal 3 uren per week).
|
||||
\end{itemize}
|
||||
@ -1 +0,0 @@
|
||||
\chapter{Planning}
|
||||
116
chapters/7 - risicoanalyse.tex
Normal file
116
chapters/7 - risicoanalyse.tex
Normal file
@ -0,0 +1,116 @@
|
||||
\chapter{Risicoanalyse}
|
||||
Er bestaat een mogelijkheid dat het project niet succesvol zal zijn. Dit hoofdstuk zal in gaan op de manier waarop risico's worden geclassificeerd, gemanaged en gecommuniceerd.
|
||||
|
||||
\section{Assessment}
|
||||
|
||||
Wanneer een potentieel risico wordt vastgesteld wordt eerst de ernst van dit risico vastgesteld. Dit wordt gedaan op basis van \textit{impact} en \textit{kans} (zie figuur \ref{fig:kansimpactmatrix}). Met \textit{impact} wordt de grootte van de consequenties bedoeld. Met \textit{kans} wordt bedoeld hoe waarschijnlijk het is dat een risico optreedt
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\begin{tikzpicture}[scale=0.8]
|
||||
\draw[fill=green] (0,0) -- (4,0) -- (4,1) -- (3,1) -- (3,2) -- (1,2) -- (1,5) -- (0,5);
|
||||
|
||||
\draw[fill=yellow] (4,0) -- (5,0) -- (5,2) -- (4,2) -- (4,3) -- (3,3) -- (3,4) -- (2,4) -- (2,5) -- (1,5) -- (1,2) -- (3,2) -- (3,1) -- (4,1);
|
||||
|
||||
\draw[fill=red] (4,2) -- (5,2) -- (5,5) -- (2,5) -- (2,4) -- (3,4) -- (3,3) -- (4,3) -- (4,2);
|
||||
|
||||
\draw[step=1,gray,very thin] (0,0) grid (5,5);
|
||||
|
||||
\draw[thick,->] (0,0) -- (5,0) node[midway, below] {Impact};
|
||||
\draw[thick,->] (0,0) -- (0,5) node[midway, left] {Kans};
|
||||
|
||||
|
||||
|
||||
\end{tikzpicture}
|
||||
\caption{Kans- en impactmatrix}
|
||||
\label{fig:kansimpactmatrix}
|
||||
\end{figure}
|
||||
|
||||
Een precieze definitie van elk impactniveau is gedefinieerd in tabel \ref{tbl:impactmatrix}. In deze tabel is voor elke categorie vastgesteld wanneer een risico een bepaalde impact heeft.
|
||||
|
||||
Vervolgens worden de kansen in tabel \ref{tbl:kansmatrix} gedefinieerd. Waarbij $p$ de kans is dat het risico optreedt.
|
||||
|
||||
\begin{table}[h]
|
||||
\caption{Impact matrix}
|
||||
\label{tbl:impactmatrix}
|
||||
\begin{tabular}{ p{0.1\linewidth} p{0.15\linewidth} p{0.15\linewidth} p{0.15\linewidth} p{0.15\linewidth} p{0.15\linewidth} }
|
||||
\toprule
|
||||
\textbf{Categorie}&
|
||||
\textbf{1 Zeer Laag}&
|
||||
\textbf{2 Laag}&
|
||||
\textbf{3 Gemiddeld}&
|
||||
\textbf{4 Hoog}&
|
||||
\textbf{5 Zeer Hoog}\\
|
||||
|
||||
\midrule
|
||||
|
||||
Planning&
|
||||
Er is niet of, een verwaarloosbaar impact op de planning (enkele dagen)&
|
||||
Er is kleine impact op de planning maar binnen uitloop; geen impact op het kritieke pad.&
|
||||
Er is impact op de planning, maar binnen uitloop; wel impact op het kritieke pad.&
|
||||
Er is een groot impact op de planning; veel impact op het kritieke pad.&
|
||||
De planning kan niet worden behaald.\\
|
||||
|
||||
|
||||
\bottomrule
|
||||
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[ht]
|
||||
\caption{Kans Matrix}
|
||||
\label{tbl:kansmatrix}
|
||||
\begin{tabular}{ p{0.18\linewidth} p{0.18\linewidth} p{0.18\linewidth} p{0.18\linewidth} p{0.18\linewidth} }
|
||||
\toprule
|
||||
\textbf{1 - Extreem Zeldzaam}&
|
||||
\textbf{2 - Zeer Zeldzaam}&
|
||||
\textbf{3 - Zeldzaam}&
|
||||
\textbf{4 - Waarschijnlijk}&
|
||||
\textbf{5 - Zeer Waarschijnlijk}\\
|
||||
|
||||
\midrule
|
||||
|
||||
$p \leq 10\% $&
|
||||
$10\% < p \leq 25\%$&
|
||||
$25\% < p \leq 50\%$&
|
||||
$50\% < p \leq 75\%$&
|
||||
$p > 75\%$\\
|
||||
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
\section{Management}
|
||||
|
||||
We definieren verschillende strategieën om om te gaan met vastgestelde risico's. De beste strategie is afhankelijk van de categorie van het risico, maar is ook afhankelijk van het inhoudelijke risico. We definiëren de volgende strategieën:
|
||||
|
||||
\begin{enumerate}
|
||||
\item \textbf{Beperken} Er worden maatregelen genomen om het risico volledig of gedeeltijk te voorkomen.
|
||||
\item \textbf{Accepteren} Het risico wordt geaccepteerd en er worden geen maatregelen getroffen.
|
||||
\item \textbf{Monitor} Houdt het risico in de gaten of deze in impact of kans toe- of afneemt.
|
||||
\item \textbf{Onderzoek} Verricht verder onderzoek naar het risico om de kans en impact beter te kunnen begrijpen.
|
||||
\end{enumerate}
|
||||
|
||||
Voor elke categorie risico (laag, gemiddeld, hoog) zijn verschillende opties het meest toepasselijk. In tabel \ref{tbl:strategiepercat} wordt per categorie aangegeven welke strategieën kunnen worden overwogen. Hier kan eventueel van afgeweken worden, afhankelijk van het inhoudelijke risico. Dit zal echter altijd vooraf gecommuniceerd worden.
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
\caption{Strategie per risico categorie}
|
||||
\label{tbl:strategiepercat}
|
||||
\begin{tabular}{ r l }
|
||||
\toprule
|
||||
\textbf{Risico Categorie} & \textbf{Strategie}\\
|
||||
\midrule
|
||||
\textbf{Hoog} & 1 of 4\\
|
||||
\textbf{Gemiddeld} & 1, 3 of 4\\
|
||||
\textbf{Laag} & 1 t/m 4\\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
|
||||
|
||||
\section{Communicatie}
|
||||
|
||||
Gedurende het project kunnen risico's worden geïdentificeerd. Deze zullen dan zoals beschreven in de vorige hoofdstukken worden geclassificeerd en een bijhorende strategie voor worden aangehouden. afhankelijk van de categorie van het risico kan deze ook worden gecommuniceerd met de opdrachtgever en/of procesbegeleider.
|
||||
|
||||
Over het algemeen zal worden aangehouden dat risico's met een \textbf{hoge} categorie altijd worden gecommuniceerd met de beide de opdrachtgever en de procesbegeleider. Risico's van \textbf{gemiddelde} categorie zullen in ieder geval met de opdrachtgever worden gecommuniceerd maar hier kan optioneel, afhankelijk van de gekozen strategie en aard van het risico, ook de procesbegeleider bij worden betrokken eventueel om advies. Risico's van \textbf{lage} categorie zullen over het algemeen niet (of, met lage prioriteit) gecommuniceerd worden.
|
||||
31
chapters/8 - planning.tex
Normal file
31
chapters/8 - planning.tex
Normal file
@ -0,0 +1,31 @@
|
||||
\chapter{Planning}
|
||||
|
||||
Zoals reeds vermeld hanteert dit project een iteratieve aanpak in plaats van een waterval methode. Het is dus in principe niet zo dat alle producten één voor één worden afgerond. Dit wordt ook gereflecteerd in de planning (figuur \ref{fig:gantt}).
|
||||
|
||||
\begin{figure}[ht]
|
||||
\begin{ganttchart}[
|
||||
vgrid,
|
||||
hgrid,
|
||||
expand chart=0.9\linewidth
|
||||
]{1}{20}
|
||||
\gantttitle{Schoolweek}{20} \\
|
||||
\gantttitlelist{1,...,20}{1} \\
|
||||
\ganttgroup{Initiatie fase}{1}{4} \\
|
||||
\ganttbar{Prestatieplan}{1}{4}\\
|
||||
\ganttbar{Plan van Aanpak}{1}{4}\\
|
||||
|
||||
\ganttgroup{Research fase}{5}{17}\\
|
||||
\ganttbar{Onderzoeksrapport}{5}{17}\\
|
||||
\ganttbar{Ontwerp}{8}{17}\\
|
||||
\ganttbar{Proof of Concept}{9}{17}\\
|
||||
\ganttbar{Extended Abstract}{12}{17}\\
|
||||
\ganttbar{Advies}{12}{17}\\
|
||||
|
||||
\ganttgroup{Eind fase}{17}{20}\\
|
||||
\ganttbar{Voorbereiden presentatie}{17}{20}\\
|
||||
\ganttmilestone{Inleveren}{17}\\
|
||||
\ganttmilestone{Afstudeersessie}{20}
|
||||
\end{ganttchart}
|
||||
\caption{Gantt Planning}
|
||||
\label{fig:gantt}
|
||||
\end{figure}
|
||||
BIN
figures/hevner-dsr-cycle.pdf
Normal file
BIN
figures/hevner-dsr-cycle.pdf
Normal file
Binary file not shown.
7
main.tex
7
main.tex
@ -45,7 +45,11 @@ Martijn Remmen
|
||||
\newcommand{\versie}{CONCEPT}
|
||||
%% }
|
||||
|
||||
\usepackage{pgfgantt}
|
||||
\usepackage{pdflscape}
|
||||
|
||||
\usepackage{multirow}
|
||||
\usepackage{tikz}
|
||||
|
||||
\usepackage[pdftex,
|
||||
pdfauthor={\auteur},
|
||||
@ -72,7 +76,8 @@ Martijn Remmen
|
||||
\input{chapters/4 - kwaliteit.tex}
|
||||
\input{chapters/5 - organisatie.tex}
|
||||
\input{chapters/6 - projectgrenzen.tex}
|
||||
\input{chapters/7 - planning.tex}
|
||||
\input{chapters/7 - risicoanalyse.tex}
|
||||
\input{chapters/8 - planning.tex}
|
||||
|
||||
\printbibliography
|
||||
|
||||
|
||||
Reference in New Issue
Block a user