Innoverend informatiseren Aanpak en werkwijze van informatiesysteemontwikkeling

SI-Innoveren_ASdef

13-02-2006

13:14

Pagina 1

STARTBLOKKEN INFORMATICA

René Lewis is werkzaam als ICI-adviseur bij de Nederlandse politie en actief in een aantal landelijke trajecten. Andre Wanders is partner en manager consultant bij het adviesbureau In View.

De reeks Startblokken Informatica is bestemd voor het hoger beroepsonderwijs, het cursorisch onderwijs (HG-opleidingen, I-Tracks) en als zelfstudiemateriaal. De reeks is gebaseerd op de specificaties van Stichting EXIN.

90 12 11323 7 980

9 789012 113236

RENÉ LEWIS EN ANDRÉ WANDERS

Startblokken Informatica Startblokken Informatica is een leerboekenreeks van Sdu uitgevers, gebaseerd op twee maatschappelijke ontwikkelingen: a. iedereen, in elke functie, in elke branche en zowel privé als zakelijk, komt in aanraking met de consequenties van informatica en automatisering b. de opleidingsinstituten zijn op zoek naar modulaire leerstof. De tijd is voorbij van een duur en allesomvattend studieboek over informatica waaruit een deel behandeld werd. Men zoekt maatwerk in leerstof, met een bijbehorende prijs.

Innoverend informatiseren

In dit deel van de Startblokken Informatica wordt ingegaan op de aanpak, denkwijzen en werkwijzen voor het ontwikkelen van informatiesystemen. Aan de hand van de zevenkleurige bril wordt aangegeven welke aspecten van systeemontwikkeling te onderscheiden zijn. Vervolgens worden de verschillende werkwijzen en het proces van systeemontwikkeling behandeld, waarna informatiesystemen getypeerd worden op grond van de beoogde toepassing en de te gebruiken hardware. Tot slot wordt een overzicht gegeven van de relatie tussen het type informatiesysteem, de hardware en de meest geschikte wijze van ontwikkelen. Bij dit deel hoort een vervolg van dezelfde auteur, dat nader ingaat op de mogelijke technieken en hulpmiddelen voor informatiesysteemontwikkeling.

Innoverend informatiseren Aanpak en werkwijze van informatiesysteemontwikkeling René Lewis en André Wanders

04_lewis_sdu

01-03-2006

11:51

Pagina I

Innoverend informatiseren, aanpak en werkwijze van informatiesysteemontwikkeling

04_lewis_sdu

01-03-2006

11:51

Pagina II

04_lewis_sdu

01-03-2006

11:51

Pagina III

Innoverend informatiseren, aanpak en werkwijze van informatiesysteemontwikkeling René Lewis en André Wanders

Sdu

04_lewis_sdu

01-03-2006

11:51

Pagina IV

Meer informatie over deze en andere uitgaven kunt u verkrijgen bij: Sdu Klantenservice Postbus 20014 2500 EA Den Haag tel.: (070) 378 98 80 fax: (070) 378 97 83 © 2006 Sdu Uitgevers bv, Den Haag Academic Service is een imprint van Sdu Uitgevers bv. Dit boek is eerder onder dezelfde titel verschenen bij ten Hagen en Stam Uitgevers, Den Haag Omslagontwerp: Frans Meijer Redactie en zetwerk: LINE UP tekstprodukties bv, Groningen Druk- en bindwerk: Drukkerij De Groot, Goudriaan ISBN 90 12 11323 7 NUR 980

Alle rechten voorbehouden. Alle auteursrechten en databankrechten ten aanzien van deze uitgave worden uitdrukkelijk voorbehouden. Deze rechten berusten bij Sdu Uitgevers bv. Behoudens de in of krachtens de Auteurswet 1912 gestelde uitzonderingen, mag niets uit deze uitgave worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Voorzover het maken van reprografische verveelvoudigingen uit deze uitgave is toegestaan op grond van artikel 16 h Auteurswet 1912, dient men de daarvoor wettelijk verschuldigde vergoedingen te voldoen aan de Stichting Reprorecht (postbus 3060, 2130 KB Hoofddorp, www.reprorecht.nl). Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet 1912) dient men zich te wenden tot de Stichting PRO (Stichting Publicatie- en Reproductierechten Organisatie, Postbus 3060, 2130 KB Hoofddorp, www.cedar.nl/pro). Voor het overnemen van een gedeelte van deze uitgave ten behoeve van commerciële doeleinden dient men zich te wenden tot de uitgever. Hoewel aan de totstandkoming van deze uitgave de uiterste zorg is besteed, kan voor de afwezigheid van eventuele (druk)fouten en onvolledigheden niet worden ingestaan en aanvaarden de auteur(s), redacteur(en) en uitgever deswege geen aansprakelijkheid voor de gevolgen van eventueel voorkomende fouten en onvolledigheden. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the publisher’s prior consent. While every effort has been made to ensure the reliability of the information presented in this publication, Sdu Uitgevers neither guarantees the accuracy of the data contained herein nor accepts responsibility for errors or omissions or their consequences.

04_lewis_sdu

01-03-2006

11:51

Pagina V

Voorwoord

Informatica is niet meer weg te denken uit de huidige samenleving; iedereen wordt ermee geconfronteerd in het dagelijks leven, zowel zakelijk als privé. Voor het beroepsonderwijs heeft dat als consequentie dat Basiskennis Informatica een noodzakelijk onderdeel van de opleiding is geworden. Voor het Hoger Beroepsonderwijs baseren we ons op de specificaties die door de Stichting EXIN (Exameninstituut Informatica Nederland) zijn opgesteld om door het afleggen van de examens HG1, HG2 en HG3 het Basisdiploma AMBI te verkrijgen. Ook in de propedeusefase van het Hoger Beroepsonderwijs vinden we deze basiskennis van de informatica. Deze specificaties betreffen de volgende onderwerpen: – Informatie Technologie, waarbij aan de orde komen: • hardware • software • netwerken • databases. – Bij de Organisatie bespreken we: • structuur en doelstellingen • informatiebehoeften • betrokkenheid bij het ontwikkelen van informatiesystemen. – Gebruik van Informatie Technologie, zowel in de maatschappij als binnen organisaties. – Bij Systeemontwikkeling komen aan de orde: • projectaanpak • methoden en technieken. De boekenreeks ‘Startblokken Informatica’ behandelt deze onderwerpen. Bij de opzet van de boeken zijn de specificaties van Stichting EXIN als uitgangspunt genomen. Als extra onderwerpen komen ook recente ontwikkelingen op de diverse gebieden aan de orde die niet in de specificaties vermeld zijn.

04_lewis_sdu

01-03-2006

11:51

Pagina VI

Door deze opzet verwachten wij dat deze boeken niet alleen goed bruikbaar zijn bij de vakken op het gebied van de informatica in de propedeusefase van het Hoger Beroepsonderwijs, maar tevens een ondersteuning geven voor diegenen die zich door cursussen of zelfstudie voorbereiden op het afleggen van de HG-examens. Wij wensen de gebruikers van deze reeks veel succes toe bij hun studie van de informatica. Voor opmerkingen en aanmerkingen houden wij ons gaarne aanbevolen. Bussum, juli 1998 Roelof van der Kamp

04_lewis_sdu

01-03-2006

11:51

Pagina 1

Inhoud

Ten geleide

3

1 1.1 1.2 1.3

Informatiesysteemontwikkeling Algemene introductie De levensfasen van een informatiesysteem Denkwijze, werkwijze en notatiewijze Samenvatting

5 5 8 9 10

2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8

Denkwijzen De zevenkleurige bril BPR Procesmodellering Gegevensmodellering Boodschap, inhoud en betekenis Gedragsmodellering Objectoriëntatie De invalshoek Samenvatting

11 11 14 15 18 22 26 29 31 34

3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Werkwijzen Lineair Prototyping Cyclisch (of iteratief) Incrementeel Evolutionair Standaardpakketten RAD: rapid application development Gevolgen voor de informaticus Samenvatting

35 35 36 39 39 40 40 42 43 44

4 4.1 4.2 4.3

Het proces van systeemontwikkeling Kwaliteitsmanagement Informatieplanning Informatiebehoefte

45 46 49 50

04_lewis_sdu

01-03-2006

11:51

Pagina 2

4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11

Ontwerp, bouw en testen Acceptatietest Invoering Opleiding Conversie Ingebruikneming Gebruik en beheer ITIL Samenvatting

51 53 54 56 57 57 58 58 61

5 5.1 5.2 5.3 5.4 5.5

Producten van systeemontwikkeling Applicatietypen Applicaties naar functionaliteit Applicatie naar type hardware-omgeving Recente ontwikkelingen Type toepassing en type ontwikkelmethode Samenvatting

63 63 64 67 68 71 74

Literatuurlijst Register

77 79

04_lewis_sdu

01-03-2006

11:51

Pagina 3

3

Ten geleide

Dit boek over de ontwikkeling van informatiesystemen maakt deel uit van een reeks boeken voor de propedeusefase in het HBO. Deze reeks is tevens geschikt ter ondersteuning van de HG-modulen van de AMBIstudie. Zoals de titel al aangeeft, behandelt dit deel het ontwikkelen van informatiesystemen, waarbij met name ingegaan wordt op de volgende aspecten: – de aanpak: hierbij gaat het vooral om denkwijzen of benaderingswijzen – de werkwijzen: een aantal methoden of werkwijzen zal de revue passeren, waarbij zeker niet naar volledigheid is gestreefd – de besturing van het proces van systeemontwikkeling – de verdeling van applicaties – de producten of resultaten van systeemontwikkeling – in een aantal categorieën – de relatie tussen proces en product: welke aanpak is het meest geschikt voor welk type applicatie. We hebben geprobeerd de te behandelen onderwerpen te illustreren met voorbeelden, maar ieder voorbeeld heeft zijn beperkingen en kan dus het te behandelen onderwerp niet volledig dekken. In deze herziene uitgave van ons boek behandelen we systeemontwikkeling vooral op het niveau van organisatie en besturing van het proces van systeemontwikkeling. De onderwerpen aangaande methoden en technieken voor de uitvoering van ontwerp en analyse, die in eerdere uitgaven van dit boek nog aan de orde kwamen, zijn in een geheel nieuw deel in deze reeks ondergebracht: Innoverend Informatiseren; methoden, technieken en tools voor informatiesysteemontwikkeling. De auteurs houden zich aanbevolen voor suggesties voor andere, illustratieve voorbeelden en verdere opmerkingen over de inhoud. Hoorn/Naarden, juni 1998 René Lewis/André Wanders

04_lewis_sdu

01-03-2006

11:51

Pagina 4

04_lewis_sdu

01-03-2006

11:51

Pagina 5

5

1

Informatiesysteemontwikkeling

In het eerste hoofdstuk van dit boek zetten we het begrippenkader neer. De rode draad die door het boek loopt, wordt gevormd door de begrippen denkwijze, werkwijze en notatiewijze, of woorden die dezelfde begrippen aanduiden. In de hoofdstukken 1 tot en met 3 wordt vooral de theorie rond deze begrippen behandeld; in de hoofdstukken 4 en 5 komt de relatie tussen aanpak en beoogd resultaat aan de orde.

1.1 Algemene introductie

informatiesysteem

Hoewel het op het eerste gezicht een open deur lijkt te zijn, willen we beginnen met de titel van dit hoofdstuk nader te verklaren. Het eerste deel van het woord informatiesysteemontwikkeling is ‘informatiesysteem’:

–––

|

Een informatiesysteem beschouwen we als het geheel van gegevens, bewerkingen op die gegevens en besturing van die bewerkingen, met het doel gegevens beschikbaar te stellen.

–––

|

Hiertoe moet het systeem in staat zijn gegevens te verzamelen, op te slaan, te bewerken en te distribueren. ontwikkeling

Het tweede deel van het woord informatiesysteemontwikkeling is ‘ontwikkeling’:

–––

|

Ontwikkeling is het planmatig realiseren van een tevoren beschreven resultaat.

–––

|

04_lewis_sdu

01-03-2006

6

11:51

Pagina 6


Zowel uit de literatuur als uit de praktijk blijkt het ontwikkelen van het veelal complexe product informatiesysteem een complex proces te zijn. Om tot een zo goed mogelijk product te komen, moet dit proces zo goed mogelijk worden beheerst. Deze noodzaak heeft zich in meerdere planmatige en gestructureerde aanpakken vertaald, die bestaan uit het gebruik van adequate en onderling samenhangende instrumenten, zoals methoden, technieken en geautomatiseerde hulpmiddelen. Hiermee is tevens het tweede deel van de titel van dit hoofdstuk toegelicht. bouwstenen

Een goede methode bestaat uit een aantal bouwstenen: – het doel (waarvoor) – de werkwijze (hoe) – de fasering, het scenario (wat, wanneer) – de organisatie (wie) – het ’gereedschap’ of de technieken (waarmee). Zoals uit de volgende hoofdstukken zal blijken, zijn in lang niet alle methoden al deze bouwstenen daadwerkelijk aanwezig.

doel

Hoewel de vraag naar het doel van een informatiesysteem een voor de hand liggende vraag is, blijkt dat een goede ondersteuning voor het bepalen van het doel van een informatiesysteem nog niet erg ver ontwikkeld is. We zullen in het navolgende zien dat deze vraag zelden onderdeel uitmaakt van methoden. Bij het bepalen van het doel kunnen overwegingen op alle drie de managementniveaus een rol spelen: – strategisch niveau (marktpositie, marktontwikkeling) – tactisch niveau (concurrentie op in- en verkoopmarkten) – operationeel niveau (verbetering efficiëntie, aansturing bedrijfsprocessen, financieel management). Wil het geheel flexibel zijn, dan dient bovendien rekening te worden gehouden met de behoefte van de betrokkenen, alsmede met organisatorische, technische en andere situatiegebonden factoren. In dit boek zullen we deze vraag, die onder andere betrekking heeft op informatieplanning en kosten-batenanalyse, laten rusten. We verwijzen naar het boek Gebruik van informatietechnologie in deze reeks, dat de relatie behandelt tussen informatie- en communicatietechnologie (ICT), samenleving en organisatie. Tevens gaat het in op ICT binnen organisaties, de kwaliteit van informatie en de kosten van ICT in relatie tot investeringsbeslissingen.

invalshoek

Onder werkwijze of invalshoek verstaan we de aanpak, waarbij men onderscheid kan maken tussen:

04_lewis_sdu

01-03-2006

11:51

Pagina 7


7

– top-down – bottom-up – centre-out.

benaderingswijzen

fasering

organisatie

Aan de onderlinge samenhang van methoden, technieken en tools liggen een of meer filosofieën ten grondslag. Deze filosofieën worden vaak aangeduid als benaderingswijzen of denkwijzen. Over deze onderlinge relatie gaat hoofdstuk 2. Het product (het ontwikkelde of aangepaste informatiesysteem) kan op diverse manieren tot stand komen (fasering): lineair, via prototyping, cyclisch (ook wel iteratief) of evolutionair. Al deze manieren van werken hebben een bepaalde vaste aanpak. Ze worden dan ook wel eens samengevat met de term scenario-aanpak. Deze onderwerpen worden nader behandeld in hoofdstuk 3. De organisatie van het proces van systeemontwikkeling gaat in de eerste plaats over de vraag: wie doen er mee? Veelal worden informatiesystemen ontwikkeld of aangepast via projectmatig werken. Een project kenmerkt zich door het eenmalige karakter van de opdracht, de vereiste multidisciplinaire aanpak, de begrensde hoeveelheid tijd en geld, en de gevolgen voor de organisatie. Het boek Projectmatig werken in deze reeks behandelt alle belangrijke aspecten hiervan, zoals het communicatieproces, de projectorganisatie, de projectaanpak en de projectwerkzaamheden. De vraag naar wat en wanneer (fasering) hang hiermee samen. Een complete beschrijving van de combinatie wie doet wat en wanneer vormt het plan van aanpak voor een systeemontwikkelingsproces en derhalve het projectplan. Hoofdstuk 4 beschrijft deze relatie tussen inhoud, werkwijze en planning (wat, hoe en wanneer) voor het ontwikkelen van geautomatiseerde informatiesystemen. We gaan ook (kort) in op de vraag of bepaalde activiteiten projectmatig zou moeten worden uitgevoerd of een regulier onderdeel van de staande organisatie zouden moeten vormen. Dit onderwerp komt in de volgende paragraaf (1.2) aan de orde.

technieken

Aan technieken (ook wel notatiewijzen genoemd) kunnen de volgende eisen worden gesteld: – reductie van de complexiteit – ondersteuning van het denkproces – mogelijkheid van controle op juistheid.

tools

Geautomatiseerde hulpmiddelen (tools) dienen ter ondersteuning van het systeemontwikkelingsproces. Dit betekent dat deze tools:

04_lewis_sdu

01-03-2006

8

11:51

Pagina 8


– de samenhang van de ondersteunde technieken moeten bewaken – beschikbaar moeten zijn op de meest voorkomende platforms (combinaties van hardware en systeemsoftware) – producten moeten ontwikkelen die op (meerdere van) de meest voorkomende platforms in productie moeten kunnen worden genomen. Technieken en de rol van geautomatiseerde hulpmiddelen komen in ons andere boek in deze reeks, Innovatief informatiseren; methoden, technieken en tools voor informatiesysteemontwikkeling, uitvoerig aan de orde. Ter afronding van dit inleidende hoofdstuk willen we iets zeggen over de levenscyclus van een (informatie)systeem (men spreekt ook wel van ‘systems life cycle’). We brengen de verschillende fasen van deze levenscyclus meteen in relatie tot de hiervoor al opgeroepen vraag: wie doet wat?

1.2 De levensfasen van een informatiesysteem

systems life cycle

Informatiesystemen kennen, overeenkomstig veel andere technische producten, drie levensfasen: productontwikkeling, ingebruikneming en onderhoud. Men noemt dit ook wel de systems life cycle. Bij informatiesystemen gebruikt men bij deze drie fasen veelal de volgende begrippen: – ontwerp en bouw – conversie en invoering – gebruik en beheer. De diverse fasen die in verschillende methoden worden genoemd, zoals vooronderzoek, definitiestudie, functioneel ontwerp, technisch ontwerp, bouwen en testen, behoren in deze driedeling alle tot de fase ‘ontwerp en bouw’. Evenzo behoren (her)ontwerp formulieren, opleiden, installeren, converteren en ingebruikneming tot de fase ‘conversie en invoering’. Het is overigens interessant te zien dat veel boeken over systeemontwikkeling de fase van invoering (en de volgende fase van gebruik en beheer) slechts oppervlakkig behandelen. En dat terwijl de kwaliteit en het succes van een methodisch keurig ontworpen en gebouwd systeem bepaald wordt door de kwaliteit van de invoering en het beheer! Daarbij komt dat, zeker nu, door alle hulpmiddelen, de kosten van ontwerp en bouw hooguit enkele tientallen procenten bedragen van de kosten van invoering en beheer. In hoofdstuk 2 doen we een poging tot een meer evenwichtige benadering.

04_lewis_sdu

01-03-2006

11:51

Pagina 9


9

Een ander aspect dat we hier willen noemen is de wijze van organiseren van de uitvoering. Het is gebruikelijk een projectteam in te richten dat een groot deel van het traject van de systems life cycle voor zijn rekening neemt. Voor zover dit activiteiten betreft die voldoen aan de criteria van een project (eenmalig, vooraf bepaald doel, beperkt budget, beperkte tijd, meerdere deskundigheden nodig) is dit prima, maar bepaalde activiteiten, met name informatiemanagement, onderhoud en beheer, voldoen niet aan deze criteria. Deze taken, die continue processen vormen, dienen op continue basis in de staande organisatie te zijn belegd.

1.3 Denkwijze, werkwijze en notatiewijze Informatiesystemen dienen een of meer problemen op te lossen en te voldoen aan de (informatie)behoefte(n) van de organisatie, het management en de gebruikers. Er zijn verschillende manieren om naar deze problemen respectievelijk behoeften te kijken. Deze filosofieën, denk- of benaderingswijzen, of invalshoeken vormen de bril waarmee naar de werkelijkheid wordt gekeken. Dit heeft niet alleen directe gevolgen voor de werkwijze tijdens het realiseren van informatiesystemen (faseren, gebruik technieken en wijze van ontwikkelen), maar ook voor de manier waarop een en ander in modellen wordt vastgelegd (de notatiewijze). Er zijn veel verschillende denkwijzen. Elke denkwijze biedt de mogelijkheid om vanuit een bepaald perspectief inzicht te verkrijgen in de organisatie en haar problemen en wensen. Eén van de manieren om problemen op te lossen en wensen te vervullen, is het gebruik van een informatiesysteem. Zodra hiervoor is gekozen, kan worden bepaald welke werkwijze men wil hanteren. Het is hierbij belangrijk dat de gekozen werkwijze samenhangt met de (belangrijkste) denkwijze. Bijvoorbeeld: voor procesbesturingssystemen (zoals in energiecentrales) is vooral het gedrag van belang, voor verzekeringsmaatschappijen zijn met name de gegevens van belang en bij de BankGiroCentrale gaat de aandacht vooral uit naar de verwerking (het proces). Als de problemen en wensen door een andere bril worden bekeken, kunnen andere oplossingen naar voren komen, bijvoorbeeld een reorganisatie, omdat blijkt dat de verkeerde mensen de verkeerde dingen doen, of een andere overlegstructuur, omdat blijkt dat de interne afstemming niet klopt. Deze denkwijzen vallen in aanleg buiten het bestek van dit boek; in paragraaf 2.2, ‘BPR’, komen ze echter zijdelings aan de orde.

