Voorbeeld opzet handboek voor ict kwaliteit 

1. Toelichting op dit document

Dit document is het tweede deel van een voorbeeld van een kwaliteitshandboek ICT, dat daadwerkelijk is geïmplementeerd in de praktijk. Het gaat in op systeemontwikkeling (waterval methode SDM-2), beheer (ITIL-based) en projectmanagement (ook mogelijk via Prince 2).

Het handboek is geschreven vanuit de behoefte van de bedrijfsprocessen en gebruikers en is bedoeld om de ICT-afdeling zo te laten werken, dat aan de gebruikers een adequate informatievoorziening wordt gegarandeerd. Er wordt dan vooral ook ingezoomd op de activiteiten die voor de gebruikers van belang zijn, zodat zij begrijpen, dat hun participatie cruciaal is om die adequate informatievoorziening te realiseren. Het maakt hierbij niet uit of het om een interne of externe ICT-afdeling gaat. Het handboek is ook zeker bruikbaar om tot een werkzame samenwerking te komen in het geval van outsourcing is , waarbij taken, verantwoordelijkheden en bevoegdheden zijn vastgelegd.

Om hergebruik gemakkelijk mogelijk te maken, is de bedrijfsnaam in dit document vervangen door PPPP. Via zoek en vervang kunt u hier uiteraard de naam van uw eigen organisatie invullen.

Het handboek is gezien zijn omvang opgesplitst in drie delen, om problemen met downloaden te voorkomen.

Natuurlijk kan ZBC u ondersteunen bij de aanpassing voor en de invoering van dit handboek in uw organisatie. Ook kan ZBC workshops verzorgen voor betrokkenen.

Het handboek is gezien zijn omvang opgesplitst in drie delen, om problemen met downloaden te voorkomen. In deel 1 vindt u de inleiding op het handboek, die bestaat uit de volgende hoofdstukken: 

Deel 1

2. Inleiding: duidelijkheid als sleutelwoord

3. Duidelijke doelstellingen PPPP-IT

4. Het PPPP-IT kwaliteitssysteem

Deel 2

5. De systeemontwikkelingsmethode

5.1 Structuur van de methode

Het Kwaliteitshandboek beschrijft wèlke activiteiten kunnen of moeten worden uitgevoerd en wèlke producten daarbij dienen te worden opgeleverd. Met andere woorden: planning en beheersing vinden plaats op grond van mijlpaalproducten die als gevolg van alle activiteiten worden opgeleverd.

In het Handboek wordt de vormgeving van een informatiesysteem vanuit vier invalshoeken benaderd:

• verandering:
  Wat wil de organisatie? Hoe zal de organisatie er over twee tot vijf jaar uitzien?
• systeemontwikkeling:
  Welke ondersteuning van informatiesystemen heeft de organisatie nodig en hoe maken we deze?
• kwaliteitsborging:
  validatie, verificatie en acceptatie
• besturing:
  Hoe zorgen we ervoor dat het gewenste resultaat binnen de randvoorwaarden bereikt wordt?

Deze vier bouwstenen slaan de brug van de huidige naar de gewenste informatievoorziening en zullen als rode draden door alle modules van het Kwaliteitshandboek verweven zijn.
Het ontwikkelingstraject is opgedeeld in fasen, waarbij van elke fase de activiteiten en de te maken producten worden beschreven. Iedere fase kent activiteiten en producten die verband houden met de genoemde vier invalshoeken.

Fasen van het ontwikkelingstraject
De fasering dient om de ontwikkeling van het systeem in hanteerbare en overzichtelijke eenheden in te delen en om de noodzakelijke beslismomenten vast te leggen. PPPP-IT onderkent in de levensloop van een informatiesysteem vijf fasen, te weten:

1. Definitiestudie
2. Basisontwerp
3. Detailontwerp
4. Realisatie
5. Invoering

