Index: doc/trunk/DAM Projectplan/DAM - Projectplan.tex =================================================================== diff -u -r164 -r165 --- doc/trunk/DAM Projectplan/DAM - Projectplan.tex (.../DAM - Projectplan.tex) (revision 164) +++ doc/trunk/DAM Projectplan/DAM - Projectplan.tex (.../DAM - Projectplan.tex) (revision 165) @@ -1,4 +1,4 @@ -\documentclass[signature]{deltares_report} +\documentclass[signature, dutch]{deltares_report} \usepackage[titletoc]{appendix} \usepackage{lipsum} @@ -13,13 +13,13 @@ \title{\ProgramName} \subtitle{Projectplan} -\projectnumber{1210702-000} +\projectnumber{1221575-000} \client{Deltares - Geo engineering DKS} -\reference{1210702-000-GEO-XXXX} +\reference{1221572-000-GEO-XXXX} \classification{-} -\date{Jan. 2017} -\version{0.1} +\date{Mrt 2017} +\version{0.2} \keywords{Dike, safety assessment, design, software, macro stability, piping} @@ -30,9 +30,9 @@ \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.1} -\datei{Jan 2017} -\authori{Tom The} +\versioni{0.2} +\datei{Mrt 2017} +\authori{Tom The, Irene van der Zwan} \revieweri{John Bokma} \approvali{Maya Sule} @@ -43,13 +43,18 @@ %------------------------------------------------------------------------------ -\chapter{Introductie} \label{chapterIntroductie} +\chapter{Inleiding} \label{sec:Introductie} -\section{Purpose and scope of this document} \label{sec:1.1} +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. -Dit document is het projectplan voor de refactoring van \ProgramName. +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. +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. @@ -60,7 +65,7 @@ %\caption{xxx} %\label{xxx} \begin{tabular}{|p{60mm}|p{80mm}|} \hline -\textbf{Title} & \textbf{Content} \\ \hline +\textbf{Titel} & \textbf{Omschrijving} \\ \hline \ProgramNamePlusSpace - Architecture Overall \newline \citep{DAM_ArchitectureOverall} & Description of overall architecture of \ProgramNamePlusSpace and its components. \\ \hline \ProgramNamePlusSpace Kernel - Technical Design \newline \citep{DAMKernel_TechnicalDesign} & Description of the implementation of the technical design of \ProgramName. \\ \hline \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 @@ -79,9 +84,109 @@ %------------------------------------------------------------------------------ -\chapter{Werkzaamheden} \label{chapterActiviteiten} +\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. -De volgende ontwikkelblokken kunnen worden onderscheiden. +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. + +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. + +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. + +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. + +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. + +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 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. + +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. + +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: +\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} +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 + + +\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 los 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. + +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} @@ -122,7 +227,7 @@ \section{Regionale toetsing} \label{sec:RegionaleToetsing} \begin{itemize} \item Scenario selectie. - \item Schematisatie factor uitrekenen. + \item Evenwichtsfactor uitrekenen. \item Aansluiten op bestaande UI. \end{itemize} @@ -149,11 +254,16 @@ \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. + 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. +%------------------------------------------------------------------------------ + + %------------------------------------------------------------------------------ \chapter{Deliverables} \label{chapterDeliverables} Deliverables: @@ -164,8 +274,12 @@ \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} + + + %------------------------------------------------------------------------------ -\chapter{Planning} \label{chapterPlanning} +\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. @@ -181,7 +295,7 @@ 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 product +Er is dan geen bruikbaar produkt. \subsection{Maatregel} Na eerste sprint evalueren of de ontwikkelsnelheid voldoende is om tot het gewenste eindresultaat te komen. Index: doc/trunk/DAM Projectplan/DAM - Projectplan.pdf =================================================================== diff -u -r164 -r165 Binary files differ