04_lewis_sdu

01-03-2006

10

11:51

Pagina 10


Elk van de denkwijzen geeft aanleiding tot het beschrijven van de werkelijkheid op grond van een model. Een model is een vereenvoudigde afbeelding van de werkelijkheid, met als doel deze begrijpelijker te maken. Zo ontstaan gegevensmodellen, procesmodellen, gedragsmodellen, organisatiemodellen, enzovoort. Voor het opstellen van deze verschillende modellen zijn verschillende werkwijzen nodig (het maken van een procesmodel verloopt anders dan het maken van een gegevensmodel), alsook verschillende technieken (een besturingsmodel is iets anders dan een gegevensmodel). Deze komen in het volgende hoofdstuk aan bod.

Samenvatting informatiesysteemontwikkeling

In dit hoofdstuk zijn enkele begrippen neergezet die in het kader van dit boek belangrijk zijn. Wat is een informatiesysteem en wat is informatiesysteemontwikkeling? Welke eisen moet men stellen aan een methode voor systeemontwikkeling en welke fasen kan men onderscheiden in het proces van systeemontwikkeling? Vervolgens is ingegaan op de vraag wie wat doet tijdens het traject. Is er sprake van projectorganisatie of ligt de taak bij de staande organisatie?

systems life cycle

Het begrip ‘systems life cycle’ is behandeld, alsook de verschillende manieren om deze levenscylcus te benoemen. Hierbij is opgemerkt dat veel methoden de technische constructie (analyse, ontwerp, bouw, enzovoort) uitvoerig behandelen, maar de qua kosten en welslagen veel belangrijker fasen van invoering en exploitatie (onderhoud en beheer) nogal verwaarlozen. Tot slot zijn de begrippen denkwijze, werkwijze en notatiewijze en hun onderlinge samenhang behandeld.

04_lewis_sdu

01-03-2006

11:51

Pagina 11

11

2

Denkwijzen

Uit de definitie van een informatiesysteem (paragraaf 1.1) is af te leiden dat een informatiesysteem uit drie componenten bestaat: gegevens, processen en besturing. Gerelateerd aan deze drie bouwstenen van een informatiesysteem, bestaan er ook minimaal drie benaderingswijzen. De verschillende modellen die deze benaderingswijzen met zich meebrengen, worden in dit hoofdstuk behandeld. Zoals in paragraaf 1.3 al is aangegeven, zijn er meer dan drie benaderingswijzen, al geven deze niet allemaal direct de realisatie van een informatiesysteem weer. Alle benaderingswijzen kunnen worden samengebracht in het model van de zevenkleurige bril.

2.1 De zevenkleurige bril De kleuren van de zevenkleurige bril zijn al volgt te benoemen: – organisatiebenadering – communicatiebenadering – doel-functiebenadering – procesbenadering – gegevensbenadering – gedragsbenadering – veranderingsbenadering. We behandelen deze ‘kleuren’ hier stuk voor stuk inhoudelijk. Organisatiebenadering structuur

Bij de organisatiebenadering wordt de structuur beschreven, ontworpen of gewijzigd. Denk hierbij aan de opdeling in organisatorische eenheden (afdelingen, business units), taken en verantwoordelijkheden, de verdeling daarvan over functionarissen en werkplekken, enzovoort. De structuur van de organisatie is van invloed op de informatievoorziening (bijvoorbeeld bepaalde overzichten per afdeling), terwijl informatiesystemen

04_lewis_sdu

01-03-2006

12

11:51

Pagina 12


de organisatie beïnvloeden (denk maar aan de wijze van besluitvorming, mogelijke sociale gevolgen en het werkklimaat). Deze benadering geeft een goed inzicht in de verhouding organisatie-mens-informatie en is uiterst geschikt voor een rol-functiecultuur waarin informatie een stuurmiddel is (rationeel, logisch, economisch, bureaucratisch). De benadering verdient de voorkeur als wordt nagegaan of en zo ja waar nieuwe informatie- en communicatietechnologie nieuwe mogelijkheden biedt voor de wijze van structurering (bijvoorbeeld het gebruik van een managementinformatiesysteem bij de opdeling in product-marktgroepen). Deze in bedrijfs- en organisatiekunde veel toegepaste benaderingswijze is nog onderbelicht in de verschillende methoden en technieken voor systeemontwikkeling. Communicatiebenadering In de communicatiebenadering wordt bekeken welke werkplekken communiceren over welke soort informatie en met welke middelen. Daar waar informatie, mens en besluitvorming centraal staan (informatie is communiceren), is deze zienswijze uitermate belangrijk. Denk bijvoorbeeld aan kantoorautomatisering (waaronder electronic mail) en elektronische gegevensuitwisseling tussen organisaties (EDI, ofwel electronic data interchange; zie hierna). Merkwaardig is dat de communicatiebenadering juist bij diegenen vreemd overkomt die veel en professioneel met informatiesystemen werken. Wellicht is dit te verklaren doordat informatici vaak ‘opgevoed’ zijn met het denken in termen van overzichten en gegevensverwerkende processen. Ook deze benadering komt (nog?) niet voor in methoden en technieken voor systeemontwikkeling. Doel-functiebenadering

realiseren van doelstellingen

In de doel-functiebenadering worden de doelstellingen van de organisatie vertaald in hoe informatievoorziening en -systemen een bijdrage kunnen leveren aan het realiseren van de doelstellingen. Daarbij wordt veelal een scheiding aangebracht tussen uitvoerende, ondersteunende en verzorgende functies, strategische, tactische en operationele beleidsfuncties en diverse ondernemingsfuncties, zoals inkoop, verkoop, productie en personeelszaken. Het grote nut van deze benadering is een zekere robuustheid van systemen ten opzicht van organisatieveranderingen. Omdat de kern gevormd

04_lewis_sdu

01-03-2006

11:51

Pagina 13

Denkwijzen

13

wordt door de doelstellingen en de functie, is men niet zozeer afhankelijk van de ‘toevallige’ structurering van afdelingen en werkplekken. Procesbenadering volgorde bedrijfsprocessen

Bij de procesbenadering wordt bekeken in welke logische en/of volgtijdelijke volgorde bedrijfsprocessen plaatsvinden en wat de bijdrage daarvan is aan het product of de dienst. Vervolgens wordt nagegaan welke gegevens en gegevensverwerkende processen daarbij nodig zijn. Dit levert inzicht op in de totale keten van processen en de rol van informatie daarbij, wat vooral van belang is als er één informatiesysteem moet worden ontwikkeld voor processen die uit een groot aantal stappen bestaan en door meerdere afdelingen lopen, zoals goederenprocessen (grondstof- en receptuursystemen) en arbeidsintensieve processen (logistieke systemen). Gegevensbenadering

analyse en structuur

In de gegevensbenadering wordt bekeken welke gegevens van belang zijn (analyse) en hoe die gegevens tot elkaar in relatie staan (structuur). Ordenen, begrippen definiëren (omvang en inhoud) en identificeren zijn hierbij sleutelwoorden. Deze benadering wordt veel toegepast bij gegevensintensieve processen bij banken en verzekeringsmaatschappijen (verzekerden-, polis-, schade-administratie). Als bijzondere toevoeging bij deze gegevensgerichte benadering zullen we ook de meer taalkundige aanpak van Nijssen behandelen. Gedragsbenadering Een gedragsbenadering ligt voor de hand bij bijvoorbeeld robotisering van een productielijn van een automobielfabrikant of een reservering van een vliegtuigticket. Kenmerkend is dat de reactie van het systeem op een gebeurtenis uit de omgeving essentieel is voor het systeem qua snelheid en behandeling. Veranderingsbenadering

wijze van veranderen

De veranderingsbenadering wijkt af van alle voorgaande benaderingswijzen, die inhoudelijk van aard zijn, omdat deze zich uitsluitend bezighoudt met de wijze van veranderen: – Moeten we het probleem of de wens totaal of in delen realiseren? – Is de huidige (deductie) of de toekomstige (inductie) situatie leidend? – Wordt de werkelijkheid gemodelleerd of wordt er al lerende veranderd? – Heeft het systeem een lange of korte levensduur?

04_lewis_sdu

14

01-03-2006

11:51

Pagina 14


– Ontwikkelen we top-down (zoals bij SDM) of bottom-up (RAD, zie paragraaf 3.7) Wie de juiste combinatie van de zeven kleuren projecteert op een punt (probleem of wens), ziet het (witte) licht. Hoewel het tijdstip waarop en de nadruk waarmee kunnen verschillen, zal een juist samenspel van de kleuren het beste resultaat geven. Als we informatiesysteemontwikkeling in beperkte zin opvatten (het realiseren van een geautomatiseerd informatiesysteem, het onderwerp van dit boek), blijven drie relevante benaderingswijzen over (zie de definitie van informatiesysteem) te weten: de procesgerichte, de gegevensgerichte en de gedragsgerichte benadering. Bij het ontwerpen van ieder geautomatiseerd informatiesysteem dient een mix van deze drie benaderingswijzen te worden toegepast, waarbij één benaderingswijze meestal dominant is. Het resultaat van deze aanpak is een model(ontwerp) waarin alle aspecten zijn beschreven. Een wat vreemde eend in de bijt, in de zin dat zowel processen als gegevens en gedrag erin verenigd zijn, is objectoriëntatie. Hieraan besteden we een aparte paragraaf (2.7).

2.2 BPR Business proces redesign/re-engineering (BPR) heeft zich de afgelopen jaren, ondanks kritiek, een vaste plaats verworven bij de aanpak van informatieproblemen, niet in de laatste plaats omdat ook veel informatici zich in de BPR-aanpak hebben verdiept. De belangstelling van de kant van informatici laat zich mede verklaren uit de hiervoor gemaakte opmerking dat het alleen maar kijken naar geautomatiseerde informatiesystemen als oplossing meer weg heeft van ‘oogkleppen’ dan van een ‘zevenkleurige bril’. Een belangrijk herkenningspunt is dat informatie- en communicatietechnologie (ICT) slechts één strategie is om iets te verbeteren aan het functioneren van organisaties. Het vertrekpunt bij het realiseren van ICT-toepassingen is eigenlijk dat het bestaande bedrijfsproces voldoet. Het is echter de vraag of dat (nog) zo is, gelet op de ontwikkelingen in de markt en de technologie van productieprocessen zelf. BPR is een aanpak waarbij eerst (fundamenteel) vanuit de markt en de producten gekeken wordt naar het productieproces zelf (het voortbrengingsproces) en pas daarna naar de wijze van informatievoorziening en/of

04_lewis_sdu

01-03-2006

11:51

Pagina 15

Denkwijzen

15

toepassing van ICT. Dit houdt in dat bij BPR-trajecten alle zeven kleuren van de bril aan bod komen. zes stappen

Een typisch BPR-project verloopt in de volgende stappen: – vaststellen missie van de organisatie (waartoe zijn wij, als organisatie, op aarde?) – bepalen doelstellingen, wat willen we bereiken? – vaststellen strategie om die doelen te realiseren – welke producten/diensten willen we dus leveren? – hoe willen we die producten/diensten maken, hoe ziet het productieproces eruit? – welke stappen (activiteiten) voegen echt waarde toe en welke zijn alleen maar ‘bureaucratisch’? Als al deze stappen zijn uitgevoerd, heeft men goed zicht op de manier waarop eigenlijk gewerkt zou moeten worden. Het veranderen van de huidige werkwijze naar deze nieuwe manier van werken, levert (soms) aanzienlijke verbeteringen in efficiency, effectiviteit en/of kwaliteit op. Pas daarna komen vragen als: – Hoe organiseer je het nieuwe bedrijfsproces? – Hoe moet de informatievoorziening verlopen? – Welke ICT-toepassingen horen hierbij?

2.3 Procesmodellering aanpak vanuit processen

De aanpak vanuit processen is de meest klassieke aanpak; de eerste informatiesystemen werden ontwikkeld op basis van de activiteiten die door het systeem dienden te worden overgenomen. De ontwikkelingsmethoden, zoals Yourdon en ISAC, waren sterk op deze aanpak gericht. Voorbeeld: binnen een bedrijf, bijvoorbeeld een autodealer, is een proces benoemd genaamd ‘verkopen van auto aan klant in showroom’. Dit proces heeft als beoogd resultaat (ook wel product genoemd) een verkochte auto. In het proces zijn verschillende onderdelen te herkennen, zoals ontvangst, voorstellen, vragen waarvoor de klant komt, rondleiden, een kop koffie aanbieden, aanbieden plaats te nemen in het kantoor, koffie inschenken, doornemen van prijzen, opties en financieringsmogelijkheden, het maken van een proefrit en het tekenen van een voorlopig koopcontract. Elk van deze onderdelen kunnen we weer verder opsplitsen, en nog verder, enzovoort. Wanneer moeten we ophouden? Zijn die onderdelen ook weer processen?

04_lewis_sdu

01-03-2006

16

11:51

Pagina 16


–––

|

Een proces is een samenstel van activiteiten (handelingen) dat erop gericht is één van tevoren benoemd product of één van tevoren benoemde dienst tot stand te brengen.

–––

|

In de praktijk zijn voor de verschillende begrippen veel verschillende woorden in omloop, zoals proces, deelproces, activiteit, taak, handeling. Als denkwijze hebben deze terminologieën gemeen dat een proces is op te delen in deelprocessen en dat deelprocessen weer zijn op te delen in kleinere eenheden. We hanteren als laagste zinvolle detailniveau de activiteit.

–––

|

Een activiteit is een samenstel van handelingen dat altijd in dezelfde samenhang en hetzelfde tijdsbeslag wordt uitgevoerd en een herkenbaar resultaat heeft.

–––

|

Functionele ontwerpen in het kader van systeemontwikkeling hebben als procesmodel in het algemeen geen lager detailniveau nodig, omdat we dan belanden op het niveau van de afzonderlijke programmaregels die bij realisering worden geschreven. Een activiteit is dus: koffie inschenken. Andere voorbeelden kunnen zijn: opmaken voorlopig koopcontract, maken proefrit. Procesmodellering streeft er dus naar de gang van zaken in de werkelijkheid zodanig te analyseren dat het verloop van de processen in beeld komt, en wel zodanig dat de verschillende processtappen en hun resultaten zichtbaar worden. Dit inzicht is nodig om later te kunnen controleren of de programma’s wel opleveren wat gewenst is. Aanpak procesmodelleren input ➛ proces ➛ output

Bij het maken van procesmodellen zijn drie aanpakken mogelijk, uitgaande van het algemene model: INPUT ➛ PROCES ➛ OUTPUT. Met andere woorden: een proces is altijd een transformatie van input naar output; zijn input en output aan elkaar gelijk, dan is er geen proces. Men kan deze ‘vergelijking met drie onbekenden’ altijd als volgt ‘oplossen’: – Als output en input bekend zijn, dan is het proces te herleiden uit het verschil tussen deze twee.

04_lewis_sdu

01-03-2006

11:51

Pagina 17

Denkwijzen

17

– Als de input bekend is, kun je vragen ‘wat doe ik ermee’ en vervolgens aan de hand van de output nagaan of dat ‘doen’ correct is beschreven. – Als de output bekend is, kun je vragen ‘hoe kom ik eraan’ en vervolgens aan de hand van de input nagaan of de beschrijving correct is. In de praktijk blijkt het vaak moeilijk om achter processen te komen, omdat op de vraag ‘wat doe ik’ meestal een antwoord komt dat naar een functie of een rol wijst (politie-agent, verpleger, huisvrouw, boekhouder, kok, enzovoort) en niet een beschrijving van het werk zelf is. Procesmodellen Een procesmodel is een gestructureerde beschrijving van het verloop van een of meer processen. Zo’n model kan de vorm hebben van een reeks zinnen of formules of een schematische weergave. Deze schematische weergave bestaat meestal uit bolletjes of hokjes die processen voorstellen en lijntjes die de bolletjes of hokjes in de goede volgorde met elkaar verbinden. Belangrijk in een procesmodel is dat de weergave van een proces of een activiteit een werkwoord bevat: er moet iets gebeuren of worden gedaan. Voorbeeld: het leveringsproces van een bedrijf verloopt als volgt: de klant bestelt een artikel, het artikel wordt aan de klant geleverd, de klant krijgt een rekening (factuur) voor het geleverde artikel en de klant betaalt de factuur. Merk op dat in deze beschrijving ontbreken: het hoe, het wanneer en het wie. Hierdoor is het model geldig voor de levering van een auto, maar ook voor het kopen van een zakje patat. Het ontbreken van dergelijke aanvullende informatie is heel kenmerkend van een procesmodel. Aanvullende informatie komt uit andere modellen, zoals het gegevensmodel, het gedragsmodel en het organisatiemodel. Het procesmodel zou kunnen luiden:

–––

|

BESTELLEN: LEVEREN: FACTUREREN: BETALEN:

–––

|

KLANT bestelt ARTIKEL KLANT ontvangt ARTIKEL KLANT ontvangt FACTUUR KLANT betaalt FACTUUR

Tabel 2.1 Voorbeeld procesmodel

04_lewis_sdu

01-03-2006

18

11:51

Pagina 18


In de loop van de tijd is gebleken dat de aanpak van procesmodellering het risico in zich draagt dat binnen één organisatie verschillende definities voor dezelfde gegevens ontstaan; elke definitie vanuit de specifieke invalshoek van het betreffende proces. Overigens doet dit risico zich ook voor bij de bottom-up-werkwijze (inhoudelijk dezelfde processen worden anders genoemd en het kan lang duren voor iemand dit opmerkt).

2.4 Gegevensmodellering Als antwoord op de moeilijkheden van procesmodellering is de gegevensgerichte benadering naar voren gekomen, met als uitgangspunt dat hoewel de processen verschillende aspecten van hetzelfde ‘ding’ nodig hebben, het ‘ding’ zelf uiteraard hetzelfde ding blijft. Systeemontwikkeling op basis van gegevensmodellering gaat uit van gegevens als de meest stabiele elementen van een proces. De werkwijze (het proces) kan veranderen, maar de voor het proces relevante gegevens blijven (nagenoeg) dezelfde. Aanpak gegevensmodelleren Bij de gegevensgerichte benadering van systeemontwikkeling is er sprake van het opstellen van drie samenhangende modellen: – informatiemodellering – gegevensmodellering – datamodellering. drielagenmodel

Deze drie modellen komen overeen met het drielagenmodel dat door de ANSI/SPARC-databasewerkgroep is geformuleerd en dat als algemeen geldig model wordt beschouwd. Alvorens hierop in te gaan zal eerst de achtergrond van dit drielagenmodel worden geschetst.

ISO

De International Standards Organization (ISO) hanteert voor het benoemen van informatie en gegevens drie niveaus (zie tabel 2.2):

–––

|

ISO knowledge information data

–––

|

Nederlands informatie gegevens data

Beter is kennis informatie gegevens

Tabel 2.2 Begrippen ISO-Nederlands-Beter Nederlands

04_lewis_sdu

01-03-2006

11:51

Pagina 19

Denkwijzen

19

Voor de duidelijkheid zullen we de drie lagen (niveaus) hier nader definiëren.

–––

|

Knowledge/informatie/kennis is een voorstelling van (een deel van) de werkelijkheid die voor de ontvanger ervan zinvol is, dat wil zeggen iets toevoegt aan diens beeld van de werkelijkheid, respectievelijk bijdraagt aan diens begrip (pragmatisch aspect).

–––

|

Let op: informatie wordt hier als subjectief begrip gedefinieerd: de ontvanger of gebruiker van de ontvangen voorstelling bepaalt of deze informatie levert. De mededeling dat het in Hong Kong regent, voegt bijvoorbeeld weinig informatie toe voor iemand die naar Londen wil.

–––

|

Information/gegevens bestaan uit waarnemingen die in een zodanige context zijn geplaatst dat ze interpreteerbaar zijn (semantisch aspect).

–––

|

Een kenmerkende eigenschap van deze laag is dat men aangeeft in welke eenheid zaken worden gemeten: ‘67 mm regen in een dag’ is begrijpelijk, en voor iemand die er verstand van heeft betekent het zelfs meer: die kan zeggen of het veel of weinig is.

–––

|

Data zijn gestructureerde indrukken/waarnemingen die tot stand komen door rechtstreekse, sensorische waarneming van impulsen uit de wereld (syntactisch aspect).

–––

|

De kale mededeling ‘67 mm regen’ levert weinig direct betekenisvolle informatie. Gegevensmodellen Gegevensmodellen zien er vaak net zo uit als procesmodellen: het kunnen reeksen van zinnen of formules zijn, of schema’s met bolletjes, hokjes en lijntjes. Maar nu betekenen ze iets anders: de kern van een gegevensmodel bestaat niet uit een werkwoord, maar uit een zelfstandig naamwoord. Iets wat er is en wat wordt aangeduid met een zelfstandig

04_lewis_sdu

01-03-2006

11:51

Pagina 20

20


entiteit

naamwoord, noemt men een entiteit. Een entiteit is meestal een weergave van een ding (object) in de werkelijkheid. Objecten en entiteiten behoren altijd tot groepen of categorieën van gelijksoortige dingen. Deze groepen noemt men typen; men spreekt van objecttypen (in de werkelijkheid) en entiteittypen (in het gegevensmodel). Entiteittypen zijn bijvoorbeeld klant en artikel.

attribuuttypen

relationship-type

