Invoering en fasering van het project SIMONA

P2: li

Invoering en fasering van het project SIMONA

Guus Segal

Pagina

Inhoud 1

Inleiding

1

2

Indeling in fasen

2

3

Uitwerking van fase 1

7

3.1

7

4

Inschatting van de benodigde middelen


9

4.1

Fase 2a: het rekengedeelte

•

9

4.2

Fase 2b: de pre—processing

10

4.3

Fase 2c: de post-processing

11

4.4


13

5

Aantekeningen bij fase 3

14

6


15

7

Conclusies

16

^

-1-

rijkswaterstaat dienst getijdewateren biblioiheek

Inleiding

4*

Dit rapport is het laatste uit een serie van drie deelrapporten ten behoeve van een vooronderzoek voor het project SIMONA (SImulatie MOdellen van de NAtte waterstaat). SIMONA beoogt de ontwikkeling van een geintegreerd pakket, waarin bestaande en nieuw te ontwikkelen rekenmodellen worden ingehangen. Voordeel van z o ' n geintegreerde aanpak is dat onderhoud en beheer efficienter plaats kunnen vinden, dat er sprake is van uniformiteit van i n - en output naar de gebruiker toe en dat doublures in programmaontwikkeling worden vermeden. Tengevolge daarvan zullen in de toekomst modellen sneller en goedkoper kunnen worden geimplementeerd. In het eerste deelrapport is een inventarisatie gemaakt van pakketten welke veelvuldig bij RWS in gebruik zijn op het gebied van de natte watermodellen. Daarnaast zijn sterke en zwakke punten van de huidige pakketten opgesomd alsmede bij gebruikers levende wensen. In het tweede deelrapport is een eerste aanzet gegeven tot een technisch concept voor SIMONA. Met name is de functionele beschrijving van de globale datastructuur, de memory management en de database uitgewerkt. Bijbehorende tools zijn beschreven. Daarnaast is een opsomming gegeven van een aantal mogelijkheden waarover S I M O N A uiteindelijk dient te beschikken. In dit deelrapport wordt getracht een inschatting te maken van de uit te voeren taken en de daarmee gepaard gaande kosten. Daarnaast wordt een voorstel voor een indeling in fasen gemaakt, waarbij na iedere fase een evaluatie kan plaats vinden en een "go-nogo" beslissing over de rest van het project genomen kan worden. In hoofdstuk 2 wordt een indeling in fasen voorgesteld. Op grond van argumenten wordt voorgesteld om te beginnen met algemene tools en vervolgens W A Q U A onder te brengen in S I M O N A . Latere fases worden wat vager gehouden. Daarnaast lijkt een onderzoek naar de functionaliteit van D E L W A Q zeer wenselijk. Fase 1 (tools) wordt nader uitgewerkt in hoofdstuk 3. Een beschrijving van welke tools ontwikkeld moeten worden, wordt gegeven alsmede een schatting van de totale kosten. Hoofdstuk 4 is gewijd aan een nadere invulling van fase 2. Hierbij is als uitgangspunt genomen dat W A Q U A reeds in fase 2 deel gaat uitmaken van SIMONA. B i j de kostenschatting moet in ogenschouw worden genomen, dat ook de bestaande plannen tot vernieuwing van W A Q U A een grote hoeveelheid middelen vereisen.

In de hoofdstukken 5 en 6 worden wat aantekeningen bij de fases 3 en 4 gemaakt. Door de onzekerheid over deze fases is de inhoud noodgedwongen vaag gehouden. Tenslotte dienen nog de volgende opmerkingen te worden gemaakt: — Zoals voor ieder programmapakket geldt ook voor SIMONA dat permanent onderhoud nodig is om het systeem draaiende te houden. Enerzijds dienen er aanpassingen aan de hard- en software ontwikkelingen plaats te vinden, anderzijds dienen fouten opgespoord en hersteld te worden. Daarnaast is het noodzakelijk door middel van uitbreidingen aan gebruikerswensen te voldoen. Indien niet voldoende tijd in het onderhoud wordt gestoken, is een programmapakket reeds bij zijn ontstaan gedoemd weer zeer snel te verdwijnen. — B i j de ontwikkeling van nieuwe programmatuur binnen R W S , welke nog niet meteen in SIMONA wordt ondergebracht, is het verstandig reeds nu rekening te houden met het SIMONA-concept. Indien volgens de SIMONA-standaards wordt ontwikkeld, dan zal het uiteindelijk inbrengen binnen SIMONA relatief weinig werk kosten. Daarnaast wordt het onderhoud van die programmatuur beter gegarandeerd. Als voorbeeld van dergelijke nieuwe programmatuur kan gedacht worden aan de 3D—versie van W A Q U A . — W i l SIMONA een succes worden, dan is het noodzakelijk dat er een intense betrokkenheid is vanuit de R W S bij de ontwikkeling. Voorgesteld wordt om een of meerdere mensen vanuit de I & A structuur actief te laten deelnemen aan de ontwikkeling.

