\documentclass[dutch]{deltares_report}
\usepackage[titletoc]{appendix}
\usepackage{lipsum}

%-----------------------------------------------

\begin{document}
\pagestyle{empty}
%

\newcommand{\ProgramName}{DAM}
\newcommand{\ProgramNamePlusSpace}{DAM }

\title{\ProgramName}
\subtitle{Projectplan}
\projectnumber{1221575-000}
\documentid{}
\client{Deltares - Geo engineering DKS}
\contact{}
\reference{1221572-000-GEO-XXXX}
\classification{-}

\author{Tom The}
\partner{Irene van der Zwan}
\date{Mrt 2017}
\version{0.2}

\keywords{Dike, safety assessment, design, software, macro stability, piping}

\summary{This document contains the projectplan for refactoring of \ProgramName, an application that computes the strength of a complete dikering with respect to several failure mechnanisms, such as macro stability and piping.
	
	\textbf{\footnotesize{Samenvatting}} \\
	Dit document bevat het projectplan voor de refactoring van \ProgramName, een User Interface applicatie die een gebruiker in staat stelt om voor een dijktraject berekeningen uit te voeren voor verschillende faalmechanismen, waaronder macrostabiliteit en piping.}

\versioni{0.2}
\datei{Mrt 2017}
\authori{Tom The\newline Irene van der Zwan}
\revieweri{John Bokma \newline Kin Sun Lam}
\approvali{Maya Sule}
\organisationi{Deltares}
\publisheri{Deltares}

\status{draft}
\disclaimer{This is a draft report, intended for discussion purposes only. No part of this report may be relied upon by either principals or third parties.}

\deltarestitle


%------------------------------------------------------------------------------
\chapter{Inleiding} \label{sec:Introductie}

Het softwarepakket Dijksterkte Analyse Module (DAM) is sinds 2008 ontwikkeld binnen verschillende projecten van diverse waterschappen, STOWA en (ontwikkelings)programma\'s. Dit heeft in 2013 geleid tot DAM 1.0: een versie van DAM die voor iedereen binnen het waterkeringendomein te gebruiken is. De voordelen van DAM en de aanwezige functionaliteiten in DAM voor de waterkeringsprocessen hebben zich in de praktijk bewezen. Tegelijkertijd zien Deltares en de gebruikers veel mogelijkheden om DAM uit te breiden met nieuwe functionaliteiten, zoals aansluiten bij de ontwikkelingen van het Wettelijke Beoordelingsinstrumentarium 2017 (WBI2017). Maar ook in DAM-Live (de real-time variant van DAM voor operationele systemen, zoals monitoringssystemen) worden vele mogelijkheden gezien om de waterkeringsprocessen door middel van automatisering te ondersteunen.

Door de ontwikkeling in de beginjaren van DAM uit te voeren binnen projecten, konden er snel resultaten worden geboekt en functionaliteiten worden gerealiseerd. De keerzijde van deze aanpak is dat de software-technische structuur (software-architectuur) en softwaredocumentatie van DAM niet voldoende rekening houdt met functionele uitbreidingen.
De ontwikkelingen richtten zich immers op de benodigde functionaliteiten binnen de projecten. De ruimte binnen de projecten om de software-ontwikkeling toekomstbestendig en robuust uit te voeren was beperkt. Door de vele uitbreidingen in het verleden is de complexiteit van programmeercode van DAM steeds meer toegenomen, waardoor nieuwe uitbreidingen steeds meer inspanning kosten en de complexiteit van de code verder wordt vergroot. Het gebruik en de ontwikkeling van DAM is hierdoor niet toekomstbestendig.

Aangezien er nog veel wensen zijn in de uit te breiden functionaliteiten en men DAM voor langere tijd wil blijven gebruiken, is het moment aangebroken om de software-ontwikkeling van DAM tegen het licht te houden. We willen de softwarecode als de software-ontwikkeling herstructureren naar de huidige en toekomstige wensen voor DAM en op deze manier DAM toekomstbestendig maken. In de software-ontwikkeling wordt dit refactoring of redesign genoemd.