De Definitiestudie (fase 1) is het begin van het feitelijke systeemontwikkelingstraject, waarin de globale eisen, alternatieven en de haalbaarheid onderzocht worden, op grond waarvan beleidskeuzes gemaakt kunnen worden.
In de fase Basisontwerp (fase 2) worden de gemeenschappelijke aspecten van de systeemdelen ontworpen en moeten de belangrijke ontwerpkeuzes gemaakt worden. Dit is de laatste fase waarin een systeem in z’n totaliteit wordt beschouwd.
In de fasen 3 tot en met 5 wordt in deelprojecten het systeem verder ontworpen, gerealiseerd en ingevoerd. Vervolgens wordt de verantwoordelijkheid voor het systeem overgedragen aan de gebruikersorganisatie, waarbij PPPP-IT dienstverlening kan bieden op het gebied van productie, onderhoud en beheer.
De diverse fasen zullen in het vervolg van dit Kwaliteitshandboek nader uitgewerkt worden. 

Activiteiten en producten
Zoals al is aangegeven, kent iedere fase activiteiten die verband houden met de vier basisprocessen van waaruit PPPP-IT de ontwikkeling van de organisatie en de informatievoorziening benadert.

5.2 De ontwikkelingsfasen

PPPP-IT streeft naar fixed quality door een constante beheersing van de drie-eenheid kwaliteit, geld en tijd. Eén van de zaken waarmee een doortimmerd kwaliteitsbeleid staat of valt, is een gedegen, goed gefaseerde, strakke planning. Want alleen strak plannen en voortdurend controleren resulteert in een product dat voldoet aan de verwachtingen van de klant. Een goede planning schept echter niet alleen duidelijkheid naar de klant: ook het eigen personeel heeft er baat bij. Daarom worden op de volgende pagina’s uitgebreid de verschillende fasen behandeld die PPPP-IT onderscheidt in de levensloop van een informatiesysteem.

5.2.1 Definitiestudie

De Definitiestudie is de eerste fase in de ontwikkeling van een informatiesysteem. Het doel van deze fase is: het definiëren en selecteren van de oplossingsrichting en het onderzoeken of deze oplossingsrichting economisch, technisch, sociaal en organisatorisch haalbaar is. De activiteiten in hun onderlinge samenhang zijn duidelijk weergegeven in figuur 2 (zie verderop). Eerst volgt een korte toelichting op de activiteiten uit de Definitiestudie.

Activiteit 1.1.
De Definitiestudie begint zoals elke fase met het vastleggen van de uitgangspunten en het opstellen van het plan van aanpak. In termen van Prince 2 is dit te beschouwen als de projectdefinitie.
Deze activiteit levert twee producten op:

1. De Werkopdracht:
   de door de opdrachtgever goedgekeurde opdracht waarin de basis wordt gelegd voor een gezond project met een aanvaardbaar risico. Aangezien de Definitiestudie de basis vormt voor een aantal beleidskeuzes, wordt het daadwerkelijk uitvoeren van deze studie als een zelfstandig deelproject beschouwd, dat meestal als opdrachttype 1 wordt uitgevoerd.
2. Het Plan van Aanpak:
   een duidelijke beschrijving wanneer welke producten tot stand komen, wie welke taken en verantwoordelijkheden heeft en langs welke weg de producten gerealiseerd worden. Het Kwaliteitshandboek vormt hiervoor de stevige basis.

Beide producten zijn een mijlpaalproduct.

Activiteiten 1.2 t/m 1.4: De informatieanalyse
Hierbij worden op basis van een analyse van de huidige èn de gewenste situatie de eisen en criteria vastgesteld waaraan de gewenste informatievoorziening moet voldoen. Als werkwijze en afbeeldingswijze wordt een mix gebruikt van ISAC-technieken en Yourdon Stuctured Analysis. Voor het beschrijven van de organisatorische gevolgen worden relatiematrices en technieken voor de administratieve organisatie gebruikt. De in activiteit 1.3 gedefinieerde systeemeisen vormen eveneens een mijlpaalproduct.

Activiteiten 1.5 t/m 1.7
Deze activiteiten richten zich op het definiëren van de hoofdfuncties, gegevensverzamelingen en interacties van het gewenste informatiesysteem. Ze geven antwoord op de vragen welke middelen hiervoor kunnen worden aangewend, naar welke oplossing de voorkeur uitgaat en welke eisen en consequenties deze oplossing heeft voor de organisatie en haar middelenvoorziening. De gekozen systeemoplossing (activiteit 1.7) is weer een mijlpaalproduct.

