Releases en change-management bij maatwerkapplicaties

Releases en change-management bij maatwerkapplicaties - 01-26-2011 Door Wim - ITpedia - http://www.itpedia.nl

Releases en change-management bij maatwerkapplicaties door Wim - 01-26-2011 http://www.itpedia.nl/2011/01/26/releases-en-change-management-bij-maatwerk-applicaties/ Op grote maatwerk informatiesystemen waarbij de informatiebehoeften vaak en onregelmatig wijzigen zal veel onderhoud plaatsvinden. Onderhoud op functies die soms al weer veranderen voordat de vorige wijziging in productie is genomen. Deze vorm van onderhoud doet zich met name voor als het informatiesysteem regelgeving ondersteund die door de politiek wordt bepaald. Uitvoerenden hebben vrijwel geen invloed op hoe de regelgeving met alle uitzonderingen eruit komt te zien en op welk moment deze regelgeving van kracht wordt. De ervaring leert dat het geen zin heeft om tijd te rekken of de regelgeving onvolledig door te voeren. Wat wel werkt is de nieuwe regelgeving tijdelijk op een geïsoleerd (PC)systeem uit te voeren zodat tijd ontstaat om de nieuwe informatiebehoefte goed in het informatiesysteem in te bouwen. De beheersing over de constante stroom van zowel correctieve als adaptieve wijzigingen wordt change-management genoemd. Om de beheersbaarheid zo groot mogelijk te maken is het verstandig om het onderhoud te bundelen in kleine overzichtelijke releases van het informatiesysteem. Opzet Change-management organisatie. Bij omvangrijke maatwerksystemen zal er zeker na de in productie name een grote stroom van problemen opgang komen. Om niet te verzanden in een brei van problemen, foutmeldingen, storingen en verschillen in versies van modules dient er te worden gezocht naar een structuur waarin de toevloed van problemen kan worden gestroomlijnd. Het beheersen van zo'n omgeving wordt ook wel change-management genoemd.

Problemen die zich t.a.v. de applicaties bij applicatiebeheerders aandienen kunnen van velerlei aard en diepgang zijn. Tevens worden problemen door verschillende personen en instanties aangemeld. Om te komen tot een gefundeerde aanpak van problemen dienen deze eerst te worden geclassificeerd naar aard en herkomst. Hiertoe dient eerst een probleemanalyse plaats te vinden. De probleemanalyse door de applicatiebeheerder dient de volgende gegevens op te leveren : • Aantal betrokken programmamodules. • Controle status betrokken programmamodules Voor een juist versiebeheer dient rekening te worden gehouden met het overige onderhanden onderhoud. • Aantal betrokken gegevensverzamelingen. • Aantal betrokken records. • Ernst van het probleem. • Aard van het probleem (Adaptief, correctief...). • Controle of werking overeenkomt met de beschrijving in het ontwerp. • Eventueel controle op de broncode. • Eventueel afstemming met eindgebruikers. • Eventueel afstemming met onderhoudsteam. • Aangeven oplossingsrichting.

page 1 / 5


