Midterm review WTI2017 cluster software Ringtoets en HydraRing

Midterm review WTI2017 cluster software Ringtoets en HydraRing

Rijkswaterstaat Water, Verkeer en Leefomgeving 4 december 2013 Definitief rapport BC6529-101

HASKONINGDHV NEDERLAND B.V. RIVERS, DELTAS & COASTS

Barbarossastraat 35 Postbus 151 6500 AD Nijmegen +31 (0)24 328 42 84 [email protected] www.royalhaskoningdhv.com Eem-, Gooi- en Flevoland 56515154

Documenttitel

Telefoon E-mail Internet KvK

Midterm review WTI2017 cluster software Ringtoets en HydraRing

Verkorte documenttitel

Review Ringtoets en HydraRing

Status

Definitief rapport

Datum

4 december 2013

Projectnaam

Midterm review WTI2017

Projectnummer

BC6529-101

Opdrachtgever

Rijkswaterstaat Water, Verkeer en Leefomgeving

Referentie

Auteur(s) Collegiale toets Datum/paraaf Vrijgegeven door Datum/paraaf

BC6529-101/R0001/414320/JEBR/Nijm

ir. A.J. Duindam Peter van der Scheer 4 december 2013

.

L.W. van Nieuwenhuijzen MSc. 4 december 2013

A company of Royal HaskoningDHV

INHOUDSOPGAVE

Blz. 1

2

3

INLEIDING 1.1 1.2 METHODE 2.1 2.2 RINGTOETS 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12

Kader en doel Leeswijzer

1 1 2

Ringtoets HydraRing

3 3 4

PMC - projectbewaking en –sturing PP – projectplanning REQM – eisenmanagement PI – productintegratie RD – eisenontwikkeling TS – technische oplossing VAL – validatie VER – verificatie CM – configuratiemanagement MA - meting en analyse PPQA - proces- en productkwaliteitsborging Resultaten op hoofdlijnen

6 6 6 7 7 8 8 9 9 10 10 11 11

4

HYDRARING 4.1 Van requirements naar product 4.1.1 Requirements RWS 4.1.2 Softwareplan 4.1.3 Testfilosofie 4.1.4 Testrapport

13 13 13 13 14 14

5

CONCLUSIES EN AANBEVELINGEN 5.1 Algemeen 5.2 Ringtoets 5.2.1 Projectbewaking en –sturing (PMC) 5.2.2 Projectplanning (PP) 5.2.3 Eisenmanagement (REQM) 5.2.4 Technische oplossing (TS) 5.2.5 Validatie (VAL) 5.2.6 Meting en analyse (MA) 5.2.7 Overige aanbevelingen 5.3 HydraRing 5.3.1 Geclaimde functionaliteit 5.3.2 Juistheid modellering belastingmodellen 5.3.3 Juistheid modellering sterktemodellen 5.3.4 Implementatie foutenbomen 5.3.5 Ringbenadering 5.3.6 Vergelijk PC-Ring

16 16 17 17 17 18 18 18 18 19 19 19 19 20 20 20 20

Review Ringtoets en HydraRing Definitief rapport

-i-

BC6529-101/R0001/414320/JEBR/Nijm 4 december 2013

5.3.7 5.3.8 5.3.9 5.4 6

Mate waarin voldaan is aan de requirements 2013 Aanbevelingen requirements 2014 Overige conclusies en aanbevelingen Discussie

REFERENTIES

21 21 21 22 23

BIJLAGEN 1. Overzicht Requirements en claims 2. Beschrijving CMMI® procesgebieden 3. Toelichting Vaardigheidsniveaus


- ii -


1

INLEIDING De Nederlandse waterkeringen worden sinds 1996 periodiek beoordeeld. Sinds de start van deze toetsingen heeft de automatisering een grote vlucht genomen en is er veel kennis ontwikkeld op het gebied van waterkeringen. De automatisering gaf de mogelijkheid om over te stappen naar meer probabilistische berekeningen van de waterkeringen. Hiervoor is in 2009 het programma Wettelijk Toetsinstrumentarium (WTI2017) opgestart. Het WTI2017 heeft als doel dat waterkeringbeheerders de veiligheid van de waterkeringen nauwkeuriger kunnen toetsen. Rijkswaterstaat (RWS) heeft kennisinstituut Deltares opdracht gegeven de regels en modellen in het WTI te verbeteren. De opdracht omvat de inhoudelijke ontwikkelingen zoals de sterktemechanismen en de belastingen, maar ook de software. De ontwikkeling van het WTI is opgedeeld in 11 clusters waarvan de softwareontwikkeling er één is. Aangezien de software het platform is waarmee de gebruiker het meest te maken heeft en alle kennis door de software aan de gebruiker aangeboden wordt, is een goede werking hiervan essentieel voor het slagen van het WTI2017. RWS stuurt deze opdracht aan op basis van systeem gerichte contractbeheersing (SCB). Rijkswaterstaat Water, Veiligheid en Leefomgeving (RWS WVL) signaleert dat specialistische kennis nodig is voor de beoordeling van de softwareontwikkeling. RWS WVL heeft daarom gevraagd om een review van Ringtoets en HydraRing door Royal HaskoningDHV (RHDHV). Aan de zijde van Rijkswaterstaat is het project begeleid door Deon Slagter (clusterleider software en hydraulica) en Robert Slomp (technisch manager WTI en voormalig clusterleider software). Aan de zijde van Deltares zijn betrokken geweest:  Joost Icke, clusterleider software;  Wim van Balen, projectleider HydraRing;  Kin Sun Lam, projectleider Ringtoets;  Robert Kamp, product owner Ringtoets Deze review is uitgevoerd door Leo van Nieuwenhuijzen en Arie Duindam van RHDHV. Leo van Nieuwenhuijzen heeft de review gedaan van HydraRing. Arie Duindam heeft de review van Ringtoets uitgevoerd.

1.1

Kader en doel De review beoogt inzicht te geven in mogelijkheden om de softwareontwikkeling binnen WTI2017 te verbeteren. Daarvoor is de voortgang beoordeeld in het licht van de requirements van 2013. De inhoudelijke juistheid van de softwareontwikkeling wordt conform SCB geborgd door Deltares op basis van hun eigen kwaliteitssysteem. De conclusies en aanbevelingen uit de review worden bij voorkeur gedragen door de betrokken partijen om gezamenlijk tot verbetering van de contract-requirements 2014 te komen.


BC6529-101/R0001/414320/JEBR/Nijm -1-

4 december 2013

1.2

Leeswijzer Hoofdstuk 2 beschrijft de gehanteerde methodes voor de review. Hoofdstuk 3 gaat in op de bevindingen voor RingToets. Hoofdstuk 4 geeft de bevindingen voor HydraRing. Hoofdstuk 5 vat de conclusies en aanbevelingen samen en sluit af met een discussie.


BC6529-101/R0001/414320/JEBR/Nijm -2-

4 december 2013

2

METHODE Het project bestaat uit twee onderdelen, te weten de beoordeling van het proces van de softwareontwikkeling van RingToets en de beoordeling van het testrapport van HydraRing. Naast controle en verificatie is het doel om te komen tot een verbetering van het proces. Naast de review van de documenten zijn ook twee groepsinterviews met projectleiders van Deltares gehouden. Doel hiervan was het proces beter in beeld te krijgen en te komen tot een gedragen advies.

2.1

Ringtoets De review van Ringtoets is gericht op het proces van softwareontwikkeling. Dit komt naar voren bij de vier concrete vragen die RWS heeft gesteld ten aanzien van Ringtoets: 1. Wordt er gewerkt vanuit een voldoende beschreven en onderbouwde productvisie en startarchitectuur? Wordt voldoende rekening gehouden met onderhoudbaarheid en uitbreidbaarheid?  Deze vraag richt zich op software requirements en ontwerpdocumenten. 2. Wordt er op een slimme en efficiënte wijze geprogrammeerd en ontwikkeld door Deltares? Kan het wellicht slimmer?  Deze vraag richt zich direct op het ontwikkelen van de software. 3. Sluit Ringtoets voldoende aan bij het werkproces van de eindgebruikers, m.a.w. leidt de gekozen ontwikkelstrategie en -methodiek tot een product dat het toetsproces op efficiënte wijze ondersteunt?  Deze vraag richt zich op het requirements management en communicatie. 4. Welke aanbevelingen zijn er ten aanzien van softwareontwikkeling WTI2017 voor de periode 2014-2016?  Deze vraag richt zich op de softwareontwikkeling voor de rest van het project. De reviewers hebben op twee manieren informatie verzameld: 1. studie van de projectdocumentatie [Ref 6.], [Ref 7.], [Ref 8.], [Ref 9.], [Ref 10.][Ref 11.], [Ref 12.]. 2. interviews. Bij de voorbereiding op deze activiteiten en bij het verwerken van de resultaten is vooraf onderzocht of er gebruik zou kunnen worden gemaakt van een formele methodiek voor het softwareproces. Hiervoor is gekeken naar [Ref 13.], [Ref 14.], [Ref 15.], [Ref 16.]. Een formele methodiek heeft een aantal voordelen. Ten eerste kan een formele methodiek gebruikt worden als maatstaf bij het beoordelen van bevindingen. Ten tweede kan er op die manier eenvoudig een logische structuur worden aangebracht in de bevindingen. Ten derde helpt het om voldoende “breedte” aan te brengen in het eigen blikveld, zonder dat er blinde vlekken ontstaan die toevallig niet ter sprake zijn gekomen in de interviews. Er is uiteindelijk voor gekozen om gebruik te maken van een aantal procesbeschrijvingen uit het Capability Maturity Model® Integration (CMMI®) voor Ontwikkeling, Versie 1.3, [Ref 13.]. Het CMMI® bestaat uit ‘best practices’ die op de ontwikkelactiviteiten ingaan en die gelden voor producten en diensten. Het behandelt activiteiten („praktijken”) die de gehele levenscyclus van het product afdekken van conceptie tot en met oplevering en onderhoud. De nadruk ligt op de werkzaamheden die nodig zijn om het totale product te bouwen en te onderhouden. Het CMMI® is allereerst gebruikt voor de definitie van de procesgebieden waar de review zich op richt. Review Ringtoets en HydraRing Definitief rapport

BC6529-101/R0001/414320/JEBR/Nijm -3-

4 december 2013

