Sinds alweer bijna twee jaar beschikt Finalist over een beheerorganisatie. Activiteiten die deel uitmaken van beheer zijn o.a. het leveren van support m.b.t. de ingevoerde content, oplossen van incidenten en het bouwen van nieuwe functionaliteit Request for Changes (RFC’s). Langzamerhand zien we overgang naar andere soorten projecten die in beheer worden genomen, zoals de complexere java applicaties bestemd voor gebruik door grote aantalen gebruikersgroepen i.p.v. de kleinere webapplicaties bedoeld voor inter- en intranet sites.

Het doel van dit artikel is om de aandachtsgebieden van het intake proces toe te lichten en de ervaringen met recente intakes hierin te verwerken.

Voordat een project in beheer komt wordt het voorafgegaan door een traject bestaande uit verschillende activiteiten. Ten grondslag aan een in beheer komend project ligt de SLA, opgesteld door de service manager in samenwerking met een account manager van Finalist, en de klant. In de SLA wordt o.a. bepaald hoeveel uren per jaar besteed mogen worden aan beheer, het maandelijkse factuurbedrag, operationele contactpersonen voor zowel klant als Finalist en andere soortgelijke afspraken. Vervolgens wordt er een intake gedaan van het project, in combinatie met een overdracht aan het beheerteam door de ontwikkelaars en verantwoordelijke projectmanager. Afhankelijk van hoe de intake en overdracht is verlopen, zal het beheerteam in overleg met het ontwikkelteam bepalen of er nog acties moeten volgen voordat het project daadwerkelijk in beheer genomen kan worden.

Om de intake en overdracht zo soepel en snel mogelijk te laten verlopen is het essentieel dat een project vanaf het begin goed is opgezet. Dit vooral om latere struikelblokken tijdens het beheer van een applicatie te voorkomen en om de afhankelijkheid van het beheerteam ten opzichte van de oorspronkelijke ontwikkelaars zo klein mogelijk te houden.

Bij iedere nieuwe oplevering verfijnt het beheerteam het intakedocument, waarin staat beschreven waar een project aan moet voldoen voordat het in beheer genomen kan worden. Het is de verwachting dat elk project dat in de toekomst binnen Finalist wordt opgeleverd, moet voldoen aan de richtlijnen van dit document voor het als voltooid en correct opgeleverd beschouwd wordt.

Documentatie
Een steeds terugkerend onderwerp voor verbetering en ban voor elke ontwikkelaar (of juist niet?) is het documenteren van zijn codes. Vaak wordt er in een project niet genoeg tijd/geld ingeruimd voor documentatie, en als deadlines voor oplevering beginnen te naderen wordt het bijwerken en voltooien van documentatie verwaarloosd. Vooral bij kleinere projecten of projecten gebaseerd op code van een voorgaand project is dit het geval.

Voor het beheerteam is documentatie van essentieel belang vanwege de volgende redenen:

• Om in het beheerteam een applicatie te kunnen begrijpen is een functioneel ontwerp en eventueel een technisch ontwerp voor de complexere functionaliteit noodzaak;
• Build procedures moeten helder zijn uitgelegd, zodanig dat de applicatie gemakkelijk lokaal gedraaid kan worden. Eventueel moeten afwijkende build procedures voor uitlevering naar een productieomgeving en/of acceptatieomgeving zijn beschreven;
• Een opsomming van de gebruikte software om de applicatie te kunnen draaien moet aanwezig zijn met daarin de versie van de JVM, de applicatie server, belangrijke libraries die handmatig geïnstalleerd moeten worden, ondersteunende tools (denk aan imagemagick), databases, enz. Als het project zijn einde nadert is het noodzakelijk om de software opnieuw na te lopen, omdat benodigde versies kunnen veranderen in het verloop van een project;
• Tevens is het belangrijk om URL’s te vermelden, zoals het startpunt van de applicatie en locatie van de beheeromgeving.

Om er zeker van te zijn dat alle belangrijke zaken zijn vermeld om de applicatie aan de praat te krijgen, is om verstandig vóór oplevering een clean build te doen op een lege database aan de hand van de geschreven documentatie.

ANT
ANT, en dus de structuur van de build.xml, staat centraal bij de build procedures. Regelmatig wordt voor een nieuw project een bestaande build structuur gebruikt uit een vorig project. Uit recente intakes is gebleken dat vaak achteraf de ANT targets niet worden bijgewerkt of sommige targets zelfs niet meer valide zijn. Dit kan tijdens onderhoud van een applicatie verwarrend zijn en veel tijd kosten om achteraf uit te zoeken. Een schone en correcte build structuur is zeker geen luxe en zal het intakeproces van een applicatie aanzienlijk versnellen.

Versiebeheer en Issuemanagement
Tijdens de intake van een applicatie wordt bepaald welke versie van de applicatie in beheer genomen gaat worden. Het moet uit CVS duidelijk af te leiden zijn welke versie van de applicatie als laatste is uitgerold naar de productieomgeving. Dat betekent dat tijdens het project alle releases naar productie en/of acceptatie omgevingen een versie moeten hebben om precies te kunnen zien wat in welke versie is opgelost/gebouwd en welke code wel of niet uitgerold is.
Tevens moeten alle versies nauwkeurig bijgehouden worden in de Roadmap van het Jira systeem, zodat op elke moment bekeken kan worden welke problemen in welke versie zijn opgelost en of gebouwde functionaliteit nog opgeleverd moet worden. Op deze manier kan de projectleider van het project een lijst met nog openstaande issues overdragen welke in onderhoud opgepakt kunnen worden.

In gevallen dat er na de in beheer name van een applicatie, nog functionaliteit gebouwd wordt door een projectteam anders dan het beheerteam. Ook hier is versiebeheer weer van groot belang, zodat issues en wensen niet door elkaar heen gaan lopen.

Klantorganisatie
Voor het beheerteam is het van belang om te weten wie de contactpersoon is bij de klant. De informatie moet terug te vinden zijn in het interne administratie systeem, FacturenOnline.

Daarnaast moeten de gegevens gedocumenteerd zijn voor de productieomgeving en/of acceptatieomgeving en procedures voor het aanmelden van server issues, opvragen van databases en uitrollen van applicatie releases. Tijdens de intake is een recente kopie nodig van de database en worden de procedures direct nagelopen.

Conclusie
Tijdens de opstart en de gehele duur tot aan oplevering van een project, loont het de moeite om zorg te dragen voor een aantal belangrijke activiteiten, zoals het documenteren van de applicatie, up-to-date houden van de build structuur, het beheren van versies en issues, en het bijhouden van klantgegevens en procedures.

Als er extra moeite en aandacht worden vrijgemaakt zal dit achteraf veel tijd en moeite (dus geld) besparen, doordat een project snel in beheer genomen kan worden en het beheerteam zo min mogelijk afhankelijk is van het oorspronkelijke ontwikkelteam. Daarnaast kunnen vervolg issues in het onderhoudstraject efficiënt worden opgepakt zodat de klant hier geen nadelige gevolgen van ondervindt.

Dit alles gezegd is een succesvolle intake en in-beheer-name van een applicatie iets waar men binnen een organisatie baat bij heeft en veel inspanning kan schelen in toekomstige projecten.

—————————————————————————————
Meer weten over Software beheer-specialist Finalist IT Group?