In het systeemconcept wordt de basis voor het totale systeem ontworpen en weergegeven in een functie- en een gegevensmodel. Deze modellen worden ontwikkeld met behulp van respectievelijk Yourdon Structured Analysis en Entity Relationship Modelling.

Activiteiten 1.8 t/m 1.11
Het ontwikkelen van plannen die het mogelijk maken om een ‘go/no go’-beslissing te nemen. In termen van Prince 2 is dit te beschouwen als het Project Initiatie Project (PID) voor het totale project.
In een dergelijk ontwikkelingsplan wordt aangegeven hoe de ontwikkeling van het systeem wordt aangepakt, welke hulpmiddelen en faciliteiten hiervoor nodig zijn en hoe de ontwikkeling in de tijd gerealiseerd kan worden. De Definitiestudie-fase wordt afgesloten met een eindrapport (1.11), waarin de economische, technische en sociaal/organisatorische haalbaarheid beschreven wordt. Ook dit Rapport Definitiestudie is een mijlpaalproduct.
Tenslotte: door het uitvoeren van een kosten/baten analyse heeft de Definitiestudie het karakter van het voorbereiden van een investeringsbeslissing.
Tot zover een toelichting op de activiteiten van de eerste fase, de Definitiestudie.Hierna wordt door de klantorganisatie beslist of en hoe met de systeemontwikkeling moet worden verder gegaan.

5.2.2 Basisontwerp

Het Basisontwerp is de tweede fase van systeemontwikkeling die het totale systeem betreft. Voortbordurend op hetgeen tijdens de Definitiestudie in kaart is gebracht, vormt het Basisontwerp letterlijk de basis, het fundament onder elk te ontwikkelen systeem.
Het Basisontwerp verschaft de gemeenschappelijke basis op grond waarvan te onderscheiden delen van het systeem afzonderlijk verder ontwikkeld kunnen worden. Daartoe wordt zowel het systeemconcept als de systeemoplossing tot een zodanig niveau gedetailleerd, dat gewenste systeemdelen die in deelprojecten verder worden ontwikkeld, kunnen worden gedefinieerd. Bovendien moeten de interfaces tussen deze systeemdelen en die met andere systemen tot op detailniveau worden uitgewerkt. Dit impliceert tevens, dat vrijwel alle belangrijke ontwerpbeslissingen in het basisontwerp gemaakt moeten worden. Voorts moet bepaald worden, welke functies handmatig en welke geautomatiseerd uitgevoerd moeten worden.

Activiteit 2.1: Uitgangspunten en Plan van Aanpak
Deze activiteiten leveren twee producten op:

1. De werkopdracht:
   De basis voor een gezond project met een aanvaardbaar risico wordt hierin (vast)gelegd. Het uitgangspunt voor de werkopdracht is het Rapport Definitiestudie en de wijzigingen die de opdrachtgever heeft aangebracht naar aanleiding van dit rapport. Aangezien in het Basisontwerp belangrijke ontwerpbeslissingen genomen moeten worden en deelprojecten worden gedefinieerd, wordt het uitvoeren van een Basisontwerp als een zelfstandig deelproject beschouwd.
   Als PPPP-IT niet betrokken is geweest bij de Definitiestudie en wel projectverantwoordelijkheid draagt voor het Basisontwerp (opdrachttype 2), zal voor het opstellen van de opdracht een risicoanalyse en een audit op het Rapport Definitiestudie worden uitgevoerd, om te voorkomen dat de opdrachtgever met negatieve gevolgen van een slecht uitgangsproduct geconfronteerd wordt.
2. Het Plan van Aanpak:
   Net als bij de Definitiestudie is ook bij het Basisontwerp het Plan van Aanpak een duidelijke beschrijving wanneer welke producten tot stand komen, wie welke taken en verantwoordelijkheden heeft en langs welke weg de producten gerealiseerd worden. Formeel is dit Plan van Aanpak hetzelfde als bij de Definitiestudie, inhoudelijk is het hier geheel toegesneden op de fase van het Basisontwerp.

De producten van activiteit 2.1 zijn mijlpaalproducten.

