Inhoudsopgave. Projectdocumenten niveau 4 IB en AO Versie 0.11

Transcriptie

1 Inhoudsopgave Inleiding...2 Algemene opmaak...2 Planning, urenverantwoording en kostenoverzicht...2 Planning...2 Urenverantwoording...2 Kostenoverzicht...3 Definitiestudie...4 Werkproces...4 Doel van het document...4 Inhoud van het document...4 Functioneel Ontwerp...6 Werkproces...6 Doel van het document...6 Inhoud van het document...6 Technisch ontwerp...7 Werkproces...7 Doel van het document...7 Inhoud van het document...7 Plan van Aanpak...9 Werkproces...9 Doel van het document...9 Inhoud van het document...9 Opstellen (en presenteren) van een implementatieplan...10 Werkproces...10 Doel van het document...10 Inhoud van het document...10 Pagina 1 van

2 Inleiding In dit document vind je informatie voor het schrijven van verschillende documenten en het uitvoeren van activiteiten bij het uitvoeren van projecten, behorende bij de werkprocessen binnen de niveau 4 opleidingen van het ICT-Lyceum van het Drenthe College. Algemene opmaak De volgende opmerkingen gelden voor elk document dat je schrijft binnen de uitvoering van een project. Controleer dus elke document voordat je het inlevert op deze punten: Bedenk bij elk document e/o product dat je schrijft/oplevert, voor wie je dat doet. Een document bedoeld voor de opdrachtgever stel je zakelijk op. Je gaat na of de opdrachtgever inhoudelijke kennis van zaken heeft en daarop pas je je taalgebruik aan. Begin elk document met een duidelijke inleiding. In de inleiding vertel je waar het document over gaat zodat de lezer weet wat hij gaat lezen. Probeer daarbij zo specifiek mogelijk te zijn; geef geen uitleg wat een definitiestudie, FO of TO is maar leg kort uit wat je gaat vertellen, hoe het document is op gebouwd of iets dat de lezer moet weten voordat hij het document gaat lezen. Zorg dat de opmaak van de documenten consequent is. Gebruik niet onnodig veel verschillende soorten opmaak van de tekst zonder dat je daar een reden voor hebt, dit leidt alleen maar af van de inhoud. Gebruik zoveel mogelijk de functies van je tekstverwerker om het document netjes op te maken, bijvoorbeeld kop- en voetteksten, automatische inhoudsopgave, opmaakprofielen etc. De verschillende documenten binnen een project moeten een gelijke opmaak hebben zodat je duidelijk kunt zien dat ze bij elkaar horen. Zorg dat belangrijke informatie duidelijk in of op het document vermeld staat. Als je een document op de grond vindt moet je kunnen zien van wie het is, waarvoor en wanneer het is geschreven. Geef alle documenten een duidelijk versienummer zodat je weet wat je laatste versie is, en wat een eerdere versie is. Elke keer als je een document (voorlopig) oplevert geef het een nieuw nummer. Aan het nummer moet ook te zien zijn dat het een definitieve versie is. Begin je nummering bijvoorbeeld met 0.1, 0.2, De definitieve (afsluitende) versie krijgt dan het nummer 1.0. Als het definitieve document in de loop van het project toch nog moet aanpassen, door bijvoorbeeld nieuwe informatie of inzichten, ga je verder met 1.1, 1.2 etc. Zo is duidelijk te zien dat de laatste documenten een aanpassing is op de definitieve versie. Bij grote inhoudelijke wijzigingen of een herschrijving van een document, wordt het eerste nummer verhoogt. Versienummers worden altijd met één tegelijk verhoogt. Dit voorkomt dat de indruk ontstaat dat er versies verloren zijn gegaan. Planning, urenverantwoording en kostenoverzicht Lever bij elk document of product dat je oplevert een planning, een urenverantwoording (logboek) en een kostenoverzicht in. De document lever je in als bijlage, zodat je de bijlage ook weer bijgewerkt mee kan nemen naar de volgende fase of opdracht. Planning Om het proces van het maken van een project of opdracht goed te laten verlopen moet je een planning maken. Hierdoor kan je zien wanneer welk onderdeel af moet zijn, of er verschillende fasen zijn die je moet plannen en hoeveel tijd het project, de opdracht of het uitvoeren van het werkproces in beslag gaat nemen. Bij het starten van het project of de opdracht maak je een globale planning. Je geeft de startdatum aan en het verloop van de verschillende fasen (oriëntatie-, ontwerp- en realisatiefase) in tijd (dagen of uren). In de planning moet zichtbaar zijn, wanneer je een document of product af hebt of wilt opleveren. Zorg ervoor wanneer je de volgende fase ingaat of aan de slag gaat met het volgende document, dat je planning is bijgewerkt met de werkzaamheden die zijn geweest, kloppend met je urenverantwoording. De werkzaamheden die je nog moet doen blijven gepland staan, maar zul je wel moeten controleren of het nog steeds klopt. Urenverantwoording Om tijdens een project of een opdracht, de werkzaamheden die je doet goed te volgen, zul je een Pagina 2 van

