Inhoud leereenheid 2. Systemen en systeemontwikkeling. Introductie 43. Leerkern 44. Samenvatting 71. Zelftoets 72

Inhoud leereenheid 2

Systemen en systeemontwikkeling Introductie Leerkern 1

43 44

Wat zijn informatiesystemen? 44 Huisartsinformatiesysteem 46 1.2 Computerspel 49 1.3 Betaalautomaat 50 1.4 Industriële robot 52 1.5 Soorten informatiesystemen 53 Informatiesystemen ontwikkelen 55 2.1 Een mislukking 56 2.2 De softwarecrisis 57 2.3 De watervalmethode 59 2.4 Iteratief ontwikkelen: het Unified process Modellen en modelleren 67 Vooruitblik 70 1.1

2

3 4

Samenvatting Zelftoets

71

72

Terugkoppeling 1 2

42

73

Uitwerking van de opgaven 73 Uitwerking van de zelftoets 76

65

Leereenheid 2

Systemen en systeemontwikkeling

INTRODUCTIE

Deze leereenheid geeft een introductie tot de ontwikkeling van informatiesystemen. We beantwoorden eerst de vraag wat een informatiesysteem eigenlijk is. Vermoedelijk hebt u daar wel een beeld van; we hebben er uiteindelijk allemaal dagelijks mee te maken. Om dat beeld aan te scherpen, bekijken we in de eerste paragraaf vier voorbeelden: een huisartsinformatiesysteem, een computerspel, een betaalautomaat en een industriële robot. Bij elk van die systemen vragen we ons af in hoeverre we te maken hebben met een informatiesysteem. De ontwikkeling van informatiesystemen is een van de belangrijkste toepassingen waar informatica zich mee bezighoudt. Aan de ene kant is het een zeer succesvolle toepassing: we hebben het hele maatschappelijke functioneren ervan afhankelijk gemaakt (denk aan de doemscenario’s die geschetst werden toen men vreesde dat bij de millenniumwisseling veel van deze systemen uit zouden vallen). Aan de andere kant valt dat succes ook weer tegen. In het klein kent iedereen die regelmatig met een computer werkt, de frustratie van vastlopende programma’s en van onbegrijpelijk gedrag. In het groot lijden informatiesystemen aan hetzelfde euvel als grote infrastructurele projecten: ze worden meestal te laat en met grote kostenoverschrijdingen opgeleverd. Soms worden ze zelfs helemaal niet opgeleverd. Hoe dat komt en wat de informatica aandraagt om daar verandering in te brengen, bekijken we in paragraaf 2. Bij informatiesysteemontwikkeling blijkt modelleren een belangrijke rol te spelen. Informatiesysteemontwikkelaars zijn allereerst modelbouwers. In paragraaf 3 bekijken we wat dat voor modellen zijn en welke rol ze spelen. Tot slot geven we in paragraaf 4 een vooruitblik op de volgende leereenheden van dit blok waarin systeemontwikkeling centraal staat. LEERDOELEN

Na het bestuderen van deze leereenheid wordt verwacht dat u – informele omschrijvingen kunt geven van de begrippen systeem, informatiesysteem en informatie – kunt uitleggen waarom een informatiesysteem niet altijd deels of volledig geautomatiseerd hoeft te zijn en in verband daarmee het belang van het afbakenen van systeemgrenzen kunt aangeven – kunt omschrijven wat de specifieke kenmerken zijn van administratieve informatiesystemen, real-timesystemen, gedistribueerde systemen, ingebedde systemen en kritische systemen

OU

43

Inleiding informatica

– kunt aangeven wat bedoeld wordt met de softwarecrisis en enkele factoren kunt noemen die bijdragen tot het ontstaan en de voortduring van deze crisis – een beschrijving kunt geven van systeemontwikkeling volgens de watervalmethode en het doel kunt aangeven van de analyse-, ontwerpen implementatiefase – de belangrijkste kenmerken kunt noemen van systeemontwikkeling volgens het Unified process en kunt aangeven wat de voordelen zijn van iteratieve ontwikkelmethoden boven de watervalmethode – kunt aangeven welke rol onderhoud speelt in de levensloop van een informatiesysteem – kunt omschrijven wat een model is en welke rol modellen spelen in systeemontwikkeling – de betekenis kunt geven van de volgende kernbegrippen: software engineering, methoden, technieken, voortraject, bedrijfsmodellering, informatieanalyse, specificatie, eisendocument, domein. Studeeraanwijzing De studielast van deze leereenheid bedraagt circa 5 uur.

LEERKERN 1

Wat zijn informatiesystemen?

Wat is eigenlijk een informatiesysteem? We gaan dat in deze paragraaf onderzoeken aan de hand van een aantal voorbeelden. De bedoeling van die voorbeelden is laten zien hoe sterk zulke systemen uiteenlopen en vast stellen met welke aspecten ervan we ons in deze cursus wel en met welke we ons niet bezig zullen houden. Als uitgangspunt nemen we de volgende (vrij informele en zeer ruime) definities van de begrippen systeem en informatiesysteem. Systeem

Definitie

Een systeem is een verzameling componenten die samenwerken om bepaalde doelen te verwezenlijken. Systemen kunnen zeer eenvoudig zijn (een balpen) of zeer complex (een vliegtuig). Complexe systemen bevatten meestal delen die zelf ook systemen zijn (bijvoorbeeld de motoren en het navigatiesysteem). Een systeem is dus vaak opgebouwd uit deelsystemen.

Definitie

Een informatiesysteem onderscheidt zich van andere systemen doordat de doelen van het systeem uitsluitend bereikt worden door het bewerken van informatie. Een informatiesysteem ontvangt invoer en produceert uitvoer; beide bestaan uit symbolen (zie figuur 2.1).

Deelsysteem Informatiesysteem

FIGUUR 2.1

44

OU

Zeer eenvoudige weergave van een informatiesysteem

Leereenheid 2 Systemen en systeemontwikkeling

Voorbeeld

Informatie als betekenisvolle gegevens

Balpennen en vliegtuigen zijn dus geen informatiesystemen, want ze zijn niet op een voor de hand liggende manier in dit schema in te passen. Het navigatiesubsysteem van het vliegtuig is dat wel: het ontvangt informatie over de positie van het vliegtuig en de te volgen koers en produceert besturingsinformatie voor de motoren. Wat is eigenlijk informatie? Ook hier willen we niet al te formeel zijn. We vatten informatie op als gegevens die een betekenis hebben voor de mensen die bij het systeem betrokken zijn. We spreken alleen van een informatiesysteem als die betekenis binnen het systeem een rol speelt.

Voorbeeld

Bij het opnemen van geld uit een geldautomaat worden gegevens uitgewisseld tussen de bank en de geldautomaat. De beheerders van het communicatienetwerk tussen automaten en banken moeten ervoor zorgen dat die gegevens foutloos over dat netwerk verstuurd kunnen worden. Voor hen speelt de betekenis eigenlijk geen rol: wat voor de bank en de klant bedragen zijn, kunnen zij heel goed behandelen als inhoudsloze bitpatronen die goed op de plaats van bestemming aan moeten komen. Zo’n netwerk opzetten en beheren kan zonder inhoudelijke kennis van het betalingssysteem (zolang de beheerders maar weten dat onontdekte transmissiefouten onacceptabel zijn en dat er mensen kunnen zijn die belang hebben bij een inbraak in het systeem). Het communicatienetwerk op zich noemen we dan ook geen informatiesysteem. We bekijken een aantal voorbeeldsystemen en vragen ons daarbij af in hoeverre die systemen informatiesystemen zijn. We onderzoeken dat aan de hand van drie vragen.

Vraag 1

Wie zijn er betrokken bij het systeem en wat zijn hun doelen?

Toelichting

Een belangrijk aspect van de eerder gegeven definitie is dat een systeem bepaalde doelen dient. Die doelen zijn niet van het systeem, maar van belanghebbenden, van mensen dus. Een doel bestaat niet op zichzelf, maar is altijd een doel voor een persoon of een groep personen. Hetzelfde systeem kan voor verschillende belanghebbenden verschillende doelen hebben.

Vraag 2

Welke informatie speelt een rol bij het systeem en wat doet het systeem daarmee?

Toelichting

Het meest wezenlijke aspect van een informatiesysteem is het bewerken van informatie. Een informatiesysteem ontvangt invoer en produceert uitvoer.

Vraag 3

Welke mensen en welke middelen (apparatuur en programmatuur) behoren tot het systeem?

Toelichting

Omdat dit een cursus op het gebied van informatica is, denken we bij een informatiesysteem al snel aan een volledig geautomatiseerd systeem. Ook die aanname is echter een onderzoek waard. De telefonische inlichtingendienst van KPN fungeert voor de beller als informatiesysteem, met als doel het achterhalen van een telefoon- of faxnummer van een bepaalde persoon. Vanuit de bellers bezien, behoort de telefonist die de oproep beantwoordt, tot het systeem. Het maakt voor de bellers niet uit

OU

45


of de telefonist het gevraagde nummer uit een computer of uit een telefoonboek haalt; het zou vreemd zijn om in het ene geval wel maar in het andere geval niet van een informatiesysteem te spreken. Het maakt voor het bereiken van het doel ook niet uit of de oproep beantwoord wordt door een mens of door een spraakcomputer (mits die spraakcomputer goed genoeg is en het doel van de bellers alleen het achterhalen van het nummer is en niet bijvoorbeeld het maken van een praatje). Bij een informatiesysteem kunnen dus kennelijk zowel mensen, dingen (in dit voorbeeld telefoonboeken) als apparatuur en programmatuur betrokken zijn. Aan de hand van deze drie vragen bekijken we de volgende vier voorbeeldsystemen: – een informatiesysteem voor huisartsen – een computerspel – een betaalautomaat – een industriële robot. Alle informatiesystemen hebben met elkaar gemeen dat ze doelen van belanghebbenden bereiken door het bewerken van informatie. Maar verschillende informatiesystemen kunnen verschillende kenmerkende eigenschappen hebben, waardoor we informatiesystemen in categorieën kunnen indelen. 1.1

Huisartsinformatiesysteem (HIS)

HUISARTSINFORMATIESYSTEEM

Als eerste voorbeeld bekijken we een huisartsinformatiesysteem (HIS). Een HIS bestaat uit een of meer computers waarop een computerprogramma draait dat een huisarts ondersteunt bij het beheren van zijn praktijk. Een belangrijke taak van het systeem is het beheren van patiëntgegevens. Voor elke patiënt beheert het systeem een elektronisch medisch dossier, waarin zaken als medische handelingen, voorgeschreven medicijnen en correspondentie met/over de patiënt worden geregistreerd. Een tweede belangrijke functie van het systeem is het beheren van afspraken in een agenda. Dat kan op verschillende manieren. De huisarts zelf gebruikt een eenvoudige daglijst waarop alle afspraken met patiënten op een bepaalde dag staan. De assistent gebruikt een uitgebreide versie van de agenda waarin afspraken gemaakt, verzet en geannuleerd kunnen worden, of voor een bepaalde patiënt een reeks afspraken gepland kan worden. Ten slotte ondersteunt het systeem ook de financiële taken in de huisartsenpraktijk, zoals facturen aanmaken en automatische incasso’s verwerken. We onderzoeken de doelen van het systeem met behulp van de drie vragen. Wie zijn er betrokken bij het systeem en wat zijn hun doelen? De huisarts is de eerste betrokkene bij het systeem. Het doel van de huisarts kan globaal worden omschreven als het doelmatiger organiseren van de praktijk.

46

OU