In dit document wordt beknopt een projectplan beschreven met wat de Deltares visie omtrent de toekomstbestendigheid van DAM inhoudt en hoe dit zich vertaalt in de globale activiteiten van de herstructurering. 

De begeleidingsgroep van DAM heeft in het laatste overleg (d.d. 30 november 2016) verzocht om bij de herstructurering de (bestaande) functionaliteiten voor het toetsen van regionale waterkeringen aan te passen conform de laatste leidraad. Dit verzoek is meegenomen in dit projectplan.

\section{Andere documenten} \label{sec:Documenten}

De totale documentatie van \ProgramName bevat de volgende documenten.

\renewcommand{\arraystretch}{1.3}

\begin{table}[H]
%\caption{xxx}
%\label{xxx}
\begin{tabular}{|p{60mm}|p{80mm}|} \hline
\textbf{Titel} & \textbf{Omschrijving} \\ \hline
\ProgramNamePlusSpace - Architecture Overall \newline \citep{DAM_ArchitectureOverall} & Description of overall architecture of \ProgramNamePlusSpace and its components. \\ \hline
\ProgramNamePlusSpace DAM Kernel Functional Design  \newline \citep{DAMEngine_FunctionalDesign} & Description of the different functionalites available in the \ProgramName and background information. \\ \hline
\ProgramNamePlusSpace Kernel - Technical Design \newline \citep{DAMEngine_TechnicalDesign} & Description of the implementation of the technical design of \ProgramName. \\ \hline
\ProgramNamePlusSpace Kernel - Technical documentation \newline \citep{DAMEngine_TechnicalDocumentation} & Description of the arguments and usage of different software components, generated from in-line comment with Doxygen. \\ \hline
\ProgramNamePlusSpace Kernel - Test Plan \newline \citep{DAMEngine_TestPlan} & Description of the different regression and acceptation tests, including target values.  \\ \hline
\ProgramNamePlusSpace Kernel - Test Report \newline \citep{DAMEngine_TestReport} & Description of the test results (benchmarks and test scripts). \\ \hline
\ProgramNamePlusSpace UI - Handleiding deel C \newline  \citep{DAMUI_Manual} & Description of the requirements and functional design. \\ \hline
\ProgramNamePlusSpace UI - Technical Design \newline  \citep{DAMUI_TechnicalDesign} & Description of the requirements and functional design. \\ \hline
\ProgramNamePlusSpace UI - Technical documentation \newline \citep{DAMUI_TechnicalDocumentation} & Description of the arguments and usage of different software components, generated from in-line comment with Doxygen. \\ \hline
\ProgramNamePlusSpace UI - Test Plan \newline \citep{DAMUI_TestPlan} & Description of the different regression and acceptation tests, including target values.  \\ \hline
\ProgramNamePlusSpace UI - Test Report \newline \citep{DAMUI_TestReport} & Description of the test results (benchmarks and test scripts). \\ \hline
\end{tabular}
\caption{\small \ProgramNamePlusSpace system documents.}
\label{tbl-Documents}
\end{table}


%------------------------------------------------------------------------------
\chapter{Visie op herstructurering DAM}\label{sec:visie}
De herstructurering moet DAM weer toekomstbestendig maken voor nieuwe ontwikkelingen, uitbreidingen of aanpassingen van functionaliteiten tegen acceptabele inspanning en kosten. Daarnaast zullen ook de kosten voor het beheer en onderhoud na een herstructurering niet gaan oplopen. DAM moet daarbij verschillende waterkeringsprocessen met betrekking tot de dijksterkte kunnen ondersteunen. De waterkeringsprocessen waaraan gedacht kan worden zijn bijvoorbeeld (regionale) toetsen, ontwerpen, zorgplicht, uitvoeren van beleidstudies, calamiteitenzorg.