3 urenverantwoording bij moeten houden. De urenverantwoording verschaft de projectbegeleider en de opdrachtgever inzicht in het verloop van je project (uitvoering), in de planning en in het realiseren van je product. Je werkzaamheden leg je vast om je voortgang te bewaken. In de urenverantwoording geef je aan welke uren je aan de opdracht hebt gewerkt en wat je in deze uren hebt gedaan. De urenverantwoording moet verwerkt worden in je planning en in het kostenoverzicht, als het gaat om de manuren die zijn uitgegeven. Kostenoverzicht Welke kosten de opdrachtgever kan verwachten als het project wordt uitgevoerd. Wees zo compleet mogelijk. Je wilt aangeven wat het totale project gaat kosten voor de opdrachtgever. Kosten die je kunt berekenen moet je noemen, kosten die je niet kan voorspellen moet je indien mogelijk schatten, waarbij je verantwoord hoe je aan het bedrag komt. Als je geen schatting kunt maken maar je verwacht nog wel kosten moet je wel noemen waar je nog kosten verwacht. Geef ook aan welk kosten definitief (is al uitgegeven) zijn en welke geschat (komt nog). Het kostenoverzicht kan per product dat je oplevert verschillend zijn, omdat er wellicht nieuwe wensen bijkomen, die het kostenplaatje beïnvloeden. Pagina 3 van

4 Definitiestudie Werkproces ICT Beheerder: 1.1 Applicatieontwikkelaar: 1.1 Doel van het document De opdrachtgever moet op basis van de definitiestudie kunnen beslissen om wel of niet met het project te beginnen. In het document moet duidelijk worden wat de opbrengsten van het project zijn; eindproduct, oplossing van de probleem(stelling) en doelstelling. Daarnaast moeten de kosten duidelijk worden; materieel en mensen die nodig zijn, materialen die aangeschaft moeten worden en de tijd die nodig is voor de uitvoering (planning). Inhoud van het document Contactgegevens Noteer hier de contactgegevens van de opdrachtgever en van jezelf of van jouw bedrijf. Werkwijze Omschrijf de structuur van je werkwijze. Wanneer je volgens een projectfasering werkt en de opdrachtgever is daar niet van op de hoogte, is het belangrijk om dat uit te leggen. De opdrachtgever weet dan wat hij mag en kan verwachten van jou als bedrijf. Dit kun je doen in de inleiding. De werkwijze kun je ook omschrijven bij de planning, maar als je bijvoorbeeld het functioneel ontwerp benoemd in je tekst, dan is dat belangrijk om van tevoren aan te geven wat je daarmee bedoeld. Bedrijfsinformatie Beschrijf het bedrijf van de opdrachtgever. Denk hierbij aan de grootte; hoeveel mensen werken er, wat doen ze; wat zijn de belangrijkste werkzaamheden van het bedrijf, wat is de structuur; bijvoorbeeld afdelingen of een organigram. Wat is het werk van de opdrachtgever (huidige situatie) Voor wie ga je het project uitvoeren, de eindgebruikers; afdelingen, werknemers en/of opdrachtgeveren en beschrijf de werkzaamheden/handelingen die met het project te maken hebben. Geef hierbij een duidelijk beeld van de beginsituatie, hoe wordt er op het moment gewerkt. Wat is het probleem/doelstelling (gewenste situatie) Welke problemen zijn er op dit moment die moeten worden opgelost. Welke wensen zijn bij de opdrachtgever, bijvoorbeeld; uitbreiding of nieuwe functionaliteit. Het oplossen van de genoemde problemen en/of het mogelijk maken van de wensen is de doelstelling voor het project. Kijk uit dat je hier niet de oplossing noemt maar het probleem of doelstelling. Bijvoorbeeld 'het maken van een database' is niet een wens, maar 'het verbeteren van de informatiestroom binnen de organisatie' wel. Daarbij kan het maken van een database-toepassing wel de oplossing zijn. Probleemanalyse Analyseer de eerder genoemde problemen, wensen en doelstellingen. Verzamel informatie die met het probleem of de wens te maken hebben. Bekijk of het probleem of de wensen is op te delen in deelproblemen/wensen. Onderzoek wat de oorzaak is van het probleem. Waar heeft het probleem of de wens mee te maken; wat zijn de verbanden. Oplossing(-srichting) Welke oplossing heb je om de problemen te verhelpen en de doelstellingen te halen. Geef aan welke eigenschappen je oplossing moet hebben. Pagina 4 van

