Thesis/onderzoeksrapport
1
0
Fork 0
Code Issues Pull Requests Projects Releases 2 Wiki Activity

uitgewerkte teksten

Browse Source
This commit is contained in:
Martijn Remmen
2022-04-07 18:18:57 +02:00
parent 579ae0b7f5
commit 62069c36ba
7 changed files with 427 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
chapters/3 - methode.tex
View File

@ -2,7 +2,7 @@
\begin{figure}[h]
\centering
\includegraphics[scale=0.7]{test}
\includegraphics[scale=0.7]{onderzoeksopzet.pdf}
\caption{Onderzoeksopzet diagram}
\end{figure}
@ -13,6 +13,8 @@ KEMBIT maakt gebruikt van een IT-servicemanagement systeem, genaamd TOPDesk. Dit
De informatie in het IT-servicemanagement systeem kan dus worden gebruikt voor het beantwoorden van deelvragen 1 en 2 en daarmee inzichten krijgen in de beste plek in het proces om automatisering toe te passen.
De data-analyse is uitgevoerd met een interactief Python-notebook. In dit interactieve notebook is de code te zien waarmee de resulterende grafieken zijn gemaakt en kan zelfs worden aangepast en opnieuw uitgevoerd om andere inzichten te creeren (interactief). Door deze methode is de validiteit van de gemaakte grafieken goed te controleren.
\section{Interview}
@ -29,12 +31,13 @@ De volgende onderwerpen zullen gedurende het interview behandeld worden, zie app
\item Activiteiten welke als meest problematisch worden beschouwd
\item Reeds gerealiseerde en/of onderzochte oplossingen
\item Bevindingen met betrekking tot deze oplossing
\item Toekomstbeeld netwerkautomatisering
\end{itemize}
\section{Survey}
Het expertteam networking is de doelgroep voor de uiteindelijke oplossing (eindgebruikers). Om ervoor te zorgen dat de oplossing is afgestemd op deze eindgebruikers zal een survey worden uitgevoerd. Uit de survey zal moeten blijken onder andere het algemene kennisniveau is binnen automatisering en wat de verwachtingen, wensen en eisen zijn van deze stakeholder.
Het expertteam networking is de doelgroep voor de uiteindelijke oplossing, zij zullen de automatseringsoplossing moeten kunnen toepassen in hun eigen werkzaamheden. Om ervoor te zorgen dat de oplossing is afgestemd op deze eindgebruikers zal een survey worden uitgevoerd. Uit de survey zal moeten blijken onder andere het algemene kennisniveau is binnen automatisering en wat de verwachtingen, wensen en eisen zijn van het Expert Team Networking.
De resultaten van de survey moeten inzichten geven waarmee de onderzoeksvragen 4 \& 5 beantwoord kunnen worden. De volgende onderwerpen zullen behandeld worden in de survey (zie appendix \ref{appendix:survey} voor de exacte vragen):
@ -47,6 +50,7 @@ De resultaten van de survey moeten inzichten geven waarmee de onderzoeksvragen 4
\item Netwerkautomatisering
\end{itemize}
\item Huidige werkzaamheden
\item Bevindingen huidige situatie
\item Huidig gebruik netwerkautomatisering
\item Toekomstbeeld netwerkautomatisering
\end{itemize}

365
chapters/4 - resultaten.tex
View File

