Taakgebied realisatie

Transcriptie

1 Een monnik vroeg aan zijn meester: Ik zoek bevrijding. Hij antwoordde: Waar zijn dan je boeien? De leerling keek verbaasd: Die heb ik niet! Toen vroeg de zenmeester: Waarom zoek je dan naar bevrijding? (Zen) Hoofdstuk 15 Taakgebied realisatie V1.1 / 01 september 2015

2 Hoofdstuk Plaats in het MCTL-framework... 3 Achtergrond... 3 Definities... 4 Doel van dit taakgebied... 4 Hoe weet je dat het doel is bereikt?... 4 Input, activiteiten, output... 5 Activiteit: Bijwerken parameterinstellingen... 5 Activiteit: Bijwerken configuratie instellingen... 5 Activiteit: Aanpassen rollen en autorisaties... 5 Activiteit: Bijwerken documentatie... 6 Relaties met andere onderdelen van MCTL... 7 Opmerkingen Versiebeheer van alle documentatie Terugdringen noodzaak documentatie Terugdringen uitprinten documentatie... 9 Nuttige websites en boeken... 9 V Pagina 15-2

3 HOOFDSTUK 15 TAAKGEBIED REALISATIE In het taakgebied worden, zoals uit de naam al valt af te leiden, de wijzigingen werkelijk gerealiseerd. Hoewel wellicht een open deur, maar toch goed om vast te stellen is dat deze realisatie niet direct in productie plaatsvindt. In dit taakgebied wordt alles wat in het taakgebied Ontwerp is uitgewerkt in een ontwikkelomgeving en vervolgens in (acceptatie)test omgeving(en) uitgevoerd. Pas na een test, die in het taakgebied Testen plaatsvindt, die tot een goed resultaat leidt worden de wijzigingen in het taakgebied Transitie in de productieomgeving gerealiseerd. Indien, zoals de bedoeling is, de testomgeving (vrijwel) gelijk is aan de productieomgeving, worden sommige activiteiten van realisatie dus meermalen uitgevoerd. Een aantal resultaten van realisatie, zoals bijv. bijgewerkte gebruikershandleidingen, kunnen na goedkeuring vanuit de acceptatietestomgeving worden overgezet naar de productieomgeving. PLAATS IN HET MCTL-FRAMEWORK Het taakgebied Realisatie maakt onderdeel uit van het taakcluster Change support: ACHTERGROND Realisatie heeft lang vrijwel geheel op het bord van infrasupport en applicatie support en / of leveranciers gelegen. Het aanpassen van soft- en hardware zijn nadrukkelijk taken die daar lagen en tot op de dag van vandaag liggen. Door gebrek aan kennis en tijd bij functioneel support kwamen de V Pagina 15-3

4 uit te voeren functionele taken daar uiteindelijk terecht. Binnen MCTL wordt in de uitvoerende taken nadrukkelijk ingezoomd op de functioneel uit te voeren taken, die vanzelfsprekend binnen functioneel support worden uitgevoerd. De taken worden in dit taakgebied beschreven en uitgevoerd in de testomgeving(en). Vervolgens wordt in taakgebied Testen in de testomgeving worden getest of de technische en functionele aanpassingen voldoen aan de eisen. Daarna worden in taakgebied Transitie de wijzigingen in productie doorgevoerd. Om zeker te stellen dat de wijzigingen in productie identiek zijn aan die in de testomgeving(en) wordt de daarvoor benodigde documentatie beschreven. Dit leidt ertoe dat de wijzigingen in de testomgevingen conform deze documentatie in productie worden uitgevoerd. Het is mogelijk om via tooling het een en ander beter en vooral zekerder te regelen. Zijn bijv. parameterinstellingen in de acceptatietestomgeving gewijzigd, dan kan via tooling worden geregeld dat precies deze set parameterinstellingen (binnen taakgebied Transitie) in productie wordt overgenomen. Het maakt de kans op handmatige fouten aanzienlijk kleiner, maar dergelijke tools moeten dan natuurlijk wel ter beschikking staan. DEFINITIES Binnen het taakgebied Realisatie worden enige definities gebruikt. Degene die nog niet eerder ter sprake is gekomen worden hier genoemd: Definitie parameter Een parameter is een instelling van een systeem. Vanuit MCTL wordt nadrukkelijk gekeken naar instellingen die de functionele werking beïnvloeden. Voorbeelden zijn limieten (hoeveel bestellingen mag een klant in één keer doen), taalinstellingen, keuzemogelijkheden (bijv. in menu van restaurant), mogelijkheden die elkaar uitsluiten (idem in restaurantmenu) etc. Definitie configuratie De configuratie van een systeem is de mogelijkheid de werking van het systeem op een hoger niveau dan op het niveau van individuele parameters te beïnvloeden. Het configureren van een workflow in een systeem is hiervan een goed voorbeeld. DOEL VAN DIT TAAKGEBIED Het doel van het taakgebied Realisatie is het daadwerkelijk uitvoeren van aanpassingen op alle onderdelen die onder de verantwoordelijkheid van functioneel support vallen in de ontwikkel- en (acceptatie)testomgeving(en) inclusief de bijbehorende documentatie. De activiteiten kunnen samenvallen met de uitvoerende activiteiten aan de technische kant; bij infrasupport, applicatie support en evt. leverancier. Het kan voorkomen dat de functionele activiteiten worden uitgevoerd nadat de technische activiteiten zijn voltooid. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel wordt bereikt: De uitgevoerde wijzigingen wijken op minder dan 5% af van de in het ontwerp aangegeven wijzigingen In taakgebied Testen blijkt dat de wijzigingen inderdaad conform ontwerp zijn uitgevoerd V Pagina 15-4