2

Indeling in fasen

In dit hoofdstuk zullen we een globale invulling van de verschillende fasen voorstellen, alsmede een motivering voor deze keuze. De uiteindelijke beslissing over een precieze invulling en de gewenste volgorde zal uiteraard door R W S genomen moeten worden. In fase 1 moeten in ieder geval het ontwerp en de ontwikkeling van de basistools voor SIMONA ter hand worden genomen. Het is duidelijk dat zonder deze basistools SIMONA nooit fatsoenlijk van de grond kan komen. Teneinde fase 1 zo kort mogelijk te laten verlopen, moeten in fase 1 uitsluitend de minimale tools ontwikkeld worden. Eventuele uitbreidingen en verfraaiingen kunnen alsnog in een later stadium worden toege-

voegd. De reden hiervoor is zeer simpel: zonder tools kunnen we niet werken; met alleen maar fraaie tools kunnen we geen enkel probleem oplossen. Fase 2 kan het best worden benut om een van de bestaande applicaties in zijn geheel in SIMONA onder te brengen. Het ontwikkelen van het basisontwerp voor fase 2 kan parallel met fase 1 worden uitgevoerd. De keuze voor een bestaande applicatie boven een volledig nieuwe wordt ingegeven door de gedachte dat S I M O N A binnen afzienbare tijd tenminste voor een type toepassing gebruikt kan worden. Een nieuwe applicatie draagt altijd een element van research in zich en is daarom minder voorspelbaar. In ieder geval geldt dat in fase 2 voor een algemene benadering van pre- en post-processing moet worden gekozen, zodat de verrichte werkzaamheden ook in latere fases benut kunnen worden. Van de bestaande pakketten lijken de volgende het meest in aanmerking te komen om op korte termijn in een SIMONA-kader onder te brengen: W A Q U A (2DH) DELWAQ een deel van de golfprogrammatuur biologische/chemische modellen ( B L O O M / C H A R O N ) Van genoemde pakketten lijkt W A Q U A het meest geschikt om als eerste in SIMONA te implementeren. Redenen hiervoor zijn: •

RWS is (mede)eigenaar van alle onderdelen van W A Q U A ; een groot deel is bij RWS ontwikkeld en als gevolg daarvan beschikt R W S over alle benodigde kennis.

•

W A Q U A wordt zowel binnen als buiten RWS veel gebruikt.

•

W A Q U A is hoognodig aan revisie toe en plannen in die richting zijn al gemaakt. Zelfs indien SIMONA niet ontwikkeld zou worden, dan nog zou een grote inspanning in W A Q U A gestoken (moeten) worden om W A Q U A aan de eisen van deze tijd aan te passen.

•

W A Q U A levert de invoer voor een aantal van de andere programma's, zoals bijvoorbeeld D E L W A Q en de golfprogrammatuur. Zonder W A Q U A kan de koppelingsproblematiek dus niet goed worden aangepakt.

•

Uitbreidingen van W A Q U A (kromlijnig, 3D) zijn in ontwikkeling (of reeds in prototype aanwezig) en kunnen worden voortgezet binnen SIMONA.

Het is duidelijk dat bij het ontwerp van W A Q U A binnen het SIMONA-kader in ieder geval rekening gehouden moet worden met de mogelijkheid van genoemde uitbreidingen. Met name moet de opzet van de datastructuur uitgaan van een kromlijnig grid. Het pakket D E L W A Q lijkt op dit moment nog niet in aanmerking te komen om binnen S I M O N A onder te brengen vanwege de volgende redenen: •

D E L W A Q blijkt functioned nog niet uitontwikkeld; nog niet alle aangekondigde features zijn reeds operationeel.

•