Deze te ondersteunen processen vereisen verschillende functionaliteiten en verschillende implementaties van de functionaliteiten in DAM. De herstructurering van DAM moet dus het toevoegen, vervangen en onderhouden van functionaliteiten van DAM eenvoudiger maken. Hierbij wordt uitgegaan dat de functionaliteiten beschikbaar zijn als afzonderlijke softwarecomponenten (modules). Daarbij maakt het niet uit wie de modules heeft ontwikkeld. Zolang deze aan bepaalde (nog nader te omschrijven) eisen voldoet, kunnen deze gekoppeld worden aan DAM. Dit is de gewenste modulaire opzet, die in DAM was voorzien.

Bij functionaliteiten moet niet uitsluitend gedacht worden aan dijksterkteberekeningen voor verschillende faalmechanismen, maar ook aan (grafische) gebruikers interfaces (GUI), ondersteuning bij het schematiseren en het presenteren/visualiseren van de gewenste resultaten voor een waterkeringsvraagstuk, --taak of --proces.

Naast deze modulaire opzet in functionaliteit willen we met de herstructurering ook de data (-formats) en data-uitwisseling meer in lijn brengen met standaarden die ook elders in de waterveiligheidssector worden gebruikt (o.a. Aquo-standaard), zodat dit beter is in te passen in het databeheer en eenvoudiger is te verwerken en bewerken met ETL-tools.

De bestaande functionaliteiten willen we, na de herstructurering, zo veel mogelijk behouden. Hiervoor is het nodig dat deze functionaliteiten beschikbaar zijn als modules. Deel van de functionaliteiten zijn reeds modules, maar er zijn ook functionaliteiten die nog moeten worden ge\"isoleerd en herstructureerd tot modules. Door de modulaire opzet is het mogelijk om dit gefaseerd uit te voeren.

Door de gewenste modulaire opzet wordt het van belang hoe de modules in DAM worden gekoppeld. De expliciete keuze om ook extern ontwikkelde modules toe te kunnen voegen, vraagt om heldere eisen waaraan een module moet voldoen om te kunnen koppelen. Ook de sofware-documentatie moet voldoende informatie bieden om deze koppeling mogelijk te maken. Dit zijn organisatorische zaken die expliciet bij de herstructurering moeten worden geregeld.

DAM wordt door de herstructurering een ondersteunend softwareprogramma die het mogelijk maakt om op relatief eenvoudige wijze verschillende functionaliteiten met betrekking tot de dijksterkteberekening aan elkaar te koppelen, zodat waterkeringsvraagstukken en -taken snel en effici\"ent kunnen worden uitgevoerd. DAM zal beschikken over een uit te breiden set algemene functionaliteiten die in overleg met de gebruikers is vastgesteld en gerealiseerd. Daarnaast kunnen gebruikers specifieke functionaliteiten aan DAM toevoegen, zodat DAM precies aan kan sluiten bij de behoeftes van de gebruikers. Deze functionaliteiten kunnen in projecten of (onderzoeks)pilots door verschillende partijen/belanghebbenden worden ontwikkeld. Het is dan aan de gebruikers van DAM om te bepalen of deze specifieke functionaliteiten worden omgezet naar algemene functionaliteiten in DAM. Daarmee zijn deze functionaliteiten onderdeel van DAM en worden zo als zodanig ook beheerd en onderhouden. Het is ook weer aan de gebruikers om te besluiten om functionaliteiten te verwijderen uit DAM.

De continu\"iteit van DAM wordt gewaarborgd door Deltares en de gebruikers. Deltares zorgt voor het beheer en onderhoud van DAM inclusief de set met algemene functionaliteiten, zodat deze beschikbaar blijft voor alle gebruikers. De gebruikers dragen gezamenlijk de financi\"en voor het beheer en onderhoud en de kosten voor het implementeren van specifieke (beschikbare) modules/functionaliteiten in DAM. Het implementeren van DAM of het ontwikkelen van specifieke modules/functionaliteiten wordt gefinancierd door de belanghebbenden.

De bovenstaande visie sluit aan op de uitgevoerde Businesscase DAM, waarbij de meerwaarde van DAM onder andere ligt bij het (kosten-)effici\"ent kunnen uitbreiden van de functionaliteiten van DAM. In de Businesscase wordt onder andere aansluiten van WBI-functionaliteiten genoemd, maar ook het ondersteunen van zorgplicht, continue toetsen en ontwerpen.

