Rij kswaterstaat Adviesdienst Verkeer en Vervoer Bureau Dokumentatie Postbus BA Rotterdam C 7001

49 .

r

4.

ea

4

(.

0

Rij kswaterstaat Adviesdienst Verkeer en Vervoer Bureau Dokumentatie Postbus 1031 3000 BA Rotterdam

C 7001

;2&2o —.

.

.

Navigator L YJ Software Quality Assurance Plan (SQAP) voor ontwerp en implementatie

.

projectaanpak mei 1989 S

.

...........................-

Q 900

waterloopkundig IaboratoriumwL

Navigator

Software Quality Assurance Plan (SQAP) voor ontwerp en implementatie

W.J.A. Mol

'

pAp W 49k waterloopkundig IaboratoriumwL

1.

Inleiding

In dit Software Quality Assurance Plan (SQAP) wordt de aanpak van het softwareontwikkelingsproject NAVIGATOR beschreven volgens het Handboek voor informaticaprojecten [1]. Dit SQAP wordt voor kennisname ter inzage gegeven aan de opdrachtgever. De werkzaamheden zullen worden verricht met als referentienummer Q900.10 De hoofdstukindeling van het SQAP is conform het SQA-Handboek [1] en is hieronder weergegeven: 1 Inleiding 2 Achtergrondgegevens van het project 3 Fasering en eindprodukten 4 Planning 5 Voortgangscontrole en rapportage 6 Organisatie 7 Revjews en audits 8 Probleemrapportage en wijzigingsvoorstellen 9 Configuratie- en wijzigingsbeheer 10 Documentatie 11 Gereedschappen 12 Ontwerpstandaarden 13 Codeerstandaarden 14 Testen Referent les Appendix met formulieren en adressen

NAVIGATOR QA-FILE (versie 0.2)

2.

2. Achter2rondPePevens In het kader van het Toegepast Onderzoek voor de Waterstaat (TOW) is door de stuurgroep Scheepvaart een projectgroep "Sturen van Schepen" opgericht, met als taak: het opstellen van een wiskundig model voor de bestuurder van een schip. In de periode 1982-1987 heeft deze projectgroep de mogelijkheden van een dergelijk model tot in details onderzocht. De uitgevoerde werkzaamheden zijn geevalueerd in het rapport: "Evaluatie TOW - Sturen van Schepen" [2]. Er wordt in dit rapport verwezen naar een aantal andere rapporten waarin een inventarisatie wordt gegeven rond de modelvorming van de bestuurder. Tevens worden voorstellen gedaan voor een model en wordt de feasibility van het model aangetoond. Als vervolg hierop zijn in de periode van november 1988 tot februari 1989 de functionele specificaties van het model, dat inmiddels is gedoopt met de naam FATIMAH, opgesteld In een aantal gesprekken met Rijkswaterstaat zijn de functionele specificaties bijgesteld [3]. Tevens wordt afgesproken de naam FATIMAH te vervangen door NAVIGATOR. Het programma NAVIGATOR is opgebouwd uit een aantal modules; te weten: * WAARNEEM MODULE De waarneming relateert de toestand van het schip aan de situatie waarin de navigator zich bevindt. Dit gebeurt in twee stappen. Eerst wordt een verzameling van alle mogelijke waarnemingen gegenereeerd (presentatie) en vervolgens wordt er een selectie uit deze waarnemingen gedaan (selectie). * TOESTANDSCHATTINGS MODULE Hierin zijn weer twee deelprocessen te onderscheiden. Het eerste voorspelt een waarneming (predictie), het tweede corrigeert de voorspelde toestand (filterstap). * PLANNINGS- EN BESTURINGS MODULE Het ontwerpen van een vaarplan. * SCHEEPSSIMULATIE MODULE De rnanoeuvreer-simulator. * INTERN MODEL-BESTANDEN Te weten: het intern model omgevingsbestand en het intern model schip-be stand * BESTANDEN Te weten: het omgevingsbestand, het schipbestand en het taakbestand. NAVIGATOR heeft ook een preprocessingsprogramma: * PRELUDE

Dit werkplan beschrijft de vervolgactiviteiten na de functionele specificaties te weten: het (globaal en technisch) ontwerp en de implementatie. Acceptatie en installatie zijn in dit plan niet opgenomen. In de offerte Q900.95 d.d. 24 mei 1989 is een en ander nader toegelicht. In dit projekt wordt van de functionele specificaties afgeweken op de volgende punten: - Wat betreft de preprocessing zal gebruik worden gemaakt van het TNOIWECO invoerprograrnma. - Wat betreft het interne model wordt uitgegaan van een simpel intern model te weten het TNO-IWECO model. NAVIGATOR QA-FILE (versie 0.2) 3.

- Er wordt door NAVIGATOR geen statistiekenfile opgeleverd. - Als extern manoevreermodel wordt alleen SHIPMA gebruikt. De volgende punten schuiven op naar een vervolg van het projekt: - Een gebruikersvriendelijke invoerprogramrna (PRELIJDE). - (Gelineariseerd) SHIPMA als intern model. - Een statistiekenfile - Het MARIN-model als manoevreermodel. In de offerte wordt uitgegaan van de taal C als programmeertaal en UNIX als operatingsysteem.Als het globale ontwerp wordt opgeleverd zal Rijkswaterstaat een beslissing hebben genomen omtrent de hardware waarop NAVIGATOR geinstalleerd zal gaan worden. Wanneer dit een computersysteem is, waarop geen UNIX aanwezig is, zal het WL een aparte offerte opstellen, waarbij de extra kosten worden begroot wat betreft het gebruik van FORTRAN als programmeertaal.


4.

3. Fasering en eindprodukten De navolgende fasen en op te leveren documenten worden onderscheiden: Opstartfase/definitiefase Eindproducten: - Offerte - Gedetailleerde SQAP aanpakrnethodiek - Middelen en activiteitenplan globaal ontwerpfase Globaal ontwerpfase Eindproducten: - Systeem ontwerp - Gemeenschappelijk bestand - Middelen en activiteitenplan voor de technisch ontwerpfase Technisch ontwerpfase Eindproducten: - Technisch ontwerp - Testspecificaties - Middelen en activiteitenplan voor de ontwikkelingsfase Ontwikkelingsfase Eindproducten: - Programmadocumentatie - Sourcecode


5.

4. Planning 4.1

Algemeen

De fasering van het project is ingedeeld volgens het lineaire fasemodel, te weten: - opstartfase/definitiefase - globaal ontwerpfase - technisch ontwerpfase - ontwikkelingsfase 4.2

Algemene projectplan

De verschillende fasen resulteren in documenten zoals beschreven in hoofdstuk 3. Op het moment dat de documenten zijn opgeleverd en goedgekeurd (de zogenaamde mijlpalen) door de stuurgroep wordt een fase afgesloten. De verwachte data dat een fase wordt afgesloten zijn in het navolgende vermeld: -

-

-

-

opstartfase/definitiefase globaal ontwerpfase technisch ontwerpfase ontwikkelingsfase

1 1 1 1

juli november februari juni

1989 1989 1990 1990

In de technische ontwerpfase wordt per module een technisch ontwerp document opgeleverd. Na accoord van de stuurgroep kan tot implementatie van een module worden overgegaan. Het algemene projectplan wordt opgesteld tijdens de algemene opstartfase van het project. Het geeft het volgende weer: De planning in de tijd van de fasen Overzicht van de benodigde mensen en middelen in de tijd per fase. Overzicht van de belangrijkste mijlpalen, reviews en kontrole punten in het project. Een beschrijving van de algemene aannames, uitgangspunten en grootste risicO's van het project. - Veranderingen in het algemene projectplan zijn alleen toegestaan nadat deze zijn goedgekeurd door de projectleider en dienen zoveel mogelijk vermeden te worden. 4.3

Faseplannen

Per fase wordt een faseplan opgesteld dat voor de aanvang van de fase bekend dient te zijn. Het is een gedetailleerde uitwerking van het projectplan voor een fase in het subproject. Uitgangspunt voor het faseplan zijn de activiteiten die een persoon kunnen worden toegekend. Ieder faseplan zal als zodanig in het projectplan zijn terug te vinden. Het geeft het volgende weer: De planning in de tijd van alle activiteiten in de desbetreffende fase. Activiteiten in een faseplan zullen minimaal 3 dagen en maximaal 1 week beslaan. Overzicht van de benodigde mensen en middelen in de tijd per activiteit (eenheid = dag). Overzicht van de belangrijkste mijlpalen, reviews en kontrole punten in de fase. Elk eind van een activiteit is een controle punt. Een beschrijving van de relaties tussen de activiteiten, aannames en risico's. Veranderingen in het faseplan zijn alleen toegestaan nadat deze zijn goedgekeurd door de projectleider en dienen zoveel mogelijk vermeden te worden. NAVIGATOR QA-FILE (versie 0.2) 6.

5. Voortgangscontrole en rapportage Bij de planning wordt bijgehouden - het bestede aantal uren - het aantal uren nog te besteden - aan welke teamleden de activiteiten zijn toegewezen - de stand van zaken van de activiteiten De projectleider verwerkt de activiteitenrapporten tot het projectweekrapport. Bij het passeren van een maandgrens wordt door de projectleider de projectmaandstaat samengesteld. Richt ing opdrachtgever zal 1keerin._41çej. de voortgang van het project worden gerapporteerd. Dit gebeurt in de vorm van een stuurgroepbijeenkomst. De volgende aspecten worden toegelicht: - afgeronde produkten - onderhanden werk - eventuele problemen - verwachtingen komende periode - detailplanning - mijlpalen in het algemene projectplan - mijlpalen in de faseplannen - uitstaande actiepunten In geval van acute problemen, die snel een oplossing behoeven, kan de stuurgroep frekwenter worden bijeengeroepen. Naast de stuurgroepbijeenkomsten wordt de voortgang ook in het projektteam besproken (elke week). In het volgende schema staan de verschillende ,inclusief de financiele relaties aangegeven:

RWS-Dienst Ve rkee rskunde

1,2,3

TNO - 1,4 WL uitvoerder IWECO van ontwikkeling NAVIGATOR

De codering van de relaties is als volgt: 1 = geldstromen 2 = opdrachtgever en voortgangscontrole 3 = stuurgroep en overleg 4 = projectoverleg


7.

6. Organisatie Het projectteam bestaat uit de projectleider (ir. W.J.A. Mol ) en 2 WLprojectmedewerkers (ir. E.W.B. Bolt en ir. C.J.M. Vermeulen), een aantal WL-systeemanalisten en/of programmeurs en een vertegenwoordiger van TNOIWECO (ir. R. Papenhuijzen). De stuurgroep bestaat uit een vertegenwoordiger van RWS-DVK (ir. H.B. Smits), ir. W.J.A. Mol en ir. J.B.M. Pieffers. De Project SQA-man voor het project is ir. J.H. Laboyrie. Organisatorisch is een en ander als volgt geregeld: Extern 1 Intern RSK RWSDVK

1

Management

RSK S QA Coordinator

Proj ect leider Mol

1

Project SQA-man Laboyrie

Project Project Syst. An. mede- mede- Programm. werker werker WL TNO Bolt Vermeulen

De taken en verantwoordelijkheden zijn als volgt: Projectleider (ir. W.J.A. Mol) - het overleg voeren met de stuurgroep betreffende de voortgang van het proj ect - het afleveren aan de stuurgroep van de eindprodukten, zoals die vastgesteld zijn voor de fase, respectievelijk het project. - het opstellen van projecten fase- middelenplannen - het opstellen van het fase-activiteitenplan - het verstrekken en bewaken van de doelstellingen, verantwoordelijkheden en werkplannen aan en van alle teamleden het informeren van de stuurgroep wanneer afwijkingen van de fase worden verwacht, met aanbevolen acties voor herstel - het oplossen van konflikten tijdens de uitvoering 8. NAVIGATOR QA-FILE (versie 0.2)

Projectmedewerkers Bolt en Vermeulen: De projectmedewerkers zullen zorgdragen voor het globale en technische ontwerp en de testen tijdens implementatie. Projectmedewerker systeemanalist/programmeur: De implementatie van het programma zal worden uitgevoerd door programmeurs en/of systeemanalisten van WL. Projectmedewerker: Papenhuijzen (TNO-IWECO) Zaken betrekking hebbende op planner aspecten worden geadviseerd door TNO. Bovendien zal TNO zich bezighouden met het technisch ontwerp en implementatie van de planner. Project SQA-man ir. J.H. Laboyrie: De kwaliteitsbeoordelende persoon controleert of de door het projectteam opgeleverde eindprodukten overeenstemmen met de normem voor kwaliteitsborging, zoals die zijn beschreven in dit SQAP. De project SQA-man richt zich op alle op te leveren eindprodukten. Opgemerkt wordt dat de project SQA-man geen inhoudelijke en/of organisatorische relatie met het project zal hebben. In de appendix wordt een overzicht gegeven van de adressen van de personen die bij het project betrokken zijn. Wanneer R. Papenhuijzen voor of tijdens het projekt werknemer wordt bij RWS-DVK geldt het volgende: - R. Papenhuijzen blijft projectmedewerker en zal de activiteiten blijven uitvoeren, zoals deze in het werkplan zijn vastgelegd. - H.B. Smits is verantwoordelijk voor: het afleveren aan de stuurgroep van de eindprodukten, zoals die vastgesteld zijn voor de fase, respectievelijk het project van R. Papenhuijzen. het bewaken van de doelstellingen,verantwoordelijkheden en werkplannen van R. Papenhuijzen. het informeren van de stuurgroep wanneer t.a.v. de activiteiten van R. Papenhuijzen afwijkingen van de fase worden verwacht, met aanbevolen acties voor herstel.


9.

7. Reviews en audits Reviews en audits zijn procedures, die gevolgd worden om bepaalde eindprodukten van een fase te beoordelen. Het moment dat deze eindprodukten gereed komen staat in de planning. De beoordeling bij de reviews en audits is gericht op de beantwoording van de volgende vragen: * is het eindprodukt correct (ook kwalitatief) * is het eindprodukt kompleet * zal en kan het werken op de gedefinieerde manier Alle documentatie betreffende reviews en audits worden gearchiveerd.Voor de indeling van de te gebruiken formulieren wordt verwezen naar de appendix. Binnen het project zullen reviews worden gehouden tussen de projectleiders en de projectmedewerkers. Tussen de projectleider en de SQA-man (Laboyrie) zullen audits worden gehouden. De procedure van een review is als volgt: - projectleider organiseert overleg waarbij aanwezig zijn: projectleider projectmedewerker(s) - de te bespreken punten worden voorafgaande de vergadering naar de projectleider gestuurd - op het overleg worden de verschillende punten besproken en worden afspraken gemaakt - verslag wordt opgesteld volgens het daartoe geeigende formulier in de appendix Een audit wordt georganiseerd door de projectleider. De SQA-man kan ten alle tijde een audit ook zelf organiseren.


10.

8. Probleemrapportage en wijzigingsvoorstellen 8.1

Algemeen

Probleemrapportage en wijzigingsvoorstellen hebben betrekking op die fouten die geconstateerd worden nadat het product reeds is goedgekeurd door de stuurgroep. Op twee gebieden is probleem rapportage van toepassing: Ten eerste op de documentatie, ten tweede op de software. 8.2

Documentatie

Probleem rapportage voor documentatie heeft betrekking op de systeem file. Probleemrapportering gaat in zodra het document de status "goedgekeurd" heeft. De stuurgroep bepaalt deze status. Alle inhoudelijke fouten dienen met behulp van een probleemrapport gerapporteerd te worden. Bij de probleemrapporteringsprocedure worden probleemrapporten gebruikt. De indeling van deze formulieren is te vinden in de appendix. Het probleemrapport bevat onder andere de probleembeschrijving, de oorzaken, de oplossingen en de verwachte effecten op het project. De procedure is als volgt: - Diegene die een fout detecteert stelt een probleemrapport op waarin minimaal het probleem omschreven staat. Deze persoon kan ook eventueel oorzaak en oplossing reeds invullen. Het ingevulde rapport wordt aan de projectleider overhandigd. - Blijkt het gerapporteerde probleem een fout of inconsistentie te zijn, zal besloten moeten worden tot het al dan niet opstellen van een wijzigingsvoorstel. - Is aangegeven dat de uitvoering onmiddellijk plaats dient te vinden dan wordt, in overleg met de projectleider bepaald wie de uitvoering gaan doen en wie de uitvoering controleert. - De projectleider houdt de probleemrapporten, wijzigingsrapporten en follow-up activiteiten bij en controleert de openstaande actiepunten. De uitvoering van een probleemoplossing kan betekenen dat nieuwe versies van documenten ontstaan. 8.3

Code

Voor de code is een informele en een formele probleemrapportering te onderscheiden zoals die zijn omschreven in het SQA-handboek. Na de module test zal de programmeur zijn module overdragen aan de persoon die de modulen zal trachten te integreren. Is de module door de integratiepersoon geaccepteerd en treden daarna problemen aan het licht dan zal de formele probleemrapportering gehanteerd worden. De formulieren en procedure zijn in dat geval gelijk aan die zoals die hiervoor beschreven zijn. 8.4

Wij zigingsprocedure

De projectleider is verantwoordelijk voor alle onderdelen van de wijzigingsprocedure. Dit houdt het volgende in: * schrijven wijzigingsvoorstel * verantwoordelijk voor het definieren van het benodigde hertesten/reviewen om de modifikaties te controleren * vaststellen wanneer documenten (inclusief de materie-inbreng) en software (componenten) onder de wijzigingsprocedure vallen. De indeling van de te gebruiken formulieren is te vinden in de appendix. NAVIGATOR QA-FILE (versie 0.2) 11.

9. Configuratiebeheer en wijzigingsbeheer Software Configuratiebeheer (SCB) is het proces van identificeren en definieren van configuratie onderdelen in een systeem, het beheren van de wijzigingsstatus van deze componenten gedurende het gehele "leven" van het systeem, het rapporteren van de status van de componenten en het verifieren dat deze componenten kompleet en correct zijn. De sleutel tot configuratiebeheer is het indelen van systeemdocumentatie en software in configuratiecomponenten. De systeemdocumentatie is hiervoor al beschreven. De indeling van de software wordt verkregen gedurende de ontwerpfase van het project. Elk document dat in de ontwikkelingsfase onder SCB valt is op elke bladzijde vôorzoen van onderstaand kopje:

Project : Document: Doc.id. :

Versie: Datum Auteur:

Onder Doc.id. wordt de identificatiestring vermeld van de volgende vorm: Q.532.08. II.F.nnn met: II = categorieindeling volgens [1] F = aanduiding filetype (zie hoofdstuk 10) S = systeemfile M = managementfile Q = SQA-file nnn = volgnummer

Elk document dient voorzien te zijn van een wijzigingsbiad, dat gebruikt wordt om op elk moment de exacte status van het document te kunnen bepalen. Dit wijzigingsbiad bevat de volgende informatie: - datum wijziging - wie heeft wijziging doorgevoerd - reden wijziging - gewijzigde paragraven - nieuwe versie en/of stautus van het document


12.

10. Documentatie De documentatie wordt in 3 groepen verdeeld: Technische documentatie (systeemfile) Project management documentatie (managementfile) Quality assurance documentatie (QA-file) De navolgende inhoud voor de documenten wordt gehanteerd. Met een cijfer wordt aangegeven tot welke groep documentatie het document behoort. *SQAP 3 • Reviews 3 • Middelen en activiteitenplan voor de globaal ontwerpfase 2 • Globaal ontwerp 1 - systeem ontwerp document - gemeenschappelijk bestand document • Middelen en activiteitenplan voor de technisch ontwerpfase 2 • Technisch ontwerp 1 - detailontwerp modules - programmaontwerp standaarden - datastructeren en interne interfaces - detail programmabeschrijving - programmastructuur * Bouw-en teststrategie 1 * Middelen en activiteitenplan voor de ontwikkelingsfase 2 * Programadocumentatie 1 - systeemdocumentatie - gebruikersdocumentatie * Sourcecode 1


13.

11. Gereedschappen De navolgende gereedschappen zullen worden gebruikt cq. toegepast: - IBM-PS/2 compatible computers gebaseerd op 80386 chip, met 80387 coprocessor, EGA kleurenkaart, 16 kleuren en muis - operating SCO Xenix Sytem 386 - Microsoft C compiler - X-windows - operating system MS-DOS met Turbo C Professional 2.0 compiler - editor - planningspakket (SPE) - tekstverwerker (WF) - communicatie (Reflection, Kermit) - libraries (plot, HALO, IMSL, NAG) - schermroutines Pluto en Venus Afgezien van X-windows zijn al deze gereedschappen bij WL aanwezig.


14.

12. Ontwerpstandaarden

In de ontwerpfase zal gebruik worden gemaakt van de SADT-methodiek [5] en van de Yourdon-ontwerpmethodiek [6] en [7].


15.

13 Codeerstandaarden In de eerste fase van het NAVIGATOR-project is gecodeerd in C. Voor wat betreft de layoutvoorschriften en codeerrichtlijnen wordt verwezen naar het SQA-Handboek [1]. De header van elke module, subroutine of function is als volgt:


16.

* * +

* 1 * WATERLOOPKUNDIG LABORATORIUM

-+

* 1 " de Voorst " * * + ------------------------------------------------------------------ + * * Latest update : xx - xx - 1988 * ************************** N A A M . C **********************************

* * Projekt :

*

* Programmeur . ..................

*

* Funktie . ...................................................

* * *

* Programma beschrijving:

* * * * *

* Parameters (Input / Output)

* *

* Nummer Naam I/o Omschrijving

* ---- --* 1 * 2

*

* Aanroepen (Funkties en / of Subroutines)

* *

* Naam Filenaam Omschrijving * ----

* * * *


17.

14. Testen 14.1 Inleiding Testen is de enige manier om na te gaan of software werkt en functioneert volgens specifikaties. Gedurende de realisatie van het systeem worden module-/programmatesten en integratietesten uitgevoerd. Systeemtesten en acceptatietesten worden in dit projekt niet uitgevoerd. Voorafgaand aan het testen moeten er een aantal testprincipes en testplannen worden opgesteld. Deze testplannen kunnen echter pas worden gemaakt als er duidelijkheid en overeenstemming is over: * testmethodes * integratiemethodes * opzet van testbestanden * teststrategie De testspecificaties worden opgesteld tijdens de technisch ontwerpfase. 14.2 Uitgangspunten bij testen Bij het voorbereiden en uitvoeren van testen moet men de volgende principes hanteren: * De functie van het testen is twee-ledig: - controle op procedures - constateren en het vinden van fouten. Een belangrijk deel van testset wordt derhalve gevormd door een definiering van de niet-te-verwachten resultaten. * Een programmeur test niet zijn eigen programma. * Een bouwgroep test niet de zelf ontwikkelde programmatuur. * Er worden geen wegwerp testbestanden gemaakt. * Bij het opmaken van een planning moet men rekening houden met fouten Het testplan moet bestaan uit de volgende onderdelen: * de doelstellingen van het testen * de gekozen testmethodes * testprocedures de weg die gevolgd wordt, wie waar verantwoordelijk voor is, en de wijze waarop fouten afgehandeld worden * de wijze waarop het eindresultaat wordt opgeleverd * de gekozen methodes met betrekking tot opbouw en gebruik van testbestanden * de voor het testen benodigde apparatuur * de in te zetten personen * kriteria die aangeven wanneer het testen gereed is


18.

REFERENTIES Handboek voor informatica projecten Deel 1 en 2, Versie 1.00 Waterloopkundig Laboratorium Maart 1989 Evaluatie TOW "Sturen van schepen" maart 1988 WL, Q706 Functionele specificaties maart 1989 WL, Q900.00 Offerte vervolgproject maart 1989 WL, Q900.95 "Structured Analysis and Design Technique" SADT Softech Report, 1976 Structured Analysis and System Specifications, T. de Marco, Yourdon Press, 1979. The practical guide to structured system design, M. Page-Jones, 1981.


19.

APPENDIX MET FORMULIEREN EN ADRESSEN - probleemrapportage - wijzigingsvoorstel - evaluatie wijzigingsvoortsel - review uitnodiging - review verslag - review actielijst - documenten statuslijst - adressen


20.

PROBLKEMRAPPORT PROJECT: PROBLEEM RAPPORT NuMMER:

PROJECTNR.: FILE:

GERAPPORTEERD DOOR:

DATUM:

/ /19

FASE:

ONDERWERP:

OORZAAK:

OPLOSSING:

EFFECT OP HET PROJEKT:

UITVOERING ONMIDDELIJK / UITERLIJK VOOR; REFERENTRIES:

GESCHREVEN DOOR:

DATUM:

/ / 19

ONDERZOCHT DOOR:

DATUM:

/ / 19

PROJEKT LEIDER :

DATUM:

/ / 19


21.

WIJZIGINGSVOORSTEL

PROJECT: WIJZIGINGSVOORSTEL NR.:

PROJECTNR.: DATUM: / / 19

FILE:

GERAPPORTEERD DOOR:

FASE:

REFERENTIES: VOORSTEL:

PLANNINGSGEVOLG:

PRIJS KONSEKWENTIES:

OPMERKINGEN:

Handtek.

(klant):

O GOEDGEKEURD / / 19

DATUM: Handtek.

(WL):

O VERWORPEN DATUM:


/ / 19

22.

EVALUATIE WIJZIGINGSVOORSTEL

PROJECT: WIJZIGINGSVOORSTEL NR.:

PROJECTNR.: FILE:

GERAPPORTEERD DOOR:

DATUM: / / 19 FASE

GEEVALUEERD DOOR:

CONSEQUENTIES

1 ACTIVITEITEN / UIT TE VOEREN TAKEN 1

URENSCHATTING

TOTAAL:


23.

1

REVIEW UITNODIGING

PROJECT: REVIEW NUMMER:

PROJECTNR.:

FILE:

REVIEW LEIDER:

DATUM: / / 19 FASE

LOCATIE DATUM: / / 19

[—

T!jD:

DEELNEMERS:

LIJST VAN TE REVIEWEN PRODUCTEN: 1

......................................................................

2

......................................................................

3

......................................................................

4

......................................................................

LIJST VAN AANDACHTSPUNTEN:


24.

REVIEW VERSLAG PROJECT:

REVIEW NUMMER:

PROJECTNR.: DATUM: / / 19

FILE: FASE:

REVIEW LEIDER: LOCATIE: DATUM: / / 19

TIJD:

REVIEW TEAM:

ONDERWERP VAN DE REVIEW: IDENTIFICATIE

GEACCEPTEERD O ZONDER WIJZIGINGEN O KLEINE WIJZIGINGEN NAAM

OMSCHRIJVING

NAAM

BIJLAGEN

NIET GEACCEPTEERD 0 BELANGRIJKE WIJZIGINGEN 0 AFGEKEURD 0 REVIEW NIET GEREED FUNCTIE


0 AKTIEPUNTEN LIJST

DATUM

HANDTEK.

25.

REVIEW ACTIEPUNTENLIJST

PROJECT: REVIEW MR.:

FILE:

AUTEUR:

PROJECTNR.: DATUM: / / 19 FASE

BEHOREND BIJ: ACT IEPTJNTEN ACTIE NR.

OMSCHRIJVING

TYPE

GEWICHT

TYPE : Additie / Tegenstrijdig / Ontbrekend / Overbodig / Suggestie GEWICHT: Belangrijk / Minder belangrijk / Cosmetisch


26.

DOCUMENT STATUSLIJST

PROJEKT:

PROJEKTNR.:

DOC. ID . OMSCHRIJVING AUTEUR VERSIE STATUS DATUM NuMMER REVIEW


27.

ADRESSEN

mevr. ir . M.P. Bogaerts ir. H.B. Smits Rij kswaterstaat Dienst Verkeerskunde Hoofdafdeling Scheepvaart Postbus 494 3300 AL Dordrecht ir. R. Papenhuijzen TNO- IWECO Postbus 29 2600 AA Delft tel. 015-608608 ir. W.J.A. Mol ir. J.H. Laboyrie ir. J.B.M. Pieffers ir. E.W.B. Bolt ir. C.J.M. Vermeulen Waterloopkundig Laboratorium Postbus 152 8300 AD Emmeloord tel. : 05274-2922


28.

• locatie 'De Voorst'

• hoofdkantoor

hoofdkantoor Rotterdamseweg 185 postbus 177 2600 MH Delft telefoon (015) 56 93 53 telefax (015) 61 96 74 telex 38176 hydel-ni locatie' De Voorst' Voorsterweg 28, Marknesse postbus 152 8300 AD Emmeloord telefoon (05274) 29 22 telefax (05274) 35 73 telex 42290 hylvo-ni

Noordzee

• Amsterdam • Londen Brussel •

Rij kswaterstaat Adviesdienst Verkeer en Vervoer Bureau Dokumentatie Postbus BA Rotterdam C 7001

Recommend Documents