D E L W A Q is binnen het W L ontwikkeld; de kennis van D E L W A Q binnen de R W S is nog te gering, mede omdat de documentatie nog niet aan alle eisen voldoet.

•

Door delen van de RWS is kritiek geuit op de kwaliteit van D E L W A Q . Het is daarom de vraag of de D E L W A Q programmatuur, dan wel de D E L W A Q functionaliteit binnen SIMONA moet worden geimplementeerd.

•

D E L W A Q verwacht een snelheidsveld als invoer, het ligt dus voor de hand de basis (i.e. W A Q U A ) allereerst in S I M O N A onder te brengen.

Omdat binnen de RWS groot belang wordt gehecht aan de functionaliteit van D E L W A Q lijkt het verstandig om toch in een vroeg stadium de mogelijkheid van implementatie te onderzoeken. Het is daarom verstandig om parallel aan het begin van fase 2 een vooronderzoek naar de inhoud en functionaliteit van D E L W A Q te starten. Noodzakelijk voor dit vooronderzoek is dat de benodigde documenten ter beschikking komen. Ten aanzien van de golfprogrammatuur geldt i n veel mindere mate dat zij niet in aanmerking kan komen om in fase 2 in S I M O N A te worden ingebracht. V o o r - en tegenargumenten zijn onder ander: •

De golfprogrammatuur lijkt

zeer

gestructureerd

opgezet;

inpassing binnen

SIMONA zal mogelijk minder inspanning vergen dan voor W A Q U A . (Voorstudie moet dit uitwijzen!)

•

De kennis van de golfprogrammatuur is in mindere mate aanwezig bij de R W S dan de kennis van W A Q U A . Dat pleit ervoor om eerst met W A Q U A te starten en al vast een onderzoek naar de inpassing van de golfprogrammatuur te starten.

•

De golfprogrammatuur gebruikt vaak een snelheidsveld als invoer, waarvoor W A Q U A resultaten als eerste in aanmerking komen. Ook dit wijst in de richting W A Q U A gevolgd door golfprogrammatuur.

•

Uit verschillende gesprekken is gebleken dat de golfprogrammatuur wat betreft gebruikersgemak veel moderner aandoet dan W A Q U A . Dit betekent dat SIMONA in de eerste fase weinig extra toe te voegen heeft aan deze programmatuur. De voordelen van SIMONA zullen pas bij een koppeling tot uiting komen.

Wat betreft de chemische en biologische modellen geldt dat zij volledig ontwikkeld zijn binnen het W L en dat de kennis binnen de R W S nog zeer marginaal is. Daarnaast worden deze pakketten veelal samen met D E L W A Q gebruikt. Het ligt dus voor de hand deze modellen pas na het implementeren van D E L W A Q ter hand te nemen. In plaats van voor een pakket kan in fase 2 uiteraard gekozen worden voor het meteen aanpakken van meerdere pakketten (bijvoorbeeld twee). V o o r - en

tegenargumenten

hiervoor zijn onder andere: •

Indien slechts een pakket wordt ingebracht in S I M O N A dan voegt SIMONA nog niet de wezenlijke uitbreiding richting koppelingsprogrammatuur

toe, terwijl

SIMONA juist met dat doel is opgestart. Het enige dat bereikt wordt, is dat een huidig pakket

"netter" wordt

opgezet

en

meer

gebruikersvriendelijk wordt

gemaakt. •

De gelijktijdige aanpak van meerdere pakketten heeft als nadeel dat de te leveren inspanning aanzienlijk wordt uitgebreid. Als gevolg daarvan is het inschatten van de benodigde middelen veel minder realistisch uit te voeren. Bovendien is de kans dat binnen beperkte tijd een werkend product geleverd kan worden aanmerkelijk kleiner. Als gevolg hiervan bestaat de mogelijkheid dat niet tijdig resultaten kunnen worden getoond en S I M O N A als een mislukt project te boek komt te staan.

Om toch iets van beide argumenten tot hun recht te laten komen, lijkt een goede aanpak te starten met W A Q U A en meteen "constituents" mee te nemen als aparte modules. Hierdoor kan getoond worden dat de koppelingsproblematiek in simpele gevallen eenvou-