Naast de huisarts is de assistent een directe gebruiker van het systeem. Ook de assistent wil dat het systeem de werkzaamheden op een goede manier ondersteunt. Als het systeem voor de huisarts een grote verbetering betekent, maar voor de assistent lastig te gebruiken is, dan is dat hopelijk voor de huisarts aanleiding om een ander systeem aan te schaffen. De patiënt is geen directe gebruiker van het systeem, maar wel een belanghebbende, met doelen die deels wel en deels niet parallel lopen met die van de huisarts. Zowel de huisarts als de patiënt heeft belang bij het feit dat de informatie die over de patiënt bewaard wordt, correct is. De patiënt is meestal ook gebaat bij volledigheid, maar daarop zijn uitzonderingen (een patiënt kan een verslavingsverleden bijvoorbeeld liever buiten het dossier houden). Verder heeft de patiënt een groot belang bij het bewaken van de privacy, wat betekent dat de gegevens niet toegankelijk zijn voor anderen dan de betrokken huisarts. We zien hoe belangrijk het is om bij de doelen van een systeem altijd ook te bekijken voor wie die doelen van belang zijn. Verschillende betrokkenen kunnen verschillende doelen hebben. Welke informatie speelt een rol bij het systeem en wat doet het systeem daarmee? Uit de beschrijving van het systeem blijkt dat het systeem informatie beheert over patiënten (medische dossiers), afspraken en betalingen. Die informatie wordt ingevoerd door de huisarts en de assistent. Op verzoek wordt relevante informatie op het scherm getoond en/of afgedrukt. Hieruit blijkt dat binnen het HIS het bewaren en beheren van informatie centraal staat. Het systeem slaat ingevoerde informatie op en presenteert deze op een voor de gebruikers aantrekkelijke en doelmatige manier wanneer daarom gevraagd wordt. Merk daarbij op, dat voor het bereiken van het doel van het systeem die presentatie net zo belangrijk is als de opslag. Een systeem dat gegevens prima opslaat en beheert, maar waar ze alleen als een ongeordende brei weer uit te halen zijn, mist zijn doel. Welke mensen en welke middelen (apparatuur en programmatuur) behoren tot het systeem? Het systeem bestaat uit een programma dat draait op een of meer computers, met randapparatuur zoals printers en scanners. Het systeem is daarmee een voorbeeld van een volledig geautomatiseerd informatiesysteem. Toch is daarmee nog niet het hele verhaal verteld. We noemden het voorbeeld van de inlichtingendienst van KPN en merkten op dat vanuit de bellers gezien de telefonist deel uitmaakt van dit systeem. Hoe zit dat hier, als we vanuit de patiënt kijken? Deze komt naar de huisarts voor een gesprek over een medisch probleem, uitmondend in een advies en eventueel een recept voor het gebruik van bepaalde medicijnen of een doorverwijzing. Vanuit de patiënt gezien kunnen we de volledige praktijk daarom opvatten als een informatiesysteem, waarvan de huisarts, de assistent en het HIS allemaal deel uitmaken. Het geautomatiseerde deel is daarbij voor de patiënt relatief onbelangrijk.

OU

47


OPGAVE 2.1

Acht u het mogelijk en/of wenselijk dat het systeem vanuit perspectief van de patiënt in zijn geheel geautomatiseerd wordt? Kijken we vanuit de huisarts, dan kunnen we nog een derde systeem onderscheiden: het systeem dat de praktijkvoering ondersteunt en waarvan zowel de assistent als het geautomatiseerde HIS deel uitmaakt. Figuur 2.2 illustreert de drie systemen en hun onderlinge relaties.

FIGUUR 2.2

Systeemgrenzen

Drie informatiesystemen, met verschillende systeemgrenzen

Dit voorbeeld illustreert dat het bij de beschrijving van een informatiesysteem van belang is om het systeem nauwkeurig af te bakenen van zijn omgeving. Voor de ontwerpers van het HIS is het van belang om te weten hoe een huisartsenpraktijk functioneert en dat daarbij (vrijwel altijd) een assistent is betrokken. Ook moet vastgesteld worden welk deel van de werkzaamheden geautomatiseerd kan worden en welk deel niet. De patiëntgegevens die voorheen op patiëntkaarten in kaartenbakken werden beheerd, kunnen worden vervangen door elektronische medische dossiers, maar het maken van afspraken gaat nog steeds met tussenkomst van de assistent. OPGAVE 2.2

a Teken een schema als figuur 2.2 voor de inlichtingendienst van de KPN zoals die lang geleden functioneerde: de telefonist heeft de beschikking over alle telefoonboeken van Nederland plus een lijst van nieuwe aansluitingen en zoekt het gevraagde nummer daar in op. b Idem, voor het geval de telefoon beantwoord wordt door een spraakcomputer, die uiteraard ook het opzoeken van het nummer voor zijn rekening neemt. c Welke informatiesystemen kunt u in beide gevallen onderscheiden?

48

OU


1.2

COMPUTERSPEL

Als tweede voorbeeld bekijken we het populaire computerspel Tomb Raider, waarvan inmiddels een hele reeks is verschenen. De centrale figuur is telkens de archeologe Lara Croft (zie figuur 2.3), een heldin die verschillende missies uitvoert waarbij ze op vele locaties in verschillende continenten terecht komt. Ze komt daarbij voortdurend vijanden tegen (mensen, dieren en monsters) die het op haar leven hebben gemunt en die volgens de logica van het spel uit de weg geruimd moeten worden. Onderweg worden verschillende voorwerpen (zoals wapens) aangetroffen die meegenomen en gebruikt kunnen worden. Het spel wordt door één persoon op een pc of spelcomputer gespeeld. De speler bestuurt de hoofdpersoon met het toetsenbord op een pc of met een apart bedieningsapparaat op een spelcomputer; vijanden (en een enkele keer een medestander) verschijnen en bewegen vanzelf. De speler kan het spel op elk moment opslaan; met een opgeslagen spel kan later worden verder gespeeld (ook te gebruiken in het geval Lara verslagen wordt).

FIGUUR 2.3

Lara Croft, de hoofdpersoon uit Tomb Raider

Wie zijn er betrokken bij dit systeem en wat zijn hun doelen? De betrokkenen zijn de individuele spelers en hun doel is om zichzelf door middel van de uitdaging die het spel biedt, te vermaken. Welke informatie speelt een rol bij het systeem en wat doet het systeem daarmee? De invoer van dit systeem bestaat (bij een pc) uit commando’s van de gebruiker, gegeven via het toetsenbord (naar links, naar rechts, rennen, schieten, oprapen, ...). De uitvoer bestaat uit een fraaie grafische weergave van de bijbehorende acties van Lara en haar tegenspelers. Binnen het systeem wordt informatie verwerkt en beheerd. Er wordt bijgehouden waar Lara zich bevindt, hoe die locatie grafisch gerepresenteerd moet worden, welke vijanden er aanwezig zijn, hoeveel kracht Lara nog heeft, welke wapens ze gebruikt, waarover ze nog meer beschikt en welke wijzigingen er eventueel eerder in de omgeving zijn aangebracht (zoals verslagen vijanden, geopende deuren of bassins die met water zijn gevuld). Bij het construeren van zo’n spel moet uiteraard grondig nagedacht worden over de organisatie en presentatie van die informatie.

OU

49


Het beheren van informatie speelt echter geen hoofdrol. Ook is het niet nodig om een analyse te maken van de manier waarop in de echte wereld met deze informatie wordt omgegaan. Welke mensen en welke middelen (apparatuur en programmatuur) behoren tot het systeem? Het systeem bestaat uit programmatuur, die op een pc of een spelcomputer uitgevoerd wordt. Er is geen sprake van verschillende mogelijke systeemgrenzen. OPGAVE 2.3

Noem enkele verschillen tussen het computerspel Tomb Raider en het HIS. 1.3

BETAALAUTOMAAT

Als derde voorbeeld bekijken we een betaalautomaat of pinautomaat waarmee een betaling elektronisch kan worden uitgevoerd. Betaalautomaten zijn gemeengoed in winkels en benzinestations, waar klanten hun aankopen kunnen betalen met een betaalkaart bij een betaalautomaat in plaats van met contant geld. De gang van zaken bij het uitvoeren van een betaling is schematisch in figuur 2.4 weergegeven. De winkelier voert het juiste bedrag in op een kassa of computer die met de betaalautomaat verbonden is. Het bedrag verschijnt vervolgens op de display van de betaalautomaat. De klant steekt zijn betaalkaart (een bankkaart of een creditkaart) in de betaalautomaat, voert zijn pincode in, en bevestigt dat hij het getoonde bedrag wil betalen. De betaalautomaat leest gegevens van de betaalkaart, die zich op een magneetstrook of op een chip op de betaalkaart bevinden. Via een communicatieverbinding maakt de betaalautomaat contact met de organisatie die de betalingstransactie verwerkt en met de banken die de rekeningen van de klant en de winkelier beheren. Voordat het bedrag van de rekening van de klant naar de rekening van de winkelier wordt overgeschreven, worden eerst gegevens geverifieerd. Zo wordt gecontroleerd of de betaalkaart geldig is, of de ingevoerde pincode juist is, of de klant voldoende geld op zijn rekening heeft staan en of het bedrag binnen de betalingslimiet van de klant ligt.

FIGUUR 2.4

50

OU

Betaling via een betaalautomaat


Wie zijn er betrokken bij dit systeem en wat zijn hun doelen? De direct betrokkenen zijn de klant en de winkelier. Hun doel is om een elektronische betaling te verrichten waarbij de klant een aankoop kan betalen aan de winkelier. De organisatie die de transacties verwerkt en de banken zijn ook belanghebbenden. Hun doelen zijn om gegevens over de transactie te communiceren en de rekeningen van klant en winkelier te beheren. Voor al deze belanghebbenden is het correct en snel verlopen van het betalingsverkeer van belang. Een andere groep betrokkenen, waar terdege rekening mee gehouden moet worden, zijn criminelen en criminele organisaties, die via frauduleuze handelingen proberen geld te onttrekken. Een bekend probleem is het skimmen van betaalkaarten, waarbij criminelen de gegevens op een betaalkaart kopiëren als deze in de betaalautomaat wordt gestoken en over de schouder meekijken bij het invoeren van de pincode. Criminelen maken daarbij bijvoorbeeld gebruik van een extra kaartleesapparaat op de betaalautomaat en een camera, die voor argeloze klanten nauwelijks opvallen. Vooral betaalkaarten met magneetstrippen zijn gevoelig voor skimmen. In nieuwe betaalkaarten zijn gegevens op een veiligere manier opgeslagen in een chip op de betaalkaart, wat een betere bescherming tegen skimmen biedt. Welke informatie speelt een rol bij het systeem en wat doet het systeem daarmee? De betaalautomaat ontvangt informatie van de winkelier (het bedrag) en van de klant (gegevens op betaalkaart, pincode, bevestiging). De betaalautomaat wisselt informatie uit met de transactieverwerkende organisatie en de banken. Uiteindelijk toont de betaalautomaat op de display of de betaling al dan niet is uitgevoerd. De betaalautomaat zelf is slechts een onderdeel in de betaalketen zoals die in figuur 2.4 is geschetst. Het bewaren en beheren van informatie is in de betaalautomaat nauwelijks van belang. Het gaat er meer om dat de betaalautomaat de informatie op de correcte wijze verwerkt en communiceert. Welke mensen en welke middelen (apparatuur en programmatuur) behoren tot het systeem? Net als bij het HIS, kunnen we diverse systeemgrenzen onderscheiden. In principe is de betaalautomaat een vrij eenvoudig apparaat, dat informatie communiceert met de winkelier, de klant, de transactieverwerkende organisatie en de banken. De betaalautomaat communiceert met andere informatiesystemen. De kassa of de computer van de winkelier is een informatiesysteem dat de inkomsten en uitgaven van de winkelier registreert. De transactieverwerkende organisatie is een omvangrijk onderdeel in de betaalketen, waarin talloze informatiesystemen een rol spelen. De informatiesystemen van de banken beheren de rekeningen.

OU

51


Equens is een Europese transactieverwerkende organisatie die een groot deel van de betaalinfrastructuur in onder andere de Benelux en Duitsland beheert en ontwikkelt. Er zijn circa 20.000 geldautomaten, waar contant geld opgenomen kan worden, en meer dan 500.000 betaalautomaten verbonden met het Equens-netwerk, waarmee in 2008 maar liefst 3,2 miljard transacties uitgevoerd werden. Ook beheert Equens 45 miljoen betaalkaarten. OPGAVE 2.4

Noem enkele eigenschappen waarin dit systeem zich onderscheidt van de eerder gegeven voorbeelden. 1.4

INDUSTRIËLE ROBOT

In het vierde en laatste voorbeeld kijken we naar een industriële robot. Een bekende toepassing van industriële robots is de auto-industrie, waar robots onderdelen van de carrosserie aan elkaar lassen en de auto in de juiste lakkleur spuiten. We bekijken hier een eenvoudige industriële robot voor het verpakken van diepvriesproducten. De robot bestaat uit een robotarm die aan het uiteinde is voorzien van een grijpbek waarmee een product opgepakt kunnen worden. Bij het verpakken van een product, neemt de robotarm telkens een product van een lopende band en plaatst het in een doos. De robot kan met behulp van een camera de plaats van een product op de lopende band detecteren. De robot kan dus zelf zijn beweging bepalen om een product op te pakken. De beweging om een product vervolgens in een doos te plaatsen, is voorgeprogrammeerd. Is deze robot een informatiesysteem? Het doel van dit systeem is het verpakken van producten; dat wordt niet alleen bereikt door het bewerken van informatie. Deze robot is dus geen informatiesysteem. Deelsystemen ervan zijn echter wel informatiesystemen. De robot bevat in elk geval twee deelsystemen: – een detectiesysteem dat een product op een lopende band detecteert, waarbij een camera wordt gebruikt – een besturingssysteem dat de beweging van de robotarm controleert en bepaalt wanneer de grijpbek moet openen en sluiten. OPGAVE 2.5