@ -1 +1,364 @@
\chapter{Resultaten}
\chapter{Resultaten}
\begin{itemize}
\item Wat is automatisering
\begin{itemize}
\item Toelichting belang data (management)
\end{itemize}
\item Huidige situatie
\begin{itemize}
\item Data management
\item Processen
\item Resultaten Data analyse en relatie processen
\item Kennis \& ervaring (interview en survey)
\item Toekomstbeeld
\item Kansen
\end{itemize}
\item Mogelijkheden automatiseren (mooie marketing)
\begin{itemize}
\item Keuze maken voor ansible
\item Werking toelichten
\end{itemize}
\item Hoe implementeer je automatisering binnen business
\begin{itemize}
\item Toelichting tool
\begin{itemize}
\item Modules
\item Inventory
\end{itemize}
\item Roadmap voor opdrachtgever
\begin{itemize}
\item Dynamic inventory (poc)
\item Integratie(s) binnen business
\item Lab omgeving
\item Cultuurchange
\item Bedrijfsdocumentatie
\end{itemize}
\end{itemize}
\end{itemize}
\section{Introductie tot automatisering}
Automatiseren is het (gedeeltelijk) vervangen van menselijke handelingen door een programma. Dit programma verricht dezelfde handelingen (of komt in ieder geval tot hetzelfde resultaat) door gebruik te maken van diverse koppelingen (API) met andere systemen. Het doel van automatisering is het omzetten van data naar acties (afbeelding \ref{fig:automatiserinhighlevel}). Automatisering kan op deze manier worden gezien als een soort koppeling tussen allerlei systemen en/of applicaties.
\begin{figure}[h]
\centering
\includegraphics[scale=0.7]{automatisering.pdf}
\caption{High level automatisering}
\label{fig:automatiserinhighlevel}
\end{figure}
\begin{figure}[h]
\centering
\includegraphics[scale=0.7]{anatomie_automatisering.pdf}
\caption{Decompositie automatisering}
\label{fig:automatiserindecompositie}
\end{figure}
\subsection{Data en Data Management}
Data zijn vastgelegde feiten en kunnen betrekking hebben tot elk aspect binnen een business; Een IT-servicemanagent tool om incidenten in bij te houden, een centraal 'directory' systeem om accounts en contactgegevens bij te houden enzovoorts. Al deze data staat verspreid in meerdere verschillende software en formaten elk gespecialiseerd om deze te verwerken en/of op te slaan.
In elk domein zijn andere data relevant. Voor netwerkbeheer kunnen hoofdzakelijk de volgende categorieen worden gedefinieerd:
\begin{itemize}
\item Apparatuur (CMDB)\\
Gegevens met betrekking tot de apparatuur zoals de fabrikant, model, mogelijkheden enzovoorts.
\item Netwerkconfiguratie\\
De technische gegevens van een netwerk zoals IP-adressen, netwerken, poortconfiguraties enzovoorts.
\item Klanten (CRM)\\
Gegevens over klanten en locaties zoals contactgegevens en fysieke adressen.
\item Service Management (ITSM)\\
Een systeem waarin het proces met betrekking tot de dienstverling in wordt bijgehouden (bijvoorbeeld incidenten en changes).
\item Monitoring\\
Gegevens over de operationele status van netwerken.
\end{itemize}
\subsection{Application Programming Interfaces}
Een API ('Application Programming Interface') is een manier waarop programma's gegevens kunnen uitwisselen met elkaar.
Een API kan vele vormen hebben en kenmerkt zich altijd als een manier om gebruik te maken van bestaande functionaliteit (waaronder het ophalen van gegevens). Er bestaan meerdere vormen van API's. Bijvoorbeeld softwarelibraries en Web APIs. Softwarelibaries zijn meestal kant-en-klare paketten die te downloaden zijn om bepaalde (gespecialiseerde) functionaliteit te bieden voor een softwareontwikkelaar. Op deze manier hoeft een softwareontwikkelaar niet alles zelf te schrijven maar kan gebruik worden gemaakt van bestaande en geteste code.
Een Web API is een koppeling die gebruikt kan worden over een netwerk en data formaten zoals JSON of XML hanteerd. Populaire Web API-standaarden zijn bijvoorbeeld REST en GraphQL. De voornaamste eigenschap van een web api is dat deze communicatie mogelijk maakt tussen verschillende programmeertalen, frameworks en externe systemen.
\subsection{Event-Driven}
Veel usecases zetten automatisering in om bepaalde acties uit te voeren naar aanleiding van een bepaalde gebeurtenis. Bijvoorbeeld een account aanmaken op het moment dat hier een verzoek voor binnenkomt. Of de configuratie van een apparaat wijzigen op het moment dat een aanpassing wordt gemaakt in een Configuration Management Database. Het asynchroon ontvangen en verwerken van deze gebeurtenissen is wat de term 'event-driven' betekent \cite{richards_fundamentals_2020}.
\subsection{Declaratief en imperatief}
Imperatief en declaratief zijn programmeerconcepten die een bepaalde programmeerstijl (of 'schrijfstijl') inhouden. Bij het imperatief programmeren wordt beschreven \textit{hoe} tot een bepaald eindresultaat moet worden gekomen. Dit houd dus in het een voor een beschrijven van stappen en instructies om bijvoorbeeld een gebruikersaccount aan te maken. In afbeelding \ref{fig:imperatief_voorbeeld} wordt een voorbeeld gegeven van een imperatief geschreven routine voor het aanmaken van nieuwe gebruikers.
\begin{figure}[h]
\begin{lstlisting}[language=python]
username = 'jdoe'
password = 'hunter02'
if userExists(username):
user := getUser(username)
else:
user := createUser(username, password)
if length(password) > 7 and
contains(password, "!@#$%^&*()"):
setUserPassword(user, password)
else:
print("Password not valid")
\end{lstlisting}
\caption{Voorbeeld imperatieve schrijfstijl}
\label{fig:imperatief_voorbeeld}
\end{figure}
Bij een declaratieve schrijfstijl wordt het eindresultaat beschreven (wat) in plaats van de manier om die te bereiken (hoe). Een declaratieve versie van het voorbeeld in figuur \ref{fig:imperatief_voorbeeld} zou simpelweg een lijst zijn met gebruikers en wachtwoorden, zoals in \ref{fig:declaratief_voorbeeld}.
\begin{figure}[h]
\begin{lstlisting}
users:
- username: jdoe
password: hunter02
- username: foo
password: bar
\end{lstlisting}
\caption{Voorbeeld declaratieve schrijfstijl}
\label{fig:declaratief_voorbeeld}
\end{figure}
Een voordeel van een declaratieve schrijfstijl is dat deze beter te begrijpen is. Er hoeft alleen nagedacht te worden over wat het gewenste resultaat is en niet hoe deze bereikt kan worden. Wanneer automatisering wordt toegepast in een afdeling die niet gespecialiseerd is in het ontwikkelen en onderouden van code is een abstractere programmeertaal een voordeel.
\subsection{Use cases}
Er zijn vele usecases voor automatisering. Enkele globale categorieen zijn bijvoorbeeld configuratie management, event processing en data synchronisatie.
\subsubsection*{Data interfacing en transformatie}
Automatiseren bestaat vaak uit operaties tussen bestaande systemen. Of deze systemen nu bepaalde softwarepakketten, servers of netwerkapparaten zijn. Deze systemen bevatten verschillende soorten aan gegevens waaronder operationele status, configuratie en/of domeinspecifieke data die verwerkt wordt door het systeem. Netwerkapparatuur
Neem bijvoorbeeld een webserver, deze moet worden geconfigureerd met bijvoorbeeld welke poort deze moet luisteren (configuratie). De site die wordt geserveerd door de webserver is in dit geval domeinspecifieke data. Wanneer de webserver in productie wordt genomen produceert deze gegevens zoals bijvoorbeeld logs, throughput en gegevens over de bezoekers van de webserver, dit zijn operationele gegevens.
Bij \textbf{configuratie management} wordt het genereren en beheren van bepaalde configuraties geautomatiseerd. Deze configuraties kunnen bijvoorbeeld zijn voor bepaalde software zoals webservers, proxies of vpn's. Meestal in de vorm van een tekstbestand. Een configuratie kan een gestructureerde- of semigestructureerde syntax hebben. Bij een gestructureerd syntax worden bijvoorbeeld JSON, XML of INI gebruikt.
Bij een semigestructureerde syntax wordt geen gebruik gemaakt van een bepaald gestandaardiseerd formaat maar lijkt deze meer op text. In deze text zit een vorm van structuur maar zal eerst 'geparsed' moeten worden om deze om te zetten in volledig gestructureerde data. Het produceren van een semigestructureerde data kan worden gedaan door 'templating', dit is een techniek waarbij programmatisch lappen text worden gegenereerd aan de hand van een gestructureerd dataformaat.
\subsubsection*{Event processing}
Bij event processing is het doel om bepaalde acties uit te voeren als reactie op een bepaalde gebeurtenis. Bijvoorbeeld een welkomstmail sturen op het moment dat een nieuwe gebruiker wordt aangemaakt in een CRM.
Bij event-driven automatisering spreken we van een bepaalde \textbf{trigger}, \textbf{context} en \textbf{acties}. De trigger is de gebeurtenis welke moet worden
\subsection{Tools}
Er zijn vele tools welke automatisering bevorderen of volledig zijn geoptimaliseerd voor een 'automatisering'-usecase. Dit houdt onder andere in dat de tools veel functionaliteiten bevatten voor het verwerken van data en het communiceren met systemen. Over het algemeen hebben automatietools de volgende karakteristieken:
\begin{enumerate}
\item \textbf{Data-extractie en -injectie functionaliteit}\\
Bevatten een uitgebreid assortiment aan functies waarmee gecomuniceerd kan worden met verschillende systemen en in verschillende datastructuren en protocollen.
\item \textbf{Data transformatie functionaliteit}\\
Bevatten een uitgebreid assortiment aan functies waarmee veelvoorkomende operaties kunnen worden uitgevoerd op data. Zoals filteren, sorteren en omzetten van datastructuren.
\item \textbf{Declaratieve syntax}\\
Hebben een manier om op een declaratieve manier de taak vast te leggen.
\item \textbf{Flexibel uitbreidbaar}\\
Kan worden uitgebreid wanneer er geen bestaande functionaliteit zijn om het gewenste resultaat te bereiken. Dit is belangrijk omdat elke business een andere omgeving heeft. Om een automatietool tot volledige potentie te kunnen gebruiken moet deze maximaal geintegreerd zijn in de omgeving van een business en het mogelijk maken om seamless met alle software en apparaten te kunnen integreren.
\end{enumerate}
\subsection{Ansible}
Ansible is een op Python gebaseerde tool waarmee zeer diverse soorten automatiseringen kunnen worden gerealiseerd dankzij een uitgebreid assortiment aan eenvoudig te gebruiken modules en een YAML gebaseerde "Domain Specific Language".
Ansible is door KEMBIT als automatiseringstool naar keuze verkozen dankzij de flexibiliteit, uitbreidbaar, gebruiksvriendelijkheid en inzetbaarheid in haar huidige productieomgevingen. De tool is initïeel in gebruik genomen door het Expert Team Infrastructure, een ander team binnen KEMBIT gespecialiseerd in het beheren van servers.
Na evaluatie door het networking team wordt de tool als zeer potentieel beschouwd dankzij het uitgebreide assortiment aan netwerkmodules en officiele ondersteuning voor het automatiseren van netwerk gerelateerde taken waaronder configuratie.
\subsubsection*{Functionaliteit voor netwerkautomatie}
\subsubsection*{Uitbreidbaarheid}
Ansible is zeer uitbreidbaar door het creeren van 'modules' waarmee bijna alle gewenste additionele koppelingen en/of functionaliteiten kunnen worden toegevoegd aan de automatietool.
\section{Huidige situatie}
\subsection{Een visie voor netwerkautomatsering}
Door inspanningen voornamelijk van teamleider Patrick zijn een aantal automatiseringstools gerealiseerd. Deze tools zijn gebaseerd op Powershell en maken het mogelijk om gedeeltijk geautomatiseerde handelingen uit te voeren op netwerkapparatuur.
Tegenwoordig zijn met name verschillende junior networkengineers belast met het verder ontwikkelen van netwerkautomatiseringen sinds het vervullen van een rol als teamleider door Patrick.
\subsection{Data management}
Gezien het belang van data is voor het mogelijk maken van automatiseren wordt ten eerste inzichtelijk gemaakt welke data er al opgeslagen wordt, in welk systeem en welke koppelingen deze systemen beschikbaar stellen.
\begin{itemize}
\item TOPDesk
\item TOPDesk Asset Management
\item PRTG
\end{itemize}
\subsubsection{Topdesk}
Topdesk is een IT-servicemanagent tool die wordt gebruikt door KEMBIT in het uitvoeren van hun werkzaamheden. TOPDesk faliciteerd het managenen van het ITIL proces
\begin{itemize}
\item Incidenten
\item Changes
\item Projecten
\end{itemize}
\subsubsection{Topdesk Asset Management}
Topdesk Asset Management is een module voor Topdesk die CMDB-functionaliteit toevoegd. Een 'configuration management database' is een systeem die wordt gebruikt voor het opslaan van informatie over hardware en software 'assets'. Dit is handig voor verschillende redenen bijvoorbeeld het bijhouden van bepaalde werkzaamheden die zijn uitgevoerd op een bepaald apparaat zoals reparaties.
Een bedrijf kan elk soort apparaat in een CMDB willen opnemen, afhankelijk van het type bedrijf. Voor elk soort apparaat kunnen andere eigenschappen relevant zijn om op te nemen in het CMDB. Bij een server misschien hoeveel memory of harde schijven deze heeft. Maar bij een monitor misschien de resolutie of ondersteunde inputs (vga, hdmi enzovoorts).
Het bijzondere aan TOPDesk Asset Management is dat zelf velden kunnen worden gedefinieerd die een soort apparaat heeft. Dit soort functionaliteit noemt men 'meta-modeleren', Asset Management biedt een model (soorten velden en relaties) waarmee modellen kunnen worden gedefinieerd (zoals monitors, servers of netwerkapparatuur). De gemaakte modellen noemt TOPDesk Asset Management een 'template'. Zo kan dus een template worden gemaakt voor een monitor die de velden 'merk' en 'resolutie' heeft. Of een template voor een server die de velden 'geheugen capaciteit' en 'aantal harde schijven' heeft.
Het Expert Team Networking gebruikt Asset Management voor het opslaan van alle netwerkapparatuur die wordt beheerd en heeft hier zelf templates voor gedefinieerd. De volgende templates zijn gemaakt:
\begin{enumerate}
\item Switch 8 Poorten
\item Switch 12 Poorten
\item Switch 24 Poorten
\item Switch 48 Poorten
\item Switch Core
\item Switch Distributie
\item Wireless Access Point
\item Wireless LAN Controller
\item Firewall
\item Router
\item UPS
\end{enumerate}
Onderling zijn er relatief weinig verschillen in deze templates behalve de naam.
\newcommand{\gray}{\cellcolor{lightgray}}
\begin{table}[h]
\centering
\caption{Templates met dezelfde eigenschappen (aangegeven met een '+')}
\begin{tabular}{r | r | r | r | r | r | r | r | r | r | r | r |}
& \rotatebox[origin=l]{90}{Switch 8 Poorten}&
\rotatebox[origin=l]{90}{Switch 12 Poorten}&
\rotatebox[origin=l]{90}{Switch 24 Poorten}&
\rotatebox[origin=l]{90}{Switch 48 Poorten}&
\rotatebox[origin=l]{90}{Switch Core}&
\rotatebox[origin=l]{90}{Switch Distributie}&
\rotatebox[origin=l]{90}{Wireless Access Point}&
\rotatebox[origin=l]{90}{Wireless LAN Controller}&
\rotatebox[origin=l]{90}{Firewall}&
\rotatebox[origin=l]{90}{Router}&
\rotatebox[origin=l]{90}{UPS}\\
\hline
Switch 8 Poorten& \gray & + & + & + & + & + & & + & + & & + \\
\hline
Switch 12 Poorten& \gray & \gray & + & + & + & + & & + & + & & + \\
\hline
Switch 24 Poorten& \gray & \gray & \gray & + & + & + & & + & + & & + \\
\hline
Switch 48 Poorten& \gray & \gray & \gray & \gray & + & + & & + & + & & + \\
\hline
Switch Core& \gray & \gray & \gray & \gray & \gray & + & & + & + & & + \\
\hline
Switch Distributie& \gray & \gray & \gray & \gray & \gray & \gray & & + & + & & + \\
\hline
Wireless Access Point& \gray & \gray & \gray & \gray & \gray & \gray & \gray & & & & \\
\hline
Wireless LAN Controller& \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & + & & +\\
\hline
Firewall& \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & & + \\
\hline
Router& \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & \gray & \\
\hline
\end{tabular}
\end{table}
\subsection{Analyse tijdsbesteding}
\begin{figure}[h]
\centering
\includegraphics[scale=0.6]{changes_tijd_categorie.pdf}
\caption{Totaal bestede tijd per categorie (percentage)}
\label{fig:changes_tijd_categorie}
\end{figure}
\begin{figure}[h]
\centering
\includegraphics[scale=0.6]{changes_aantal_categorie.pdf}
\caption{Aantal changes per categorie (percentage)}
\label{fig:changes_aantal_categorie}
\end{figure}
\begin{figure}[h]
\centering
\includegraphics[scale=0.6]{changes_tijd_gemiddeld_categorie.pdf}
\caption{Gemiddelde bestede tijd per categorie (genormaliseerd)}
\label{fig:changes_tijd_gemiddeld_categorie}
\end{figure}
\begin{figure}[h]
\centering
\includegraphics[scale=0.8]{changes_tijd_categorie_tijd.pdf}
\caption{Gespendeerde tijd per categorie over de periode 2020 t/m 2022 (genormaliseerd)}
\label{fig:changes_tijd_categorie_tijd}
\end{figure}
\begin{figure}[h]
\centering
\includegraphics[scale=0.6]{incidenten_tijd_categorie.pdf}
\caption{Gemiddelde bestede tijd per categorie (genormaliseerd)}
\label{fig:incidenten_tijd_gemiddeld_categorie}
\end{figure}
\subsection{Processen en werkwijze}
\textbf{TODO}
\begin{enumerate}
\item Intro van werkzaamheden
\item Kort overzicht van processen
\end{enumerate}
\begin{itemize}
\item Facturatieproces
\item Onderhoudsproces
\item Securityproces
\item Monitoringsproces
\item Backupproces
\item Beheerproces
\end{itemize}
\section{Implementeren van Ansible}
\section{Roadmap}