• Aangeven of aanpassing van het ontwerp nodig is. • Aangeven of aanpassing van de programmamodules nodig is. • Aangeven of aanpassing van ede administratieve organisatie nodig is. • Eventueel eenvoudige aanpassing Database d.m.v. SQL-update doorvoeren. • Eventueel complexere aanpassing Database d.m.v. geleide conversie doorvoeren. • Analyse van de gevolgen van de oplossing voor het systeem als geheel en voor de gebruikersorganisatie. Het resultaat van de probleemanalyse door de applicatiebeheerder dient een classificatie van het probleem te zijn. De verschillende probleemklasses wordt in Het classificeren van problemen beschreven. Het uitvoeren van de probleemanalyse gebeurt vaak intuïtief met als gevolg dat de impact van een oplossing vaak groter is dan verwacht. Om te komen tot een meer overdachte aanpak van problemen zou langer stilgestaan moeten worden bij de probleemanalyse. Voorwaarde hiervoor is dat alle problemen bij de applicatiebeheerder worden gemeld. De applicatiebeheerder kan de problemen dan eenduidig analyseren en volgen. Aanpak van een probleem. In de meeste gevallen is de aanpak van problemen voornamelijk gebaseerd op de aard en de ernst van een probleem. Adaptieve problemen worden meestal wel grondig aangepakt, ernstige problemen worden vanwege de spoedeisendheid vaak direct bij het onderhoudsteam aangeleverd. Deze aanpak leidt niet altijd tot het gewenste resultaat. Spoedeisende problemen kunnen bijvoorbeeld omvangrijker zijn dan ze in aanvang lijken. Het komt ook regelmatig voor dat ernstige problemen na verdere analyse worden ingetrokken. Oorzaken hiervan zijn : Het dubbel aanmelden van problemen; het alsnog d.m.v. SQL updaten van records en een verkeerde beoordeling. De wijze waarop een probleem wordt aangepakt moet echter uitsluitend afhankelijk worden gemaakt van de klasse waarin een probleem valt. Bij een groot probleem (klasse A) zal de aanpak grondig en uitgebreid moeten zijn. Er zou voor gekozen kunnen worden om alle problemen volgens klasse A aan te pakken zodat een eenduidige werkwijze ontstaat. In de praktijk is dit echter een onnodige verspilling van tijd en geld zijn. Het is daarom verstandig om per probleemklasse een aanpak vast te stellen waarbij ook de kwaliteit blijft gewaarborgd. Het is van belang om ook onder tijdsdruk niet van deze aanpak af te wijken. Ernstige problemen uit klasse A of B zullen ongeacht hun prioriteit wel degelijk grondig aangepakt moeten worden. Per probleemklasse wordt een algemene fasering weergegeven de stappen worden daarna afzonderlijk toegelicht. Aanpak klasse A probleem. fase a. Informatieanalyse. b. Ontwerp administratieve organisatie. c. Functioneel- en Technisch-ontwerp. d. Aanpassen van de procedures. e. Realisatie programmatuur en database. f. Acceptatietesten. g. Invoering. Aanpak klasse B probleem. fase b. Ontwerp administratieve organisatie. c. Functioneel- en Technisch-ontwerp. d. Aanpassen van de procedures. e. Realisatie programmatuur en database. f. Acceptatietesten. g. Invoering. Aanpak klasse C probleem. fase

page 2 / 5


c. e. f. g.

Functioneel- en Technisch-ontwerp. Realisatie programmatuur. Acceptatietesten. Invoering.

Aanpak klasse D probleem. fase e. Realisatie programmatuur. f. Acceptatietesten. g. Invoering. Aanpak klasse E probleem. fase c. Functioneel- en Technisch-ontwerp. d. Aanpassen van de procedures. e. Realisatie programmatuur. f. Acceptatietesten. g. Invoering. Aanpak klasse F probleem. fase c. Technisch-ontwerp. e. Realisatie programmatuur. f. Acceptatietesten. g. Invoering. Aanpak klasse G probleem. fase c. Technisch-ontwerp. e. Realisatie programmatuur. f. Acceptatietesten. g. Invoering. Aanpak klasse H probleem. fase c. Functioneel- en Technisch-ontwerp. e. Realisatie programmatuur. f. Acceptatietesten. g. Invoering. Aanpak klasse I probleem. fase c. Technisch-ontwerp. e. Realisatie programmatuur. f. Acceptatietesten. g. Invoering. Aanpak per fase. Ten aanzien van onderhoud kan per fase een aantal standaard producten en activiteiten worden gedefinieerd. Hieronder wordt daarop nader ingegaan. Plan van aanpak. Het plan van aanpak bevat de volgende producten : • Opdracht waarbij een formele opdrachtgever bekend dient te zijn. • Een overzicht van de personele inzet.

page 3 / 5