5 De wijzigingen die in dit taakgebied in de (acceptatie)testomgeving(en) worden uitgevoerd worden 100% identiek in productie uitgevoerd / overgenomen (in taakgebied Transitie) en behoeven daarna geen verdere aanpassing Aantal vragen / fouten na inproductiename is minder dan 50% hoger dan het gemiddelde. N.B. hier worden alleen de vragen / fouten geteld die te wijten zijn aan onvoldoende goede uitvoering van de wijzigingen (Genoemde percentages zijn uiteraard indicatief) INPUT, ACTIVITEITEN, OUTPUT De input wordt gevormd door de in taakgebied Ontwerp uitgewerkte beschrijving van de aanpassingen. De output wordt gevormd door: 1. de werkelijk aangebrachte aanpassingen in de ontwikkel- en (acceptatie)testomgeving(en), 2. een beschrijving van de manier waarop aanpassingen zijn aangebracht zodanig dat die gebruikt kan worden in het taakgebied Transitie om de aanpassingen in productie aan te kunnen brengen 3. bijgewerkte documenten als gebruikershandleidingen en werkinstructies, die na goedkeuring in taakgebied Testen vervolgens binnen taakgebied Transitie worden overgezet naar de productieomgeving De activiteiten om te komen tot de genoemde output worden hierna uitgewerkt. ACTIVITEIT: BIJWERKEN PARAMETERINSTELLINGEN In deze activiteit worden de parameterinstellingen bijgewerkt conform de beschrijving in taakgebied Ontwerp. In nauw overleg met infrasupport, applicatie support of de leverancier moeten deze in ontwikkelomgeving(en) worden bijgewerkt. Alle gewijzigde parameterinstellingen moeten zodanig worden gedocumenteerd dat deze moeiteloos in het taakgebied Transitie kunnen worden herhaald, maar daar dan logischerwijs in de productieomgeving. ACTIVITEIT: BIJWERKEN CONFIGURATIE INSTELLINGEN De activiteit bijwerken configuratie instellingen heeft grote gelijkenis met de activiteit bijwerken parameterinstellingen. Hier worden, indien van toepassing, in overleg in de ontwikkelomgeving(en) configuratie instellingen bijgewerkt. Vervolgens wordt dat herhaald in de (acceptatie)testomgevingen. Alle gewijzigde configuratie instellingen moeten evenzo zodanig worden gedocumenteerd dat deze moeiteloos in het taakgebied Transitie kunnen worden herhaald, maar daar dan in de productieomgeving. ACTIVITEIT: AANPASSEN ROLLEN EN AUTORISATIES V Pagina 15-5