5 Middelen Welke middelen heb je nodig van de opdrachtgever, bijvoorbeeld een werkplek, specifieke hard- en software, externe deskundigheid, gegevens, inlogmogelijkheden. Hier moet de opdrachtgever een compleet overzicht hebben van de zaken die hij moet aanleveren/regelen voor de uitvoering van het project. Dit kan dus ook zijn; informatie, bijvoorbeeld bestaande rapportage, gegevens, bijvoorbeeld ingevulde formulieren die op dit moment worden gebruikt of toegang tot een of meerdere locaties, als je daar zaken moet inspecteren of controleren om het project te kunnen uitvoeren. Pagina 5 van

6 Functioneel Ontwerp Werkproces ICT Beheerder: 1.2 Applicatieontwikkelaar: 1.2 Doel van het document In het functioneel ontwerp moet duidelijk worden wat de wensen en eisen aan het project en/of eindproduct(en) zijn. Het moet een gedetailleerd beeld geven van wat de opdrachtgever wil/gaat krijgen. Je kunt tevens oplossingen aangeven of aanvullende wensen en/of eisen adviseren. Geef dit wel duidelijk aan en licht het toe bij de presentatie van het Functioneel Ontwerp bij de opdrachtgever. Inhoud van het document Opdrachtgever Beschrijf de opdrachtgever aan de hand van organisatie (afdeling), werkzaamheden, producten en/of diensten. Kijk daarbij voor al naar die zaken die van belang zijn voor het project, maar geef ook voldoende algemene informatie zodat de plaats en het belang van het project binnen en voor de opdrachtgever duidelijk wordt. Het kopje opdrachtgever in de definitiestudie beschrijft het bedrijf algemeen en de beschrijving. Binnen het functioneel ontwerp kan een specifieke afdeling of een medewerker zijn binnen het bedrijf. Je moet weten voor wie je het werk gaat doen. Algemene eisen Wat zijn de eisen en wensen die je van de opdrachtgever krijgt en wat is zijn doelstelling voor het project, deze kan namelijk anders zijn dan die van de eindgebruikers. Denk hierbij aan efficiëntie, beveiliging, kwaliteitsbewaking, flexibiliteit, beheersbaarheid, prestaties, opmaak en de gebruikersinterface. Eindgebruiker(s) De eindgebruikers zijn de mensen die uiteindelijk gebruik gaan maken van het eindproduct. Verschillende eindgebruikers hebben vaak verschillende eisen en wensen, maar vooral ook verschillende verwachtingen van het eindproduct. Het is belangrijk daarvan een compleet beeld te krijgen zodat je niet een project gaat uitvoeren waarvan niemand het eindproduct wil gebruiken. Vergeet geen gebruikers; een klant van een webwinkel is ook een gebruiker van dat informatiesysteem, de opdrachtgever is vaak ook gebruiker bijvoorbeeld als hij managmentinformatie uit het systeem wil halen. Wat zijn de verwachtingen (wensen en eisen) van de eindgebruiker(s) van het project/eindproduct Ga per eindgebruikersgroep bekijken wat ze verwachten van het eindproduct. Denk daarbij aan functionaliteit; hoe gaan ze gebruikmaken van het eindproduct, op welke momenten, bij welke werkzaamheden. Belangrijk is dat je kijkt met de ogen van de eindgebruiker; wat zien ze van het eindproduct, bijvoorbeeld de layout van gebruiksinterface, de formulieren, de rapporten of de tekst van een handleiding. Eén eindgebruiker kan verschillende momenten een andere functionaliteit verwachten. Wanneer je een nieuwe telefoon besteld bij een webwinkel verwacht je een ander scherm dan wanneer je de bestelstatus, de verzendstatus of je factuur wilt zien. Welke informatie wil de gebruiker uit het systeem halen? Pagina 6 van