• Een overzicht van de uit te voeren activiteiten (kan door verwijzing naar klasse). • Een geschat tijdsplan van activiteiten met bezetting van mensen. • Een overzicht van de op te leveren producten (kan door verwijzing naar klasse). Deze fase wordt uitsluitend bij de grotere problemen toegepast waarbij een team wordt geformeerd dat als geheel voor de oplossing verantwoordelijk is. Te denken is aan materiedeskundige gebruikers, applicatiebeheerders, beleidsmedewerkers, testers (gebruikers) en leden van het onderhoudsteam. Door deze aanpak wordt een projectteamgeest gecreëerd, met een gezamenlijke verantwoordelijkheid. D.w.z. de verantwoordelijkheid wordt niet telkens van de ene persoon op de andere overgedragen. De applicatiebeheerder vervult hierin een centrale rol. Er zal in die gevallen een projectleider worden aangewezen. De projectleider is verantwoordelijk voor het maken van een plan van aanpak, de bewaking van de voortgang van het project en de rapportage aan de opdrachtgever. De projectleider blijft hiervoor verantwoordelijk totdat de opdracht is afgerond. In voorkomende gevallen kan de applicatiebeheerder als projectleider optreden. a. Informatieanalyse. De Informatie-analyse hoort ook thuis bij de grotere problemen en zal door een Informatieanalist worden uitgevoerd. De opgeleverde producten zijn een activiteitenmodel en een gegevensmodel. Verder wordt aandacht besteed aan eventuele aanpassingen in de systeemstructuur, de beveiliging en de gewenste kwaliteit van de op te leveren producten. De functioneelbeheerder zal producten uit de IA mede reviewen en daarbij met name letten op de inpasbaarheid in het informatiesysteem als geheel en de interfaces met de buitenwereld. Tevens beoordeelt hij of er een werkbare situatie zal ontstaan voor de eindgebruikers. b. Ontwerp administratieve organisatie. Deze fase wordt met name uitgevoerd bij grote wijzigingen op informatiesystemen. Aangezien het om onderhoud gaat dient er een nauwe samenwerking te zijn met de procedure-beheerder in verband met de principes zoals die bij de administratieve organisatie gelden. De Applicatiebeheerder dient vast te stellen of er een werkbare situatie ontstaat waarbij een vertaling naar het informatiesysteem mogelijk is en de risico's voldoende zijn afgedekt. c. Aanpassen van de procedures. Tijdens deze fase wordt vastgesteld op welke werkplek welke processen worden uitgevoerd. In de onderhoudsfase kunnen hierin veranderingen optreden a.g.v. veranderde inzichten. E.e.a. kan gevolgen hebben voor de organisatie, de processen, de procedures en de werkinstructies. Afhankelijk van de organisatie wordt een deel van de werkzaamheden door de applicatiebeheerder uitgevoerd. d. Functioneel- en Technisch-ontwerp. Het ontwerp wordt meestal door het onderhoudsteam onderhouden. Wijziging van het ontwerp kan een onderdeel zijn van grotere onderhoudsklussen. De applicatiebeheerder moet vaststellen of het ontwerp aansluit op de Informatie-analyse en de Administratieve Organisatie. Tevens dient er een afstemming met de beleving van de gebruikers plaats te vinden. A.g.v. onderhoud kunnen wijzigingen optreden in het database-ontwerp, reeds genomen ontwerpbeslissingen, interfaces en de lay-out van schermen en lijsten. e. Realisatie programmatuur en database. De realisatie komt in iedere probleemklasse voor. Het is echter niet zo dat iedere realisatie door het onderhoudsteam wordt uitgevoerd. Ook de invoering van nieuwe systeemsoftware of een SQL-update kan tot een realisatie worden gerekend. Tijdens de realisatie worden de in het ontwerp bedachte wijzigingen aangebracht. Het onderhoudsteam geeft een planning af voor de uit te voeren werkzaamheden. f. Acceptatietesten. Net als de realisatie komt de acceptatietest in alle probleemklassen voor, de diepgang van de test kan per klasse echter zeer verschillend zijn. Bij kleine aanpassingen kan een test door de applicatiebeheerder voldoende zijn om vast te stellen dat de wijziging is doorgevoerd. Bij grotere problemen (klasse A en B) dienen de gebruikers bij de test te worden betrokken. In dergelijke gevallen dient een testset te worden gemaakt en er dient een testverslag te worden gemaakt inclusief de archivering van de resultaten. Tevens dient te worden vastgesteld of de nieuwe functies aansluiten op de administratieve organisatie.

page 4 / 5


g. Invoering. De invoering van de oplossing van een probleem kan soms eenvoudig plaatsvinden door het overzetten van de aangepaste programmamodule met daarbij een telefoontje aan de gebruiker. Dit geldt met name voor de problemen in de klassen D, F, G en H. In voorkomende gevallen kan dit ook voor een probleem in de klasse C gelden. Het andere uiterste is de instelling van een Invoeringsteam, hetgeen afhankelijk is van de omvang van het probleem. De volgende extra activiteiten kunnen tijdens de invoering een rol spelen : • Overgang buiten de kantooruren, bijvoorbeeld in verband met een database-wijziging of conversie. • Het veilig stellen van de uitgangssituatie (backup). • Instructie en training van de eindgebruikers. • Pre-productierun. Bij een enkelvoudige uitvoering van een informatiesysteem en het onmiddellijk van kracht worden van de aanpassingen is het vrijwel onmogelijk om bij een systeem dat reeds in de onderhoudsfase verkeerd nog principes als schaduwdraaien en pilotgroepen toe te passen. De bruikbaarheid van de aangepaste programmamodules dient reeds in de acceptatietest te zijn aangetoond. _______________________________________________ PDF gegeneerd door ITpedia

page 5 / 5

Releases en change-management bij maatwerkapplicaties

Recommend Documents