Specificaties cruciaal bij offshoring

Betere resultaten zijn het gevolg van adequate functionele beschrijvingen

Een van de belangrijkste en tegelijkertijd lastigste factoren bij offshoring van ict-diensten is de kwaliteit van de softwarespecificaties. In de praktijk blijken deze vaak onvoldoende. Waar gaat het mis?

Het resultaat van offshoring is niet altijd even positief. De nieuw ontwikkelde of aangepaste applicatie voldoet niet aan de verwachtingen of het project slokt meer tijd en budget op dan was begroot. De oorzaak ligt dikwijls bij de softwarespecificaties. Waar moet de applicatie allemaal aan voldoen? In de praktijk blijkt regelmatig dat er gegevens ontbreken, inconsistenties zijn of er ruimte bestaat voor interpretatieverschillen.

Welke zaken beïnvloeden nu eigenlijk precies de kwaliteit van de specificaties? De volgende vier hoofdfactoren zijn zeker van belang: organisatie, processen, middelen en mensen. Gerichte aanpassingen binnen deze factoren resulteren in winst: een gerichter en meer voorspelbaar proces. In onderstaande ‘best practices’ wordt uitgelegd hoe dat gaat.

Organisatie

Bij offshoring van activiteiten wordt de relatie tussen opdrachtgever en opdrachtnemer ingevuld door een frontoffice en een backoffice. Op locatie bij de klant vormt de frontoffice de schakel tussen de lokale business units en de uitvoerende global backoffice(s) in bijvoorbeeld India, Oost-Europa of China.

Ervaren requirements engineers in de frontoffice verzamelen de business issues en vertalen deze naar functionele en niet-functionele softwarespecificaties. Zij betrekken daarbij (naast de toekomstige gebruikers) ook de toekomstige software engineers, test engineers en beheerders.

Vervolgens draagt de frontoffice de softwarespecificaties over aan de backoffice en geeft daarbij de nodige toelichting. Nu kan de applicatie – onder voortdurend overleg en toezicht – gebouwd worden. Dit vindt zoveel mogelijk plaats in het backoffice.

Processen

De complexiteit en de omvang van applicaties maken het veelal onmogelijk om in een keer alle softwarespecificaties te definiëren, de hele oplossing te ontwerpen, de software te bouwen en tenslotte de kwaliteit ervan vast te stellen.

Met een iteratieve of geleidelijk verdergaande aanpak kunnen de grootste technische, functionele en organisatorische risico’s steeds als eerste worden opgelost. Dit verhoogt de voorspelbaarheid van het project en verlaagt de kans op herstelwerk verderop in het proces.

Voortschrijdend inzicht en nieuwe eisen en wensen kunnen op een beheerste wijze per iteratie worden gespecificeerd. Dit maakt (onvermijdelijke) wijzigingen beter realiseerbaar. Daarnaast brengt deze wijze van requirements-beheer met zich mee dat afwijkingen op de afgesproken omvang per iteratie eenvoudig aan het licht komen. De scope van het project wordt dus beter bewaakt. Meer- of minderwerk is zo aantoonbaar en er kunnen afspraken gemaakt worden over doorlooptijd en budget.

Templates worden gebruikt als invulschema: handig voor iedereen die ermee werkt. De beste ervaringen uit de praktijk worden steeds vastgelegd. Door gebruik te maken van een set vooraf overeengekomen documenten, verbetert de kwaliteit van de softwarespecificaties aanzienlijk.

Tools dragen bij tot het effectiever, efficiënter en flexibeler uitvoeren van activiteiten. Voorbeelden als IBM Rational RequistePro, Borland CaliberRM, Compuware OptimalTrace, Telelogic Doors en Sparx Enterprise Architect ondersteunen zowel de requirements definition als requirements management.

Onder requirements definition wordt verstaan: het initieel opstellen van requirements en softwarespecificaties. Tools ondersteunen het vastleggen van de specificaties en het maken van prototypes en visuele modellen. Daarmee wordt voor toekomstige gebruikers, ontwikkelaars, testers en beheerders snel duidelijk wat een requirement en een specificatie inhoudt. Templates in de tools dwingen af dat bepaalde kenmerken, zoals oorsprong, context, prioriteit, versie, status, relatie met andere requirements en specificaties, worden vastgelegd en gecontroleerd.

Requirements management betekent het beheren en beheersen van de requirements en softwarespecificaties gedurende de levenscyclus van een applicatie. Wijzigingen en toevoegingen aan de bestaande set requirements en specificaties komen vaak voor. Maar welke andere requirements, specificaties en artefacts (bijvoorbeeld testcases) worden door de wijziging beïnvloed? Tools vereenvoudigen het opstellen van een impactanalyse.

Door gebruik te maken van gestandaardiseerde werkplekken (inclusief tools en templates) kunnen de requirements engineers zich concentreren op hun hoofdtaak, zonder de beperkingen van eigenhandig gemaakte hulpmiddelen.

Mensen

Een efficiënt en effectief proces, ondersteund door state-of-the-art-tools is alleen succesvol in combinatie met een team van goed getrainde professionals.

Requirements engineers worden daarom intensief opgeleid, zowel in methoden en technieken als in vaardigheden. Hierop volgt een meester/gezel samenwerking waarbij ervaren specialisten ‘on the job’ hun kennis en ervaring pragmatisch kunnen overdragen. Een uitgebreidere vorm van samenwerking met een leverancier is een joint resourcing afspraak, waarbij de leverancier goed getrainde en ervaren requirements engineers beschikbaar stelt. n


Hans Baaten, consultant en productmanager Atos Origin systems integration