Uitwerkingen ASL

Uitwerkingen van de opdrachten bij Applicatiebeheer volgens ASL

Peter Janssen Pearson Education Benelux

ISBN 90-430-0883-4

Uitwerkingen en antwoorden bij Applicatiebeheer volgens ASL, Peter Janssen

© Pearson Education Benelux Pagina 2

Inhoudsopgave:

Toelichting op de antwoorden..............................................................................................3

Hoofdstuk 1 Informatiesystemen ...................................................................................4

Hoofdstuk 2 Beheer van informatiesystemen ................................................................6

Hoofdstuk 3 Organisatie van het beheer........................................................................9

Hoofdstuk 4 Procesmatige aanpak van het applicatiebeheer......................................11

Hoofdstuk 5 De beheerprocessen .................................................................................14

Hoofdstuk 6 De verbindende processen.......................................................................18

Hoofdstuk 7 Onderhoud en vernieuwing.....................................................................21

Hoofdstuk 8 De sturende processen .............................................................................25

Hoofdstuk 9 ACM.........................................................................................................29

Hoofdstuk 10 OCM ........................................................................................................32

Hoofdstuk 11 Application Management volgens ITIL..................................................36

Hoofdstuk 12 Testen van informatiesystemen...............................................................40

Modelexamen 1 ..............................................................................................................42

Modelexamen 2...................................................................................................................43



Toelichting op de antwoorden Dit document bevat de antwoorden die horen bij de opgaven uit het boek “Applicatiebeheer volgens ASL”, ISBN 90-430-0883-4, uitgegeven door Pearson Education Benelux. Per hoofdstuk uit het boek wordt achtereenvolgens een antwoordindicatie gegeven van de vragen en opdrachten bij de casus, de open vragen, de waar/niet waar vragen en de meerkeuzeopgaven. Ook worden de antwoorden van de beide modelexamens gegeven. Bij de antwoorden op de vragen bij de casussen hoort de kanttekening dat de casussen vooral bedoeld zijn voor discussie in de klas of in een groep. De verstrekte antwoorden moeten dan ook slechts worden gezien als een richtlijn. Naast de gegeven antwoorden zijn ook andere antwoorden mogelijk, dit ter beoordeling van de docent of de groep waarin de casussen worden besproken. Naast de beide modelexamens achterin het boek kunnen tegen betaling andere modelexamens worden aangevraagd bij de stichting EXIN, de organisatie die in Nederland de ASL-examens afneemt. De modelexamens kunnen telefonisch (030-2344811) of via de website van EXIN (www.exin.nl) worden aangevraagd. Deze antwoordindicatie en het boek zijn met de grootste zorg samengesteld. Het is echter onvermijdelijk dat er zowel in het boek als in de antwoordindicatie fouten staan. Docenten en studenten worden verzocht deze fouten te melden bij de auteur, liefst via e-mail: [email protected], zodat deze bij een herdruk kunnen worden verbeterd en andere docenten en studenten nóg prettiger met het boek zullen werken. Amsterdam, 14 november 2005 Peter Janssen



Hoofdstuk 1 Informatiesystemen Vragen en opdrachten met betrekking tot de casus: 1. ZorgPlan en ZorgPak. 2. ZorgPlan is een decentraal informatiesysteem dat op een locale server is geïnstalleerd en

draait onder Windows. Het informatiesysteem is toegankelijk via pc’s. 3. ZorgPak is een centraal informatiesysteem, dat draait op een IBM-mainframe en

toegankelijk is via pc’s met terminalemulatie. 4. ZorgPlan wordt gebruikt om per vestiging roosters te maken voor de planning van de

zorg. 5. ZorgPak wordt gebruikt voor de administratie van de zorg, er kunnen declaratie mee

worden verstuurd naar de aangesloten ziekenfondsen en particulieren. 6. ZorgPak ZorgPlan

administratie planning centraal informatiesysteem decentraal informatiesysteem draait op IBM-Mainframe draait onder Windows toegankelijk via pc’s met terminalemulatie toegankelijk via pc’s

7. In eerste instantie is er sprake van nieuwbouw, dit wordt echter afgeraden, waarna er voor wordt gekozen het bestaande systeem aan te passen, te wijzigen.

8. In de casus is sprake van (delen van) informatieplanning, ontwikkeling, gebruik en wijziging.

9. Wijziging, acceptatie en invoering en gebruik. 10. Dan kunnen steeds kleine verbeteringen worden aangebracht in korte ontwikkeltrajecten

die in nauw overleg met de eindgebruikers tot stand komen. Open vragen: 1. Gegevens vormen de basis voor informatie, gegevens worden ingevoerd en verwerkt tot

informatie. 2. Een informatiesysteem bestaat uit een aantal onderdelen dat met elkaar samenwerkt om

gegevens te verwerken tot informatie. 3. Het doel van een informatiesysteem is te voorzien in de informatiebehoefte van een

organisatie. Deze informatie is nodig om de bedrijfsprocessen van een organisatie te besturen.

4. Een informatiesysteem bestaat uit de volgende componenten: apparatuur, programmatuur, gegevensverzamelingen, procedures en mensen.

5. Een informatiesysteem wordt gebruikt om de medewerkers van een organisatie te voorzien van informatie.

6. Een invoerapparaat wordt gebruikt om de gegevens in te voeren in een applicatie. Vervolgens worden de gegevens in het interne geheugen van de computer verwerkt tot informatie die op het scherm of via de printer aan de gebruiker wordt gepresenteerd. Voor de juiste verwerking zijn afspraken (procedures) nodig en mensen om te controleren of alles goed gaat.

7. Bij een centraal informatiesysteem worden alle gegevens op één plaats verwerkt en vervolgens naar de gebruikers gedistribueerd. De gegevens worden dus maar op één plaats bijgehouden. De PC wordt vooral decentraal gebruikt, dus de gegevens kunnen op meerdere plaatsen worden verwerkt met behulp van decentrale informatiesystemen.

8. Het rekencentrum. 9. Gebruikers hebben bij een decentraal systeem meer vrijheid dan bij een centraal

informatiesysteem, dus meer kans op ongelukken, storingen en virussen.



10. Informatiesystemen komen voort uit het beleid van een organisatie, een lange termijnplan dat de toekomstige ontwikkeling van de organisatie beschrijft. Dit organisatiebeleid wordt vervolgens vertaald in het informatiebeleid, dat de ontwikkeling van de informatieverzorging op de lange termijn beschrijft.

11. Het proces dat leidt tot een langetermijnvisie op de informatievoorziening, die wordt vastgelegd in een informatieplan.

12. Analyse, ontwerp en realisatie. 13. Informatieplanning, systeemontwikkeling, gebruik en beheer, evaluatie en bijsturing. 14. Informatieplanning, definitiestudie, functioneel ontwerp, technisch ontwerp, bouw,

invoering, gebruik en beheer. 15. SDM II verschilt van SDM I doordat de ontwerpfase is opgesplitst in een globaal ontwerp

en een detailontwerp, in plaats van het functionele en het technische ontwerp van SDM I. Het basisontwerp bevat zowel de functionele als de technische specificaties van het hele systeem. Het detailontwerp beschrijft hoe de verschillende subsystemen moeten worden ontwikkeld.

16. Een increment is een deel van een informatiesysteem. 17. Een informatiesysteem kent een levenscyclus, die loopt van de informatieplanning, via de

ontwikkeling, acceptatie en invoering naar gebruik en wijziging. Als het informatiesysteem wordt gewijzigd moet het opnieuw worden geaccepteerd en wordt het weer ingevoerd en gebruikt tot aan de volgende wijzigingsronde. Als het informatiesysteem niet meer aansluit bij de wensen van de gebruikers, wordt het uit productie genomen en gearchiveerd.

18. Zodra het informatiesysteem niet meer aansluit bij de wensen van de gebruikers. Waar/niet waar: 1. Niet waar, verwerken van gegevens tot informatie. 2. Waar 3. Waar 4. Waar 5. Waar 6. Niet waar, andersom. 7. Waar 8. Waar 9. Waar 10. Waar Meerkeuzeopgaven: 1. C 2. A 3. B 4. A, dat is het doel! 5. C 6. A 7. C 8. B 9. A 10. B 11. C 12. C



Hoofdstuk 2 Beheer van informatiesystemen Vragen en opdrachten met betrekking tot de casus: 1. Zorgplan: het hoofd van de planningsafdeling. ZorgPak: het hoofd van de financiële

afdeling. 2. ZorgPlan: de medewerkers op de vestigingen. ZorgPak: ziekenfondsen en particulieren. 3. Exploitatie: het operationeel houden van de systemen. Beheer: zorgen dat de systemen

blijven aansluiten bij de wensen en eisen van de gebruikers. Onderhoud: het aanbrengen van wijzigingen in de informatiesystemen door het indienen van wijzigingsverzoeken.

4. Correctief Onderhoud: oplossen van fouten en problemen, preventief onderhoud: het voorkomen van fouten en problemen, perfectief onderhoud: het verbeteren van de snelheid, adaptief onderhoud: aanpassen aan de wet en additief onderhoud: het toevoegen van nieuwe functionaliteit.

5. Om roosters te kunnen maken voor de zorg en de declaraties te kunnen verwerken (reële systemen) is een informatiesysteem nodig. Parallel aan de materiestromen binnen een organisatie, verwerkt het informatiesysteem de informatiestromen.

6. Om de informatiesystemen die in gebruik zijn te kunnen beheren, zijn binnen HomeCare beheerders werkzaam. Het hele systeem is onderhevig aan allerlei technische, informatische, bestuurlijke en bedrijfseconomische invloeden.

7. Bestuurlijke invloeden: fusie of reorganisatie. Informatische invloeden: bijvoorbeeld nieuwe privacywetgeving. Bedrijfseconomische invloeden: bijvoorbeeld een economische crisis. Technische invloeden: bijvoorbeeld het verwerken van gegevens via internet.

8. Recursie betekent dat elk systeem weer kan bestaan uit verschillende deelsystemen. Dit geldt zowel voor de verhouding tussen reëel systeem en informatiesysteem als voor de verhouding tussen beheer, informatiesysteem en reëel systeem.

9. ZorgPlan is ooit ontstaan vanuit de behoefte om de informatievoorziening onder controle te krijgen. Daartoe moet een beleidsplan worden opgesteld waarin de toekomstige informatievoorziening wordt beschreven. Vervolgens is het systeem ontwikkeld en geaccepteerd en ingevoerd. Vanuit exploitatie en gebruik komen regelmatig verzoeken om het systeem aan te passen. Als deze worden gehonoreerd, moet het systeem worden gewijzigd en vervolgens opnieuw geaccepteerd en ingevoerd.

10. Informatieplanning: het informatieplan. Ontwikkeling: de ontwerpen en de broncode. Acceptatie en invoering: de acceptatietesten. Gebruik: handleiding en documentatie. Exploitatie: instellingen van de parameters. Wijzigingen: de wijzigingsvoorstellen.

11. Correctief onderhoud: het herstellen van fouten in ZorgPak en ZorgPlan. Preventief onderhoud: het voorkomen van fouten in ZorgPak en ZorgPlan. Perfectief onderhoud: het verbeteren van de prestaties van ZorgPak en ZorgPlan. Adaptief onderhoud: aanpassingen van de informatiesystemen vanwege veranderingen in de voorschriften van de overheid. Additief onderhoud: aanpassingen in ZorgPak en ZorgPlan als gevolg van de gewijzigde functionele eisen.

Open vragen: 1. Het geheel van apparatuur, met bijbehorende basisprogrammatuur en

toepassingsprogrammatuur, gegevensverzamelingen, procedures en personen voor het kennen, besturen en ondersteunen van reële systemen.

2. Apparatuur, programmatuur, gegevensverzamelingen, mensen en procedures. 3. Technische infrastructuur, technische gegevensinfrastructuur, applicatie-infrastructuur en

informatie-infrastructuur. 4. zie vraag 1



5. Informatievoorziening is het geheel aan activiteiten dat binnen een organisatie moet worden uitgevoerd om iedereen te voorzien van de informatie die nodig is voor de vervulling van de toegewezen functies.