Benadrukt wordt dat het bovenstaande een visie betreft die de randvoorwaarden schept voor de herstructurering. De herstructurering moet het bovenstaande mogelijk maken. Hoe de verschillende genoemde zaken ge\"implementeerd moet worden na herstructurering, zal dan eerst verder uitgewerkt moeten worden samen met de gebruikers. DAM moet immers ondersteuning bieden aan de gebruikers aan aansluiten aan de wensen en behoefte van de gebruikers.

%-----------------------------------------------
\chapter{Doel van de herstructurering}\label{sec:doel}
Het doel van de herstructurering is het toekomstbestendig maken van DAM, zowel programmeertechnisch (d.w.z. goede software-architectuur) als organisatorisch (o.a. documentatie en gebruikerscommunity bij de ontwikkeling), zodat nieuwe ontwikkelingen, uitbreidingen of aanpassingen van functionaliteiten en het beheer en onderhoud van DAM tegen acceptabele inspanning en kosten kan plaatsvinden. De herstructurering moet de gebruikers de gelegenheid geven om zelf functionaliteiten tegen DAM aan te (laten) ontwikkelen (modulaire opzet), zodat de ondersteuning van DAM in de werkprocessen optimaal kan zijn. 

Uitgangspunt is dat de bestaande functionaliteiten beschikbaar blijven. Maar met het herstructureren zullen er ook bijvoorbeeld afwegingen gemaakt moeten worden of een bestaande functionaliteit moet worden geherstructureerd en opnieuw aan DAM moet worden aangesloten of dat de functionaliteit moet worden vervangen door een nieuwe beschikbare module (bijvoorbeeld uit WBI). Dergelijke zaken worden voorgelegd aan de gebruikers (vertegenwoordigd nu door de begeleidingsgroep). De begeleidingsgroep heeft reeds verzocht om de (bestaande) functionaliteiten voor het toetsen van regionale waterkeringen aan te passen conform de laatste leidraad. 

%------------------------------------------------------------------------------
\chapter{Werkzaamheden} \label{sec:werkzaamheden}
Voor de herstructurering van DAM zijn de volgende activiteiten voorzien:
\begin{enumerate}

\item Opstellen van de software-architectuur en het datamodel
\item Opstellen van de documentatie en het organiseren van het beheer en ontsluiten daarvan  
\item Herstructureren van de DAM-code
\item Opnieuw aansluiten van de (bestaande) GUI (grafische gebruikersinterface)
\item Opnieuw aansluiten van de bestaande functionaliteiten 
\item Functionaliteit: Regionaal toetsen consistent met de laatste versie van de Leidraad Toets op veiligheid – Regionale Waterkeringen (2015).
\end {enumerate}

\section{Architectuur}\label{sec:architectuur}
Zoals in de inleiding is aangegeven is tijdens de ontwikkeling van DAM de architectuur zijdelings meegenomen. Om DAM toekomstbestendig te maken, dient de plaats van DAM en de opbouw van DAM geanalyseerd te worden en de ontwerpkeuzen vastgelegd te worden. Toekomstige ontwikkelingen en uitbreidingen bouwen voort op de architectuur.
Het ontwerp van de architectuur wordt besproken in document \newline

\section{Documentatie}\label{sec:documentatie}
Voor de documentatie wordt zoveel mogelijk aangesloten bij de werkwijze van het WBI, m.u.v. het eerder genoemde architectuurdocument en een visiedocument. Dit houdt in dat er een functioneel ontwerp en een technisch ontwerp worden opgesteld. Daarnaast wordt een testplan (op welke wijze er getest gaat worden) en een test document (resultaten van de testen) opgesteld. Een gebruikershandleiding is reeds aanwezig en zal niet aangepast worden aangezien de GUI ook niet veranderd.