Binnen CMMI® zijn er in totaal 22 procesgebieden. Deze zijn niet allemaal relevant, dit is afhankelijk van de volwassenheid van de organisatie en de aard van de werkzaamheden. Binnen CMMI® wordt aangegeven voor welke vaardigheidsniveau (0 t/m 5) bepaalde processen van toepassing zijn. In deze review is alleen gekeken naar de procesgebieden tot en met vaardigheidsniveau 2, aangevuld met engineering processen tot en met niveau 3. Dit zijn er in totaal 11: Basis projectmanagement procesgebieden (niveau 2):  Projectbewaking en –sturing (PMC);  Projectplanning (PP);  Eisenmanagement (REQM);  Management van leveranciersovereenkomsten (SAM). Engineering procesgebieden (niveau 3):  Productintegratie (PI);  Eisenontwikkeling (RD);  Technische Oplossing (TS);  Validatie (VAL);  Verificatie (VER). Basis ondersteunende procesgebieden (niveau 2):  Configuratiemanagement (CM);  Meting en Analyse (MA);  Proces- en Productkwaliteitsborging (PPQA). Een beschrijving van deze procesgebieden wordt gegeven in Bijlage 2. Een beschrijving van de vaardigheidsniveaus wordt gegeven in Bijlage 3. Bij het doornemen van de projectdocumentatie voorafgaand aan de interviews zijn deze procesgebieden gebruikt als “bril” om te kijken waar de focus en aandacht van het project nu naar toe gaat en waar mogelijk ruimte is voor verbeteringen, omdat een bepaald procesgebied onvoldoende aandacht krijgt. Na de interviews zijn de procesgebieden opnieuw gebruikt, ditmaal om de nog ongeordende bevindingen te kunnen groeperen per logisch proces, en tevens om de eerdere constatering van compleetheid bij te stellen. Dit levert uiteindelijk een resultaat per procesgebied, waar de aanbevelingen en concrete vragen van RWS van kunnen worden afgeleid. Uiteindelijk gaat het hier niet om direct een procesverbeteringstraject uit te voeren (de primaire doelstelling van CMMI®), maar om concreet voor Ringtoets te kunnen ontdekken waar mogelijke verbeteringen in het project doorgevoerd zouden kunnen worden.

2.2

HydraRing Voor HydraRing is gevraagd een verificatie te doen van de claims die Deltares maakt in het testrapport, Validation document [Ref 5.]. De review is daarbij gericht op de voortgang. De review beoogt op basis van de claims inzicht te krijgen in


BC6529-101/R0001/414320/JEBR/Nijm -4-

4 december 2013

De volgende vragen zijn door Rijkswaterstaat gevraagd te beantwoorden over HydraRing: 1. Is de door Deltares geclaimde functionaliteit behaald? 2. Zijn de belastingmodellen juist gemodelleerd? 3. Zijn de sterktemodellen juist gemodelleerd? 4. Zijn de foutenbomen van faalmechanismen juist ingebouwd? 5. Is de ringbenadering op de juiste manier ingebouwd? 6. Kan het prototype als een nagebouwd PC-Ring gezien worden? 7. In hoeverre is aan de requirements voldaan? 8. Gegeven de deadline van 2016 voor het WTI, welke aanbevelingen kunt u doen ten aanzien van de requirements 2014 In essentie zijn de vragen: 1. Kloppen de claims van Deltares zoals in het testrapport? 2. Voldoet de HydraRing eind 2013 aan de requirements? 3. Welke requirements zijn nodig voor 2014 om WTI2017 tijdig gereed te hebben? Voor de uitvoering is gebruik gemaakt van het testrapport, aangevuld met informatie uit interviews. Vanwege de omvang van het testrapport is ten eerste een overzicht van de claims opgezet, zie Bijlage 1. Hiervoor diende ook steekproefsgewijs de onderbouwing in de achterliggende hoofdstukken gereviewd te worden voor een beter begrip.


BC6529-101/R0001/414320/JEBR/Nijm -5-

4 december 2013

3

RINGTOETS Voor Ringtoets zijn op basis van het bestuderen van de documenten en de interviews per procesgebied de volgende resultaten gemeten.

3.1

PMC - projectbewaking en –sturing De bedoeling van „Projectbewaking en –sturing” is inzicht te verschaffen in de voortgang van het project zodat passende corrigerende maatregelen genomen kunnen worden als de projectprestaties in belangrijke mate afwijken van het plan. Wat is het algemene

x incompleet

toelichting: Er is wel een projectplan, maar dit is vooral een

vaardigheidsniveau van dit

□ uitgevoerd

technisch inhoudelijk plan dat geen goede overkoepelende

procesgebied?

□ beheerst

begroting en sturing bevat. Er is vanuit RWS weinig zicht op

□ gedefinieerd

de relatie tussen budget, planning en voortgang. Inhoudelijk hinkt de sturing op twee gedachten: sturen op realisatie van use cases of sturen op aantal en diepgang van de faalmechanismen.

Wie voert dit procesgebied

□ vooral RWS

toelichting: Hoewel de overall sturing uiteraard bij RWS ligt,

uit?

x vooral Deltares

vindt de operationele en tactische sturing toch vooral plaats

□ een derde partij

door Deltares. Dit heeft ook te maken met de verhouding tussen inspanning bij Deltares (groot team) en RWS (1 dag per week betrokken).

Overige opmerkingen

Bewaking en sturing van de planning op jaarbasis in de systematiek van de sprints is goed geborgd bij Deltares, daar zit geen belemmering. Dit zou ook een goed aanknopingspunt kunnen zijn om meer grip te krijgen over het gehele proces vanuit RWS.

3.2

PP – projectplanning De bedoeling van “Projectplanning” is plannen opstellen en bij te houden die de projectactiviteiten definiëren. Wat is het algemene

□ incompleet

toelichting: Bij Deltares vindt een gedegen planning plaats


x uitgevoerd

rond de sprint cycli in relatie tot het jaarplan. Het is alleen

procesgebied?

□ beheerst

wel vooral de planning van Deltares. De interactie met RWS

□ gedefinieerd

en toekomstige gebruikers is onderbelicht, wat een risico voor het commitment is.


□ vooral RWS

toelichting: Net als bij de sturing (PMC) is het ook in dit

uit?

x vooral Deltares

procesgebied zo dat de overkoepelende planning formeel bij


RWS ligt, maar de planning per jaar en per sprint vooral van Deltares afkomstig zijn. Daarmee ligt ook de nadruk bij de dynamiek in de planning, bijvoorbeeld wijzigingen in scope en volgorde van implementatie, onevenredig bij Deltares.

Overige opmerkingen

De planning hinkt nu op twee gedachten: used cases realiseren of sturen op implementatie van faalmechanismen. Door een duidelijke keus te maken voor de overkoepelende planning kan een eenvoudiger sturing en communicatie naar toekomstige gebruikers worden gerealiseerd.


BC6529-101/R0001/414320/JEBR/Nijm -6-

4 december 2013

3.3

REQM – eisenmanagement De bedoeling van „Eisenmanagement” is de eisen voor de producten en productcomponenten van het project te managen en te zorgen dat deze eisen en de projectplannen en werkproducten op elkaar afgestemd zijn. Wat is het algemene

x incompleet

toelichting: Er vindt wel eisenmanagement plaats, maar dit is


□ uitgevoerd

versnipperd. Er is een duidelijk pakket aan functionele en

procesgebied?

□ beheerst

niet-functionele eisen vastgelegd. Dit wordt echter niet actief

□ gedefinieerd

gebruikt, omdat er vanuit gegaan is dat deze eisen zijn meegenomen in de vertaling naar de use cases. Maar het is niet duidelijk welke use cases welke eisen implementeren en hoe daar op getest wordt. Verder staat het inhoudelijk eisenmanagement vanuit de faalmechanismen feitelijk los van de overige functionele documentatie.


□ vooral RWS

toelichting: Het ligt voor de hand dat dit proces vooral door

uit?

x vooral Deltares

Deltares wordt uitgevoerd. Maar hierdoor valt de inbreng van


eisen vanuit RWS en toekomstige eindgebruikers een beetje tussen wal en schip. Zo zijn er vanuit de rijksoverheid ontwikkelingen met betrekking tot referentiearchitecturen en het verplicht gebruik van open standaarden. Dit zijn feitelijk eisen vanuit RWS, maar deze worden niet afgestemd met de overige eisen.

Overige opmerkingen

Het is onduidelijk wat de status is van eisen die geen “must” zijn, en wat de relatie tussen deze eisen en de projectsturing is.

3.4

PI – productintegratie De bedoeling van “Productintegratie” is het product samen te stellen uit de productcomponenten, te zorgen dat het product, zoals het is samengesteld, correct werkt (dat wil zeggen: de vereiste functionaliteit en kwaliteitskenmerken bezit) en het product op te leveren. Wat is het algemene

□ incompleet

toelichting: Dit proces verloopt goed door de keus voor


□ uitgevoerd

duidelijke cycli voorbereiding-sprint-nazorg.

procesgebied?

x beheerst □ gedefinieerd


□ vooral RWS

toelichting: Dit is een kerntaak van het ontwikkelteam bij

uit?

x vooral Deltares

Deltares. Het ligt dan ook voor de hand dat dit door Deltares


wordt uitgevoerd. Dit is conform SCB.

Overige opmerkingen

Geen.


BC6529-101/R0001/414320/JEBR/Nijm -7-

4 december 2013

3.5

RD – eisenontwikkeling De bedoeling van „Eisenontwikkeling” is het ontdekken, analyseren en uitwerken van klant-, producten productcomponenteisen. Wat is het algemene

□ incompleet

toelichting: Dit proces is voor het algemene raamwerk van


x uitgevoerd

Ringtoets eigenlijk al goeddeels beëindigd op dit moment,

procesgebied?

□ beheerst

doordat eisen zijn vastgelegd in documentatie.

□ gedefinieerd

Eisenontwikkeling met betrekking tot de inhoudelijke faalmechanismen van Hydraring vindt echter nog voortdurend plaats.


□ vooral RWS

toelichting: RWS speelt in dit proces een bijrol. Dit heeft tot

uit?

x vooral Deltares

gevolg dat de inbreng van de interne klant bij het ministerie


maar zeer beperkt wordt ingebracht. Dit is conform SCB

Overige opmerkingen

De eisen met betrekking tot de technische architectuur zijn wat onderbelicht in de communicatie. Naar verwachting speelt dit echter geen grote rol bij het resterende project. Er is weinig zicht op ondersteunde versies van het besturingssysteem, gebruik van ‘client frameworks’ en de toekomstige ontwikkeling hier in.

3.6