Activiteiten 2.2 t/m 2.4
Definiëring van de functies van het informatiesysteem vanuit de eisen die de toekomstige werkomgeving aan het gebruik van dat systeem stelt.
Ook worden in dit stadium de gegevensverzamelingen beschreven en de dialogen vastgelegd. Het systeem wordt daarbij in functionele termen beschreven. Het wordt daarin voor de gebruiker zichtbaar wàt het systeem gaat doen, zonder dat in eerste instantie het hoè wordt ingevuld. Ook moet nu de keuze gemaakt worden welke functies handmatig en welke geautomatiseerd worden.
Voor het vastleggen van de toekomstige werkomgeving worden technieken voor de vastlegging van de administratieve organisatie gebruikt. De gegevensstructuur wordt met behulp van Entity Relationship Modelling bepaald en de functiestructuur via Yourdon Structured Analysis.

Activiteiten 2.5 en 2.6
Definiëring technische basisstructuur. Daarbij kunnen technische hulpmiddelen en faciliteiten gemeenschappelijk worden gebruikt door verschillende informatiesystemen. Die informatiesystemen zijn vaak al operationeel en daarom zal er gebruik moeten worden gemaakt van de beschikbare hulpmiddelen, of zullen nieuwe hulpmiddelen hierop moeten worden afgestemd. De eisen die in technische zin gesteld worden aan hardware en software worden in activiteit 2.5 nader gepreciseerd. De technische structuur uit activiteit 2.6 wordt ontworpen met behulp van Yourdon Structured Design.

Activiteiten 2.7 en 2.8
Aanscherping van de plannen uit de Definitiestudie. Tevens te beschouwen als een aangescherpt PID in termen van Prince 2.

Activiteit 2.9: Het opstellen van het Eindrapport Basisontwerp
Hierin is een systeemontwikkelingsplan opgenomen waarin de ontwikkelstrategie wordt beschreven die aangeeft hoè het systeem in gedeelten zal worden gerealiseerd en op wèlke wijze en met het gebruik van wèlke faciliteiten dit zal gebeuren. Voor het opstellen van het plan is de projectleider verplicht gebruik te maken van functie-punt-analyse en risicoanalyse. De projectleider initieert tenslotte een kwaliteitsaudit.

Tot zover de fase van het Basisontwerp. In de nu volgende fase kunnen één of meer delen uit het Basisontwerp meer in detail uitgewerkt worden: de fase van het Detailontwerp.

5.2.3 Detailontwerp

In de fase van het Detailontwerp zijn we aangekomen op het punt waarop één of meer delen van het systeem uit het Basisontwerp in detail uitgewerkt/ontworpen worden. Op deze wijze kan beter gebruik gemaakt worden van de beschikbare mensen en middelen.
Het Detailontwerp richt zich op het voltooien van de in het Basisontwerp aangegeven systeemspecificaties. En wel op een zodanig niveau, dat in de hierna volgende Realisatiefase begonnen kan worden met de daadwerkelijke bouw van het systeem.

In dit stadium van het project kunnen meerdere parallelsporen onderkend worden, waarvoor verschillende opdrachttypes gedefinieerd kunnen worden. Naast de pure systeemontwikkeling kunnen we de organisatieontwikkeling, het voorbereiden van de acceptatietest en de conversie en het opleiden onderscheiden.
Het spreekt vanzelf dat de afbakening van de onderdelen in goed overleg tot stand moet komen.
Hieronder worden de tot deze fase behorende activiteiten meer ‘in detail’ toegelicht.

Activiteit 3.1
Deze activiteit levert de volgende twee producten op:

1. De werkopdracht: de basis voor een gezond Detailontwerp.
   De basis hiervoor wordt gevormd door het Rapport Basisontwerp en eventueel de wijzigingen die de opdrachtgever heeft aangebracht naar aanleiding van dit rapport. Aangezien in het basisontwerp de belangrijke ontwerpbeslissingen reeds genomen zijn, is het mogelijk dat de fasen 3 en 4 (respectievelijk Detailontwerp en Realisatie, zie ook volgende paragrafen) als één project geoffreerd worden en daarom een aparte projectopdracht kennen.