7 Technisch ontwerp Werkproces ICT Beheerder: 1.2 Applicatieontwikkelaar: 1.2 Doel van het document Het maken en verantwoorden van technische beslissingen voor het project/eindproduct zodat functionele eisen en wensen gehaald gaan worden. Inhoud van het document Toelichting gekozen oplossing(en) Geef hier een samenvatting van alle gekozen oplossingen. Eindproduct(en) Een beschrijving van alle eindproducten. Geef per eindproduct de inhoud aan, om daarna per eindproduct de systeemonderdelen te (be)noemen. Systeemonderdelen / Objecten Welke losse systeemonderdelen / objecten kun je onderscheiden? Bekijk welke onderdelen/objecten van het eindproduct je kunt beschrijven. Van elk onderdeel/object moet je duidelijk de functie en zijn belangrijkste eigenschappen noemen. Door een duidelijke lijst van onderdelen/objecten te maken kun je later een planning maken waarbij verschillende personen verantwoordelijk zijn voor de verschillende onderdelen. Bijvoorbeeld: 'Welke services gaan draaien op een Windows 2003 Standaard server; DHCP, DNS, WINS, NTP, ADS, SMTP, POP3, IMAP?' 'Uit welke hardwarecomponenten bestaat je fysieke netwerk; servers en clients, switches, routers, patchkasten, bekabeling?' 'Welke database wordt gebruikt?' 'Welke formulieren worden er gebruikt? Welke pagina's omvatten de applicatie? Welke klassen moeten er komen? Objecten benoemen zoals variabelen, sessies, functies en methoden (belangrijk wanneer de info door verschillende programmeurs gebruikt dient te worden)' Kwaliteitseisen Welke (kwaliteits)eisen stel je aan elk systeemonderdeel? Probeer zoveel mogelijk te denken aan specifieke nummers, bijvoorbeeld hoeveel, hoe groot, hoe snel, hoe lang, hoe duur...? Aan de hand van deze gegevens kun je ook later je systeemtest gaan inrichten. Bijvoorbeeld: 'Hoeveel poorten moet een switch hebben?' 'Hoe groot moet de scoop van een DHCP server zijn?' 'Hoe snel moet het netwerk zijn, 100 Mbit of 1 Gbit?' 'Hoeveel clients hebben we nodig?' 'De locatie van de database, de pagina s etc. Noteer ook eventuele hostinggegevens en/of wachtwoorden.' 'Hoeveel gebruikers gaan er gebruik maken van de applicatie?' 'Welke afspraken gelden er? Denk hierbij aan afspraken over includes, functies, opmaak, variabelen, naamgeving en instellingen.' 'Hoe wordt er omgegaan dataopslag? Denk hierbij aan het opslaan van afbeeldingen.' Afhankelijkheden Welke relatie bestaat er tussen de verschillende systeemonderdelen? Hoe is een onderdeel afhankelijk van andere onderdelen? Door dit goed te beschrijven wat je vooraf moet vastleggen om de onderdelen apart te kunnen maken. Daarnaast geeft dit veel informatie voor de systeemtest. Behalve dat het onderdeel goed moet werken volgens de specificatie moeten de onderdelen ook goed samenwerken. Hierop kun je tijdens Pagina 7 van