6. De eigenaar van een informatiesysteem is verantwoordelijk voor de functionaliteit van het informatiesysteem. De gebruikers van een informatiesysteem zijn de mensen die voor hun werkzaamheden gebruik maken van de functionaliteit van een informatiesysteem.

7. Exploitatie is het operationeel houden van het informatiesysteem. Onderhoud wil zeggen het aanbrengen van wijzigingen in het informatiesysteem. Beheer wil zeggen het instandhouden van het informatiesysteem overeenkomstig de eisen en randvoorwaarden vanuit het gebruik.

8. Correctief, preventief, perfectief, adaptief en additief onderhoud. 9. Het informatiesysteem is nodig voor de ondersteuning en besturing van het reële systeem,

de bedrijfsprocessen van een organisatie. 10. Informatieparadigma: voor de besturing en ondersteuning van de bedrijfsprocessen van

een organisatie is een informatiesysteem nodig. 11. Beheerparadigma: Voor het beheer van het informatiesysteem is een beheerafdeling

nodig, waarbij alle onderdelen van het beheerparadigma (reëel systeem, informatiesysteem en beheer) worden beïnvloed door informatische, bestuurlijke, bedrijfseconomische en technische invloeden.

12. Informatische, bestuurlijke, bedrijfseconomische en technische invloeden. 13. Het recursiebeginsel bij zowel het informatieparadigma als het beheerparadigma houdt in

dat beide paradigma ook gelden voor deelsystemen, met andere woorden de beheerafdeling heeft weer een eigen informatiesysteem nodig voor de besturing van haar eigen reële systeem.

14. Het toestandenmodel brengt de verschillende toestanden van een informatiesysteem gedurende de levensloop van dat informatiesysteem in kaart en plaatst daarin de verschillende beheertaken.

15. IBP: informatiebeleid en -planning; O: ontwikkeling; AI: acceptatie en invoering; G: gebruik, E: exploitatie; W: wijzigen.

16. Toestand IBP: volgen van de technische ontwikkeling. Toestand O: advies geven aan de ontwikkelaars met betrekking tot de wensen van de gebruikers. Toestand AI: controleren of gebruik en beheer voldoende zijn ingericht om met het nieuwe systeem om te kunnen gaan. Toestand G: ondersteuning van de gebruikers die met het systeem werken. Toestand E: inspelen op technologische en bedrijfseconomische ontwikkelingen. Toestand W: wijzigen van het informatiesysteem als gevolg van fouten in de programmatuur.

17. Het uitgebreid toestandenmodel geeft het voortschrijdend karakter in de tijd en de consequenties die daaraan zijn verbonden voor het beheer beter in kaart.

18. Correctief, preventief, perfectief, adaptief en additief onderhoud.



Waar/niet waar: 1. Waar 2. Waar 3. Niet waar: architectuur, uitrusting en realisatie. 4. Niet waar: de applicatie-infrastructuur bestaat uit de toepassingsprogrammatuur en de

bijbehorende gegevensverzamelingen. 5. Niet waar, het doel van informatievoorziening is iedereen van de juiste informatie te

voorzien. 6. Niet waar, de gebruiker maakt gebruik van de functionaliteit, de eigenaar is

verantwoordelijk voor de functionaliteit. 7. Waar, beheer bestaat uit exploitatie en onderhoud. 8. Waar 9. Waar 10. Waar, zie figuur 2.2 11. Waar 12. Niet waar 13. Waar 14. Waar 15. Waar 16. Waar Meerkeuzeopgaven: 1. D 2. D 3. A 4. A 5. D 6. B 7. B 8. B, dit is geen toestand waarin het IS zich kan bevinden. 9. A, bij het bepalen van het informatiebeleid wordt rekening gehouden met de bestaande IS. 10. C



Hoofdstuk 3 Organisatie van het beheer Vragen en opdrachten met betrekking tot de casus: 1. Functioneel beheer: Marion. Applicatiebeheer: Frank en Patrick. Technisch beheer: Johan. 2. Johan: netwerk beheren. Marion: gebruikers ondersteunen. Frank en Patrick:

programmeren. Gerard: leiding geven. Daarnaast participeren alle medewerkers regelmatig in projecten.

3. Taakveld: apparatuurbeheer, taak: registreren en bewaken van de apparatuur. Taakveld: gebruikersondersteuning, taak: begeleiden en opleiden van de gebruikers. Taakveld: onderhoud applicatieprogrammatuur, taak: uitvoeren systeemtest. Taakveld: tactisch management, taak: planning en bewaking van de uitvoering.

4. Strategisch: opstellen van een plan voor een nieuwe inrichting van de ICT-afdeling Tactisch: verdelen van het werk over de 5 medewerkers van de afdeling ICT. Operationeel: netwerk beheren, gebruikers ondersteunen, programmeren.

5. Doel: oplossen van problemen. Volgorde taken: probleem registereren, analyseren, zoeken van gelijksoortige problemen, escaleren van het probleem en probleem sluiten.

6. Ja: technisch beheer: vergroten van de netwerkcapaciteit. Applicatiebeheer: aanpassen van de databasestructuur. Functioneel beheer: verbeterplan voor de ICT-afdeling.

7. Als de netwerkcapaciteit wordt vergroot, kan de structuur van de database misschien worden aangepast. Dit moet eerst met de gebruikers worden besproken, wat de taak is van functioneel beheer.

8. Bij alle drie de wijzigingsvoorstellen. 9. Nee, alle drie de wijzigingsvoorstellen beïnvloeden het werk van de gebruikes. 10. Vergroting van de netwerkcapaciteit: Johan. Aanpassen databasestructuur: Frank en

Patrick. Toevoegen van een nieuw programmaonderdeel: Marion. Open vragen: 1. Eisen vanuit het gebruik, randvoorwaarden vanuit het gebruik, karakteristieken van

apparatuur, karakteristieken van programmatuur, karakteristieken van gegevensverzamelingen, karakteristieken van procedures en karakteristieken van mensen.

2. Eisen vanuit het gebruik: snelheid en gebruikersgemak, randvoorwaarden vanuit het gebruik: controlemogelijkheden voor de gebruikers, karakteristieken van apparatuur: de hoeveelheid geheugen in de pc, karakteristieken van programmatuur: soort besturingssysteem, karakteristieken van gegevensverzamelingen: aantal bestanden en velden, karakteristieken van procedures: back-up en inloggen, karakteristieken van mensen: kennis en ervaring.

3. Technisch beheer, applicatiebeheer en functioneel beheer. 4. Zie figuur 3.2 op bladzijde 49. 5. Functioneel beheer richt zich op de instandhouding van de functionaliteit van het

informatiesysteem. 6. Ja. 7. Technisch beheer is verantwoordelijk voor de instandhouding van de operationalisering

van het informatiesysteem. 8. De drie beheereenheden moeten samenwerken om problemen met informatiesystemen op

te lossen. 9. Binnen de ontwikkelomgeving spelen zaken als versiebeheer en de gebruikte methoden en

technieken een centrale rol. Binnen de exploitatieomgeving spelen de performance en stabiliteit van het informatiesysteem een centrale rol.



10. Met behulp van het logo van Mintzberg kunnen de drie managementniveaus (strategisch, tactisch en operationeel) van het beheer binnen de drie beheereenheden (functioneel-, technisch- en applicatiebeheer) worden weergegeven.

11. In het uitgebreid drievoudig model van beheer kan elke beheervorm vaker dan eenmaal voorkomen. Binnen elke beheervorm worden de taakgebieden vermeld. Vervolgens worden clusters van beheertaken gevormd, die op zijn te vatten als een aantal bij elkaar behorende beheertaken dat goed herkenbaar is. In het onderste gedeelte van het model worden uit de gevormde clusters van beheertaken die beheertaken geselecteerd, die voor de uitvoering van een bepaald beheerproces in aanmerking komen.

12. Kritische, in gedragstermen omschreven kenmerken van mensen die ten grondslag liggen aan succesvol functioneren binnen een organisatie.

13. Analytisch vermogen, creativiteit, methodisch werken, accuratesse. Waar/niet waar: 1. Waar 2. Waar 3. Waar 4. Niet waar 5. Waar 6. Waar 7. Waar 8. Waar 9. Waar 10. Waar Meerkeuzeopgaven: 1. B 2. A 3. C 4. A 5. B 6. C 7. B 8. C 9. D 10. C



Hoofdstuk 4 Procesmatige aanpak van het applicatiebeheer Vragen en opdrachten met betrekking tot de casus: 1. Bijvoorbeeld de beheerders spreken niet de taal van de gebruikers en gebruiken jargon,

vaktaal die niet wordt begrepen door de gebruikers, wat tot irritaties leidt. 2. De Servicedesk is het centrale aanspreekpunt voor de gebruikerd. Het Serviceteam is het

centrale aanspreekpunt voor de functioneel beheerders, waar ze kunnen overleggen met de applicatiebeheerders en de technisch beheerders, zodat de lijnen kort blijven.

3. Applicatiebeheer: plegen van onderhoud, aanpassen van de databases en uitvoeren van programmatests. Technisch beheer: oplossen storingen, aanpassen en vervangen van hardware en beveiliging van het netwerk. Functioneel beheer: overleggen met de gebruikers, specificeren van wijzigingen in de functionaliteit en uitvoeren van de acceptatietest.

4. Openingstijden van de Servicedesk, welke aplicaties worden ondersteund, welk deel van het beheer wordt centraal uitgevoerd en welk deel decentraal, wie beslist er over wijzigingen en welke eisen worden er gesteld aan de beschikbaarheid van de systemen.

5. Omdat er twee klanten zijn (hoofdkantoor en de vestigingen) met hun eigen wensen en eisen met betrekking tot de dienstverlening.

6. Je hoeft niet alles zelf te bedenken, maar maakt gebruik van de kennis die er al is. Bovendien kun je makkelijker communiceren met de mensen die de standaard ook kennen, bijvoorbeeld de leverancier.

7. Beter registreren, bewaken, procedures maken en plannen, dus minder ad-hoc werken. 8. ITIL voor technisch beheer of infrastructuurbeheer en ASL voor applicatiebeheer. 9. Door vooraf na te denken waar de problemen zich kunnen voordoen en deze problemen

proberen te voorkomen. Bijvoorbeeld de capaciteit van de server uitbreiden als wordt geconstateerd dat de gebruikers steeds mee mails versturen.

10. Dat argument is terecht, want natuurlijk moet de gebruiker of de klant de dienst uitmaken. Johan beseft niet dat hij een dienstverlenende, ondersteunenede functie heeft.

11. Nee, het is een logische ontwikkeling dat de klant of opdrachtgever bepaalt wat er moet gebeuren. De dienstverlener heeft een adviserende taak, maar de opdrachtgever betaalt en bepaalt.

Open vragen: 1. Omdat applicatiebeheer, naast functioneel beheer en technisch beheer, steeds meer als een

apart vak wordt gezien, bestaat er sinds enkele jaren een apart framework voor de applicatiebeheerprocessen: de “Application Service Library”, afgekort tot ASL. Dit framework gaat ervan uit dat applicatiebeheer bestaat uit een verzameling beheer- en onderhoudsprocessen dat invulling geeft aan het vak applicatiebeheer op drie niveaus: richtinggevend, sturend en uitvoerend. Het ASL-framework heeft als doel om invulling te geven aan het vak applicatiebeheer als schakel tussen het functioneel beheer en het technisch beheer. In die visie is het functioneel beheer verantwoordelijk voor de aansluiting op de bedrijfsprocessen aan de kant van de opdrachtgever of gebruiker en is ITIL verantwoordelijk voor het beheren van de technische infrastructuur. ASL heeft als doel het optimaal ondersteunen van de bedrijfsprocessen door applicaties gedurende de hele levenscyclus van deze bedrijfsprocessen. ITIL is internationaal inmiddels uitgegroeid tot een standaard voor het

2. Technisch beheer is verantwoordelijk voor de instandhouding van de operationalisering van het informatiesysteem, dat bestaat uit apparatuur, programmatuur en gegevensverzamelingen. Kortom is dit de organisatie die de informatiesystemen draait en zorgt dat de infrastructuur op orde blijft. Applicatiebeheer is verantwoordelijk voor de