a Wie zijn er bij de twee informatiesystemen betrokken en wat zijn hun doelen? b Welke informatie speelt een rol bij deze systemen en wat doen ze daarmee? c Welke mensen behoren tot deze systemen? d Waarin onderscheiden deze systemen zich van de andere drie voorbeelden?

52

OU


1.5

SOORTEN INFORMATIESYSTEMEN

In de vorige paragrafen hebben we vier verschillende systemen bekeken. Daarbij hebben we geconstateerd dat er verschillende soorten informatiesystemen zijn die elk specifieke kenmerken hebben. In deze paragraaf zetten we de verschillende soorten informatiesystemen op een rijtje. Administratief systeem Informatiebank

In het HIS staat het bewaren en beheren van informatie centraal. Informatiesystemen waarbij het bewaren en beheren van potentieel grote hoeveelheden informatie centraal staat, noemen we administratieve systemen. De informatie wordt opgeslagen in een informatiebank. Figuur 2.5 toont een schematisch overzicht van een dergelijk systeem.

FIGUUR 2.5

Real-timesysteem

In administratieve systemen speelt de informatiebank een belangrijke rol

Het computerspel Tomb Raider is een voorbeeld van een realtimesysteem. In zo’n systeem moet de respons op aangeboden informatie binnen een vooraf vastgestelde, vaak korte tijd zijn gegenereerd om van correct functioneren te kunnen spreken. Meestal moeten zulke systemen een proces in de buitenwereld bij kunnen houden (in dit voorbeeld de besturingscommando’s van de gebruiker). Kunt u nog enkele voorbeelden van real-timesystemen bedenken? Ander voorbeelden zijn het detectiesysteem en het besturingssysteem van de industriële robot. Zij moeten ervoor zorgen dat een product binnen een bepaalde tijd vanaf de lopende band in een doos wordt geplaatst. De besturing die de robotarm op de juiste manier laat bewegen, luistert daarbij nauw. De robotarm moet ook het tempo kunnen bijbenen van de stroom producten die op de lopende band worden aangevoerd. Het navigatiesysteem in een vliegtuig is eveneens een real-timesysteem. Het moet immers meteen reageren op navigatieaanwijzingen. Ook een systeem voor het voorspellen van het weer is een real-timesysteem. Een weersvoorspelling voor het weer van morgen op grond van de gegevens van vandaag met een berekeningstijd van 32 uur, is immers volstrekt waardeloos. Real-timesystemen zijn dus lang niet altijd supersnelle systemen die binnen een fractie van een seconde een complexe berekening moeten uitvoeren.

OU

53


Het HIS is geen real-timesysteem. De gebruiker wil natuurlijk niet al te lang wachten voordat het systeem reageert, maar het systeem is er niet op ontworpen om altijd binnen een vastgestelde tijd te reageren. Dat blijkt ook wel in de praktijk: de reactietijd van programma’s op een desktopcomputer wordt grotendeels bepaald door de snelheid en configuratie van de hardware van de computer en van de hoeveelheid rekenwerk die de computer moet uitvoeren. OPGAVE 2.6

Is een betaalautomaat een real-timesysteem? Kritisch systeem

Een systeem waarin (bepaalde) fouten tot onacceptabele schade leiden, heet een kritisch systeem (waarbij wat precies als onacceptabel geldt, mede afhangt van maatschappelijke opvattingen daarover). De duidelijkste voorbeelden zijn systemen waar mensenlevens van afhangen, zoals systemen voor de besturing van vliegtuigen, kerncentrales of hartbewakingsapparatuur. Maar ook systemen waarvan het falen tot grote economische schade of politieke onrust kan leiden, zijn kritisch (denk aan wat er zou gebeuren als de banken kwamen met de mededeling ‘sorry, maar we zijn alle gegevens kwijt’). Alle geautomatiseerde systemen ondergaan een periode van testen voor ze in gebruik worden genomen. Dat is (meestal) genoeg om de ergste fouten er uit te krijgen, maar zeker niet om te garanderen dat programma’s (vrijwel) foutvrij zijn. Een kritisch systeem moet bovendien altijd beschikbaar zijn. In de betaalketen van figuur 2.4 kunnen we kritische systemen aanwijzen. Een betaalautomaat is niet kritisch. Als die het een keer niet doet, is dat hinderlijk maar niet levensbedreigend. De systemen voor de verwerking van de transacties, zijn wel kritisch. Storingen daarin kunnen ertoe leiden dat er geen transacties meer verwerkt kunnen worden, wat een flinke impact kan hebben op de economische stabiliteit van een land. Moeten informatiesystemen eigenlijk niet altijd foutvrij zijn? Theoretisch is het gewenst om alle informatiesystemen te beschouwen als kritische systemen. Dat zou ook goed zijn voor de werkgelegenheid in de IT-sector, maar het zou informatiesystemen ook veel en veel duurder maken. Stel bijvoorbeeld dat een tekstverwerker gemiddeld eens in de 100 uur dat er mee gewerkt wordt, vastloopt. De kosten om dat terug te brengen tot eens in de 1000 uur kunnen de verkoopprijs van het programma gemakkelijk twee of meer keer zo hoog maken. Het is dan de vraag of we dat ervoor over hebben (zeker als het programma ons werk uit zichzelf regelmatig bewaart, zodat een crash bijna nooit meer dan het verlies van 15 minuten werk betekent). Anderzijds bevat programmatuur meer fouten dan we van andere systemen gewend zijn en acceptabel vinden. Niemand kijkt ervan op dat een programma soms vastloopt en dan herstart moeten worden, en niemand eist, als het niet te gek wordt, op grond daarvan zijn geld terug. Van koffiezetapparaten, dvd-spelers, wasmachines en auto’s accepteren we dat niet. In paragraaf 2 van deze leereenheid gaan we iets dieper in op de vraag waarom het zo moeilijk is om goede informatiesystemen te construeren.

54

OU


Een systeem waarin verschillende computers en andere apparaten met elkaar samen moeten werken, heet een gedistribueerd systeem. In zo’n systeem zijn speciale maatregelen nodig om het verkeer in goede banen te leiden en te zorgen dat er geen transacties verloren gaan.

Gedistribueerd systeem

Zijn HIS en Tomb Raider gedistribueerde systemen? Tomb Raider is duidelijke geen gedistribueerd systeem. Het HIS is mogelijk wel een gedistribueerd systeem, maar noodzakelijk is dat niet. Binnen een groepspraktijk kunnen meerdere huisartsen en assistenten met het systeem werken, die elk een eigen pc hebben. Die pc’s zijn opgenomen in een netwerk; het opslaan van informatie gebeurt centraal. Een informatiesysteem dat deel uitmaakt van een apparaat dat zelf geen informatiesysteem is, heet een embedded system. Ingebedde systemen zijn alomtegenwoordig, niet alleen in de industrie, maar ook in het dagelijks leven in consumentenelektronica, mobiele en vaste telefoons, wasmachines, auto’s en koffiezetapparaten. Het besturingssysteem in de industriële robot is een ingebed informatiesysteem.

Embedded system

OPGAVE 2.7

Kan het navigatiesysteem voor routebepaling in een personenauto het best beschouwd worden als een administratief, embedded, real-time of kritisch systeem? Samenvatting

In deze paragraaf hebben we een eerste indruk gegeven van wat informatiesystemen zijn. Deze systemen hebben gemeen dat ze betekenisvolle gegevens manipuleren. Ze kunnen in complexiteit echter zeer uiteenlopen en kunnen een of meer bijzondere eigenschappen hebben. Een informatiesysteem heet – administratief als het draait om het opslaan en beheren van informatie – real-time als het per se binnen een bepaalde tijd op invoer moet reageren – kritisch als het falen van het systeem tot onacceptabele schade kan leiden – gedistribueerd als het over meer dan één computer verspreid is – ingebed als het niet op een computer draait, maar deel uitmaakt van een omvattend systeem dat zelf geen informatiesysteem is. 2

Informatiesystemen ontwikkelen

Deze paragraaf geeft een inleiding over het ontwikkelen van informatiesystemen. We staan eerst stil bij de redenen waarom het ontwikkelen van complexe informatiesystemen in de praktijk nogal eens misgaat. Vaak worden de geraamde kosten en tijd voor de ontwikkeling ruimschoots overschreden. Aan het einde van deze paragraaf bespreken we een ontwikkelmethode die bedoeld is om die problematiek het hoofd te bieden.

OU

55


2.1

EEN MISLUKKING

In 1990 besloot de London Ambulance Service het sturen van ambulances naar ongelukken voor een groot deel te gaan automatiseren. De toenmalige gang van zaken was onbevredigend; er ging te veel tijd verloren en er werden te veel fouten gemaakt bij het doorgeven van de juiste locatie van het ongeluk en het kiezen van de meest geschikte ambulance om erheen te sturen. Ook de administratieve afhandeling was omslachtig. Het nieuwe systeem zou een autovolgsysteem bevatten. Via automatische radiomeldingen zou de centrale voortdurend op de hoogte blijven van de locaties van alle ambulances. Telefonistes van de hulpdienst zouden de plaats en aard van het ongeluk invoeren. In luttele seconden zou het systeem daarna drie suggesties doen aan een menselijke toewijzer die daaruit de meest geschikte ambulance zou kiezen om naar het gemelde ongeluk te sturen. Het ambulancepersoneel moest dan uiteraard bevestigen dat ze de opdracht hadden ontvangen en op weg waren. OPGAVE 2.8

Noem drie eigenschappen van dit systeem (zoals behandeld in paragraaf 1). Het systeem werd in oktober 1992 in gebruik genomen. Het autovolgsysteem bleek niet in staat om de locaties van alle ambulances goed bij te houden, waardoor er fouten ontstonden in de informatiebank van het systeem en dus ook bij het toewijzen van ambulances. De fouten in de informatiebank maakten het systeem trager, wat weer tot nieuwe fouten leidde. De vertragingen en foutieve toewijzingen leidden op hun beurt tot extra telefoontjes naar het alarmnummer, wat het systeem nog verder vertraagde. Het ambulancepersoneel, dat aan het systeem moest terugmelden dat het inderdaad op weg was naar een ongeluk, raakte gefrustreerd en werkte niet meer mee. Het hele systeem ontaardde in chaos (één ambulance arriveerde pas elf uur na de melding; de patiënt was toen overigens al lang via privévervoer in het ziekenhuis aangekomen). De automatisering werd onmiddellijk voor een deel teruggedraaid; binnen acht dagen liep ook dat beperkte systeem vast en ging men terug naar de oude procedures. Volgens krantenartikelen waren er tot twintig doden gevallen tengevolge van deze mislukking (het is niet duidelijk of deze claim op waarheid berust). Een onafhankelijke commissie bracht in 1995 een rapport uit, waaruit bleek dat bij dit project vrijwel alles misgegaan was wat er mis kon gaan. Het project werd gegund aan de enige biedercombinatie die het systeem binnen de opgelegde randvoorwaarden (tijd en geld) wilde ontwikkelen. Er was grote druk op de ontwikkelaars om het systeem tijdig op te leveren. Gedurende de ontwikkeling was veel te weinig overlegd met de toekomstige gebruikers en de opdrachtgevers, zodat die het systeem niet als iets van hen ervaarden. Het systeem was voor de gebruikers onhandig om mee te werken. Bij het ontwerp waren onjuiste aannames gemaakt. De opgeleverde programmatuur was onvolledig en bovendien niet serieus getest. Het systeem kon gebruikersfouten niet goed opvangen en was inefficiënt.

56

OU


2.2

DE SOFTWARECRISIS