TS – technische oplossing De bedoeling van „Technische Oplossing” (TS) is, voor de eisen oplossingen te selecteren, te ontwerpen, en te realiseren. De oplossingen, ontwerpen en realisaties hebben, afhankelijk van de situatie, betrekking op producten, productcomponenten en aan de levenscyclus van het product gerelateerde processen, of een combinatie hiervan. Wat is het algemene

□ incompleet

toelichting: De speciale technische inbreng vanuit de


x uitgevoerd

wetenschappelijke discipline maakt dit project bijzonder.

procesgebied?

□ beheerst

Deltares gaat daar technisch goed mee om, hoewel het

□ gedefinieerd

mechanisme van aanlevering en aansluiting van modellen in de uiteindelijke applicatie niet heel expliciet beschreven is. Met betrekking tot dit procesgebied is er speciale aandacht nodig voor interne Deltares processen, in de zin dat het team deels afhankelijk is van de levering van werkproducten door de wetenschappelijke medewerkers. De tijdigheid en kwaliteit van deze leveringen is soms een uitdaging die zijn weerslag kan krijgen in de totale planning van het project.


□ vooral RWS

uit?

x vooral Deltares

toelichting: Dit is een kerntaak van Deltares.

□ een derde partij Overige opmerkingen

Let op: er is discrepantie tussen Shape files versus Open Standaarden. Let op: er is dynamiek met betrekking tot IRIS.


BC6529-101/R0001/414320/JEBR/Nijm -8-

4 december 2013

3.7

VAL – validatie De bedoeling van “Validatie” is aan te tonen dat een product of productcomponent kan worden gebruikt zoals is bedoeld wanneer het in zijn beoogde omgeving is geplaatst. Wat is het algemene

x incompleet

toelichting: Er is veel en gedegen focus op verificatie, maar


□ uitgevoerd

niet op validatie. Er is weinig inbreng vanuit een senior user

procesgebied?

□ beheerst

rol.

□ gedefinieerd Wie voert dit procesgebied

□ vooral RWS

toelichting: Er ontbreekt in het project een duidelijke senior

uit?

x vooral Deltares

user rol. Deze wordt nu de facto ingevuld door Deltares, die


ook supplier is. Bij RWS is wel een algemeen eindbeeld aanwezig, maar dat is niet uitgewerkt en speelt geen grote rol in het testtraject. Maar daarmee raakt de vraag of het juiste product voor de eindgebruikers wordt gebouwd onderbelicht in het project.

Overige opmerkingen

Een sterkere iteratieve oplevering van werkende software (die meer bij Scrum past) kan dit proces versterken, omdat RWS en waterschappen zich dan eerder een concreet beeld kunnen vormen van de Ringtoets applicatie in ontwikkeling.

3.8

VER – verificatie De bedoeling van „Verificatie” (VER) is om te garanderen dat geselecteerde werkproducten voldoen aan hun gespecificeerde eisen. Wat is het algemene

□ incompleet

toelichting: Dit is een kernactiviteit voor Hydraring. Hydraring


□ uitgevoerd

wordt aangestuurd vanuit Ringtoets. De verificatie wordt op

procesgebied?

□ beheerst

een hoog niveau uitgevoerd.

x gedefinieerd Wie voert dit procesgebied

□ vooral RWS

toelichting: de wetenschappelijke toetsing van

uit?

x vooral Deltares

modelresultaten is een kernelement van Deltares in het


project. Niemand kan dat beter dan Deltares zelf. In de beeldvorming kan dit wel een risico zijn: keurt de slager hier zijn eigen vlees?

Overige opmerkingen

Vanwege het fundamentele belang worden verdere bevindingen van dit proces in een separaat hoofdstuk behandeld.


BC6529-101/R0001/414320/JEBR/Nijm -9-

4 december 2013

3.9

CM – configuratiemanagement De bedoeling van „Configuratiemanagement” is de integriteit van werkproducten vast te stellen en te handhaven door middel van configuratie-identificatie, configuratiebeheer, het administreren van de configuratiestatus en configuratie-audits. Wat is het algemene

□ incompleet

toelichting: Uit het interview blijkt een beheerste situatie met


□ uitgevoerd

betrekking tot dit proces. Ook de meeste documenten zijn

procesgebied?

x beheerst

onder versiebeheer gebracht. Er wordt professioneel

□ gedefinieerd

gewerkt in het software proces. Verder is dit geen groot issue.


□ vooral RWS

uit?

x vooral Deltares

toelichting: Dit ligt ook voor de hand.

□ een derde partij Overige opmerkingen

3.10

Geen.

MA - meting en analyse De bedoeling van „Meting en Analyse” is een vermogen tot meten te ontwikkelen en te handhaven, dat gebruikt wordt om te voorzien in de behoefte aan managementinformatie. Wat is het algemene

x incompleet

toelichting: Naar de aard van dit project wordt er uiteraard


□ uitgevoerd

van alles gemeten en geanalyseerd, vooral rond verificatie

procesgebied?

□ beheerst

van modelresultaten. Verder wordt er in de sprints ook heel

□ gedefinieerd

gedetailleerd voortgang gemeten op dagelijkse basis. Er wordt echter te weinig geaggregeerd, waardoor en toch onvoldoende management informatie is voor RWS. Dit blijkt onder andere uit de vragen die RWS heeft gesteld aan de reviewers.


□ vooral RWS

toelichting: Vooral Deltares doet dit nu, of zou dit moeten

uit?

x vooral Deltares

doen, maar er is meer sturing nodig vanuit RWS. Wat heeft


RWS nodig om overkoepelend te kunnen sturen? Dit ontbreekt vrijwel geheel.

Overige opmerkingen

Er is een opvallende discrepantie tussen de volwassenheid van de meting en analyse op detailniveau in de sprints (met Jira) en de schijnbaar bijna totale afwezigheid van sturingsinformatie op management niveau dat bij RWS aanwezig is.


BC6529-101/R0001/414320/JEBR/Nijm - 10 -

4 december 2013

3.11

PPQA - proces- en productkwaliteitsborging De bedoeling van „Proces- en Productkwaliteitsborging” is zowel medewerkers als management objectief inzicht te verschaffen in processen en daaraan gerelateerde werkproducten. Wat is het algemene

□ incompleet

toelichting: Dit proces vindt met name plaats rond de

vaardigheidsniveau van

x uitgevoerd

inhoudelijke thematiek van het project. Er is wel een

dit procesgebied?

□ beheerst

duidelijke discrepantie tussen de (inhoudelijke)

□ gedefinieerd

productkwaliteitsborging en de (projectmatige) proceskwaliteitsborging. In algemene zin kan worden gezegd dat hier wel aandacht voor is, maar niet op een structurele manier.

Wie voert dit

□ vooral RWS

toelichting: Omdat RWS zelf weinig inhoudelijke

procesgebied uit?

x vooral Deltares

kwaliteitsborging doet, is er een mogelijk issue met de


onafhankelijkheid. Wellicht dat om die reden ook gekozen is voor een midterm review door een onafhankelijke partij.

Overige opmerkingen

3.12

Geen.

Resultaten op hoofdlijnen Aan de hand van de bovenstaande resultaten kan per procesgebied naast het vaardigheidsniveau een globale inschatting worden gemaakt van het totale projectrisico voor dit procesgebied: in hoeverre draagt het procesgebied bij aan de slaag- en faalkansen van het project als geheel. Vervolgens kan het huidige vaardigheidsniveau worden afgezet tegen dit risico. Niet alle procesgebieden hoeven op het hoogste niveau te worden uitgevoerd, vaak is dit zelfs onwenselijk, want: te duur en te star. De effectiviteit van een verhoging van het vaardigheidsniveau is een functie van het huidige vaardigheidsniveau en het risico dat het project loopt ten gevolge van dit procesgebied, als volgt: Effectiviteit bij verbetering als functie van projectrisico en vaardigheidsniveau Vaardigheidsniveau huidige situatie Risico

0: incompleet

1: uitgevoerd

2: beheerst

3: gedefinieerd

laag

klein effect

klein effect

klein effect

klein effect

middel

groot effect

middel effect

klein effect

klein effect

hoog

groot effect

groot effect

middel effect

klein effect

De resultaten per procesgebied kunnen nu als volgt worden weergegeven: proces

huidig niveau

projectrisico

Effect bij verbetering

projectbewaking en –sturing

0: incompleet

hoog

groot

projectplanning

1: uitgevoerd

hoog

groot

eisenmanagement

0: incompleet

middel

groot

productintegratie

2: beheerst

laag

klein

eisenontwikkeling

1: uitgevoerd

laag

klein

technische oplossing

1: uitgevoerd

hoog

groot

validatie

0: incompleet

middel

groot


BC6529-101/R0001/414320/JEBR/Nijm - 11 -

4 december 2013

proces

huidig niveau

projectrisico

Effect bij verbetering

verificatie

3: gedefinieerd

middel

klein

configuratiemanagement

2: beheerst

laag

klein

meting en analyse

0: incompleet

middel

groot

proces- en productkwaliteitsborging

1: uitgevoerd

middel

middel

De procesgebieden waar een verbetering een mogelijk groot effect heeft, zijn vetgedrukt. Bij de conclusies en aanbevelingen zal vooral worden in gegaan op deze procesgebieden.


BC6529-101/R0001/414320/JEBR/Nijm - 12 -

4 december 2013

4

HYDRARING In Bijlage 1 is een overzicht gegeven van:  eisen aan de faalmechanismen op basis van de Requirements van RWS [Ref 6.];  voorgestelde functionaliteit op basis van het softwareplan [Ref 7.];  de claims in het testrapport [Ref 5.] Voor de belastingmodellen en de overslagmodule is in de bijlage een aparte tabel opgezet.

4.1

Van requirements naar product Om te komen tot een vergelijk tussen requirements en resultaat is in eerste instantie nagegaan wat de requirements waren en met welke stappen tot het testrapport is gekomen. De tussentijdse wijzigingen zijn door Deltares en RWS afgestemd in overleg en bijgehouden. Voor een overzichtelijk vergelijk zijn per faalmechanisme de requirements, specificaties en testen naast elkaar gezet, zie Bijlage 1, om beter inzicht te krijgen in:  volledigheid;  gehanteerde criteria;  opmerkingen en verbeterpunten.

4.1.1