instandhouding van de applicatieprogrammatuur en de gegevensbanken. Het is dus de partij die het informatiesysteem (applicatie) beheert en onderhoudt.

3. Vroeger economische klimaat voor de ontwikkeling van nieuwe software was gunstiger dan nu en organisaties reserveerden budgetten hiervoor.

4. De laatste jaren komt er echter steeds meer belangstelling voor beheren van de bestaande informatiesystemen. Dit komt enerzijds door de complexiteit en de grote risico’s van nieuwbouwprojecten, aan de andere kant functioneren de informatiesystemen die in gebruik zijn over het algemeen goed, waardoor er minder noodzaak is om steeds nieuwe te ontwikkelen. Omdat organisaties in de loop der jaren steeds afhankelijker zijn geworden van de informatiesystemen die ze gebruiken, is de noodzaak om deze te onderhouden en aan te passen steeds meer toegenomen. Dit alles draagt ertoe bij dat het vak applicatiebeheer steeds belangrijker is geworden.

5. ITIL is een methode die uitgaat van een procesmatige aanpak van het beheer van de technische infrastructuur. Binnen ITIL wordt het applicatiebeheer beschreven in het proces application management. ITIL ziet het applicatiebeheer als een geheel van processen en activiteiten dat het beheer van een applicatie gedurende de hele levenscyclus van de applicatie beschrijft. Deze levenscyclus bestaat uit twee delen: applicatieontwikkeling en servicemanagement, waarmee het ondersteunen en optimaliseren van applicaties wordt bedoeld.

6. De procesmatige aanpak van het beheer, het gebruik van best practices en het public domain karakter.

7. De ontwikkelingen in de ICT volgen elkaar in snel tempo op. ITIL en ASL zijn ontwikkeld om op een systematische en samenhangende wijze de best practice op het vakgebied over te dragen. Door de praktijk van de beheerprocessen te beschrijven in best practices, kunnen de processen voortdurend worden verbeterd en aangepast

8. Applicatiebeheerprocessen worden bij ASL op drie niveaus beschreven: richtinggevend, sturend en uitvoerend.

9. Om de drie vormen van beheer op elkaar af te stemmen, gaat ASL uit van één orgaan, het ServiceTeam, dat de verantwoordelijkheid draagt voor de totale levenscyclus van de informatievoorziening. Het ServiceTeam vervult daarmee een brugfunctie tussen de gebruikersorganisatie en de beheerders en biedt een centraal aanspreekpunt naar de klant.

10. Binnen het ASL-Framework worden de volgende procesclusters onderscheiden: • Richtinggevend:

o Organization Cycle Management (OCM) o Applications Cycle Management (ACM)

• Sturend: o De sturende processen

• Uitvoerend: o Beheer o Verbindende processen o Onderhoud en vernieuwing

Waar/niet waar: 1. Waar 2. Niet waar 3. Waar 4. Waar 5. Niet waar 6. Waar 7. Waar



8. Waar 9. Niet waar 10. Waar 11. Waar Meerkeuzeopgaven: 1. B 2. A 3. C 4. D 5. C 6. C 7. A 8. B 9. A 10. B



Hoofdstuk 5 De beheerprocessen Vragen en opdrachten met betrekking tot de casus: 1. Het beste kan dit bottom-up gebeuren, dus eerst de uitvoerende beheerprocessen, baarna

de sturende en als laatste de richtinggevende. Het beste kan worden begonnen met configuration management en incident management.

2. Eerst configuration management, daarna incidnet management, problem management, change management en release management.

3. Vooral configuration management, incident management, problem management, change management en release management.

4. Vooral incident management omdat dit beheerproces het dichtst bij de gebruikers staat. 5. Frank en Patrick zijn vooral betrokken bij onderhoud en vernieuwing en voor een deel bij

beheerprocessen als availability management, capacity management en continuity management.

6. Bij een incident moet Marion vooral snel reageren, een probleem heeft altijd een diepere oorzaak, waardoor het meer tijd nodig heeft om op te lossen. Problemen duiden vooral op een structureel gebrek aan kwaliteit in een applicatie.

7. Goe naar de gebruikers luisteren en met ze overleggen over wijzigingen in de applicaties, zodat incidenten en problemen kunnen worden voorkomen.

8. Johan, want hij is verantwoordelijk voor de infrastructuur. 9. Opstellen van beleidsplannen voor de afdeling en voor de applicaties die worden gebruikt. 10. De andere medewerkers kunnen hem in beide gevallen ondersteunen door vanuit hun

expertise feedback aan hem te geven. Open vragen: 1. Zorgen voor een optimale inzet van de applicaties die in gebruik zijn, zodat deze het

bedrijfsproces optimaal kunnen ondersteunen, met een minimum aan middelen en verstoring in de operatie.

2. Configuration Management (Configuratiebeheer), Incident Management (Incidentbeheer), Availability management (Beschikbaarheidsbeheer), Capacity Management (Capaciteitsbeheer), Continuity Management (Continuïteitsbeheer).

3. Technisch beheer richt zich op het operationeel houden van de technische infrastructuur, applicatiebeheer richt zich op het operationeel houden van de applicaties.

4. 2 doelen: garanderen van de continuïteit van de dienstverlening door een zo spoedig mogelijk herstel van het afgesproken dienstenniveau wanneer een afwijking hierop bij de servicedesk wordt geconstateerd. Daarnaast in behandeling nemen en planmatig afhandelen van vragen en andere servicecalls die via de servicedesk binnenkomen.

5. Een incident is een aanleiding voor een gebruiker of een monitoringsysteem om een melding te doen. Een incident kan leiden tot meerdere meldingen. Meestal wordt in de registratiesystemen een 1 op 1 relatie tussen incident en melding gebruikt.

6. Een probleem is een structurele oorzaak van meerdere incidenten. Oplossing van een incident neemt vaak niet het achterliggende probleem weg. Daarom worden problemen afzonderlijk aangepakt.

7. Proactieve communicatie heeft als doel het voorkomen van incidenten en verstoringen. Dit kan door over alle veranderingen in de status van een CI te communiceren met de betrokken functioneel beheerders. Een voorbeeld van een statusverandering van een CI is het in productie gaan van een nieuwe release. Door hierover goed te communiceren tussen functioneel beheer en incidentbeheer kunnen veel problemen worden voorkomen. Hierdoor ondervinden de bedrijfsprocessen geen hinder van het in productie nemen van de nieuwe release.



8. Incidenten kunnen een indicatie zijn voor een probleem, een achterliggende structurele oorzaak van het niet goed functioneren van de applicatie of de dienstverlening. Een probleem staat los van het incident. Het incident kan vaak worden opgelost door gebruik te maken van een patch of een work-around, zodat de dienstverlening snel kan worden hersteld. Er komt dan meer tijd beschikbaar voor analyse van gelijksoortige incidenten en problemen en het zoeken naar een structurele oplossing. De afhandeling van problemen gebeurt bij ASL niet net als bij ITIL binnen Problem Management maar via het sturende proces Quality Management. De reden hiervoor is dat de meeste problemen niet worden geconstateerd door Incident Management maar door de andere processen, vaak de deelprocessen binnen Onderhoud & Vernieuwing.

9. Proactieve activiteiten als communicatie naar functioneel beheerders en gebruikers om incidenten te voorkomen.

10. Reactieve communicatie als zich een incident voordoet, zodat de functioneel beheerders en gebruikers tijdig op de hoogte zijn.

11. Rapportages over opgeloste en openstaande incidenten. 12. Configuratiebeheer is verantwoordelijk voor de registratie van en de

informatievoorziening over alle objecten die deel uitmaken van een informatiesysteem of applicatie.

13. Voor de registratie van de applicatieobjecten wordt gebruik gemaakt van een geautomatiseerd informatiesysteem, de Configuration Management Database (CMDB). In deze database worden alle configuratie-items (CI’s) of applicatieobjecten geregistreerd.

14. Applicaties, documentatie, procedures. 15. Naamgevingsconventies zijn afspraken over het geven van namen aan CI’s. Ze worden

gebruikt om overzicht te houden over het beheer van de CI’s. Naamconventies hebben betrekking op alle soorten CI’s: programma’s, tabellen en gegevensbestanden. De afspraken over het verstrekken van namen gaan vaak over de systemen heen. Ze maken dan ook vaak deel uit van het kwaliteitssysteem van een organisatie.

16. Nee, want daar worden andere gegevens geregistreerd, vooral gegevens die betrekking hebben op de technische infrastructuur.

17. In de Service Delivery Database (SDDB) worden de afspraken en service levels over de dienstverlening aan de klanten geregistreerd.

18. Doel van Availability Management (beschikbaarheidsbeheer) is het waarborgen van de juiste inzet van middelen, methoden en technieken om te voorzien in de met de opdrachtgever overeengekomen optimale beschikbaarheid en bruikbaarheid van ICT-diensten.

19. Beschikbaarheid is de mate waarin de klant over de functionaliteit een product of dienst kan beschikken op de tijd en de plaats die de klant wenst.

20. Betrouwbaarheid is het vermogen om het prestatieniveau van een applicatie gedurende een vastgestelde periode te handhaven.

21. Met de Mean Time Between Failures (MTBF) wordt de betrouwbaarheid van de applicatie bedoeld. Hiermee wordt aangegeven of de applicatie doet wat ze moet doen, of de juiste gegevens worden verwerkt en of de gegevens op de juiste wijze worden verwerkt. De betrouwbaarheid van een applicatie kan worden gemeten aan de hand van het aantal storingen, fouten in de verwerking.

22. De Mean Time To Repair (MTTR) is een indicatie voor de betrouwbaarheid van de service: hiermee wordt aangegeven of de applicatiebeheerorganisatie zich houdt aan de in de SLA gemaakte afspraken. De betrouwbaarheid van de service kan worden gemeten aan de hand van de gemiddelde storingstijd.

23. Allereerst moet er een beschikbaarheidsplan worden opgesteld. Vervolgens moeten de maatregelen uit het beschikbaarheidsplan worden gerealiseerd. Om te kunnen beoordelen



of de genomen maatregelen afdoende zijn, worden ze voortdurend bewaakt en gemeten. Nadat de maatregelen zijn gemeten kan de beschikbaarheid worden gestuurd door het beschikbaarheidsplan aan te passen, wat weer leidt tot nieuwe of aanvullende maatregelen enzovoort.

24. Via incidentbeheer komen er voortdurend meldingen binnen over de beschikbaarheid en de betrouwbaarheid van de applicaties. Dit zijn voornamelijk tweedelijnsincidenten die niet door incidentbeheer kunnen worden opgelost en zijn geëscaleerd naar de tweede lijn, in dit geval het proces beschikbaarheidsbeheer. Van de andere kant zal beschikbaarheidsbeheer ook incidenten aanmelden bij incidentbeheer.

25. Het doel van Capacity Management is het op het juiste moment toewijzen van de juiste en juiste hoeveelheden resources aan de rondom het beheren, gebruiken en exploiteren van het systeem te leveren diensten.Capacity Management moet ervoor zorgen dat de beschikbare middelen optimaal (niet maximaal!) worden ingezet, dat wil zeggen op de juiste plaats, op het juiste moment en tegen gerechtvaardigde kosten.

26. Werklast, middelen en prestaties. 27. Beïnvloeden van de werklast, veranderen van de middelen en optimaliseren van de

prestaties. 28. Opstellen van het capaciteitsplan, realiseren van de capaciteit, bewaken van de capaciteit

en bijsturen van de capaciteit. 29. Het analyseren van de bedreigingen en het bedenken en treffen van maatregelen om te

voorzien in de continuïteit van het bedrijfsproces is het belangrijkste doel van het proces Continuity Management (Continuïteitsbeheer).

30. Ongestoorde doorgang van de dienstverlening. 31. Bedreigingen van binnenuit als fraude, ongeoorloofd gebruik van gegevens en storingen.