De mislukking uit de vorige paragraaf betrof een kritisch systeem en is mede daardoor uitgebreid onderzocht en gedocumenteerd. Maar zo’n mislukking is niet uniek en evenmin iets uit het verleden. Het komt nog steeds regelmatig voor dat informatiesysteemprojecten volledig mislukken en er uiteindelijk niets bruikbaars wordt opgeleverd. In een bron (Bennett e.a., Object oriented systems analysis and design using UML, McGraw-Hill, 2002) wordt dat aantal zelfs op een kwart van alle projecten geschat. Het komt nog veel vaker voor dat projecten ver over het budget gaan en/of veel te laat worden opgeleverd. Opgeleverde software bevat bovendien, zoals al eerder geconstateerd, vrijwel altijd fouten, waardoor het systeem op een voor de gebruiker ondoorgrondelijke wijze vastloopt (zie figuur 2.6; het foutenlogboek is voor een normale gebruiker onbegrijpelijk).

FIGUUR 2.6

Problemen met kwaliteit

Problemen met voortgang

Veel programma’s lopen wel eens vast

De redenen voor de mislukkingen vallen uiteen in twee groepen (zie ook hiervoor Bennett e.a.). – Problemen met de kwaliteit van het systeem. Daaronder vallen systemen die op zich wel goed werken, maar nutteloos blijken (het verkeerde probleem is opgelost), systemen die zeer onhandig in het gebruik zijn of niet aansluiten bij de bedrijfscultuur en systemen die te veel fouten bevatten. In zulke gevallen accepteren de gebruikers het systeem terecht niet of alleen met grote tegenzin. Vaak betekent dit dat het ontwikkelteam zijn werk niet goed heeft gedaan. Het heeft niet begrepen wat de klanten wilden, of heeft wel goed geluisterd naar de opdrachtgevers maar niet naar de eindgebruikers (zoals het ambulancepersoneel in het voorbeeld uit paragraaf 2.1). Of erger nog: het vindt dat de gebruikers zich naar het systeem moeten richten in plaats van omgekeerd. – Problemen met de voortgang van het ontwikkelwerk. Deze treden op als de benodigde ontwikkeltijd verkeerd is ingeschat, als er een slechte projectmanager aan het hoofd staat of als het project van het begin af aan onhaalbaar was, maar de druk om het toch te ontwikkelen niet kon worden weerstaan. De voortgang komt ook in gevaar door veranderingen die tijdens de ontwikkeling op verzoek van de klant moeten worden aangebracht. Zeker als een ontwikkeltraject lang duurt, zijn dergelijke veranderingen onvermijdelijk. In een periode van twee jaar staat de bedrijfsvoering niet stil; een informatiesysteem moet daar uiteraard rekening mee houden. Soms zijn er dwingende externe factoren, zoals gewijzigde wetgeving.

OU

57


Softwarecrisis

De problematiek van ondermaatse kwaliteit van informatiesystemen en het overschrijden van tijd en geldbudgetten, bestaat al vrijwel zolang als er computers zijn en is zeer hardnekkig. Deze problematiek wordt met de term softwarecrisis aangeduid. De problemen deden zich initieel om een andere reden voor, namelijk vanwege de stormachtige ontwikkeling van de computerhardware. Zowat elke paar jaar komt er een dubbel zo krachtige computer voor hetzelfde geld, waardoor steeds complexere software uitgevoerd kan worden. Al in 1968 werd het achterblijven van de kwaliteit van de software bij de mogelijkheden van de hardware benoemd als de softwarecrisis. Ook werd toen geconstateerd dat het tijd werd om anders tegen programmatuurontwikkeling aan te kijken. Tot dan toe werden informatiesystemen redelijk ad hoc ontwikkeld. Naarmate die systemen complexer werden, voldeed die ad-hocbenadering minder en minder. Vergelijk dit met het bouwen van een huis. Een eenvoudig hutje kan vrijwel iedereen in elkaar timmeren, en met een beetje geluk is het nog waterdicht ook. Maar ook een begenadigd aannemer bouwt niet zonder plan een woonhuis en een wolkenkrabber al helemaal niet. Daarvoor zijn naast creativiteit ook allerlei standaardtechnieken nodig, ontwikkeld binnen de ingenieursdiscipline van de bouwkunde.

Software engineering Methoden en technieken

Eind jaren zestig werd de noodzaak gevoeld voor een vergelijkbare discipline op het gebied van informatiesysteemontwikkeling: de software engineering was geboren. De belangrijkste doelstelling van het vakgebied software engineering is het bedenken van methoden en technieken die gebruikt kunnen worden voor de ontwikkeling van informatiesystemen. Een methode voor informatiesysteemontwikkeling beschrijft welke taken er zijn bij die ontwikkeling en hoe die taken georganiseerd moeten worden. Vergelijk dit met bijvoorbeeld een methode voor het maken van een kledingstuk, die zou kunnen voorschrijven om eerst een grove schets te maken die toont hoe het eindresultaat er ongeveer uit moet gaan zien, dan de maat te nemen van de beoogde drager en uit te rekenen hoeveel stof er ongeveer nodig is, vervolgens een geschikte stof te kopen, dan een patroon te tekenen en aan de hand daarvan de stof te knippen, enzovoort. Bij een methode gaat het dus om wat er in welke volgorde gedaan moet worden. Een techniek is een hulpmiddel voor één bepaalde taak. Een goede kleermaker beschikt bijvoorbeeld over technieken om een patroon op stof over te brengen, om een mouw netjes in te zetten, om knoopsgaten te maken, enzovoort. Bij een techniek gaat het dus om hoe een bepaalde taak uitgevoerd moet worden. In de rest van deze paragraaf zullen we twee methoden bekijken voor de ontwikkeling van informatiesystemen; in de volgende leereenheden zullen we ook kennismaken met technieken die op dit moment veel worden toegepast. Daarbij past een waarschuwing: methoden en technieken zijn niet meer dan gereedschap en kunnen op zich nooit een oplossing bieden voor de softwarecrisis. Iemand die geen talent heeft op dat gebied of die volstrekt onervaren is, zal ook uit de mooiste stof met de beste naaimachine geen fraaie avondjurk kunnen maken.

58

OU


Met informatiesysteemontwikkeling is het niet anders. Daarvoor is naast methoden en technieken ook altijd een goed projectteam nodig, waarin niet alleen technische, maar ook communicatieve en leidinggevende vaardigheden ruim vertegenwoordigd zijn. 2.3

DE WATERVALMETHODE

In deze paragraaf bekijken we een ontwikkelmethode, de zogenaamde watervalmethode, aan de hand van een voorbeeld, en wel de ontwikkeling van een denkbeeldig huisartsinformatiesysteem zoals we dat in paragraaf 1.1 hebben bekeken. Voorbeeld

Voortraject

Paul is een softwarehuis begonnen en is op zoek naar een verkoopbaar product. Hij heeft een tijd medicijnen gestudeerd en heeft daaraan goede contacten in de medische wereld overgehouden. Huisarts Jenny heeft belangstelling voor automatisering en heeft zelf haar patiënten ‘in de computer’ gezet, maar heel bevredigend werkt dat nog niet. Paul stelt aan haar voor om met haar hulp een beter systeem te ontwerpen en te implementeren. Daarmee is een begin gemaakt met de mogelijke ontwikkeling van een informatiesysteem. Paul en Jenny zijn nu bezig met het voortraject. De deal is als volgt: Jenny verleent in ruil voor het systeem haar medewerking aan de ontwikkeling; Paul mag het product daarna ook aan derden verkopen. Jenny deelt in de winst. Zo’n deal komt alleen tot stand als beide partijen denken daar voordeel bij te hebben. Jenny moet ervan overtuigd zijn dat een HIS leidt tot een betere of efficiëntere praktijkvoering en dat de tijd die ze in de ontwikkeling moet steken, daar tegenop weegt. Paul moet van mening zijn dat hij het systeem in een redelijke tijd kan ontwikkelen en dat er een markt voor is. Hij weet op dit moment nog niet wat hij precies zal gaan (laten) bouwen, dus hij kan nog niet zeggen hoeveel tijd dat gaat kosten. Maar hij zal wel een idee hebben in welke orde dat ligt.

Analyse

Nadat in het voortraject besloten is dat het project de moeite waard is om aan te pakken, begint het echte werk. De eerste fase heet de analysefase. In deze fase moet besloten worden wat er precies gebouwd gaat worden. Daartoe worden verschillende activiteiten uitgevoerd, namelijk bedrijfsmodellering, informatieanalyse en het opstellen van eisen. We zullen deze hierna toelichten.

Bedrijfsmodellering oude situatie

Paul gaat zich met behulp van Jenny eerst een beeld vormen van de bedrijfsvoering in een huisartsenpraktijk. Hij bekijkt wat ze allemaal doet, wat haar assistent doet en welke informatie daarbij een rol speelt. Hij zal ook willen weten of het er in andere praktijken ook zo aan toe gaat en als hij vermoedt van niet, zal hij dat proberen uit te zoeken (misschien werkt Jenny alleen en moet Paul zich dus ook oriënteren op de gang van zaken in een groepspraktijk). Op dat moment zijn ze dus nog niet bezig met het toekomstige, deels geautomatiseerde informatiesysteem; ze zijn het huidige, niet-geautomatiseerde informatiesysteem in kaart aan het brengen.

OU

59


Bedrijfsmodellering nieuwe situatie

Vervolgens gaan ze na welke taken voor automatisering in aanmerking komen en hoe dit de bedrijfsvoering zal beïnvloeden. Daarbij speelt zowel haalbaarheid als wenselijkheid een rol. Misschien dacht Paul op dit punt wel dat de assistent overbodig zou kunnen worden en heeft Jenny hem duidelijk gemaakt dat dat een vergissing is, omdat een assistent een belangrijke sociale functie in de praktijk vervult. En misschien kwam Jenny op het idee om ook meteen de volledige financiële administratie in het systeem onder te brengen en heeft Paul toen gezegd dat hij dat zeker niet in de eerste versie van het systeem wil doen. Ze brengen samen de nieuwe, toekomstige situatie in kaart, waarbij ook de grenzen van het geautomatiseerde informatiesysteem worden vastgesteld. Omdat de veranderingen in de bedrijfsvoering ook voor de assistent van belang zijn, zal ook deze hierbij betrokken worden.

Informatieanalyse

Bij administratieve systemen wordt tijdens de analyse ook vastgesteld welke informatie in het systeem zal worden vastgelegd. Dat moet heel nauwkeurig gebeuren. Voor de patiëntgegevens kan bijvoorbeeld worden uitgegaan van de patiëntkaarten die tot dan toe gebruikt werden. Het opnemen van naam, adres, telefoonnummer, geboortedatum en geslacht liggen voor de hand. Maar er zijn ook keuzes te maken. Wordt er ruimte gemaakt voor het vastleggen van een mobiel nummer? Of wordt er gekozen voor een algemene aanpak, waarbij iedere patiënt een rijtje telefoonnummers kan hebben? Kan een patiënt ook meer dan één adres hebben (denk aan kinderen van gescheiden ouders)? Leggen we ook vast waar een patiënt geboren is? Op al die vragen moet een gedetailleerd antwoord komen.

Opstellen van eisen

Een derde belangrijk onderdeel van de analyse is om gedetailleerd vast te leggen wat het systeem moet kunnen en aan welke randvoorwaarden het moet voldoen. Eén (vrij nieuwe) techniek die daarbij gebruikt kan worden, zullen we in leereenheid 6 en 7 nader bekijken. Voor elke taak die een gebruiker met behulp van het systeem wil uitvoeren, wordt het verloop van de interactie beschreven. De eisen worden dus opgesteld in de vorm van verhaaltjes over het gebruik van het systeem. Dergelijke verhaaltjes worden use cases genoemd. We geven een mogelijk voorbeeld van een use case uit een HIS.

Use case

Voorbeeld

60

Patiëntgegevens tonen Bij het begin van een consult wil de huisarts de gegevens van de patiënt zien. De arts kiest daartoe de naam van de patiënt uit de lijst met namen van patiënten die zich voor dit spreekuur hebben aangemeld. Om fouten te voorkomen, toont het systeem van de gekozen patiënt nogmaals de naam, de geboortedatum en het adres; de arts moet vervolgens bevestigen dat het inderdaad om deze patiënt gaat. Vervolgens toont het systeem op één scherm alle relevante gegevens van die patiënt.

OU


In een later stadium wordt een dergelijke use case nog verder uitgewerkt. Enkele andere use cases uit een HIS geven weer wat er gebeurt bij het uitschrijven van een recept, bij het maken van een nieuwe afspraak en bij het wijzigen van patiëntgegevens. Omdat die laatste twee taken door de assistent gedaan worden, moet deze betrokken worden bij het opstellen van die use cases. OPGAVE 2.9

Noem enkele use cases van Tomb Raider. Eisendocument of specificatie