dig kan worden aangepakt (althans wat betreft de informatica-technische kant). Het koppelen met andersoortige pakketten moet dan worden uitgesteld tot fase 3. In fase 3 kan de keuze gemakkt worden tot het inbrengen van extra pakketten binnen S I M O N A , dan wel over te gaan tot uitbreiding van de functionaliteit van het in fase 2 ingebouwde pakket. Het ligt voor de hand om fase 3 inderdaad te benutten voor uitbreiding van het aantal applicaties, omdat anders S I M O N A niets anders wordt dan een veredeld W A Q U A (uitgaande van een keuze voor W A Q U A in fase 2) en dat is zeker niet de bedoeling van SIMONA. Pakketten die in aanmerking komen om in fase 3 ingebracht te worden, zijn onder andere: golfprogrammatuur (HISWA, C R E D I Z , P H A R O S , etc.) DELWAQ/transportmodellen TRISULA WAQUA-kromlijnig WAQUA-3D Mogelijk kunnen een aantal van deze pakketten gelijktijdig worden aangepakt, afhankelijk van de beschikbare menskracht. De voorbereidende studies dienen reeds gedurende fase 2 gestart te worden. In ieder geval dient een studie van D E L W A Q ter hand te worden genomen. Tenslotte kunnen de fases 4 en verder benut worden voor het inbrengen van de ontbrekende pakketten en het ontwerpen en ontwikkelen van uitbreidingen van de functionaliteit, waarbij allerlei gebruikerswensen gehonoreerd dienen te worden. In de volgende paragrafen worden de verschillende fases iets nader uitgewerkt. Hierbij is i n fase 2 alleen de keuze W A Q U A bekeken. De inschatting van de benodigde middelen (menskracht en materiele middelen) is alleen voor de fases 1 en 2 gegeven, omdat de latere fases nog te vaag zijn en zeker nog voorstudie vereisen. Een inschatting nu zou prematuur zijn en van realiteit ontbloot. Tenslotte dient nog opgemerkt te worden dat in iedere fase van S I M O N A het volledige ontwikkelingstraject dient te worden gevolgd, te weten:

Definitiestudie Basisontwerp Detailontwerp Realisatie Invoering Onderdeel van het basisontwerp dient ook het ontwerp van een testplan te zijn. B i j de realisatie behoort ook het maken van de handleidingen en de technische documentatie. Na iedere fase ontstaat een mijlpaal welke benut kan worden voor go/nogo beslissingen. Daarnaast kunnen deze mijlpalen benut worden om realistische schattingen over de hoeveelheid benodigde middelen in de volgende fase te maken.

3


Fase 1 behelst het ontwerp en ontwikkeling van de basistools. In principe behoeven alleen die tools ontworpen te worden die in ieder geval nodig zijn om S I M O N A verder te kunnen ontwikkelen (de zgn. minimum tools). In een later stadium van het project ontstaat automatisch de behoefte aan uitbreiding en verfraaiing van deze tools. Minimum tools zijn: — tools voor memory management (zie deelrapport 2) — tools voor de database (zie deelrapport 2) — algemene hulptools: • afhandeling van foutboodschappen • eenvoudig verwerken van algemene batchinvoer • hulproutines voor interactieve invoer • arraygrens checkers • opvragen

van

gebruikersgegevens,

zoals

datum/tijd/gebruikersnaam,

e.d.

(basisroutines hiervan zijn machine-onafhankelijk, de onderliggende machine— afhankelijk) • S I M O N A start en close subroutine

3.1


Voor het ontwikkelen van de programmatuur wordt uitgegaan van senior systeemana-

listen. De term mensmaand is equivalent met 20 mensdagen van 8 werkuren. • memory management

3 mensmaanden

• database

4 mensmaanden

• hulptools

4 mensmaanden (basissysteem)

• bewaking kwaliteit + management

3 mensmaanden

• computerkosten

< f 25.000,=

• reproductiekosten

f 5.000,=

Op te leveren producten zijn algemene tools voor memory management en database, zoals beschreven in het tweede deelrapport S I M O N A . Hierbij dient de kanttekening gemaakt te worden dat de databaseroutines in eerste instantie slechts voor een type array geschikt gemaakt dient te worden (bijvoorbeeld een oplossingsarray) omdat de locale datastructuren nog niet vastliggen. De te leveren hulptools bestaan ook uit een verzameling subroutines; een precieze invulling dient nog gemaakt te worden. Naast de tools moet fase 1 als eindproduct leveren: — gebruikersdocumentatie met een beschrijving van de tools; - testprogramma's voor het testen van de tools. Deze testprogramma's moeten bij iedere uitbreiding c.q. verandering van de tools opnieuw "gerund" worden. Opmerkingen: De bewaking van de kwaliteit moet een essentieel onderdeel van SIMONA uitmaken. Een projectteam (1 a 3 man) beoordeelt de ontwerpen inclusief de users interface. Met name de users interface moet ook voorgelegd worden aan niet—direct betrokkenen (gebruikers) om de logica en de leesbaarheid na te gaan. De ontwikkeling van fase 1 kan in principe op een P C plaats vinden zodat de computerkosten relatief beperkt zijn. B i j reproductiekosten worden ook de typekosten voor de handleidingen gerekend.