2. Het Plan van Aanpak:
   de beschrijving wanneer welke producten tot stand komen, wie welke taken en verantwoordelijkheden heeft en langs welke weg de producten gerealiseerd worden. Het handboek vormt hiervoor weer een uitstekende basis.

De producten van activiteit 3.1 zijn mijlpaalproducten.

Activiteit 3.2 t/m 3.7
In het eerste deel van het Detailontwerp worden de functionele specificaties verder in detail uitgewerkt en beschreven. Vanuit de gedetailleerde structuur van de toekomstige werkomgeving (activiteit 3.2) worden de elementaire functies beschreven in activiteit 3.3. Het gaat daarbij om alle typen gebruikersspecificaties, inclusief de handmatige functies en de gedetailleerde prestatie-eisen. Vervolgens worden de elementen van de gegevensverzamelingen gedefinieerd (activiteit 3.4) en worden de mens x machine-interfaces vastgelegd in activiteit 3.5.
Bij activiteit 3.2 wordt gebruik gemaakt van vastleggingstechnieken voor administratieve organisatie. Voor de activiteiten 3.3 en 3.5 wordt gebruik gemaakt van Yourdon Structured Analysis and Design, terwijl activiteit 3.4 wordt uitgevoerd met behulp van Entity Relationship Modelling.
Het eerste deel wordt afgesloten met een Functioneel Ontwerp Rapport en het bijbehorende validatierapport, (activiteiten 3.6 en 3.7).
In het Functioneel Ontwerp Rapport ligt dus in feite de volledige specificatie van het systeem vast en is het normeren van het aspect ‘kwaliteit’ afgerond.
Het is van het grootste belang dat dit rapport grondig geverifieerd wordt door de gebruikers en geaccepteerd wordt door het gebruikersmanagement. Wijzigingsvoorstellen van de gebruikers hoeven daardoor niet meer voor te komen, hetgeen een sterke reductie op de bouwkosten zal geven.
Het rapport vormt dan ook de basis voor de acceptatietest.

Activiteit 3.8 t/m 3.12
Na acceptatie van het Functioneel Ontwerp Rapport kan begonnen worden met het in technische zin verder specificeren en detailleren van het betreffende systeemonderdeel (activiteiten 3.8 t/m 3.12).
Vanaf dit moment gaan de gebruikers en de informatici in aparte werkgroepen verder.
De gebruikers houden zich bezig met het ontwerpen van procedures en het formuleren van de gebruikershandleiding. Daarnaast beginnen ze de acceptatietest voor te bereiden. Bovendien kunnen een aantal activiteiten uit de fase invoering nu al gestart worden.
Het belangrijkste aspect voor de informatici in het tweede deel van het Detailontwerp is de inbedding van het systeemonderdeel in zijn toekomstige technische omgeving. De specificaties worden zodanig opgesteld en structureel geordend, dat deze geprogrammeerd en getest kunnen worden. De structuur en fysieke organisatie van bestanden en programma’s worden vastgelegd. De bewerkingen worden zowel beschreven als vastgelegd in een gedetailleerde programmatuurspecificatie. Alle interfaces van het systeemonderdeel met zijn interne en externe omgeving worden tot op het laagste detailniveau gespecificeerd.

Activiteit 3.13 t/m 3.16
Na een laatste beoordeling van de technische specificaties wordt de fase Detailontwerp afgesloten met het voorbereiden van een gedetailleerd testplan (activiteit 3.13) en een rapport Detailontwerp (activiteit 3.16), waarin opgenomen een plan voor realisatie en invoering.
Voor het procedureontwerp worden technieken voor administratieve organisatie geadviseerd, terwijl voor het vastleggen van de specificatie van het geautomatiseerde systeem Yourdon Structured Design wordt gebruikt.

5.2.4 Realisatie

In deze fase wordt het door de klant verlangde ontwerp op grond van de specificaties uit het Detailontwerp omgezet in de realiteit en vervolgens productierijp gemaakt.