12
chapters/5 - conclusie.tex
View File

@ -1 +1,11 @@
\chapter{Conclusie}
\chapter{Conclusie}
Ten eerste kunnen de volgende primaire knelpunten worden gedefinieerd voor het implementeren van netwerkautomatisering in de praktijk:
\begin{enumerate}
\item Reeds gerealiseerde en op Powershell gebaseerde automatiseringen die niet volledig overdragen naar het implementeren van Ansible in de praktijk. Dit maakt investeringen in het realiseren van Ansible op de kortere termijn minder waardevol omdat deze functionaliteiten al mogelijk waren met de oude tools. Hiernaast zijn deze investeringen hoger omdat het nu in een nog relatief onbekende manier moet worden geimplementeerd.
\item De reeds bestaande kennis over PowerShell in het netwerking team is niet of minder relevant bij het in gebruik nemen van Ansible. Dit presenteerd weer op de kortere termijn een extra drempel voor het in gebruik nemen van Ansible omdat het nu meer tijd kost om even effectief te zijn met de bestaande powershell tools en/of kennis.
\item \label{knelpunt:am_useability} Een relatief complexe API van Asset Management (voornamelijk veroorzaakt door de meta-modeleer functionaliteit). Dit verhoogd de vereiste tijdsinvestering en minimale complexiteit om tools te maken die integreren met deze API
\item Geen bestaande integraties met Asset Management. Terwijl het gebruik maken van deze API (direct of indirect) een vereiste is voor het toepassen van Ansible in productie netwerken voor het genereren van een ansible inventory. Dit in combinatie met punt \ref{knelpunt:am_useability} veroorzaakt dat het niet mogelijk is om Ansible te gebruiken en het een hoge upfront investering vereist om op te lossen.
\item Asset Management lijkt nog niet volledig optimaal te worden ingezet aan de hand van de templates die grotendeels hetzelfde zijn. Hierdoor is er een grote kans dat de inventory plugin voor Ansible op korte termijn moet worden aangepast om eventuele herstructureringen in Asset Management te reflecteren.
\end{enumerate}