Objecten hebben eigenschappen waaraan ze binnen het type kunnen worden herkend of beschreven. Voorbeelden hiervan zijn klantnummer, artikelnummer, klantnaam, klantadres en artikelprijs. Ook entiteiten hebben eigenschappen, die attributen worden genoemd. Attributen zijn weer onder te brengen in groepen: attribuuttypen. Tussen de objecten in de werkelijkheid bestaan relaties: ik ben eigenaar van een fiets. Evenzo bestaan er relaties tussen entiteiten, die men relationships noemt: artikelen worden door klanten besteld, artikelen worden aan klanten geleverd, artikelen worden aan klanten in rekening gebracht, enzovoort. Relaties behoren ook weer tot typen, zoals bestelling, levering en factuur. Zo’n relatietype noemt men een relationship-type. Tussen entiteittypen kunnen dus meerdere relationship-typen staan: bestelling, levering, factuur en betaling zijn allemaal (onder meer) relaties tussen klant en artikel. Deze relationship-typen komen vaak weer voor als proces in het procesmodel (bestellen, leveren, factureren, betalen). Als aan het relatietype eigenschappen zijn te koppelen die specifiek zijn voor de relatie, dan vormen deze relaties een nieuw entiteittype: het associatieve entiteittype. Een gegevensmodel zou er zo uit kunnen zien:

–––

|

entiteittypen en attribuuttypen: KLANT: klantnummer, klantnaam, klantadres, klantwoonplaats ARTIKEL: artikelnummer, artikelomschrijving, artikelprijs BESTELLING: bestelnummer, klantnummer, artikelnummer, aantal, datum bestelling LEVERING: leveringnummer, klantnummer, artikelnummer, aantal, datum levering FACTUUR: factuurnummer, klantnummer, artikelnummer, factuurbedrag, datum factuur BETALING: betalingnummer, klantnummer, artikelnummer, betaalbedrag, datum betaling

04_lewis_sdu

01-03-2006

11:51

Pagina 21

Denkwijzen

21

relatietypen: KLANT bestelt ARTIKEL via BESTELLING KLANT ontvangt ARTIKEL via LEVERING KLANT ontvangt voor ARTIKEL FACTUUR KLANT betaalt ARTIKEL via BETALING

–––

|

Tabel 2.3 Voorbeeld gegevensmodel

In het voorbeeld is voor de overzichtelijkheid afgezien van allerlei zaken die in de dagelijkse praktijk zullen worden gedaan. Zo zullen we er met name voor zorgen dat we het verband tussen bestelling, levering, factuur en betaling expliciet vasthouden. Maar dat doen we voor óns gemak; strikt genomen is het niet nodig en zelfs overtollig (redundant). In het gegevensmodel wordt dit bijvoorbeeld vertaald door het opnemen van een verwijzing naar de bestelling in levering: als attribuuttype wordt het bestelnummer toegevoegd aan levering:

–––

|

LEVERING: leveringnummer, klantnummer, artikelnummer, aantal, datum levering, bestelnummer

–––

|

Uit het voorbeeld blijkt dat bestelling, levering, facturering en betaling eigenlijk opvolgende stadia (toestanden) zijn in de relatie tussen klant en product(leverancier). We komen hier bij de gedragsbenadering op terug. Het model dat we tot nu toe hebben besproken, is een logisch of conceptueel gegevensmodel. Dit model beschrijft de typen (categorieën) objecten waarvan we iets willen vastleggen. attribuutwaarden

domein

In het systeem worden vervolgens van ieder exemplaar (occurrence of instance) de feitelijke attribuutwaarden vastgelegd. Er is dus een klant met de naam ‘Janssen’, een artikel met de naam ‘moertje 7 mm’, enzovoort. Klant Janssen heeft klantnummer 1001 en artikel moertje 7 mm heeft artikelnummer 10100207. De attribuutwaarden moeten voldoen aan bepaalde voorschriften, zoals beschreven bij het attribuuttype. Deze voorschriften beschrijven het domein waarbinnen de attribuutwaarden moeten liggen. Bijvoorbeeld: een klantnummer kan alleen de waarden tussen 1001 en 1999 hebben. Door het gebruik van codes (klantnummer, artikelnummer, enzovoort) kunnen gegevens worden vastgelegd, opgevraagd, gecombineerd, enzovoort.

04_lewis_sdu

22

01-03-2006

11:51

Pagina 22


2.5 Boodschap, inhoud en betekenis In het dagelijks verkeer tussen mensen, zowel in het kader van hun professionele bezigheden (werk) als privé, wordt informatie uitgewisseld. Dit proces van informatie-uitwisseling wordt communicatie genoemd en voltrekt zich op een aantal verschillende niveaus. We zullen niet proberen het uitgebreide vakgebied van de communicatiewetenschappen hier ‘even’ samen te vatten; we noemen slechts een aantal aspecten.

–––

|

Een boodschap is een afgeronde, samenhangende set data die door een zender wordt verzonden naar een ontvanger.

––– |––– |

De inhoud is de verzameling data met de bijbehorende context.

––– |––– |

De betekenis is de interpretatie van de ontvanger van de inhoud van de boodschap.

–––

|

Hoewel de begrippen verschillend zijn benoemd en gedefinieerd, is de overeenkomst met de beide kolommen in tabel 2.2 duidelijk: – betekenis heeft te maken met knowledge/informatie/kennis – inhoud heeft te maken met gegevens/informatie – boodschap heeft te maken met data/gegevens. Bij communicatie tussen mensen, een proces dat ook wel wordt aangeduid als informatie-uitwisseling, gaat het dus om de betekenis van de uitgewisselde boodschappen. In het zakelijk verkeer en ook bij zakelijke communicatie tussen mensen privé is de inhoud van de boodschap van belang: wat wordt gecommuniceerd. De betekenis is min of meer een direct, logisch gevolg van de inhoud van de boodschap. Dit komt omdat de betrokkenen bezig zijn met het uitvoeren van een gezamenlijk afgesproken taak of activiteit. In dit geval kan voor de uitvoering van de gegevensgerichte wijze van systeemontwikkeling worden uitgegaan van de informatiebehoefte van de gebruikers, beschreven in termen van inhoud van de boodschap.

04_lewis_sdu

01-03-2006

11:51

Pagina 23

Denkwijzen

23

Geheel anders ligt het bij communicatie waarbij de uitwisseling van boodschappen gericht is op andere doelen, zoals het uitdrukking geven aan gevoelens van vriendelijkheid of vijandigheid. In dergelijke gevallen worden boodschappen verzonden waarbij de inhoud niet of alleen indirect te maken heeft met de betekenis. Voorbeelden hiervan zijn de sociale gesprekjes over het weer en dergelijke of het gebruik van scheldwoorden.

–––

|

Stelling: gegevensgerichte ontwikkeling van (bestuurlijke) informatiesystemen is alleen mogelijk indien boodschap, inhoud en betekenis op een eenduidige manier aan elkaar zijn gerelateerd (informatieparadigma).

–––

|

Als aan deze voorwaarde is voldaan, bestaat het proces van gegevensgerichte systeemontwikkeling uit het invullen van de drie lagen van het ANSI/SPARC-drielagenmodel. Op basis van het soort overwegingen dat hiervoor is beschreven, is door een aantal mensen een methodische aanpak van de gegevensgerichte benaderingswijze ontwikkeld, die zich baseert op taal. NIAM is een voorbeeld van deze werkwijze.

propositie

predikaat

In heel veel gegevensgerichte methoden duiken entiteiten en attributen op als factuur, factuurregel, artikel en prijs. Deze typen ontstaan op basis van de hiervoor beschreven aanpak (objecten en objecttypen in de werkelijkheid zijn vaak entiteiten en entiteittypen in het informatiesysteem). In de praktijk blijkt evenwel dat nogal wat entiteiten niet de weergave van objecten zijn (reservering, wedstrijd, reis, enzovoort). Hoe vind je dergelijke entiteittypen? De taalkundige aanpak gaat, grof geschetst, als volgt te werk: – Maak een gewone zin die een dagelijkse gebeurtenis beschrijft waarin je bent geïnteresseerd (zo’n zin heet propositie). – Onderzoek of meer van dergelijke zinnen over soortgelijke gebeurtenissen kunnen worden gemaakt (het heeft geen zin een eenmalige of unieke gebeurtenis te modelleren). – Bekijk wat deze zinnen gemeenschappelijk hebben qua structuur. – Herformuleer de zinnen in de vorm van een enkele algemene zin, op basis waarvan, door het vervangen van bepaalde variabelen door de feitelijke waarden van de oorspronkelijke zinnen, de oorspronkelijke zinnen weer kunnen worden gereconstrueerd (zo’n zin heet predikaat). – De variabelen uit het predikaat en andere regels uit de predikatenlogica geven de gezochte entiteittypen en de regels over hun samenhang, enzovoort.

04_lewis_sdu

01-03-2006

24

11:51

Pagina 24


Voorbeeld: uitspraak 1

6 is een samengesteld getal (want het is het product van 2 en 3) uitspraak 2 8 is een samengesteld getal (2 x 2 x 2) uitspraak 3 36 is een samengesteld getal (2 x 2 x 3 x 3) uitspraak 4 111 is een samengesteld getal (3 x 37) uitspraak 5 7 is geen samengesteld getal (1 x 7, maar de 1 telt niet mee als getal) uitspraak 6 113 is geen samengesteld getal Van ieder van deze uitspraken is na te gaan of hij waar of onwaar is. Algemeen: een (natuurlijk, geheel) getal heet samengesteld als het te schrijven is als het product van 2 of meer andere (natuurlijke, gehele) getallen (= ontbindbaar in factoren). Anders gezegd: van ieder getal ‘P’ is vast te stellen of het samengesteld ‘s’ is: s(P). Voor iedere P is na te gaan of de uitspraak s(P) waar of onwaar is. Er is dus een entiteittype P, met de eigenschap s (P’s met de eigenschap niet-s heten priemgetallen). Het ANSI/SPARC-drielagenmodel Een algemeen aanvaarde wijze van beschrijven (en dus een paradigma) voor het beschrijven van gegevens is het drielagenmodel van de ANSI/SPARC-databasewerkgroep. Deze groep ‘bedacht’ in de jaren zeventig dat gegevens op drie niveaus zijn af te beelden: conceptueel, logisch en fysiek. Sindsdien is dit concept overgenomen door de ISO en op veel gebieden in de informatica toegepast, waarbij het begrippenapparaat soms is aangepast. In tabel 2.4 zijn enkele van de gebruikte begrippen samengebracht. Het zijn niet altijd echte synoniemen, maar duiden wel begrippen aan die in grote lijnen dezelfde inhoud hebben.

–––

|

ANSI/SPARC

Alternatieve aanduidingen

Voor wie

Toont

Niveau

conceptueel extern

logisch en/of conceptueel fysiek/technisch of logisch/ organisatorisch implementatie of fysiek/ operationeel

analist gebruiker

relaties weergave

organisatie proces

technicus

structuur

realisatie

intern

–––

|

Tabel 2.4 Alternatieve aanduidingen voor het drielagenmodel

04_lewis_sdu

01-03-2006

11:51

Pagina 25

Denkwijzen

25

extern niveau

Het externe niveau komt overeen met de betekenis van de boodschap en beweegt zich dus op het niveau van knowledge/informatie: wat heeft de gebruiker nodig, wat betekent het voor hem?

conceptueel niveau

Het conceptuele niveau komt overeen met de inhoud van de boodschap: welke logische elementen (entiteiten en attributen) komen in de boodschap voor?

intern niveau

Het interne niveau ten slotte komt overeen met de samenstelling van de boodschap zelf, met de technische uitvoering van de componenten: zijn het bits of muzieknoten, hoe worden ze vastgelegd, enzovoort? Data dictionary/directory system

repository

Het data dictionary/directory system (gegevenswoordenboek, DD/DS) is de centrale kapstok waaraan alle gehanteerde begrippen, definities, enzovoort zijn opgehangen. Het DD/DS vervult de rol van controleur op consistentie van entiteittypen, attribuuttypen, relationship-types, enzovoort. Deze oorspronkelijk uit de jaren zeventig stammende term komt men nog veel tegen in mainframe-omgevingen. In de DD worden entiteiten, attributen en relaties opgenomen; in de directory vindt men gegevens als ‘waar wordt het gebruikt?’, ‘door welk programma?’ en dergelijke. In moderne systemen spreekt men vaak over repository.

DD/DS-notatie

Omdat we hierna regelmatig zullen terugvallen op de techniek van de DD/DS-notatie, introduceren we deze hier vast (tabel 2.5).

–––

|

= NETNUMMER_1 + ABONNEENUMMER_1 ∗in Nederland∗ TELEFOONNUMMER_2 = LANDCODE + NETNUMMER_2 + ABONNEENUMMER_2 ∗rest vd wereld∗ FAXNUMMER_1 = TELEFOONNUMMER_1 ∗faxen in Nederland∗ FAXNUMMER_2 = TELEFOONNUMMER_2 ∗faxen rest van de wereld∗ NETNUMMER_1 = 0 + [2|3](9) ∗conform PTT telefoongids, zie TABEL PTT_1∗ ABONNEENUMMER_1 = [6|7](9) NETNUMMER_1 + ABONNEENUMMER_1 = 10(9) LANDCODE = 2(9) ∗conform PTT telefoongids, zie TABEL PTT_2∗ NETNUMMER_2 = [2|3](9) ∗zie NETNUMMER_1, zonder de eerste 0∗ LANDCODE + NETNUMMER_2 + ABONNEENUMMER_2 = 12(9) TELEFOONNUMMER_1

–––

|

Tabel 2.5 Voorbeeld van een DD-notatie

04_lewis_sdu

01-03-2006

26

11:51

Pagina 26


Meestal staan de entries van een DD op alfabet; omwille van de duidelijkheid is dat hier niet gedaan. Deze DD begint bij begrippen die vervolgens in elementen worden opgedeeld en voorzien worden van ‘constraints’ (= beperkingen ten aanzien van mogelijke waarden). Elementen van de notatiewijze

constraints

primaire zoeksleutels

De entries van de DD staan in HOOFDLETTERS, de toelichting staat tussen ∗sterren∗ in kleine letters. Het plusteken (+) is het koppelteken, dat aangeeft dat de gekoppelde elementen tot dezelfde entry behoren. Hiervoor wordt ook wel de komma gebruikt. Voor aantallen tekens en soorten teken is de picture-notatiewijze van COBOL gevolgd. 6 (X) betekent dus een stuk tekst met een lengte van 6 alfanumerieke tekens; 5,2(9) betekent een getal van 5 posities voor de komma en twee posities erachter. Overigens zijn hier meerdere vormen voor te bedenken; dit is maar een voorbeeld. [..|..] betekent ‘of’: óf de ene waarde wordt gebruikt, óf de andere. Tevens zijn in dit voorbeeld beperkende regels (constraints) in de DD zelf opgenomen. Deze geven aan dat een netnummer en een abonneenummer samen gelijk moeten zijn aan 10 cijfers; bij een internationaal nummer is er sprake van 12 cijfers. De items voorafgegaan door het teken @ zijn primaire zoeksleutels. Ook onderstreping wordt hier veel voor gebruikt. Primaire zoeksleutels zijn uniek identificerende attribuuttypen. Entries tussen ‘()’ zijn optioneel (niet verplicht); alle andere zijn verplicht. Entries die tussen ‘{}’ staan, komen meerdere keren voor (repeating groups). De getallen ervoor en erachter geven het minimum en het maximum aan. {..}3 betekent dus minimaal niet (=0) en maximaal 3 keer; dit wil dus zeggen dat het element ook niet kan voorkomen, oftewel optioneel is.

2.6 Gedragsmodellering OLTP

Met de introductie van on line transaction processing (OLTP) bleek zowel de procesmodellering als de gegevensmodellering tekort te schieten als benaderingswijze. Bij OLTP is er sprake van directe interactie tussen gebruiker en het geautomatiseerde systeem; er ontstond behoefte aan een manier om deze interactie te modelleren. Het modelleren van gedrag dient ertoe om alle mogelijke situaties (toestanden) die zich kunnen voordoen in kaart te brengen, met daarbij welke acties in een bepaalde toestand onder welke voorwaarden zijn toe-

04_lewis_sdu

01-03-2006

11:51

Pagina 27

Denkwijzen

27

gestaan en wat de toegestane uitkomsten van de verschillende acties kunnen zijn. Aanpak gedragsmodellering Gedragsmodellering kan in essentie op twee manieren worden aangepakt: – de keten aflopen, van begintoestand via toestandsovergang naar eindtoestand – eerst alle toestanden inventariseren en vervolgens de overgangen beschrijven. Welke van de twee aanpakken de beste is, is afhankelijk van het probleem. In sommige gevallen is het totale aantal toestanden onkenbaar (externe, onbestuurbare omstandigheden spelen een rol), in andere gevallen mag er maar een beperkt aantal toestanden mogelijk zijn, omdat anders de gebruiker (meestal een mens, die maar een beperkt aantal opties kan overzien) in de war raakt. Een derde, veel voorkomend type is het type waarbij maar een beperkt aantal toestanden ‘legaal’ is (toegestaan); alle andere (een onbekend aantal) toestanden zijn niet toegestaan en voor niet-toegestane toestanden is maar één actie mogelijk: terug naar ‘af’ of iets dergelijks. Gedragsmodellen

toestand

Het wordt misschien wat saai, maar ook een gedragsmodel is ofwel een verzameling zinnen (die heel vaak beginnen met ALS of DAN) of formules, ofwel een schema met hokjes, bolletjes en lijntjes. Maar nu betekenen de hokjes: een toestand, en de lijntjes: een toestandsovergang. Een bijzondere weergave van een gedragsmodel is een beslissingstabel. De meest voorkomende toestand bij gedragsmodellen is ‘wachten’: wachten op een aanleiding om iets te gaan doen.

voorwaarden

Aan het tot stand komen van de nieuwe toestand is een aantal voorwaarden gekoppeld: – voorwaarden vooraf, zoals: is het artikel in voorraad en is de klant kredietwaardig? – voorwaarden achteraf, zoals: is de levering daadwerkelijk verzonden? Een beschrijving van een gedragsmodel zou kunnen luiden:

04_lewis_sdu

01-03-2006

28

11:51

Pagina 28


–––

|

TOESTAND 1: TRIGGER: POSTCONDITIE: PRECONDITIES: TOESTANDSOVERGANG (proces 1): TOESTAND 2:

–––

|

Het bedrijf wacht op bestellingen Een klant bestelt een artikel Het artikel is aan de klant gestuurd (gewenst resultaat) Klant moet OK zijn, artikel moet er zijn, voorraad moet voldoende zijn ALS klant = OK EN artikel bestaat EN voorraad = akkoord DAN lever artikel aan klant Wachten op bevestiging aflevering (artikel is gestuurd)

Tabel 2.6 Voorbeeld gedragsmodel

precondities postcondities

De voorwaarden vooraf (precondities) spelen een rol bij het al dan niet in gang zetten van het proces. De voorwaarden achteraf (postcondities) bepalen of de volgende toestand daadwerkelijk wordt bereikt of dat het proces opnieuw moet worden uitgevoerd. Het voorgaande voorbeeld (tabel 2.6) ging over toestanden waarin een systeem (in dit geval een verkoopafdeling) zich kan bevinden.

dialoogmodel

Er is een nog een tweede vorm van gedragsmodel, waarin specifiek de interactie tussen mens en machine (informatiesysteem) wordt beschreven. Dit gedragsmodel noemt men vaak dialoogmodel. Bij het opstellen van een dialoogmodel luidt de centrale vraag: wie neemt op welk moment welk initiatief? Hierbij is het van belang dat de mens, de gebruiker, altijd de mogelijkheid heeft om de besturing over te nemen en daarmee het gedrag van het systeem onder controle te houden. In het gedragsmodel dient met name te worden vastgelegd wanneer (zowel in de tijd als onder welke voorwaarden) het systeem iets doet en wanneer de mens iets doet. Bij een dergelijke interactie zijn de volgende aspecten te onderscheiden: – Hoe geeft de mens aan het systeem te kennen dat er iets moet worden gedaan? – Hoe laat het systeem merken dat het de opdracht heeft ‘begrepen’ en tot uitvoering is overgegaan? – Hoe weet de gebruiker hoe het met de uitvoering staat? – Hoe meldt het systeem de afloop van de uitvoering? – Hoe meldt het systeem dat het gereed is om een nieuwe opdracht te ontvangen?

04_lewis_sdu

01-03-2006

11:51

Pagina 29

Denkwijzen

29

Dit rijtje beschrijft alleen het verloop van de gebeurtenissen als het allemaal goed gaat. Bij ieder van de stappen kan er echter ook iets mis gaan, en hoe wordt dat afgehandeld? Een bekend voorbeeld van zo’n situatie is de DOS-melding (op een PC) ‘wrong command or filename’. Wat is er nu fout: het commando of de bestandsnaam? En wat moet ik nu doen? Een goed dialoogontwerp dient op al deze vragen antwoord te geven. Daarnaast dient het ontwerp situaties uit te sluiten waarin de toestand ‘onbekend’ of onvoorspelbaar is. Bij dat soort situaties horen namelijk meestal zeer ingrijpende acties, zoals Alt-Ctrl-Delete op een PC. Dergelijke ingrepen kunnen rampen aanrichten in het systeem (onjuist of nietafgesloten databases en indexen) en zijn dus zeer ongewenst. Wat er ook gebeurt, er dient altijd een van tevoren beschreven toestand te ontstaan, waarbij voor de gebruiker ten minste één (van tevoren beschreven) zinvolle actie beschikbaar is om op ordelijke wijze het werk voort te zetten. Meer algemeen: in een gedragsmodel mogen geen ‘doodlopende straten’ zitten, anders ‘crasht’ het systeem.

