Werkdocument X Drs. A.C. Krings, J. Duker datum HANDBOEK APPLICATIE- BEHEER. ministerie van verkeer en waterstaat

Maat: px
Weergave met pagina beginnen:

Download "Werkdocument 92.082X Drs. A.C. Krings, J. Duker datum HANDBOEK APPLICATIE- BEHEER. ministerie van verkeer en waterstaat"

Transcriptie

1 ministerie van verkeer en waterstaat rijkswaterstaat riza rijksinstituut voor integraal zoetwaterbeheer en afvalwaterbehandeling tel , fax doorkiesnummer HANDBOEK APPLICATIE- BEHEER Werkdocument X auteur(s) Drs. A.C. Krings, J. Duker datum 2 juni 1992

2

3 ALGEMEEN

4 Onderwerp : Algemeen Blad: 0-1 INHOUD 1. Inleiding 2 2. Soorten onderhoud 2 3. Karakter van onderhoud 2 4. Motivatie 2 5. Doel en inhoud van het handboek 3

5 RIZArlOSBA Onderwerp: Algemeen Blad: Inleiding Van de totale hoeveelheid tijd en geld die aan automatisering wordt besteed neemt het onderhoud van informatiesystemen een groot deel in beslag. Hoe meer tijd en geld er aan onderhoud wordt besteed des te minder blijft er over voor nieuwbouw. Ondanks het grote belang van onderhoud is de aandacht vanuit het management voor dit onderwerp over het algemeen gering. Recente onderzoeken hebben uitgewezen dat binnen de meeste organisaties de helft tot twee derde van de beschikbare capaciteit besteed wordt aan onderhoud. Maar wat is onderhoud precies? 2. Soorten onderhoud Onderhoud van informatiesystemen omvat meer dan alleen het verbeteren van fouten in de software. Ook het aanpassen van systemen aan gewijzigde wensen van de gebruikers valt onder onderhoud. Daarnaast wordt er ook vaak onderhoud gepleegd om de performance of onderhoudbaarheid van systemen te verbeteren. In het algemeen wordt onderhoud opgedeeld in drie categorieen: 1. Correctief onderhoud : het herstellen van fouten; 2. Adaptief onderhoud : aanpassen en uitbreiden van systemen naar aanleiding van wensen van gebruikers; 3. Perfectief onderhoud : het verbeteren van de performance of van de technische kwaliteit van het systeem in het algemeen. Van deze drie neemt adaptief onderhoud het grootste deel van de onderhoudsinspanning voor haar rekening. 3. Karakter van onderhoud. Over het algemeen is onderhoud complexer en veeleisender dan nieuwbouw. De voornaamste reden hiervoor is dat onderhoud, in het bijzonder correctief onderhoud, vaak onder grote tijdsdruk dient te geschieden. Daarnaast begint men bij onderhoud niet met een schone lei, maar met een bestaand systeem waarvan de exacte werking eerst doorgrond moet worden. 4. Motivatie Onderhoud wordt in de meeste omgevingen sterk ondergewaardeerd. Het lijkt beter voor de carriere ontwikkeling om in nieuwbouw actief te zijn, waar de modernste technieken worden toegepast en met flitsende grafisch ondersteunde CASE-tools wordt gewerkt, dan in onderhoud, waar men vaak met, per definitie (ver)ouder(d)e

6 Onderwerp: Algemeen Blad: 0-3 omgevingen ie maken heeft. Deze onderwaardering is geheel ten onrechte, daar het goed functioneren van de informatiesystemen het grootste deel van hun levenscyclus van de onderhoudsafdeling afhankelijk is. 5. Doel en inhoud van het handboek Het handboek applicatiebeheer is opgesteld in opdracht van de sectie applicatiebeheer (IOSBA) van het RIZA. De aanleiding tot het opstellen van het handboek was de behoefte het beheer van applicaties, zoals dat door de sectie IOSBA wordt uitgevoerd, meer structuur te geven. Deze behoefte spitste zich toe op het ontbreken van standaards, procedures en richtlijnen ten aanzien van het beheer en onderhoud van applicaties. Tevens bleek er behoefte te bestaan aan duidelijke afspraken ten aanzien van de samenwerking met andere afdelingen of organen binnen de RIZA-organisatie. Het doel van het handboek applicatiebeheer is duidelijk te maken hoe onderhoud moet (of kan) worden uitgevoerd. Verschillende aspecten die direct of indirect met onderhoud te maken hebben komen hierbij aan bod. Niet alleen wordt gekeken naar het onderhoudsproces zelf, maar ook worden de procedures en richtlijnen behandeld die van toepassing zijn op de samenwerking met andere delen van de organisatie. Hierdoor is het voor eenieder die met applicatiebeheer te maken heeft of krijgt (zoals projectgroepen die een systeem opleveren of gebruikers die hun systeem in onderhoud hebben) duidelijk wat zij van applicatiebeheer kunnen verwachten en wat applicatiebeheer van hen verwacht. In deel 1 wordt de organisatie van het beheer van geautomatiseerde systemen in beeld gebracht. Er wordt ingegaan op de taken en doelstellingen van de sectie IOSBA, alsmede de plaats die deze sectie in de RIZA-organisatie inneemt. De verschillende vormen van beheer van een applicatie worden hiertoe in kaart gebracht en de plaats van applicatiebeheer hierin wordt toegelicht. Tenslotte wordt, uitgesplitst naar typen hardware, uitgelegd hoe de algemene invulling van de verschillende beheersvormen dient te geschieden. In deel 2 van het handboek worden de procedures toegelicht die rondom het onderhoudsproces gehanteerd moeten worden. De nadruk ligt hierbij op het versie-gewijs werken en de overdrachts- en acceptatieprocedures. In deel 3 wordt aangegeven welke methode er bij het uitvoeren van een onderhoudsopdracht gehanteerd moet worden. Het onderhoudsproces wordt hiertoe opgedeeld in een aantal stappen die achtereenvolgens worden uitgevoerd. De nadruk ligt in dit hoofdstuk op het feit dat onderhoud niet beperkt is tot het aanpassen van programmacode, maar dat ook het testen van de programmatuur en het aanpassen van documentatie bij onderhoud hoort.

7 Onderwerp: Algemeen Blad: 0-4 In het laatste deel van hel handboek, deel 4, worden <.k documentatiestanda-jtds behandeld. Voor ieder type handleiding wordt een globale beschrijving gegeven van de inhoud, alsmede van de eventueel toe te passen (teken)technieken voor het aanmaken en onderhouden van documentatie. Tenslotte wordt een aantal formulieren besproken die de procedures rondom het onderhoud dienen te begeleiden.

8 DEEL I: ORGANISATIE

9 Onderwerp: Organisatie Blad: 1-1 INHOUD 1. Inleiding 2 2. Taken en doelstellingen IOSBA Doelstelling sectie IOSBA Taken sectie IOSBA rganogram en relatie met andere secties en (onder)afdelingen 6 3. Beheervormen Inleiding Functioneel beheer informatiesystemen Gegevensbeheer informatiesystemen Applicatiebeheer informatiesystemen DBMS-beheer informatiesystemen Computerbeheer informatiesystemen Beheer van de huidige systemen Inleiding Beheer van systemen die op een PC zijn gei'nstalleerd Beheer van systemen op andere hardware Overzicht beheer per systeem 23