Ontwerp

Gebruikersinterface

Relationele database

Object

Als afronding van de analysefase wordt een document opgeleverd, het eisendocument of de specificatie genoemd, waarin gedetailleerd is vastgelegd wat het systeem moet kunnen. Ook eventuele randvoorwaarden zijn daarin vastgelegd, bijvoorbeeld over de snelheid van het systeem of over wat er gebeurt als het systeem opeens uitvalt. Nu er precies is vastgesteld wat er gebouwd gaat worden, is Paul ook in staat om een nauwkeurige planning en een kostenraming te maken. In de volgende fase, de ontwerpfase, wordt de structuur van het systeem bepaald: de aandacht verschuift van wat het systeem zal gaan doen naar hoe het dat zal gaan doen. Er wordt bepaald uit welke deelsystemen het zal worden opgebouwd en hoe die met elkaar communiceren. We noemen drie belangrijke ontwerptaken. – Ontwerp van de gebruikersinterface. In het eisendocument is wel de interactie met het systeem vastgelegd, maar nog niet hoe alle schermen er precies uit zullen zien. Het is duidelijk dat bij deze stap de toekomstige gebruikers nauw betrokken moeten worden. Jenny en de assistent hebben hier dus nog een belangrijke taak. Maar dat is voorlopig ook ongeveer de laatste. Tot het systeem (bijna) af is, doen in deze ontwikkelmethode Paul en zijn medewerkers het verdere werk. – Het bepalen van de vorm van de informatiebank. Er zijn verschillende mogelijkheden, maar in de praktijk wordt in zeker 95 % van de administratieve systemen gekozen voor een relationele database. Zo’n database bestaat uit verschillende tabellen. Onderdeel van de ontwerpfase is het vertalen van de resultaten van de informatieanalyse naar zulke tabellen. In leereenheid 3 gaan we nader in op relationele databases en hun tabelstructuur. – Ontwerp van de benodigde programmatuur. Ook programma’s kunnen op veel verschillende manieren in elkaar worden gezet. Populair op dit moment is het objectgeoriënteerd ontwerpen, waarbij een systeem wordt beschreven als een verzameling objecten die samenwerken om de vereiste taken uit te voeren. Een object is daarbij iets dat we als betekenisvolle eenheid willen onderscheiden. Dat kan van alles zijn: een patiënt, een medicijn, een ziekte, maar ook meer abstracte zaken als een symptoom, een diagnose of een consult. Objecten kunnen zijn samengesteld uit andere objecten. Een patiënt bijvoorbeeld heeft een adres; dat is zelf ook weer een object. Het ontwerp bevat ook objecten die geen tegenhanger buiten het systeem hebben. Zo bestaat ook de gebruikersinterface uit objecten. In de ontwerpfase wordt bedacht welke objecten er moeten zijn en hoe die samenwerken. Leereenheid 7 gaat in zijn geheel over objectgeoriënteerd ontwerpen.

OU

61


OPGAVE 2.10

Kunt u enkele objecten bedenken die in Tomb Raider een rol spelen? Ook de ontwerpfase wordt afgesloten met een document: het ontwerp. Dit kan beschouwd worden als de bouwtekening van het systeem, waarmee de programmeurs straks aan de gang kunnen. Belangrijk bij de afronding van de ontwerpfase is, dat zorgvuldig wordt nagegaan of het ontwerp in overeenstemming is met het eisendocument: gaat dit systeem ook echt alles doen wat daarin is vastgelegd? Implementatiefase

Na het afronden van de ontwerpfase volgt de implementatiefase: het systeem wordt daadwerkelijk gebouwd, met het ontwerp als leidraad. In ons voorbeeld doet Paul dat vermoedelijk niet zelf, maar huurt hij daar programmeurs voor in. Die moeten meer doen dan alleen programmacode schrijven. Ze moeten die code ook uitgebreid testen: eerst de code voor elk object afzonderlijk, dan de subsystemen en ten slotte het hele systeem. Ze moeten er ook voor zorgen dat het programma goed gedocumenteerd wordt, zodat als er later iets aan veranderd moet worden, anderen kunnen begrijpen wat ze gedaan hebben. Na verloop van tijd is het systeem in de ogen van de programmeurs klaar. Er volgt dan nog een testfase, waarbij Jenny en eventueel ook anderen voorlopige versies van het systeem uitproberen. Ondertussen wordt ook een gebruikershandleiding geschreven. Ten slotte is het zover: het systeem is voltooid en daarmee is de implementatiefase afgerond. Jenny neemt het in gebruik en het wordt ter verkoop aangeboden aan andere artsen. De echte invoering in een praktijk vereist nog een apart invoeringstraject, waarin arts en assistent worden getraind in het gebruik en waarin de patiëntgegevens worden ingevoerd (in één keer of, wat waarschijnlijker is, geleidelijk). Met dat invoeringstraject houden we ons hier verder niet bezig. Daarmee is het verhaal nog niet af. Tijdens het gebruik zullen er nog af en toe fouten opduiken. De gebruikers komen door het gebruik van het systeem op nieuwe ideeën over gewenste extra’s. Er komt nieuwe regelgeving van de overheid, die eist dat bepaalde zaken geregistreerd worden waar het systeem nog geen rekening mee had gehouden. Er komen nieuwe versies van de database waarmee het systeem werkt, en van het besturingssysteem waar het op draait. Al deze zaken maken het nodig dat er regelmatig nieuwe versies van het systeem worden uitgebracht.

Onderhoud

62

Voor de meeste systemen gaat zeker 75 % van de kosten zitten in onderhoud. Oude systemen zijn soms heel moeilijk te wijzigen, zeker als ze niet behoorlijk gedocumenteerd zijn en niemand meer weet hoe de programmatuur in elkaar zit en waarom bepaalde beslissingen zijn genomen. Dit is zeer duidelijk geworden in de jaren voorafgaand aan de millenniumwisseling, toen veel tijd en menskracht is gestoken in het millenniumbestendig maken van oude programmatuur, waarin jaartallen door twee cijfers werden voorgesteld. Sindsdien wordt in de ontwerpfase (als het goed is) al veel meer rekening gehouden met het feit dat het systeem zal veranderen.

OU


Watervalmethode

De ontwikkelmethode die we zojuist schetsten, is de watervalmethode. Het is een vrij oude ontwikkelmethode, die tegenwoordig achterhaald is. In de volgende paragraaf beschrijven we een veel modernere ontwikkelmethode. Het zojuist geschetste ontwikkeltraject van het HIS is dan ook niet meer van deze tijd. Het dateert uit de tijd dat het gebruik van een HIS in een huisartsenpraktijk nog niet algemeen was. Nu zou een dergelijk systeem niet meer van de grond af aan ontwikkeld worden; daarvoor is er al te veel op de markt. Figuur 2.7 toont nog eens de verschillende fasen in de watervalmethode. Het onderhoud hebben we hierbij buiten beschouwing gelaten: dit is geen echte fase; het gaat immers altijd door. Iedere nieuwe versie heeft weer een eigen ontwikkeltraject, waarbij zowel het eisendocument, het ontwerp als de implementatie worden aangepast.

FIGUUR 2.7

De watervalmethode in schema

Figuur 2.7 verklaart de naam van de methode: met wat fantasie kan de figuur als een waterval gezien worden, waarbij het systeem langs de verschillende fasen stroomt. Figuur 2.7 toont daarbij een vrij eenvoudige versie; er zijn ook versies die meer verschillende fasen onderscheiden. Belangrijk is, dat iedere fase wordt afgerond met een product dat de overgang naar de volgende fase markeert: het eisendocument aan het eind van de analysefase, het ontwerp aan het eind van de ontwerpfase en het voltooide systeem aan het eind van de implementatiefase. De figuur toont ook pijlen terug. In het voorbeeld hebben we voor het gemak gedaan alsof alles probleemloos verliep, maar in de praktijk is dat meestal niet zo. Tijdens het ontwerp kunnen bepaalde eisen zeer moeilijk te verwezenlijken blijken en tijdens de implementatie kan blijken dat het ontwerp op bepaalde punten niet voldoet. In iedere fase is er daarom gelegenheid om foute beslissingen uit de vorige fase nog te wijzigen. OPGAVE 2.11

Tot welke fase behoren de volgende activiteiten, uitgevoerd tijdens de ontwikkeling van een administratief informatiesysteem voor een grote hotelketen? a aanpassing van het systeem naar aanleiding van de bevindingen met een proefopstelling, waarbij een klein deel van het personeel op een paar locaties alvast met het systeem gewerkt heeft b aanpassing van het systeem wanneer de directie heeft besloten om binnen de hotelketen voortaan met Mac- in plaats van Windowscomputers te gaan werken

OU

63


c de constructie van webpagina’s voor de website die onlineboeking mogelijk maakt d een gesprek met de directie over welke overzichten het systeem dagelijks automatisch moet aanmaken e een gesprek met het baliepersoneel over hun werkzaamheden en wat daar wel en niet goed in gaat f samen met het baliepersoneel tot een goede schermindeling komen voor het deelsysteem dat het inchecken van klanten ondersteunt. De watervalmethode was een van de eerste systematische ontwikkelmethoden. Het gemaakte onderscheid tussen analyse, ontwerp en implementatie heeft zijn geldigheid nog niet verloren. Toch bleek deze methode niet de gehoopte oplossing te bieden voor de softwarecrisis; naarmate de tijd voortschreed, bleken er steeds meer problemen aan te kleven. Eisen bevriezen

Eén groot probleem is dat het definitief vaststellen (‘bevriezen’) van de eisen aan het eind van de analysefase in de praktijk vrijwel onmogelijk blijkt. Opdrachtgevers en gebruikers weten vooraf niet altijd precies wat ze willen, zeker als het systeem onder constructie innovatief is. Pas bij het werken met een voltooid systeem kan blijken wat ze eigenlijk gewild hadden, of wat het systeem nog meer voor ze zou kunnen doen (probeert u zich maar eens voor te stellen dat u een volledige specificatie van een tekstverwerker of een browser zou moeten opstellen als u zo’n programma nog nooit gebruikt had). Als het een groot systeem betreft en de ontwikkeling dus lang duurt, is er bovendien een grote kans dat er in de bedrijfsvoering of in de buitenwereld iets verandert dat aanpassing van de eisen onvermijdelijk maakt.

Risico’s

Een tweede probleem is dat niet alle risico’s in een vroeg stadium van het project duidelijk zijn. Denk bijvoorbeeld aan het systeem voor de Londense ambulancedienst. Voor zo’n systeem is het essentieel dat het autovolgsysteem de ambulances goed kan bijhouden. Als het de eerste keer is dat iets dergelijks geprobeerd wordt (dat was in Londen overigens niet het geval), dan is het zinloos om de rest van de eisen op te stellen en de rest van het systeem te ontwerpen voor het zeker is dat dat lukt. Bij de watervalmethode komt die zekerheid er pas in de implementatiefase.

Overschrijding tijd en geldbudget

Een derde probleem is dat vrijwel alle systemen te laat en met overschrijding van het budget worden opgeleverd. We kunnen natuurlijk vaststellen dat dat niet zou moeten, maar dat lost het probleem niet op. Bij de watervalmethode is het alles of niets: pas helemaal aan het eind is er een werkend systeem; als dat eind niet gehaald wordt, is er niets. Voorbeeld

64

Het had met het HIS van Jenny en Paul ook anders kunnen lopen. Nadat ze samen de eisen hebben vastgesteld, werd het stil. Paul dacht het systeem in een half jaar te ontwikkelen, maar dat viel tegen. Hij was inmiddels ook met een ander groot project bezig en besteedde het opstellen van het ontwerp uit. De ontwerper bleek niet zo kundig als gehoopt. Halverwege de implementatiefase ging een van de meest productieve programmeurs weg; helaas zonder zijn code eerst goed te documenteren. Pas na vijftien maanden kreeg Jenny een eerste versie van het systeem. Dat bleek lang niet zo handig als ze gedacht had. Ze had een waslijst van klachten. Sommige waren het gevolg van

OU


misverstanden, maar andere bleken ‘onterecht’: Jenny had gekregen waarom ze gevraagd had, maar dat bleek niet te zijn wat ze eigenlijk had gewild. Het systeem kwam op de markt toen er inmiddels al concurrerende systemen waren verschenen en bleek daarom niet erg succesvol. Jenny besloot na een half jaar modderen er niet verder mee te werken. De assistent kon het woord computer niet meer horen. Al met al was het een teleurstellende ervaring geworden. De genoemde problemen hebben geleid tot andere ontwikkelmethoden, die de ontwikkeling opsplitsen in kleinere stappen. In de volgende paragraaf behandelen we een voorbeeld van zo’n iteratieve ontwikkelmethode. 2.4