2.7 Objectoriëntatie Alle drie genoemde denkwijzen (proces-, gegevens- en gedragsbenadering) worden min of meer verenigd in de meest recente aanpak: objectoriëntatie (OO). Bij OO wordt uitgegaan van de gegevens als ‘kern’, waaraan de verschillende ‘verschijningsvormen’ van het gegeven, afhankelijk van het gebruik (proces), worden gekoppeld. De processen worden gestart op basis van boodschappen van andere objecten (gedrag). Aldus ontstaat een ‘object’, waarin gegevens en programmatuur, die voor de verschijningsvormen zorgen, zijn samengevoegd. Overigens is er volop discussie over de vraag of OO een denkwijze, een werkwijze of alleen maar een notatiewijze is. We willen niet in deze discussie treden; zeker is dat OO een andere perceptie van de werkelijkheid (en dus een denkwijze) is, die ook invloed heeft op de werkwijze en de te hanteren techniek. De volgende begrippen spelen bij OO een rol: – object – objectidentificatie – variabele – domein – methode – klasse – overerving

04_lewis_sdu

01-03-2006

30

11:51

Pagina 30


– inkapseling – boodschap – hergebruik. Het centrale begrip bij objectoriëntatie is dus object.

–––

|

Een object is een ‘ding’, waarin de volgende onderdelen zijn opgenomen: objectidentificatie, variabelen en methoden.

–––

|

Een object is meer dan een entiteit, zoals besproken bij gegevensmodellering; het bevat namelijk niet alleen attributen (die hier variabelen heten), maar ook alle bewerkingen die op die variabelen mogen worden uitgevoerd, dus de programma’s (die hier methoden worden genoemd). objectidentificatie

overerving

De objectidentificatie is een unieke en nooit veranderende aanduiding van het object, waarmee het object moet worden ‘aangesproken’. Dit is een andere identificatie dan het klant- of artikelnummer, zoals we bij gegevensmodellering tegenkwamen. Dergelijke codes zijn hier gewoon variabelen. De variabelen van het object behoren tot domeinen, net zoals de attribuutwaarden bij gegevensmodellering. En nu komt het: objecten, domeinen van variabelen en methoden behoren tot klassen, die op hun beurt ook weer objecten zijn! In tabel 2.7 zien we het object Janssen, J., dat onderdeel uitmaakt van de (sub)klasse Klanten, die weer onderdeel uitmaakt van de (super)klasse Personen. De verzameling variabelen en methoden die bij Personen hoort, hoort automatisch ook bij alle subklassen en objecten die daaronder vallen! Dit verschijnsel noemt men overerving (inheritance). Dus: dat klanten een adres en woonplaats hebben, dat ze toegevoegd, gewijzigd, enzovoort kunnen worden, hoeft niet meer bij Klanten te worden vastgelegd. Dit is automatisch geregeld op het moment dat we Klanten benoemen als subklasse van Personen. Op dezelfde wijze is een belangrijk deel van alle variabelen en methoden van Janssen, J. vastgesteld toen we dit object als object binnen de (sub)klasse Klanten benoemden. Alleen zijn bij Janssen, J. de feitelijke waarden opgenomen.

04_lewis_sdu

01-03-2006

11:51

Pagina 31

Denkwijzen

31

–––

|

Object: Objectidentificatie: Adres: Woonplaats: Telefoonnummer: Klantnummer: Bestellingnummer: Factuurnummer: enzovoort Methoden:

Janssen Janssen, J. Boterdiep 18 Vlagtwedde 093-1234567 109001 2348, 3517, 4809 950023, 950128, 95453

(Sub)klasse: Objectidentificatie: Variabelen: Methoden:

Klanten klantnaam klantnummer, zie Personen bestelling plaatsen, factuur betalen, zoeken op klantnaam, zie Personen

(Super)klasse: Objectidentificatie: Variabelen: Methoden:

Personen klantnaam, leveranciernaam, relatienaam adres, woonplaats, telefoonnummer toevoegen, verwijderen, raadplegen, wijzigen, afdrukken

–––

|

zie Klanten

Tabel 2.7 Voorbeeld OO-structuur

inkapseling

De enige manier om een object te benaderen is door het object een boodschap (message) te sturen, waardoor het object wordt geactiveerd. Afhankelijk van de boodschap wordt een methode geactiveerd die tot het object behoort. Hoe het verder gaat, is voor de zender van de boodschap niet van belang, zelfs niet te achterhalen. Dit verschijnsel noemt men inkapseling (encapsulation). Overigens was dit fenomeen dertig jaar geleden ook al bekend; men noemde het toen ‘information hiding’ (Yourdon).

2.8 De invalshoek startpunt van het werk

Een tweede aspect van een denkwijze is wat we hier zullen noemen de invalshoek. Naast de benaderingswijze kan men ook het startpunt van het werk kiezen: beginnen we ‘op de werkvloer’ of juist bij de bedrijfsleiding om vast te stellen wat benodigd is. Men noemt deze startpunten of invalshoeken top-down, bottom-up en middle-out.

04_lewis_sdu

01-03-2006

32

11:51

Pagina 32


Deze startpunten zijn als volgt te karakteriseren: – van algemeen, globaal naar detail, specifiek (top-down) – van detail, specifiek naar globaal, algemeen (bottom-up) – van gemiddeld, detail naar globaal en specifiek (middle-out). Top-down integrale benadering

hoogste abstractieniveau

Deze aanpak wordt vaak gebruikt, omdat hiermee de onderlinge samenhang van de verschillende delen is gegarandeerd (integrale benadering). Een bezwaar van deze aanpak kan zijn dat op het specifieke detailniveau te veel elementen zitten die ‘hoger op’ in de aanpak zijn benoemd en te weinig uit oogpunt van het detailproces. Het belangrijkste kenmerk van iedere top-down-aanpak is dat men uitgaat van het hoogste abstractieniveau. Bij procesmodellering houdt dit in het geval van een verzekeringsmaatschappij bijvoorbeeld in: de verzekeringsmaatschappij verzekert mensen tegen schade door middel van polissen. Vervolgens breken we dit geheel op in kleinere stukken: de hoofdstappen van het proces worden benoemd. In het voorbeeld van de verzekeringsmaatschappij betekent dit dat we nu de processen ‘sluiten verzekering’ en ‘afhandelen schade’ kunnen onderscheiden. Vervolgens breken we ‘sluiten verzekering’ weer op in kleinere deelprocessen, zoals aanmelden, accepteren, opmaken polis, verzenden polis en factuur, en incasso. Zo kunnen we doorgaan met het in steeds kleinere stukjes opdelen van ieder (deel)proces. Zo blijkt ‘accepteren’ weer te bestaan uit: verifiëren gegevens aanvrager (Naam Adres Woonplaats, schadehistorie, kredietwaardigheid), beoordelen te accepteren risico, en vaststellen polisvoorwaarden. We naderen nu het punt waarvan we al eerder melding maakten: moeten we nu doorgaan met nog verder opdelen of mogen we stoppen? Hiervoor is helaas geen algemeen recept beschikbaar. We mogen stoppen zodra we alle processtappen en bijbehorende gegevens hebben beschreven die nodig zijn voor het ontwerpen van het nieuwe systeem. Bottom-up

detailniveau

Deze aanpak is het spiegelbeeld van de voorgaande aanpak. Het voordeel van de bottom-up-aanpak is dat deze op detailniveau goed aansluit bij het specifieke proces, maar omgekeerd kan daardoor de integratie en samenhang op een hoger niveau in het gedrang komen. Dus: we begin-

04_lewis_sdu

01-03-2006

11:51

Pagina 33

Denkwijzen

33

nen bij het detailniveau van bijvoorbeeld ‘vaststellen polisvoorwaarden’. Om dit te kunnen doen dienen ‘verifiëren gegevens aanvrager’ en ‘beoordelen te accepteren risico’ te zijn uitgevoerd. Deze drie processtappen vormen samen het deelproces ‘accepteren’. Dit deelproces maakt op zijn beurt weer deel uit van een groter geheel: sluiten verzekering. Zodra we op het niveau van de organisatie als geheel zijn aangeland, zijn we klaar. Er is dus geen probleem met het stoppen. Middle-out Deze aanpak kiest voor goed herkenbare, generiek te beschrijven procesdelen. Deze worden niet op detailniveau beschreven, maar ook niet op het hoogste abstractieniveau. Een voorbeeld kan zijn: afspraak maken met patiënt. Enerzijds is dit een deel van de administratieve procedure in een polikliniek, anderzijds bestaat het uit kleinere elementen als ‘bepalen dag en tijd’, ‘vastleggen afspraak’ en ‘financiële afhandeling’. valkuil

De grootste valkuil is hier dat men gauw geneigd is om op basis van gewoonte of spraakgebruik wezenlijk verschillende processen op één hoop te gooien, te behandelen als één generiek type. Voorbeeld: het aangifteproces. Iedereen komt op het politiebureau aangifte doen van allerhande gebeurtenissen, maar de aangifte van een gestolen fiets is wezenlijk anders (in het verloop) dan de aangifte van een zedenmisdrijf! Wat is de beste invalshoek? Deze vraag is niet eenvoudig te beantwoorden. Eigenlijk is er geen beste invalshoek. Het is van de situatie in de organisatie afhankelijk welke aanpak het handigste is en het beste werkt. Elk van de invalshoeken heeft zijn eigen voor- en nadelen. Over het probleem van het stoppen bij detailleren (top-down) hebben we het al gehad. Een nadeel van bottomup is: hoe integreert men de afzonderlijke deelontwikkelingen tot een samenhangend geheel? Bij middle-out bestaat het risico dat de verkeerde uitgangspunten worden gehanteerd. Een ander aspect is de vraag waarom er met de aanpak van het probleem is begonnen. Was het een wens van de directie, die het hele proces wil stroomlijnen (voorkeur top-down), was er een probleem bij een werkproces, zoals het vaststellen van polisvoorwaarden (bottom-up), of was er een probleem bij een proces (de acceptatie, voorkeur middle-out). Het voordeel van de top-down-aanpak is dat het gehele ontwerp een goede interne samenhang vertoont (de details volgen logisch uit het geheel). Het voordeel van bottom-up is dat de feitelijke werkwijze van

04_lewis_sdu

01-03-2006

34

11:51

Pagina 34


de medewerkers (de uiteindelijke gebruikers van het systeem) als uitgangspunt wordt genomen. Bij middle-out is men verzekerd van een snelle en doelgerichte aanpak, waardoor een goede aansluiting met de omgeving wordt verkregen. Ten slotte verwijzen we naar het volgende hoofdstuk over werkwijzen bij systeemontwikkeling. Gefaseerd ontwikkelen gaat veelal gepaard met top-down, prototyping werkt alleen goed met bottom-up en middle-out geeft goede aanknopingspunten voor incrementeel ontwikkelen.

Samenvatting denkwijzen

In dit hoofdstuk zijn de denkwijzen aan bod gekomen. Niet alleen de denkwijzen die om technische redenen sterk aan systeemontwikkeling zijn gekoppeld (gegevens-, proces- en gedragsgericht), maar ook de denkwijzen die meer samenhangen met de organisatie en de informatievoorziening in het geheel (organisatie-, communicatie-, doel-functie- en veranderingsgericht).

BPR

In de paragraaf over BPR zijn deze onderwerpen nogmaals zijdelings aan de orde gekomen. In het kader van de ontwikkeling van geautomatiseerde informatiesystemen worden drie belangrijke benaderings- of denkwijzen behandeld: proces-, gegevens- en gedragsgericht.

objectoriëntatie

Aparte aandacht is besteed aan objectoriëntatie, aangezien deze aanpak de eerder genoemde drie in zich verenigt of het onderscheid overbodig maakt. De belangrijkste begrippen van OO worden behandeld, zoals object, message, encapsulation en inheritance.

invalshoeken

Het hoofdstuk is afgesloten met de verschillende invalshoeken: topdown, bottom-up en centre-out. Welke van deze invalshoeken de voorkeur geniet, is sterk situationeel gebonden.

04_lewis_sdu

01-03-2006

11:51

Pagina 35

35

3

Werkwijzen

De werkwijze bij systeemontwikkeling gaat over de manier van uitvoeren van het werk. Wordt het werk in stappen of fasen gedaan? Waar ligt de grens tussen de fasen? Of gaan we volgens het prototyping-model te werk? Bouwen we snel een klein deel van het systeem, dat we vervolgens op basis van ervaringen hiermee opgedaan, verder uitbouwen? In de loop der tijd zijn er diverse werkwijzen ontwikkeld, waarvan we hier de belangrijkste behandelen: – lineair – prototyping – cyclisch (of iteratief) – incrementeel – evolutionair – RAD/MAD.

3.1 Lineair

watervalmodel of bulldozermethode

Dit is de oudste aanpak, de klassieke. Het lineaire scenario werkt stapsgewijs en in fasen van beleid via ontwerp en bouw naar implementatie, van globaal naar detail. Om deze reden wordt het ook wel eens het watervalmodel of de bulldozermethode genoemd.1 Ook is het wel vergeleken met een estafetteloop: iedere volgende stap is een logisch gevolg van de eraan voorafgaande stappen, waarbij steeds ‘dichter’ naar de machine toe wordt gewerkt. Figuur 3.1 geeft de aanpak weer. Na iedere stap is er een moment van toetsing van de vorderingen en een bijgestelde planning, op basis waarvan wordt besloten om aan de volgende stap te beginnen, het project te stoppen of in een aangepaste vorm verder te gaan. 1 Deze beide beeldspraken illustreren het voortgaande en ‘onstuitbare’ karakter van dit model: het oplossen van detailproblemen wordt vooruitgeschoven en teruggaan is moeilijk of onmogelijk.

04_lewis_sdu

01-03-2006

36

11:51

Pagina 36


Watervalmodel

Informatieplanning Definitiestudie Basisontwerp Detailontwerp Realisatie Invoering

Gebruik en beheer

Figuur 3.1 De lineaire werkwijze

Deze aanpak is uitermate geschikt voor redelijk stabiele situaties. Dit is het geval wanneer de bedrijfsprocessen niet aan sterke veranderingen onderhevig zijn en de, meestal ervaren, gebruikers goed weten welke informatiebehoeften zij hebben. Als men wel weet wat, maar nog niet zo goed hoe het systeem eruit moet gaan zien, wordt dit nogal eens gecombineerd met een vorm van prototyping. Daarbij wordt een prototype van (een deel van) het beoogde systeem ontwikkeld om het hoe te achterhalen. Als men het daarover eens is, kan het prototype, dat als ‘wegwerpsysteem’ bedoeld is om de kwaliteit van het ontwerp te verbeteren, vervangen worden door het (volledige) definitieve systeem. bezwaar

Het grootste bezwaar van deze aanpak is dat ‘fouten’ (vergissingen, dingen die vergeten zijn of echte fouten) pas helemaal aan het eind aan het licht komen, namelijk als het (min of meer) gerede product kan worden getest. Daarnaast hebben projecten die op deze manier worden uitgevoerd het nadeel dat ze nogal eens lang duren, waardoor er ook ‘fouten’ ontstaan doordat men in de loop van de tijd van mening of inzicht is veranderd.2

3.2 Prototyping In essentie kunnen twee groepen vakgenoten worden onderscheiden in hun opvatting over prototyping. De ene groep stelt dat prototyping dient om de specificaties duidelijk te maken (mens-machine-model, verwerking), de andere stelt dat prototyping een wijze van systeemontwikkeling is. specificaties

Het gebruik van prototypers (of prototyping tools, meestal onderdeel van een CASE-tool; zie ons andere boek over methoden, technieken en tools) 2 De lange duur wordt enerzijds veroorzaakt door de strenge volgorde waarin wordt gewerkt en anderzijds nemen de verschillende beslismomenten aan het eind van iedere fase nogal eens wat tijd.

04_lewis_sdu

01-03-2006

11:51

Pagina 37

Werkwijzen

3GL

permanent onderhoud

37

om specificaties duidelijk te maken, ondersteunt met name het opstellen van het fysieke model en het mens-machine-model in de ontwikkelingsfase. Als eenmaal duidelijk is hoe het systeem dient te functioneren, wordt het prototype weggegooid en wordt met 3GL3 het voorbeeld nagebouwd (zie figuur 3.2). Argumenten die voor deze werkwijze worden aangevoerd zijn: grotere efficiëntie van de coding (minder overhead, optimaliseerbaar via bekende technieken en hulpmiddelen) en het feit dat gecompliceerde structuren voor veel prototypers een probleem opleveren. De andere partij beweert niet dat deze argumenten niet waar zouden zijn, maar legt de prioriteiten ergens anders. Zij stellen dat systemen nooit zijn voltooid; door veranderende omstandigheden zullen steeds wijzigingen moeten worden aangebracht (figuur 3.3). Het is dan van belang telkens uit te kunnen gaan van de correcte, laatste versie van de documentatie van het systeem. Prototypers ondersteunen dit proces van permanent onderhoud als deze tools in staat zijn door, telkens op basis van de aangepaste documentatie, de gewenste functionaliteit te realiseren in plaats van zelf te programmeren. Aldus ontstaat een ‘evolutionaire’ ontwikkelingsmethode. Prototypers gecombineerd met generatoren kunnen hier goede diensten bewijzen. Prototyping

Inventariseer een beperkte (logische) basisbehoefte met een kleine groep gebruikers Ontwikkel snel een werkend prototype Gebruik het prototype Ontwikkeling met een of meer gebruikers Schaaf het prototype bij en breid het uit Demonstreer het prototype voor de project-/ stuurgroep

Ontwikkeling met meer gebruikers(groepen)

Introduceer het prototype bij een grotere groep gebruikers Verkrijg goedkeuring door de project-/ stuurgroep Ontwikkel het definitieve systeem

Figuur 3.2 Prototyping-cyclus bij ontwerp 3 Onder 3GL worden de ‘klassieke’ programmeertalen verstaan, zoals COBOL, PL/1 en Pascal.

04_lewis_sdu

38

01-03-2006

11:51

Pagina 38


Inventariseer de basisbehoeften

Ontwikkel een werkend prototype (=systeem)

Ontwikkeling met een of meer gebruikers

Gebruik het prototype (=systeem)

Onderhoud met gebruikersgroep

Schaaf het systeem bij en breid het uit

Figuur 3.3 Prototyping-cyclus bij onderhoud

omgeving

risico

Naar onze mening is het vooralsnog de omgeving die in belangrijke mate zal moeten bepalen welke werkwijze moet worden gevolgd. In stabiele omgevingen waar grote hoeveelheden gegevens moeten worden verwerkt (bijvoorbeeld bij banken en verzekeringsmaatschappijen), lijkt prototyping als specificatie-ondersteunende werkwijze de voorkeur te verdienen. In snel veranderende omgevingen (handel, analysesystemen) zal de tweede opvatting, prototyping als ontwikkelmethode, beter werken. Bij het gebruik van prototypers loert overigens nog een gevaar. Sommige van deze tools genereren standaard 3GL (waar programmeurs dus rechtstreeks op kunnen ingrijpen), andere genereren een soort intermediaire taal (ergens tussen 3GL en assembler in), die niet buiten het tool om is te wijzigen. Bij het gebruik van de eerste groep bestaat het risico dat de documentatie door aanpassingen achteraf niet meer correct is. En dat betekent verlies van een van de belangrijke voordelen van het gebruik van deze hulpmiddelen, zoals aangegeven bij het permanente onderhoud. De tweede groep prototyping-tools dwingt gebruik van het hulpmiddel af, voor iedere wijziging, hoe onbenullig ook. En daarmee wordt de documentatie in ieder geval up-to-date gehouden.

04_lewis_sdu

01-03-2006

11:51

Pagina 39

Werkwijzen

39

3.3 Cyclisch (of iteratief) Bij cyclisch of iteratief ontwikkelen wordt het systeem in diverse cycli of iteraties uitgebouwd tot een volledig systeem. Dit kan het best worden geïllustreerd aan de hand van een voorbeeld: 1 Allereerst worden de schermen ontwikkeld. Deze worden, in de goede volgorde van de dialoog met de gebruiker, als een soort dia getoond. Men kan dus (nog) niets intoetsen. 2 Vervolgens wordt er een database gekoppeld aan de schermen. De gebruiker kan wel gegevens intoetsen, maar moet dit wel goed doen, omdat er geen controles zijn. 3 Nu worden inhoudelijke en samenhangcontroles ingebouwd. 4 Vervolgens worden de overige functies ingebouwd, bijvoorbeeld voor toegangscontrole. Pas aan het eind is het systeem rijp om te worden geïmplementeerd. Uiteraard kan ook een andere opdeling worden gehanteerd. alle functies van het systeem

Kenmerkend van de cyclische aanpak is dat deze alle functies van het beoogde systeem betreft; dit in tegenstelling tot evolutionair ontwikkelen (zie hierna). Hét grote voordeel van deze aanpak is dat eerst en relatief snel de gebruikersinterface helder wordt gemaakt, voordat veel tijd en geld wordt gestoken in de bestanden en de controles. Als dit van tevoren en bewust gebeurt, kan ook het prototype van de lineaire aanpak worden ‘opgekrikt’ tot iteratief ontwikkelen (dus een lineair ontwerp met prototyping en iteratieve bouw en invoering). Dit scenario is uiterst effectief als de gebruikers nog niet precies weten wat ze willen.