Daarnaast bedreigingen van buitenaf zoals hackers, fraudeurs, virussen of blikseminslag. 32. Het gebruik van wachtwoorden, organisatorische en procedurele maatregelen, fysieke

maatregelen als sloten en het regelmatig maken van backups. 33. Opstellen van een continuïteitsplan, realiseren van de continuïteit, bewaken van de

continuïteit en bijsturen van de continuïteit. Waar/niet waar: 1. Niet waar, ze lijken op elkaar maar hebben een andere focus. 2. Niet waar, veel-op-veel 3. Waar, ze hebben een andere invalshoek 4. Waar 5. Waar 6. Waar 7. Waar 8. Niet waar, reactief 9. Waar 10. Waar, zie blz. 117 11. Niet waar, incidenten kunnen wel een indicatie zijn voor een probleem. 12. Waar 13. Nee, dit is reactieve communicatie. 14. Waar, ze worden ontdekt door testers, ontwikkelaars of beheerders. 15. Niet waar, alleen de kenmerken van een applicatie worden in de CMDB opgenomen. 16. Niet waar, dit hoort bij kwaliteitsbeheer. 17. Waar 18. Waar 19. Waar



20. Waar Meerkeuzeopgaven: 1. C, ze zijn uitvoerend 2. D, dit is een ITIL-proces 3. D 4. B, dit is proactief 5. D 6. A, zie blz. 122-123 7. C, zie blz. 122-123 8. B, zie blz. 122-123 9. A, zie blz. 122-123 10. C, zie blz. 129 11. A, zie blz. 127



Hoofdstuk 6 De verbindende processen Vragen en opdrachten met betrekking tot de casus: 1. Het is niet altijd duidelijk met welke versie de gebruikers werken, er worden verschillende

versies door elkaar heen gebruikt en er is geen eenduidige procedure voor de acceptatie en planning van wijzigingen. Daarnaast gaat er regelmatig iets fout bij de distributie van de applicaties en de bijbehorende documentatie. Ook is bij onderhoud vaak niet duidelijk waar de broncode is en welke wijzigingen er in moeten worden doorgevoerd. Daarnaast komt het regelmatig voor dat de documentatie niet wordt bijgewerkt en dat de gegevensdefinities niet kloppen.

2. Omdat Zorgplan decentraal wordt gebruikt, waardoor er regelmatig nieuwe versies en releases naar de filialen moeten worden gedistribueerd.

3. Gestructureerd doorvoeren van wijzigingen, goede registratie, plannen van wijzigingen in releases, bijstellen en bewaken van de wijzigingen en beter communiceren met de gebruikers.

4. Applicaties, documentatie, procedures en gegevens definities. 5. Impactanalyse moet de technische en organisatorische consequenties van een wijziging

bekijken en beoordelen en vervolgens een advies uitbrengen over de wijziging. 6. Vooral van de gebruikers van ZorgPak en ZorgPlan. 7. Besluitvorming over wijzigingen, het veilig opbergen van broncode en het distribueren

van de juiste versie naar de gebruikers als de wijziging is doorgevoerd. 8. Met een change of een wijziging wordt het hele traject bedoeld dat doorlopen wordt voor

het aanbrengen van een bepaalde hoeveelheid gewijzigde functionaliteit in een applicatie, bijvoorbeeld ZorgPak of ZorgPlan. Met een change set wordt de verzameling objecten bedoeld die door een release mogelijk zullen worden gewijzigd, bijvoorbeeld een paar modules van ZorgPak en de bijbehorende documentatie. Een change package bestaat uit een verzameling objecten die gewijzigd en geaccordeerd zijn en die overgeheveld zullen worden naar de productieomgeving. Een shipment is een verzameling gewijzigde objecten die integraal overgezet worden naar een of meer productieomgevingen, bijvoorbeeld de decentrale vestigingen van HomeCare.

9. Naam, versienummer, status, modules, gebruikers en beheerders van een applicatie. 10. Gerard zou een goede Changemanager kunnen zijn. Voor de distributie van de

wijzigingen zou Marion kunnen zorgen omdat zij het beste weet wat er leeft bij de gebruikers.

Open vragen: 1. Beheer en onderhoud & vernieuwing. 2. Wijzigingenbeheer en programmabeheer & distributie. 3. Wijzigingenbeheer is de ingaande sluis richting de onderhouds- en

vernieuwingsprocessen. 4. Programmabeheer en distributie is de ingaande sluis richting beheer. 5. De verbindende processen zorgen voor de synchronisatie en de afstemming van

applicaties die vanuit het beheer in onderhoud worden genomen of andersom, na het plegen van onderhoud weer in beheer worden genomen.

6. Doel van het proces wijzigingenbeheer is ervoor te zorgen dat er een gestandaardiseerde werkwijze wordt gebruikt om wijzigingsvoorstellen te verzamelen, prioriteren, clusteren en door te voeren zodat de kwaliteit van de applicatie structureel kan worden verbeterd.

7. Wijzigingsbeheer is verantwoordelijk voor het inzamelen, prioriteren, clusteren en inplannen van de gewenste wijzigingen. Daarna deze doorsluizen naar onderhoud.



8. Wijzigingen worden uitgevoerd in releases. Een release is een verzameling wijzigingen voor één klant. Deze wijzigingen worden in één wijzigingsronde aangebracht. Door de wijzigingen te clusteren in releases, kunnen ze veel beter worden gepland.

9. Een aantal mogelijke aanleidingen voor wijzigingen: • incidenten die niet kunnen worden opgelost; • wetswijzigingen; • nieuw of gewijzigde functionaliteit; • Prestatie of kwaliteitsverbetering; • voldoen aan SLA’s; • urgente wijzigingen; • correctief onderhoud.

10. Drie stadia van een wijziging zijn: • Wijzigingsvoorstel: een voorstel tot wijziging dat nog niet is ingepland of afgewezen. • In onderhoud: een wijziging die momenteel wordt doorgevoerd. • Afgehandeld: een wijziging die is uitgevoerd of afgewezen.

11. In applicatie beheer wijzigingen worden niet meteen doorgevoerd, in tegenstelling tot wijzigingsvoorstellen bij technisch beheer. De reden is dat de prioriteit van een wijziging moet bepaald worden om de onverwachte gebeurtenissen die een urgente wijziging noodzakelijk maken te vermijden.

12. De activiteiten van wijzigingenbeheer zijn: Registratie van de wijziging, Inplannen van de release, Bijstellen en bewaken van de release, Sturen en rapporteren.

13. Door wijzigingsbeheer in ontvangst te nemen van het geïnventariseerd wijzigingsvoorstel en vervolgens het wijzigingsvoorstel wordt geregistreerd waarbij een aantal initiële gegevens worden vastgelegd.

14. Change set en change package. 15. Deze processen vormen een verbinding tussen de beheerprocessen en de onderhouds- en

vernieuwingsprocessen. Uit het dagelijkse beheer komen wijzigingsverzoeken die worden beoordeeld en ingepland door wijzigingsbeheer, waarna ze worden doorgesluisd naar onderhoud en vernieuwing. Als de nieuwe release klaar is moet deze worden geïmplementeerd in het dagelijkse beheer. Programmabeheer en distributie is verantwoordelijk voor de distributie van applicatieobjecten naar de productieomgeving.

16. Doel van programmabeheer en distributie is het volgens een gestandaardiseerde werkwijze aanbrengen van wijzigingen in applicatieobjecten en er voor zorgdragen dat alleen geautoriseerde applicatieobjecten in productie worden genomen.

17. De applicaties, documentatie, gegevensdefinities van applicaties. 18. Om te voorkomen dat de verkeerde versie wordt overgebracht naar de productieomgeving

naast onderlinge afstemming van wijzigingen ook bij de distributie van de gewijzigde applicaties naar de productieomgeving is afstemming nodig,.

19. Programmabeheer en distributie houdt zich bezig met de fysieke uitrol van de releases. Dit is een gecompliceerd proces, omdat de releases elkaar niet sequentieel opvolgen, maar parallel kunnen lopen, waardoor er tegelijkertijd meerdere releases in omloop kunnen zijn.

20. Change set: de verzameling objecten die als gevolg van een release mogelijk zullen worden gewijzigd.Change package: de verzameling objecten die gewijzigd en geaccordeerd zijn en die overgeheveld zullen worden naar de productieomgeving. Shipment: een verzameling gewijzigde objecten die integraal overgezet worden naar één of meer productieomgevingen.

21. Door het versienummer aan te passen in de CMDB. 22. In de praktijk zullen vaak meerdere versies van een bepaalde applicatie op verschillende

plaatsen naast elkaar draaien. Er is dan sprake van een n:m relatie tussen de CMDB’s van applicatiebeheer en van technisch beheer. Programmabeheer en distributie is ervoor



verantwoordelijk dat samen met de release het juiste nummer wordt doorgegeven aan beide configuratiebeheer-processen.

23. De activiteiten van programmabeheer en distributie zijn: Registratie van de change set, Uitgifte van de change set, Informatieverstrekking, Distributie naar de productieomgeving.

24. Shipments die kunnen worden overgezet naar de productieomgeving Waar/niet waar: 1. Waar 2. Niet waar, is de ingaande sluis richting onderhoud en vernieuwing en niet richting beheer. 3. Waar 4. Waar 5. Waar 6. Waar, is afhankelijk van de prioriteit. 7. Niet waar, die zijn al gewijzigd en geaccordeerd en zullen worden overgeheveld naar de

productieomgeving. 8. Niet waar, dat is een shipment. 9. Waar 10. Niet waar, het is n:m relatie. 11. Waar, mits er ook verschillende releases naast elkaar kunnen bestaan. 12. Niet waar, dit kan wel. 13. Waar 14. Waar 15. Waar 16. Niet waar, stabiliteit en kwaliteit zijn de belangrijkste prestatie-indicatoren. Meerkeuzeopgaven: 1. B 2. A 3. B 4. B 5. C 6. C, dat is de uitgaande sluis, dus geen bron. 7. C, wordt beheerd door technisch beheer. 8. A, zie blz. 152 9. A, zie blz. 144 10. A, zie blz. 144 11. C, zie blz. 144 12. C, zie blz. 144 13. D, zie blz. 144 14. D, zie blz. 154



Hoofdstuk 7 Onderhoud en vernieuwing Vragen en opdrachten met betrekking tot de casus: 1. Gestructureerd aanpassen van de applicaties ZorgPlan en ZorgPak, zodat de organisatie

minder last heeft van storingen als gevolg van wijzigingen. De onderhouds- en vernieuwingsprocessen kunnen ook een belangrijke bijdrage leveren aan de verbetering van de kwaliteit van de applicaties door de nieuwe releases goed te testen voordat ze worden gedistribueerd.

2. Ja, want elke wijziging heeft andere consequenties en door de wisselende samenstelling kan Gerard steeds de juiste mensen erbij halen om de consequenties van een wijziging te overzien.

3. Omdat die het beste de consequenties van de wijziging voor de gebruikers kunnen overzien.

4. Zij kan een belangrijke rol spelen bij het opstellen van de specificaties, omdat zij zowel op de hoogte is van de gebruikerskant als van de ontwikkelkant.

5. Modelleringstechnieken als UML, ERD etc. 6. Zij moeten de wijzigingen doorvoeren, programmeren en een programmatest uitvoeren. 7. Unittest: Frank en Patrick. Technische systeemtest: Frank en Patrick. Functionele

systeemtest: Marion. Ook de Exploitatietest en de acceptatietest worden door Marion uitgevoerd.

8. Vooral goed communiceren met de gebruikers en de gebruikers ondersteunen tijdens de distributie van de nieuwe release. Daarnaast kan ze hulp bieden bij de conversie en bij het aanpassen van de gebruikershandleidingen.

9. Door planmatig te werken en goed te testen, worden er minder fouten doorgelaten zodat de kwaliteit van de opgeleverde releases toeneemt.

10. Vooral de implementatie van de nieuwe releases. Open vragen: 1. Op een gestructureerde wijze aanpassen van de functionaliteit van het informatiesysteem. 2. Bedrijfsprocessen van organisaties veranderen. Omdat informatiesystemen nauwe relaties