Requirements RWS De eerste bron voor de requirements is de Product requirements van RWS [Ref 6.]. Deze zijn op hoofdlijnen geformuleerd en schrijven vooral voor dat eind 2013. Voor 2013 is aangegeven dat 9 faalmechanismen aangesloten zijn voor faalkansberekeningen. De mechanismen worden alleen bij naam genoemd zonder verdere duiding van de onderdelen of rekenmethoden. De Use Cases zijn daarbij de basis voor de werkzaamheden. RWS schrijft tevens voor dat een testplan opgesteld dient te worden met acceptatietesten aan rekenresultaten. In het testverslag dient aangegeven te worden hoe de rekenresultaten zich verhouden tot de eisen. Deze eisen zijn in het document zelf niet toegelicht. Aanvullend op deze notitie is een notitie geschreven “Acceptatiecriteria producten voor TOI” [Ref 2.]. Welke mede is verwerkt in de testfilosofie.

4.1.2

Softwareplan De volgende stap is geweest de specificaties zoals uitgewerkt in het Softwareplan 2013 door Deltares [Ref 7.]. Deze specificaties zijn een detaillering van de productrequirements van RWS. Hierbij is per faalmechanisme aangegeven tot welke niveau implementatie haalbaar is en welke methode wordt geïmplementeerd, bijvoorbeeld Bishop en Uplift Van. Vanwege budgettaire redenen is besloten een aantal onderdelen door te schuiven naar 2014 ten opzichte van de eerdere planning. Dit betreft de faalmechanismen voor bekleding.


BC6529-101/R0001/414320/JEBR/Nijm - 13 -

4 december 2013

4.1.3

Testfilosofie Voor het testen is door drie auteurs een voorstel gedaan. Deze voorstellen zijn gecombineerd in één document met de testfilosofie [Ref 1.]. De testfilosofie gaat uit van testen op vier niveaus:  Acceptatietesten ter beoordeling van de specificaties. Dit betekent dat de testen antwoord geven of de software voldoet als wettelijk toetsinstrumentarium;  Systeemtesten ter beoordeling van de werking van het systeem. Hiervoor is een groot aantal locaties doorgerekend met de module voor een faalmechanisme;  Integratietesten ter beoordeling van het subsysteem. Deze testen geven aan of de modules samen goed functioneren en of de subsystemen van een module tot een goede uitkomst voor het faalmechanisme leiden;  Unit testen ter controle van de functionaliteit van subsystemen. In de uitwerking van de testfilosofie [Ref 1.] is een procesvoorstel opgenomen om te werken aan de hand van claims, welke verifieerbaar zijn door een derde partij. Bovendien is aangegeven dat acceptatietesten door de opdrachtgever uitgevoerd dienen te worden. De andere testen kunnen en zijn uitgevoerd worden door Deltares. Deze zijn gerapporteerd in het testrapport [Ref 5.]

4.1.4

Testrapport In het testrapport zijn de unit-, integratie- en systeemtesten gerapporteerd. De testen in de rapportage zijn als volgt onderverdeeld:  Statistiek  Faalmechanismen: Overloop, piping bij dijken, macrostabiliteit, etc.  Systeemtesten  Tijdintegratiescenario’s Per faalmechanisme is de onderverdeling als volgt:  Integratietest, bestaande uit een test op basis van een locatie:  designpoint check met een Z-functie;  vergelijk met PC-Ring;  Systeemtest door:  berekening van meerdere locaties en:  test van combinatie van sub-mechanismen indien relevant; Op basis van de testen zijn door Deltares claims gemaakt per faalmechanisme en watersysteem. De claims van Deltares zijn uitgebreid beschreven en zoveel mogelijk specifiek gemaakt. Eventuele afwijkingen zijn door Deltares overal onderzocht en zo mogelijk verklaard. Uit enkele van de claims volgt dat nader onderzoek of aanpassing van de software nodig is.


BC6529-101/R0001/414320/JEBR/Nijm - 14 -

4 december 2013

De claims in het testplan tonen aan:  Deltares heeft alle watersystemen en de voorgeschreven faalmechanismen in HydraRing geïmplementeerd. De belastingmodellen voor de kust (m.u.v. IJmuiden) en het Schelde-estuarium functioneren goed. De belastingmodellen functioneren slecht voor de meren en benedenrivieren (Rijn en IJssel/Vecht). De oorzaken zijn: het sluitcriterium van de Maeslandtkering, circular failure space door FORM, toepassing van blokiteraties voor windsnelheden. Het sluitcriterium is daarvan een majeur probleem. De andere twee problemen kunnen worden opgelost door toepassing van DS in plaats van FORM. Het overzicht van de juistheid per watersysteem is weergegeven in Bijlage 1.  Op het niveau van integratietesten wordt middels de Z-functie aangetoond dat de werking van de modules juist is, losstaand van een vergelijking met PC-Ring of Hydra’s. Geconcludeerd wordt dat de onderdelen van de sterktemodellen juist geïmplementeerd zijn;  De implementatie van een groot aantal componenten levert resultaten die overeenkomen met PC-Ring. De integratie van die subsystemen functioneert ook naar behoren volgens de claims. Geconcludeerd wordt dat de modules per faalmechanismen correct werken. De foutenbomen zijn juist geïmplementeerd;  Resultaat is dat de hele trein van basisstatistiek tot aan uitvoer getest is op unit-, subsysteem- en systeemniveau.


BC6529-101/R0001/414320/JEBR/Nijm - 15 -

4 december 2013

5

CONCLUSIES EN AANBEVELINGEN

5.1

Algemeen De voorliggende review is uitgevoerd door een onafhankelijk team dat vooraf niet of nauwelijks direct betrokken is geweest bij het project. Dit heeft als nadeel dat er wellicht weinig of te weinig inhoudelijke kennis bij het reviewteam aanwezig is geweest om het project op details te beoordelen. Het heeft echter als grote voordeel dat er frisse blik in de keuken van het project is geworpen, zonder a priori aannames of enige vooringenomenheid. Daarmee is de eerste professionele indruk een belangrijke graadmeter, los van alle inhoudelijk verder onderbouwde bevindingen tijdens de review zelf. Deze eerste indruk is als volgt. 1. De reviewers zijn van mening dat het project alle potentie heeft om succesvol te zijn. De reviewers hebben zowel bij RWS als bij Deltares een betrokken en gecommitteerd projectteam aangetroffen bij een beheerst project. 2. De reviewers hebben bij RWS een situatie aangetroffen die op een tekort aan middelen wijst om de noodzakelijke rol van opdrachtgever in de volle breedte te kunnen spelen passend binnen de SCB contractvorm. De aansturing door RWS en projectmanagement door Deltares sluiten nog onvoldoende aan. 3. Bij de meeste projecten zit het venijn in de staart. Bij dit project lijkt daar zelfs met een verhoogde kans sprake van te zijn. De reviewers hebben bij Deltares een situatie aangetroffen van een project onder druk van tijd en afhankelijkheden. Een goed en gezamenlijk management in de slotfase van het project (kalenderjaren 2014 en 2015) is daarbij cruciaal. RWS heeft de voorliggende review geïnitieerd om het project te versterken. Dat is het uitgangspunt geweest bij het formuleren van de meer gedetailleerde conclusies en aanbevelingen. Niet alle aanbevelingen zullen even relevant blijken. Dit heeft te maken met de onafhankelijkheid en daardoor relatieve afstand van de reviewers. Er is echter een consistent beeld naar voren gekomen waar de knelpunten in het project zitten. De rest van dit hoofdstuk richt zich hier direct op. De diepgang en uitgebreidheid van het eindproduct in 2016 is nog niet concreet. Dit geeft onduidelijkheid bij opdrachtnemer (Deltares) en opdrachtgever (RWS). Door verwachtingen concreter en tijdsgebonden te maken, zoals hiervoor genoemd, kan dan concreter gediscussieerd worden over prioritering. In de uitwerking van het eindbeeld dient ook rekening gehouden te worden met het beheer en onderhoud van HydraRing en RingToets. Wanneer een onvolledig of beperkt instrumentarium wordt opgeleverd moet rekening gehouden worden met updates of aanpassingen. Aanbevolen wordt een beheervisie te formuleren, aansluitend op de uitwerking van het eindbeeld. Het werken met jaarbudgetten heeft er afgelopen jaar toe geleid dat de implementatie van enkele modules vooruit is geschoven en de pot onvoorzien is geschrapt. Het doorschuiven betekent echter dat deze implementatie meer op het kritieke pad komt en dit gelijk een claim legt op het budget voor volgend jaar. Aangezien de eindoplevering in zicht komt is het noodzakelijk een meerjarenplanning richting het eindproduct op te stellen.


BC6529-101/R0001/414320/JEBR/Nijm - 16 -

4 december 2013

5.2

Ringtoets Het advies is om in elk geval de volgende procesgebieden te versterken:  projectbewaking en –sturing (PMC);  projectplanning (PP);  eisenmanagement (REQM);  technische oplossing (TS);  validatie (VAL);  meting en analyse (MA). Deze procesgebieden kennen een hoog risico in relatie tot het vaardigheidsniveau. Ook bij de overige procesgebieden zijn verbeteringen mogelijk. Deze worden onderaan deze paragraaf opgesomd. Bij de voornoemde procesgebieden waar de focus voor versterking op zou kunnen liggen, zijn de aanbevelingen per procesgebied gegeven. Deze aanbevelingen zijn voor de leesbaarheid in de gebiedende wijs opgeschreven. Het zijn uiteraard echter adviezen die door het project team zelf in vrijheid op waarde kunnen worden geschat. De aanbevelingen zijn als volgt.

5.2.1

Projectbewaking en –sturing (PMC) Versterk de rol van RWS als opdrachtgever. Op dit moment wordt het opdrachtgeverschap ingevuld met 0,2 FTE. Dat lijkt te weinig voor een volwaardige rol, zeker nu er een cruciale eindfase van het project in zicht komt. Het gaat erom dat RWS gelijkwaardig kan worden met Deltares door beter grip te krijgen op de sturingsdriehoek tijd, geld, functionaliteit. De invulling van het opdrachtgeverschap vergt meer inzet ook binnen SCB. Dit is ook een direct belang van Deltares, die nu noodzakelijkerwijs veel tactische beslissingen zelf nemen zonder de klant daar echt in mee te nemen. Dit levert risico’s op voor de acceptatie, beeldvorming en de verwachtingen bij de opdrachtgever, die de belangrijkste ambassadeur kan zijn voor het eindproduct. Verder is een sterke opdrachtgever van belang bij het beheersen van interne processen binnen het ministerie. Wat gebeurt er als deadlines niet worden gehaald? Hoe reageert RWS als het product op een aantal faalmechanismen slechts een rudimentaire implementatie kent? Wat als er meer middelen nodig zijn? Voor al deze zaken is het van belang om tijdig en proactief in verbinding te zijn. Bewaking en sturing van de planning op jaarbasis in de systematiek van de sprints is goed geborgd bij Deltares. Dit is een concreet aanknopingspunt om meer grip te krijgen over het gehele proces vanuit RWS.