3.4 Incrementeel

increment

Bij de incrementele aanpak worden de eerste drie fasen, vaak aangeduid als informatieplanning, definitiestudie en basisontwerp, in hun geheel uitgevoerd (zie ook hoofdstuk 4). Daarna wordt getracht zo snel mogelijk werkende programmatuur op te delen in incrementen. Een increment is een zelfstandig bruikbare eenheid van het systeem, inclusief ontwerpdocumentatie, opleidingen en dergelijke. Realisatie en invoering geschiedt in een aantal kleine onderdelen in plaats van in één grote fase.

04_lewis_sdu

01-03-2006

40

11:51

Pagina 40


Incrementeel ontwikkelen heeft veel weg van cyclisch of iteratief ontwikkelen. Kenmerkend verschil is dat er nu delen van een systeem op pragmatische wijze worden ontwikkeld en geïmplementeerd. Het betreft het herhaald uitvoeren van alle fasen van het systeemontwikkelingstraject, maar dan kortdurend. Na enige tijd ervaring met dit deelsysteem te hebben opgedaan (voortschrijdend inzicht), worden verbeteringen aangebracht. Deze aanpak is vooral effectief wanneer relatief snel gereageerd moet worden op externe (markt)veranderingen, de organisatie in grote lijnen weet wat en hoe men de informatie wil hebben en het vermoedelijk een groot informatiesysteem betreft. Omdat de eerste drie fasen volgens het watervalmodel worden uitgevoerd, vergt dit toch relatief veel tijd. centre-out-aanpak

Een bijzondere manier van incrementeel werken is de centre-out-aanpak. Centre-out is een werkwijze die gebaseerd is op het idee dat veel informatiesystemen zijn onder te verdelen naar een ‘kern’ (centre) waarin het meest wezenlijke van het systeem wordt uitgevoerd, met daar omheen meerdere ‘schillen’ van uitbreidingen, toevoegingen en verfraaiingen. Deze schillen voegen relatief niet zoveel toe aan de wezenlijke functionaliteit van het systeem, maar wel aan de gebruiksvriendelijkheid, de dekking van het bedrijfsproces en dergelijke. Een financiële administratie draait bijvoorbeeld om het grootboek. Om het grootboek te voeden, zijn journaalposten nodig. Deze vormen de kern van het systeem en bouwen we daarom het eerst. Vervolgens voegen we de debiteuren- en crediteurenadministratie toe en weer wat later ook de voorraadadministratie. Deze deeladministraties maken automatisch de journaalposten voor het grootboek aan.

3.5 Evolutionair rugbymodel

Bij evolutionair ontwikkelen wordt voor ieder increment afzonderlijk alle fases uitgevoerd. Dit wordt ook wel het rugbymodel genoemd. Ten slotte wordt het increment aan de gebruiker(s) overgedragen, waarna dezelfde werkwijze gehanteerd wordt voor het volgende increment. De voordelen zijn vergelijkbaar met die van incrementeel ontwikkelen. Als nog sneller gereageerd moet worden op veranderingen, verdient deze aanpak de voorkeur. Het houdt echter wel enig risico in qua afstemming, omdat het fundament ontbreekt dat wel bij incrementeel ontwikkelen wordt gelegd.

04_lewis_sdu

01-03-2006

11:51

Pagina 41

Werkwijzen

41

Figuur 3.4 geeft een overzicht van de verschillende vormen van systeemontwikkeling. Persoonlijk computergebruik Informatieplanning Iteratief ontwikkelen

Lineair ontwikkelen

Prototypen

Specificatie en ontwerp

Definitiestudie

Prototyping

Realisatie

Basis- en detailontwerp

Invoering

Realisatie

Evaluatie

Invoering

Gebruik en beheer

Figuur 3.4 Vormen van systeemontwikkeling

3.6 Standaardpakketten Waren de voorgaande vormen voorbeelden van maatwerk, in toenemende mate wordt gebruikgemaakt van confectie: standaardpakketten. Hoewel sommige methoden deze pakketten zien als een variant op de lineaire systeemontwikkeling, vereisen ze een specifieke aanpak. Immers, het systeem hoeft niet te worden gebouwd (misschien wel aangepast en dat kan heel lastig zijn), maar is ‘kant en klaar’, wat inhoudt dat de organisatie en de werkwijzen (procedures) binnen de organisatie zullen moeten worden afgestemd op het pakket. Een belangrijke fase in het instellen van de (vele) parameters van het pakket (configuratiepakket, zie fig. 3.5). Voor conversie geldt dat niet de wijze waarop de administratie werd gevoerd maatgevend is voor het nieuwe systeem (zoals bij maatwerk), maar het systeem maatgevend is voor wat er kan worden geconverteerd.

04_lewis_sdu

42

01-03-2006

11:51

Pagina 42


Standaardpakketten Eisen/criteria en marktverkenning Selecteer en evalueer Ontwerp aanpassingen/interfaces

Aanschaf

Conversieplanning

Kosten/baten Detailontwerp Systeembouw

Installatie hardware/software

Conversievoorbereiding

Procedures

Configuratiepakket Testen Converteren Invoering

Gebruik en beheer

Figuur 3.5 Werkwijze bij standaardpakketten

Tot besluit van dit hoofdstuk staan we kort stil bij een nieuwe trend in systeemontwikkeling: RAD (rappid application development).

3.7 RAD: rapid application development RAD als werkwijze is mogelijk geworden door de toenemende mogelijkheden van geautomatiseerde hulpmiddelen. Er bestaan vele uitvoeringen van RAD, die allemaal min of meer als volgt te werk gaan: met behulp van geautomatiseerde hulpmiddelen (zoals screenpainters en reportwriters) kunnen heel snel, op basis van summiere aanwijzingen, prototypes worden gemaakt van verschillende functies van het systeem. Hierdoor kan men de uitkomst zeer snel na het ontwikkelen van het idee testen. Zo worden de functies één voor één gemaakt en samengevoegd tot één samenhangende applicatie. De stukken die al klaar zijn, zijn meteen gereed voor daadwerkelijk gebruik in de productie-omgeving. MAD: model-based application development Sinds kort spreekt men ook over MAD (model-based application development) als een manier van RAD. Het tool dat hierbij wordt gebruikt, legt logische (referentie)modellen vast, van zowel gegevens als processen.

04_lewis_sdu

01-03-2006

11:51

Pagina 43

Werkwijzen

43

Vervolgens zet het tool deze specificaties om naar executeerbare code. Het aantrekkelijke van deze werkwijze is dat de logische modellen die ten grondslag liggen aan het systeem, bewaard blijven en in de toekomst opnieuw kunnen worden gebruikt, bijvoorbeeld bij onderhoud of om over te gaan naar een andere omgeving. Het onderhoud vindt namelijk plaats op de logische modellen, terwijl de generator zorgt voor de omzetting naar de programma’s voor het operationele systeem.

3.8 Gevolgen voor de informaticus Veel van de genoemde nieuwe(re) vormen van werken, hebben grote invloed op de kennis en vaardigheden die van de informaticus (vooral de analist en ontwerper) worden verwacht. Bij de meer klassieke vormen van systeemontwikkeling ging het vooral om technische vaardigheden (het kunnen vertalen van gebruikerswensen naar het geautomatiseerde systeem toe); nu gaat het veel meer om communicatieve vaardigheden (het vertalen naar het systeem toe wordt grotendeels door de hulpmiddelen gedaan) en wordt (enige) deskundigheid aangaande het bedrijfsproces of de bedrijfsomgeving waarin wordt gewerkt steeds meer van belang. intra- en internetten

Maar er is meer. Het toenemende gebruik van intra- en internetten leidt tot een heel andere benadering van informatievoorziening. Kenmerkend aan deze aanpak is dat de aanbieder van de informatie deze aanbiedt omdat hij meent dat dat nuttig is. Aanbieden is simpel en goedkoop en als iemand iets met de informatie kan doen, dan doet hij dat volledig op eigen verantwoordelijkheid. Daarnaast biedt het interactieve karakter van de technologie de mogelijkheid om, in de letterlijke zin van het woord, van gedachten te wisselen. Deze ontwikkelingen geven op hun beurt weer aanleiding tot nieuwe vormen van ontwikkeling en beheer en nieuwe hulpmiddelen (talen zoals Java en Corba en standaardpakketten zoals Internet-browsers). Overigens kan, ter lering en vermaak, hier nog worden opgemerkt dat uit recent onderzoek van de afdeling Bedrijfskundige Informatica van de Hogeschool West-Brabant, is gebleken dat 40% van de Nederlandse ondernemingen de ICT-trends niet of nauwelijks volgen en dat veel ondernemers niet op de hoogte zijn van de gevolgen van deze trends voor hun onderneming (Computable, 3 oktober 1997).

04_lewis_sdu

01-03-2006

44

11:51

Pagina 44


Samenvatting werkwijzen

Dit hoofdstuk is gewijd aan werkwijzen: de manieren van uitvoeren van systeemontwikkeling binnen de gekozen denkwijze. Als belangrijke werkwijzen worden behandeld: lineair, evolutionair, incrementeel en prototyping. Daarnaast worden MAD en RAD behandeld.

lineair

Lineaire methoden (of watervalmethoden) worden al enkele decennia gebruikt en kenmerken zich door een vaste fasering die volgordelijk in de tijd wordt doorlopen.

evolutionair

De evolutionaire werkwijze realiseert telkens kleine aanvullingen of wijzigingen op het systeem, waarbij het hele traject van de lineaire werkwijze wordt doorlopen.

incrementeel

Bij de incrementele werkwijze worden eerst de stappen informatieplanning, definitiestudie en globaal functioneel ontwerp uitgevoerd voor het gehele beoogde systeem, waarna het systeem in kleinere eenheden stuk voor stuk wordt afgebouwd en toegevoegd.

prototyping

Bij prototyping maakt men eerst een voorbeeldsysteem (prototype) om zekerheid te krijgen over het beoogde resultaat. Daarna wordt het productiesysteem gebouwd.

RAD

RAD is de aanduiding voor rapid application development. Deze werkwijze lijkt sterk op die van evolutionair werken, gecombineerd met prototyping met behulp van moderne tools (automatisering van de automatisering). Bij MAD (model-based application development) bouwt men met dergelijke hulpmiddelen eerst een model van het bedrijfsproces, waarna snel applicaties kunnen worden gebouwd op basis van het model. Zo lang het bedrijfsproces stabiel blijft, kunnen zo telkens nieuwe applicaties worden gegenereerd.

rol van de informaticus

Het hoofdstuk wordt afgesloten met een beschouwing over de rol van de informaticus in het licht van ontwikkelingen als RAD en MAD. De conclusie is dat de taak van de informaticus zich meer en meer gaat bewegen op het vlak van de logische aspecten van het systeem, daar de techniek meer en meer van het ‘technische handwerk’ overneemt.

04_lewis_sdu

01-03-2006

11:51

Pagina 45

45

4

Het proces van systeemontwikkeling

De werkwijzen beschrijven in algemene termen op welke manieren een informatiesysteem tot stand kan komen; er wordt nog geen operationele invulling gegeven in termen van wat gebeurt wanneer, in welke volgorde, op basis van welke criteria, enzovoort. In dit hoofdstuk zullen we deze aspecten nader invullen, nadat we hebben aangegeven dat zo’n methodische manier van werken noodzakelijk is om kwaliteit van product en proces te kunnen garanderen. In een dergelijke aanpak zijn verschillende aspecten bij elkaar gebracht: inhoudelijke aspecten (wat moet er worden gedaan, in welke volgorde), planmatige aspecten (wanneer en door wie wordt hierover beslist) en algemene kaders (welke methoden en technieken, welke criteria, welke hulpmiddelen, enzovoort). systems life cycle

In hoofdstuk 1 hebben we reeds aangegeven dat de systems life cycle kan worden gezien als een cyclus bestaande uit drie fasen: – ontwerp en bouw – conversie en invoering – onderhoud en beheer. Deze drie aanduidingen zijn uiteraard geen volledige weergave van wat er in ieder van de fasen feitelijk moet worden gedaan. In dit hoofdstuk zullen de drie fasen verder worden opgedeeld in de afzonderlijke deelproducten die per fase moeten worden opgeleverd.

deelfasen

Over deze opdeling in deelfasen en bijbehorende producten zijn talloze methoden geschreven, zeker over de werkwijzen die gefaseerd verlopen. De indeling die wij hanteren benoemt de deelfasen en producten op een algemeen niveau, zodat vergelijking met andere methoden mogelijk is. Voorafgaande aan de afzonderlijke fasen en producten willen we echter eerst antwoord geven op de vraag waarom er zoveel methodische aanpakken zijn.

04_lewis_sdu

01-03-2006

46

11:51

Pagina 46


4.1 Kwaliteitsmanagement kwaliteitszorg

In essentie draait het bij alle methodische aanpakken van systeemontwikkeling om kwaliteitszorg: doet het systeem wat bedoeld was en heeft dat gekost wat bedoeld was. We gaan hier nader in op het managen van kwaliteit door het managen van het ontwikkelproces. Immers, de kwaliteit van het product (de applicatie) wordt mede bepaald door de mate waarin we het ontwikkelproces onder controle hebben. Daarnaast kunnen eisen ten aanzien van de applicatie worden geformuleerd. We behandelen in dit kader de begrippen statische en dynamische eigenschappen van het systeem en functionele en prestatie-eisen. Procesbeheersing Naast de hierna te beschrijven fasering, die vooral een logische volgorde van te nemen stappen en uit te voeren activiteiten omvat, zijn geld (budget), tijd en beschikbare hulpmiddelen (vooral mensen en hulpmiddelen) bepalend voor de planning.

time box

Nu is het maken van een planning waarin deze drie aspecten variabel zijn, nauwelijks uitvoerbaar. Afhankelijk van de situatie zullen één of twee variabelen ‘vast’ moeten worden gezet. Zo is ‘time boxing’ een aanpak waarbij de beschikbare tijd bepalend is en geld en resources daaraan ondergeschikt zijn. Een time box is een gefixeerde periode waarin een bepaalde klus moet worden geklaard (een fase of stap binnen een fase bijvoorbeeld). Vervolgens worden de overige elementen (geld en resources) in deze box ‘gepropt’. Voordeel: je weet precies wanneer iets wordt gedaan en wanneer het klaar is. Het beschikbaar hebben van de resources kan meer geld kosten dan nodig zou zijn geweest als we de resources als uitgangspunt hadden genomen. Neem je de resources als uitgangspunt (wanneer kan wie worden ingezet), dan weet je zeker dat de beste mensen kunnen worden ingezet (garantie van kwaliteit) zonder dat dit extra kosten met zich meebrengt (je kunt binnen het budget blijven). Je weet echter niet precies wanneer het klaar is. Neem je het budget als uitgangspunt (het mag niet meer kosten dan ...), dan worden kwaliteit en tijd onzeker. Hoe meer variabelen vast worden gezet, hoe moeilijker het wordt om tot een planning te komen en de kwaliteit te garanderen.

04_lewis_sdu

01-03-2006

11:51

Pagina 47


47

In het tweede deel van Innoverend informatiseren gaan wij uitgebreid op enkele concrete methoden in. Productbeheersing Bij productbeheersing gaat het om eigenschappen van het informatiesysteem die ervoor zorgen dat het product geen onverwachte eigenschappen heeft die het beheer ervan bemoeilijken. Maatregelen die hieraan kunnen bijdragen hebben te maken met: – statische eigenschappen van het systeem, zoals modulaire opbouw, goede scheiding van verwerking en gegevens, actuele documentatie, gebruik van betrouwbare componenten en leveranciers – dynamische eigenschappen van het systeem, waarbij gedacht kan worden aan betrouwbaarheid en correctheid van de verwerking, maar ook performance (belasting van het netwerk en de CPU, beslag op schijfruimte, omvang van transacties, enzovoort). De statische eigenschappen worden in belangrijke mate bepaald door de wijze van uitvoering van het proces van systeemontwikkeling (de hierna te behandelen fasering). De dynamische eigenschappen hangen ook samen met het ontwikkelingsproces, maar teven met het gevoerde beleid ten aanzien van de automatisering: zijn er normen, criteria, richtlijnen, enzovoort? Deze criteria worden vastgelegd in het informatiebeleidsplan of informatieplan. De dynamische aspecten van kwaliteit hebben de vorm van functionele eisen en prestatie-eisen. functionele eisen

Functionele eisen zijn de eisen die men stelt aan de gebruikersfuncties van een informatiesysteem. Met andere woorden: wat moet het informatiesysteem doen? Deze eisen worden bepaald door het soort systeem (boekhoudsysteem, patiëntenregistratiesysteem, enzovoort) en de organisatie die het systeem gaat gebruiken. Een voorbeeld: een boekhoudsysteem moet kunnen boekhouden, dus debet en credit kennen, journaalposten en grootboekrekeningen hebben, enzovoort. Maar er zijn organisaties die alleen gebruikmaken van kostenplaatsen (inkoop, productie, magazijn) en kostensoorten (personeel, grondstoffen, energie), of alleen van kostendragers (veelal de producten die de organisatie levert). Als een bedrijf een kostendrageradministratie wenst, zal het informatiesysteem die functionaliteit moeten bieden. Daarnaast behoren tot de functionele eisen onderwerpen als gebruiksvriendelijkheid, foutafhandeling en goede invoercontroles. Functionele eisen zijn vastgelegd in het functioneel ontwerp (zie hierna).

04_lewis_sdu

01-03-2006

11:51

Pagina 48

48


prestatie-eisen

In de literatuur worden prestatie-eisen omschreven als een set eisen die, onafhankelijk van de feitelijke toepassing, op voorhand kan worden geformuleerd op basis van de karakteristieken van de gebruiksomgeving. Men spreekt in dit kader ook wel van generieke eigenschappen: eigenschappen die worden veroorzaakt (gegenereerd) door bepaalde externe omstandigheden, zoals de gebruiksomgeving, en in aanleg voor alle systemen gelden die in die omgeving kunnen worden gerealiseerd. Deze eisen gaan vooraf aan de functionele eisen, die voortvloeien uit het soort toepassing (zie hiervoor). Prestatie-eisen zou je kunnen samenvatten als: hoe moet het informatiesysteem het doen? Voorbeeld 1: een informatiesysteem dat gebruikt wordt voor de begeleiding van een raketvlucht naar de maan, moet zo snel zijn dat het koerscorrecties kan berekenen voordat deze moeten worden uitgevoerd. Bij snelheden van tienduizenden kilometers per uur heb je maar heel weinig tijd om een correctie uit te voeren en dus moet het antwoord heel snel worden gevonden. Hiervoor is een supercomputer nodig, omdat de berekeningen zeer complex zijn, het ‘tijdvenster’ waarin de benodigde correcties kunnen worden uitgevoerd heel klein is en raketten nu eenmaal feitelijk niet kunnen stoppen. Voorbeeld 2: een informatiesysteem dat wordt gebruikt voor de begeleiding van een vaart met een mammoettanker moet zo ver vooruit kunnen ‘denken’ dat koerscorrecties nog effectief kunnen worden uitgevoerd. Een mammoettanker heeft zoveel massa dat het bij een ‘noodstop’ meer dan 20 kilometer (circa een uur) duurt voordat het schip stil ligt. Voor het uitvoeren van de berekening is een klein computertje genoeg, het steekt niet op een paar minuten als het probleem tijdig is gedetecteerd. In de praktijk betekent dit dat het een mens is (de kapitein) die voorziet wanneer een manoeuvre moet worden uitgevoerd; de computer doet de aanvullende berekeningen voor invloeden van getijdenstromingen, wind en dergelijk. Prestatie-eisen dienen expliciet vooraf te worden geformuleerd, dus voordat de functionele eisen aan de orde komen. De functionele eisen zijn automatisch onderdeel van het (functioneel) ontwerp (waartoe dient het systeem), maar zonder de prestatie-eisen zijn ze eigenlijk niet compleet. Nu zijn natuurlijk niet alle eisen altijd even belangrijk. Bij het realiseren van een informatiesysteem dient ook naar een evenwicht tussen kosten en baten te worden gestreefd. Het inwilligen van alle eisen (als dat al mogelijk is) drijft de prijs meestal tot grote hoogten op. We zullen dus keuzes moeten maken, prioriteiten moeten stellen.

04_lewis_sdu

01-03-2006

11:51

Pagina 49


49

4.2 Informatieplanning

informatieinfrastructuur

In veel moderne(re) literatuur wordt als eerste ‘fase’ informatieplanning benoemd, die nog vooraf gaat aan het ontwerp (zie bijvoorbeeld de latere versies van SDM/LAD). Informatieplanning houdt zich, in grote lijnen, bezig met de totale informatie-infrastructuur van de organisatie. Het gaat hierbij dus om langeretermijnbeleid aangaande de inrichting van de gegevenshuishouding, de ICT-infrastructuur en de applicatie-architectuur (deze begrippen lichten we hierna toe). Doordat hierover een visie bestaat, is het mogelijk voorstellen voor nieuwe applicaties of vernieuwing te beoordelen en tot beslissingen te komen van meer principiële aard (doen we het wel of doen we het niet?). Een dergelijke visie dient men niet alleen te ontwikkelen, maar ook te onderhouden. Zeker in de ICT gaan ontwikkelingen snel. Er is weliswaar niet ieder jaar weer een dergelijk plan nodig, maar periodiek moet worden getoetst of het bestaande plan nog voldoende bij de tijd is en welke aanpassingen eventueel nodig zijn. Informatieplanning is een doorgaand proces, dat een nauwe relatie heeft met het verdere bedrijfsbeleid. Hoewel je misschien het eerste plan ooit door een projectgroep hebt laten opstellen, is het verdere onderhoud en beheer ervan een taak voor de staande organisatie. Soms noemt men de functionarissen hiervoor wel informatiemanagers.