8 de systeemtest ook testen. Bijvoorbeeld: 'Een Active Directory service is afhankelijk van een DNS.' 'De SMTP-, POP3- en IMAP-services zijn afhankelijk van de Mail Transport Agent.' 'Zijn er afhankelijkheden vanuit een andere applicatie?'(data-upload vanuit een ander pakket?)' 'Zijn er afhankelijkheden naar een andere applicatie? (data-output naar een ander pakket?)' 'Bestaat er een relatie met een ander pakket?' 'Vindt er een conversie plaats?' 'Moet er rekening gehouden worden met oude data?' Structuren Welke structuren kun je onderscheiden? Door de structuren uit te werken in schema's kan er veel duidelijk worden over de interne werking van het systeem. Dit levert veel informatie op over de kwaliteitseisen die je moet stellen aan de systeemonderdelen. Bijvoorbeeld een netwerkstructuur geeft veel informatie voor het bepalen van de snelheid van switches en bekabeling. Een stromingsdiagram voor gegevens geeft veel informatie hoe deze door een applicatie lopen. Daarmee kan bepaald worden welke modules wat welke manier specifieke gegevens moet verwerken. Bijvoorbeeld: 'Hoe ziet de DNS structuur eruit?' 'Hoe ziet de netwerkstructuur eruit?' 'Datamodel met uitwerkingen per veld' 'Linkenplan, boomstructuur' 'Klassendiagram' 'Usecasediagram (gebruikersscenario's)' Pagina 8 van

9 Plan van Aanpak Werkproces ICT Beheerder: 1.3 Applicatieontwikkelaar: 1.3 Doel van het document Als eenmaal het ontwerp van het informatiesysteem klaar is, wordt het tijd om het te gaan maken (realisatie fase). Meestal is dit de langste fase van een project, en het is daarom belangrijk om deze goed voor te bereiden. Je maakt een Plan van Aanpak voor het maken van het informatiesysteem; wie gaan er meewerken, hoeveel tijd is er beschikbaar, welke taken moeten worden uitgevoerd, welke investeringen moeten wanneer gedaan worden etc. Het doel van het document is dat je aan de hand van het document de realisatiefase met zo min mogelijk problemen kunt uitvoeren. Inhoud van het document Planning Op basis van het functioneel en technisch ontwerp inventariseer je de uit te voeren activiteiten. De activiteiten plan je in MS Project. Je onderbouwt de gekozen werkwijze binnen de planning. Geef aan op welke wijze en in welke volgorde je de planning hebt gemaakt. Projectvoorwaarden Zijn er nog andere zaken waar je rekening mee moet houden. Bijvoorbeeld: 'Zijn er afhankelijkheden die niet in de planning zichtbaar zijn?' 'Heb je een testruimte nodig?' 'Moeten de medewerkers ingelicht worden?' 'Zijn er procedures waar tijdens het uitvoeren rekening mee gehouden moet worden?' Kosten Vanuit de definitiestudie heb je een kostenoverzicht opgebouwd. Tijdens het schrijven van het functioneelen technisch ontwerp heb je de kosten bijgehouden en zonodig aangepast. In het plan van aanpak geef je aan welke middelen e/o materialen op welk moment aangeschaft moeten worden. Pagina 9 van