5.2.2

Projectplanning (PP) Versterk de gezamenlijke sturing op een overkoepelende planning voor de rest van het project. Om dit concreet te realiseren kan er bijvoorbeeld een betere koppeling worden gemaakt tussen de overkoepelende WTI planning en de cyclische planning per kalenderjaar en sprint. Hierdoor kan er dan beter gestuurd worden op het eindresultaat, waarbij ook de tussentijdse resultaten beter meetbaar worden gemaakt. Maak RWS verantwoordelijk voor deze overkoepelende planning, zodat ook op dit procesgebied een gelijkwaardiger verhouding ontstaat. De planning hinkt nu op twee gedachten: use cases realiseren of sturen op implementatie van faalmechanismen. Door een duidelijke keus te maken voor de overkoepelende planning kan een eenvoudiger sturing en communicatie naar toekomstige gebruikers worden gerealiseerd.


BC6529-101/R0001/414320/JEBR/Nijm - 17 -

4 december 2013

5.2.3

Eisenmanagement (REQM) Uniformeer requirements door te kiezen waar op gestuurd gaat worden gedurende de rest van het project. Op dit moment vindt de sturing plaats in verschillende discrete pakketten; functioneel/niet-functioneel, use cases en faalmechanismen. Breng daar meer samenhang in. Maak duidelijk wat de status is van eisen die geen “must” zijn, en wat de relatie tussen deze eisen en de projectsturing is. Communiceer helder over de voortgang op basis van de gekozen systematiek. De Scrum aanpak met sprints leent zich hier bij uitstek voor. Zorg er voor dat iedere sprint een echte productie-kwaliteit applicatie oplevert. Ook al zitten daar bijvoorbeeld minder faalmechanismen in dan verwacht, dat wordt dat in elk geval zichtbaar voor alle betrokkenen, met alle voordelen van dien.

5.2.4

Technische oplossing (TS) Zorg binnen en buiten de eigen organisatie voor meer zichtbaarheid van de directe relatie die er ligt tussen de tijdige en juiste wetenschappelijke inbreng en de kwaliteit en tijdigheid van het eindproduct. Daarmee komt er ook meer zicht op de complexiteit van Ringtoets en wellicht meer draagvlak bij vertraging ten gevolge van interne vertragingen of budgetoverschrijdingen. Dit punt heeft een relatie met de aanbevelingen bij projectbewaking en –sturing (PMC), projectplanning (PP) en meting en analyse (MA) en is alleen in die zin al van belang.

5.2.5

Validatie (VAL) Versterk de invulling van de senior user rol in het project, met name met betrekking tot het beantwoorden van de vraag bij het testen: is dit de applicatie die we willen en kunnen gebruiken? Dit vergt een grotere betrokkenheid van eindgebruikers. Ook hier kan een meer geprofileerde iteratieve incrementele oplevering van werkende software dit proces versterken, omdat RWS en waterschappen zich dan eerder en vaker een concreet beeld kunnen vormen van de applicatie die in ontwikkeling is.

5.2.6

Meting en analyse (MA) Start een sturingsmechanisme op basis van gezamenlijke management informatie. Een gezamenlijk “dashboard” voor de monitoring van het project op hoofdlijnen kan daarbij een hulpmiddel zijn. Bij deze sturing moet aandacht zijn voor de overkoepelende planning, de detailplanning, de wetenschappelijke planning, de eisenontwikkeling, geld, tijd en risico’s. Er is een opvallende discrepantie tussen de volwassenheid van de meting en analyse op detailniveau in de sprints en de schijnbare afwezigheid van sturingsinformatie op management niveau bij RWS. Maak gebruik van de volwassenheid op detailniveau om op te schalen.


BC6529-101/R0001/414320/JEBR/Nijm - 18 -

4 december 2013

5.2.7

Overige aanbevelingen De overige aanbevelingen zijn als volgt: 1. Versterk de eisenontwikkeling die betrekking heeft op de levensduur van het product. De huidige eisen betreffen vooral de projectfase. 2. Versterk de eisen en communicatie met betrekking tot de technische architectuur. Het is bij RWS niet eens 100% zeker of er een desktop of web applicatie wordt gebouwd. Deltares werkt aan een “Windows” applicatie die ook op Citrix moet kunnen draaien, maar er is geen zicht op ondersteunde versies van het besturingssysteem, gebruik van client frameworks en de toekomstige ontwikkeling hier in. 3. Los de discrepantie op tussen de twee conflicterende eisen met betrekking tot het ondersteunde geografische bestandsformaat. Ten eerste is er een eis om ESRI Shape files te ondersteunen. Ten tweede is er de eis om aan de lijst met Open Standaarden te voldoen, die een GML formaat voorschijven. 4. Onderzoek de huidige dynamiek met betrekking tot IRIS. Er wordt een koppelvlak gemaakt met IRIS, maar waterschappen neigen naar vervanging door een ander systeem.

5.3

HydraRing Onderstaand wordt ingegaan op de vragen die door RWS gesteld zijn bij opdrachtverlening.

5.3.1

Geclaimde functionaliteit Vraag van RWS: Is de door Deltares geclaimde functionaliteit behaald? Ja, de claims zijn onderbouwd en corresponderen met de inhoud van de onderliggende hoofdstukken.

5.3.2

Juistheid modellering belastingmodellen Vraag van RWS: Zijn de belastingmodellen juist gemodelleerd? De belastingmodellen voor de kust (m.u.v. IJmuiden) en het Schelde-estuarium functioneren goed. De belastingmodellen functioneren slecht voor de meren en benedenrivieren (Rijn en IJssel/Vecht). Belangrijk dilemma zijn de afwijkingen die het gevolg zijn van toepassen van FORM. Andere inhoudelijke oorzaken van afwijkingen worden veroorzaakt door iteratie van de windsnelheden en het sluitcriterium van de Maeslandtkering. Ten aanzien van de door Deltares gesignaleerde tekortkomingen wordt het volgende opgemerkt door de reviewers: 1. Uit de beschrijving volgt dat FORM bij voorkeur wordt toegepast vanwege rekentijd, DS wegens juistheid van de resultaten. De noodzaak van DS of FORM wordt aangetoond door de testen; 2. Deltares geeft geen verklaring voor de afwijkingen bij IJmuiden. De situatie bij IJmuiden wijkt sterk af van de rest van de kust. De buitenhaven van IJmuiden is zeer complex vanwege de dammen en eilanden. Voor ontwerpprojecten wordt hiervoor - op termijn – een apart model gemaakt. Overwogen moet worden de modellering buiten WTI te houden vanwege de complexe situatie.


BC6529-101/R0001/414320/JEBR/Nijm - 19 -

4 december 2013

3. 4.

5.3.3

Ten aanzien van de windsnelheid is sprake van een klein probleem dat vooral door aanpassing van de iteratiemethode kan worden opgelost; Het ontbreken van het sluitcriterium Maeslandtkering leidt tot grote waterstandsafwijkingen (max 15 cm). Implementatie van het sluitcriterium lijkt wenselijk vanwege het feit dat dit sluitcriterium een wettelijk gegeven is.

Juistheid modellering sterktemodellen Vraag van RWS: Zijn de sterktemodellen juist gemodelleerd? De sterktefunctie (Z-functie) en de check van het illustratiepunt leiden voor alle mechanismen tot oplossing. Berekeningen zijn waar mogelijk opgeknipt en op onderdelen gecontroleerd. Daaruit wordt geconcludeerd dat de sterktemodellen juist gemodelleerd zijn. Hierbij wordt geen uitspraak gedaan over de vraag of de werkelijkheid juist is gemodelleerd. Dit houdt in dat de PC-Ring modules inhoudelijk op juistheid moeten worden gecontroleerd voor deze als terugvalscenario kunnen worden toegepast. Uit de integratietesten zijn de resultaten voor overtopping voor meerdere watergebieden niet juist. De oorzaak ligt echter in de afwijkingen in de belastingmodellen in plaats van in de overslagmodule. Het testen van alle onderdelen afzonderlijk en de keten als geheel bewijst hier zijn waarde.

5.3.4

Implementatie foutenbomen Vraag van RWS: Zijn de foutenbomen van faalmechanismen juist ingebouwd? Binnen de faalmechanismen zijn faalbomen ingebouwd en gecontroleerd middels de integratietesten. Deze voldoen.

5.3.5

Ringbenadering Vraag van RWS: Is de ringbenadering op de juiste manier ingebouwd? De ringbenadering is getest op meerdere manieren. In de testen zijn meerdere secties en meerdere mechanismen gecombineerd en is het lengte-effect getest. De uitkomsten stemmen overeen met PC-Ring uitkomsten. Volgende testen kunnen meer mechanismen en sectie meenemen om tevens de snelheid en performance te testen.

5.3.6

Vergelijk PC-Ring Vraag van RWS: Kan het prototype als een nagebouwd PC-Ring gezien worden? De vergelijking met PC-Ring is nuttig als snel vergelijk voor de bestaande modules voor het doorrekenen van grote aantallen locaties. Dit snelle vergelijk is noodzakelijk vanwege de korte doorlooptijd. Niet alle watersystemen functioneren volwaardig, zoals ook genoemd in paragraaf 5.3.3. Verschillen in resultaten zijn daarom herleidbaar tot afwijkingen in de basisstatistiek. Door gebruik van meerdere dll‘s direct uit PC-Ring worden de berekeningen uit PC-Ring verder goed gereproduceerd. Ten aanzien van de faalmechanismen is de werking van HydraRing goed vergelijkbaar met PC-Ring en worden sterk vergelijkbare resultaten geproduceerd. Voor grote aantallen locaties geeft vergelijk van HydraRing en PC-Ring resultaten een goede indicatie van de betrouwbaarheid van HydraRing. Review Ringtoets en HydraRing Definitief rapport

BC6529-101/R0001/414320/JEBR/Nijm - 20 -

4 december 2013

Geconstateerd wordt uit de interviews dat PC-Ring nooit gevalideerd is en ook fouten lijkt te bevatten. Bij gebruik van een module uit andere software is ervan uitgegaan dat de toegeleverde modules juist zijn. Voor het vervolg van de software ontwikkeling dient geverifieerd te worden dat aangeleverde input voldoende gecontroleerd en geaccordeerd is. Bovendien is het noodzakelijk te verifiëren of de werking juist is wanneer ervoor gekozen wordt bestaande modules in het WTI2017 over te nemen. 5.3.7