10 Onderwerp: Organisatie Blad: Inleiding Om het onderhoud naar behoren te kunnen uitvoeren is het van belang dat de organisatie hierop is ingesteld. In de praktijk blijkt vaak dat onderhoud 'erbij'wordt gedaan door degene die de applicatie heeft gebouwd, of dat het ergens in de organisatie wordt ondergebracht waar dat het gemakkelijkst uit komt. Voordat we kunnen bepalen welke applicaties er beheerd moeten worden, dienen we vast te leggen wat we onder de term beheer verstaan. Het komt heel vaak voor dat men binnen dezelfde organisatie verschillende dingen verstaat onder de term beheer. Pas nadat hierover duidelijkheid bestaat, kan men afspraken maken over de organisatie van het beheer. De sectie IOSBA is opgericht voor het uitvoeren van het applicatiebeheer. Allereerst worden in dit hoofdstuk de doelstellingen van de sectie uiteengezet, waarna vervolgens de vormen van beheer aan bod komen.

11 Onderwerp : Organisatie Blad: Taken en doeblellinueii IOSBA 2.1. Doelstelling sectie IOSBA De sectie IOSBA maakt deel uit van de onderafdeling IOSB die zorg draagt voor de beschikbaarheid van landelijke waterhuishoudkundige gegevens. De onderafdeling houdt zich bezig met de produktie van gegevens en met de presentatie daarvan in diverse vormen, zoals periodieke rapportages en rapportages via de media. De onderafdeling maakt hiervoor gebruik van een groot scala aan automatiseringsmiddelen. Diverse hardware-configuraties alsmede een grote hoeveelheid softwareapplicaties staan de onderafdeling ter beschikking voor een adequate taakuitvoering. Net als binnen veel andere organisaties is binnen RIZA het applicatiebeheer lange tijd een onderbelichte zaak geweest. Dientengevolge zijn er in het verleden vele applicaties in gebruik genomen, waarbij geen voorzieningen zijn getroffen voor het beheer van deze applicaties. In 1989 is binnen de onderafdeling IOSB van de afdeling IOS de sectie Applicatiebeheer opgericht. Deze sectie heeft tot doel vorm te geven aan het applicatiebeheer van de aan haar in onderhoud gegeven applicaties. De sectie richt zich hierbij in eerste instantie op de eigen onderafdeling, doch heeft ook enige applicaties in beheer die elders binnen de dienst worden gebruikt. Verder wordt vanuit de sectie ondersteuning gegeven aan IO-medewerkers v.w.b. gebruik en beheer van P.C.'svoor zover dit valt onder de werkzaamheden die uitgevoerd worden binnen het kader van het DAK (Decentrale Automatiserings Kern). Het applicatiebeheer dat IOSBA zich tot doel stelt, houdt het volgende in: Zorg dragen voor betrouwbare applicaties waarin de door de gebruikers gedefinieerde functionaliteit is gewaarborgd. Vergroten van de levensduur van applicaties door deze in een goede staat van onderhoud te brengen, c.q. te houden. Zodanige inrichting van de uitvoering van het applicatiebeheer, dat voor iedereen die betrokken is bij de te onderhouden applicaties, duidelijkheid ontstaat omtrent de gevoerde werkwijze.

12 Onderwerp: Organisatie Blad: Taken sectie IOSBA Om de taken van de sectie goed te kunnen afbakenen, dient er duidelijkheid te zijn omtrent de vormen van beheer die uitgevoerd worden. Hiervoor zijn alle beheerwerkzaamheden betreffende een applicatie ondergebracht in vijf categorieen : - functioneel beheer - gegevensbeheer - applicatiebeheer - DBMS-beheer - computerbeheer De exacte omschrijving van deze vijf begrippen is opgenomen in hoofdstuk 3 van dit deel van dit handboek. Hier volgt reeds een korte omschrijving : - functioneel beheer De functioneel beheerder van een informatiesysteem dient als eerste aanspreekpunt voor gebruikers. Hij/zij beheert de functionaliteit die het systeem biedt, verzamelt de wensen van gebruikers en coordineert wijzigingen die in de functionaliteit moeten worden aangebracht. Hij/zij leidt gebruikers op. - gegevensbeheer Hij/zij heeft de verantwoording voor het beheer van de gegevens, en ziet toe op een correct gebruik van de gegevens uit het informatiesysteem. - applicatiebeheer Voor problemen die meer op het vlak van programmatuur e.d. liggen, kan de functioneel beheerder een beroep doen op de applicatiebeheerder van het informatiesysteem. Hij/zij heeft de verantwoording voor het beschikbaar zijn van het systeem, en de juiste werking ervan. Tevens vertaalt hij/zij wensen in nieuw te ontwikkelen programmatuur, of doet aanpassingen in reeds bestaande programmatuur. - DBMS-beheer Onder deze vorm van beheer valt het onderhouden van het DBMS, tunen van applicaties op het DBMS en adviseren bij ontwerp van databases op het betreffende DBMS.

13 Onderwerp: Organisatie Blad: computerbeheer Hieronder valt het beheer van computerhardware en systeemsoftware en de zorg voor de beschikbaarheid ervan. Maken van back-ups, verhelpen en melden van storingen aan de leveranciers vallen ook onder deze vorm van beheer. De taken die onder het applicatiebeheer vallen en welke uitgevoerd worden door de sectie Applicatiebeheer, kan men nu als volgt omschrijven : Participeren in nieuwbouwprojecten waarvan later het applicatiebeheer bij IOSBA wordt ondergebracht. Dit teneinde vroegtijdig (liefst in het ontwerpstadium) de belangen van een goed uitvoerbaar applicatiebeheer te kunnen waarborgen. Mede opstellen van functionele specificaties a.d.h.v.wensen van gebruikers m.b.t. wijzigingen in bestaande programmatuur en deze vervolgens doorvoeren. Op peil houden c.q. brengen van de kwaliteit en de staat van onderhoud van de applicaties. Uitvoeren van werkzaamheden die behoren tot het takenpakket van een DAK (Decentrale Automatiserings Kern).