Het realiseren van het systeemonderdeel betreft het creëren van databases, het maken van de benodigde handmatige routines en geautomatiseerde programmamodules en het nemen van maatregelen voor het testen van het systeem en het opleiden van de gebruiker.
Voorts wordt het systeem getest op zowel programmaniveau als op systeemniveau.
Tenslotte wordt door de toekomstige gebruikers in een acceptatietest beoordeeld of de werking van het systeem (inclusief systeembeheer en productie) voldoet aan de verwachtingen en gestelde eisen, zodat het daarna bij akkoord kan worden ingevoerd. Dit betreft zowel de gedeelten van het systeemonderdeel die handmatig zullen worden uitgevoerd, als de delen die geautomatiseerd zullen gaan worden.
Hoewel de te gebruiken programmeertalen sterk kunnen verschillen, zal de programmering in ieder geval via gestructureerde technieken worden uitgevoerd.

5.2.5 Invoering

Gedurende de invoeringsfase worden zowel het systeemonderdeel als de werkomgeving waartoe het onderdeel gaat behoren gereed gemaakt voor gebruik. Het systeem kan ingevoerd worden in de dagelijkse praktijk, waarvoor het in samenspel tussen klant en PPPP-IT gecreëerd is.
Waarbij op voorhand nog eenmaal voor alle duidelijkheid gesteld dient te worden dat de voorbereiding op die daadwerkelijke invoering reeds in een vroeger stadium getroffen moet zijn.
Dat begint al direct na de beslissing tot aanschaf of bouw van een nieuw informatiesysteem, bijvoorbeeld door het geven van voorlichting. Een belangrijke factor voor het welslagen van de invoering van het systeemonderdeel in de gebruikersorganisatie is namelijk de mate waarin de gebruiker betrokken is geweest bij de totstandkoming ervan. Goede en tijdige voorlichting en opleiding zijn essentieel met het oog op het uiteindelijk alles overheersende doel: de acceptatie van het systeem door tevreden gebruikers.
De klant is en blijft daarbij koning, PPPP-IT een meedenkende partner! De primaire verantwoordelijkheid voor de invoering ligt dan ook bij de gebruikersorganisatie. De informatici spelen een ondersteunende en adviserende rol.
In figuur 10 zijn de activiteiten in hun onderlinge samenhang weergegeven.

Zoals figuur 10 laat zien, worden tijdens de invoeringsfase taakbeschrijvingen opgesteld, de gegevensverzamelingen opgebouwd in hun nieuwe vorm en worden de gebruikers van het systeem opgeleid.
Het systeem zal tenslotte worden overgedragen aan de lijnorganisatie, die voor de goede werking daarvan de volledige verantwoordelijkheid gaat dragen.
Tot zover de diverse fasen die PPPP-IT onderkent in de ontwikkeling van een informatiesysteem. Deze fasering dient om in de ontwikkeling van dat informatiesysteem de verschillende mijlpalen te onderkennen en het systeem op te splitsen in overzichtelijke, goed hanteerbare eenheden.
Aangegeven werd hoe PPPP-IT in de diverse fasen (van Definitiestudie, Basisontwerp, Detailontwerp en Realisatie tot de uiteindelijke Invoering) omgaat met het begrip kwaliteit.
Het is PPPP-IT echter duidelijk dat het werk er na een perfecte voorbereiding, goede planning en dito uitvoering geenszins opzit. Goed onderhoud en beheer zijn eveneens onmisbare pijlers onder de kwaliteitsbenadering van PPPP-IT. 

5.3 Onderhoud van informatiesystemen

De onderhoudskosten over de life cycle van een informatiesysteem zijn vaak aanzienlijk hoger dan de ontwikkelingskosten. Bovendien is de zorgvuldigheid van het onderhoud in hoge mate bepalend voor de levensduur van een systeem. Redenen waarom PPPP-IT kiest voor een projectmatige aanpak van het zo belangrijke onderhoudsaspect. Dit betekent dat er per jaar een nader met de klant overeen te komen aantal releases van een informatiesysteem gemaakt wordt. Voor elke release wordt dan vervolgens een project ingericht, waarin kwaliteit, tijd en geld beheerst worden conform het geldende kwaliteitssysteem. 

5.3.1 Onderhoudsaanpak

