Neem contact met ons op
+31 (0) 88 000 54 00
info@divetro.nl
Volg ons op LinkedIn
DiVetro BV
Villa de Reehorst
Hoofdstraat 20A
3972 LA Driebergen-Rijsenburg
The Netherlands

Welke versiebeheertool gebruikt u als analist?

Ronald Koenis

Het werken in een agile omgeving geeft vaak een uitdaging voor analisten: hoe houdt u de requirements, specificaties en beheerdocumentatie in lijn met de snel opeenvolgende releases van software?

In een voorgaand artikel stonden we stil bij het inzichtelijk maken van wijzigingen binnen analyseproducten. In dit artikel kijken we een niveau hoger: hoe kunt u de volledige set van aan elkaar gerelateerde analyseproducten relateren aan een specifieke versie van opgeleverde software?

Het Agile Manifesto kent meer waarde toe aan werkende software dan aan documentatie. Maar dat ontslaat de analist niet van de plicht om die documentatie goed bij te houden. Alleen dan is duidelijk wat de werkende software had moeten doen.

Veel analysetools hebben een eigen versiebeheersysteem waarmee van de analyseproducten een oplevering gemaakt kan worden. Maar er ontstaat dan wel een schaduwboekhouding om die interne versies te kunnen koppelen aan de opgeleverde software.

En wat moet u doen als uw analysetool geen eigen versiebeheer heeft? Kunt u dan best aansluiten bij de programmeurs en gebruik maken van populaire versiebeheertools zoals Subversion en GIT die alles aankunnen? Wij zien een aantal mogelijkheden om uw versiebeheer voor analyse in te richten.

welke-versiebeheertool-gebruikt-u

1.      Werken zonder versiebeheertool

Er is een analistenleven zonder versiebeheertools mogelijk. In een snel veranderende omgeving kost het dan wel veel moeite om het overzicht te houden.

Word diff geeft wel inzicht in de verschillen met een oudere versie van een specifiek onderdeel van uw documentatie maar deze functie is veel te gedetailleerd en het gebruik ervan is tijdsintensief. Daarnaast zijn wij ook geïnteresseerd in de complete oplevering en dus de samenhang tussen de specifieke onderdelen.

Omdat u niet vanzelf terug kunt naar een eerder opgeleverde versie van de documentatie loopt u een groter risico op verlies van uw bereikte resultaten. Zodra een applicatie groter wordt of de organisatie professioneler is een versiebeheertool noodzakelijk.

2.      Requirements in een versiebeheertool

Algemene versiebeheertools helpen de analist om orde in de chaos te scheppen. CVS, Subversion en GIT zijn veel gebruikte tools. Naast verschillen en versies op documentniveau is het ook mogelijk om een baseline, branch of tag te maken. Er zijn echter belangrijke verschillen tussen deze tools. En deze verschillen komen (pas) naar voren wanneer je met meerdere analisten aan dezelfde set van requirements werkt.

Zo werken sommige tools met een lock-mechanisme. De eerste analist claimt dan exclusieve aanpassingsrechten en geeft de lock pas weer vrij wanneer hij klaar is. Andere tools staan toe dat analisten gelijktijdig aan dezelfde producten werken, waarna de laatste analist de verantwoordelijkheid heeft om alle wijzigingen samen te voegen tot één consistent geheel.

Samenvoegen (mergen) van broncode kan vaak automatisch gedaan worden en is daarmee relatief eenvoudig. Het samenvoegen van opgemaakte documentatie is echter een ander verhaal. Voor grafische modellen is het al helemaal niet te doen, uitzonderingen (ze bestaan) daar gelaten.

Hierbij moet de analist ook controleren wat zijn requirement tool zelf doet. Tools zoals Enterprise Architect bijvoorbeeld wijzigen een aantal van de onderliggende bestanden al wanneer ze simpelweg geraadpleegd worden. Zo ontstaan veel verschillende versies op bestandsniveau terwijl er functioneel niets wezenlijks wijzigt.