6 Indien in het taakgebied Ontwerp rolbeschrijvingen zijn aangepast, verwijderd of toegevoegd, dienen hier de bijbehorende autorisaties in de (acceptatie)testomgevingen te worden aangepast. Op die manier is te checken of de systemen inclusief de autorisaties functioneel precies goed werken. De uitgevoerde aanpassingen aan de rollen / autorisaties moeten zodanig worden gedocumenteerd dat deze moeiteloos in het taakgebied Transitie kunnen worden herhaald, maar daar dan in de productieomgeving. ACTIVITEIT: BIJWERKEN DOCUMENTATIE Er zijn diverse soorten documentatie te benoemen die moet worden bijgewerkt: 1. Documentatie voor gebruikers ter ondersteuning van het gebruik van het systeem (gebruikershandleidingen, werkinstructies, FAQ s, helpteksten op menuschermen, wiki s, zelfservice systemen) 2. Documentatie voor opleidings- / instructiedoeleinden 3. Documentatie bestemd voor de Service Desk, waardoor zij in staat zijn de eindgebruikers beter te ondersteunen (knowledge base, overzicht wijzigingen, FAQ s) 4. Documentatie voor intern gebruik binnen de groep Functioneel support zelf (wiki s, knowledge base, documentatie over de functionele werking van het systeem) Hierna worden de verschillende soorten documentatie toegelicht. Gebruikershandleidingen Gebruikershandleidingen moeten hier worden bijgewerkt aan de hand van de werkelijke wijzigingen die in taakgebied Ontwerp zijn beschreven. Dit dient te gebeuren in overleg met degenen die de software, parameterinstellingen en configuratie instellingen aanpassen. Ook dient er aandacht te zijn voor een goed versiebeheer. Aangezien hiervoor meestal geen tooling beschikbaar is, dient doorgaans handmatig een nieuwe versie te moeten worden aangemaakt en worden bijgehouden welke versie van de handleiding bij welke versie van het systeem hoort. Gebruikershandleidingen bestaan soms uit (lange) tekstdocumenten met bijv. screenshots. Vooral de omvang ervan kan gebruikers erg afschrikken, waardoor het gebruik van de handleidingen beperkt blijft. Het is mogelijk handleidingen in meer hapklare brokken onder te verdelen, zodat elk stukje uit de complete handleiding precies aansluit op de behoefte van een gebruiker. Instructievideo s Een alternatief voor gebruikershandleidingen, of een aanvulling daarop, zijn instructievideo s. In een instructievideo kan in korte tijd veel informatie worden overgedragen. Het wordt door gebruikers vaak als plezierig ervaren, maar helaas is het aanpassen van instructievideo s wel veel werk. In een bedrijf zijn op de werkvloer mensen met geen mogelijkheid te bewegen de aanwezige gebruikershandleidingen te gebruiken. Op proef worden enkele instructievideo s gemaakt. Er wordt enige drang toegepast: sommige menu-opties zijn pas te gebruiken indien eerst de instructievideo is bekeken en daar wordt ook op gemonitord. Dit helpt: het aantal functionele vragen neemt aantoonbaar af en het juiste gebruik van systemen toe. Helaas is er geen sprake van tijdsbesparing bij functioneel support: het maken en up-to-date houden van de instructievideo s kost ongeveer net zoveel tijd als de oude tekstuele handleidingen. V Pagina 15-6

7 Werkinstructies Voor werkinstructies geldt hetzelfde als wat reeds bij gebruikershandleidingen is beschreven. Ook van werkinstructies moet een nieuwe versie worden gemaakt en deze bijgewerkt aan de hand van de werkelijk aangebrachte wijzigingen in het systeem. Helpteksten in menuschermen Behalve handleidingen, werkinstructies en eventueel instructievideo s, moeten ook helpteksten die in menuschermen zijn opgenomen waar nodig worden bijgewerkt. Het betreft hier bijvoorbeeld kleine stukjes tekst die met een?-teken kunnen worden opgeroepen bij invoervelden. FAQ s / Wiki s FAQ s kunnen op verschillende plaatsen worden ingezet. Een bekende plaats is natuurlijk de website en het intranet, voor respectievelijk externe klanten en interne gebruikers, maar ook voor beheer en de service desk kan een FAQ nuttig zijn. Bij wijziging van een systeem moet hier worden gecheckt of deze FAQ s moeten worden aangepast, uitgebreid of juist ingekrompen. Voor wiki s en andere informatiebronnen die verbonden zijn aan het te wijzigen systeem geldt feitelijk hetzelfde verhaal. Ook deze moeten worden doorgelopen en waar nodig aangepast. Net zoals hiervoor is geschetst is voor FAQ s en wiki s vaak het versiebeheer een lastige en vooral handmatig uit te voeren taak. Knowledge base Een knowledge base wordt vooral bijgehouden en gebruikt binnen Functioneel support. Indien de Service Desk functionele taken uitvoert, kan ook zij gebruiker zijn van deze knowledge base. Intern opleidingsmateriaal In het geval een aparte interne opleidingsomgeving is gecreëerd voor het systeem en daar apart opleidingsmateriaal voor is ontwikkeld, moet dat hier worden aangepast aan het gewijzigde systeem. Indien een e-learning omgeving voor gebruikers is gemaakt, moet deze hier waar nodig worden aangepast. Uitvraagscripts Indien de Service Desk gebruik maakt van uitvraagscripts moeten deze hier waar nodig worden aangepast. Opruimen oude beschrijvingen van oplossingen / work-arounds Het opruimen van beschrijvingen van oude oplossingen en work-arounds verdient tot slot nog aparte aandacht. Dergelijke beschrijvingen kunnen in de toekomst verwarring zaaien en daardoor juist nieuwe fouten veroorzaken. Ze moeten daarom worden verwijderd. RELATIES MET ANDERE ONDERDELEN VAN MCTL Dit taakgebied kent de volgende belangrijke relaties: V Pagina 15-7