4


In fase 2 wordt een bestaand pakket ingebouwd in SIMONA. In hoofdstuk 2 is beargumenteerd dat W A Q U A hiervoor het meest in aanmerking komt. Vandaar dat in dit hoofdstuk alleen een uitwerking voor W A Q U A wordt gegeven. Mocht tot een ander pakket worden besloten, dan zal eerst een extra voorstudie noodzakelijk zijn. De te verwachten inspanning zal ongetwijfeld van dezelfde grootte orde zijn als voor W A Q U A . Om de inspanning voor fase 2 nog enigszins overzichtelijk te maken, splitsen we deze fase i n drie deelfases: 2a

rekengedeelte

2b pre—processing 2c post—processing De keuze van het rekengedeelte in fase 2a is gedaan op grond van het feit dat een gestructureerde aanpak van het rekengedeelte automatisch bepaalt welke invoer noodzakelijk is. Hierbij moeten we ook denken aan input-arrays die het rekenproces sturen. Het is verstandig om bij de invoering van de verschillende fases binnen W A Q U A een migratiepad te volgen. Hiermee wordt bedoeld dat een nieuw ontwikkeld deel in het bestaande WAQUA-pakket ingeplugd wordt. Voordeel van zo'n aanpak is dat niet meerdere versies van W A Q U A dienen te worden bijgehouden. Daarnaast kunnen tussenresultaten getoetst worden in werkelijk gebruik. De extra kosten die hieraan verbonden zijn, behoren tot het onderhoud van W A Q U A en maken geen deel uit van S I M O N A . Opgemerkt dient nog te worden dat in alle fasen geldt dat voor dezelfde grootheden een eenduidige naamgeving gebruikt dient te worden. Naamgeving, zowel als handleidingen dienen in het Engels gesteid te worden.

4.1

Fase 2a: het rekengedeelte

Taken welke in deze fase dienen te worden uitgevoerd zijn: -

Het functioneel splitsen van het rekengedeelte van W A Q U A zodat modules voor het berekenen van een (of een halve) tijdstap te onderscheiden zijn.

-10-

- Het opzetten van modules voor het oplossen van extra transport

(advectie-

diffusie) vergelijkingen. Het betreft hier het inbrengen van constituents, wat meteen gebruikt kan worden om de oplossing van de koppelingsproblematiek (informatica-technisch) te demonstreren. - Opzetten van bovenroutines voor het rekengedeelte op basis van voorgaande en het inbrengen van de lagere niveauroutines. - Inbouw in SIMONA-database. Sturing door middel van array(s). Als basis voor het aangepaste rekengedeelte kan de voor het K N M I ontwikkelde bolcoordinatenversie gelden, omdat deze reeds is gestructureerd en geschikt gemaakt voor vectormachines. Uitbreiding met de in de standaardversie beschikbare functionaliteit is dan wel noodzakelijk, aangezien de KNMI—versie een zeer beperkte functionaliteit heeft. Algemeen geldt dat gestart moet worden met de definitie van een nette, niet te ingewikkelde, locale datastructuur. Hierbij moeten specifieke arrays onderscheiden worden zoals dat in de appendix in deelrapport 2 is gedaan (mesh, probleemdefinitie, etc.). Als eindproduct moet er een nieuwe versie van het WAQUA—rekengedeelte komen. Deze versie moet de functionaliteit van het huidige WAQUA—pakket (rekengedeelte) combineren met het oplossen van een aantal transportvergelijkingen (constituents). Deze nieuwe versie moet voldoen aan de SIMONA—standaards en gebaseerd zijn op de SIMONA memory management en database tools. Halverwege fase 2a kan als mijlpaal een simpele versie van W A Q U A gekoppeld met een transportvergelijking dienen. Hiermee kan getoond worden dat het S I M O N A concept inderdaad werkt. Gebruik in de praktijk moet uitgesteld worden tot aan het einde van fase 2a.