3.      Versiebeheer in een requirement tool

Diverse requirement tools kunnen ook zelf voor versiebeheer zorgen. Deze functie zorgt ervoor dat meerdere analisten aan dezelfde requirements en modellen binnen de tool kunnen werken.

Afhankelijk van de tool kunt u met baselines en centrale repositories werken. De recovery is ook vaak goed geregeld. Maar let ook hier goed op want soms houdt recovery in dat uw hele model terug moet naar een oude versie. Daarmee is niet iedereen geholpen.

Daarnaast bent u veroordeeld tot het bijhouden van een schaduwboekhouding om uw versie te koppelen aan de opleveringen (sourcecode, testscripts, etc.) van de andere projectleden.

4.      Geïntegreerd versiebeheer

Als u 1 plus 1 optelt dan komt u al snel uit op tools die met versiebeheertools integreren. Zo heeft DiVetro goede ervaringen met het onderbrengen van analyseproducten waaronder Enterprise Architect modellen in Subversion.

Het grote voordeel van deze configuratie boven de standaard “DBMS” oplossing, is dat specifieke versies op bestandsniveau kunnen worden teruggezet of opgeleverd. Dankzij deze configuratie kan een heel team van analisten van DiVetro bijvoorbeeld het beheer van de BurgerzakenModules verzorgen.

Hoe kiest u de beste oplossing voor uw versiebeheer?

Bij de keuze tussen een geïntegreerde versiebeheertool of losse versiebeheertools gaat het om de volgende afwegingen:

  • Is het belangrijk om de requirements van een specifieke oplevering te hebben?
  • Wilt u met meerdere teamleden aan hetzelfde model gaan werken?
  • Zijn er naast de leden van uw team nog andere teams die bij uw requirements willen aansluiten (hergebruik van functionaliteiten)?
  • Wilt u zelf bepaalde requirements van andere teams hergebruiken?
  • Hoe is versiebeheer geregeld binnen de andere disciplines?
  • Is het reëel dat u soms zaken terug moet draaien?

De specificaties laten aansluiten op een specifieke versie van de applicatie is voor een analist niet altijd eenvoudig. Hij moet beoordelen wat zijn tools kunnen en nadenken over de aansluiting met versiebeheer van de software. Zijn er voordelen te behalen in het meegaan met dat versiebeheer en moet hij dan all the way gaan of houdt hij het simpel?

Worstelt u ook met de impact van agile op uw werkmethoden en zoekt u advies of hulp van analisten met ervaring? Wij delen graag onze ervaringen. Neem hier contact met ons op. Wij helpen u graag verder.

Blijf op de hoogte

Vond u dit artikel interessant? Via de knoppen hieronder kunt u het artikel eenvoudig met uw netwerk delen.

Lees hier onze overige publicaties en schrijf u hieronder in voor onze nieuwsbrief. Zo ontvangt u elke maand automatisch een overzicht van onze recente publicaties in uw mailbox.

DiVetro Team - Ronald Koenis

Ronald Koenis is een senior analist die meer dan 25 jaar in het IT vak zit. Zijn brede ervaring heeft hij in diverse rollen opgedaan. Hij was onder meer informatie analist bij Albert Heijn, projectleider bij gemeente Almere en is momenteel product owner en information engineer bij het Kadaster. Hij is in staat complexe IT oplossingen zo weer te geven dat die voor de business te begrijpen is en tegelijkertijd voldoende specifiek is, zodat IT er mee aan de slag kan.

Hoe kunnen wij u helpen?

Villa de Reehorst
Hoofdstraat 20A
3972 LA Driebergen-Rijsenburg
Nederland

Stuur ons een bericht

  • Wij behandelen uw gegevens vertrouwelijk en vragen graag uw toestemming om u via e-mail informatie te bezorgen. Lees hier ons privacybeleid.