Index: doc/trunk/DAM Projectplan/DAM - Projectplan.pdf =================================================================== diff -u -r165 -r167 Binary files differ Index: doc/trunk/DAM Projectplan/DAM - Projectplan.tex =================================================================== diff -u -r165 -r167 --- doc/trunk/DAM Projectplan/DAM - Projectplan.tex (.../DAM - Projectplan.tex) (revision 165) +++ doc/trunk/DAM Projectplan/DAM - Projectplan.tex (.../DAM - Projectplan.tex) (revision 167) @@ -23,7 +23,7 @@ \keywords{Dike, safety assessment, design, software, macro stability, piping} -\references{Refer to \autoref{chapter5}.} +\references{Refer to \autoref{sec:referenties}.} \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.\\ \\ @@ -32,8 +32,8 @@ \versioni{0.2} \datei{Mrt 2017} -\authori{Tom The, Irene van der Zwan} -\revieweri{John Bokma} +\authori{Tom The\newline Irene van der Zwan} +\revieweri{John Bokma \newline Kin Sun Lam} \approvali{Maya Sule} \status{draft} @@ -45,9 +45,10 @@ %------------------------------------------------------------------------------ \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. +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 kon 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, waar door nieuwe uitbreidingen steeds meer inspanning kost en de complexiteit van de code verder wordt vergroot. Het gebruik en de ontwikkeling van DAM is hierdoor niet toekomstbestendig. +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. @@ -71,12 +72,12 @@ \ProgramNamePlusSpace Kernel - Technical documentation \newline \citep{DAMKernel_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{DAMKernel_TestPlan} & Description of the different regression and acceptation tests, including target values. \\ \hline \ProgramNamePlusSpace Kernel - Test Report \newline \citep{DAMKernel_TestReport} & Description of the test results (benchmarks and test scripts). \\ \hline -\ProgramNamePlusSpace UI - Functional Design \newline \citep{DAMUI_FunctionalDesign} & Description of the requirements and functional design. \\ \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 -\ProgramNamePlusSpace UI - User Manual \newline \citep{DAMUI_Manual} & Description of the different functionalites available in the \textit{User Interface} and background information. \\ \hline +\ProgramNamePlusSpace Functional Design \newline \citep{DAMUI_FO} & Description of the different functionalites available in the \textit{User Interface} and background information. \\ \hline \end{tabular} \caption{\small \ProgramNamePlusSpace system documents.} \label{tbl-Documents} @@ -89,36 +90,31 @@ 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 of –taak/-proces. +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 water(veiligheids)sector 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. +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. Deels van de functionaliteiten zijn reeds modules, maar er zijn ook functionaliteiten die nog moeten worden geïsoleerd en herstructureerd tot modules. Door de modulaire opzet is het mogelijk om dit gefaseerd uit te voeren. +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 op 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. +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ënt kan 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 (ondezoeks)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. +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ïteit 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ën 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 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ënt 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. +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ïmplementeerd 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. +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{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.e - - %------------------------------------------------------------------------------ \chapter{Werkzaamheden} \label{sec:werkzaamheden} -Voor de herstructurering van DAM zijn nu globaal de volgende activiteiten voorzien: +Voor de herstructurering van DAM zijn de volgende activiteiten voorzien: \begin{enumerate} \item Opstellen van de software-architectuur en het datamodel @@ -129,19 +125,20 @@ \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} +\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} +\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 functionaliteiten in vast te leggen. En hierover consensus te bereiken bij alle belanghebbenden. Het document zal dus geactualiseerd worden tijdens ontwikkelperiodes van DAM. -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. -Tot slot dient het testen worden vastgelegd in een testplan en testrapporten. Zodat aangetoond wordt dat de functionaliteit en kwaliteit behouden blijft.\newline +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} +\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; @@ -151,22 +148,22 @@ 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} +\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 los van de macrostabilteitskernel plaatsvindt. +\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ënt kunnen worden uitgebreid of aangepast. +\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 + \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. @@ -185,17 +182,17 @@ \end{itemize} -\chapter{Ontwikkelblokken}\label{sec:Ontwikkelblokken} +\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} +\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} +\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. @@ -204,7 +201,7 @@ \item Aansluiten op bestaande UI. \end{itemize} -\section{Ontwerpen} \label{sec:Ontwerpen} +\section{Ontwerpen} \label{sec:ontwerpen} Ontwerpen toevoegen voor de relevante faalmechanismen. \begin{itemize} \item Ontwerp berekening voor piping (Sellmeijer 4 krachten) over meerdere locaties. @@ -224,7 +221,7 @@ \item Aansluiten op bestaande UI. \end{itemize} -\section{Regionale toetsing} \label{sec:RegionaleToetsing} +\section{Regionale toetsing} \label{sec:regionaletoetsing} \begin{itemize} \item Scenario selectie. \item Evenwichtsfactor uitrekenen. @@ -241,56 +238,108 @@ %------------------------------------------------------------------------------ -\chapter{Bemensing en kosten} \label{chapterBemensing} +\chapter{Kosten} \label{sec:kosten} -Er wordt uitgegaan van een budget van 180.000 euro. +De volgende werkzaamheden zijn voorzien: +\begin{enumerate} -De volgende onwikkelaars zijn beschikbaar: +\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. +Dit betekent, dat als er 12 weken ontwikkeld wordt (4 sprints van 3 weken), het budget belast wordt met 146.784. -Uitgaande van een budget van 180.000 euro, betekent dat er voor testen, documentatie en projectbeheer nog 33.216 euro resteert. -Omdat het hier een kernel betreft zal die voornamelijk automatisch getest worden. Het resterende budget zal voldoende zijn voor de bedoelde werkzaamheden. - 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{Deliverables} \label{chapterDeliverables} -Deliverables: +\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 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. -\section{Acceptatie} +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} +\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. -Ook rekening houden met vakanties en inzet in andere projecten is dit dus goed haalbaar. + %------------------------------------------------------------------------------ -\chapter{Risico's} \label{chapterRisicos} +\chapter{Risico's} \label{sec: risicos} -\section{Personele bezetting} \label{sec:PersoneleBezetting} +\section{Budget} \label{sec:budget} -\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. @@ -301,7 +350,7 @@ 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} +\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. @@ -310,13 +359,13 @@ \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. +\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{Literatuur} \label{chapterLiteratuur} +\chapter{Referenties} \label{sec:referenties} \bibliography{../DAM_references/dam_references}