Mate waarin voldaan is aan de requirements 2013 Vraag van RWS: In hoeverre is aan de requirements voldaan? De vraag is gelezen of de behaalde functionaliteit correspondeert met de gewenste functionaliteit en dit past in de planning tot 2017. Geconcludeerd wordt dat alle faalmechanismen en watersystemen zijn geïmplementeerd met uitzondering van bekledingen. Bekledingen zijn vanwege budgettaire redenen niet geïmplementeerd, zoals aangegeven in het softwareplan. Lopende het jaar zijn de requirements bijgesteld. Gegeven de beperking van de review is niet wijzigingenregister doorlopen. Uit sec vergelijk van requirements 2013 en testplan wordt geconcludeerd dat niet alle functionaliteiten zoals genoemd in januari 2013 zijn uitgevoerd en volledig functioneel zijn. Opgemerkt wordt dat in de requirements 2013 niet scherp was gedefinieerd wat het niveau van implementatie en de diepgang diende te zijn. Wanneer implementatie wordt gelezen als “werkend binnen de tolerantie” was de ambitie erg groot en heeft Deltares in de claims aangetoond dat dit is behaald voor de faalmechanismen wel, en niet voor alle watersystemen. Voor het oplossen van de problemen van deze watersystemen is nadere uitwerking nodig.

5.3.8

Aanbevelingen requirements 2014 Vraag van RWS: Gegeven de deadline van 2016 voor het WTI, welke aanbevelingen kunt u doen ten aanzien van de requirements 2014 Bij het doorschuiven van onderdelen naar 2014 is niet aangegeven wat het gevolg voor de planning is. Het doorschuiven van werkzaamheden geeft extra druk op het budget van volgend jaar en verkleint de speling in de planning. Uit de testen blijkt tevens nader onderzoek noodzakelijk. De door RWS gevraagde acceptatietesten dienen nader ingevuld te worden door RWS zelf. In het kader van SCB dient RWS na te gaan op welke wijze zij tot acceptatie van het eindproduct in 2017 over kunnen gaan. Het tijdig inrichten van de testen, al dan niet op basis van het testprogramma van Deltares, geeft opdrachtgever en opdrachtnemer meer duidelijkheid over het eindproduct en de eisen.

5.3.9

Overige conclusies en aanbevelingen Verwacht wordt dat de bekledingenmodules moeilijk te implementeren zijn vanwege discontinue functies. Door deze implementatie uit te stellen wordt tevens de resterende tijd beperkt.


BC6529-101/R0001/414320/JEBR/Nijm - 21 -

4 december 2013

5.4

Discussie Omdat Deltares niet werkt met CMMI®, kan er een discrepantie ontstaan tussen de methodiek van Deltares en voorliggende rapportage die deels op een wellicht afwijkende systematiek is gebaseerd. Dit lijkt zelfs voor de hand te liggen, want Deltares gebruikt Scrum, en dat is heel iets anders dan CMMI®. Toch is het in deze review geen beperking gebleken, vooral omdat de CMMI® procesgebieden erg op hoofdlijnen zijn ingedeeld en beschreven, waarmee het echt een bovenliggende kapstok kan zijn. CMMI® gaat niet in op concrete zaken zoals rolverdeling in een project, de opbouw van een architectuur document of de wijze waarop het dagelijks operationeel overleg gevoerd dient te worden. CMMI® bevat weliswaar ook praktijken, annotaties, voorbeelden en voorbeeld werkproducten, maar deze zijn in de review niet gebruikt. Er is alleen gefocust op de procesgebieden als structurerend en inhoudelijk raamwerk. Uit de interviews naar voren dat het eindbeeld niet duidelijk is. Het eindbeeld en de communicatie daarover is evenwel essentieel voor het behalen van het doel van RWS: een betrouwbaar, gebruiksvriendelijk, robuust instrument. Indien geconstateerd wordt dat aan het eind een minder volledig instrument opgeleverd dient te worden, is het noodzakelijk het beheer en onderhoud zo in te richten dat resterende punten opgelost kunnen worden. De vergelijking van requirements, specificaties en testrapport wijzen erop dat de beoogde functionaliteit ten dele is behaald. De ambitie hierin was erg groot. Gegeven dat een deel van de werkzaamheden vooruit geschoven is en uit de testen nader onderzoek voortkomt om tot volledige, werkende implementatie te komen, is de vraag of een volledig instrument tijdig gereed is. In het kader van SCB heeft RWS de wens van acceptatietesten. Het tijdig inrichten hiervan of afspraken maken hierover is noodzakelijk om opdrachtnemer en opdrachtgever helderheid te geven over de acceptatieprocedure en het op te leveren product.


BC6529-101/R0001/414320/JEBR/Nijm - 22 -

4 december 2013

6

REFERENTIES [Ref 1.] [Ref 2.] [Ref 3.] [Ref 4.] [Ref 5.] [Ref 6.] [Ref 7.]

[Ref 8.] [Ref 9.] [Ref 10.]

[Ref 11.] [Ref 12.] [Ref 13.] [Ref 14.] [Ref 15.] [Ref 16.]

Memo Nadere uitwerking van de testfilosofie, W. van Balen, Deltares, 16 mei 2013. 20130516 Acceptatiecriteria producten voor TOI, R. Slomp, RWS, 11 april 2011, update 24 januari 2012 Basisuitgangspunten WTI2017, J.G. Knoef e.a., Deltares, september 2012. 1206004-002-GEO-0002 Hydra Design document, version 2, Draft, A. Markus, e.a., Deltares, december 2011. 1204145-004-ZWS-0003. Hydra-Ring: probabilistics and statistics: validation document, Deltares, 22 October 2013. 1.1.18017. Product – Requirements ‘Cluster B Software’. R. Slomp, RWS, Programma WTI2017, onderzoek en ontwikkeling landelijk toetsinstrumentarium: projectplan Cluster Softwareontwikkeling 2013. Deltares, J. Icke e.a., januari 2013, 1207804-000 Ringtoets Testplan, Robert Kamp, 1207804-001-DSC-0003, Version 0.4, 2 September 2013, draft. Ringtoets Technical Design, Marcel Visschedijk, Robert Kamp, Rob Brinkman, Version 1.1, 1207804-001-DSC-0002, 16 May 2013, draft. Ringtoets Requirements and Functional Design, Marcel Visschedijk, Robert Kamp, Rob Brinkman, Version 1.1, 1207804-001-DSC-0002, 16 May 2013, draft. Oplegmemo bij Ringtoets documenten voor de externe review, Kin Sun Lam, 18 oktober 2013. Memo Review Testplan RingToets, Pim Witlox, 17 October 2013. CMMI® voor Ontwikkeling, Versie 1.3, CMMI-DEV, V1.3, CMU/SEI-2010TR-033 / ESC-TR-2010-033, Software Engineering Institute, november 2010. De kleine PRINCE2, Gids voor projectmanagement Editie 2010, Mark van Onna, Ans Koning, juni 2010. Mark van Onna, Ans KoningDe Scrumgids, De definitieve gids voor Scrum: de regels van het spel, Ken Schwaber en Jeff Sutherland, oktober 2011. RUP op maat, Agile ICT met RUP, Scrum en PRINCE2, derde druk, Remi-Armand Collaris, Eef Dekker, augustus 2011.


BC6529-101/R0001/414320/JEBR/Nijm - 23 -

4 december 2013

Bijlage 1 Overzichtstabel requirements en claims



Tabel 1: Overzicht van requirements en claims

Nr

Programma Methode WTI2017, /submech Product projectplan anisme requirements software 2013 R. Slomp jan '13J. Icke, jan '13

DIJKEN 1 Basis statistiek 2 3 Hoogte overloop implementatie 4 5 overslag implementatie 6 7 8 9 Piping/heave implementatie 10 11 12 13 Macrostabiliteit implementatie 14 15 16 Bekleding implementatie 17 Steenzetingen 18 Asfalt 19 Gras 20 Duinen implementatie 21 22 23 KUNSTWERKEN 24 Hoogte overslag implementatie 25 26 27 overloop 28 Niet sluiten keermid implementatie 29 30 31 Piping implementatie 32 33 34 Constructief falen implementatie 35 36 37 COMP PROB 38 Failure probab single component 39 40 41 42 systeembetrouwbaarheid 43 44 45 46 Statistische verdeling


Validation report W. van Balen 22 oct '13 paragraaf claim claim 2.2.1

implementatie

2.2.3 2.2.4

2.2.1 reproduceerbaar 2.2.2 correct 2.2.3 t/mzie ander blad 2.2.21 t/zie ander blad

implementatie 2.3.1

implementatie 2.3.2 gereed voor evaluatie

implementatie

2.3.1 2.3.2 2.3.3

module geïntegreerd z‐functie functioneert systeemtest, vergelijkbaar

2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 2.3.9

module geïntegreerd z‐functie functioneert systeemtest, vergelijkbaar module geïntegreerd z‐functie functioneert systeemtest, vergelijkbaar

Uitgesteld 2014 2014 2014 implementatie

2.3.4 2.3.10 module geïntegreerd 2.3.11 systeemtest, vergelijkbaar

implementatie

2.3.5

2.3.12 module geïntegreerd 2.3.13 z‐functie functioneert+faalboom 2.3.14 systeemtest, vergelijkbaar

implementatie

2.3.6

implementatie

2.3.7

implementatie

2.3.8

2.3.15 2.3.16 2.3.17 2.3.18 2.3.19 2.3.20 2.3.21 2.3.22 2.3.23

module geïntegreerd z‐functie functioneert+faalboom systeemtest, vergelijkbaar module geïntegreerd z‐functie functioneert+faalboom systeemtest, vergelijkbaar module geïntegreerd z‐functie functioneert+faalboom systeemtest, vergelijkbaar

2.4.1 2.4.2 2.4.3

verwijst naar test per faalmechanism verwijst naar test per faalmechanism verwijst naar test per faalmechanism

2.4.4 2.4.5 2.4.6 2.5.1

juist geïmplementeerd deels geslaagd correct statistische functies zijn juist geïmpl

2.4 2.4.1

2.4.2

2.5

Bijlage 1 -1-


Tabel 2: Overzicht functionaliteit watersystemen maximaal verschil in cm's

good good fair

poor poor fair

fair fair good

poor poor fair

good good fair

poor poor poor

poor poor poor

good good fair

good good fair

good good poor

fair fair poor

good good poor

good good poor

good good poor

good good poor