14 Onderwerp: Organisatie Blad: iganogram en relatie nui amltrt- MI lie. en (onder)afdelingen Dit schema geeft de positie weer van de sectie Applicatiebeheer binnen de afdeling IO van de dienst RIZA. RIZA AO WS RA IO BX PX IOI IOS IOL IOSO IOSA IOSB IOSM IOSBG IOSBA [ IOSBC

15 Onderwerp: Organisatie Blad: 1-7 In het kort zal nu geschetst worden hoc de relatie tussen de verschillende secti (onder)afdelingen en de sectie IOSBA ligt. Sectie Applicatiebeheer (IOSBG). (IOSBA) in relatie tot de sectie Gegevensbeheer Voor sommige informatiesystemen zal de functioneel beheerder en de gegevensbeheerder bij IOSBG zijn geplaatst. Deze fungeert als eerste aanspreekpunt voor de gebruikers. Hij/zij ziet toe op een correct gebruik van het informatiesysteem. Hij/zij zal eventueel gebruikers bijstaan, dan wel opleiden. Voor problemen die meer op het vlak van programmatuur e.d. liggen, kan de functioneel beheerder een beroep doen op de applicatiebeheerder van het informatiesysteem (IOSBA). Hij/zij heeft de verantwoording voor het beschikbaar zijn van het systeem, en de juiste werking ervan. Tevens vertaalt hij/zij wensen in nieuw te ontwikkelen programmatuur, of doet aanpassingen in reeds bestaande programmatuur. Ook wordt door de applicatiebeheerder de systeemdocumentatie 'up to date' gehouden. Sectie Applicatiebeheer (IOSBC). (IOSBA) in relatie tot de sectie Berichtencentrum Een groot deel van de op het BC draaiende programmatuur is voor onderhoud ondergebracht bij IOSBA. Dit houdt in dat IOSBA verantwoordelijk is voor het goed functioneren van deze software op het BC. Het BC voert voor deze applicaties het gegevens- en het computerbeheer uit. Voor een aantal applicaties voert men ook het functioneel beheer uit. Voor wijzigingen in deze software dient met IOSBA contact opgenomen te worden. Sectie Applicatiebeheer in relatie tot de hoofdafdelingen Watersystemen (WS) en Algemeen Onderzoek (AO). De gebruikers van een deel van de applicaties die op het BC is gei'nstalleerd en in onderhoud is bij IOSBA, bevinden zich voor een groot deel binnen de hoofdafdelingen WS en AO. Deze hoofdafdelingen leveren in principe de functioneel beheerder. Sectie Applicatiebeheer in relatie tot de afdeling Informatica binnen de hoofdafdeling Informatie en Ontwikkeling (IOI). Hier vindt het computerbeheer en DBMS-beheer plaats van de applicaties die op de grotere systemen zoals VAX draaien. Ook andere systeemsoftware zoals datacommunicatiepakketten worden door IOI onderhouden.

16 Onderwerp: Organisatie Blad: Behecrvormcn 3.1. Inleiding Dit hoofdstuk gaat uitgebreid in op de vijf vormen van beheer die zijn onderscheiden. Ze definieren de taken en verantwoordelijkheden die tot het beheer behoren. De noodzaak tot het opstellen van deze definities komt voort uit het feit dat de theorie geen eenduidige definities voor deze begrippen aanreikt. Na het creeren van deze duidelijkheid zijn taken beter te definieren. De verschillende vormen van beheer zijn gebaseerd op de onderstaande voorstelling van de opbouw en samenhang van de verschillende componenten van een willekeurig informatiesysteem. FUNCTIONALITEIT APPLICATIE- SOFTWARE OPERATING SYSTEEM HARDWARE Toelichting: Hardware en operating systeem De onderste twee lagen omvatten de hardware waarop het informatiesysteem draait en het operating systeem waaronder dit gebeurt. Deze beide componenten worden beheerd door de computerbeheerder.

17 Onderwerp: Organisatie Blad: 1-9 DBMS Vaak maken informatiesystemen gebruik van een of ander DataBase Management Systeem (DBMS) om gegevens in op te slaan. Het beheer en onderhoud van een dergelijk DBMS vergt meestal zeer specifieke kennis omtrent relationele database technieken en tuning van databases. Beheer van het DBMS is daarom ondergebracht bij een aparte beheerder, de DBMS-beheerder. Deze beheerder kan, gezien de specifiek vereiste kennis, het beste een informatica achtergrond bezitten. Applicatiesoftware De systemen zelf zijn gerealiseerd in de vorm van applicatiesoftware. Onderhoud van deze software vereist specifieke kennis omtrent het ontwerp en bouw van informatiesystemen. Onderhoud van deze component is ondergebracht bij applicatiebeheer. Ook voor deze functie is kennis van automatisering een vereiste. Gegevens Met behulp van een informatiesysteem worden meestal gegevens van de gebruikers vastgelegd en beheerd. Omdat een gebruiker vaak geen inzicht en kennis heeft van de gegevens die door andere gebruikers worden opgeslagen is er een aparte functionaris voor het beheer van de totale gegevensverzameling van het informatiesysteem in het leven geroepen: de gegevens-beheerder. Omdat inhoudelijke kennis van de gegevens noodzakelijk is, kan deze beheerder het beste uit de gebruikerswereld afkomstig zijn. Functionaliteit Het systeem is er voor de gebruikers. Aangezien de wensen van gebruikers ten aanzien van de functionaliteit van het systeem over het algemeen aan veranderingen onderhevig zijn zal ook het informatiesysteem qua functionaliteit mee moeten verander. De functioneel beheerder verzamelt de gebruikerswensen t.a.v. de functionaliteit van het systeem en coordineert de veranderingen die in de functionaliteit moeten worden aangebracht.

18 Onderwerp: Organisatie Blad: Functioneel beheer informatiesystemen Functioneel Beheerder FUNCTIONAUTEIT Gebruikers Het doel van functioneel beheer is het zorg dragen voor een, qua functionaliteit, op de behoeften van de eindgebruikers aansluitende applicatie. In dat kader treedt degene aan wie het functioneel beheer is opgedragen op als intermediair tussen de eindgebruikers en de applicatiebeheerder van de applicatie. Onder de taken van de functioneel beheerder wordt verstaan : Fungeren als aanspreekpunt voor management, eindgebruikers, applicatiebeheer, computerbeheer, DBMS-beheer en gegevensbeheer voor de functionele aspecten van de beheerde applicatie. Bewaken dat de geboden functionaliteit van de applicatie zo goed mogelijk overeen blijft stemmen met de veranderende bedrijfsprocessen waarvoor de applicatie is ontwikkeld. Inventariseren van eisen en wensen van eindgebruikers en deze voorleggen en bespreken met de applicatiebeheerder en de gegevensbeheerder. De wensen en eisen worden vastgelegd in functionele wijzigingen. Bewaken dat er overeenstemming bestaat tussen eindgebruikers over door te voeren wijzigingen in de applicatie. Onderhouden van de gebruikersdocumentatie en de vastgelegde procedures m.b.t. de applicatie, dit in samenwerking met de applicatiebeheerder. Coordineren van de acceptatietest door eindgebruikers in geval van oplevering

19 Onderwerp : Organisatie Blad: 1-11 van (een nieuwe versie van) de applicatie. Zorg dragen voor tijdige opleiding van eindgebruikers inzake het gebruik van de applicatie. Deelnemen aan overlegstructuren met andere functioneel beheerders teneinde een uniform beheer van applicaties binnen de organisatie te waarborgen, alsmede het maken c.q. aanscherpen van richtlijnen m.b.t. het beheren van gegevensdefinities (Data Dictionary) bij ontbreken van D.D.-functionaris. Het registreren en bewaken van de werking van het systeem aan de hand van overeengekomen prestatienormen, en het toezien op een tijdige verwerking van gegevens en oplevering van informatie uit het systeem. Coordineren van door eindgebruikers gesignaleerde storingen in de applicatie en deze melden aan applicatiebeheer. Het handhaven van beveiligingseisen door toezicht op verleende autorisatie en het coordineren van de werkzaamheden bij het in werking treden van uitwijkprocedures in geval van langdurige storing.

20 Onderwerp: Organisatie Blad: Gegevensbeheer informatiesystemen Gegevens- Beheerder MlCMALITEJ!,SCFTW^E ilgegfvens_ I i'wms Gebruikers Dit is het onderdeel dat verantwoordelijk is voor het beheer van de gegevens in de database van de applicatie. De gegevensbeheerder neemt gegevens op uit andere systemen of levert deze aan voor andere systemen. Tevens controleert hij/zij de gegevens die door de gebruikers in de database worden opgeslagen op vervuiling, volledigheid en redundantie. Daarnaast maakt de gegevensbeheerder specifieke rapportages die buiten het aandachtsgebied van de "gewone" gebruiker vallen. Voor de gegevensbeheerder kunnen de volgende taken worden gedefinieerd : Fungeren als aanspreekpunt voor management, eindgebruikers, functioneel beheer, computerbeheer, DBMS-beheer en applicatiebeheer voor de operationele aspecten van de applicatie. Adviseren met betrekking tot en mede opstellen van procedures inzake gebruik en beheer van de applicatie. Bewaken en signaleren aan functioneel- en applicatiebeheer van vermindering van de beschikbaarheid van de applicatie. Gebruikers autoriseren voor de betreffende applicatie middels het uitgeven van User-ids en passwords. Het toezien op de integriteit van de door de applicatie gehanteerde gegevensverzamelingen c.q. deelverzamelingen en het actueel houden van deze gegevens.

21 Onderwerp: Organisatie Blad: Applicatiebeheer informatiesystemen Applicatie- Beheerder Applicatie Onderhoud i Software Het applicatiebeheer kan worden gezien als de tegenhanger van het functioneel beheer. Het doel van applicatiebeheer is zorg dragen voor een werkende applicatie welke tegemoet komt aan de door de gebruikers gedefinieerde functionaliteit en past binnen de voor applicaties gedefinieerde technische normen. Daartoe kunnen de volgende taken worden gedefinieerd: Fungeren als aanspreekpunt voor management, functioneel beheer, gegevensbeheer, computerbeheer en DBMS-beheer voor de technische aspecten van de applicatie. Adviseren en bieden van ondersteuning bij het opstellen van de functionele specificaties van de applicatie. Vertalen van door te voeren wijzigingen naar concrete aanpassingen in programma's en procedures van de applicatie en deze afstemmen met functioneel beheer en gegevensbeheer. Adviseren van functioneel beheer en management inzake te gebruiken apparatuur en standaard-programmatuur, gericht op de in beheer zijnde applicaties. Opstellen en onderhouden van de technische documentatie van de applicatie. Doorvoeren van wijzigingen in de programma's en procedures van de applicatie. Het betreft wijzigen : - Naar aanleiding van functionele specificaties (Adaptief onderhoud). - Ter opheffing van optredende fouten (Correctief onderhoud).

22 Onderwerp: Organisatie Blad: Ter verbetering van de efficiency (Pcrfccticf onderhoud). Adviseren en bieden van ondersteuning aan de functioneel beheerder bij de opleiding van eindgebruikers van de applicatie. Adviseren en bieden van ondersteuning bij het gegeven sbeheer van de applicatie. Deelnemen aan overlegstructuren met andere applicatiebeheerders teneinde een uniform applicatiebeheer van applicaties binnen de organisatie te waarborgen. Adviseren bij het tot stand brengen van een software kwaliteitsborgingsysteem.

23 Onderwerp: Organisatie Blad: DBMS-lnluti infill niatiesystemen DBMS Beheer Het DBMS-beheer kan worden gezien als het beheer van omgeving die door de applicatie wordt gebruikt om gegevens in op te slaan. Daartoe kunnen de volgende taken worden gedefinieerd: Fungeren als aanspreekpunt voor management, eindgebruikers, applicatiebeheer, computerbeheer en gegevensbeheer voor aspecten van de beheerde applicatie die te maken hebben met het door de applicatie gebruikte database management systeem. Bewaken en uitvoeren van de gedefinieerde operationele procedures : opstarten/afsluiten van het DBMS, opstarten/afsluiten van de applicatie die op het DBMS draait, maken van back-ups van de database, etc. Gebruikers autoriseren voor het gebruik van het betreffende DBMS middels het toekennen van User-ids en Passwords. Bewaken en zonodig verbeteren van de performance van het DBMS. Generen van nieuwe of gewijzigde tabellen in de database.

24 Onderwerp: Organisatie Blad: Computerbeheer [nformatiesystemen Computer Beheer IFMNCTIONAUTEIT "APPLICATIE-- : SOFTWARE GEGEVENS: : Z W C OPERATING SYSTEEM Operators HARDWARE PC beheerders Dit is het onderdeel dat verantwoordelijk is voor de ongestoorde, juiste en tijdige beschikbaarheid van de hardware en de bijbehorende systeemsoftware. Daartoe kunnen de volgende taken worden gedefinieerd : Fungeren als aanspreekpunt voor management, eindgebruikers, functioneel beheer, gegevensbeheer, gegevensbeheer en applicatiebeheer voor de operationele aspecten van de systeemsoftware en hardware. Bewaken en zonodig zelf uitvoeren van de gedefinieerde operationele procedures : opstarten/afsluiten van de apparatuur, opstarten/afsluiten van de systeemsoftware, maken van back-ups, etc. Adviseren met betrekking tot en mede opstellen van procedures inzake gebruik en beheer van de systeemsoftware en hardware. Bewaken en signaleren aan functioneel en applicatiebeheer van vermindering van de beschikbaarheid van de systeemsoftware en hardware. Testen en invoeren van nieuwe versies van het besturingssysteem en andere componenten van de systeemprogrammatuur. Bevorderen van een doelmatig gebruik van apparatuur en programmatuur (capaciteitsbeheersing en prestatiemetingen). Verhelpen van storingen in de werking van systeemcomponenten, eventueel in samenwerking met de leverancier. Ontwikkelen en onderhouden van standaardroutines en hulpprogrammatuur.

25 Onderwerp: Organisatie Blad: 1-17 Bcdiencn en gebruiksklaar maken cn houden van dc apparatuur, bewaken van de verwerkingsvoortgang, de werking van de computer en de beschikbaarheid van het datacommunicatienetwerk.

26 Onderwerp: Organisatie Blad: Beheer van de huidige systemen 4.1.Inleiding Binnen de sectie Applicatiebeheer worden twee typen systemen onderhouden. systemen die op een PC zijn gei'nstalleerd systemen op andere hardware Aangezien deze systemen op een aantal aspecten fundamentele verschillen vertonen is ook het beheer van deze systemen verschillend ingevuld. Systemen die op een PC zijn gei'nstalleerd Deze systemen kennen een aantal karakteristieken: ook verdere ontwikkeling (aanpassing) van nieuwe versies van de modellen door anderen dan de sectie Applicatiebeheer een gebruiker (single user) 24 uurs beschikbaarheid draaien op een PC opstarten van het systeem gebeurt door de gebruiker zelf Systemen op andere hardware De andere systemen draaien hetzij op een DEC/VAX hetzij op een UNISYS machine. Voor deze systemen zijn bij het gebruik de volgende karakteristieken bepalend: meerdere gebruikers per systeem afgeschermde configuratie gebruiker kan het systeem niet zelf opstarten

27 Onderwerp : Organisatie Blad: Beheer van systemen die op een PC zijn gei'nstalleerd Binnen de groep systemen die op een PC zijn gei'nstalleerd is weer onderscheid te maken tussen de modellen en de overige systemen. Dit onderscheid wordt gehanteerd vanwege de verschillen in het gebruik van deze systemen. Modellen De groep systemen aangeduid als "modellen" omvat de calamiteitenmodellen en de hoog- en laagwatermodellen. Deze systemen worden niet dagelijks gebruikt maar, zoals de naamgeving al aanduidt, in bijzondere situaties. Indien zich een calamiteit voordoet of er bepaalde waterstanden worden bereikt dienen deze modellen voorspellingen op te leveren van waterstanden of concentraties van vervuilingen. Deze voorspellingen dienen ad hoc te kunnen worden gemaakt en daarom dienen de modellen 24 uur per dag operationeel te zijn. Functioneel beheer Het functioneel beheer van de calamiteitenmodellen wordt uitgevoerd door de betreffende calamiteitengroep. Voor de hoog- en laagwatermodellen wordt deze taak uitgevoerd door de bijbehorende hoog- en laagwatergroepen. De functioneel beheerder is het aanspreekpunt voor alle wijzigingen van het systeem, zowel storingen die acuut verholpen moeten worden als wijzigingsverzoeken ten aanzien van de functionaliteit van het systeem. Hij/zij geeft deze wijzigingsverzoeken door aan de applicatiebeheerder van het betreffende model die voor verdere afhandeling zorgdraagt. Applicatiebeheer Het applicatiebeheer van de modellen wordt uitgevoerd door de sectie Applicatiebeheer (IOSBA). Deze beheert alle (versies van) sources, alsmede de applicatie documentatie van het systeem. Nieuwe versies van modellen worden aangeboden aan de sectie Applicatiebeheer ter acceptatie voor onderhoud. De afdeling applicatiebeheer is de enige die nieuwe versies van de modellen mag installeren. Een (versie van een) model kan dus nooit in gebruik genomen worden voordat de sectie Applicatiebeheer het onderhoud ervan op zich heeft genomen.

28 Onderwerp: Organisatie Blad: 1-20 Overige Gegevensbeheer Het gegevensbeheer van systemen op de PC wordt veelal ingevuld door de gebruiker (in dit geval de calamiteiten of hoog- en laagwater groepen). Deze is tenslotte degene die de gegevens in het model invoert. Bij niet foutloos functioneren van het model wordt de functioneel beheerder ingeschakeld. Deze beoordeelt de fout en schakelt applicatiebeheer (bij fouten in het programma) of computerbeheer (bij fouten in de configuratie) of beiden in. DBMS-beheer Veel applicaties die op een PC draaien worden ontwikkeld met behulp van een 4GL omgeving met bijbehorende DBMS management systeem. Hierdoor is het niet mogelijk de applicatie en het DBMS van elkaar te scheiden. Het beheer van het DBMS wordt uitgevoerd door de sectie IOSBC. Computerbeheer Het computerbeheer valt, voor wat betreft de modellen onder de verantwoordelijkheid van IOSBC. De op de PC's gei'nstalleerde modellen zijn zeer gevoelig voor de configuratie van de PC waarop zij draaien en van de aangesloten randapparatuur. Het beheer van de hardwareconfiguratie is ook ondergebracht bij de sectie IOSBA. De overige systemen betreffen systemen die dagelijks door gebruikers voor de verwerking van gegevens en informatievoorziening vanuit die gegevens worden gebruikt. Deze systemen zijn gei'nstalleerd op de PC's van de betreffende gebruikers. Functioneel beheer Het functioneel beheer is voor deze systemen in handen van de gebruiker. Applicatiebeheer van de overige systemen berust bij de sectie Applica Het applicatiebeheer tiebeheer (IOSBA).

29 Onderwerp: Organisatie Blad: 1-21 Gegevensbeheer Het gegevensbeheer is voor deze systemen in handen van de gebruiker. DBMS-beheer Het DBMS-beheer van de overige systemen wordt uitgevoerd door de sectie IOSBA. Computerbeheer Het computerbeheer voor wat betreft de overige PC-systemen is ook de verantwoordelijkheid van de gebruiker. Dit is een direct gevolg van het feit dat de betreffende systemen op de PC's van deze gebruikers gei'nstalleerd zijn. Zij zijn immers degenen die de installatie van de betreffende systemen kunnen aanpassen en dus ook de enigen die verantwoordelijk kunnen zijn voor deze installatie. Een uitzondering hierop wordt gemaakt wanneer een systeem voor de eerste keer op een PC wordt gei'nstalleerd. Deze taak wordt uitgevoerd door de sectie IOSBA bij oplevering van het systeem. IOSBA levert bij het nieuwe systeem een handleiding voor de installatie en een beschrijving van de configuratie en de daarmee samengaand parameterinstellingen.

30 Onderwerp : Organisatie Blad: Bchccr van systemen op andere hardware Functioneel beheer Het functioneel beheer van de overige systemen is voor wat betreft het Conversieprogramma SGF-AVEWAD ondergebracht bij de sectie IOSBA. Dit is een direct gevolg van het feit dat de systemen organisatie-breed gebruikt worden. Gebruikers kunnen zich met wijzigingsverzoeken of storingen wenden tot de sectie IOSBA, die voor de verdere afhandeling zorgt. Het functioneel beheer van de overige systemen wordt uitgevoerd door medewerkers van de sectie IOSBG. Gegevensbeheer Voor het gegevensbeheer van de overige systemen is een aparte gegevensbeheerder aangewezen binnen de sectie Gegevensbeheer (IOSBG). Applicatiebeheer Het applicatiebeheer wordt uitgevoerd door de sectie Applicatiebeheer. DBMS-beheer DBMS-beheer van de hier behandelde systemen is de verantwoordelijkheid van de sectie Database Management (IOID) Computerbeheer Het computerbeheer is ondergebracht bij het computercentrum (IOIC)

31 Onderwerp : Organisatie Blad: Overzicht beheer per systeem In het volgende wordt een overzicht gegeven van die systemen waarvoor de sectie IOSBA in een of andere vorm het beheer uitvoert. Systemen op PC: Modellen: IOSBA onderhoudt zes model-systemen: drie calamiteiten modellen: Rijncalamiteitenmodel Maascalamiteiten model Noordelijk deltabekken calamiteitenmodel twee hoogwatermodellen: Maashoogwatermodel Rijn hoog water model een laagwatermodel: Maaslaagwatermodel Overige systemen op PC: Dagelijkse berichtgeving Berichten aan de scheepvaart Opslag FYTO plankton gegevens Adresseersysteem (DAGBER) (BAS) (FYTOPLAN) (ADRES) Systemen die niet op PC draaien: Interim Systeem Projectmatig Onderzoek Conversieprogramma SGF-AVEWAD (ISPO) (SGFAVE) In het hierna volgende overzicht wordt aangegeven welke systemen er direct of indirect door het berichtencentrum worden gebruikt, wie de eigenaar c.q. sponsor van het systeem is en wie verantwoordelijk is voor welke vorm van beheer.

32 Onderwerp : Organisatie Blad: 1-24 BEHEERVORMEN HOOEL FUNCTIONEEL APPLICATIE GEGEVENS DBMS COMPUTER Alarnmodel "RIJN" CHR/IRC I.HR 7 CHR? N.V.T. IOSBA Calamiteitenmodel voor de Maas (stationair) projectleider BER*CAL IOSBA projectleider BER'CAL N.V.T. IOSBA Calamiteitenmodel voor de Haas (semi-dynamisch) * projectleider BER*CAL IOSBA projectleider BER*CAL N.V.T IOSBA Calamiteitenmodel Noordelijk Deltabekken projectleider BER'CAL IOSBA projectleider BER*CAL N.V.T IOSBA FLOFOM Hoogwater Voorpsellingsmodel Maas projectleider BER'HW IOSBA projectleider BER*HW N.V.T IOSBA LOBITH Hoogwater Voorspellingsmodel Rijn projectleider BER'HW IOSBA projectleider BER*HW N.V.T IOSBA LAMA Laagwatermodel voor de Maas projectleider BER*HW IOSBA projectleider BER'HW N.V.T IOSBA BAS Berichten Aan de Scheepvaart projectleider BER*BS IOSBA projectleider BER*BS N.V.T IOSBC DAGBER Dageli jkse Berichtgeving projectleider BER*DB IOSBA projectleider BER*DB N.V.T IOSBC ACRES Adresseersysteem berichten centrum IOSBA N.V.T IOSBC US projectleider BERMJS BC 1 l GSR/GSH projectleider BER-1JS N.V.T BC i GSR/GSH WDY projectleider BER*H0OGWAM WS projectleider BER'HOOGWAM N.V.T. IOSBC Aqua I arm IOSA IOSA IOSA IOSA IOI MFPS BOVAM TPD IOSBC N.V.T. IOSBC MSW DGW TPD DGW DGW DGW AKNDEB IOSM/IOSO IOSBA ICIM IOSO N.V.T IOSBA ZWENDL WS WS WS N.V.T N.V.T DELWAO WS WS WS N.V.T N.V.T Aquabel * Algemeen Beheerder Aquabel ABA Algemeen Beheerder Aquabel ABA ABA

33 Onderwerp : Organisatie Blad: 1-25 MODEL GEBRUIKER SPONSOR EIGENAAR OVERLEG- STRUCTUUR Alarnmodel "RIJN" Calamiteiten- CHR IRC/CHR IRC/CHR Calamiteitenmodel voor de Maas (stationair) Calami tei ten- Groep BER RIZA BER'CAL Calamiteitenmodel voor de Maas * (semi-dynamisch) Calamiteiten- Groep RIWA RIWA toekomst via Aquabel Calamiteitenmodel Noordelijk Deltabekken Calamiteiten- Groep BER RIZA BER*CAL toekomst: via AQUABEL FLOFOM Hoogwater Voorspellingsmodel Maas LOBITH Hoogwater Voorspellingsmodel Rijn LAMA Laagwatermodel voor de Maas BAS Berichten Aan de Scheepvaart DAGBER Dagelijkse Berichtgeving Hoogwater- Groep BER RIZA BER*HW Hoogwater- Groep BER RIZA BER*HW Hoogwater- Groep BER RIZA BER*HW IOSBC BER RIZA IOSBC IOSBC BER RIZA IOSBC ADRES Adresseersysteem IOSBC BER RIZA IOSBC US IOSBC BER RIZA BER*IJS WDY WDY-Groep BER RIZA BER*HOOGWAM Aqua Iarm RWS HW HW Gebruikersoverleg AQUALARM MFPS RWS IOSBC, WDYgr. Hoogwatergroep HW HW Gebruikersoverleg MFPS MSW IOSBC Hoogwatergroep WDYgroep HW HW? AKNDEB AQUALARM RIZA RIZA gebruikersoverleg AQUALARM ZWENDL RWS & extern RWS RIZA WL Gebruikersoverleg ZWENDL DELWAQ RWS WS RIZA WL Aquabel * Directies Cal.-groep IOSBC RWS RWS RWS = nog niet in produktie

34 DEEL II: PROCEDURES

35 Onderwerp: Procedures Blad: II-l INHQUD 1. Inleiding 2 2. Aanpak van het onderhoud Versie-gewijs Projectmatig 3 3. Onderhoudsprocedures Bronnen van wijzigingen 4 4. Wijziging naar aanleiding van wijzigingsverzoeken Bronnen van wijzigingsverzoeken Opstellen van een werkplan Toekennen van prioriteiten aan wijzigingsverzoeken Inhoud van het werkplan Uitvoering van het werkplan Acceptatie van de nieuwe versie Wijzigingen naar aanleiding van storingen Aanpassingen door derden Acceptatie van de nieuwe versie Beheer sources en documentatie Versienummers Opbouw Ophogen van de versienummering Samenvatting 19

36 Onderwerp: Procedures RIZArlOSBA Blad: II-2 I. Inleiding In dit deel van het handboek wordt aangegeven hoe er bij onderhoud precies te werk wordt gegaan. Hierbij ligt de nadruk op de procedures die er bij onderhoud gevolgd moeten worden.

37 Onderwerp: Procedures Blad: n-3 2. Aanpak van het onderhoud 2.1. Versie-gewijs Het onderhoud van de informatiesystemen wordt versie-gewijs aangepakt. Dit betekent dat iedere wijziging op een bestaand systeem een nieuwe versie van dat systeem tot gevolg heeft. Deze versie, aangegeven door een versienummer, dient in alle objecten die bij het systeem behoren te worden opgenomen, dus zowel in de sources als in alle voorgeschreven vormen van documentatie die het systeem beschrijven. Er kan altijd maar een versie van een systeem in produktie zijn. Onderhoud op het systeem wordt uitgevoerd op basis van deze produktie-versie. Er mag maar aan 66n nieuwe versie van het systeem tegeljjk gewerkt worden. Pas als deze nieuwe versie door de gebruiker is geaccepteerd en alle bijbehorende documentatie up-to-date is gebracht, wordt deze in produktie is genomen. Daarna kan, naar aanleiding van de inmiddels nieuw binnengekomen wijzigingsaanvragen, aan een volgende versie van het systeem gewerkt gaan worden. Dit versie-gewijs werken dient te voorkomen dat er op hetzelfde tijdstip parallel verschillende versies van systemen ontstaan. Het combineren van verschillende versies van een systeem tot een nieuwe produktieversie is namelijk over het algemeen zeer complex en foutgevoelig en dient dus absoluut vermeden te worden Projectmatig Bij het versie-gewijs aanmaken van een nieuwe versie van een systeem wordt een projectmatige aanpak gehanteerd. Projectmatig betekent in dit verband: het uitvoeren van een aantal wijzigingen op een bestaand systeem waarbij van te voren duidelijk vaststaat welke wijzigingen er in het kader van het project moeten worden aangebracht, op welke wijze dit dient te gebeuren en welke functionarissen er bij de uitvoering van het project betrokken zijn. Bovendien dient er een startdatum, een einddatum en een planning van de te besteden tijd te worden opgesteld. Al de hierboven genoemde zaken worden vastgelegd in een zgn. Werkplan.

38 Onderwerp: Procedures Blad: II-4 3. Ondeiiiouds >rocedures 3.1. Bronnen van wijzigingen Gebruikers : : Wijzigings Verzoek unctioneel Gebruikers UIMIUII i»muuummaimmi-hiuimi--i-iiii^^agbab5bbboom Verstoring Functio Beheerder er Overig Beheer H_H_l_B_ij l Wijzigings j Verzoek Overige Tijdens het gebruik van een systeem kunnen er allerlei redenen zijn om onderhoud op een systeem te plegen: 1. Er komt een wens van een gebruiker. Iedere gebruiker die de wens heeft een systeem aan te (laten) passen dient zich allereerst te wenden tot de functioneel beheerder van het betreffende systeem. Deze zal in overleg treden met de applicatiebeheerder van het systeem en beoordelen of en zo ja, hoe en wanneer de aanpassing van het systeem doorgang kan vinden. 2. Er treedt een verstoring op in het systeem. Hierdoor kan het gehele systeem of delen ervan niet naar behoren gebruikt worden. In dat geval wenden de gebruikers zich in eerste instantie ook tot de functioneel beheerder, die applicatiebeheer inschakelt. Indien de functioneel beheerder van het systeem niet beschikbaar is kunnen de gebruikers zich, gezien het spoedeisende karakter van verstoringen, direct tot de applicatiebeheerder richten. 3. Een computerbeheerder, DBMS-beheerder of applicatiebeheerder heeft een wens ten aanzien het systeem. Deze wens heeft dan meestal betrekking op een aspect van het systeem dat te maken heeft met de hardware waarop het systeem draait, het

39 Onderwerp: Procedures Blad: II-5 DBMS waarvan gebruik gemaakt wordt of de applicatiesoftware van het systeem. Een dergelijke wens resulteert meestal in een verbetering van het systeem in technisch opzicht, zonder dat de gebruiker er iets van de wijziging merkt. In deze situatie richt men zich tot de applicatiebeheerder. Deze zal de wensen eventueel opnemen in een werkplan dat tot de volgende versie van het systeem zal leiden. Uitvoering van de wijziging De uitvoering van een wijziging kan op twee manieren plaatsvinden: Door applicatiebeheer In de meeste situaties zullen wijzigingen naar aanleiding van verzoeken van betrokken beheerders uitgevoerd worden door applicatiebeheer. De betreffende beheerder bespreekt de wensen met de applicatiebeheerder en bepaalt de prioriteit die aan de wijziging moet worden toegekend. De wijziging wordt, afhankelijk van de toegekende prioriteit, opgenomen in het werkplan, dan wel vooruitgeschoven naar een volgende wijzigingsronde. Ook is het mogelijk dat een verzoek om wijziging na beoordeling door de betrokken beheerders helemaal niet wordt uitgevoerd, bijvoorbeeld omdat de te verwachten baten ervan kleiner zijn dan de kosten. Verstoringen worden uitsluitend opgelost door applicatiebeheer. Door derden: Deze situatie doet zich in het bijzonder voor bij de model-systemen. Bij deze modellen wordt regelmatig door derden op verzoek van de gebruikers, dan wel beheerders, verder aan de modellen ontwikkeld teneinde deze te verbeteren of te verfijnen. De reden voor het uitbesteden kan zijn dat er specifieke inhoudelijke kennis vereist is die niet binnenshuis aanwezig is of dat er een tekort aan capaciteit is voor het uitvoeren van de wijziging. Wijzigingen van deze aard geschieden geheel onder verantwoordelijkheid van de derde partij. Deze dient er voor te zorgen dat de nieuwe release van het systeem voldoet aan alle eisen die de gebruikers en beheerders aan het systeem stellen, voordat het in produktie en onderhoud genomen kan worden.

40 Onderwerp: Procedures Blad: II-6 4. Wgziging naar aanleiding van wyzigingsverzoeken 4.1. Bronnen van wijzigingsverzoeken Wijzigingsverzoeken kunnen afkomstig zijn van eenieder die met het systeem te maken krijgt. De verzoeken kunnen te maken hebben met de functionaliteit, het beheer van de gegevens in het systeem, de applicatiesoftware, het gebruikte DBMS en de gebruikte hardware. Alle wijzigingsverzoeken worden in eerste instantie ingediend bij de betreffende beheerder. Deze neemt kontakt op met de applicatiebeheerder die de wijziging eventueel zal opnemen in het werkplan. Functioneel De gebruikers van het systeem zullen meestal wijzigingsverzoeken indienen die te maken hebben met de functionele kant van het systeem. Door veranderde omstandigheden of veranderde inzichten voldoet het systeem niet meer aan hun wensen. Gegevensbeheer Ook vanuit de kant van het gegevensbeheer kunnen wijzigingsverzoeken ontstaan ten aanzien van het beheer en de inhoud van de gegevensverzameling van het systeem. Deze wensen kunnen soms aanpassingen van het systeem tot gevolg hebben. Applicatiesoftware Tijdens het onderhoud kunnen de bij het onderhoud betrokken medewerkers zaken in het systeem tegenkomen die hun werk bemoeilijken of technisch zwakke plekken in het systeem blootleggen. Om deze knelpunten te verhelpen kan een wijzigingsverzoek worden ingediend. Computerbeheer De computerbeheerders starten het systeem op, maken back-up's etc. Bij hun dagelijkse werkzaamheden kunnen ook zij belemmerd worden door eigenschappen van het systeem. Soms kan de combinatie van systeem en de hardware waar het op draait voor problemen zorgen. Denk bijvoorbeeld aan problemen met performance, met randapparatuur of met de configuratie van een PC. Ook zij kunnen wijzigingsverzoeken indienen bij de applicatiebeheerder.

41 Onderwerp: Procedures Blad: II-7 Database Management Systeem (DBMS) Sommige systemen maken gebruik van een specifiek DBMS. Bij het gebruik van het systeem kan de DBMS-beheerder ook zaken tegenkomen die tot wijzigingen kunnen leiden. Zo kan de wens ontstaan indexen op de database te zetten om daarmee de performance te vergroten. Wensen op het gebied van de DBMS worden voorgelegd aan de applicatiebeheerder en eventueel opgenomen in een werkplan.

42 Onderwerp: Procedures Blad: n Opstellen van een werkplan periodiek overleg WERKPLAN Periodiek komen de Functioneel- en Applicatiebeheerder van een systeem bij elkaar om een werkplan op te stellen. In dit overleg worden de wijzigingsverzoeken samengebracht en op hun prioriteit beoordeeld. Van ieder wijzigingsverzoek wordt een analyse gemaakt. Hierbij wordt van elk wijzigingsverzoek een globale kosten/baten analyse gemaakt. Elk wijzigingsverzoek wordt tevens beoordeeld op technische haalbaarheid. Een deel van de wijzigingsverzoeken wordt geaccepteerd en mogelijk wordt een deel afgewezen.

43 Onderwerp: Procedures Blad: II Toekennen van prioriteit cn aan wyzigingsverzoeken Omdat in de meeste gevallen niet alle wijzigingsverzoeken in de eerstvolgende versie van het systeem gehonoreerd kunnen worden kunnen de indieners aan hun wijzigingsverzoeken een prioriteit toekennen; hoog, normaal en laag. Alhoewel er geen algemene regels aan te geven zijn voor het toekennen van deze prioriteiten en eenieder hierover een subjectief oordeel zal geven, worden hieronder toch een paar aanknopingspunten gegeven voor het toekennen van de juiste prioriteit. Hoge prioriteit Hieronder vallen zaken die het functioneren van het systeem in ernstige mate bedreigen. Indien bijvoorbeeld vanuit de omgeving van het systeem absolute eisen gesteld worden die een bepaalde ingangsdatum hebben (wetswijzigingen, gewijzigde aanlevering van gegevens, etc.) zullen deze wijzigingen op de ingangsdatum gerealiseerd moeten zijn. Normale prioriteit Onder deze categorie vallen de wensen van gebruikers ten aanzien van extra functionaliteit, zonder welke er toch nog goed met het systeem gewerkt kan worden. Lage prioriteit Hiermee worden onvolkomenheden in het systeem bedoeld die het functioneren van het systeem niet in gevaar brengen maar het gebruik ervan bemoeilijken. De cursorbesturing is bijvoorbeeld niet handig of de meer kosmetische aspecten van het systeem zoals het verfraaien van de layout van overzichten en/of schermen, het aanpassen van kopregels en/of vaste schermteksten etc. moeten worden aangepast. De geaccepteerde wijzigingsverzoeken worden onderverdeeld naar prioriteit. Sommige komen in aanmerking om in de eerstvolgende versie van het systeem te worden aangebracht, de overige wijzigingsverzoeken worden in een of meer van de daarop volgende versies van het systeem verwezenlijkt. Voor het aanbrengen van de wijzigingen in de eerstvolgende versie van het systeem wordt een werkplan opgesteld. Dit werkplan omvat alle activiteiten die nodig zij voor het aanmaken van een nieuwe release van het systeem.

44 Onderwerp: Procedures Blad: H Inhoud van het werkplan In het Werkplan worden de volgende zaken opgenomen: Overzicht van de wijzigingen Per wijzigingsverzoek wordt aangegeven: Start datum wie het heeft ingediend; wat het geconstateerde probleem of de wens is; wat de oorzaak is van het probleem of de wens; eventueel hoe de wijziging aangebracht moet worden; hoeveel tijd het aanbrengen van de wijziging in beslag neemt. De startdatum van het project wordt aangegeven. Op deze datum wordt begonnen met het verzamelen van de benodigde zaken betreffende de huidige versie van het systeem. Einddatum De einddatum van het project wordt aangegeven. Op deze datum dient de nieuwe versie van het systeem door de gebruiker te zijn geaccepteerd. Mensdagen Het totaal aantal mensdagen dat benodigd is voor het uitvoeren van het werkplan wordt aangegeven. Doorlooptijd Personeel Hierin wordt aangegeven hoe het tijdbeslag verloopt gedurende de uitvoering van het werkplan. Tevens wordt het aantal personen aangegeven dat op ieder moment aan de uitvoering van het werkplan meewerkt. Bij het onderdeel personeel wordt aangegeven wie er bij de uitvoering van het werkplan betrokken zijn, gedurende welke periode dat het geval is en voor hoeveel procent van hun tijd ze betrokken zullen worden. Niet alleen de personen die het systeem aanpassen dienen hierbij te worden meegenomen, maar alle personen die voor de uitvoering van het werkplan nodig zijn. Hierbij kan men bijvoorbeeld denken aan:

45 Onderwerp: Procedures Blad: gebruikers waarmee afgestemd moet worden over de gewenste aanpassing en de gekozen oplossing; gebruikers die een acceptatietest moeten uitvoeren; operationeel- en computerbeheerders moeten installeren. die de nieuwe versie van het systeem Benodigde omgevingen Voor het uitvoeren van het werkplan kunnen aparte omgevingen gewenst zijn. Te denken valt aan een systeemtestomgeving, een acceptatietestomgeving etc. Alle aspecten die hiervoor benodigd zijn komen aan bod, zoals benodigde hardware, software, userid, password, rekentijd, geheugenbeslag etc. Nadat het werkplan gereed is wordt een onderhoud steam geformeerd. Dit team heeft tot taak de in het werkplan opgenomen wijzigingen op het systeem aan te brengen en in de vorm van een nieuwe release aan de gebruikers ter acceptatie aan te bieden.

46 Onderwerp: Procedures Blad: n Uitvoering van het werkplan uitvoeren wijziging V E R S I n + 1 handleiding operator Voorbereiding uitvoering werkplan Voordat aan de uitvoering van het werkplan begonnen kan worden dient een aantal zaken aanwezig te zijn. het werkplan de sources (applicatiebeheer) de systeembeschrijving (applicatiebeheer) de gebruikershandleiding (functioneelbeheer) de handleiding voor installatie (applicatiebeheerbeheer) de operators handleiding (computerbeheer)

47 Onderwerp: Procedures Blad: U-13 Als eerste stap in de uitvoering van het werkplan worden de sources en documentatie van de huidige versie verzameld. Eerst wordt nagegaan op welke delen van het systeem de wijziging van invloed is (impact analysis). Vervolgens wordt een ontwerp van de wijziging gemaakt. Daarna worden de wijzigingen gecodeerd en getest en de documentatie aangepast. Tenslotte wordt het systeem overgedragen aan de functioneel beheerder ter acceptatie. Deze selecteert ten of meer gebruikers die een acceptatietest uitvoeren. De gebruiker is zelf verantwoordelijk voor de testdata. N.B. Voor het testen van de nieuwe versie van het systeem mag geen gebruik gemaakt worden van de produktieomgeving waarop de oude versie draait. Dit zou de operationaliteit van de oude versie namelijk in gevaar kunnen brengen. Installatie van de nieuwe versie van het systeem valt onder verantwoordelijkheid van Applicatiebeheer Acceptatie van de nieuwe versie Nadat de gebruiker het systeem akkoord heeft bevonden wordt dit officieel overgedragen. Deze overdracht wordt formeel vastgelegd d.m.v.een overdrachtsformulier (zie deel IV: Standaards) Vanaf het moment van overdracht wordt er niets meer gewijzigd aan de in produktie zij nde versie.