hebben met die bedrijfsprocessen, zullen applicaties mee moeten veranderen om optimaal bruikbaar te zijn.

3. De vijf processen zijn: Impactanalyse, ontwerp, realisatie, testen en implementatie. 4. De onderhoudsprocessen volgen in hoofdlijnen de fasering van systeemontwikkeling. 5. Bij onderhoud en vernieuwing wordt onderhoud en aanpassingen gedaan aan een bestaand

systeem, waar nog mee wordt gewerkt. Bij systeemontwikkeling wordt een nieuw systeem ontwikkeld, dat in de plaats komt van een systeem dat nog wordt gebruikt.

6. Het komt omdat een vernieuwd systeem meteen in productie gaat, waardoor ervaren gebruikers de slechte oplossingen er meteen uit halen, wat leidt tot nieuwe wijzigingsverzoeken.

7. Om te zorgen dat de beheerders het onderhoud niet onder hoge werkdruk uitvoeren en dat de onderhoud genoeg aandacht krijgt wordt projectmatig gewerkt.

8. Vertrekpunt is het wijzigingsvoorstel dat vanuit wijzigingenbeheer komt. In de impactanalyse worden alle consequenties van dit wijzigingsvoorstel in kaart gebracht en afgewogen. Daarna het ontwerp van de wijziging gemaakt. In het realisatieproces wordt de wijziging gebouwd en worden de applicatieobjecten samengevoegd tot een werkende applicatie. In het testproces wordt onderzocht of de gewijzigde applicatiecomponenten voldoen aan de vooraf gestelde eisen. In het implementatieproces worden de gewijzigde applicatiecomponenten weer in productie genomen, waarbij ook aandacht wordt besteed aan opleiding, conversie en migratie.



9. Er wordt in tegenstelling tot bij systeemontwikkeling, gewerkt aan een bestaand systeem, dat in gebruik is. Er wordt bij onderhoud en vernieuwing bottom-up gewerkt, waardoor de wijzigingen achteraf moeten worden ingepast in het globale concept. Er is voor onderhoud en vernieuwing vaak minder tijd beschikbaar dan voor nieuwbouw. De eisen aan onderhoud en vernieuwing zijn veel hoger dan bij nieuwbouw omdat het systeem meteen in productie moet. Het budget voor onderhoud en vernieuwing is vaak minder dan bij nieuwbouw. Beheerders hebben het druk met andere werkzaamheden, waardoor een achterstand kan ontstaan.

10. Onderhoud wordt meestal gedaan door de lijnmedewerkers, die het al veel te druk hebben met hun dagelijkse werkzaamheden. Op deze wijze ontstaat er een onderhoudsbacklog, een achterstand ten opzichte van de vraag.

11. Alle consequenties van een wijzigingsvoorstel zoals de financiële en organisatorische consequenties worden in kaart gebracht en afgewogen ten opzichte van andere wijzigingsvoorstellen.

12. Input voor de impactanalyse is het wijzigingsvoorstel dat vanuit wijzigingenbeheer komt. 13. Het onderzoeken wat de gevolgen zijn van de voorgestelde wijzigingen voor de applicatie,

voor de infrastructuur waarop de applicatie draait en voor de gebruikersorganisatie. 14. De verzameling objecten die als gevolg van een release mogelijk zullen worden

gewijzigd. 15. In kaart brengen van de wijziging, inschatten van de verandering, inschatten van de

consequenties en de verificatie en terugkoppeling. 16. Het omzetten van de wijzigingsvoorstellen in een dusdanige vorm dat ze daarna voor alle

betrokkenen duidelijk zijn en kunnen worden ontwikkeld en getest. 17. Het resultaat is een uitgewerkt functioneel ontwerp. soms ook een technisch ontwerp. 18. De keuze voor de ontwikkelmethodiek die afhankelijk is van de organisatie en de

applicatie. 19. Door middel van een gebruikerspecificatie (uitgewerkt functioneel ontwerp), waarin alle

gebruikerswensen zijn terug te vinden. 20. Uitwerken van de vraag, bepalen van de oplossingsrichting, uitwerken oplossingsrichting,

validatie en besturing. 21. Het rapport impactanalyse is input voor het ontwerpproces. 22. De omzetting van het functionele ontwerp naar een werkende oplossing die voldoet aan de

gestelde eisen. 23. Bouwfase 24. Alle applicatieobjecten zoals de broncode, de documentatie, procedures,

gegevensdefinities etc. 25. Een technisch ontwerp is de vertaling van het functionele ontwerp naar de techniek 26. Change package is de verzameling applicatie objecten die daadwerkelijk zijn veranderd. 27. Impact bepalen, oplossing bepalen, oplossing realiseren, White-box tests en bijsturen. 28. Door goed te testen kunnen veel fouten uit de gerealiseerde oplossing gehaald, waardoor

de kwaliteit van de oplossing toeneemt. Hoe eerder met testen kan worden begonnen, hoe goedkoper het is de fouten uit het programma te halen.

29. Applicatiebeheer: Programmatest, Technische systeemtest en Functionele systeemtest. Technisch beheer:Exploitatietest. Functioneel beheer: Acceptatietest.

30. Programmatest of uittest: hiermee testen de ontwikkelaars of een programma of een programmaonderdeel voldoet aan de gestelde eisen. Proces testen.

31. Acceptatietest wordt na programmatest, systeemtest, functioneel en exploitatietest in de laatste stap bij implementatie wordt uitgevoerd. ???

32. Bij acceptatietest wordt getest of het systeem bruikbaar is voor de gebruikersorganisatie.



33. Activiteiten binnen het testproces zijn: • technische- en de functionele systeemtest:

o aanmaken testgevallen o uitvoeren testen; o impact fouten bepalen; o evalueren fouten; o bepaal oplossingsrichting; o laat fouten oplossen.

• ondersteuning productietest: o uitvoering ondersteunen; o impact fouten bepalen; o evalueren fouten; o bepaal oplossingsrichting; o laat fouten oplossen.

• voortgangsrapportages maken; • foutrapportages maken; • proces en resultaat evalueren.

34. De functioneel beheerder onderzoekt of alle wijzigingen vanuit gebruikersperspectief op de juiste wijze zijn aangebracht, waarna decharge kan worden verleend aan de ontwikkelaars.

35. Implementatie zorgt ervoor dat het onderhoudsproces kan worden afgerond door de randvoorwaarden in te vullen die een foutloos gebruik van de nieuwe release mogelijk maken.

36. Voorbereiding van de exploitatie, voorbereiden van de gebruikersorganisatie, afronden van de release

Waar/niet waar: 1. Waar 2. Waar 3. Waar 4. Waar 5. Niet waar, dat doet Design 6. Waar 7. Waar 8. Waar 9. Waar 10. Waar 11. Niet waar, dat is een functioneel ontwerp dat voor alle betrokkenen duidelijk moet zijn. 12. Waar 13. Waar 14. Waar, zie blz. 172 15. Waar 16. Waar 17. Waar 18. Waar, zie blz. 175 19. Waar, zie blz. 177 20. Niet waar, sommige tests vinden plaats tijdens de fase Realization, zie blz. 177. 21. Niet waar, dat gebeurt tijdens de functionele systeemtest. De productietest wordt ook wel

de exploitatietest genoemd en test of het systeem voldoet aan de afgesproken service levels, zie blz. 177.



22. Waar, zie blz. 179. 23. Niet Waar, andersom 24. Waar 25. Waar Meerkeuzeopgaven: 1. A 2. A 3. A en B zijn beide correct, zie blz. 164. 4. C 5. A 6. C 7. D, die is input. 8. A, of programmatest 9. A 10. B 11. C, ook wel Exploitatietest, zie blz. 177 12. D 13. A 14. D 15. C, die vindt plaats in de fase Realization



Hoofdstuk 8 De sturende processen Vragen en opdrachten met betrekking tot de casus: 1. Ja, eerst top down en daarna bottom up, dus eerst kijken naar het beleid en daarna

terugkoppelen met de geluiden die hij hoort vanaf de werkvloer. 2. Planning en control, kostenmanagement, kwaliteitsmanagement en Service Level

Management. 3. Planning en control: sturen op tijd en capaciteit. Kostenmanagement: werken met kosten

en budgetten. Kwaliteitsmanagement: duidelijke afspraken maken over de gewenste kwaliteit van producten en diensten. Service Level Management: aanpassen van de SLA’s.

4. Planningen maken, urenregistraties, uitvoeren van risicoanalyses, evalueren van de resultaten.

5. Problemen en storingen oplossen en het doorvoeren van wijzigingen. 6. Vooral grote onderhoudsrondes met betrekking tot ZorgPak en ZorgPlan. 7. Door op alle activiteiten van de IT-afdeling een prijskaartje te plakken. 8. Beter testen. 9. Enquêtes bij de gebruikers en het aantal gemelde incidenten en problemen moet afnemen. 10. Openingstijden van de servicedesk, beschikbaarheidseisen van ZorgPlan en ZorgPak, wie

beslist er over wijzigingen, op welk moment worden nieuwe releases uitgerold en binnen hoeveel tijd kan een incident of een probleem worden opgelost.

Open vragen: 1. Tijd, geld, kwaliteit en gemaakte afspraken 2. Door bij en professionele organisatie de drie niveaus van de sturende processen; doen van