De bestaande functionaliteit is beschreven in deel C van de handleiding van DAM.
Dit was een bruikbare werkwijze voor de afgelopen ontwikkelfases van DAM. Voor de herstructurering is het echter van belang dat de functionaliteiten zo volledig mogelijk omschreven en dat wordt vastgelegd hoe aangetoond kan worden dat deze functionaliteit aanwezig is, met name na de herstructurering is dit van belang. Verder is dit document, ‘Functioneel ontwerp’ genaamd, een plek om toekomstige gewenste functionaliteiten in vast te leggen. En hierover consensus te bereiken bij alle belanghebbenden. Het document zal dus geactualiseerd worden tijdens ontwikkelperiodes van DAM.\newline
Ten grondslag van het document Functioneel ontwerp ligt het nog op te stellen visie document. Met dit visie document kan getoetst worden of beoogde nieuwe functionaliteit binnen de visie past.
Naast deze documenten, dient een technisch ontwerp gemaakt te worden tijdens de herstructurering. Hier dienen de noodzakelijke technische ontwerpkeuzen in vastgelegd te worden.  Zodat bij verdere ontwikkeling van DAM duidelijk is wat de consequenties zijn van nieuwe functionaliteit.\newline
Tot slot dient het testen worden vastgelegd in een testplan en testrapporten. Zodat aangetoond wordt dat de functionaliteit en kwaliteit behouden blijft.

\section{Herstructuren code}\label{sec:code}
In de huidige DAM zijn de GUI-functionaliteit en de schematiserings-/rekenfunctionaliteit met elkaar vervlochten. Deze schematiserings-/rekenfunctionaliteit bestaat uit:
\begin{itemize}
	\item Scenarioselectie ten behoeve van toetsing regionale keringen;
	\item Geometrie-aanpassing (ontwerp-optie);
	\item Waterspanningenschematisatie.
\end{itemize}

Tijdens de herstructurering wordt de GUI- en rekenfunctionaliteit uit elkaar gehaald. Verdere uitwerking van dit proces, wordt beschreven in \autoref{sec:ontwikkelblokken}.

\section{Bestaande GUI}\label{sec:bestaandeGUI}
Tijdens de herstructurering wordt de GUI niet aangepast. Door de herstructurering wordt het wel mogelijk om later gemakkelijker over te schakelen op een andere of een nieuwe te maken GUI, dankzij activiteit 3. 

\section{Bestaande functionaliteit}\label{sec:bestaandefunctionaliteit}
Door de herstructurering bij activiteit 3, dient de bestaande functionaliteit hersteld te worden. Met bestaande functionaliteit wordt hier bedoeld het aansluiten op de reeds gebruikte macrostabiliteits- en pipingkernels.  Deze zijn niet gelijk aan de kernels uit het WBI; naast een andere programmeertaal, zijn er functionele verschillen. Zo bevat de WBI-macrostabiliteitskernel een gedeelte dat de waterspanningen schematiseert (waternet creator), hetgeen in DAM apart van de macrostabilteitskernel plaatsvindt.

\section{Toetsen regionaal}\label{sec:regionaal}
Deze activiteiten betreft geen herstructurering, maar zijn opgenomen in overleg met de gebruikersgroep met de herstructurering ook direct te laten profiteren van de herstructurering (relatief eenvoudig aan kunnen sluiten van nieuwe functionaliteiten). Het toetsen van de regionale waterkeringen zal hiervoor in een afzonderlijke module worden gezet. Omdat de functionaliteiten voor het toetsen van de regionale waterkeringen wel in een aparte module wordt ondergebracht, zal deze in de toekomst wel effici\"ent kunnen worden uitgebreid of aangepast. 

Andere mogelijk nieuwe (aan te sluiten) functionaliteiten zijn hieronder weergegeven. Het realiseren van deze functionaliteiten is afhankelijk van de beschikbare financiering en prioritering van (onder andere) de begeleidingsgroep.
\begin{enumerate}
	\item Updaten toetsen regionale keringen module naar nieuwe leidraad.
	\item Aansluiten  op D-Soil Model; inlezen van projectbestanden
	\item Rekenen met de Piping-kernel (Module uit WBI)
	\item Rekenen met de Macrostabiliteit-kernel (Module uit WBI)
	\item Rekenen met ontgravingen ten behoeve van de beoordeling van NWO\'s