gegevenshuishouding

Met gegevenshuishouding wordt bedoeld de manier waarop gegevens worden verzameld en vastgelegd, wat ze betekenen, waar ze worden opgeslagen en wie ze mag gebruiken. Men spreekt wel van een corporate data model (bedrijfsgegevensmodel). Deze modellen blijken in de praktijk overigens zeer moeilijk op te stellen (zeker als ze compleet moeten zijn). De beschrijving van het netwerk en de daarin aanwezige componenten, de benodigde capaciteit en functionaliteit, noemt men wel ICT-infrastructuur (informatie- en communicatietechnologie). Het is met name dit deel van het informatieplan dat het meest aan wijzigingen onderhevig is: er zijn altijd wel weer componenten die nog krachtiger, slimmer of goedkoper zijn. Het is nodig permanent in de gaten te houden wat er op de ICT-markt gaande is. Telkens dienen vooral strategische keuzes te worden gemaakt: welke leverancier(s), welke standaards, welke budgetten en welke planning in de tijd. Dit traject noemt men wel informatiestrategie of ICTstrategie.

04_lewis_sdu

01-03-2006

50

applicatiearchitectuur

informatieplan

11:51

Pagina 50


Het geheel van software dat voor de verzameling, vastlegging, distributie en verstrekking van gegevens zorgt, de applicaties dus, vormt de applicatie-architectuur. Vooral als er in de loop van de tijd meerdere generaties applicaties binnen een organisatie in gebruik zijn, wordt het bewaken van de onderlinge afstemming steeds moeilijker. Dit is in heel veel organisaties het geval. Het informatieplan moet de afstemming en samenwerking van al deze verschillende elementen (hardware, software, gegevens) in hun onderlinge samenhang beheren en besturen. Binnen de kaders van het informatieplan worden de diverse applicaties ontwikkeld, in de reeds genoemde stappen ontwerp en bouw, conversie en invoering, en gebruik en beheer. De verschillende manieren van aanpak van dit traject worden behandeld in de volgende paragrafen van dit hoofdstuk.

4.3 Informatiebehoefte Het vaststellen van informatiebehoeften begint al bij het opstellen van het informatieplan. Er zal (al is het maar globaal) in kaart moeten worden gebracht wie welke informatie wanneer nodig heeft. Daarnaast zal duidelijk moeten zijn welke informatie wanneer waar vandaan komt (we spraken hiervoor over gegevenshuishouding). Zodra we een specifieke applicatie willen gaan bouwen, zullen we de informatiebehoefte veel preciezer moeten gaan vaststellen. Deze maakt deel uit van de functionele eisen en is dus onderdeel van het (later) te maken ontwerp. Ook zal hier moeten worden gekeken naar de prestatie-eisen. In de praktijk is deze fase niet alleen de belangrijkste (een onopgemerkte fout die je hier maakt blijft je het hele verdere proces (achter)volgen!), maar ook de moeilijkste. denkwijze en werkwijze

Bij de aanpak van deze fase zijn keuzes omtrent denkwijze (proces, gegeven, gedrag) en werkwijze (top-down of bottom-up) van groot belang. Iedere informatie-analist heeft de ervaring dat de mensen die het feitelijke werk moeten doen, een heel goed beeld hebben van hun informatiebehoefte (deze is immers een rechtstreeks gevolg van hun werkinhoud). Maar hoe ‘hoger’ je komt in de hiërarchie, hoe onduidelijker de informatiebehoefte wordt (de directeur weet niet welk probleem hij morgen tegenkomt en wat hij dan zou willen weten). Dit vertaalt zich vaak in een soort ‘totale informatiebehoefte’ (ik wil alles weten). Dit is technisch gezien meestal onmogelijk, maar ook niet wenselijk. Welk mens kan ‘alles’ overzien?

04_lewis_sdu

01-03-2006

11:51

Pagina 51


51

Overigens kan ook de informatie-analist niet ‘alles’ overzien. Daarom maakt hij gebruik van technieken om dingen vast te leggen, vraagt hij een goede afbakening van het terrein en bedient hij zich van een aantal ervaringsregels. Bijvoorbeeld: als niet alle situaties zijn te voorspellen, is gegevensmodellering vaak beter dan procesmodellering; is snelheid van belang, dan is gedrags- of procesmodellering handiger dan gegevensmodellering, enzovoort. Men noemt deze fase in andere methoden ook wel vooronderzoek, haalbaarheidsonderzoek of definitiestudie. Het doel van het vooronderzoek is afbakening van het te bouwen systeem en beoordeling van de haalbaarheid (uitvoerbaarheid) van het beoogde systeem, vooral vanuit technisch oogpunt (kunnen we het?) en vanuit financieel oogpunt (kunnen we het betalen?). Als het antwoord op deze vragen bevestigend luidt, wordt overgegaan tot de tweede fase: het ontwerp.

4.4 Ontwerp, bouw en testen

onderzoek

In de fase ontwerp en bouw (ontwikkeling) kunnen de volgende activiteiten aan de orde komen: Eerst wordt onderzoek gedaan naar aspecten als: – knelpunten in de huidige situatie – haalbaarheid van geautomatiseerde ondersteuning van de informatieverwerking – randvoorwaarden volgens het informatieplan. Op grond van de resultaten van het onderzoek moet een aantal keuzes worden gemaakt, zoals: – selectie van een denkwijze (benaderingswijze) en een werkwijze – selectie van interne/externe ondersteuning – zelf (laten) bouwen of standaardpakket kopen – selectie van ontwikkelingssoftware en eventueel de hardware.

analyse

De onderzoeksresultaten zijn tevens uitgangspunt voor de analyse: – analyse van de informatiebehoeften – analyse van gegevens die benodigd zijn. De meeste van deze zaken zijn aan de orde geweest in het informatieplan en het vooronderzoek, zoals hiervoor is beschreven. De resterende punten kunnen apart worden opgepakt of als onderdeel van de volgende activiteiten worden uitgevoerd.

ontwerp

De uitkomsten van de analyse zijn weer input voor het ontwerp. In het ontwerp zijn opgenomen:

04_lewis_sdu

01-03-2006

52

11:51

Pagina 52


– een logische beschrijving van het systeem. Dit is de beschrijving van de gewenste functionaliteit van het systeem en de prestatie-eisen – een technische beschrijving van het systeem. Dit is de omzetting van functionele beschrijvingen naar programma’s, databases en andere technische onderdelen van het systeem. bouw functioneel ontwerp

Ten slotte wordt op basis van het ontwerp het systeem daadwerkelijk gebouwd: – programmeren en testen. De logische beschrijving, vaak functioneel ontwerp (FO) of functionele specificaties (FUSP) genoemd, beschrijft in detail wat het systeem allemaal moet kunnen, hoe de gebruikersinterface eruit ziet (lay-out beeldscherm, boodschappen, foutmeldingen, helpfunctie), wat de print-layout is, maar ook hoe back-ups moeten worden gemaakt, hoe tabellen worden onderhouden, enzovoort. In het functioneel ontwerp staat ook welke gegevens moeten worden opgeslagen, wat ze betekenen en hoe ze samenhangen. Ten slotte wordt een (bijgestelde) begroting voor het verdere traject gemaakt. Functionele ontwerpen worden meestal gemaakt door informatie-analisten, ontwerpers en gebruikers tezamen. FO’s zijn meestal behoorlijk dikke pakken papier. En het is de bedoeling dat de opdrachtgever (toekomstige gebruiker) het FO helemaal doorleest en goedkeurt, want het is de ‘blauwdruk’ voor de volgende activiteiten: technisch ontwerp, programmeren en testen tot en met de acceptatietest. Als het functioneel ontwerp wordt goedgekeurd door de opdrachtgever, kan worden overgegaan tot de volgende fase: het technisch ontwerp.

technisch ontwerp

De technische beschrijving, vaak technisch ontwerp (TO) genoemd, beschrijft van alle onderdelen van het FO hoe deze technisch gerealiseerd gaan worden. Programmastructuren, database-ontwerp, koppelingen, standaardcodes, enzovoort worden tot op ‘de laatste bit’ behandeld. Hoe zit de besturing van het systeem in elkaar? Aan de gegevenskant worden de volgende zaken vastgelegd: wat is de zoeksleutel, hoe lang mag een veld zijn, wat voor soort tekens bevat het veld? Nu kan ook definitief worden gekozen voor het soort en de grootte van de machine, de schijven en andere hardware-zaken. Ten slotte wordt ook nu weer naar de financiën gekeken, omdat bij iedere stap meer zekerheid ontstaat omtrent de uiteindelijke kosten. De bedoeling van het TO is dat programmeurs alleen nog maar bezig hoeven te zijn met het oplossen van de feitelijke programmeerproblemen;

04_lewis_sdu

01-03-2006

11:51

Pagina 53


53

de structuur en de samenhang zijn duidelijk. TO’s zijn meestal nog dikker dan FO’s en voor de opdrachtgever eigenlijk onleesbaar. Alleen iemand die echt verstand heeft van techniek, kan ze lezen. Ze worden dan ook gemaakt door programmeurs/analisten en databasespecialisten. Gebruikers komen er niet aan te pas. coderen

test

Vervolgens start de bouw, vaak ‘coderen’ genoemd, omdat het resultaat bestaat uit wat men noemt de source coding (broncode). Dit zijn de programma-instructies in een bepaalde programmeertaal (C, Pascal, Fortran, Visual Basic, Cobol, enzovoort). Vervolgens wordt de broncode door een compiler (een programma dat programmaregels omzet in door de machine ‘leesbare’ instructies) omgezet in ‘executables’ (objectcode, machinecode), waarna kan worden getest. Deze eerste test gaat om de vraag: doet het systeem het? Als de verschillende delen van het systeem geprogrammeerd en getest zijn, worden ze samengevoegd en opnieuw getest. Hierbij is sprake van de vraag: doet het geheel het? Men noemt een dergelijke test integratietest. Als een systeem in modules wordt gebouwd, zijn er vaak integratietests op meerdere niveaus. Telkens worden de gebouwde en geteste delen tot grotere gehelen samengevoegd en weer getest. Als alles is geprogrammeerd en samengevoegd, volgt ter afsluiting de systeemtest. Hierbij gaat het om de vraag: werkt het zoals het in het TO is beschreven? Als een systeem door deze test heen komt, is het werk van de programmeurs bijna klaar. Bijna, want nu moet nog de finale controle plaatsvinden: doet het systeem wat bedoeld was? Dit betekent dat het systeem aan de hand van het FO moet worden getest. We spreken dan van een acceptatietest.

4.5 Acceptatietest Men noemt deze test acceptatietest omdat het resultaat ervan moet zijn dat de opdrachtgever (de uiteindelijke gebruiker) het product daadwerkelijk accepteert: het doet wat het moet doen, zoals vastgelegd in het FO. Vaak volgt men voor het doen van de acceptatietest de volgende procedure: – opstellen testscripts Voor iedere functie in het FO wordt een testgeval opgesteld, dat alle aspecten van de functie, dus ook de fouten, storingen, enzovoort, beschrijft. Hierbij worden de verschillende input-waarden en de bijbehorende output (op basis van het FO) vastgelegd. Vervolgens loopt

04_lewis_sdu

01-03-2006

54

11:51

Pagina 54


men het systeem helemaal door aan de hand van testscripts. De resultaten worden per geval vastgelegd – foutherstel Er komen altijd wel een aantal dingen uit zo’n test naar voren die niet helemaal (of helemaal niet) goed zijn. Deze worden vervolgens, volgens de beschrijving van het FO en de bevindingen van de test, aangepast – hertest Het geheel wordt opnieuw getest (soms veroorzaken correcties op de ene plaats, nieuwe fouten op een andere plaats). Zo gaat het door totdat men zich ervan overtuigd heeft dat het allemaal naar behoren werkt. Dan is de acceptatietest klaar, kunnen de bouwers worden gedechargeerd en kan de rekening worden betaald. omgeving

Overigens moet ook de omgeving bij een acceptatietest aan een aantal voorwaarden voldoen. Onder omgeving verstaan we de grootte van de computer (de capaciteit), de versie van het besturingssysteem, het aantal gelijktijdige gebruikers, het netwerk en mogelijke andere applicaties die op dezelfde machine draaien. Al deze zaken moeten zoveel mogelijk lijken op de situatie waarin het productiesysteem straks operationeel wordt. Is dit niet het geval, dan kunnen straks bij de invoering nieuwe problemen opduiken die het proces in gevaar brengen.

4.6 Invoering Invoering wil zeggen: het in gebruik nemen van het nieuwe systeem in de organisatie. Personeel moet worden opgeleid, apparatuur geïnstalleerd, enzovoort. Het kan niet vaak genoeg worden gezegd dat deze fase eigenlijk de belangrijkste is en de meest bepalende voor het slagen dan wel falen van het nieuwe systeem. Ook al is het systeem misschien niet 100%, als de introductie zodanig verloopt dat iedereen enthousiast is, wordt het een succesvol systeem. Een perfect systeem dat zodanig wordt ingevoerd dat iedereen er een hekel aan krijgt, mislukt meestal. implementatie

In deze fase, ook wel aangeduid als implementatie, kunnen onder andere de volgende zaken aan de orde komen: – opleiden van de gebruikers – opleiden van de beheerders – overzetten van de gegevens vanuit de oude situatie naar de nieuwe situatie (conversie)

04_lewis_sdu

01-03-2006

11:51

Pagina 55


55

– treffen van de technische voorzieningen voor het nieuwe systeem (bedrading, technische ruimten, enzovoort) – doorvoeren van organisatorische aanpassingen – aanpassingen in de administratieve organisatie – de feitelijke ingebruikstelling. Overigens kan een aantal van deze activiteiten (zoals opleiden, technische voorbereidingen en dergelijk) al beginnen voordat de bouw voltooid is. Bij invoering komen ook enkele andere kleuren van de zevenkleurige bril aan de orde. Vaak is er sprake van een verandering (reorganisatie, andere taken en functies) en communicatie is van groot belang (iedereen moet ervan weten en iedereen moet hetzelfde weten). Juist omdat veel automatiseerders van deze onderwerpen onvoldoende verstand hebben, is het aan te raden hiervoor aparte deskundigen in te zetten. Daarnaast zijn er enkele factoren in het spel die het hele invoerproces aanzienlijk ingewikkelder kunnen maken. We komen daar in het navolgende uitvoerig op terug. Hier kunnen we alvast melden dat hoewel planning in het traject van ontwerp en bouw van belang is, er eigenlijk geen man overboord is als het mis gaat. De oplevering kan daardoor te laat zijn en het kan extra geld kosten, maar de gewone bedrijfsvoering loopt niet of nauwelijks risico, het gewone werk kan gewoon doorgaan. Bij invoering ligt dit anders, dan wordt de gewone bedrijfsvoering rechtstreeks geraakt door het invoerproces, ook als het goed gaat en helemaal als er iets fout gaat. Dit geldt voor de installatie, de opleidingen, de conversie en de feitelijke ingebruikneming. Invoerstrategieën Voor de invoering van een (nieuw) systeem kan uit een aantal strategieën worden gekozen: – ineens (ook wel cold turkey genoemd) – gefaseerd – schaduwdraaien.

‘fall back’-plan

Ineens Dit is de snelste, maar ook meest riskante manier van invoering. Soms kan het niet anders (bij een nieuwe telefooncentrale bijvoorbeeld), maar dan is een goed ‘fall back’-plan van groot belang: als het mis gaat kan men weer terug naar de vorige situatie. Door dit soort extra voorzieningen blijkt deze invoerstrategie niet zo goedkoop als men wel eens denkt.

04_lewis_sdu

56

01-03-2006

11:51

Pagina 56


Gefaseerd Bij stukje en beetje gaat men over op het nieuwe systeem. Deze methode werkt alleen als het nieuwe systeem hierop is voorzien. Een probleem is dat gedurende het invoertraject telkens andere situaties in de organisatie ontstaan (‘oh, jullie zitten nog niet op het nieuwe systeem?’ ... ‘nee, die mogelijkheid hebben wij pas over een week’). Schaduwdraaien Gedurende enige tijd draaien het oude en het nieuwe systeem naast elkaar. Dit is een dure oplossing omdat voor een bepaalde periode dubbel werk moet worden gedaan en dubbel geld moet worden uitgegeven (aan twee systemen). Het voordeel is dat er, nadat zeker is geworden dat het nieuwe systeem goed werkt, ineens en integraal over kan worden gestapt naar het nieuwe systeem. Over opleidingen hebben we het later nog; hier willen we nog even iets zeggen over de installatie. Installatie kan een groot project op zich zijn. Als alle kabels nog moeten worden gelegd, de computerruimte nog moet worden ingericht, enzovoort, gaat het al gauw over miljoenen en over weken werk. Van dit soort werkzaamheden hebben de andere medewerkers in het bedrijf last: het is lawaaiig, het tocht omdat er ramen uit de gevel worden gehaald, de gangen staan vol dozen, de plafonds liggen open, enzovoort. En het werk moet gewoon verder! Er is een probleem met de invoering als zich in het bedrijf de volgende scène afspeelt: man komt binnen met klopboor en begint een gat in de vloer te boren. Medewerker vraagt: waarom boort u een gat in de vloer? Man met klopboor zegt: dat is voor het nieuwe computersysteem dat hier komt. Waarop de medewerker vraagt: welk computersysteem?

4.7 Opleiding Opleiden heeft meerdere kanten: wat moet ik doen, wanneer moet ik het doen en waarom moet ik het doen? Bij het maken van opleidingsplannen moeten deze aspecten duidelijk uit elkaar worden gehouden, want het gaat om totaal verschillende manieren van opleiden. Het zal niet de eerste keer zijn dat een dagje ‘wat-cursus’ voor de bediening van het nieuwe systeem (ook wel knoppencursus genoemd) niet leidt tot het beoogde doel, omdat telkens vragen opduiken die te maken hebben met: hoe past het in mijn werkzaamheden (wanneer, waarom)? Een ander lastig punt is dat iemand die in de klas zit, zijn gewone werk niet kan doen. Hoe los je dat op? Door niet iedereen tegelijk naar cursus

04_lewis_sdu

01-03-2006

11:51

Pagina 57


57

te sturen? Maar dan gaan de opleidingen langer duren. En om iemand cursus te geven die daarna nog weken op het nieuwe systeem moet wachten is weggegooid geld: als het zover is, is hij de cursus vergeten. Zeker bij grootschalige projecten, waarbij veel personeelsleden naar cursus moeten, blijkt dat het tempo van invoering van het systeem wordt bepaald door de snelheid van opleiden. Dit leidt tot gefaseerd invoeren, maar is het systeem daar wel op berekend?

4.8 Conversie Conversie is het overzetten van gegevens, maar ook van procedures en dergelijke, van de oude situatie naar de nieuwe. Met name gegevensconversie is nogal eens aanleiding tot verhitte discussies. Enerzijds is het zonde (en soms zelfs onmogelijk) om alle oude gegevens ‘weg te gooien’, anderzijds kost converteren tijd en geld (en soms zelfs veel van allebei) terwijl er geen goed zicht is op de kwaliteit van de te converteren gegevens. Bovendien is het meestal zo dat het systeem maar gedeeltelijk of helemaal niet beschikbaar is gedurende een conversie, en dus moet het in het weekend, wat overwerk betekent. Als de hoeveelheid gegevens heel groot is, red je het soms niet in een weekend. En wat doe je als halverwege het weekend de conversie mis gaat? noodscenario’s

Het zal duidelijk zijn dat conversie zorgvuldig moet worden gepland, waarbij ook allerhande calamiteitenscenario’s moeten worden bedacht.

4.9 Ingebruikneming Als alle voorbereidingen klaar zijn (installatie, opleiding en conversie), komt het moment waarop ‘de knop omgaat’. Afhankelijk van de gekozen strategie kan dit voor het eerst en voor iedereen zijn of per afdeling of nadat al een tijdje met het nieuwe systeem is gewerkt. Als alle noodscenario’s goed zijn uitgewerkt, het communicatieplan heeft gewerkt (iedereen weet het) en alle andere voorbereidingen goed zijn uitgevoerd, is dit een soort anticlimax: je merkt er bijna niets van. Soms krijg je echter te maken met nieuwe, onverwachte gevolgen, zoals bij de Effectenbeurs van Londen, inmiddels jaren geleden. Toen het nieuwe beurssysteem in gebruik was genomen, bleek de impact op de effectenhandel van dien aard, dat het systeem zichzelf ‘opblies’ en de effectenhandel blokkeerde. Het systeem gaf iedereen hetzelfde advies op

04_lewis_sdu

01-03-2006

58

11:51

Pagina 58


basis van de koersontwikkeling en een simpele druk op de knop was genoeg om het advies om te zetten in een echte beurstransactie. De koersen gingen daardoor gigantisch en onverantwoord schommelen. Men heeft het systeem toen weer uitgezet en is, na enkel uren, weer op de oude, handmatige manier verdergegaan. Het betreffende systeem is niet meer in gebruik genomen.