Watersystemen Rivieren Meren Kust 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 bovenlobovenlobenede benede Ijssel Vecht IjsselmeMarkermWaddenWaddenHollandse kust Ooster‐ Wester‐ duinen Rijn Maas Rijn Maas delta delta Oost West Noord Centraa Zuid schelde schelde

waterstand good overschrijdingsfrequentie good kruinhoogte (ws, Hs, Tp, zq) fair

4 december 2013

-2-

Definitief rapport

BC6529-101/R0001/414320/JEBR/Nijm

Bijlage 1

Review Ringtoets en HydraRing

Bijlage 2 Beschrijving CMMI procesgebieden ®



Beschrijving CMMI® procesgebieden 1) PROJECTBEWAKING EN -STURING (PMC − Project Monitoring and Control) De bedoeling van „Projectbewaking en –sturing” is inzicht te verschaffen in de voortgang van het project zodat passende corrigerende maatregelen genomen kunnen worden als de projectprestaties in belangrijke mate afwijken van het plan. Een gedocumenteerd projectplan is de basis voor bewakingsactiviteiten, het communiceren van de status en het nemen van corrigerende maatregelen. Voortgang wordt voornamelijk bepaald door op voorgeschreven mijlpalen of sturingsniveaus in de projectplanning de actuele werkproducten taakkenmerken, uren, kosten en planning te vergelijken met het plan. Juist inzicht in de voortgang maakt het mogelijk dat tijdig corrigerende maatregelen genomen kunnen worden als de prestaties in belangrijke mate afwijken van het plan. Een afwijking is significant als zij, wanneer zij onopgelost blijft, het project belet zijn doelstellingen te bereiken. De term „projectplan” wordt hier overigens gehanteerd om te verwijzen naar het alles omvattende plan om het project te besturen. Wanneer de actuele status significant afwijkt van de verwachte waarden, dan worden waar van toepassing corrigerende maatregelen genomen. Deze acties kunnen herplanning vereisen, wat een herziening van het originele plan, het maken van nieuwe afspraken, of het opnemen van extra risicobeperkende activiteiten in het huidige plan kan betekenen. 2) PROJECTPLANNING (PP – Project Planning) De bedoeling van “Projectplanning” is plannen tot stand te brengen en te onderhouden die de projectactiviteiten definiëren. Eén van de sleutels tot het doeltreffend managen van een project is projectplanning. Het procesgebied „Projectplanning” omvat de volgende activiteiten:  ontwikkeling van het projectplan;  op de juiste wijze interacteren met relevante belanghebbenden;  het verkrijgen van commitment voor het plan;  het plan onderhouden. Planning omvat het schatten van aspecten van werkproducten en taken, het bepalen van de benodigde mensen en middelen, het onderhandelen over commitment, het maken van een tijdschema en het vaststellen en analyseren van projectrisico’s. Om het projectplan te realiseren, kan het noodzakelijk zijn om deze activiteiten meermalen te doorlopen. Het projectplan vormt de basis voor de uitvoering en sturing van de projectactiviteiten die de commitment aan de klant van het project adresseren. Als het project vordert, wordt het projectplan gewoonlijk aangepast om wijzigingen in eisen en commitment, onnauwkeurige schattingen, corrigerende maatregelen en proceswijzigingen erin te verwerken. Dit procesgebied bevat specifieke praktijken die zowel planning als herplanning beschrijven. 3) EISENMANAGEMENT (REQM − Requirements Management) De bedoeling van „Eisenmanagement” is de eisen voor de producten en productcomponenten van het project te managen en te zorgen dat deze eisen en de projectplannen en werkproducten op elkaar afgestemd zijn.


Bijlage 2 -1-


Eisenmanagementprocessen managen alle ontvangen of door het project gegenereerde eisen inclusief zowel technische als niet-technische eisen, evenals de eisen die aan het project zijn opgelegd door de organisatie. Het project neemt passende stappen om ervoor te zorgen dat het afgesproken pakket aan eisen wordt beheerd om de plannings- en uitvoeringsbehoeften van het project te ondersteunen. Als een project eisen ontvangt van een erkende eisenverstrekker, worden de eisen met de eisenverstrekker gereviewd om problemen op te lossen en misverstanden te voorkomen voordat de eisen worden opgenomen in de projectplannen. Zijn de eisenverstrekker en de eisenontvanger het eenmaal eens geworden, dan wordt commitment op de eisen verkregen van de projectdeelnemers. Het project beheert wijzigingen op de eisen als ze ontstaan en stelt mogelijke inconsistenties vast die voorkomen tussen plannen, werkproducten de en eisen. Een deel van het beheren van eisen bestaat uit het documenteren van wijzigingen van de eisen en de argumentatie daarvoor en het onderhouden van bidirectionele traceerbaarheid tussen broneisen, alle producten productcomponenteisen en andere gespecificeerde werkproducten. 4) PRODUCTINTEGRATIE (PI - Product Integration) De bedoeling van “Productintegratie” is het product samen te stellen uit de productcomponenten, te zorgen dat het product, zoals het is samengesteld, correct werkt (dat wil zeggen: de vereiste functionaliteit en kwaliteitskenmerken bezit) en het product op te leveren. Dit procesgebied behandelt het integreren van productcomponenten tot complexere productcomponenten of tot complete producten. De scope van dit procesgebied is om complete productintegratie te bereiken door de productcomponenten steeds verder te integreren, in één fase of in incrementele fasen volgens een gedefinieerde integratiestrategie en procedures. Een cruciaal aspect van productintegratie is het beheer van interne en externe interfaces van de producten en productcomponenten om te zorgen voor compatibiliteit tussen de interfaces. Deze interfaces beperken zich niet tot gebruikersinterfaces, maar betreffen ook interfaces tussen componenten van het product, inclusief interne en externe gegevensbronnen, middleware, en andere componenten die al dan niet onder beheer van de ontwikkelorganisatie vallen, maar waar het product van afhankelijk is. Gedurende het hele project moet aandacht worden geschonken aan interfacemanagement. Productintegratie is meer dan alleen een eenmalige integratie van de productcomponenten aan het eind van het ontwerp en de bouw. Productintegratie kan incrementeel worden uitgevoerd, gebruikmakend van een iteratief proces van samenvoegen van productcomponenten, ze evalueren, gevolgd door het toevoegen van nog meer productcomponenten. Het kan worden uitgevoerd met behulp van verregaand geautomatiseerde „builds” en door continue integratie van voltooide componenten, waarvan de unittesten zijn afgerond. 5) EISENONTWIKKELING (RD − Requirements Development) De bedoeling van „Eisenontwikkeling” is het ontdekken, analyseren en uitwerken van klant-, producten productcomponenteisen. Dit procesgebied beschrijft drie soorten eisen: klanteisen, producteisen en productcomponenteisen. Samen geven deze eisen de behoeften van relevante belanghebbenden weer, inclusief behoeften die relevant zijn voor de verschillende fasen van de productlevenscyclus (bijvoorbeeld acceptatietestcriteria) en de productkenmerken (bijvoorbeeld responsiviteit, veiligheid, betrouwbaarheid en onderhoudbaarheid).


Bijlage 2 -2-


Eisen gaan ook in op beperkingen als gevolg van de geselecteerde ontwerpoplossingen (bijvoorbeeld integratie van commerciële standaardproducten, het gebruik van een bepaald architectuurmodel). Alle ontwikkelingsprojecten hebben eisen. Eisen zijn de basis voor ontwerp. De ontwikkeling van eisen omvat de volgende activiteiten:  het ontdekken, analyseren, valideren en communiceren van behoeften, verwachtingen en voorwaarden van de klant om geprioriteerde klanteisen te verkrijgen die inzicht geven in wat belanghebbenden tevreden zal stellen;  het verzamelen en coördineren van behoeften van belanghebbenden; de ontwikkeling van eisen over de levenscyclus van het product;  het vaststellen van de functionele eisen en kwaliteitseisen van de klant; het vaststellen van initiële producten productcomponenteisen consistent met klanteisen. Klanteisen worden verder uitgewerkt in producten productcomponenteisen. Behalve klanteisen worden producten productcomponenteisen afgeleid van de geselecteerde ontwerpoplossingen. Eisen worden in alle fasen van de productlevenscyclus vastgesteld en nader uitgewerkt. 6) TECHNISCHE OPLOSSING (TS − Technical Solution) De bedoeling van „Technische Oplossing” (TS) is, voor de eisen oplossingen te selecteren, te ontwerpen, en te realiseren. De oplossingen, ontwerpen en realisaties hebben, afhankelijk van de situatie, betrekking op producten, productcomponenten en aan de levenscyclus van het product gerelateerde processen, of een combinatie hiervan. Het procesgebied „Technische Oplossing” is van toepassing op elk niveau van de productarchitectuur en op ieder product, productcomponent en op ieder aan de levenscyclus van het product gerelateerd proces. Overal in de procesgebieden waar de termen „product” en „productcomponent” worden gebruikt, omvat hun beoogde betekenis ook diensten, dienstverlenings-systemen en hun componenten. Dit procesgebied richt zich op het volgende:  het evalueren en selecteren van die in potentie voldoen aan een hiervoor bestemd pakket met op functionaliteit en kwaliteitskenmerken gerichte eisen;  het ontwikkelen van gedetailleerde ontwerpen voor de geselecteerde oplossingen (gedetailleerd in die zin dat het alle informatie bevat die nodig is om het ontwerp te bouwen, te coderen, of op andere wijze als een product of productcomponent te realiseren);  het realiseren van een product of productcomponent vanuit de ontwerpen. Gewoonlijk werken deze activiteiten op elkaar in en ondersteunen elkaar. Er kan een bepaald niveau van ontwerp nodig zijn, soms tamelijk gedetailleerd, om oplossingen te selecteren. Er kunnen prototypes of proefprojecten gebruikt worden als een middel om voldoende kennis te vergaren voor de ontwikkeling van een technisch informatiepakket of een compleet pakket eisen. Er kunnen modellen van kwaliteitskenmerken, simulaties, prototypes of proefprojecten worden gebruikt om aanvullende informatie te verstrekken over de mogelijke ontwerpoplossingen om te helpen bij de selectie van oplossingen. Simulaties kunnen vooral nuttig zijn voor projecten die systemen-van-systemen ontwikkelen.


Bijlage 2 -3-