Bij een iteratieve ontwikkelmethode wordt het systeem in stappen ontwikkeld. Aan het eind van iedere stap is er een werkend systeem dat in een volgende stap wordt uitgebreid. Er zijn verschillende iteratieve methoden. In deze paragraaf behandelen we er één die op dit moment sterk in de belangstelling staat: het Unified process. Onze behandeling daarvan beperkt zich tot enkele belangrijke aspecten en is daarom verre van volledig.

Unified process

Voortraject

Ook bij ontwikkeling volgens het Unified process is er een voortraject of opstartfase. Tijdens deze fase wordt vastgesteld waarom de betrokkenen vinden dat het systeem er moet komen. Ook wordt bekeken wat de grootste risico’s zijn en hoe die moeten worden aangepakt en wordt een begin gemaakt met het opstellen van de eisen. Voorbeelden

Iteratie

ITERATIEF ONTWIKKELEN: HET UNIFIED PROCESS

– Bij het systeem voor de Londense ambulancedienst zou het volgen van de ambulances als een belangrijke risicofactor kunnen worden aangemerkt. – Risico’s kunnen allerlei vormen aannemen. In het HIS van Paul en Jenny zou Paul bijvoorbeeld vast kunnen stellen dat het systeem binnen een jaar op de markt moet zijn, wil hij de concurrentie voor blijven, terwijl hij zelf slechts een beperkte hoeveelheid tijd tot zijn beschikking heeft. Het doorgaan van het project kan dan afhankelijk worden gemaakt van het snel vinden van een goede ontwerper. Het verschil tussen het Unified process en de watervalmethode zit niet in de activiteiten: ook in het Unified process wordt er aan analyse, ontwerp, implementatie, testen en oplevering gedaan. Het grote verschil is de organisatie van deze activiteiten. Die vinden bij het Unified process niet in onderscheiden fases na elkaar plaats. In plaats daarvan is het project opgedeeld in iteraties (herhalingen; meerdere malen doorlopen van een cyclus), waarbij in elke iteratie in principe aan al die activiteiten gewerkt kan worden. Welke onderdelen van het systeem daarbij voorrang krijgen, wordt onder meer gestuurd door de risicoanalyse: de meest riskante onderdelen van het systeem moeten het eerst voltooid worden. Iedere iteratie heeft een vaste, vooraf bepaalde lengte van bij voorkeur vier tot zes weken. We illustreren de iteratieve werkwijze aan de hand van het HISvoorbeeld.

OU

65


Eerste iteratie

Tijdens de opstartfase hebben Paul en Jenny al een eerste inventarisatie van de use cases gemaakt, maar zonder die erg ver uit te werken. Paul vraagt nu aan Jenny een of twee use cases te noemen die zij als de belangrijkste beschouwt. In de eerste iteratie werken zij één van deze use cases (bijvoorbeeld het maken van afspraken) tot in detail uit. Er wordt voor die use case ook meteen een gebruikersinterface ontworpen. Tegelijk vindt ook een stukje informatieanalyse plaats, beperkt tot wat nodig is voor het maken van afspraken. Naar de patiëntgegevens wordt daarbij bijvoorbeeld nog niet gekeken; een patiënt is voorlopig alleen een nummer. Aan het eind van de eerste iteratie is de use case ‘afspraken maken’ tot in detail uitgewerkt. Er is ook een scherm ontworpen en geïmplementeerd voor deze use case. Die gebruikersinterface is nog wel ‘namaak’: er zit geen informatiebank achter. Toch krijgt de assistent een redelijk idee hoe het maken van afspraken in zijn werk zal gaan.

Tweede iteratie

In de volgende iteratie wordt verder gewerkt aan het deelsysteem voor het maken van afspraken. De interface wordt op verzoek van Jenny en de assistent op een aantal punten aangepast. Er wordt een database geconstrueerd waarin de afspraken kunnen worden vastgelegd, en die wordt opgenomen in het systeem. Jenny en Paul werken ondertussen verder aan de use cases en de informatieanalyse. In deze iteratie werken ze twee use cases in detail uit: het opvragen van patiëntgegevens en het invoeren van een nieuwe diagnose. Aan het eind van deze iteratie is er een systeem waarmee daadwerkelijk afspraken gemaakt kunnen worden (voor patiënten met alleen een nummer). Ook is de informatieanalyse voor de patiëntgegevens voltooid en is er een interface gebouwd voor het opvragen daarvan. Het was de bedoeling geweest om ook al zo’n interface te maken voor het invoeren van een nieuwe diagnose, maar dat is niet gelukt: dat schuift door naar een volgende iteratie.

Derde iteratie

Aan het eind van de derde iteratie is er een systeem waarmee afspraken gemaakt kunnen worden en dat per spreekuur een lijst toont van de patiënten die daar zijn gepland. Klikken op een patiënt leidt tot het tonen van de gegevens (patiënten zijn dus niet langer alleen nummers). Op die manier blijft het systeem, iteratie voor iteratie, verder groeien. In de loop van de iteraties verschuift wel de nadruk. In het begin van de ontwikkeling wordt veel aandacht besteed aan het uitwerken van de use cases. Na verloop van tijd wordt dat wel minder en ligt de nadruk vooral op het bouwen en testen. Maar ook op driekwart van het project kunnen er nog wijzigingen in de eisen optreden (al zullen bepaalde wensen dan niet meer te realiseren zijn omdat ze de hele opzet van het systeem zouden veranderen). Figuur 2.8 toont een mogelijk verloop van een project volgens het Unified process. Voor elke activiteit laat de figuur zien hoe de tijd die daaraan besteed wordt in de loop van het project verandert. Zo zien we dat aan bedrijfsmodellering (onderdeel van de analyse) vooral gewerkt wordt in de eerste drie iteraties, en wel het meest in de tweede. Geïmplementeerd en getest wordt er gedurende het hele project, al is dat in de eerste iteraties wat minder dan later. De tijd besteed aan projectmanagement is het grootst in het begin, als het project goed op poten moet worden gezet, en aan het eind, als de opleverdatum nadert en de teugels dus strak moeten worden aangetrokken.

66

OU


FIGUUR 2.8

UML

In iedere iteratie kan elke activiteit gedaan worden

Het Unified process omvat niet alleen deze ontwikkelmethode, maar ook een aantal technieken. Het gebruik van use cases voor het vastleggen van eisen is daar één van. Ontwerp en implementatie zijn objectgeoriënteerd, met als belangrijk gereedschap de objectgeoriënteerde modelleertaal UML (Unified Modeling Language). In de volgende leereenheden komen we terug op de objectgeoriënteerde technieken gebruikt in het Unified process. Voordelen van deze iteratieve manier van ontwikkelen boven de watervalmethode zijn de volgende. – Omdat niet alle eisen vooraf worden vastgelegd en de gebruikers met het groeiende systeem kunnen werken, is de kans groter dat het uiteindelijke systeem ook is wat de opdrachtgever wilde hebben. – Er wordt eerder duidelijkheid verkregen over riskante onderdelen van het systeem, omdat daar prioriteit aan wordt gegeven. – De complexiteit blijft beheersbaar. Omdat per iteratie gepland wordt, kan bij ontwikkeling volgens het Unified process niet vooraf gegarandeerd worden in welke tijd tegen welke kosten er wat gebouwd wordt. Dat is een nadeel, omdat geen opdrachtgever akkoord gaat met de mededeling ‘we bouwen het, maar hebben geen idee hoe lang het gaat duren en wat het gaat kosten’. Aanhangers van het Unified process stellen daar (niet ten onrechte) tegenover, dat de zekerheid die andere methoden bieden, slechts schijn is: vrijwel alle projecten gaan immers over de geplande tijd en de geplande kosten heen. Bij het afsluiten van een contract zal daar echter toch iets over vastgelegd moeten worden, ook bij ontwikkeling volgens het Unified process. 3

Model

Modellen en modelleren

Bij de ontwikkeling van een informatiesysteem wordt, ongeacht de gevolgde methode, gebruikgemaakt van modellen. Zo wordt er bij gebruik van het Unified process een model opgesteld van de bedrijfsvoering (bedrijfsmodellering). De informatieanalyse mondt uit in een

OU

67


informatiemodel. De eisen worden gepresenteerd in de vorm van use cases, die samen het use-casemodel vormen, en voor het ontwerp wordt een objectgeoriënteerd model gemaakt. Het is daarom goed om even stil te staan bij wat een model eigenlijk precies is. Voorbeelden

Figuur 2.9 toont drie voorbeelden van modellen. Links is een maquette van een huis getoond, in het midden een organigram waarin de structuur van een organisatie wordt weergegeven en rechts een wiskundige formule waarmee de totale vertraging berekend kan worden die wordt veroorzaakt door een rood verkeerslicht.

FIGUUR 2.9

Drie voorbeelden van modellen

Deze drie voorbeelden illustreren het belangrijkste kenmerk van een model: het is een vereenvoudigde weergave van een deel van de werkelijkheid of van een (eventueel nog te bouwen) systeem. Bij het opstellen van een model wordt dus altijd iets weggelaten, ofwel: modellen zijn altijd abstracties. Het zijn brillen die worden opgezet om bepaalde aspecten van de werkelijkheid beter te kunnen zien, ten koste van andere. Een goed model is een model dat het doel van de maker dient. Modellen staan soms ver van de werkelijkheid af. Van een atoommodel weten we niet eens zeker of het de werkelijkheid representeert. We kunnen hooguit vaststellen of het bepaalde experimentele resultaten kan voorspellen. De modellen die we maken in de analyse- en ontwerpfase, hoeven ook geen objectieve weergave te zijn van de werkelijkheid; als we ze maar kunnen gebruiken voor de beoogde doelen. Een model is dus altijd een maaksel (artefact) van een persoon, die zijn of haar eigen keuzes in het model heeft gelegd. Ontwerpers moeten zichzelf dus niet beschouwen als waarnemers die objectief proberen te beschrijven waar het om gaat. Integendeel, ontwerpers zijn actieve participanten, die eigen keuzes maken, die ze kunnen onderbouwen en verdedigen. Welke aspecten naar voren worden gehaald en welke juist worden weggelaten, hangt dus af van het doel waarmee het model gemaakt is.

Modellen zijn abstracties

OPGAVE 2.12

a Welk deel van de werkelijkheid wordt door de modellen in figuur 2.9 gemodelleerd? b Wat zou het doel kunnen zijn waarvoor deze modellen gemaakt zijn? c Bedenk voor elk van deze modellen een aspect van de werkelijkheid dat in het model is weggelaten en een bijbehorend doel waarvoor dit model daardoor ongeschikt is. Een model kan naast de doelen genoemd in opgave 2.12 ook dienen om een verandering in de werkelijkheid te sturen. Een goed voorbeeld is een organigram, zoals getoond in figuur 2.9. Als besloten wordt de structuur

68

OU


van de organisatie te wijzigen, dan wordt die verandering eerst beschreven in (onder meer) een nieuw organigram en dan pas geïmplementeerd. Het model beschrijft dan een toekomstige of gewenste werkelijkheid. Informatiesystemen bevatten modellen. Een administratief systeem beheert informatie die betrekking heeft op een deel van de realiteit. Dat deel noemen we het domein van het informatiesysteem. Binnen het informatiesysteem bevindt zich een model van dat domein.

Domein

Voorbeelden

