Alle rechten op deze cursustekst blijven voorbehouden aan de auteur.
Het doel van de levenscyclus systeemontwikkeling is het beheerst verloop van de ontwikkeling van informatiesystemen. De levenscyclus systeemontwikkeling is de laatste stap van de vierfasige informatieplanning, als de eigenlijke automatiseringsprojecten worden gerealiseerd.
Systeemontwikkeling is een proces dat in veel organisaties een problematisch karakter kent. De meeste problemen zijn onder te brengen in één van de volgende twee categorieën:
De levenscyclus systeemontwikkeling die we in deze tekst beschrijven, bestaat uit niet minder dan zeven fasen:
De eerste drie fasen bepalen welk informatiesysteem we gaan ontwikkelen. Ze zijn cruciaal voor de effectiviteit van het systeem, en dus ook van het proces 'systeemontwikkeling'. De laatste vier fasen hebben meer te maken met het hoe van de systeemontwikkeling: ze bepalen de efficiëntie van de systeemontwikkeling.
De levenscyclus systeemontwikkeling die we in deze cursus hanteren, heeft het karakter van een waterval-model. Dat wil zeggen dat de zeven fasen elkaar lineair opvolgen, en dat iedere volgende fase uitgaat van de resultaten van de vorige fase.
Een andere aanpak, waarop we in deze cursus minder diep ingaan, bestaat in iteratieve applicatie-ontwikkeling (iterative application development, IAD). Bij deze aanpak wordt op korte tijd een volledig ontwikkelingstraject doorlopen voor een deel van het systeem. Dit gedeelte wordt piloot genoemd. Aan de hand van constructieve kritiek op de piloot, wordt vervolgens op korte tijd een nieuwe piloot gebouwd, enzovoort.
IAD is een krachtig instrument om de opdrachtgever nauw te betrekken bij het ontwikkelingstraject. In de praktijk moeten echter enkele voorwaarden vervuld zijn: de verantwoordelijke opdrachtgever moet voldoende vaak beschikbaar zijn (niet zijn of haar afgevaardigde !) voor de evaluatie van de opeenvolgende versies; het totale traject mag niet langer duren dan een zestal maanden; en het ontwikkelteam mag niet meer dan een zestal ontwikkelaars bevatten.
Het waterval-model heeft de volgende voordelen ten opzichte van andere aanpakken:
De belangrijkste nadelen van het waterval-model zijn:
Bouw nooit een informatiesysteem als je niet weet waarom.
Ieder zinvol initiatief tot het ontwikkelen van een informatiesysteem komt voort uit een meer globale analyse van de informatiebehoeften van de organisatie. Deze analyse moet voortkomen uit een strategische informatieplanning, of uit een concrete, urgente wijziging in de context van de bedrijfsvoering.
Iedere goede reden om een informatiesysteem te bouwen is te herleiden tot één van de volgende twee drijfveren:
Onder een probleem verstaan we: een objectief verschil tussen een uitdrukkelijk doel en de realiteit. Bijvoorbeeld: "de doelstelling was break-even na drie jaar, en we maken in het derde jaar nog steeds een verlies van 10 miljoen". Problemen kunnen nooit objectief worden vastgesteld als niet vooraf, in het kader van een strategische planning, meetbare doelstellingen zijn geformuleerd.
De eigenaar van het probleem is de persoon die verantwoordelijk was voor het realiseren van de doelstelling. De probleemeigenaar mag niet worden veward met de oorzaak van het probleem.
Voorbeeld. Teveel geweigerde produkten kunnen een gevolg zijn van een kwaliteitsprobleem, dat op zijn beurt wordt veroorzaakt door een falend personeelsbeleid (gebrekkige opleiding, onvoldoende motivatie, ...). De eigenaar van het probleem is de produktiemanager; de oorzaak van het probleem ligt misschien buiten zijn afdeling.
Meestal wordt nog een onderscheid gemaakt tussen efficiëntie-problemen en effectiviteits-problemen. Bij de eerste soort wordt de doelstelling globaal bereikt, maar ten koste van teveel inspanning, geld, tijd en middelen. Bij de tweede soort wordt de doelstelling gewoon gemist. Effectiviteitsproblemen zijn doorgaans ernstiger dan efficiëntieproblemen, maar deze laatste kunnen op termijn ook de effectiviteit van de organisatie gaan bedreigen. Voorbeeld: de jaarlijkse onderhoudskost van een computersysteem was geschat op 200 man-uren, maar bedraagt in werkelijkheid 400 man-uren. Dit is in eerste instantie een probleem van efficiëntie: het systeem werkt, maar kost teveel. Indien de onderhoudskost echter hoger wordt dan de opbrengst van het systeem, zal het management - terecht - de afschaffing of vervanging overwegen.
Een opportuniteit is een wijziging in de context van de organisatie, extern of intern, waardoor de ambities hoger kunnen worden gelegd dan de aanvankelijk geformuleerde doelstellingen, mits actief ingrijpen in de bestaande processen. Typische bronnen van opportuniteiten zijn: nieuwe afzetmarkten (deregulering, wijziging van exportregels, politieke veranderingen, modetrends), nieuwe aankoopmarkten (wijziging van importregels, nieuwe infrastructuur), nieuwe produktietechnieken, enz.,...
A priori zijn problemen en opportuniteiten gelijkwaardige motoren van verandering in een organisatie. Ze corresponderen met twee extremen in een continue schaal van management-stijlen: de zogenaamde reactieve versus de opportunistische manager.
Een bekend voorbeeld van succesvol reactief management wordt geleverd door voormalig eerste minister Jean-Luc Dehaene. Een inmiddels beruchte uitspraak van hem, in het kader van de hervorming van het gerecht, kenmerkt zijn hele regeerstijl:
"We moeten de problemen niet oplossen voor ze zich stellen."
Een proactief of opportunistisch manager zal de afwezigheid van problemen niet als een rustpunt zien, maar eerder als een moment waarop er eindelijk tijd is voor hervormingen:
"Laten we onze organisatie op punt stellen nu we er nog de kans toe hebben".
De oudste informatiserings-inspanningen in bedrijven waren er meestal op gericht, bestaande administratieve procedures te automatiseren: boekhouding, opvolging van schuldenaars, loonadministratie, ... Het bedrijf moest geen nieuwe activiteiten ontplooien, maar slechts de oude processen op een nieuwe manier laten verlopen: vlotter, goedkoper, correcter.
In het hoofdstuk informatieplanning beschreven we een aantal technieken om op strategisch niveau de richting van het informatiebeleid te bepalen. Drie van deze technieken hebben ook al hun nut bewezen bij het identificeren van afzonderlijke opportuniteiten, en kunnen dus deel uitmaken van het eigenlijke ontwikkelingsproces:
Een goed uitgangspunt voor de levenscyclus systeemontwikkeling zou kunnen bestaan in een tweedaagse brainstorm met de topmanagers van de onderneming.
Wegens onze definitie van het begrip probleem zijn problemen niet zo moeilijk te identificeren. Het is daarentegen veel moeilijker, de precieze oorzaak van een probleem te identificeren. De oorzaak kan in een geheel andere afdeling van de organisatie liggen, of zelfs in de buitenwereld.
Voorbeeld: een bouwonderneming stelt zich tot doel, vijftien procent winst te boeken op elk project. In de praktijk eindigt een derde van de bouwprojecten op een break-even of slechter.
Deze onderneming heeft blijkbaar een efficiëntie-probleem. De eigenaar is telkens de projectleider. Het probleem kan echter a priori zeer verscheidene oorzaken hebben:
Causaliteit, de relatie tussen oorzaak en gevolg, is in de filosofie geen eenvoudig begrip. Het enige waar men zeker van is, is dat de oorzaak aan het gevolg in de tijd vooraf gaat.
Wat voor de ene persoon een oorzaak lijkt, is voor de andere niet meer dan een uitwendig symptoom. Nochtans is het belangrijk, de werkelijke oorzaken van een probleem te kennen, in het bijzonder: kan snellere, betere informatie het probleem (gedeeltelijk) wegnemen of de gevolgen ervan verminderen ?
Een bekende valstrik in de oorzaak-analyse is het cum hoc ergo propter hoc: twee zaken die gewoonlijk samen optreden, hebben daarom nog geen oorzakelijk verband. Het samengaan kan toevallig zijn, of de twee kunnen een gemeenschappelijke, dieperliggende oorzaak hebben.
Voorbeeld. Een industriële bakkerij laat een studie uitvoeren naar de seizoenschommelingen in de produktiviteit.
| maand | uitval machines (%) | ziekteverzuim (%) |
|---|---|---|
| januari | 11 | 15 |
| februari | 2 | 8 |
| maart | 3 | 3 |
| april | 4 | 4 |
| mei | 0 | 2 |
| juni | 0 | 3 |
| juli | 0 | 0 |
| augustus | 1 | 0 |
| september | 5 | 1 |
| oktober | 4 | 5 |
| november | 12 | 11 |
| december | 9 | 6 |
Als we de cijfers mogen geloven, blijkt er een sterk verband te bestaan tussen het uitvallen van de machines en het ziek worden van de arbeiders ! Een oppervlakkige lezer zou kunnen denken dat de arbeiders zich ziek melden uit frustratie over de defecte machines (de mogelijkheid dat de zieke arbeiders de machines "besmetten", laten we buiten beschouwing). Even dieper nadenken en nauwkeuriger lezen levert echter een plausibeler verklaring: zowel de arbeiders als de machines lijden onder het winterweer.
Problemen en kansen verschillen ook onderling in de haalbaarheid van de oplossing. Het is niet omdat men zich een bepaalde verandering in principe kan voorstellen, dat deze ook eenvoudig kan tot stand worden gebracht.
Drie factoren beïnvloeden de haalbaarheid van een informatica-project:
Als uit de haalbaarheidsstudie nog steeds blijkt dat het project wenselijk is voor de organisatie, dan zal ze uitmonden in een projectvoorstel. Het projectvoorstel dient ter ondersteuning van de beslissing om al dan niet met het project van start te gaan, en wordt te dien einde aangeboden aan de beheerraad van de onderneming, of en ander orgaan of persoon die als beschermheer optreedt. Een projectvoorstel zal typisch de volgende onderdelen bevatten:
Een belangrijke en niet-triviale vraag in verband met de probleemdefinitie en de eruit volgende haalbaarheidsstudie met eventueel projectvoorstel, luidt: wanneer ? Met andere woorden: hoeveel onderzoeks- en ontwerpactiviteit moet voorafgaan aan de haalbaarheidsstudie, en hoeveel moet pas na de formele goedkeuring gebeuren ?
Als de haalbaarheidsstudie te vroeg wordt gepubliceerd, zal ze te oppervlakkig zijn. De belangrijke beslissing GO/NO GO is dan gebaseerd op twijfelachtige of onvolledige informatie.
Als de haalbaarheidsstudie zeer grondig gebeurt, bijvoorbeeld nadat reeds een belangrijk deel van het systeemontwerp vastligt, zijn de conclusies in het projectvoorstel betrouwbaarder. Het nadeel is dan, dat reeds vele man-uren zijn geïnvesteerd in een project dat zelfs nog niet is goedgekeurd. Ondanks een eventuele (terechte) afwijzing van het projectvoorstel zal reeds een hoeveelheid middelen "over de balk" zijn gegooid.
In de huidige bedrijfspraktijk doet het eerste probleem zich vaker voor dan het tweede. Projecten worden dikwijls opgestart zonder grondige fundering, alleen maar omdat een invloedrijk lid van de organisatie er zijn/haar prestige aan verbonden heeft.
"Neen" kunnen zeggen is een belangrijke management-kwaliteit, maar is soms psychologisch of politiek zeer moeilijk. Daarom wordt het zwart/witte projectvoorstel vaak vervangen door een risico-analyse. Een risico-analyse onderzoekt heel gelijkaardige factoren als de haalbaarheidsstudie, maar formuleert het antwoord genuanceerder: projecten met hoog risico worden niet zomaar afgeschoten, ze krijgen speciale maatregelen ter ondersteuning. Voorbeelden van dergelijke maatregelen zijn: soepele tijdschema's, ervaren personeel, trapsgewijze oplevering.
In de tweede fase van de levenscyclus systeemontwikkeling analyseren we de bestaande informatiesystemen. De uitgangspunten van de informatie-analyse zijn observatie en raadpleging van bestaande documentatie. De resultaten worden op hun beurt vastgelegd in één of meer analysedocumenten ter goedkeuring van de opdrachtgever.
Systeemanalyse is het opsplitsen van een organiek geheel in zijn samenstellende delen, en het beschrijven van de rollen en onderlinge verbanden van de verschillende organen.
Het is belangrijk dat we ons goed realiseren welke systemen we analyseren. In onze levenscyclus systeemontwikkeling spelen namelijk twee soorten systemen een rol, op verschillende niveaus.
Het objectsysteem is het gedeelte van de organisatie waarop de gewenste verandering betrekking heeft. De processen die erin omgaan kunnen zowel materieel als virtueel zijn.
Het informatiesysteem is een secundair systeem, zuiver virtueel, dat uitsluitend gericht is op het verzamelen, verwerken en produceren van informatie met betrekking tot het objectsysteem. Het resultaat van de levenscyclus systeemontwikkeling is in de eerste plaats een nieuw informatiesysteem, al kunnen ook veranderingen in het objectsysteem worden aangebracht.
Voorbeeld: als het objectsysteem een assemblagelijn van auto's is, dan behoort de rapportering van stilstanden tot het informatiesysteem.
In deze context gezien, bestaat de informatie-analyse ruwweg uit de volgende activiteiten:
Hierbij staan de volgende technieken ter beschikking van de analyst:
De eerste stap van een informatie-analyse is meestal het kritisch nalezen van de documentatie met betrekking tot het bestaande object- en informatiesysteem: de oorspronkelijke doelstellingen, gehanteerde procedures, rapporteringen, gebruikt materieel, ...
De observatie bestaat uit bezoeken aan de fabrieksvloer en andere belangrijke plaatsen in het objectsysteem, als aanvulling op de documentatie en om in het bijzonder na te gaan hoe de deelnemers aan het objectsysteem gebruik maken van informatie. Veelvuldig direct contact met de gebruikers kan ook later belangrijke psychologische voordelen hebben bij de invoering van het nieuwe informatiesysteem.
Interviews zijn vergaderingen met groepen of individuen om hen te ondervragen over hun rol in het informatiesysteem, en het gebruik dat ze ervan maken.
Vragenlijsten hebben hetzelfde doel als interviews, maar hebben meestal een meer algemeen karakter. Ze zijn een goedkoper alternatief voor interviews als grote aantallen informatiegebruikers moeten worden bevraagd.
Een interview mag dan wel duurder zijn dan een vragenlijst, gewoonlijk zal deze kleine investering zichzelf gemakkelijk terugverdienen door de onmiddellijke interactie en door de mogelijkheid van doorvragen of zelfs discussie.
Interview-vragen worden traditioneel onderverdeeld in open en gesloten vragen. Een open vraag nodigt de persoon uit om creatief, in de breedte na te denken over zijn antwoord. Een gesloten vraag vereist een precies antwoord.
Voorbeelden van open vragen zijn:
Voorbeelden van gesloten vragen zijn:
Een extreme vorm van de gesloten vraag is de meerkeuzevraag.
Geen van beide soorten vragen verdient een absolute voorkeur boven de andere soort: een combinatie van beiden is meestal aangewezen. Open vragen kunnen 'rijkere' antwoorden opleveren dan gesloten vragen. Gesloten vragen zijn eenvoudiger te verwerken en te quantificeren ten behoeve van het eindrapport.
Een gevaarlijke valstrik bij interviews is informatie-onwetendheid: managers, of andere beslissers, zijn zich niet bewust van de informatie die aan hun beslissingen ten grondslag ligt. Deze onwetendheid kan twee verschillende vormen aannemen, die allebei gevaarlijk zijn voor het succes van het nieuwe informatiesysteem:
Een goed uitgangspunt om de precieze informatiebehoefte van een gebruiker te analyseren, zijn de beslissingen die ze moet nemen om haar normale taken uit te voeren. Beslissingen zijn daarbij niet alleen de dramatische hoogtepunten uit iemands carrière, maar ook routinematige acties zoals het oproepen van een reparateur.
De documentatie van een bestaand (of gewenst) informatiesysteem kan de vorm aannemen van een tekstuele beschrijving. Teksten hebben echter het nadeel dat de lezer tijd moet vrijmaken om aandachtig te lezen, en dan nog kunnen sommige beschrijvingen anders worden begrepen dan bedoeld. Informatici hebben al tientallen jaren goede ervaringen met modellen. Een model is een voorstelling van de werkelijkheid waarin bepaalde vereenvoudigingen (abstracties) worden gemaakt om de essentie beter tot haar recht te doen komen.
Traditionele modellen van informatiesystemen vallen uiteen in twee categorieën:
De laatste tien jaar zijn ook object-georiënteerde modellen in voege gekomen: ze trachten de informatie over processen en gegevens geïntegreerd voor te stellen. Objectmodellen zijn vooral nuttig als ook de latere fasen van de systeemontwikkeling, vooral met name de ontwerp en het programmeren, voldoen aan het object-georiënteerde paradigma.
In deze tekst beperken we ons tot de traditionele aanpak, waarbij processen en gegevensstructuren afzonderlijk worden in kaart gebracht.
Zowel voor procesmodellen als voor gegevensmodellen staan verschillende diagram-technieken ter beschikking. We bespreken hier kort één van elk: Data Flow Diagrams als procesmodel, en Entity-relationship Diagrams als gegevensmodel.
[1] Turban, Efraim, McLean, Ephraim en Wetherbe, James, "Information Technology for Management - Improving Quality and Productivity," John Wiley and Sons 1996, ISBN 0-471-58059-7.
[2] Whitten, Jeffrey L., Bentley, Lonnie D. en Dittman, Kevin C., "Systems Analysis and Design Methods," 4de uitgave, Irwin McGraw-Hill 1998, ISBN 0-256-19906-X.
[3] Curtis, Graham, "Business Information Systems - Analysis, Design and Practice," 2de uitgave, Addison-Wesley 1995, ISBN 0-201-62449-4.
Waarin onderscheiden fasen 1-3 van de levenscyclus systeemontwikkeling (problemen en kansen identificeren, bestaande situatie beschrijven, informatiebehoeften analyseren) zich fundamenteel van fasen 4-7 (ontwerp, bouw en test, implementatie, evaluatie en onderhoud) ?
De eerste drie fasen trachten een antwoord te formuleren op de vraag "WAT". Ze garanderen de effectiviteit van de systeemontwikkeling: ontwikkelen we wel het juiste systeem ?
De laatste vier fasen trachten een antwoord te formuleren op de vraag "HOE". Ze garanderen de efficiëntie van de systeemontwikkeling: ontwikkelen we het systeem wel op de juiste manier ?
Wat zijn, bij de volgende informatica-projecten, sterke en zwakke punten van een waterval-levenscyclus ? Van een iteratieve aanpak ? Van 'erinvliegen' (d.w.z. geen formele levenscyclus) ? Argumenteer kort (telkens maximum 20 woorden).
opvolging van de public relations voor een politieke partij, zodat de voorzitter tijdens televisie-vraaggesprekken sneller en beter kan inspelen op nieuwe politieke ontwikkelingen
De eventuele onzekerheid over de functionele specificaties, en de beperkte grootte van het project, suggereren een iteratieve aanpak. Nadelig is de (vermoedelijk) geringe beschikbaarheid van de partijvoorzitter voor de wekelijkse evaluatie-sessies, wat dan weer in de richting van een waterval-aanpak wijst.
Erinvliegen zonder formele planning riskeert dat het project onbeheersbaar wordt.
ontwikkeling van een cool multimedia-spelletje (type 'seek and destroy') dat via de rekken van computerwinkels massaal zal verkocht worden
Het is onwaarschijnlijk dat de specificaties op voorhand bekend zijn, dus iteratieve ontwikkeling heeft enorme voordelen op een waterval-model. De niet-beschikbaarheid van de klant tijdens het ontwikkelingsproces kan worden opgevangen door kritische proef-klanten in te huren.
Erinvliegen zonder formele planning riskeert ook hier dat het project onbeheersbaar wordt.
Een bedrijfsleider klaagt over de volgende 'problemen' in zijn
onderneming. Identificeer de échte problemen (volgens de definitie
van de cursus), en geef telkens aan wie de eigenaar is. Indien je een
veronderstelling moet maken over de onderneming, moet je die expliciet
formuleren.
"Vorig jaar was de winst niet zo best. Dat is voornamelijk
te wijten aan de blokkades op de Franse snelwegen. Verder is de helft
van ons computerpersoneel naar de concurrentie overgelopen. Dat is
zeven man, één vierde van ons hele personeelsbestand ! Mede daardoor
heeft ons nieuwe voorraadsysteem dubbel zo veel gekost als
aanvankelijk door de projectleider/analyst voorspeld. Gelukkig was het
nog niet te veel over tijd, anders hadden we die ene belangrijke
nieuwe klant in oktober gemist."
Een probleem is een objectief verschil tussen de gestelde doelen en de realisaties. De probleemeigenaar is degene die voor de realisatie van de doelstelling verantwoordelijk was.
De enige doelstelling die uit bovenstaande tekst uitdrukkelijk naar voren komt als 'niet gehaald', is het budget van het nieuwe voorraadsysteem. De probleemeigenaar is de projectleider, aangezien hij/zij verantwoordelijk is voor het projectbudget.
De geringe winst kan een probleem zijn, als er een verschil is met de geplande winst. In dat geval is de algemeen directeur verantwoordelijk.
Het personeelsverloop kan een probleem zijn, als er een doelstelling geformuleerd was met betrekking tot de stabiliteit van het personeelsbestand. In dat geval is de eigenaar ofwel de personeelschef, ofwel de informaticadirecteur, naargelang of de doelstelling geformuleerd was in termen van het algemene personeelsbestand of het informatica-personeelsbestand, en naargelang wie voor die doelstelling verantwoordelijk was.
Welke van de volgende uitspraken horen thuis in een projectvoorstel ? In welke rubriek ?
De eerste en de vierde uitspraak betreffen uitsluitend de technische realisatie van het project, en horen als dusdanig niet thuis in het projectvoorstel.
De tweede uitspraak zou kunnen thuishoren in de rubriek 'benodigde middelen', maar kan ook het 'formele verzoek' expliciteren.
De derde uitspraak geeft de gevolgen van afwijzing aan.
De vijfde uitspraak geeft een alternatief voor het huidige voorstel, met de eraan verbonden consequenties.
De zesde uitspraak signaleert een (strategisch) probleem, namelijk een manifeste afwijking tussen realiteit en een gesteld doel.
De zevende uitspraak hoort bij de informatie-analyse, dus in fase 3 (misschien fase 2) van de levenscyclus, maar normaal niet in een projectvoorstel.
Bij de analyse van een onderneming wordt ondermeer een proces "aankoop grondstoffen" onderscheiden. Wie wordt geïnterviewd om te peilen naar de informatiebehoeften van dit proces ?
Minstens worden de personen geïnterviewd die verantwoordelijk zijn voor processen waar informatie met betrekking tot aankopen wordt gebruikt en/of aangemaakt. Dit zijn in elk geval de aankoper en de produktiemanager(s), misschien ook de financieel directeur.
Bij de analyse van een onderneming wordt ondermeer een proces "aankoop grondstoffen" onderscheiden. Maak een kort gestructureerd interview (drie vragen) om te peilen naar de informatiebehoeften van dit proces, gebruikmakend van de techniek 'critical success factors'.
Maak een DFD (één niveau) voor het proces 'deliberatie'. Het diagram moet minstens de volgende elementen bevatten: prof, student, delibereer, punten.
| conditie | ||||||
|---|---|---|---|---|---|---|
| geen tekorten | j | n | n | j | n | n |
| som tekorten <= 3 | j | j | n | j | j | n |
| totaal >= 55% | j | j | j | n | n | n |
| actie | ||||||
| proclameer 'geslaagd' | X | X | X | |||
| proclameer 'niet geslaagd' | X | X | X |
In de ontwerpfase van de levenscyclus systeemontwikkeling spelen de volgende elementen een belangrijke rol: invoerdefinities (input definitions), gegevens-woordenboek (data dictionary), logische gegevensstructuur (logical data structure), logica-definities (logic definitions), uitvoerdefinities (output definitions). Welke van deze vijf elementen bindt de andere vier aan elkaar ? Geef een voorbeeld van hoe dit centrale element twee andere elementen aan elkaar bindt.
De data dictionary vormt het bindende element.
In het volgende voorbeeld zien we hoe het woordenboek-element 'pensioennummer' het verband legt tussen een aantal logica-definities (processen) en de logische gegevensstructuren waarin het element optreedt.
Naam gegevens-element: pensioennummer Komt voor in de logische gegevensstructuren: persoon (sleutelveld), storting, uittreksel. Wordt gebruikt door processen: bereken_uittreksel, registreer_storting, creëer_werknemer, registreer_overlijden.
inhoudstafel en auteursrecht
* STER *
