Pilot omgeving
Met pilot- en productie omgevingen hoeft een gebruiker zich niet mee te bemoeien. Voor de eindgebruiker hoort het transparant te zijn waar een applicatie draait. In grote lijnen kennen we twee smaken:
Technisch gezien zijn dit echter heel verschillende oplossingen. Voor de IT afdeling ligt bij cloud het accent op beveiliging en connectiviteit, maar bij een on-premise oplossing ligt het accent op beheer en onderhoud van de pilot en productie omgevingen.
Wat de keuze ook wordt, houdt er rekening mee dat de pilot omgeving zoveel mogelijk moet lijken op de toekomstige productie omgeving. Het wordt namelijk heel vervelend als de productie omgeving zich na oplevering anders gedraagt als in de proeftuin was waargenomen.
In de proeftuin zeggen we dus “ja” tegen het complete systeem. Zowel technisch als functioneel. Het kan dus zijn dat de gebruikers de software functioneel accepteren maar dat systeembeheer tot de conclusie komt dat deze niet goed te beheren is. Daarom is het van belang dat beide disciplines van begin af aan bij de selectie van de software samenwerken.
Mogelijk moet er voor het neerzetten van de proeftuin eerst nog specifieke systemen, bepaalde versies van ondersteunende software of specifieke communicatie protocollen worden ingericht. Met de ICT afdeling worden deze activiteiten besproken, ingepland en uitgevoerd. Pas dan is de pilot omgeving klaar om de software te installeren.
Het installeren van de software is een belangrijk onderdeel van de proeftuin. Tijdens de installatie leren we namelijk lessen die betrekking hebben op de technische infrastructuur. Tevens wordt helder welke beheersinspanningen de software met zich meebrengt. Zo krijgen we dus duidelijk wat de nodigde activiteiten voor de daadwerkelijke implementatie zullen zijn.
Al deze informatie documenteren we ter voorbereiding op de implementatie.
Bij de keuze voor een SaaS oplossing zijn de installatie inspanningen een stuk minder. Deze beperking zich tot het koppelen via API’s, het monitoren van de netwerkbelasting en controleren van de beveiligingsinstellingen.
Een standaard software applicatie is nooit gemaakt voor één specifieke omstandigheid maar moet in veel verschillende organisaties toegepast kunnen worden. Grote applicaties kennen vaak honderden parameters. Om de software te kunnen testen moeten de parameters in de proeftuin worden ingesteld. Meestal gaat dit om wat we business rules noemen. Voorbeelden hiervan zijn:
De resultaten hiervan moeten we ook documenteren, liefst met een onderbouwing van de gemaakte keuzes. Het parametriseren is meestal de grootste en belangrijkste activiteit bij het invoeren van een software applicatie. Omdat het zo tijdrovend en intensief is is het de vraag of dit al volledig in de proeftuin moet gebeuren.
De voor de hand liggende (Agile) keuze is het parametriseren geleidelijk te doen. Bij het bepalen van de testgevallen bijvoorbeeld. De parameters blijken in de praktijk sowieso niet statisch te zijn. Ook als de software al langere tijd in gebruik is kunnen nog aanpassingen nodig zijn. Voor die gevallen is het verstandig om de pilot omgeving na ingebruikname in stand te houden. Dan is altijd te testen welk effect de aanpassing van een parameter heeft op alle uithoeken van een applicatie zonder dat er gevolgen zijn voor de dagelijkse productie.
Om de applicatie te kunnen gebruiken moeten een groot aantal basisgegevens worden opgevoerd. Daarvoor moet er inzicht zijn over het verloop van de proeftuin en hoe de software gebruikt gaat worden. Hiervoor maken en bespreken we vooraf een document betreffende de volgende activiteiten:
In dit onderdeel van proeftuin wordt ervaring opgedaan betreffende het functioneelbeheer rond de software. De kennis die de functioneelbeheerders hierbij opdoen komt van pas bij het begeleiden van de testers.
Het kan zijn dat er aanvullend maatwerk nodig is om te kunnen voldoen aan de requirements. In overleg met de leverancier kunnen we er voor kiezen om het maatwerk in de proeftuin te realiseren. Dit is afhankelijk of het functioneren van het maatwerk invloed heeft op een go/no-go beslissing. De omvang van het maatwerk en wat de gevolgen voor het onderhoud op nieuwe releases van het pakket moeten we eerst in kaart brengen.
Hoe is de integratie naar andere systemen geregeld? Kan de software gegevens uitwisselen met andere applicaties, basis administraties? Is er standaard functionaliteit aanwezig voor het onderhouden van interfaces? Veel applicaties zijn voorzien van standaard interfaces. Tegenwoordig wordt veel gewerkt met API’s waarbij een live koppeling met andere systemen kan worden gemaakt. Hou wel in gedachten dat je aan het testen bent en dat het niet de bedoeling is dat je productie data in andere systemen aanpast. In overleg moeten we bepalen hoe we in zulke gevallen de juiste werking van de software kunnen aantonen.
Voor het testen van de software is een minimale vulling van de bestanden nodig. Deze data kan via de eerder genoemde interfaces worden ingelezen. Vaak moeten we deze data eerst bewerken om aan een goeie dataset te komen. Meer hier over lees je in het artikel datamigratie of conversie. Bedenk dat het hier om het testen van software gaat en er dus sprake dient te zijn van een proefconversie.
Dit artikel kwam tot stand i.s.m. Suzette de Raadt
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.