Als voorbeelden kijken we naar de informatiesystemen uit paragraaf 1. – Het domein van het HIS bevat onder meer de patiënten die zijn ingeschreven bij een bepaalde praktijk en de medicijnen die in die praktijk worden voorgeschreven. Het overeenkomstige model binnen het systeem bevindt zich in de database. Er vindt abstractie plaats. Van een patiënt worden wel naam, adres, geboortedatum en ziektegeschiedenis vastgelegd, maar niet de precieze toestand van het gebit, het inkomen of de toneelvoorstellingen die deze bezocht heeft. – Tomb Raider is een interessant geval. Het systeem bevat wel degelijk een model; als de speler Lara Croft een deur door laat gaan, dan moet het systeem kunnen opzoeken waar ze dan terechtkomt. Dit is echter een model van een fictieve werkelijkheid die (anders dan bij maquettes) nooit gerealiseerd hoeft te worden. Het is aan de makers van het spel om te beslissen in hoeverre ze zich in deze fictie aan de normale natuurwetten houden (we verwachten dat als Lara door een bepaalde deur gaat, ze steeds in dezelfde ruimte terecht komt, maar de makers kunnen daar moeiteloos van afwijken). De vraag waaruit de abstractie bestaat, dus wat er wordt weggelaten, verliest daarmee tot op zekere hoogte zijn geldigheid. – Het domein van de betaalautomaat bevat ook personen. In het model worden van hen alleen de bestedingsruimte (het rekeningsaldo vermeerderd met het bedrag dat ze rood mogen staan) en de bedragen van aan- en verkopen vastgelegd. Alle andere persoonskenmerken zijn weggelaten. – Het ingebedde besturingssysteem van de industriële robot ten slotte bevat voor elke vaste serie bewegingen (een onderdeel van de realiteit) een model van die bewegingen. Deze worden getransformeerd en vervolgens zo vastgelegd dat de robot ze later (afgezien van de snelheid en eventuele onregelmatigheden) weer precies zo uit kan voeren. Er vindt hier dus nauwelijks abstractie plaats.

OPGAVE 2.13

Vermoedelijk hebt u wel eens gewerkt met een routeplanner, bijvoorbeeld van de ANWB. U voert daarin een vertrekpunt en een bestemming in en krijgt dan een nauwkeurige routebeschrijving, inclusief tijdschattingen en kaartjes. a Wat is het domein van dit systeem? b Noem elementen daarvan die binnen het systeem zijn gemodelleerd, en enkele elementen die zijn weggelaten. Het zal duidelijk zijn dat het construeren van een goed model van het grootste belang is voor informatiesystemen. Een goed model bevat alle informatie die nodig is om de beoogde taak uit te kunnen voeren, maar bevat geen overbodige informatie (waarbij informatie die mogelijk in de toekomst nodig is, niet als overbodig moet worden beschouwd).

OU

69


De informatie moet bovendien op juistheid en consistentie gecontroleerd zijn en daarom bij voorkeur in een vorm zijn gegoten die een dergelijke controle vergemakkelijkt. Bedrijfsmodellering bestaat voor een deel uit het opstellen van modellen van het domein, waarbij zowel de huidige als de beoogde nieuwe situatie in kaart moet worden gebracht en niet alleen het systeem, maar ook de omgeving bij de modellering betrokken moet worden.

Ontwerpmodel

Ook bij het ontwerp van de programmatuur wordt een model opgesteld, maar dit keer is dat geen model van de realiteit, maar van het systeem. In dat ontwerpmodel ligt de nadruk op de structuur van de software en de manier waarop de verschillende delen van die software met elkaar kunnen communiceren. 4

Vooruitblik

In deze paragraaf kijken we kort vooruit naar de overige leereenheden in dit blok. In de leereenheden 3 tot met 5 kijken we naar het ontwikkelen van administratieve informatiesystemen. De belangrijkste taak van zulke systemen is het bewaren, bewerken en tonen van informatie. De informatiebank staat in deze systemen centraal en daarvoor wordt in de praktijk meestal een relationele database toegepast. We kijken daarom in de leereenheden 3 tot en met 5 naar het ontwikkelen en gebruiken van een relationele database. In leereenheid 3 komt theorie aan de orde rondom relationele databases, waarbij vooral aandacht is aan het structureren van informatie in tabellen. In leereenheid 4 gaat u in een practicum zelf met een relationeel databasesysteem aan de slag. In leereenheid 5 laten we enkele aspecten zien van een iteratieve ontwikkelmethode om administratieve systemen met een relationele database te ontwikkelen. In de leereenheden 6 tot met 9 kijken we naar het objectgeoriënteerd ontwikkelen van informatiesystemen volgens het Unified process. Voor het ontwikkelen van een informatiebank in een administratief systeem is deze methode niet geschikt. Het Unified process is wel geschikt voor de ontwikkeling van de overige delen van een administratief informatiesysteem, evenals voor het ontwikkelen van andere soorten informatiesystemen waarin geen informatiebank nodig is. In leereenheid 6 staat de analysefase in objectgeoriënteerd ontwikkelen met het Unified process centraal, en in leereenheid 7 de ontwerpfase. In de leereenheden 8 en 9 komen de basisprincipes van objectgeoriënteerd implementeren met een programmeertaal aan de orde. De leereenheden 2 tot en met 9 vormen samen het blok systeemontwikkeling. In deze leereenheden komen veel principes, methoden en technieken aan de orde, afgewisseld met talloze voorbeelden. Op een aantal plaatsen behandelen we de leerstof vrij diep, en op andere plaatsen blijven we wat oppervlakkig. Het is niet dat de bedoeling van deze cursus dat u al die methoden en technieken zelfstandig kunt toepassen op complexe systemen. In de meeste gevallen volstaat dat u ze kunt toepassen op zeer eenvoudige voorbeeldsystemen, of een gegeven complexer voorbeeld kunt begrijpen. Let daarom vooral goed op de leerdoelen zoals die in het begin van elke leereenheid vermeld staan.

70

OU


SAMENVATTING Paragraaf 1

We hebben definities gegeven van een systeem (een verzameling componenten die samenwerken om bepaalde doelen te verwezenlijken) en van een informatiesysteem (een systeem waarvan de doelen uitsluitend bereikt worden door het bewerken van informatie). Informatie moet daarbij opgevat worden als betekenisvolle gegevens. Een informatiesysteem hoeft niet per se geautomatiseerd te zijn. Aan de hand van vier voorbeelden van informatiesystemen hebben we kennisgemaakt met belangrijke mogelijke kenmerken. Een informatiesysteem waarbij het bewaren en beheren van potentieel grote hoeveelheden informatie centraal staat, heet administratief. Een informatiesysteem waarbij de respons op aangeboden informatie binnen een vooraf vastgestelde tijd moet zijn gegenereerd om van correct functioneren te kunnen spreken, heet een real-timesysteem. Een informatiesysteem waarin (bepaalde) fouten tot onacceptabele schade leiden, heet een kritisch systeem. Een informatiesysteem waarin verschillende computers en andere apparaten met elkaar moeten samenwerken, heet een gedistribueerd systeem. Een informatiesysteem dat deel uitmaakt van een apparaat dat zelf geen informatiesysteem is, heet een embedded system.

Paragraaf 2

Projecten waarin informatiesystemen ontwikkeld worden, mislukken regelmatig of leveren onbruikbare systemen af. Deze problematiek staat bekend als de softwarecrisis. De grootste problemen zijn enerzijds dat de kwaliteit van de software onder de maat is, en anderzijds dat budgetten voor tijd en geld voor het ontwikkelen worden overschreden. Initieel werden problemen veroorzaakt door de stormachtige ontwikkeling van computerhardware, waardoor steeds complexere software ontwikkeld kon worden. Het vakgebied software engineering houdt zich bezig met de ontwikkeling van methoden en technieken die gebruikt kunnen worden bij het ontwikkelen van informatiesystemen. Een methode beschrijft welke taken er zijn bij die ontwikkeling en hoe die taken georganiseerd moeten worden; een techniek is een stuk gereedschap voor een van die taken. Een van de oudste ontwikkelmethoden is de watervalmethode, waarbij de ontwikkeling wordt gesplitst in verschillende fases. Het doel van de analysefase is vaststellen wat er ontwikkeld moet worden. Activiteiten in deze fase zijn bedrijfsmodellering, informatieanalyse en het opstellen van de eisen. De analysefase wordt afgesloten met een eisendocument of specificatie. Het doel van de ontwerpfase is vast te stellen hoe de gebruikersinterface, de informatiebank (de database) en de software gebouwd gaan worden. Deze fase wordt afgerond met een ontwerpdocument, dat als bouwtekening van het systeem kan fungeren. Het doel van de implementatiefase is het systeem daadwerkelijk te bouwen en (getest en wel) op te leveren. Daarna moet het systeem nog regelmatig onderhouden worden; in de praktijk is dit onderhoud verantwoordelijk voor zo’n 75 % van de kosten. Aan de watervalmethode kleven nogal wat nadelen. De eisen worden te vroeg bevroren, er ontstaat pas aan het eind duidelijkheid over de haalbaarheid van riskante onderdelen van het project en vrijwel alle projecten worden te laat en met overschrijding van het budget opgeleverd. Iteratieve methoden proberen deze nadelen te ondervangen. Bij zulke methoden wordt het systeem in stappen ontwikkeld, met aan het eind van elke stap een werkend systeem dat steeds verder

OU

71


uitgebouwd wordt. Een voorbeeld van een iteratieve methode is het Unified process. Binnen deze methode worden objectgeoriënteerde technieken gebruikt, waarbij zowel het te modelleren bedrijf als het systeem wordt opgevat als een verzameling samenwerkende objecten. Ook het gebruik van use cases voor het opstellen van eisen maakt deel uit van het Unified process. Paragraaf 3

Alle methoden voor systeemontwikkeling gebruiken modellen. Een model is een vereenvoudigde weergave van een deel van de werkelijkheid of van een te bouwen systeem. Bij het opstellen van een model wordt altijd informatie weggelaten. Informatiesystemen bevatten veelal een model van een deel van de werkelijkheid. Het gemodelleerde deel van de werkelijkheid noemen we het domein van het systeem.

Paragraaf 4

Zaken die in deze leereenheid kort aan de orde zijn gekomen, worden later in dit blok uitgebreider behandeld. De leereenheden 3 tot en met 5 concentreren zich op administratieve systemen. In leereenheid 3 bekijken we wat een relationele database is, leereenheid 4 bevat een practicum met een relationele database en in leereenheid 5 behandelen we een iteratieve ontwikkelmethode. De leereenheden 6 en 7 behandelen technieken die binnen het Unified process worden gebruikt. Leereenheid 6 gaat over analyse, in het bijzonder over use cases en objectgeoriënteerde modellering. Leereenheid 7 gaat over objectgeoriënteerd ontwerp. De leereenheden 8 en 9 ten slotte gaan over implementatie; in deze leereenheden leert u eenvoudige programma’s te schrijven in een objectgeoriënteerde programmeertaal.

ZELFTOETS

72

1

a Geef de betekenis van de volgende termen: embedded system, realtimesysteem, kritisch systeem. b Is een informatiesysteem altijd volledig geautomatiseerd? Licht uw antwoord toe.

2

a Wat wordt bedoeld met de term softwarecrisis? b Wat is het doel van het vakgebied software engineering?

3

a Welke drie ontwikkelingsfasen worden onderscheiden in de watervalmethode? Omschrijf kort de doelstelling van deze fasen. b Noem enkele nadelen van de watervalmethode. c Hoe worden deze nadelen ondervangen in iteratieve methoden?

4

Waarom kan van een deel van de werkelijkheid geen model gemaakt worden zonder eerst het doel van dat model te kennen? Illustreer dit met als voorbeeld een landkaart (een model van een land).

OU


TERUGKOPPELING 1

Uitwerking van de opgaven

2.1

Hoewel het niet uitgesloten is dat op den duur een deel van de diagnostiek geautomatiseerd zou kunnen worden, is het vervangen van de huisarts door een computersysteem niet wenselijk. Het doel van een bezoek aan een huisarts is niet zuiver medisch, maar ook sociaal, en een goede huisarts haalt belangrijke informatie niet altijd alleen uit wat expliciet wordt gezegd.

2.2

a, b Figuur 2.10 toont de twee mogelijke structuren.

FIGUUR 2.10

Twee mogelijke structuren voor het inlichtingensysteem

c In het tweede geval bevat het systeem minstens twee deelsystemen, namelijk het spraaksysteem en het opzoeksysteem. Diezelfde functies zijn natuurlijk ook in het eerste systeem aanwezig, maar worden in dat geval allebei uitgevoerd door de telefonist. We zouden deze ook een deelsysteem kunnen noemen, maar dat is bij een persoon niet gebruikelijk. 2.3