4.2

Fase 2b: de pre—processing

In deze fase moet de pre—processor geheel worden herzien. Daarnaast moet het mogelijk blijven om de oude invoer van de W A Q U A pre-processor te blijven gebruiken.

Ir de definitiefase kunnen de volgende punten aan de orde komen: -

Definieren van een gebruikersvriendelijke invoer.

-

Vertaling van de invoer naar de SIMONA-structuren die in rekengedeelte en post-processing gebruikt moeten worden.

-

Uitsplitsing in een gridgedeelte (coordinates diepte) en probleemdeCnitie (coefCcienten, randvoorwaarden, etc.).

-

Definitie van controles van de invoer, met name ook grafische controles. Hier is een duidelijke interactie met de post-processing aanwezig.

-

Hierbij dient rekening gehouden te worden met uitbreidingen naar kromlijnig W A Q U A , alsmede naar W A Q U A - 3 D .

Opmerkingen: • In eerste instantie dient uitsluitend aan batchinvoer te worden gedacht. Interactieve invoer wordt pas in een latere fase van S I M O N A ingevoerd. • In deze fase van SIMONA moeten nog geen extra faciliteiten als meshgeneratoren, interactief aanpassen van randen, e.d. aangeboden worden. Deze behoren duidelijk tot fase 4 of later van SIMONA. De opzet moet uiteraard wel zodanig zijn dat dit soort modules later eenvoudig kunnen worden ingebracht. Als eindproduct van fase 2b dient een geheel vernieuwde W A Q U A en pre-processor ontwikkeld te zijn. Deze moet gekenmerkt zijn door gebruikersvriendelijke invoer, gebruik maken van de SIMONA tools en resultaten wegschrijven naar de S I M O N A — database. De pre-processor moet meteen aansluiten op het W A Q U A rekengedeelte.

4.3

Fase 2c: de post-processing

In fase 2c moet de aanzet gegeven worden tot de algemene SIMONA-post-processor. Hoewel in deze fase alleen nog post-processing voor W A Q U A plaats vindt, is het essentieel dat bij de ontwikkeling sterk rekening gehouden wordt met latere uitbreidingen, met name voor meer ingewikkelde grids (bijvoorbeeld ongestructureerd en kromlijnig). De uiteindehjke bedoeling is dat er een post-processor komt met meerdere modules.