7) VALIDATIE (VAL − Validation) De bedoeling van “Validatie” is aan te tonen dat een product of productcomponent kan worden gebruikt zoals is bedoeld wanneer het in zijn beoogde omgeving is geplaatst. Validatieactiviteiten kunnen toegepast worden op alle aspecten van het product ongeacht zijn beoogde omgeving, zoals exploitatie, opleiding, vervaardiging, onderhoud en ondersteunende diensten. De validatiemethoden kunnen zowel op werkproducten als op het eindproduct en de productcomponenten worden toegepast. De validatieomgeving dient zowel voor het product als voor de product-componenten de beoogde omgeving te representeren, evenals de beoogde omgeving die geschikt is voor validatieactiviteiten met werkproducten. Validatie toont aan dat het product, zoals het is opgeleverd, beantwoordt aan zijn verwachte gebruik; terwijl verificatie vaststelt of het werkproduct de gespecificeerde eisen op de juiste wijze weergeeft. Met andere woorden, verificatie garandeert dat „het product juist is gebouwd”; terwijl validatie garandeert dat „het juiste product is gebouwd”. Validatieactiviteiten hanteren aanpakken vergelijkbaar met verificatie (bijvoorbeeld test, analyse, inspectie, demonstratie, simulatie). Vaak worden de eindgebruikers en andere relevante belanghebbenden betrokken bij de validatieactiviteiten. Zowel validatie- als verificatieactiviteiten worden vaak gelijktijdig uitgevoerd en kunnen delen van dezelfde omgeving gebruiken. Waar mogelijk moet het product of productcomponent werkend in zijn beoogde omgeving worden gevalideerd. De omgeving kan in zijn geheel of slechts gedeeltelijk gebruikt worden. Door de relevante belanghebbenden erbij te betrekken, kunnen validatieproblemen al vroeg in het project dat de werkproducten gebruikt ontdekt worden. 8) VERIFICATIE (VER − Verification) De bedoeling van „Verificatie” (VER) is om te garanderen dat geselecteerde werkproducten voldoen aan hun gespecificeerde eisen. Het procesgebied „Verificatie” omvat het volgende: verificatievoorbereiding en uitvoering en identificatie van corrigerende maatregelen. Verificatie omvat het verifiëren van het product en de tussenproducten tegen alle geselecteerde eisen, inclusief klant-, producten productcomponenteisen. Voor productlijnen moeten ook de kernbedrijfsmiddelen en de bijbehorende afwijkende werkwijzen voor de productlijn geverifieerd worden. Verificatie is van nature een incrementeel proces omdat het plaatsvindt in de gehele ontwikkeling van het product en de werkproducten, te beginnen met de verificatie van de eisen, vervolgens met de verificatie van de zich verder ontwikkelende werkproducten en ten slotte met de verificatie van het voltooide eindproduct. Verificatie van werkproducten verhoogt de waarschijnlijkheid dat het product zal voldoen aan de klant-, producten productcomponenteisen aanzienlijk. De procesgebieden „Verificatie” en „Validatie” zijn vergelijkbaar, maar ze pakken verschillende aspecten aan. Validatie toont aan dat het product, zoals het wordt geleverd (of zoals het zal worden geleverd), zal beantwoorden aan zijn beoogde toepassing, terwijl verificatie nagaat of het werkproduct de gespecificeerde eisen correct weerspiegelt. Met andere woorden: verificatie garandeert „u heeft het product goed gebouwd”, terwijl validatie garandeert „u heeft het goede product gebouwd”. 9) CONFIGURATIEMANAGEMENT (CM − Configuration Management) De bedoeling van „Configuratiemanagement” (CM) is de integriteit van werkproducten vast te stellen en te handhaven door middel van configuratie-identificatie, configuratiebeheer, het administreren van de configuratiestatus en configuratie-audits.


Bijlage 2 -4-


Het procesgebied „Configuratiemanagement” omvat de volgende activiteiten:  het identificeren van de configuratie van geselecteerde werkproducten die op gegeven momenten in de tijd de baselines vormen;  het beheersen van wijzigingen op configuratie-items; het bouwen of verstrekken van specificaties om werkproducten uit het configuratiemanagementsysteem op te bouwen;  het handhaven van de integriteit van baselines; het verstrekken van exacte statusen actuele configuratiegegevens aan ontwikkelaars, eindgebruikers en klanten. De onder configuratiemanagement geplaatste werkproducten omvatten de producten die aan de klant worden opgeleverd, specifiek benoemde interne werkproducten, aangeschafte producten, hulpmiddelen en andere items die bij het creëren en beschrijven van deze werkproducten worden gebruikt. 10) METING EN ANALYSE (MA − Measurement and Analysis) De bedoeling van „Meting en Analyse” is een vermogen tot meten te ontwikkelen en te handhaven, dat gebruikt wordt om te voorzien in de behoefte aan managementinformatie. Het procesgebied „Meting en Analyse” omvat de volgende activiteiten:  het specificeren van doelstellingen voor meting en analyse zodat ze in lijn zijn met vastgestelde informatiebehoeften en met project-, organisatie- of bedrijfsdoelstellingen;  het specificeren van metrieken, analysetechnieken en mechanismen om meetgegevens te verzamelen, op te slaan, en te rapporteren en terugkoppeling te geven;  het implementeren van de analysetechnieken en mechanismen om gegevens te verzamelen en te rapporteren en terugkoppeling te geven;  het leveren van objectieve resultaten die gebruikt kunnen worden bij het nemen van onderbouwde beslissingen en het nemen van passende corrigerende maatregelen. De integratie van metingen analyseactiviteiten in de processen van het project ondersteunt het volgende:  objectief plannen en schatten;  het volgen van de feitelijke voortgang en prestaties ten opzichte van vastgestelde plannen en doelstellingen;  het identificeren en oplossen van belangrijke procesgerelateerde kwesties;  het leggen van een basis om in de toekomst bij andere processen metingen op te nemen. 11) PROCES- EN PRODUCTKWALITEITSBORGING (PPQA − Process and Product Quality Assurance) De bedoeling van „Proces- en Productkwaliteitsborging” is zowel medewerkers als management objectief inzicht te verschaffen in processen en daaraan gerelateerde werkproducten. Het procesgebied „Proces- en Productkwaliteitsborging” omvat het volgende:  het objectief evalueren van de uitgevoerde processen, werkproducten en diensten ten opzichte van de van toepassing zijnde procesbeschrijvingen, standaarden en procedures;  het vaststellen en documenteren van afwijkingen;  terugkoppeling geven aan projectmedewerkers en managers over de resultaten van kwaliteitsborgingactiviteiten;  het waarborgen dat afwijkingen worden opgelost.


Bijlage 2 -5-


Het procesgebied „Proces- en Productkwaliteitsborging” ondersteunt de levering van kwalitatief hoogwaardige producten en diensten door de projectmedewerkers en leidinggevenden op alle niveaus te voorzien van het juiste inzicht in en terugkoppeling over processen en bijbehorende werkproducten gedurende de gehele looptijd van het project. Objectiviteit bij de evaluaties voor de borging van proces- en productkwaliteit is essentieel voor het welslagen van het project. Objectiviteit wordt bereikt door zowel onafhankelijkheid als door het gebruik van criteria. Er wordt vaak een combinatie van methoden gebruikt die evalueren tegen criteria door degenen die niet het werkproduct produceren. Minder formele methoden kunnen voor algemeen dagelijks gebruik worden toegepast. Meer formele methoden kunnen periodiek gebruikt worden om objectiviteit te garanderen. (Bron: CMMI®)


Bijlage 2 -6-


Bijlage 3 Toelichting Vaardigheidsniveaus



Toelichting vaardigheidsniveaus De procesgebieden die zijn meegenomen in de review zijn per proces gescoord op vier vaardigheidsniveaus: Vaardigheidsniveau 0: Incompleet Een incompleet proces is een proces dat niet, of slechts ten dele wordt uitgevoerd. Eén of meer van de specifieke doelen van het procesgebied worden niet gehaald en er bestaan geen generieke doelen voor dit niveau aangezien er geen reden is om een gedeeltelijk uitgevoerd proces te institutionaliseren. Vaardigheidsniveau 1: Uitgevoerd Een vaardigheidsniveau 1-proces wordt gekenmerkt als een uitgevoerd proces. Een uitgevoerd proces is een proces dat de noodzakelijke werkzaamheden voltooit om werkproducten te produceren; specifieke doelen van het procesgebied worden vervuld. Hoewel vaardigheidsniveau 1 resulteert in belangrijke verbeteringen, kunnen deze verbeteringen in de loop der tijd verloren gaan als ze niet worden geïnstitutionaliseerd. De toepassing van institutionalisering (de CMMI®-generieke praktijken op vaardigheidsniveaus 2 en 3) helpt om ervoor te zorgen dat verbeteringen behouden blijven. Vaardigheidsniveau 2: Beheerst Een vaardigheidsniveau 2-proces wordt gekenmerkt als een beheerst proces. Een beheerst proces is een uitgevoerd proces dat wordt gepland en uitgevoerd in overeenstemming met beleid; deskundige mensen inzet die over adequate middelen beschikken om beheerste uitvoer te produceren; relevante belanghebbenden betrekt; wordt bewaakt, bestuurd en gereviewd; en wordt geëvalueerd op naleving van zijn procesbeschrijving. De procesdiscipline weergegeven door vaardigheidsniveau 2 helpt om te zorgen dat bestaande praktijken gehandhaafd blijven in tijden van stress. Vaardigheidsniveau 3: Gedefinieerd Een vaardigheidsniveau 3-proces wordt gekenmerkt als een gedefinieerd proces. Een gedefinieerd proces is een beheerst proces dat op maat is gemaakt vanuit de verzameling standaardprocessen van de organisatie; een onderhouden procesbeschrijving heeft; en met procesgerelateerde ervaringen bijdraagt aan de procesmiddelen van de organisatie. Een cruciaal onderscheid tussen vaardigheidsniveaus 2 en 3 is de reikwijdte van standaarden, procesbeschrijvingen en procedures. Op vaardigheidsniveau 2 kunnen de standaarden, procesbeschrijvingen en procedures erg verschillend zijn in elk specifiek geval van het proces (bijvoorbeeld voor een specifiek project). Op vaardigheidsniveau 3 zijn de standaarden, procesbeschrijvingen en procedures voor een project afgeleid van de verzameling standaardprocessen van de organisatie en geschikt gemaakt (toegesneden op) voor een specifiek project of organisatorische eenheid en zijn daarom consistenter, behalve voor de verschillen die toegestaan zijn door het op maat maken van het proces voor de specifieke toepassing binnen het project. (Bron: CMMI®)


Bijlage 3 -1-


Midterm review WTI2017 cluster software Ringtoets en HydraRing

Recommend Documents