We noemen vier verschillen. – Het HIS is geconstrueerd ter ondersteuning van een proces in de buitenwereld, met verschillende belanghebbenden (huisarts, assistent, patiënt). Om zo’n systeem te kunnen construeren, is een goed begrip van dat proces nodig en inzicht in de rollen van alle betrokkenen. Voor Tomb Raider geldt dat niet: het succes van het spel ligt alleen in het spel zelf. Er is geen proces in de buitenwereld dat ondersteund moet worden. – Tomb Raider moet snel genoeg zijn om direct te kunnen reageren op alle invoer die de gebruiker vanaf het toetsenbord geeft. Uiteraard is snelheid ook bij het HIS niet onbelangrijk, maar er is daar geen risico dat het programma zo achter raakt op de gebruiker dat opdrachten van de gebruiker verloren gaan. – Bij Tomb Raider speelt de grafische kant een hoofdrol: het spelplezier is voor een aanzienlijk deel afhankelijk van de grafische vormgeving. Hoewel ook de vormgeving van de gebruikersinterface van het HIS veel kan bijdragen aan de bruikbaarheid van het systeem, is deze niet zo bepalend als bij een computerspel. – Bij Tomb Raider lijken er steeds veel dingen tegelijk te gebeuren. Niet alleen beweegt Lara onder besturing van de speler, er zijn ook nog allerlei andere spelfiguren die ondertussen door de computer bestuurd worden (en die daarbij reageren op de acties van Lara). Er zijn binnen het systeem dus verschillende, onderling afhankelijke processen, die schijnbaar tegelijk worden uitgevoerd. Bij het HIS is daar nauwelijks sprake van.

OU

73


2.4

Het belangrijkste verschil is dat de betaalautomaat weliswaar een eenvoudig systeem is, maar in verbinding staat met vele andere systemen in de betaalketen. Elk onderdeel in die betaalketen is nodig om een elektronische betaling te kunnen uitvoeren. Als we die totale betaalketen als een enkel systeem beschouwen, is dat een zeer veel groter en complexer systeem dan de voorgaande twee voorbeelden. Dit systeem draait niet op één computer, maar is verspreid over verschillende computers en betaalautomaten door heel Europa. Het systeem moet transacties juist verwerken en het moet (vrijwel) altijd beschikbaar zijn. Het kan voorkomen dat een pintransactie een keer mislukt, maar het mag niet voorkomen dat het betalingsverkeer dagen stil ligt. Het systeem moet bovendien zeer betrouwbaar zijn en bescherming bieden tegen frauduleuze handelingen van criminelen. Schaalgrootte, geografische spreiding, beschikbaarheid, betrouwbaarheid en veiligheid spelen in dit systeem dus een veel grotere rol dan in de twee vorige voorbeelden.

2.5

a De gebruiker van de robot heeft als doel het verpakken van diepvriesproducten vanaf een lopende band in dozen. De robot werkt volledig autonoom. Er is geen gebruiker bij betrokken die tijdens het inpakken direct met de robot communiceert. Dat geldt zowel voor de robot in zijn geheel, als voor de deelsystemen van de robot. Het doel van het detectiesysteem is de locatie van een product op een lopende band te detecteren. Het doel van het besturingssysteem is om het product op te pakken en in een doos te plaatsen. Verder moet het besturingssysteem deels geprogrammeerd worden. De betrokkene bij dit deelsysteem is de programmeur die de beweging van de robot programmeert om een product in een doos te plaatsen. Zijn doel is een zo eenvoudig mogelijke manier om de robot te (her)programmeren. b Het detectiesysteem heeft als invoer de beelden die de camera registreert. Het systeem bewerkt deze beelden om producten op de lopende band te detecteren. De uitvoer bestaat uit informatie die de locatie van een product aangeeft. Het besturingssysteem neemt de uitvoer van het detectiesysteem als invoer. Aan de hand van die informatie genereert het systeem besturingsinformatie die de robotarm laat bewegen. c Bij het detectiesysteem zijn geen mensen betrokken. Bij het besturingssysteem is de programmeur betrokken. d Deze informatiesystemen zijn ingebouwd in een apparaat met een specifiek doel, het zijn geen programma’s die op een willekeurige computer geïnstalleerd kunnen worden. De informatiesystemen zijn onderdelen van een systeem (de robot) dat zelf geen informatiesysteem is. De informatiesystemen werken autonoom, zonder interactie met een menselijke gebruiker of andere informatiesystemen.

2.6

74

Een betaalautomaat is geen real-timesysteem. Het is gewenst dat een elektronische betaling zo snel mogelijk wordt uitgevoerd, maar het maakt niet veel uit of dat 3 of 5 seconden duurt. De grootste vertraging wordt veroorzaakt door de communicatie met de transactieverwerkende organisatie en de banken, waar de betaalautomaat zelf weinig invloed op kan uitoefenen.

OU


De transactieverwerkende organisatie kunnen we wel als een realtimesysteem beschouwen. Dat systeem moet transacties kunnen verwerken in het tempo waarin ze worden aangeboden. 2.7

Het navigatiesysteem in een personenauto kan het best beschouwd worden als een real-timesysteem. Immers, als we een bestemming opgeven, verwachten we dat het navigatiesysteem binnen enkele ogenblikken de route naar die bestemming berekent. Als we een afslag of splitsing naderen, moet het systeem op dat moment de juiste aanwijzing geven, en niet minuten van tevoren of als de afslag of splitsing al gepasseerd is. Ook als we de aanwijzing niet opvolgen en een andere weg kiezen, verwachten we dat het systeem binnen enkele ogenblikken met een nieuwe route komt. Het is geen embedded systeem. We kunnen het weliswaar beschouwen als een apart systeem in de auto, maar het is geen essentieel onderdeel van de auto. De auto kan immers net zo goed zonder navigatiesysteem functioneren. Een navigatiesysteem in een vliegtuig beschouwen we daarentegen wel als een embedded systeem. Het is geen administratief systeem, omdat de hoofdtaak van het systeem niet is om gegevens op te slaan en te beheren. Het systeem is niet kritisch. Als het systeem verkeerd functioneert, bijvoorbeeld door de verkeerde weg te wijzen, is dat vervelend maar dat leidt doorgaans niet tot een onoverkomelijk probleem.

2.8

Het is een kritisch systeem omdat er met het tijdig arriveren van een ambulance mensenlevens gemoeid zijn. Het is ook gedistribueerd, bijvoorbeeld vanwege het autovolgsysteem dat er deel van uitmaakt. Het is eveneens een real-timesysteem omdat het de binnenkomende telefoontjes bij moet houden.

2.9

Voorbeelden van use cases van Tomb Raider zijn het starten van een nieuw spel, het opslaan van het huidige spel, het openen van een eerder opgeslagen spel en het laten lopen, rennen of springen van Lara.

2.10

Tomb Raider zou bijvoorbeeld objecten kunnen bevatten voor Lara en voor de andere spelfiguren (zoals de vijanden die verslagen moeten worden), voor de voorwerpen die gevonden en gebruikt kunnen worden en voor onderdelen in het landschap waarin Lara zich bevindt (zoals deuren die open en dicht kunnen).

2.11

a Dit is een onderdeel van het testen van het systeem en dus van de implementatiefase. b Als dit na oplevering gebeurt, behoort het tot de onderhoudsfase, anders tot de implementatiefase. Hoe ingrijpend een dergelijke verandering is, hangt sterk af van de manier waarop het systeem geïmplementeerd is; probleemloos zal zo’n verandering nooit zijn. c

Implementatie.

d Analyse (wat moet het systeem gaan doen). e

Analyse (in kaart brengen van de huidige bedrijfsprocessen).

f

Ontwerp.

OU

75


2.12

a De maquette modelleert een bepaald type huis (niet per se een specifiek huis), het organigram is een model van een organisatie en de formule modelleert een proces, en wel de doorstroming van het verkeer wanneer een stoplicht op rood springt. b Een maquette geeft een beeld van het huis vóór het daadwerkelijk gebouwd is, bijvoorbeeld aan belangstellende kopers. Het organigram toont de structuur van de organisatie: de belangrijkste afdelingen en de communicatie daartussen. De formule maakt het mogelijk om uit te rekenen wat het effect is van de plaatsing van een stoplicht en kan dus een rol spelen in het bepalen van het verkeersbeleid in een bepaalde buurt. c Er zijn vele goede antwoorden mogelijk; we geven hier een voorbeeld daarvan. Een maquette toont niet de precieze constructie van het huis en de gebruikte materialen en is daardoor ongeschikt om uit te zoeken of de muren het dak wel zullen houden, of om de bouwkosten te berekenen. Een organigram laat niet zien wie er in de organisatie werken en helpt dan ook niet als u een bepaald iemand wilt spreken. U hebt dan meer aan een telefoonlijst (ook een model van de organisatie). De formule zegt alleen iets over de vertraging die optreedt bij het stoplicht, maar bijvoorbeeld niets over de snelheid of de remweg van de auto’s. U hebt er dus niets aan als u wilt bepalen hoe lang een stoplicht op oranje moet staan.

2.13

a Het domein van de ANWB-routeplanner is het Europese wegen- en stratennet. b Binnen het systeem is een schaalmodel van dat wegennet opgenomen, waarin de loop van de wegen, de punten waarop ze elkaar kruisen, de afstanden tussen die punten en het type van elke weg is vastgelegd. In de kaartjes is verder informatie gemodelleerd over de omgeving van de wegen (steden, bossen, water, ...). Het model bevat geen details van de wegen (waar hangen precies welke verkeersborden, waar zijn stoplichten) en de bebouwing (waar zijn geluidswallen, welke winkels zitten er langs de straten) en ook geen file-informatie (waardoor de aangegeven reistijden in de praktijk veel hoger uit kunnen vallen). 2

1

Uitwerking van de zelftoets

a Een embedded system is een informatiesysteem dat deel uitmaakt van een apparaat dat zelf geen informatiesysteem is. Een real-timesysteem is een informatiesysteem waarbij de respons op aangeboden informatie binnen een vooraf vastgestelde tijd moet zijn gegenereerd om van correct functioneren te kunnen spreken. Een kritisch systeem is een informatiesysteem waarin (bepaalde) fouten tot onacceptabele schade leiden. b Nee. Het kenmerk van een informatiesysteem is dat het informatie bewerkt. Die informatie kan ook op kaarten geschreven zijn en door mensen bewerkt worden. Die ruimere blik is van belang omdat een geautomatiseerd systeem altijd in een bepaalde omgeving functioneert (die zelf ook weer een informatiesysteem kan zijn). Vooral bij bedrijfsmodellering wordt naar die omgeving gekeken.

76

OU


2

a De term softwarecrisis duidt op de problemen rondom de ontwikkeling van (deels) mislukte informatiesystemen. Er worden regelmatig systemen opgeleverd van onvoldoende kwaliteit, die niet goed werken of niet aansluiten bij de wensen van gebruikers. Tevens worden de geraamde kosten en ontwikkeltijd vaak overschreden. De oorsprong van de problematiek is het achterblijven van de kwaliteit van de software bij de mogelijkheden van de hardware. b De belangrijkste doelstelling van het vakgebied software engineering is het bedenken van methoden en technieken die gebruikt kunnen worden voor de ontwikkeling van informatiesystemen.

3

a Het doel van de analysefase is vaststellen wat er ontwikkeld moet worden. Activiteiten in deze fase zijn bedrijfsmodellering, informatieanalyse en het opstellen van eisen. Het doel van de ontwerpfase is vast te stellen hoe het systeem gebouwd gaat worden. Het doel van de implementatiefase is het systeem daadwerkelijk bouwen en (getest en wel) opleveren. b Het bevriezen van de eisen aan het eind van de analysefase blijkt in de praktijk vrijwel onmogelijk. Er ontstaat pas aan het eind duidelijkheid over de haalbaarheid van riskante onderdelen van het project. Vrijwel alle projecten worden te laat en met overschrijding van het budget opgeleverd. c Bij iteratieve methoden worden de eisen pas in de loop van het project tot in detail uitgewekt en kunnen daarom ook nog lang gewijzigd worden. Riskante onderdelen kunnen al in een vroeg stadium gebouwd worden. Blijkt iets echt niet haalbaar, dan kan het project tijdig worden afgeblazen. Iteratieve methoden lossen het probleem van de late oplevering slechts beperkt op: omdat er slechts enkele iteraties vooruit wordt gepland, is niet volledig duidelijk wanneer precies wat zal worden opgeleverd.

4

Modellen vereenvoudigen de werkelijkheid en laten dus dingen weg. Wat kan worden weggelaten, is volledig afhankelijk van het doel van het model. Wegenkaarten voor automobilisten hebben veelal een schaal van minstens 1 : 500 000, vertonen geen of nauwelijks landschapskenmerken (bebouwing, hoogtelijnen) en laten onverharde wegen weg. Een wandelkaart heeft een schaal van 1 : 50 000 of kleiner, toont alle wegen en paden en alle landschapskenmerken.

OU

77

Inhoud leereenheid 2. Systemen en systeemontwikkeling. Introductie 43. Leerkern 44. Samenvatting 71. Zelftoets 72

Recommend Documents