10 Opstellen (en presenteren) van een implementatieplan Werkproces ICT Beheerder: 2.1 Applicatieontwikkelaar: 3.1 Doel van het document De producten van het project zijn klaar en getest, daarmee kunnen ze gebruikt gaan worden door de eindgebruikers. Het in gebruik nemen is niet altijd zo gemakkelijk als het installeren en configureren van systemen, waarna het gebruik kan worden. Vaak moeten oude systemen uitgeschakeld, gegevens overgezet en/of infrastructuur aangepast worden. Daarnaast betekent een nieuw systeem vaak veel veranderingen voor de gebruikers. Zij moeten begeleid worden om de nieuwe systemen te kunnen gebruiken, bijvoorbeeld door instructie of scholing. Ook wil je niet dat de gebruikers te lang worden gestoord in hun werk, want dat zou te veel consequenties voor het bedrijf kunnen hebben. Het implementatieplan moet ervoor zorgen dat de invoering van een product zonder problemen zal verlopen. Houd daarbij altijd rekening met toekomstige activiteiten. Presenteren van het implementatieplan De applicatieontwikkelaar presenteert het implementatieplan. Je stelt een presentatie samen, nodigt de betrokkenen uit en presenteert het plan, waarbij je aandacht besteed aan de technische en organisatorische uitwerking van de applicatie. Besteed ook ruime aandacht aan de consequenties van de implementatie van de applicatie. Je zorgt ervoor dat alle betrokkenen juist en volledig geïnformeerd en voorbereid zijn. Inhoud van het document Wie is er verantwoordelijk voor de implementatie (Voorbereiding) Beschrijf de omgeving van het project waarvan de implementatie deel uitmaakt. Je kunt de doelstelling en het gewenste eindproduct noemen van de implementatie. Beschrijf voor de implementatie wie er verantwoordelijk is, wie welke rol heeft en wie er verder bij betrokken zijn. Geef ook aan of er consequenties zijn voor de betrokkenen of voor de organisatie. Verwijs eventueel naar eerder geschreven documenten zoals Plan van Aanpak of Functioneel Ontwerp. Beschrijving van de onderdelen Geef een beschrijving hoe de implementatie gaat verlopen. Geef aan hoe de verschillende onderdelen van het gewenste informatiesysteem geïnstalleerd en in gebruik genomen moeten worden en wie, wanneer en waar actie moet ondernemen om het product in te voeren. Dit kun je benoemen in een stappenplan of actielijst. Je kunt dit onderverdelen in kopjes, afhankelijk van het project en wat op dat moment de inhoud van je implementatieplan wordt. Het is belangrijk om bij elke stap die je beschrijft aan te geven wie verantwoordelijk is, wie er geïnformeerd moet worden en aan wie er gerapporteerd moet worden. In dit stuk theorie zijn er kopjes opgenomen die in een implementatieplan kunnen worden opgenomen. Deze kopjes zijn bedoeld als voorbeeld om een plan te kunnen schrijven. Uiteraard ben je vrij om onderdelen toe te voegen en om een eigen invulling aan de onderdelen te geven. Bedenk dat elke implementatie anders is. Beschrijving van de technische installatie Technische onderdelen Bepaal de onderdelen die geïnstalleerd moeten worden. Maak een inventarisatie wat er moet gebeuren. De volgende vragen zou je voor jezelf kunnen stellen: 'Moeten er ook (aanvullende) tools worden geïnstalleerd?' 'Zijn er bestaande systemen die voorbereidt of aangepast moeten worden?' 'Zijn er technische afhankelijkheden? Moet de server down?' 'Moet de Infrastructuur aangepast worden?' Pagina 10 van

11 'Moet er rekening gehouden worden met gebruikte informatiesystemen? Is er een koppeling met bestaande systemen?' 'Moet er een conversie van bestanden plaatsvinden?' 'Moeten er bestanden worden geïmporteerd?' 'Zijn er configuratiegegevens die je nodig hebt?' 'Wat is het beste moment voor de installatie?' 'Moet er een backup gemaakt worden? Hoe ga je dat doen? Wie, waar, waarop, wanneer?' 'Heb je nog bepaalde info nodig? Te denk valt aan wachtwoorden, hostinggegevens? En hoe ga je om met deze informatie?' Bedrijfsstandaarden en richtlijnen Door de implementatie van de nieuwe software zal het overzicht met de bedrijfsstandaarden voor hardware en software worden uitgebreid. Werk in deze paragraaf uit hoe je aan het bedoelde overzicht komt en welke procedures gevolgd moeten worden om dit overzicht uit te breiden. Om de nieuwe software draaiend te krijgen, moeten er mogelijk ook (aanvullende) tools worden geïnstalleerd. Controleer of er ITIL- of ISO-systemen zijn geimplementeerd. Beleid en richtlijnen Aangezien je aan het netwerk en de computers aanpassingen moeten doorvoeren, zal je uit moeten werken hoe hiermee omgegaan moet worden. Inventariseer de mogelijkheden met betrekking tot de beleidsregels of richtlijnen voor het gebruik van computers en het netwerk. Werk vervolgens uit hoe dit zou moeten aangepast zodat de implementatie kan plaatsvinden. Het kan zijn dat er nieuwe procedures opgesteld moeten worden. Doe dit uiteraard in overleg met de opdrachtgever en de betrokken afdeling(en). Opleidingen Gebruiker(s) Leg in hier vast hoe je er voor gaat zorgen dat de (toekomstige) gebruikers volledige op de hoogte zijn van de nieuwe software die je gaat implementeren. Implementeren doe je niet alleen, maar vooral samen (ook met de gebruikers). Beschrijf de rol van de gebruikers binnen het implementatietraject. Werk in ieder geval de volgende punten uit: - Gebruikers vroegtijdig informeren over de op handen zijnde aanpassingen en houdt de gebruikers ook tussentijds op de hoogte (hoe, wie, wat, wanneer?). - Opleiden van de gebruikers zodat zij direct na de oplevering met de nieuwe software overweg kunnen. Stel jezelf de volgende aanvullende vragen: 'Hoe verloopt de communicatie naar de afdelingen?' 'Hoe zorgen we ervoor, dat ook op de afdeling controle en bijsturing plaatsvindt.' 'Richt je je op een bepaalde groep medewerkers of op alle medewerkers binnen de organisatie? Of gefaseerd?' 'Trainen/opleiden van gebruikers en beheerders. Maak een juiste analyse van het kennisniveau van de gebruikers.' 'Wanneer je bezig bent met het opleiden en informeren van de (toekomstige) eindgebruikers en beheerders, zul je tegen zaken aan lopen die niet zijn voorzien maar die belangrijk genoeg zijn om niet te vergeten. De vraag is: hoe ga je hiermee om? Leg ook vast hoe je omgaat met aandachtspunten, problemen en/of onregelmatigheden die meer aandacht vereisen' Beheerder(s) Voor de beheerders geldt in meer of mindere mate hetzelfde als voor de gebruikers, zoals in de vorige paragraaf is beschreven. Werk dit dus ook uit voor de (toekomstige) beheerder(s). Zorg er ook voor als dat nodig is dat er leden voor het installatie- en ondersteuningsteam worden getraind om die betreffende werkzaamheden tijdens de uitvoering van de implementatie uit te voeren. Documentatie (eindgebruikers- en beheerders instructies) In je Functioneel Ontwerp staat genoemd welke documentatie er binnen het project moet worden opgeleverd, Bepaal op welke manier de instructies (gebruikers en beheerders) moeten worden opgesteld. Maak een analyse van het kennisniveau van de gebruikers. Beschrijf vervolgens hoe de documentatie geïmplementeerd wordt. Pagina 11 van