4.10 Gebruik en beheer Voor deze ‘fase’ worden verschillende termen gebruikt: exploitatie, onderhoud en beheer, gebruik en beheer, enzovoort. Waar alle termen op duiden is dat de continuïteit van het systeem moet worden geregeld nadat het systeem in gebruik is genomen. Deze inspanning moet worden geleverd zolang het systeem in gebruik is. Het is dan ook verstandiger niet van een fase te spreken en deze niet bij een projectorganisatie onder te brengen, maar onderdeel van de gewone bedrijfsvoering te laten zijn. Twee belangrijke hoofdtaken zijn te onderscheiden: het onderhoud, dat vooral onder de beheerskant valt, en ondersteuning, dat vooral ten behoeve van het gebruik is. onderhoud

ondersteuning

Onderhoud omvat een reeks activiteiten die meer op de achtergrond spelen en primair gericht zijn op de continuïteit van het systeem zelf. Tot de taken behoren onder meer: – maken van reservekopieën van bestanden en programmatuur (backups) – onderhouden van de apparatuur (preventief en correctief) – onderhouden van de programmatuur (correctief, adaptief en perfectief) – onderhouden van documentatie en kennis. Voor de hele periode van het gebruik van het systeem dient voor de gebruikers ondersteuning beschikbaar te zijn voor zaken als: – behandelen van storingen en fouten – beantwoorden van vragen over de bediening van het systeem – onderhoud van passwords en autorisaties – continuïteit van kennis en opleiding.

4.11 ITIL In Engeland is een andere benadering gekozen voor het beheren en exploiteren van informatiesystemen en alles wat daarmee samenhangt.

04_lewis_sdu

01-03-2006

11:51

Pagina 59


IT-infrastructuur

59

Hier is in opdracht van de Engelse overheid de Information Technology Infrastructure Librabry (ITIL) ontwikkeld. In Nederland hebben verschillende grote bedrijven deze methode inmiddels geïmplementeerd. ITIL benadert beheer en exploitatie als processen. Van belang hierbij is dat het proces een product oplevert en dat dit product een bijdrage levert aan de organisatie. De mensen die onderdeel uitmaken van dit proces hoeven niet op een en dezelfde afdeling te werken. Aan een proces kan op verschillende plaatsen in de organisatie waarde worden toegevoegd. ITIL definieert de infrastructuur van informatie technologie (IT) als volgt.

–––

|

De IT-infrastructuur omvat het geheel van apparatuur, programmatuur, datacommunicatiefaciliteiten en de daarbijbehorende procedures en documentatie.

–––

|

processen

ITIL verdeelt de processen onder naar het soort doel: strategisch of long term, tactisch of medium term en operationeel of short term. We noemen hier kort een aantal processen. Service level management is het tactische proces dat de totstandkoming, het toezicht en de evaluatie van de overeenkomst verzorgt. De prestaties van het systeem worden gevolgd vanuit het tactische proces capacity management. Availability management is het tactische proces dat toeziet op de beschikbaarheid van diensten zoals die zijn overeengekomen in de service level agreement. Contingency planning is het tactische proces dat zich richt op het beheersen van noodsituaties. Configuration management is het operationele proces dat zich richt op het beheersen van de IT-infrastructuur. De helpdesk is het operationele proces waarbinnen vragen afgehandeld worden en incidenten worden opgelost. Het doel van dit proces is het zo spoedig mogelijk herstellen van de dienstverlening. Dit betekent over het algemeen een frequent contact met de gebruikers, omdat het hier het eerste aanspreekpunt betreft. Dit proces is in hoge mate bepalend voor de mate waarin beheer en exploitatie gewaardeerd wordt door de gebruikers.

04_lewis_sdu

01-03-2006

60

11:51

Pagina 60


Het operationele proces change management is van cruciaal belang voor de stabiliteit van de IT-infrastructuur. Niet iedere verandering in de ITinfrastructuur wordt beschouwd als de verantwoordelijkheid van het wijzigingsbeheer. Iedere verandering die een aanpassing in de CBDB noodzakelijk maakt, wordt bestempeld als wijziging. Een wijziging kan het gevolg zijn van een probleem, maar we spreken ook van een wijziging wanneer apparatuur verplaatst, verwijderd of toegevoegd wordt. Het operationele proces software control and distribution (programmatuurbeheer en -distributie) ligt in het verlengde van het proces configuratiebeheer. Programmatuur vereist speciale aandacht omdat deze vaak in verschillende versies beschikbaar is. Als door een wijziging aangepaste programmatuur beschikbaar komt, is programmatuurbeheer en -distributie verantwoordelijk voor het vaststellen van het versienummer en het implementeren van deze nieuwe versie. Tot slot is er een operationeel proces dat zich richt op het netwerk, namelijk network service management. Het netwerk service management is vooral betrokken bij wijzigingen in en vernieuwing van het netwerk. De materie rond onderhoud en beheer wordt nader behandeld in een ander deel in deze reeks: Ontwikkeling en beheer van informatiesystemen van R. Lewis en B. van der Poel.

Samenvatting lineaire aanpak

In hoofdstuk 4 komt het hele traject van de ‘klassieke’ lineaire aanpak aan de orde. Nadat is ingegaan op het belang van een gestructureerde aanpak in het kader van kwaliteitsbeheersing, zijn de opvolgende stappen van het model stuk voor stuk behandeld.

informatieplanning

Informatieplanning is het beleidsmatige fundament waarop alle systeemontwikkeling binnen de organisatie is gebouwd. IP een onderdeel van de bedrijfsstrategie en de zorg voor het uitvoeren en onderhoud ervan dient in de top van de organisatie te zijn geregeld.

informatiebehoeften

Voordat aan de realisatie van een applicatie wordt begonnen, wordt een onderzoek naar de informatiebehoeften gedaan. Daarnaast is onderzoek naar haalbaarheid, kosten en systeemgrenzen nodig. Men spreekt van een definitiestudie.

04_lewis_sdu

01-03-2006

11:51

Pagina 61


FO TO

integratietest

61

Vervolgens wordt het logisch ontwerp (FO) gemaakt, dat alle gewenste functionaliteiten in detail beschrijft. Dit is de basis voor het technisch ontwerp (TO) dat de functionele beschrijving omzet naar voor programmeurs geschikte en begrijpelijke structuren. Het schrijven van de programma’s (coderen) vertaalt het technisch ontwerp in voor de computer hanteerbare instructies. De aldus ontstane programma’s worden eerst afzonderlijk getest en daarna in hun onderlinge verband (integratietest). Als het hele systeem gereed is, volgt de finale technische test, de systeemtest.

acceptatietest

Nu wordt de acceptatietest uitgevoerd die nagaat of alle in het FO genoemde functionaliteiten correct door het systeem worden afgehandeld.

invoering

Vervolgens begint de invoering, die zeer goed planmatig moet zijn voorbereid. Immers, als hier dingen mis gaan, heeft het hele bedrijf er last van. Dit geldt voor het installeren van hardware en software, het opleiden van de gebruikers en beheerders, en de conversie van bestanden en aanpassing van procedures.

onderhoud en beheer

ITIL

Invoeren kan ineens, in fasen of via schaduwdraaien. Uiteindelijk wordt het systeem in gebruik genomen en beginnen de taken voor onderhoud en beheer. Onderhoud en beheer zorgt voor de continuïteit van het systeem, de ondersteuning van de gebruikers en de kwaliteit van de verstrekte informatie. Ook dit is een permanente taak, die bij een vast organisatie-onderdeel wordt ondergebracht. Aan het eind van het hoofdstuk komt een aantal aspecten van ITIL (Information Technology and Infrastructure Library) aan de orde. ITIL is een door de Engelse overheid gesteunde opzet voor het organiseren van onderhoud en beheer. Hierbij heeft men vooral gekeken naar wat moet worden gedaan, zowel dagelijks, op langere termijn als structureel. Langs deze lijnen wordt vervolgens het onderhoud en beheer georganiseerd.

04_lewis_sdu

01-03-2006

11:51

Pagina 62

04_lewis_sdu

01-03-2006

11:51

Pagina 63

63

5

Producten van systeemontwikkeling

Producten van systeemontwikkeling zijn in de eerste plaats applicaties, maar daarnaast zijn er nog enkele andere producten te benoemen die vooral documenterend van aard zijn. Te noemen zijn: – informatieplan) – rapport definitiestudie – functioneel ontwerp – technisch ontwerp – sources – testdocumentatie in een aantal vormen, zoals: • module-, integratie- en systeemtest (technische tests) • acceptatietest • stress-, volume- en recovery-test – administratieve procedures – gebruikershandleiding – beheerdershandleiding. Al deze producten behoren tot het geheel dat applicatie heet. Dit houdt in dat ze gezamenlijk moeten worden onderhouden. Iedere wijziging moet ook in alle andere relevante documenten worden doorgewerkt.

applicatie

Alleen het informatieplan wordt op een andere manier onderhouden (ook beleidsveranderingen moeten hierin worden opgenomen), terwijl het rapport definitiestudie niet hoeft te worden onderhouden (het is een beslisdocument dat bij de totstandkoming een rol heeft gespeeld).

5.1 Applicatietypen

gebruiksomgeving hardware-omgeving

Applicaties (toepassingen) kunnen in een aantal verschillende typen worden onderverdeeld. Voor het begrip zijn hier twee indelingen van belang: – een indeling naar gebruiksomgeving (functionaliteit, waarvoor is de applicatie bedoeld?) – een indeling naar hardware-omgeving (techniek, voor welke ICTarchitectuur is de applicatie bedoeld?).

04_lewis_sdu

64

01-03-2006

11:51

Pagina 64


In het navolgende zal blijken dat deze twee indelingen niet onafhankelijk van elkaar zijn. Met andere woorden: functionaliteit en techniek zijn niet volstrekt onafhankelijk van elkaar.

5.2 Applicaties naar functionaliteit Een veel gebruikte indeling van applicaties is: – on line transaction processing (OLTP), een groot aantal administratieve toepassingen – kantoorautomatisering, tekstverwerking, datacommunicatie, multimedia – kennissystemen, kunstmatige intelligentie, beslissingsondersteuning – technische automatisering, procesindustrie, robotica. We zullen deze vier hier nader beschrijven en er voorbeelden van geven. OLTP Onder OLTP vallen veel van de bekende transactiesystemen die vooral in administratieve omgevingen worden gebruikt. Veel van deze systemen zijn ondersteunend aan het primaire bedrijfsproces in die zin dat ze de registratieve taken binnen dat proces ondersteunen en soms zelfs sturen. Bekende voorbeelden zijn boekhoudsystemen, verzekeringssystemen, klanten- en orderregistraties, en bancaire systemen. Deze systemen hebben alle een aantal karakteristieken gemeen: – transactiegericht Een transactie is een gedefinieerde set handelingen en gegevens die een geheel vormen dat nauw verwant is aan een taak in het bedrijfsproces zelf (een debetmutatie, een aanvraag voor verzekering, een bestelling) – gebruik van coderingen De relevante gegevens worden in gecodeerde vorm vastgelegd, waarbij diverse ondersteunende codetabellen zorgen voor een eenduidige vastlegging – vaste formaten De gegevens worden vastgelegd in (meestal) relationele databases, waarbij fysieke formaten van tevoren zijn vastgelegd – veel gegevens. De hele opzet is erop gericht tot eenduidige (en daardoor optelbare) vastleggingen te komen.

04_lewis_sdu

01-03-2006

11:51

Pagina 65


65