\end{enumerate}

Naast de bovenstaande activiteiten om DAM te herstructureren zal Deltares ook activiteiten uitvoeren om de participatie van de gebruikers te vergroten en te organiseren (website, forum, enz.), communicatie naar een breed (gebruikers-)publiek te verzorgen en de cursus DAM aan te passen aan deze herstructurering.

De genoemde activiteiten worden voorafgaand aan de herstructurering verder uitgewerkt. Daarbij worden expliciet de gebruikers/begeleidingsgroep betrokken bij de verdere uitwerking van de herstructurering. Deze betrokkenheid is ook nodig om afgewogen keuzes te kunnen maken bij de uitwerking en prioritering van de activiteiten en de risicobeheersing tijdens de ontwikkeling. Daarnaast worden de gebruikers/begeleidingsgroep gevraagd om DAM te testen.

Met de beschreven visie is de toekomstrichting bepaald en is een gefaseerde aanpak mogelijk. Uitgangspunt is om het werk zo klein mogelijk te houden, zonder dat toekomstige ontwikkelingen worden geblokkeerd. 

Het eindresultaat van de bovenstaande activiteiten is een release van DAM waarbij 
\begin{itemize}
	\item de software-architectuur, het datamodel en de documentatie zijn vastgelegd en ontsloten (zodat gebruikers hun processen en systemen op DAM kunnen aansluiten); 