12 Stel jezelf aanvullende vragen zoals: 'Moet er ook cursusmateriaal worden ontwikkeld voor het opleiden van de gebruikers? Op welke manier worden de gebruikers geïnformeerd over de (bestaande) documentatie?' 'Optimaliseren procedures (handboeken en formulieren moeten misschien aangepast worden en mutaties moeten wellicht op andere wijze worden aangeleverd)' Beschrijving van de implementatie Beschrijf hoe je de daadwerkelijke implementatie gaat uitvoeren. Aan welke randvoorwaarden moet zijn voldaan om aan de implementatie te beginnen en hoe stel je vast of aan al die voorwaarden is voldaan. Denk ook aan een zogenaamd fall-backscenario voor het geval dat de uitrol mislukt en de operationele omgeving weer beschikbaar moet zijn. Houd ook rekening met het live -gaan van de nieuwe software in de operationele omgeving. Zorg dat op dat moment menskracht beschikbaar is om eventuele problemen en dergelijke op te lossen c.q. op te vangen. Hier noteer je dus daadwerkelijk een stappenplan voor de implementatie. Stel jezelf de volgende aanvullende vragen: 'Wordt er schaduw gedraaid? Op welk moment wordt er live gedraaid?' 'Wat gebeurt er als de implementatie mislukt?' 'Zijn alle onderdelen van de technische installatie voltooid?' Testmethode en risico s beperken Het testen van het informatiesysteem (de systeemtest, de functionele test en de acceptatietest) heeft in de meeste gevallen al plaatsgevonden voor de implementatie. Het is van belang om in het implementatieplan vast te leggen hoe er eventueel getest wordt na de implementatie om risico's te beperken en problemen voor te zijn. De volgende vragen zou je voor jezelf kunnen stellen: 'Hoe ga je om met onjuistheden in de applicatie? 'Hoe verloopt de procedure als er iets gewijzigd moet worden aan de applicatie?' 'Hoe verloopt de procedure wanneer de functionaliteit moet veranderen?' 'Hoe wordt er omgegaan met incidenten/fouten?' Beschrijving van de evaluatie Nadat de implementatie achter de rug is en de rust is weergekeerd, moet er een evaluatie gehouden worden van de implementatie. Werk hiervoor een procedure uit. Titel: Projectdocumenten niveau 4 IB en AO Versie: 0.11 Datum: 2 december 2008 Auteur: Harmen Steenbergen / Titia Brouwer Pagina 12 van