De projectmatige aanpak van onderhoud is in feite niets anders dan het in kort bestek toepassen van diverse ontwikkelingsfasen van het Kwaliteitshandboek, zoals die hiervoor zijn gepresenteerd.
Deze aanpak bevat de volgende stappen:

• Problemen en wensen van de gebruikers worden aangemeld. Het verwerken ervan vindt plaats conform de wijzigings- of probleemrapportageprocedure. Daarnaast vindt per release een evaluatie plaats, waarin actief geïnventariseerd wordt welke overige wensen nog leven bij de gebruikers. Deze evaluatie wordt uitgevoerd door een werkgroep bestaande uit applicatiebeheerders en materiedeskundigen van de klant en de contactpersoon van PPPP-IT. Deze groep zorgt ervoor dat de wensen formeel vastgelegd worden in termen van de gewenste oplossing.
• Vervolgens is de contactpersoon verantwoordelijk voor het (laten) maken van een schatting voor de benodigde inspanning. Op basis van deze schatting komt de werkgroep tot een prioriteitsstelling en een definitieve opdrachtformulering voor de ontwikkeling van de nieuwe release. In feite hebben de voorgaande stappen het karakter van een Definitiestudie.
• Hierna stelt de werkgroep prioriteiten en geeft opdracht aan de contactpersoon om het project te plannen opdat het onderhoudswerk uitgevoerd kan worden. Dan worden door de werkgroep de gewijzigde functionele specificaties vastgelegd en overgedragen aan de onderhoudsgroep, één en ander vanzelfsprekend op basis van de specificaties van de gebruiker. Er is hier dus eigenlijk sprake van een Functioneel ontwerp. Als een bepaald project van grote omvang is of complex van aard, kan hiervoor ook een ontwerper van PPPP-IT ingezet worden om de onderhoudbaarheid van het systeem niet in gevaar te brengen. Indien het ook veranderingen in de hardware of systeemsoftware betreft, worden eerst de consequenties ervan geanalyseerd. In dit laatste geval wordt er in feite een verkort Basisontwerp uitgevoerd.
• De onderhoudsgroep verwerkt de specificaties in het technisch ontwerp (documenteren) en realiseert vervolgens de nieuwe release. Vervolgens worden de programmatest en de systeemtest uitgevoerd door het onderhoudsteam. In termen van het Kwaliteitshandboek is dit de uitvoering van het technisch Detailontwerp en de Realisatie.
• Tenslotte voert de aangewezen testgroep van de klant de acceptatietest uit en na acceptatie worden de gebruikers van het systeem geïnformeerd en wordt de release overgedragen aan de productie. Zonodig wordt het productieplan aangepast en worden eventuele conversies uitgevoerd.

5.3.2 Urgent onderhoud

Uiteraard zullen er situaties voorkomen dat onderhoud echt niet kan wachten tot de volgende release. Na erkenning van de noodzaak ervan door de applicatiebeheerder en aanmelding bij de contactpersoon, zal in dergelijke gevallen het noodzakelijke onderhoud zo spoedig mogelijk uitgevoerd worden in de vorm van een noodoplossing. Het is dan wel verplicht dat in de volgende release deze noodoplossing vervangen wordt door een regulier tot stand gekomen wijziging.
Het beleid van de werkgroep zal er dan ook op gericht zijn om dergelijk onderhoud zoveel mogelijk te voorkomen. Bijvoorbeeld door de planning van een nieuwe release af te stemmen op een aangekondigde wetswijziging. En natuurlijk door problemen actief op te sporen voor ze urgent worden. Voorkomen is immers beter dan genezen.
Dus, ter voorkoming van ‘noodzaken’: goed onderhoud, een noodzaak! 

Deel 3

6. Inrichting van het project

In deel 3 van dit artikel werken we dit aspect verder uit.

7. Meer over kwaliteitsbeheer ICT

Meer over kwaliteitssystemen vindt u in de rubrieken ‘Kwaliteitsmanagement ICT‘. 

8. Nawoord

Tot zover de methodiek voor systeemontwikkeling op basis van SDM.
In deel 3 van dit kwaliteitshandboek gaan we verder in op Projectbeheersing. Het raamwerk voor het kwaliteitshandboek vindt u in deel 1.