\item de DAM-code is geherstructureerd volgens de architectuur, datamodel en documentatie (zodat uitbreiding met nieuwe functionaliteiten en het beheer en onderhoud effici\"enter kunnen worden uitgevoerd);
\item de bestaande GUI van DAM is aangesloten op de rekenfunctionaliteit van DAM (DAM code) zodat de vertrouwende grafische gebruiksomgeving niet veranderd).
\item de bestaande GUI- en rekenfunctionaliteiten zijn losgetrokken (en opnieuw aangesloten op de DAM-code (zodat de bestaande functionaliteiten beschikbaar blijven);
\item de bestaande functionaliteiten voor het toetsen van de regionale waterkeringen zijn aangepast aan de laatste versie van de leidraad en in een aparte module ondergebracht en aangesloten op de DAM-code (zodat de functionaliteiten voor het regionaal toetsen beschikbaar blijven en toekomstigbestendig is voor nieuwe ontwikkelingen, uitbreidingen of aanpassingen).

\end{itemize}

\chapter{Ontwikkelblokken}\label{sec:ontwikkelblokken}
De volgende ontwikkelblokken worden onderscheiden.
De ontwikkelblokken zijn niet geheel even groot wat betreft inspanning.

\section{Minimum viable product} \label{sec:minimumviableproduct}
\begin{itemize}
	\item Toets berekening voor piping (Sellmeijer 4 krachten) over meerdere locaties.
	\item Aansluiten op bestaande UI.
\end{itemize}

\section{Andere faalmechanismen toevoegen} \label{sec:extrafaalmechanisme}
Aantonen dat ander faalmechanismen eenvoudig kunnen worden aangesloten.
\begin{itemize}
	\item Toets berekening voor piping (VNK versie) over meerdere locaties.
	\item Toets berekening voor macrostabiliteit binnenwaarts (D-Geo Stability versie) over meerdere locaties.
	\item Toets berekening voor macrostabiliteit buitenwaarts (D-Geo Stability versie) over meerdere locaties.
	\item Aansluiten op bestaande UI.
\end{itemize}

\section{Ontwerpen} \label{sec:ontwerpen}
Ontwerpen toevoegen voor de relevante faalmechanismen.
\begin{itemize}
	\item Ontwerp berekening voor piping (Sellmeijer 4 krachten) over meerdere locaties.
	\begin{itemize}
		\item Berm toevoegen of groter maken.
	\end{itemize}
	\item Ontwerp berekening voor piping (VNK versie) over meerdere locaties.
	\begin{itemize}
		\item Berm toevoegen of groter maken.
	\end{itemize}
	\item Ontwerp berekening voor macrostabiliteit binnenwaarts (D-Geo Stability versie) over meerdere locaties.
	\begin{itemize}
		\item Dijk verhogen.
		\item Talud verflauwen.
		\item Berm toevoegen of groter maken.
	\end{itemize}
	\item Aansluiten op bestaande UI.
\end{itemize}

\section{Regionale toetsing} \label{sec:regionaletoetsing}
\begin{itemize}
	\item Scenario selectie.
	\item Evenwichtsfactor uitrekenen.
	\item Aansluiten op bestaande UI.
\end{itemize}

\section{WBI faalmechanismen toevoegen} \label{sec:WBIFaalmechanismen}
Nieuwe faalmechanismen aansluiten , die nog in in de huidge DAM zitten.
\begin{itemize}
	\item Toevoegen piping (WBI versie).
	\item Toevoegen macrostabiliteit binnenwaarts (WBI versie).
	\item Aansluiten op bestaande UI.
\end{itemize}


%------------------------------------------------------------------------------
\chapter{Kosten} \label{sec:kosten}

De volgende werkzaamheden zijn voorzien:
\begin{enumerate}

\item Opstellen van de software-architectuur en het datamodel
\item Opstellen van de documentatie en het organiseren van het beheer en ontsluiten daarvan  
\item Herstructureren van de DAM-code
\item Opnieuw aansluiten van de (bestaande) GUI (grafische gebruikersinterface)
\item Opnieuw aansluiten van de bestaande functionaliteiten 
\item Functionaliteit: Regionaal toetsen consistent met de laatste versie van de Leidraad Toets op veiligheid Regionale Waterkeringen (2015).
\end {enumerate}

\section{Opstellen van de software-architectuur en het datamodel}\label{budget_architectuur}
Voordat het plan voor de herstructurering opgesteld kon worden, is eerst een voorstel voor de nieuwe architectuur opgesteld.
Deze kosten zijn reeds gemaakt: 15 kEuro.

\section{Documentatie}\label{budget_documentatie}
De kosten voor het opstellen van de volgende documentatie, exclusief het bijhouden van de documentatie tijdens de sprints, is als volgt begroot:

\begin{table}[h]
	\centering
		\begin{tabular}{lr}
			Visiedocument & 1 kEuro*)\\
			Functioneel ontwerp & 8 kEuro\\
			Technisch ontwerp	&	8 kEuro\\
			Testplan & 4 kEuro\\
			Testdocument & 4 kEuro\\
		\end{tabular}
\end{table}
Het visiedocument wordt door de begeleidingscommissie opgesteld. De begrote kosten betreffen de secretari\"ele werkzaamheden.
Hiermee komt de kosten voor de documentatie op een totaal van 24 kEuro.

\section{Code herstructureren}
Onder de code herstructureren vallen de volgende werkzaamheden:
\begin{itemize}
	\item Herstructureren van de DAM-code
	\item Opnieuw aansluiten van de (bestaande) GUI (grafische gebruikersinterface)
	\item Opnieuw aansluiten van de bestaande functionaliteiten
\end{itemize}

Hiervoor zijn de volgende onwikkelaars zijn beschikbaar:
\begin{itemize}
\item John Bokma: 4 dagen per week, uurtarief 124 euro
\item Tom The: 3 dagen per week, uurtarief 157 euro
\item Esther van Zantvoort: 2 dagen per week, uurtarief 157 euro
\item Irene vd Zwan: 2 dagen per week, uurtarief 124 euro
\end{itemize}
Bij deze tarieven en inzet per week, betekent dat een week ontwikkeling 12.232 euro kost.
Dit betekent, dat als er 12 weken ontwikkeld wordt (4 sprints van 3 weken), het budget belast wordt met 146.784. 