voorspellingen, controleren en sturen en evalueren toe te passen. 3. De sturende processen worden gevoed door de richtinggevende processen (top-downen

krijgen input van de uitvoerende processen. 4. Planning en control, Kostenmanagement, Kwaliteitsmanagement, Service Level

Management 5. Ze sturen alle operationele processen aan. 6. Ervoor te zorgen dat de afgesproken dienstverlening wordt gerealiseerd met de juiste inzet

van tijd en middelen. 7. Het afwegen van de planningsfactoren tijd, geld en kwaliteit speelt hierbij een belangrijke

rol. 8. Planning en control is verantwoordelijk voor de planning en bewaking van alle

uitvoerende processen, voor de invulling en planning van de wijzigingsvoorstellen, levert de input voor het proces kostenmanagement, levert informatie over de omvang van de dienstverlening, de beschikbare capaciteit en de ervaring van de medewerkers aan skills definition en account definition, voedt de processen life cycle management en ICT portfolio management met gegevens over de ingezette capaciteit en normcijfers over productiviteit en onderhoud.

9. Door te realiseren van de afgesproken dienstverlening met de juiste inzet van tijd en mensen voorkom je uitloop van procesplanning.

10. Activiteiten van planning en control zijn: Planningsactiviteiten: � plannen van de dagelijkse beheerwerkzaamheden; � inplannen van onderhoud en vernieuwing: � uitvoeren van risicoanalyses; � plannen van service level reviews;



� bepalen van de capaciteitsbehoefte; � bijhouden en bewaken van kengetallen; Controleactiviteiten: � bewaken van de urenregistraties; � voortgangbewaking; � herschikken van taken; � bijstellen van planningen; � verschuiven van deadlines; � verminderen van de opdracht. Reviewactiviteiten: � evalueren van de resultaten; � maken van leerpuntenrapportages; � onderkennen van problemen; � doen van verbeteringsvoorstellen; � rapporteren over bevindingen; � communiceren met alle betrokkenen.

11. Planningen, risicoanalyses, kentallen, voortgangsrapportages, evaluaties, leerpuntenrapportages.

12. Voor het oplossen van incidenten en andere beheertaken. 13. Het inzichtelijk en stuurbaar maken van de kosten van de informatievoorziening is het

belangrijkste doel van kostenmanagement. 14. De klant kan een bedrijfseconomische afweging maken van de kosten versus de

opbrengsten. 15. Bij een interne beheerorganisatie hoeven de kosten niet altijd te worden doorgerekend,

hoewel dat in het kader van de professionalisering van de applicatiebeheerafdeling en het kostenbewustzijn van de klant wél is aan te bevelen. Bij een externe beheerorganisatie worden de kosten altijd doorgerekend.

16. De prijs die een product of dienst kost, dit moet volgens ASL op fixed-price basis worden doorgerekend.

17. Opstellen van het budget aan de hand van kentallen, plannen van de kosten en verdelen over de budgetten. Bewaken van het budget: monitoren van de kosten en budgetten, controleren en eventueel corrigeren van de facturen en het uitvoeren van een risicoanalyse. Evalueren van het budget: evalueren van de financiële prestaties, aanpassen van kentallen, opstellen van leerpuntenrapportages en het inventariseren van knelpunten en verbetermogelijkheden.

18. Kentallen, budgetten en begrotingen. 19. De beheerorganisatie is verantwoordelijk voor de identificatie van de kosten en de

afspraken met de klant over de facturering. De financiële administratie is verantwoordelijk voor de feitelijke facturering van de kosten.

20. Het doel van kwaliteitsmanagement is het verbeteren van de interne kwaliteit van product en dienst door deze te definiëren en te bewaken.

21. Product, proces, infrastructuur en organisatie. 22. Door incidenten en testrapporten te analyseren. 23. Kwaliteitsplanning, kwaliteitsbewaking en kwaliteitsreview. 24. Door een evaluatie of een audit uit te (laten) voeren. 25. Kwaliteitsnormen, kwaliteitsplannen, verbetermaatregelen, audits en reviews. 26. Het maken en bewaken van de afspraken met de klant is het doel van Service Level

Management. 27. De kwaliteitseisen van de klant die worden vertaald naar meetbare service levels,

meetwaarden om te beoordelen of de kwaliteitseisen worden gehaald.



28. Een Service Level Agreement, een overeenkomst tussen klant en leverancier. 29. Het functioneren van de applicatie, de functionaliteit van de applicatie, het proces van

dienstverlening en de inhoud van de dienstverlening. 30. Beschikbaarheid, performance, betrouwbaarheid, beveiliging en continuïteit. 31. De betrouwbaarheid, beschikbaarheid en stabiliteit van de applicatie. 32. Anders kunnen ze niet worden gemeten en geëvalueerd. 33. De service levels moeten functioneel en resultaatgericht zijn, ze moeten meetbaar en

aantoonbaar zijn, ze moeten een duidelijke relatie hebben met zaken die van belang zijn voor de klant en moeten haalbaar zijn.

34. Te ambitieuze afspraken werken frustrerend. 35. Ja, het contract moet regelmatig worden herzien (minimaal 1 keer per jaar) om het aan te

laten sluiten op de wensen van de klant. 36. Onderhandelen over de diensten, definiëren van de diensten, bewaken van de diensten en

evalueren van de diensten. 37. Beschikbaarheid, performance, betrouwbaarheid, beveiliging en continuïteit.

Functionaliteit, gebruikersgemak en inzichtelijkheid. De bereikbaarheid en beschikbaarheid van de applicatiebeheerorganisatie, de openingstijden, de snelheid van oplossen van storingen, de wijze van invoering van nieuwe releases. Diensten, dienstenscala, dienstencatalogus en dienstenniveau.

38. Afspraken over de omgang met problemen worden kortgesloten met kwaliteitsmanagement.

Waar/niet waar: 1. Waar 2. Niet waar 3. Waar 4. Waar 5. Waar 6. Waar 7. Waar 8. Waar 9. Niet waar 10. Niet waar, zie blz. 195 11. Waar 12. Waar 13. Niet waar, dat is het doel van kwaliteitsmanagement. 14. Waar 15. Waar 16. Niet waar, dan begrijpt de klant ze niet. 17. Waar 18. Waar 19. Waar 20. Niet waar, alleen de afspraken over de applicatie en de dienstverlening m.b.t. de

applicatie. Meerkeuzeopgaven: 1. B 2. D 3. C 4. D



5. D 6. D 7. D 8. A 9. C 10. B 11. A 12. D



Hoofdstuk 9 ACM Vragen en opdrachten met betrekking tot de casus: 1. Ja, het gaat vooral over ontwikkelingen in de omgeving van de gebruikersorganisatie en

ontwikkelingen in de applicaties ZorgPak en ZorgPlan. 2. Nee, nieuwe technologische ontwikkelingen die interessant zouden kunnen zijn voor de

informatievoorziening komen in de casus niet aan bod. 3. De markt verkennen naar nieuwe technologische ontwikkelingen. 4. De mogelijke fusie met HuisZorg. 5. Onderzoek doen naar de informatievoorziening met de ketenpartners. 6. Ja, het elektronisch zorgdossier en de vraag van de gebruikers om een centrale aansturing

van de planning. 7. Inventariseren van de relevante ontwikkelingen bij de klant en het bepalen van de impact

van deze ontwikkelingen op de applicaties. 8. Nadenken over de toekomst van de applicaties ZorgPlan en ZorgPak, zodat deze ook in de

toekomst de bedrijfsprocessen van HomeCare optimaal blijven ondersteunen. 9. Door eerst naar de toekomst van de individuele applicaties te kijken en daarna naar de

applicatieportfolio. 10. Ook de andere vormen van beheer moeten nadenken over de toekomst van de technische

infrastructuur en over de toekomst van de applicaties. Open vragen: 1. ACM richt zich op wat de klant wil. 2. Op de toekomst van de informatievoorziening en de levenscyclus van de

informatiesystemen en de informatievoorziening. 3. De scope van ACM is tweeledig: de toekomst van de individuele applicaties en de

toekomst van de totale applicatieportfolio. 4. Customer organization strategy. 5. De technologie, de gebruikersorganisatie en de omgeving. 6. Omdat het bij de applicatiebeheerorganisatie ontbreekt aan een langetermijnvisie. 7. Het onderhoud kan niet goed worden gepland en er kan niet goed worden gebudgetteerd. 8. Het brengt te grote risico’s met zich mee. 9. Omdat een applicatie niet op zich staat, maar altijd gegevens uitwisselt met andere

applicaties, waardoor niet alleen naar iedere applicatie apart moet worden gekeken, maar ook naar de totale applicatieportfolio.

10. Door vooruit te kijken naar de technologie, de gebruikersorganisatie en haar omgeving kan een strategie worden bepaald voor de toekomst van de informatievoorziening.

11. Bedrijfsprocessen, informatiesystemen en infrastructuur. 12. ICT developments strategy, Customer organization strategy en Customer environment

strategy. 13. Life Cycle Management en ICT-portfoliomanagement. 14. De richtinggevende blik van ACM moet leiden tot een strategie voor toekomstige

verbeteracties. 15. Het bepalen van de impact van technologische ontwikkelingen op de applicatieportfolio. 16. Bepalende onderwerpen voor de ICT developments strategy zijn:

• Technologieën op het gebied van het technisch beheer: o Infrastructuur o Systeemprogrammatuur

• Technologieën op het gebied van het applicatiebeheer: o Systeemontwikkelingsprogrammatuur



o Standaardprogrammatuur 17. Systeemontwikkelingsprogrammatuur en Standaardprogrammatuur. 18. Inventariseren van de nieuwe technologieën en bepaling van de impact van de nieuwe

technologieën. 19. Planningen, impactanalyses. 20. Bij dit proces is er vanwege de nadruk op de techniek een duidelijke link naar technisch

beheer, dat veel kennis kan leveren voor het proces ICT developments strategy. 21. Het bepalen van de impact van de ontwikkelingen in de omgeving van de

gebruikersorganisatie op de applicatieportfolio. 22. De ontwikkelingen in de informatievoorziening en gegevensuitwisselingen tussen

organisaties. Op basis van ketenmanagement wordt zicht gegeven op de eisen en kansen ten aanzien van de informatievoorziening van de gebruikersorganisatie.

23. Het bedrijfsproces, de informatiestromen, de informatiesystemen en de infrastructuur 24. Inventariseren van de bedrijfsprocessen en informatiestromen & Bepaling van de impact

van de ketenprocessen. 25. Het bepalen van de impact van de ontwikkelingen in de gebruikersorganisatie op de

applicatieportfolio.. 26. De uitvoer van customer environment strategy wordt gebruikt voor de ACM-processen

ICT-portfoliomanagement en Life Cycle Management. 27. De bedrijfsprocessen bij de klant; de klanten van de gebruikersorganisatie;de leveranciers

van de gebruikersorganisatie; de infrastructuur van de klant en de organisatie-inrichting van de klant.

28. Inventariseren van de relevante ontwikkelingen bij de klant & Bepaling van de impact van deze ontwikkelingen op de applicaties.

29. De gebruikersorganisatie die de informatie kunnen leveren voor de input van dit proces. 30. De resultaten van customer environment strategy kan als invoer dienen voor de OCM-

processen. 31. Het bepalen van de strategie voor de toekomst van een applicatie, zodat de applicatie het

bedrijfsproces de komende jaren optimaal kan blijven ondersteunen. 32. Applicaties gaan steeds langer mee, waardoor de noodzaak van grootschalige

nieuwbouwprojecten afneemt. Door applicaties steeds te blijven vernieuwen kan worden gewaarborgd dat ze ook in de toekomst het bedrijfsproces optimaal blijven ondersteunen.

33. De stand van zaken met betrekking tot de huidige kwaliteit van de applicatie; de gewenste veranderingen als gevolg van de veranderingen in het beleid; de technologische mogelijkheden met betrekking tot de huidige applicaties & de mogelijkheden om de huidige applicaties te vernieuwen.

34. Bepalen van de status van de huidige applicatie, In kaart brengen van het beleid ten aanzien van de huidige applicatie, Inventariseren van de technische mogelijkheden & Opstellen van een strategie met betrekking tot de huidige applicatie

35. Een beleidsplan voor de toekomst van een applicatie. 36. Functioneel beheer levert belangrijke informatie over het gebruik van applicaties en de

bedrijfsprocessen. 37. Het verzorgen van een optimale coördinatie ten aanzien van grote investeringen en

veranderingen in de verschillende objecten in de informatievoorziening. 38. In tegenstelling tot Life Cycle Management, dat zich bezighoudt met de strategie van één

enkele applicatie, houdt ICT-portfoliomanagement zich bezig met de strategie van het geheel aan applicaties.

39. Life Cycle Management.



40. Bepalen van de huidige status van de ICT-portfolio, In kaart brengen van het beleid ten aanzien van de ICT-portfolio, Inventariseren van de technische mogelijkheden & Opstellen van een strategie met betrekking tot de ICT-portfolio.

41. Een beleidsplan voor de toekomst van alle applicatie die in beheer zijn. Waar/niet waar: 1. Waar 2. Niet waar, drie tot vijf jaar. 3. Niet waar, nieuwe technologische ontwikkelingen. 4. Waar 5. Waar 6. Waar 7. Waar 8. Waar 9. Niet waar, er wordt ook naar de infrastructuur gekeken. 10. Waar 11. Waar 12. Waar 13. Niet waar 14. Niet waar, op de strategie van alle applicaties. 15. Waar Meerkeuzeopgaven: 1. C 2. B 3. C 4. A 5. B 6. C 7. B 8. C 9. C 10. B 11. D 12. C 13. D 14. B



Hoofdstuk 10 OCM Vragen en opdrachten met betrekking tot de casus: 1. Market definition: waar gaat de markt naar toe, account definition: wat wil de klant, skills

definition: welke mensen zijn er nodig op de ICT-afdeling en over welke kennis en vaardigheden moeten ze beschikken. Technology definition: met welke middelen wordt in toekomst de dienstverlening gerealiseerd en service delivery definition: hoe ziet de toekomstige dienstverlening naar de klant er uit?

2. Schaalvergroting, vergrijzing en de vraag naar meer efficiëncy. 3. De klanten worden mondiger en verwachten meer service. 4. Ja, de ontwikkeling van het nieuwe zorgdossier. 5. De rol van de medewerkers van de ICT-afdeling zal steeds meer een adviserende en

dienstverlenende worden in plaats van een technische. Gerard verwacht dat een aantal medewerkers van de ICT-afdeling daar veel moeite mee zal hebben. Hij stelt een scholings- en coachingstraject voor om de medewerkers van de ICT-afdeling te laten wennen aan deze nieuwe manier van werken.

6. Gerard maakt een plan voor de dienstverlening van de nieuwe ICT-afdeling. 7. Nee, hij krijgt opdracht van de directie om een plan te maken, dus eerst top-down. 8. De ACM-processen beschrijven de ontwikkelingen bij de klant en op het gebied van de

applicatie. Door daarvan goed op de hoogte te zijn, kan Gerard de dienstverlening beter laten aansluiten op de wensen van de klant.

9. Ja 10. Een beleidsplan voor de applicatiebeheerorganisatie. Open vragen: 1. Met de toekomst van de applicatiebeheerorganisatie en de dienstverlening die wordt

geboden. 2. Om ook in de toekomst diensten aan te kunnen bieden die aansluiten bij de wensen en

eisen van de klant. 3. Het mijden van risico’s door de aard van de werkzaamheden versus de nieuwe

ontwikkelingen in de markt, die zeer dynamisch en risicovol kunnen zijn. 4. Organisaties krijgen steeds meer inzicht in de ICT en in de ICT-dienstverlening en gaan

de laatste tijd steeds meer buiten de deur shoppen, dat wil zeggen dat sommige delen van de dienstverlening worden geoutsourced (uitbesteed) aan externe dienstverleners.

5. Organisaties kijken steeds meer of ze bepaalde applicatiebeheerdiensten ook buiten de deur kunnen vinden, ze zijn niet meer afhankelijk van hun eigen applicatiebeheerders..

6. De applicatiebeheerorganisaties zijn voornamelijk gefocust op het beheer van de problemen van alledag en niet op de langetermijn gericht.

7. OCM vult de strategische invalshoek van de applicatiebeheerorganisatie in. 8. De markt, de klanten, de technologie en de expertise. 9. De applicatiebeheerorganisatie en de diensten die ze aanbiedt. 10. Een beleidsplan voor de applicatiebeheerorganisatie en een beleidsplan voor de

dienstverlening naar de klant. 11. Market definition, account definition, skills definition, technology definition en service

delivery definition. 12. Twee beleidsplannen: voor de applicatiebeheerorganisatie en voor de services. 13. Inventarisatie van de huidige situatie, kansen en bedreigingen, de gewenste situatie en een

strategie voor de toekomst. 14. Sterktes, zwaktes, kansen en bedreigingen analyse, is een instrument om te bepalen waar

een bedrijf of product in de markt staat en hoe haar toekomst er uit kan zien.



15. Alle vier processen (market, account, skills en technology definition) komen samen in het vijfde proces (service delivery definition), waarin wordt bepaald welke diensten de applicatiebeheerorganisatie de komende jaren aanbiedt aan de gebruikersorganisatie. Hier wordt de strategie bepaald om de gewenste diensten te kunnen leveren, die vervolgens verder kan worden uitgewerkt in de andere OCM-processen.

16. Nee, ook interne applicatiebeheerorganisaties moeten zich beraden over hun eigen toekomst en de relatie met de klant.

17. Het proces ACM richt zich vooral op wat de klant wil, het proces OCM richt zich op de toekomst van de applicatiebeheerorganisatie. Beide processen zijn van belang om ook in de toekomst diensten aan te kunnen bieden die aansluiten bij de wensen en eisen van de klant.

18. Het bepalen van de positie van de applicatiebeheerorganisatie in haar omgeving en het vormgeven van de juiste samenwerkingsverbanden om de gewenste dienstverlening te kunnen leveren.

19. In dit proces worden ontwikkelingen en trends met betrekking tot de dienstverlening in kaart gebracht. Onderwerpen die hier een rol spelen zijn: Wie is ons klantgroepen?, wat is hun wensen en eisen, welke vervangende producten zijn er? Wat zijn alternatieven? Wie zijn de concurrenten? Welke leveranciers werken we mee samen, wat zijn de toekomstverwachtingen en ontwikkelingen van deze leveranciers? Welke diensten kunnen worden overgenomen door andere leveranciers, welke bedreigingen zijn er voor de eigen organisatie etc. Voor al deze afwegingen kan het concurrentiemodel van Porter worden gebruikt.

20. Inventarisatie van de huidige markt, definitie van kansen en bedreigingen, definitie van de gewenste markt en opstellen van een marktstrategie.

21. De positie van de applicatiebeheerorganisatie ten opzichte van de concurrentie en het inrichten van samenwerkingsverbanden om de diensten te kunnen leveren.

22. Vanuit account definition komt informatie over de ontwikkelingen bij de huidige klanten, deze kan worden afgestemd met de eigen bevindingen. Vanuit technology definition komt informatie over de nieuwste ontwikkelingen op het gebied van methoden en technieken. De informatie van market definition zal worden gebruikt bij het formuleren van de diensten in service delivery definition. De resultaten van market definition vormen de input voor de sturende processen.

23. Het vormgeven en uitwerken van de relatie met de klant, de gebruikersorganisatie. 24. Welk beeld heeft de klant van de applicatiebeheerorganisatie? Wie zijn de

contactpersonen bij de klant en hoe kunnen we deze benaderen? Welke producten en diensten kan de applicatiebeheerorganisatie aanbieden aan de klant en waar heeft de klant behoefte aan?

25. In kaart brengen van de huidige positie, definitie van kansen en bedreigingen, definitie van de gewenste diensten, bepalen van een strategie voor de toekomst.

26. Vanuit account definition gaat informatie naar service delivery definition, tijdens de inventarisatie vindt uitwisseling plaats met market definition en skills definition. Vanuit account definition gaat er informatie richting de sturende processen service level management en planning en control. Vanuit service level management wordt informatie geleverd over de huidige diensten, de performance en de relatie met de klant. De binnen account definition opgestelde strategie is input voor deze sturende processen.

27. In kaart brengen en verder ontwikkelen van de kennis en ervaring om goed in te kunnen spelen op de huidige en toekomstige services die aan de klant worden aangeboden.

28. Welke kennis is er nodig om de huidige en toekomstige diensten te realiseren? Welke ervaring is er nodig om de huidige en toekomstige diensten te kunnen realiseren? Van welke middelen moet de applicatiebeheerorganisatie op de hoogte zijn? Welke



kwaliteitssysteem kan worden ingezet om deze middelen te ondersteunen? Welk kennismanagementsysteem kan worden ingezet om de ervaring en expertise op te bouwen?

29. Kwaliteitsmanagement levert input over het huidige kwaliteitssysteem, planning en control levert informatie over de huidige kennis en ervaring en service level management levert informatie over de huidige afspraken daarover met de klant. Verder zijn er relaties met de OCM-processen technology definition en account definition. De resultaten van het proces skills definition vormen weer de input voor het proces service delivery definition.

30. Het proces technology definition houdt zich vooral bezig met de middelen waarmee de dienstverlening naar de klant toe wordt gerealiseerd, het proces skills definition brengt in kaart welke kennis en ervaring daarvoor nodig zijn.

31. De middelen te kiezen waarmee de organisatie de toekomstige dienstverlening gaat realiseren.

32. In kaart brengen van de huidige positie, definitie van kansen en bedreigingen, definitie van de gewenste technologie, bepalen van een strategie voor de toekomst.

33. Technology definition hangt nauw samen met skills definition waarmee informatie wordt uitgewisseld.

34. Het vormgeven van de gewenste dienstverlening over een periode van 2 à 3 jaar. 35. Hierbij kan gebruik worden gemaakt van het beleidsmodel zoals: missie voor de

applicatiebeheerorganisatie voor een periode van 2 tot 3 jaar. Concretiseren en SMART (Specifiek, Meetbaar, Acceptabel, Reëel en Tijdsgebonden) maken van de doelstellingen. Strategie en de route om doelen te bereiken, aangeven van de kritieke succesfactoren (KSF), benodigde middelen, …

36. Missie, strategie, doelstellingen, route en middelen. 37. Een strategie voor de toekomst van de applicatiebeheerorganisatie. 38. Alle andere processen leveren de input om het proces service delivery definition uit te

kunnen voeren. De uitvoer gaat richting de sturende processen, vooral richting service level management.

Waar/niet waar: 1. Waar 2. Niet waar 3. Niet waar 4. Niet waar 5. Waar 6. Waar 7. Niet waar, relatiebeheer 8. Niet waar, met de benodigde skills 9. Waar 10. Waar 11. Waar 12. Waar 13. Niet waar, alleen de ontwikkelingen in de markt. 14. Niet waar, die van de medewerkers. 15. Waar 16. Waar 17. Waar 18. Waar 19. Waar, zie blz. 234 20. Niet waar, de OCM-processen



Meerkeuzeopgaven: 1. B 2. C 3. D 4. D 5. A 6. D, hoort bij jezelf, niet bij de markt. 7. D 8. D 9. D 10. A 11. D 12. D



Hoofdstuk 11 Application Management volgens ITIL Vragen en opdrachten met betrekking tot de casus: 1. Eerste aanspreekpunt van de ICT-afdeling voor alle vragen, problemen en verzoeken om

informatie over de ICT-dienstverlening naar de gebruikers. 2. Infrastructuurbeheer richt zich op het beheer van de ICT-infrastructuur, conform de

afspraken in het SLA, zodat de ICT-infrastructuur de andere beheerprocessen optimaal kan ondersteunen. Applicatiebeheer richt zich volgens ITIL vooral op de ondersteuning van de bedrijfsprocessen, waarbij de applicaties deel uitmaken van de ICT-infrastructuur.

3. Het serviceteam is bij Bikefun verantwoordelijk voor de totale levenscyclus van de ICT-voorzieningen: de afspraken over de ontwikkeling, het gebruik en het beheer van alle ICT-voorzieningen.

4. Configuration Management, Incident Management, Problem Management, Change Management en Release Management.

5. Service Level Management, Availability Management, Capacity Management, Financial Management for IT-Services en IT Service Continuity Management.

6. Nee, de Servicedesk is het aanspreekpunt voor de gebruikers, het Serviceteam is vooral achter de schermen verantwoordelijk voor de totale levenscyclus van een ICT-voorziening. Het Serviceteam is daarmee vooral verantwoordelijk voor onderhoud en beheer.

7. ITIL ziet applicatiebeheer als een levenscyclus van ontwikkelactiviteiten en beheeractiviteiten, die worden uitgevoerd om het bedrijfsproces van de klant optimaal te ondersteunen.

8. ITIL geeft voornamelijk invulling geeft aan het technisch beheer, ASL geeft invulling aan het applicatiebeheer. Binnen ASL staat de applicatie centraal en maken de Servicemanagement-processen deel uit van het applicatiebeheer. Binnen ITIL AM is het precies andersom: de servicemanagementprocessen staan centraal, Application Management maakt hier deel van uit. ITIL AM gaat met name over het ontwikkelen van nieuwe applicaties, terwijl het onderhouds- en vernieuwingscluster van ASL vooral het aanpassen van applicaties beschrijft. Verder heeft ITIL AM vooral een operationele invalshoek, terwijl ASL ook tactische en strategische beheerprocessen kent.

9. Het ITIL-proces applicatiebeheer richt zich vooral op de nieuwbouw van applicaties. 10. Met name de onderhouds- en vernieuwingsprocessen: impactanalyse, ontwerp, realisatie,

testen en implementatie. Daarnaast moeten de verbindende ASL-processen Change Management en Software Control & Distribution worden afgestemd op de ITIL-processen Change Management en Release Management.



Open vragen: 1. Binnen de ITIL-legpuzzel vormen de beheerprocessen de puzzelstukjes. Deze staan niet

helemaal los van elkaar, maar overlappen elkaar gedeeltelijk. Zo heeft het ITIL-proces Problem Management altijd een relatie met het proces Incident Management en soms ook met het proces Change Management. Door de relaties tussen de processen lijken ze op puzzelstukjes die niet precies passen, maar elkaar gedeeltelijk overlappen.

2. Service Support, Service Delivery, Business Perspective, ICT-Infrastructure Management, Application Management, Security Management, IT Customer Relationship Management.

3. ICT-Service Management omvat het totale beheer van de ICT-infrastructuur, zowel onderhoud als exploitatie. De afnemer van de ICT-dienstverlening verwacht van de leverancier een service die optimaal is afgestemd op bedrijfsprocessen van de klant.

4. De klant verwacht een dienstverlening die optimaal is afgestemd op de bedrijfsprocessen van de klant. De leverancier verwacht van de klant duidelijkheid over de diensten die de klant wil afnemen en het niveau van de dienstverlening, met andere woorden de kwaliteitsverwachting van de klant.

5. Application Management bestaat volgens ITIL uit een combinatie van applicatieontwikkeling en servicemanagement. Door deze integrale benadering wordt de kloof tussen de ontwikkelafdeling en de beheerafdeling verkleind.

6. Application Management (applicatiebeheer)is volgens ITIL het geheel van processen en activiteiten die de ontwikkeling en het beheer en onderhoud van applicaties ondersteunen gedurende de gehele levenscyclus van de applicatie. Application Management is een combinatie van applicatieontwikkeling en servicemanagement. Application Development (applicatieontwikkeling) is het specificeren, ontwerpen en bouwen (of aankopen) van een applicatie die binnen een organisatie wordt gebruikt om te voorzien in de informatiebehoefte van de organisatie. Servicemanagement (dienstenbeheer) zijn de activiteiten die nodig zijn om ervoor te zorgen dat een applicatie voldoet aan de in een SLA overeengekomen service levels. Servicemanagement is gericht op het implementeren, uitvoeren en optimaliseren van applicaties.

7. Omdat er bij veel organisaties een kloof bestaat tussen de ontwikkelafdeling en de beheerafdeling, probeert ITIL deze twee disciplines beter op elkaar te laten aansluiten door ze samen te brengen onder Application Management.Door deze integrale benadering wordt de kloof tussen de ontwikkelafdeling en de beheerafdeling verkleind, waardoor de applicaties beter in staat zijn om te voorzien in de informatiebehoefte van de organisatie. Dit is van groot belang aangezien de concurrentiepositie van veel organisaties mede wordt bepaald door de mate waarin kan worden voorzien in de informatiebehoefte van medewerkers en klanten.

8. Met behulp van dit model kan worden beschreven hoe business en ICT beter aan elkaar kunnen worden gekoppeld. Doel is het inrichten van de samenwerking tussen business en ICT, zodat de doelen van het bedrijf beter, sneller en goedkoper gehaald kunnen worden. Uiteindelijk moeten de klanten van het bedrijf er profijt van hebben dat ICT optimaal wordt ingezet en benut.

9. De bedrijfsstrategie: de missie van de organisatie, de afgeleide doelen, de onderscheidende competenties en de allianties en samenwerking met derden. De ICT-strategie: de visie op voor de organisatie relevante technologieën, de ICT-competenties en de samenwerking met andere ICT-organisaties. De bedrijfsstructuur: de organisatiestructuur, de bedrijfsprocessen en hun samenhang, de vaardigheden om de strategie uit te voeren. De ICT- structuur: de ICT-architectuur, de uitvoerende ICT-processen en de beschikbare individuele vaardigheden.

10. Uitvoering van de bedrijfsstrategie, transformatie door technologie, benutting ICT-potentieel en optimaliseren van ICT-services.



11. De Application Managementlevenscyclus omvat volgens ITIl de volgende fasen: specificatie; ontwerp; bouw; implementatie; uitvoering; optimalisatie.

12. Voordelen: de applicaties sluiten beter aan op de specificaties van de beheerders, met als resultaat stabielere applicaties, die beter aansluiten bij de beschikbaarheidseisen van de klant. Verbeterd versie- en configuratiebeheer, waardoor meer inzicht wordt verkregen in de planning van de releases van applicaties. Doordat de beheerders al in een vroegtijdig stadium inzicht hebben in de applicatiecomponenten, kunnen de beheeractiviteiten daar beter op worden afgestemd. De beheerders zijn al in een vroegtijdig stadium bekend met de specificaties van de applicatie, waardoor tijdig inzicht wordt verkregen in service levels en prestatie-indicatoren en betere SLA’s kunnen worden opgesteld. Doordat de beheerders tijdig inzicht krijgen in specificaties en prestatie-indicatoren kan de infrastructuur tijdig worden aangepast aan de applicatie. Overdracht van de known errors door de ontwikkelaars naar de beheerders, waardoor de beheerders niet voor verrassingen komen te staan. Lagere beheerkosten, doordat de ontwikkel-, de testen de beheeromgevingen beter kunnen worden beheerd.

13. Dit zijn de kenmerken van het bedrijfsproces die bepalen of het bedrijfsproces de strategische doelen van de organisatie ondersteunt.

14. Functionele specificaties beschrijven de functionaliteit van een applicatie. De functionaliteit van een applicatie kan worden uitgedrukt in gedrag, activiteiten, taken, functies en diensten die een applicatie biedt. De functionele specificaties beschrijven wat de applicatie moet gaan doen. Technische specificaties beschrijven de technische werking van een applicatie. Bij de technische specificaties ligt de nadruk op de infrastructuur en de middelen. De technische specificaties beschrijven hoe de functionele specificaties kunnen worden gerealiseerd.

15. Een applicatieportfolio kan volgens ITIL Application Management worden gezien als een informatiesysteem waarin de belangrijkste kenmerken van applicaties worden geregistreerd.

16. Alle fasen uit de Application Managementlevenscyclus hebben een relatie met de servicemanagementprocessen. Met name met Configuration Management, Change Management en Release Management zijn er veel relaties. Configuration Management is verantwoordelijk voor de registratie van de belangrijkste kenmerken van de applicatie. Change Management is verantwoordelijk voor de coördinatie van het onderhoud en Release Management is verantwoordelijk voor de uitrol van een nieuwe release.

17. De overeenkomsten tussen ITIL Application Management en ASL zijn legio. ASL wordt ook wel het ITIL van het applicatiebeheer genoemd. Als we beide methoden naast elkaar leggen, valt op dat in beide methoden invulling wordt gegeven aan het beheer op drie niveaus: strategisch, tactisch en operationeel. Een aantal processen komt zowel voor bij ASL als bij ITIL, maar bij ITIL hebben de processen een technische invalshoek en bij ASL een applicatie-invalshoek.

18. Verschillen: daar waar ITIL voornamelijk invulling geeft aan het technisch beheer, geeft ASL invulling aan het applicatiebeheer. ASL ziet applicatiebeheer als een aparte discipline, ITIL AM beschrijft Application Management vanuit het perspectief van de ICT Service Manager. Binnen ASL staat de applicatie centraal en maken de Servicemanagement-processen deel uit van het applicatiebeheer. Binnen ITIL AM is het precies andersom: de servicemanagementprocessen staan centraal, Application Management maakt hier deel van uit.



Waar/niet waar: 1. Niet waar 2. Waar 3. Waar 4. Niet waar 5. Waar 6. Waar 7. Waar 8. Niet waar 9. Niet waar 10. Niet waar 11. Waar 12. Niet waar 13. Waar Meerkeuzeopgaven: 1. D 2. D 3. A 4. C 5. A 6. A 7. C 8. D 9. A 10. B 11. C 12. C 13. B



Hoofdstuk 12 Testen van informatiesystemen Vragen en opdrachten met betrekking tot de casus: 1. Verbeteren van de kwaliteit en stabiliteit van de applicaties ZorgPlan en ZorgPak. 2. Om de zwakke plekken in deze applicaties op te sporen. 3. Planbaar onderhoud kan van tevoren worden gepland, bijvoorbeeld een wetswijziging. 4. Ad hoc onderhoud kan niet van te voren worden gepland, als zich een probleem voordoet

waardoor een grote groep gebruikers niet meer verder kan werken, zal dat probleem meteen moeten worden opgelost.

5. Voorbereiding, specificatie, uitvoering en afronding. 6. De testomgeving moet zoveel mogelijk gescheiden zijn van de productieomgeving, maar

moet er wel zoveel mogelijk op lijken. 7. Testtools. 8. Door de fasering van het V-model te volgen, loopt het testtraject parallel aan het

systeemontwikkeltraject. 9. Die moet representatief zijn voor de productieomgeving. 10. Ervaring op te doen met testen. Open vragen: 1. Testen heeft als doel te controleren of een product, proces of dienst voldoet aan de vooraf

vastgestelde eisen. Toetsen is het inspecteren en verifiëren van de tussenproducten van een onderhoudstraject.

2. Volgens ISO bestaat testen uit een aantal activiteiten die worden uitgevoerd om een of meer kenmerken van een product, proces of dienst vast te stellen volgens een gespecificeerde procedure.

3. Functionaliteit, betrouwbaarheid, bruikbaarheid, efficiëntie, onderhoudbaarheid en portabiliteit.

4. Dynamische en statische. 5. Systeemontwikkeltrajecten halen de deadline, blijven binnen het budget en de

opgeleverde producten hebben voldoende kwaliteit. 6. Tijd, geld en kwaliteit. 7. Dynamische expliciet testen, dynamisch impliciet testen en statisch testen. 8. Aan de linkerkant van het V-model zien we de fasering van het onderhoudstraject. Dit

begint met een wijzigingsverzoek en eindigt met het daadwerkelijk uitvoeren van het onderhoud. Aan de rechterkant van het V-model zien we de verschillende tests die moeten worden uitgevoerd. De testsoorten moeten niet worden gezien als fasen uit het onderhoudstraject. Het zijn de meetpunten om te beoordelen of een bepaald aspect van het informatiesysteem voldoet aan de gestelde criteria.

9. White-boxtests testen de programmacode, de beschrijving en het technisch ontwerp. Hiervoor is kennis nodig van programmeren en ontwerpen, zodat deze tests alleen door de ontwikkelaars kunnen worden uitgevoerd. Met behulp van black-boxtests worden de functionele specificaties en de kwaliteitseisen van een informatiesysteem getest. Hiervoor is geen programmeerkennis nodig, maar kennis van de bedrijfsprocessen waarvoor het systeem zal worden gebruikt. Deze testen worden door de ontwikkelaars samen met de gebruikers en de beheerders uitgevoerd.

10. Programmatest en integratietest. 11. Systeemtest en acceptatietest. 12. Beveiliging, Controles, Functionaliteit, Handmatige ondersteuning, Herstel, Interfaces,

Middelengebruik, Productie, Regressie, Schaduwdraaien, Standaards, Stress/performance.



13. Om het testproces te plannen, wordt tijdens de vaststelling van de functionele specificaties een mastertestplan opgesteld waarin de vijf w’s van het testen worden vastgelegd (wie, welke test, waar, wanneer, waarmee?).

14. Planning en beheer, voorbereiding, specificatie, uitvoering en afronding. 15. Laboratoriumomgeving, systeemomgeving en de als-het-ware-productieomgeving. 16. Geautomatiseerde hulpmiddelen die een of meer van de volgende testactiviteiten

ondersteunen: planning, beheer, specificatie, uitvoering en beoordeling. Waar/niet waar: 1. Waar 2. Waar 3. Waar 4. Niet waar, tot onderhoud en beheer. 5. Waar 6. Waar 7. Waar 8. Niet waar, dat doen de white-boxtests. 9. Niet waar, alleen door de ontwikkelaars. 10. Niet waar 11. Waar 12. Waar 13. Waar 14. Waar Meerkeuzeopgaven: 1. B, zie blz. 266. 2. B 3. A 4. B 5. C 6. A 7. B 8. C 9. D 10. D 11. A 12. B



Modelexamen 1 1. A 2. B 3. D 4. C 5. B 6. A 7. B 8. A 9. C 10. D 11. C 12. A 13. A 14. B 15. C 16. D 17. C 18. C 19. C 20. B 21. A 22. A 23. D 24. B 25. B 26. A 27. B 28. A 29. B 30. B 31. B 32. B 33. C 34. B 35. C 36. A 37. D 38. A 39. A 40. A



Modelexamen 2 1. C 2. C 3. C 4. C 5. D 6. B 7. D 8. C 9. B 10. B 11. C 12. C 13. B 14. A 15. C 16. C 17. A 18. C 19. B 20. B 21. B 22. C 23. B 24. B 25. C 26. B 27. D 28. A 29. C 30. C 31. A 32. C 33. B 34. C 35. A 36. C 37. B 38. C 39. B 40. B

Uitwerkingen ASL

Documents

Transcript of Uitwerkingen ASL