Kantoorautomatisering Kantoorautomatisering treft men vooral aan in kantooromgevingen waar individuele medewerkers ondersteund worden bij het uitvoeren van administratieve taken, zoals het verwerken van correspondentie en documenten. Daarnaast worden er veel managementrapportages en beleidsnota’s gemaakt waarbij gebruik wordt gemaakt van rekenmodellen en grafieken. De daarvoor benodigde gegevens worden opgehaald uit de OLTP-systemen. Deze systemen ondersteunen dus ook het primaire bedrijfsproces. Ze dragen rechtstreeks bij aan de producten van deze omgeving: correspondentie, nota’s, enzovoort. Historisch gezien is deze toepassingsvorm de bakermat van de PC. Typische toepassingen zijn onder andere tekstverwerkers, spreadsheets, applicaties voor het maken van afbeeldingen, schema’s en plaatjes. OLTP en kantoorautomatisering hebben in het algemeen grote aantallen gebruikers, ook binnen een organisatie. Kantoorautomatiseringstoepassingen hebben de volgende karakteristieken min of meer gemeenschappelijk: – altijd on line en real time (iedere toetsaanslag wordt door de CPU verwerkt – weinig structurering van gegevens en werkwijzen (individugericht, geen vaste fysieke formaten – veel gegevens. Tegenwoordig worden aan deze systemen workflow-managementsystemen toegevoegd, teneinde een al te grote vrijheid van de medewerkers en het daarmee samenhangende gebrek aan inzicht in de voortgang, in te perken. Kennissystemen Deze systemen treft men met name aan in omgevingen waar complexe beslissingen dienen te worden genomen en waarbij beslissers worden ondersteund door systemen die meer overzicht of parate kennis hebben dan de betrokkenen (kunnen hebben). Binnen de groep kennissystemen zijn verschillende subtypes te onderkennen: systemen waarin weinig gegevens en veel kennis (in de vorm van redeneermechanismen) zijn opgenomen, systemen met veel gegevens en weinig kennis (in de vorm van vaste rekenmodellen), en allerlei tussenvormen. Een voorbeeld van het eerste type zijn (medische) diagnoseondersteunende systemen, een voorbeeld van het tweede type vormen simulatiesystemen.

04_lewis_sdu

66

01-03-2006

11:51

Pagina 66


Karakteristieken zijn: – altijd on line en real time om snel te kunnen bijsturen of opnieuw te kunnen starten van bepaalde stukken – gericht op specifieke problemen – soms veel data en berekeningen (simulatie), soms juist niet (AI), sterk wisselende datastructuren en data-opslag. Over het algemeen bestaan de gebruikers van deze toepassingen uit kleine groepen, gespecialiseerde mensen. Technische automatisering Tot deze laatste categorie behoort een bonte verzameling van veelsoortige toepassingen, die zich snel uitbreidt, zowel wat betreft het aantal soorten toepassingen als het gebruik ervan. Ook de automatisering van de automatisering rekenen we hiertoe, zoals 4GL’s, CASE-tools (computer aided software engineering) en IPSE (integrated project support environment). CAD/CAM

De oudste typen toepassingen van technische automatisering zijn de CAD/CAM-systemen (computer aided design/manufacturing). Hierbij wordt met de computer (grafische en rekenkundige toepassingen) een ontwerp gemaakt (bijvoorbeeld auto-onderdelen), waarna met behulp van het in de computer opgeslagen model apparatuur wordt aangestuurd die de onderdelen vervolgens vervaardigt. Later is hier de besturing van robots en dergelijke aan toegevoegd. Men noemt dit type automatisering ook wel procesautomatisering. Deze vorm komt men met name tegen bij de besturing van complexe technische processen, zoals in raffinaderijen, kerncentrales en hoogovens. Kenmerkend hierbij is: verwerking van veel gegevens, veel berekeningen, snel, real time, weinig gegevensopslag, vaste structuren.

SAP/BAAN

Een andere, nieuwe ontwikkeling van dit type systemen zijn de SAP/BAAN-achtige toepassingen (logistieke systemen of enterprise resource planning, ERP), waarbij integratie met deelsystemen voor financiën, personeel, orderadministratie en productiebesturing plaatsvindt. Dit type toepassingen is in feite een mix van alle vier genoemde typen toepassingen. Ze zijn daardoor niet alleen als systeem zeer complex, ook de implementatie ervan is een omvangrijk en moeilijk traject. De nieuwste ontwikkeling die van veel invloed zal zijn op technische automatisering, is het gebruik van allerlei vormen van ‘embedded’ software (‘ingebouwd’ of ‘ingebakken’). Soms zijn dit volwaardige proces-

04_lewis_sdu

01-03-2006

11:51

Pagina 67


67

soren (bij antiblokkeer en antislipsystemen in auto’s en besturingssystemen van liften), soms zijn het goedkope wegwerpprocessoren (van een soort plastic) die geautomatiseerde herkenning mogelijk maken (voor het volgen van pakketjes bij de post, onderdelen van auto’s die periodiek moeten worden vervangen, enzovoort).

5.3 Applicatie naar type hardware-omgeving Als we applicaties onderscheiden naar de hardware-omgeving waarin ze operationeel zijn, dienen we eerst de vraag te beantwoorden wat we precies onder hardware-omgeving verstaan. Bedoelen we merken (IBM, Compaq-DEC, enzovoort)? Nee. Bedoelen we de grootte van de machines (mainframe, mini, PC)? Nee. We doelen bij hardware op de samenstelling en de functie van de hardwarecomponenten (de technische infrastructuur) waarop de applicatie draait. De opzet en aanleg van deze infrastructuur wordt vooral bepaald door de verwachtingen die men heeft omtrent de ontwikkeling en toepassingen van ICT in de organisatie. technische infrastructuur

Men kan de technische infrastructuur als volgt indelen: – enkelvoudige of klassieke omgeving – beperkte client/server-omgeving – Internet-omgeving. Enkelvoudige of klassieke omgeving Eigenlijk omvat deze klasse het gros van de huidige beschikbare applicaties, omdat zij het grootste deel van alle operationele applicaties omvat, namelijk de applicaties die op mainframe, mini of PC actief zijn. Presentatie, logica en data bevinden zich weliswaar niet altijd binnen de begrenzing van één fysieke doos (blik), maar de dozen vormen wel een logisch afgebakend geheel. De applicatie gedraagt zich als één geheel, één monolitisch blok. Presentatie, logica en data In de argumentatie zijn de volgende nieuwe begrippen binnengedrongen: presentatie, logica en data. Ze presenteren een indeling naar functionele componenten van een applicatie. Presentatie is dat deel dat aan de gebruiker beschikbaar wordt gesteld voor de communicatie tussen mens en machine, de mens-machine-interface, met alle elementen die daartoe (kunnen) behoren (beeldscherm, toetsenbord, printer, muis, windows, tekens, plaatjes).

04_lewis_sdu

68

01-03-2006

11:51

Pagina 68


Logica is de feitelijke verwerking van input naar output, de taken die de machine van de mens heeft overgenomen, zoals berekenen, tellen en controleren. Data zijn de permanent opgeslagen gegevens, of deze nu uit input afkomstig zijn of het resultaat zijn van bewerkingen. De beperkte client/server-omgeving Onder de beperkte client/server verstaan we de situatie waarin de softwarecomponenten van de enkelvoudige omgeving (presentatie, logica en data) niet meer in dezelfde ‘doos’ zijn opgeslagen, maar zich feitelijk in verschillende machines bevinden die onderling communiceren. Het geheel staat nog wel onder één centrale regie (zowel qua ontwerp als qua beheer). Meestal behoort het hele samenstel van componenten tot een en dezelfde organisatie. De Internet-omgeving Internet is ook een soort client/server-omgeving, maar hier ontbreekt een duidelijke centrale regie (er zijn een beperkt aantal, technische en inhoudelijke, spelregels, het is grensoverschrijdend en het is niet ‘ontworpen’, zeker niet als vervanger van de mens, zoals in de enkelvoudige omgeving). Het is vooral opgezet als aanvulling, als ondersteuning van communicatie (in de beperkte zin van het woord, oftewel gegevensoverdracht).

5.4 Recente ontwikkelingen ICT-branche

Alvorens dit hoofdstuk (en het boek) af te sluiten, staan we nog even stil bij de meer recente ontwikkelingen in de ICT-branche. Kenmerkend voor de recente ontwikkelingen is dat de hiervoor beschreven typen en grenzen vervagen. Er is sprake van een toenemende mate van integratie van verschillende technologieën binnen één toepassing. Dit bemoeilijkt het proces en maakt het product gecompliceerder, reden om zo mogelijk nog stringenter om te gaan met de mogelijkheden om kwaliteit te kunnen borgen. We behandelen het call centre, het datawarehouse, DIS, workflow management, groupware, mobiele communicatie en EDI. Call center Een afdeling of locatie waar computertelefoonintegratie (CTI) intensief door medewerkers wordt toegepast, wordt een call center genoemd. Een

04_lewis_sdu

01-03-2006

11:51

Pagina 69


69

call center wordt bijvoorbeeld bij banken en verzekeringen veel gebruikt voor telemarketing (directe verkoop van polissen), klantenservice (vragen over declaraties, verzekeringsvoorwaarden, enzovoort), hulpdiensten (alarmcentrale) of de helpdesk (elektronisch betalen). Het is een veelbelovende trend die echter nog enigszins belemmerd wordt door het ontbreken van échte integratie van telefonie, datacommunicatie en systeemontwikkeling. Datawarehousing- en mining Een datawarehouse (letterlijk: gegevenspakhuis) is een grote hoeveelheid gegevens uit zowel interne als externe bronnen. Kenmerkend is dat deze gegevens systematisch worden verzameld, bewerkt, gegroepeerd en gecombineerd tot doelgerichte informatie. Daar waar voorheen toepassingen als executive information systems (EIS), decision support systems (DSS), structured decision systems (SDS) en managementinformatiesystemen (MIS) nog hun eigen gegevensverzamelingen opbouwden, wordt dat nu centraal gedaan. Datawarehousing is wat dat betreft een typische toepassing van het client/server-concept. Vaak gold voor dit soort systemen dat de gebruiker zijn vragen exact moest kunnen formuleren, maar wordt dit steeds minder nodig door de komst van zoekmachines. search engines

Dergelijke zoekmachines (search engines) zijn een kenmerkend bestanddeel van datamining. De programmatuur is in staat automatisch verbanden te leggen of patronen te herkennen en te presenteren. Hierdoor vertoont datamining gelijkenis met kennistechnologie. Het zal duidelijk zijn dat de kwaliteit van de resultaten net zo goed is als de kwaliteit van de gegevens in de operationele, registratieve systemen. Datawarehousing/-mining kan een belangrijke bijdrage leveren aan een slagvaardige en snelle reactie op ontwikkelingen in de markt. Het deel Bestuurlijke informatie in organisaties in deze reeks gaat uitgebreid in op organisatietypen en -functies, en besturing in relatie tot (management)informatie. Documentaire informatiesystemen

DIS

Een documentair informatiesysteem (DIS) heeft tot taak om interne en externe informatie, opgenomen in elektronische of gedrukte documenten, te selecteren, te beheren, te ontsluiten, toegankelijk te maken en beschikbaar te stellen aan de organisatie. Van een DIS bestaan verschil-

04_lewis_sdu

70

01-03-2006

11:51

Pagina 70


lende vormen. Scanning, optical character recognition (OCR), zorgt ervoor dat teksten, tekeningen, foto’s en dergelijke elektronisch worden herkend en opgeslagen. Zoek- en archiefsystemen zorgen ervoor dat de documenten gemakkelijk getransporteerd, bewaard en ontsloten kunnen worden. Belangrijkste voordeel is de verbetering van de kwaliteit en efficiëntie. Hoewel deze technologie reeds geruime tijd op de markt is, verschilt de mate van toepassing per branche enorm. Electronic data interchange EDI

Electronic data interchange (EDI) is de elektronische uitwisseling van gestructureerde en genormeerde gegevens tussen computers van bij transacties betrokken partijen, waarbij geen sprake is van menselijke tussenkomst. EDI wordt veel toegepast voor elektronische artikelinformatie, bestellingen, facturen en dergelijke. Er zijn enkele internationale standaarden ontwikkeld voor de structuur van EDI-berichten. EDIFACT (electronic data interchange for administration and transport) is de bekendste en meest toegepaste standaard. ODETTE is een standaard voor de automobielindustrie, INTIS voor de Rotterdamse haven, Cargonaut voor het luchtvrachtverkeer op Schiphol en SAGITTA voor de invoeraangiften voor de douane. Daarnaast zien we ook wel dat twee partijen eigen afspraken maken over de uit te wisselen gegevens. Afspraken worden veelal vastgelegd in een interchange agreement. EDI is er al sinds de jaren zeventig. De populariteit verschilt sterk per branche. Grote voordelen zijn: de snelheid van verzending en verwerking van berichten met ‘just in time’ tot gevolg, strategisch voordeel, vergroting van de efficiëntie en effectiviteit en een continue beschikbaarheid. Nadeel is echter de grote afhankelijkheid van de leverancier, de techniek en de wetgeving die nog niet aan deze nieuwe werkwijze is aangepast. Groupware Groupware is een verzamelnaam voor de geautomatiseerde ondersteuning van de samenwerking tussen mensen, ongeacht plaats en tijd. Meer concreet betreft het: agendabeheer, (video)conferenties, overdracht en gezamenlijke bewerking van documenten, (elektronische) communicatie en afstemming, brainstorming en ondersteuning van kennismanagement. Groupwise van Novell, Exchange van MicroSoft en Lotus Notes van IBM zijn voorbeelden hiervan.

04_lewis_sdu

01-03-2006

11:51

Pagina 71


71

Groupware draagt bij tot verbetering van de communicatie, de samenwerking en de sturing van het werk. Verwacht wordt dat deze functionaliteit opgenomen zal worden binnen andere trends. Workflow management WFM

Workflow management (WFM) is het geautomatiseerde beheer van uit te voeren taken volgens een vooraf gedefinieerde routing van werkstromen, zodanig dat de juiste functionarissen op de juiste tijd op de meest geschikte plaats worden uitgevoerd. WFM omvat de sturing, coördinatie en bewaking van de werkstromen binnen de (veelal administratieve) procesgang. WFM wordt gebruikt voor het verbeteren van de efficiëntie of effectiviteit (bijvoorbeeld doorlooptijdverkorting). Soms wordt het ook toegepast in combinatie met het optimaliseren of herontwerpen van bedrijfsprocessen (business process redesign of re-engineering), met als doel kwaliteitsverbetering. Veelal wordt bij WFM dankbaar gebruikgemaakt van een documentaire informatiesysteem. Er is een trend waarneembaar dat WFM onderdeel gaat uitmaken van ERP-pakketten. Het lijkt erop dat WFM de komende jaren een doorbraak zal maken. Mobiele communicatie Telefoneren, faxen, e-mailen en eventueel netwerken op een willekeurige plaats, binnen of buiten de eigen organisatie, wordt mobiele communicatie genoemd. Piepers, draadloze telefoons en netwerken, semafoons en buzzers, GSM-telefoons en personal digital assistants zijn voorbeelden van te koppelen apparatuur. Het via radiofrequentie aansturen van vorkheftrucks is een voorbeeld van een draadloos netwerk. Deze systemen bewaren vrijwel geen data (alleen voor store and foreward protocollen), maar houden zich vooral bezig met de besturing van het netwerk en het routeren van boodschappen.

5.5 Type toepassing en type ontwikkelmethode Het moge duidelijk zijn dat de verschillende typen hardwareomgevingen niet geschikt zijn voor alle typen applicaties naar functionaliteit, zoals in de paragrafen 5.2 en 5.3 is beschreven. Evenzo is niet iedere methode van ontwikkeling en invoering geschikt voor ieder type toepassing.

04_lewis_sdu

72

01-03-2006

11:51

Pagina 72


Het volgende schema (5.1) is een hulpmiddel voor het bepalen van de meest wenselijke methode. Het brengt de relatie in beeld tussen typering van applicaties (toepassingen) en benaderingswijzen (denkwijzen).

–––

|

Type toepassing OLTP kantoor intelligent technisch

–––

|

Denkwijze proces, gegevens communicatie, verandering, organisatie doel/functie, gegevens gedrag, proces

Tabel 5.1 Denkwijze per applicatietype, naar toepassing en hardwareomgeving

De volgende tabel (5.2) geeft de relatie weer tussen denkwijzen (hoofdstuk 2) en werkwijzen (hoofdstuk 3).

–––

|

Denkwijze organisatie communicatie doel/functie proces gegevens gedrag verandering

–––

|

Werkwijze evolutionair, cyclisch, prototyping prototyping, evolutionair incrementeel, evolutionair, prototyping lineair, evolutionair, incrementeel lineair, incrementeel prototyping, cyclisch evolutionair, prototyping, cyclisch

Tabel 5.2 Werkwijzen per denkwijze

We kunnen de twee voorgaande tabellen met elkaar combineren om tot een relatie tussen het type applicatie (naar toepassing) en de best passende werkwijze te komen.

–––

|

Type toepassing OLTP kantoor intelligent technisch

–––

|

Werkwijze lineair, incrementeel evolutionair, prototyping, cyclisch incrementeel, prototyping, evolutionair lineair, prototyping, cyclisch, incrementeel

Tabel 5.3 Werkwijze per applicatietype, naar toepassing

04_lewis_sdu

01-03-2006

11:51

Pagina 73


hardware-omgeving

73

Als we in dit overzicht ook nog het type hardware-omgeving willen betrekken, zullen we ons eerst moeten afvragen of en in welke mate deze omgeving van invloed is op de te hanteren denken werkwijze. In een enkelvoudige omgeving hebben we alles zelf in de hand en kunnen we ons houden aan de in tabel 5.3 gemaakte indeling. In C/S-omgevingen is dit feitelijk niet anders, alle componenten vallen immers onder de centrale regie. Bij Web-technologie is het anders: binnen de Internet-standaards kunnen anderen gebruikmaken van de door ons beschikbaar gestelde faciliteiten en kunnen zij gegevens in onze applicatie aanbrengen of wijzigen. Dit heeft tot gevolg dat wat we aanbieden compleet moet zijn. Het is (beveiliging) riskant om faciliteiten open te stellen die niet zijn afgerond. Hierdoor komt evolutionair als aanpak te vervallen, evenals prototyping. Anderzijds hebben we ook te maken met de vraag welke van de typen applicaties redelijkerwijs als Web-technologie zullen worden aangeboden. Het aanbieden van OLTP-toepassingen is nu nog lastig, maar zeker op enige termijn uitvoerbaar. Kantoorautomatisering kan zeker, net zoals kennissystemen, terwijl technische automatisering niet zinvol lijkt (zeer omgevingsspecifieke toepassingen). Aldus ontstaat het volgende overzicht (tabel 5.4), dat tevens het vertrekpunt van het volgende deel over ontwikkelmethoden is.

––– Type omgeving

|

Enkelvoudig

C/S

Internet

Type toepassing OLTP

[ incrementeel of lineair

kantoor

[ n.v.t.

intelligent

] [ incrementeel? ] [ pakketselectie

]

[ incrementeel/prototyping/cyclisch

technisch

[ incrementeel/prototyping/evolutionair

]

] ] [ n.v.t.

]

–––

|

Tabel 5.4 Werkwijze per applicatietype, naar toepassing en hardwareomgeving

Tabel 5.4 ontstaat uit een combinatie van tabel 5.3 en bovenstaande overwegingen, waarbij de meest voorkomende werkwijze is overgenomen. Uiteraard is de tabel niet meer dan een globale indicatie van de te kiezen werkwijze. Niettemin zijn enkele interessante zaken op te merken.

04_lewis_sdu

74

01-03-2006

11:51

Pagina 74


Lineaire ontwikkeling blijkt alleen nog voor OLTP, in de meer klassieke vorm, een zinnig alternatief te zijn. Of OLTP ook zinnig in een Internet-omgeving kan worden gerealiseerd, valt (nu) nog te bezien. Voor alle andere toepassingen zijn meer iteratieve processen handiger. Deze hebben gemeen dat er met kleinere te realiseren eenheden wordt gewerkt, die sneller realiseerbaar zijn. Kantoorautomatisering in een mainframe-omgeving is geen haalbare kaart bij grotere aantallen gebruikers tegelijk. In meer decentrale omgevingen werkt kantoorautomatisering wel. Er bestaat in dat geval wel behoefte aan een kader en ook een goede aansluiting op de dagelijkse praktijk telt dan zwaar (prototyping, cyclisch). Aangezien deze markt op dit moment zwaar gedomineerd wordt door één aanbieder, die één geïntegreerd standaardpakket aanbiedt, is ontwikkelen in de gebruikelijke zin van het woord eigenlijk niet aan de orde. Intelligente systemen, met hun specialistische gebruikers, laten zich niet in één keer ontwerpen en bouwen. Vanuit een kader (incrementeel) worden telkens nieuwe mogelijkheden geprobeerd (prototyping) en aan het geheel toegevoegd (cyclisch). Procesautomatisering via een Internet-achtige infrastructuur lijkt niet direct voor de hand te liggen; dit zijn zeer specifieke systemen voor een speciaal doel. Naast het hanteren van standaarden (incrementeel), zijn er vaak unieke problemen op te lossen (evolutionair), waarvan de oplossing op voorhand niet duidelijk is en zal moeten worden uitgeprobeerd (prototyping).

Samenvatting Dit laatste hoofdstuk van het boek behandelt de resultaten van systeemontwikkeling, enerzijds in algemene termen, anderzijds aan de hand van verschillende soorten feitelijke toepassingen. applicatie

Naast de applicatie zelf levert systeemontwikkeling ook allerhande documentatie op die, tezamen met het systeem, moet worden onderhouden. Genoemd worden onder andere het FO, het TO, de handleidingen en de procedurebeschrijvingen.

technische vormgeving

De applicaties worden ook getypeerd naar hun technische vormgeving. De typen die worden onderscheiden zijn OLTP, kantoorautomatisering, intelligente systemen en procesautomatisering.

04_lewis_sdu

01-03-2006

11:51

Pagina 75


75

soort netwerk

Daarnaast wordt gekeken naar het soort netwerk, dat in drie hoofdtypen wordt opgesplitst: de monolitische, centrale systemen, de C/S-architectuur en de Web-technologie.

nieuwe applicatievormen

Vervolgens wordt een aantal nieuwe applicatievormen behandeld, zoals documentaire informatiesystemen (DIS), CAD/CAM, datawarehouse en datamining, EDI en mobiele applicaties. Veel van deze nieuwe ontwikkelingen kenmerken zich doordat meerdere technieken, die vroeger apart werden gebruikt, nu geïntegreerd in een enkele applicatie voorkomen. Niet voor niets zijn de nieuwe Intell-processoren standaard uitgerust met technieken voor ondersteuning van multimedia (MMX). Het hoofdstuk wordt besloten met de aanzet tot een meer systematische beantwoording van de vraag: welke denken werkwijze is nu het meest geëigend voor welk type applicatie? Er wordt een eerste versie gegeven van een tabel die antwoord geeft op deze vraag en tevens het vertrekpunt is van deel 2 van Innovatief informatiseren, dat handelt over methoden, technieken en tools.

04_lewis_sdu

76

01-03-2006

11:51

Pagina 76


04_lewis_sdu

01-03-2006

11:51

Pagina 77

77

Literatuurlijst

Kamp, R. van der en Praat, J. van, Gebruik van Informatietechnologie, Kluwer Bedrijfsinformatie 1997, ISBN 90 267 2178 1 Kamp, R. van der, Projectmatig werken, Kluwer Bedrijfsinformatie 1997, ISBN 90 267 2177 3 Lewis, R., Organisatie en systeemontwikkeling, Kluwer Bedrijfswetenschappen 1993, ISBN 90 267 1805 5 Lewis, R. en Poel, B. van der, Ontwikkeling en beheer van Informatiesystemen, 2e druk, Kluwer Bedrijfsinformatie 1998, ISBN 90-267-2176-5 Noordam, P. en Vlist, A. van der, Trends in Informatie Technologie en de gevolgen daarvan voor organisaties, Kluwer Bedrijfsinformatie 1997, ISBN 90 267 2590 6 Veld, S.F.N. van ’t (red.), 16 methoden voor systeemontwikkeling: een vergelijkend rapport van de NGGO, Tutein Nolthenius 1990 Verhagen, J. en Kamp, R. van der, Hardware en software, Kluwer Bedrijfsinformatie 1997, ISBN 90 267 2182 X Vlasblom, G., Rijsenbrij, D.B.B. en Delen, G.A.J., Producten van systeemontwikkeling, Cap Gemini Publishing 1991, ISBN 90 71996 36 0 Wal van der, Bart, ‘Watervalmethode ingehaald door incrementele aanpak’, Computable, 2 oktober 1992 Wanders, A.G.M., ‘Methoden-oerwoud in kaart gebracht?’, Computable, jrg. 24, 8 maart 1991 Wanders, A.G.M., ‘Methoden: noodzaak tot modernisering’, BIKMAG (Bestuurlijk Informatiekundig Magazine van de Technische Universiteit Eindhoven), jrg. 3, nr. 7, juni 1992, blz. 9-12 Wanders A.G.M., Systeemontwikkelingsmethoden: vergelijken en kiezen, Academic Service, 1989

04_lewis_sdu

01-03-2006

11:51

Pagina 78

04_lewis_sdu

01-03-2006

11:51

Pagina 79

Register

79

Register

3GL 37-38 4GL 66 abstractieniveau 32 acceptatietest 53 activiteit 16 analyse 13, 51 ANSI/SPARC 18, 23-24 applicatie 63 ∼-architectuur 50 ∼typen 63, 72-73 attributen 20 attribuuttypen 20 attribuutwaarden 21 availability management 59 beheer 8, 58 benaderingswijzen 7, 11 beslissingstabel 27 betekenis 22 boodschap 22, 31 bottom-up 7, 32, 50 bouw 8, 51-52 BPR 14-15 broncode 53 bulldozermethode 35 CAD/CAM 66 call center 68 capacity management 59 CASE-tool 36, 66 CBDB 59 centre-out 7, 33 centre-out-aanpak 40 change management 60

CI 59 client/server-omgeving 68 coderen 53 codes 21 cold turkey 55 communicatiebenadering 12 conceptueel niveau 24-25 configuratie-items 59 configuratiebeheerdatabase 59 configuration management 59 constraints 26 contingency management 59 conversie 8, 54, 57 cyclisch 39 data 19, 67 data dictionary 25 datamining 69 datawarehousing 69 DD/DS 25 deelfasen 45 deelproducten 45 definitiestudie 51 denkwijzen 7, 9, 11, 50, 72 detailniveau 32 dialoogmodel 28 DIS 69 documentair informatiesysteem 69 doel-functiebenadering 12 doelstellingen 6, 12 domein 21 drielagenmodel 18, 23-24 DSS 69 dynamische eigenschappen 47

04_lewis_sdu

80

01-03-2006

11:51

Pagina 80


EDI 70 EDIFACT 70 eigenschappen: dynamische ∼ 47 statische ∼ 47 EIS 69 eisen: functionele ∼ 47 prestatie-∼ 48 electronic data interchange 70 encapsulation 31 enkelvoudige omgeving 67 entiteit 20 ERP 66 evolutionair 40 exploitatie 58 extern niveau 25 fasering 7 FO 52 foutherstel 54 functioneel ontwerp 52 functionele eisen 47 funtionele specificaties 52 FUSP 52 fysiek niveau 24 gebruik 8, 58 gebruiksomgeving 63 gedragsbenadering 13 gedragsmodel 27-28 gedragsmodellering 26 gefaseerd ontwikkelen 34 gefaseerde invoering 55 gegevens: ∼benadering 13 ∼huishouding 49 ∼model 19 ∼modellering 18 groupware 70 haalbaarheidsonderzoek 51 hardware-omgeving 63, 73 helpdesk 60

hertest 54 hulpmiddelen 7 ICT 14 ICT-infrastructuur 49 implementatie 54 increment 39 incrementeel 39 informatie: ∼behoefte 50 definitie 5 doel 6 ∼-infrastructuur 49 ∼managers 49 ∼plan 49-50 information/gegevens 19 information hiding 31 ingebruikneming 57 inheritance 30 inhoud 22 inkapseling 31 input 16 integrale benadering 32 integratietest 53 intern niveau 25 Internet-omgeving 68 internetten 43 intranetten 43 invalshoeken 6, 31, 33 invoering 8, 54 invoerstrategieën 55 IPSE 66 ISAC 15 ISO 18 IT-infrastructuur 59 iteratief 39 ITIL 58 kantoorautomatisering 65 kennissystemen 65 klassen 30 klassieke omgeving 67 knowlegde/informatie/kennis 19 kwaliteitsmanagement 46

04_lewis_sdu

01-03-2006

11:51

Pagina 81

Register

kwaliteitszorg 46 lineair 35 logica 67 logisch niveau 24

organisatiebenadering 11 output 16 overerving 30

MAD 42 management 59 message 31 methode, bouwstenen 6 middle-out, zie centre-out MIS 69 mobiele communicatie 71 model 10 dialoog∼ 28 drielagen∼ 18, 23-24 gedrags∼ 27-28 gegevens∼ 19 proces∼ 17 rugby∼ 40 waterval∼ 35-36 modellering 18, 26

permanent onderhoud 37 postcondities 28 precondities 28 predikaat 23 presentatie 67 prestatie-eisen 48 primaire zoeksleutels 26 proces 15-16, 59 ∼beheersing 46 ∼benadering 13 ∼model 17 ∼modellering 15 productbeheersing 47 programmabibliotheek 60 programmatuurbeheer 60 programmatuurdistributie 60 propositie 23 prototyping 36

network service management 60 NIAM 23 niveaus 24-25, 32 notatiewijzen 9, 26

RAD 42 relationship-type 20 repository 25 rugbymodel 40

object 30 ∼identificatie 30 ∼oriëntatie 29 OLTP 26, 64 omgeving 38, 54, 63, 67, 73 on line transaction processing 26, 64 onderhoud 58 permanent∼ 37 ondersteuning 58 onderzoek 51 ontwerp 8, 51, 51 ontwikkeling, definitie 5 ontwikkelmethoden, typen 71 OO 29 opleiding 54, 56 organisatie, ∼ van systeemontwikkeling 7

SAP/BAAN 66 scenario-aanpak 7 schaduwdraaien 55 SDS 69 search engines 69 service level management 59 source coding 53 specificaties 36 standaardpakketten 41-42 statische eigenschappen 47 structuur 11, 13 systeemontwikkeling, organisatie 7 systeemtest 53 systems life cycle 8, 45 technieken 7 technisch ontwerp 52

81

04_lewis_sdu

82

01-03-2006

11:51

Pagina 82


technische automatisering 66 technische infrastructuur 67 testen 51 testscript 53 time box 46 TO 52 toepassingen, typen 71 toestand 27 toestandsovergang 27 tools 7 top-down 7, 32, 50 veranderingsbenadering 13 vooronderzoek 51 voorwaarden 27

watervalmodel 35 werkwijzen 6, 9, 35, 45, 50, 72 WFM 71 workflow management 71 Yourdon 15, 31 zevenkleurige bril 11, 55 zoekmachines 69 zoeksleutels 26

Innoverend informatiseren Aanpak en werkwijze van informatiesysteemontwikkeling

Recommend Documents