Uitwerkingen van de opdrachten bij Applicatiebeheer volgens ASL Peter Janssen Pearson Education Benelux ISBN

Transcriptie

1 Uitwerkingen van de opdrachten bij Applicatiebeheer volgens ASL Peter Janssen Pearson Education Benelux ISBN

2 Inhoudsopgave: Toelichting op de antwoorden...3 Hoofdstuk 1 Informatiesystemen...4 Hoofdstuk 2 Beheer van informatiesystemen...6 Hoofdstuk 3 Hoofdstuk 4 Organisatie van het beheer...9 Procesmatige aanpak van het applicatiebeheer...11 Hoofdstuk 5 De beheerprocessen...14 Hoofdstuk 6 Hoofdstuk 7 De verbindende processen...18 Onderhoud en vernieuwing...21 Hoofdstuk 8 De sturende processen...25 Hoofdstuk 9 ACM...29 Hoofdstuk 10 OCM...32 Hoofdstuk 11 Hoofdstuk 12 Application Management volgens ITIL...36 Testen van informatiesystemen...40 Modelexamen Modelexamen Pearson Education Benelux Pagina 2

3 Toelichting op de antwoorden Dit document bevat de antwoorden die horen bij de opgaven uit het boek Applicatiebeheer volgens ASL, ISBN , 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 ( ) of via de website van EXIN ( 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 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 Pearson Education Benelux Pagina 3

4 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. Pearson Education Benelux Pagina 4

5 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 Pearson Education Benelux Pagina 5

6 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 Pearson Education Benelux Pagina 6

7 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. Pearson Education Benelux Pagina 7

8 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 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 Pearson Education Benelux Pagina 8

9 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 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. Pearson Education Benelux Pagina 9

10 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 Pearson Education Benelux Pagina 10

11 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 Pearson Education Benelux Pagina 11

12 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 Pearson Education Benelux Pagina 12

13 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 Pearson Education Benelux Pagina 13

14 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 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. Pearson Education Benelux Pagina 14

15 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 ICTdiensten. 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 Pearson Education Benelux Pagina 15

16 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 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 Pearson Education Benelux Pagina 16

17 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 C, zie blz B, zie blz A, zie blz C, zie blz A, zie blz. 127 Pearson Education Benelux Pagina 17

18 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. Pearson Education Benelux Pagina 18

19 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 Pearson Education Benelux Pagina 19

20 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 A, zie blz A, zie blz C, zie blz C, zie blz D, zie blz D, zie blz. 154 Pearson Education Benelux Pagina 20

21 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. Pearson Education Benelux Pagina 21

22 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. Pearson Education Benelux Pagina 22

23 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 Waar 16. Waar 17. Waar 18. Waar, zie blz Waar, zie blz Niet waar, sommige tests vinden plaats tijdens de fase Realization, zie blz 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 Pearson Education Benelux Pagina 23