8 De belangrijkste relaties zijn die met taakgebied Ontwerp en Testen. Eerstgenoemde zal het bijgewerkte ontwerp aanleveren op basis waarvan de realisatie in gang kan worden gezet. Vervolgens zullen alle gerealiseerde onderdelen aan Testen worden opgeleverd. Uiteindelijk zullen via Testen in Transitie de gerealiseerde onderdelen in productie worden genomen. OPMERKINGEN De volgende opmerkingen zijn te maken betreffende dit taakgebied: 1. VERSIEBEHEER VAN ALLE DOCUMENTATIE De in dit taakgebied bijgewerkte documentatie (gebruikershandleidingen en werkinstructies) dient zorgvuldig en beveiligd tegen ongeautoriseerde updates op een productielocatie te worden geplaatst. Dat lijkt een eenvoudige zaak, maar de praktijk wijst uit dat gebruikers soms lang kunnen zoeken naar de juiste (versie van) documentatie. Daartegenover staat dat oudere versies juist op alle mogelijke manieren ontoegankelijk moeten worden gemaakt. Dat kan elektronisch door ze in een archief te plaatsen dat door slechts een beperkt aantal mensen mag worden ingezien. Voor zover nog aanwezig is het zaak om ook de papieren versies van oude documentatie fysiek te verwijderen. 2. TERUGDRINGEN NOODZAAK DOCUMENTATIE Documentatie heeft altijd de geur gehad van het hoort erbij, het moet nu eenmaal etc. Het maken en bijhouden van documentatie kan vaak niet op veel enthousiasme bij de betrokken medewerkers rekenen. Ook het daadwerkelijk gebruik is nogal een niet om over naar huis te schrijven. Een V Pagina 15-8

9 ontwikkeling die in gang is gezet met de opkomst van internet, is ontwikkelen van systemen waar voor het gebruik geen enkele vorm van gebruikershandleidingen of werkinstructies voor nodig is. In de afgelopen jaren is inderdaad aangetoond dat het mogelijk is systemen met een grote achterliggende complexiteit, zoals bijvoorbeeld het reserveren van vliegtickets, te ontsluiten voor gebruikers zonder dat deze eerst een omvangrijke handleiding moeten doorlezen. Webshops zijn er in geslaagd hun complexe systeem zo op een website te ontsluiten dat bezoekers kunnen bestellen terwijl soms deze bezoekers feitelijk alleen in staat zijn de meest basale computerhandelingen te verrichten. 3. TERUGDRINGEN UITPRINTEN DOCUMENTATIE Onder bepaalde gebruikersgroepen, meestal te onderscheiden naar leeftijd, bestaat een hardnekkige gewoonte documentatie uit te printen. Veelal is het argument dat lezen van papier prettiger is dan vanaf een scherm. Dat is overigens helemaal geen verkeerd argument. Toch is het, vooral vanuit het oogpunt van actualiteit, ongewenst dat documenten uitgeprint gaan rondzwerven. De kans dat er wijzigingen in de elektronische versie worden doorgevoerd is aanwezig en daardoor ontstaat gegarandeerd verwarring; welke versie is de juiste? Houdbaarheidsdatum In een bedrijf werkzaam in de voedselsector bestond bij medewerkers een sterke neiging alles uit te printen. Om dat fenomeen terug te dringen werd op elk document dat werd geprint een houdbaarheidsdatum gezet ( te gebruiken tot ), met doorgaans de datum van vandaag. De achterliggende gedachte: er is maar één juiste, actuele versie van elk document en dat is degene die op het intranet staat. Medewerkers, diep doordrongen van het fenomeen houdbaarheidsdatum, gooiden inderdaad alle uitgeprinte spullen na het verstrijken van de houdbaarheidsdatum weg. En na enige tijd.. NUTTIGE WEBSITES EN BOEKEN De volgende websites zijn voor taakgebied Realisatie (vanuit functioneel oogpunt gezien) interessant: MCTL.nl Website met alle informatie over MCTL; de achtergrond, een beschrijving van het model, video s, artikelen, etc. etc. Alle documenten, waaronder ook dit document, zijn vanaf deze website te downloaden. BiSL.nl Website met alle informatie over BiSL. BiSL is, als voorganger van MCTL, interessant vanwege de verzameling Best Practices, whitepapers en artikelen die op deze website zijn te vinden. V Pagina 15-9