14
figures/src/anatomie_automatisering.dot Normal file
View File

@ -0,0 +1,14 @@
digraph {
rankdir="LR"
node [shape=box]
"Automatisering" -> "Trigger"
"Automatisering" -> "Context"
"Automatisering" -> "Actie(s)"
"Trigger" -> "Tijd"
"Trigger" -> "Handmatig"
"Trigger" -> "Gebeurtenis"
"Context" -> "Parameters"
"Actie(s)" -> "Data extractie"
"Actie(s)" -> "Data transformatie"
"Actie(s)" -> "Data injectie"
}

5
figures/src/automatisering.dot Normal file
View File

@ -0,0 +1,5 @@
digraph {
rankdir="LR"
"Data" -> "Instrument"
"Instrument" -> "Acties"
}

14
figures/src/onderzoeksopzet.dot Normal file
View File

@ -0,0 +1,14 @@
digraph {
node [shape=box]
"Data-analyse" -> "Root Cause analyse"
"Survey" -> "Root Cause analyse" [label="1"]
"Survey" -> "Requirements" [label="2"]
"Interview" -> "Root Cause analyse"
"Interview" -> "Requirements"
"Root Cause analyse" -> "Requirements"
"Requirements" -> "Literatuurstudie"
"Requirements" -> "Ontwerp"
"Literatuurstudie" -> "Ontwerp"
"Ontwerp" -> "Proof of Concept"
"Proof of Concept" -> "Requirements"
}

13
figures/src/test.dot Normal file
View File

@ -0,0 +1,13 @@
digraph {
rankdir="LR"
node [shape=box]
"Apparaat" -> "Naam"
"Apparaat" -> "Hostnaam"
"Apparaat" -> "IP-adres"
"Apparaat" -> "Klant"
"Apparaat" -> "Locatie"
"Apparaat" -> "Status"
"Apparaat" -> "Interfaces" -> "Naam"
"Interfaces" -> "Status"
}