In de deCnitiefase kunnen de volgende punten aan de orde komen: — Definitie van de functionaliteit (in eerste instantie minimaal de huidige W A Q U A post-processingsmogelijkhedenj. -

Definitie van de invoer van de post-processor.

Modules die onder andere onderscheiden kunnen worden, zijn: • printen van (delen van) data • printen van bijbehorende administratieve gegevens • contourplots • grafieken • vectorplots • plotten van randen van gebieden • plotten van kaarten en bijbehorende teksten • het plaatsen van teksten in figuren • het tekenen van kaders • het plaatsen van adminstratieve gegevens in kaders Tevens moet in de deCnitiefase rekening gehouden worden met de volgende punten: — De bovenroutines moeten binnen SIMONA—kader ontwikkeld worden (bijvoorbeeld de contourplot—routine). De eigenlijke plotroutines kunnen op andere wijze worden verkregen. Te denken valt hierbij aan het gebruiken van de huidige WAQUA—routines (echter beperkt tot rechthoekig grid), routines uit P R E S E N T (door het W L in opdracht van R W S ontwikkeld), of gebruik van commercieel verkrijgbare routines. Eventueel kunnen deze routines zelf ontwikkeld worden. Het vervangen van zo'n tekenroutine door een andere moet eenvoudig te realiseren zijn. — De keuze of een plotroutine zelf ontwikkeld moet worden, dan wel op andere wijze verkregen, hangt af van het kostenaspect. Vragen die hierbij een rol spelen, zijn: • hoe algemeen is de plotroutine? • mag RWS hem in al zijn programmatuur gebruiken en op ieder werkstation? • is de routine geschikt voor ieder werkstation? • wat kost een licentie per machine? • is de routine eenvoudig in SIMONA in te hangen? • wat kosten updates naar nieuwe hardware? Indien de plotroutines gebaseerd

zijn op een bepaald pakket (bijvoorbeeld

UNIRAS) dan gelden deze aspecten voor het hele plotpakket.

-13-

-

In deze fase van SIMONA wordt alleen batchinvoer voor de post-processor ontwikkeld. In een latere fase is interactieve invoer zeker noodzakelijk.

Het op te leveren product aan het eind van fase 2c is een volledig vernieuwde W A Q U A post-processor welke aan de SIMONA-standaards voldoet en gebaseerd is op de S I M O N A tools, database en memory management. Het product is ook geschikt voor later aan SIMONA toe te voegen pakketten.

4.4


Fase 2a rekengedeelte

mensmaanden

•

basisontwerp

4

•

detailontwerp

2

•

realisatie + invoering

4

Fase 2b pre—postprocessor •

basisontwerp

4

•

detailontwerp

6

•

realisatie 4- invoering

5-10

Fase 2c post-processor •

basisontwerp

4

•

detailontwerp

6

•

realisatie + invoering

Computerkosten fase 2:

15-20 f 100.000,= (incl. testen + kleine voorbeelden) f 50.000,= (grote testen)

Kwaliteitsbewaking en management Reproductiekosten

6 mensmaanden f 15.000,=

Naast genoemde taken dient tegelijk met fase 2 (voorjaar 1990) een voorstudie naar de functionaliteit en de inhoud van D E L W A Q worden gestart. Hiervoor moet op 2 mensmaanden worden gerekend.

Opmerkingen: — Het basisontwerp voor de fases 2a, 2b en 2c kan parallel aan fase 1 worden uitgevoerd, dat wil zeggen in het tweede halfjaar 1989. — De schattingen voor detailontwerp, realisatie en invoering van de fases 2a, 2b en 2c zijn uitsluitend indicatief. Een juiste schatting is pas na het basisontwerp aan te geven.

— De werkzaamheden aan de fases 2a, 2b en 2c kunnen parallel worden uitgevoerd.

5


B i j het inbrengen van nieuwe pakketten binnen SIMONA moet men zich steeds afvragen: wat voegt SIMONA toe aan dit pakket, dan wel wat voegt het pakket toe aan SIMONA. Indien een pakket altijd los gebruikt wordt en er geen invoer van andere programma's nodig is, dan is er niet direct een aanleiding dit pakket in S I M O N A onder te brengen. Het onderbrengen van een pakket in SIMONA moet altijd een doel dienen en het belang moet zo groot zijn dat het de kosten rechtvaardigt. Een voorstudie van het betreffende pakket is noodzakelijk. B i j het onderbrengen van een nieuw pakket binnen SIMONA moet de hele fasering, zoals die voor W A Q U A is aangebracht, opnieuw worden uitgevoerd, dat wil zeggen: — definitie invoergedeelte — definitie locale datastructuren — definitie rekenmodules — definitie post-processing Hierbij geldt dat zoveel mogelijk de invoer (indien zinvol) gelijkenis moet gaan vertonen met al eerder gedefinieerde invoer. De post-processingskant betekent een uitbreiding van reeds eerder gedefinieerde post— processing. Reeds eerder in SIMONA ingevoerde post-processing moet voor de gebruiker ongewijzigd benut kunnen worden.

-15-

B i j de definitie van locale datastructuren moeten zo min mogelijk nieuwe structuren worden gedefinieerd, omdat iedere andere structuur extra afbeeldingsroutines vereist, alsmede uitbreiding van alle post-processingsroutines. Het inbrengen van andere pakketten in de SIMONA-datastructuur is in principe een informatica-technische aangelegenheid. Hierbii komt waarschiinliik ook de koppelbaarheid van diverse DakkeUen als problematiek naar voren. Onderzoek zal moeten uitwijzen of koppeling tussen twee pakketten slechts op informatica-technische basis mogelijk is of dat roostertechnische, numeriekwiskundige of zelfs modelmatige aanpassingen nodig zijn. Oplossingen moeten altijd passen binnen de S I M O N A filosofie. Een goede tijdschatting van de hoeveelheid werk die voor het inbrengen van de nieuwe pakketten vereist is, is voor nu moeilijk te maken. Hiervoor is het noodzakelijk dat een goede beschrijving van de programmatuur beschikbaar is, alsmede deskundigheid op het gebied van die programmatuur. Afhankelijk van de kwaliteit van de bestaande programmatuur wordt alleen de functionaliteit in S I M O N A ingebouwd, dan wel het oude pakket in aangepaste vorm. Het is verstandig alvorens zo'n beslissing te nemen, het pakket nader te analyseren en op grond van zo'n analyse tot reele schattingen te komen. Dit betekent in alle gevallen dat er een voorstudie moet worden uitgevoerd. Ook van de kant van R W S wordt voor deze voorstudies inspanning vereist, teneinde de benodigde kennis over te dragen.

6


Pas in fase 4 (wat mogelijk parallel aan fase 3 kan geschieden) lijkt het zinvol om de door gebruikers gewenste uitbreiding van functionaliteit (zoals in het eerste deelrapport geinventariseerd) in te bouwen. Te denken valt hierbij aan: — invoerkant • invoering van mooie menustructuren en muisbesturing (alleen als voldoende krachtige commerciele hulpmiddelen beschikbaar zijn: zelf ontwikkelen vooralsnog te duur) • invoering van gridgeneratoren • interactief aanpassen van bestaande grids • invoering van interactieve invoer (staat los van mooie schermbesturing)

-16-

—

rekengedeelte • manipulaties met vectoren, e.d. • toevoegen van solvers, tijdsintegratoren, e.d. • toevoegen van nieuwe modellen (grondwaterstromingen, advectie—diffusie vergeli jkingen, e.e.m., etc.) • calibratie mogelijkheden, Kalmanfiltering

— post—processing • bewegende beelden • kleurenplaatjes (kleuren niveau's) • 3D—plot programmatuur •

nabewerkingsprogrammatuur

• mogelijkheden tot manipuleren met verschillende arrays Gezien het redelijk vage karakter van bovenstaande is het noodzakelijk, alvorens een beslissing tot invoering van onderdelen te nemen, behoeften te peilen en prioriteiten te stellen. Hierbij moet een reele schatting van de kosten een wezenlijke rol spelen. Het lijkt prematuur nu reeds een kostenplaatje aan fase 4 te verbinden. Wel lijkt het zeer zinvol in ieder geval budget te reserveren om na te gaan wat gebruikerswensen zijn en wat voor technische mogelijkheden er zijn. Dit houdt onder andere ook in nagaan wat er in de markt te koop is en kijken of dit binnen S I M O N A gebruikt kan worden. Steeds moet dan overwogen worden wat het kost z o ' n product aan te schaffen (inclusief de kosten voor verschillende machines en updates), alsmede de niet te verwaarlozen inbouwkosten, vergeleken met de kosten om zelf z o ' n product te bouwen met reeds aanwezige tools.

7

Conclusies

In de drie deelrapporten voorstudie S I M O N A is een inventarisatie naar de door RWS gebruikte pakketten op het gebied van de Natte Waterstaat uitgevoerd, alsmede nagegaan wat behoeften binnen RWS zijn op het gebied van programmatuur. Uit die inventarisatie is naar voren gekomen dat er duidelijk behoefte is aan de uitvoering van het project SIMONA met name om de koppelingsproblematiek tussen verschillende pakketten op te lossen, maar daarnaast zeker ook om tot uniformiteit van nabewerkingsprogrammatuur te komen. Een ander aspect dat de invoering van S I M O N A wenselijk maakt, is de behoefte aan gebruikersvriendelijke invoer, waarbij moderne hulpmiddelen benut kunnen worden.

•

Vanuit geschetste behoeften is een globale datastructuur, een memory management structuur, alsmede een database voorgesteld. Het ontwerp is zodanig opgesteld dat met name de koppelingsproblematiek is teruggebracht tot zijn modelmatige (niet-informatica-technische) kern en tevens dat de uniformiteit in post-processing een natuurlijke zaak wordt. Tenslotte is in dit deelrapport een indeling in fases voorgesteld, alsmede een schatting van de daarbij benodigde middelen. Uit genoemde cijfers blijkt dat S I M O N A een meerjarenproject is, waarbij een significante inspanning t.a.v. budget en menskracht vereist is. Daarnaast is er een permanente inspanning nodig om S I M O N A te onderhouden. Samenvattend kan worden gesteid dat het project SIMONA zeker haalbaar is. Een eerste eindproduct, bevattende de WAQUA-functionaliteit gekoppeld met een aantal transportvergelijkingen, is zeker niet voor eind 1990 te verwachten. Koppeling met andere pakketten kan eerst in latere jaren gerealiseerd worden.

Invoering en fasering van het project SIMONA

Recommend Documents