Tijdens de ontwikkelperiode dient een vertegenwoordiger van de begeleidingscommissie bereikbaar te zijn om zaken te bespreken met de product owner en/of het ontwikkelteam. Aanwezigheid van deze persoon heeft de voorkeur, maar zal niet haalbaar zijn gedurende de hele periode.

\section{Regionale toetsing} \label{sec:budget_regionaleToetsing}
Het toevoegen van een module voor toetsen regionale keringen conform nieuwe leidraad dient na de herstructurering plaats te vinden, met een maximale besteding van 35 kEuro.

%------------------------------------------------------------------------------
\chapter{Resultaat} \label{sec:resultaat}

\section{Producten}\label{sec:producten}
Vanuit de software ontwikkeling worden de volgende zogenaamde \'deliverables' opgeleverd:
\begin{itemize}
\item DAM UI client, die aangesloten is op de nieuwe kernel.
\item DAMLive client, die aangesloten is op de nieuwe kernel.
\item Dam kernel, die genoeg functionaliteit biedt om de bovenstaande clients te kunnen bouwen.
\end{itemize}
Hierbij dienen DAM UI en DamLive minimaal de functionaliteit te hebben die beschikbaar is in de release versies van de huidige applicaties (dus zonder de proof of concept opties en mogelijkheden), met uitzondering van de calamiteiten optie in de DAM UI. De calcamiteiten optie zal verwijderd worden.

Daarnaast wordt de volgende documentatie opgeleverd:
	
	\begin{itemize}
		\item Visiedocument
		\item Functioneel ontwerp
		\item Technisch ontwerp
		\item Testplan
		\item Testdocument
\end{itemize}

NB: Gebruikershandleiding blijft ongewijzigd omdat dit de GUI betreft.


\section{Acceptatie}\label{sec:acceptatie}
Voor de acceptatie van de herstructurering worden een drietal resulaten verwacht:
\begin{enumerate}
	\item Gelijke functionaliteit en uitkomsten van DAM 15.2;
	\item DAM is aanspreekbaar via een extern script (bijvoorbeeld Python);
	\item Een andere rekenkernel kan aangesloten worden op de DAM-kernel.
\end{enumerate}

NB: verder invullen na bijeenkomst 15 maart.

%------------------------------------------------------------------------------
\chapter{Planning}\label{sec:planning}

Er moet 1 november (week 43) uitgeleverd worden. Er kan worden begonnen op 20 maart (week 12).
Er is dus een maximale doorlooptijd van 31 weken, waarin 12 weken gepland moeten worden. 

%------------------------------------------------------------------------------
\chapter{Risico's} \label{sec: risicos}

\section{Budget} \label{sec:budget}

\subsection{Risico} 
Het budget is vast. 
En daarvoor moet minimaal de functionaliteit geleverd te worden die aanwezig is in de huidige release.
Als de kernel niet aangepast kan worden binnen het vastgestelde budget, dan is de refactoring niet geslaagd. 
Er is dan geen bruikbaar produkt.

\subsection{Maatregel}
Na eerste sprint evalueren of de ontwikkelsnelheid voldoende is om tot het gewenste eindresultaat te komen. 
Als dat niet het geval is, dan dient de product owner in overleg te treden met het DAM management om een go-nogo beslissing te nemen voor het doorgaan met de ontwikkeling. 

\section{Personele bezetting} \label{sec:personelebezettingrisico}

\subsection{Risico} 
Het ontwikkelteam bestaat uit 3 mensen. Als er 1 wegvalt (ziekte, of prioriteit ander project) dan kan de oplevering in gevaar komen. 

\subsection{Maatregelen}

\begin{itemize}
\item De planning goed doornemen met afdelingshoofden en de geplande weken goed afblokken.
\item De planning zodanig opzetten dat we ruim voor de deadline klaar zijn, medio september.
Dan is er ruimte om tegenvallers op te vangen.
\end{itemize}


%------------------------------------------------------------------------------
\chapter{Referenties}  \label{sec:referenties}

\bibliography{../DAM_references/dam_references}

\pagestyle{empty}
\mbox{}

%------------------------------------------------------------------------------
\end{document}
