Achtergrond
Versiebeheer: laaghangend fruit in systeemontwikkeling
7 augustus 2009
Veel organisaties in mechatronicaland kunnen met relatief simpele ingrepen hun systeemontwerp stukken beheersbaarder maken op het gebied van dynamica en performance. Een van de laaghangende vruchten is versiebeheer. Rolf Benschop van Monkeyproof Solutions legt uit hoe de klassieke engineeringdisciplines op dit gebied nog een en ander kunnen oppikken uit de softwareontwikkeling.
Virtualisering van productontwikkeling is een trend die wordt gedreven door kostenoverwegingen en - in deze context belangrijker - de noodzaak het dynamisch gedrag van complexe systemen te analyseren en te beheersen. Modelvorming en simulatie zijn hierin onmisbaar. Engineers uit klassieke disciplines als werktuigbouw, elektrotechniek, meet- en regeltechniek en natuurkunde brengen veel tijd door achter de pc om (deel)ontwerpen in de vorm van modellen, algoritmes, testscenario’s en data te produceren. Ziehier de parallel met software-engineers: iedereen produceert tegenwoordig digitale bestanden.
Maar werktuigbouwers, elektrotechneuten, meet- en regeltechneuten en natuurkundigen zijn geen software-engineers. Hun productiviteit meten we niet in lines of code en hun digitale modellen en algoritmes zien we over het algemeen niet als een product maar ‘slechts’ als een communicatiemiddel of als een analysegereedschap. Ten onrechte, want deze bestanden bevatten intellectueel eigendom dat rechtstreeks tot de corebusiness van organisaties behoort. Bovendien zijn ze het resultaat van vele uren, dagen of langer ploeteren. Reden genoeg om er zorgvuldig mee om te springen.
Buikpijn
Het beheer van simulatiemodellen, algoritmes en analysetools – de ‘software’ van de klassieke engineeringdisciplines – gebeurt veelal ad hoc en is niet of slecht geregeld. Het is al heel wat als er een centraal geback-upte netwerkschijf is met folders waarvan de namen versienummers bevatten. Bij organisaties van uiteenlopend formaat is het meer regel dan uitzondering dat modellen en algoritmes in folders van individuele engineers zijn opgeslagen. Ga dan maar eens zoeken als er iemand vertrekt.
Ter illustratie van het probleem de volgende situaties, die wellicht herkenbaar zijn. Teamleden hebben elkaars werk nodig, maar zijn elke keer weer veel tijd kwijt om uit te zoeken wat de laatste versies van de modellen zijn en om deze onderling te synchroniseren. De voortgang van het ontwerpteam wordt vertraagd doordat niet duidelijk is of een deelontwerp gereviewd en goedgekeurd is. Het ontwerp heeft aanpassingen ondergaan die geen verbetering waren, maar helaas is het origineel overschreven en is het tijdrovend, zo niet onmogelijk, om aan een back-up te komen. Aanpassingen komen pas aan de oppervlakte bij integratietests of nog later. Meerdere teamleden hebben aspecten van een model of algoritme veranderd en het kost veel moeite en tijd om die wijzigingen samen te voegen zonder iets over het hoofd te zien. Modellen, algoritmes en data worden gebruikt als specificatie of vormen een onderdeel van het product, maar bij vragen of problemen is het niet duidelijk welke revisie of variant van deze digitale bestanden een collega, toeleverancier of klant heeft gekregen. Bij het samenvoegen van subdesigns blijft het onzeker of nu daadwerkelijk de juiste versies zijn gebruikt.
Stuk voor stuk situaties om buikpijn van te krijgen. Allemaal zijn ze direct gerelateerd aan de digitale opslag van ontwerpdata waarvan een kopie met een modificatie snel is gemaakt. Er ligt ook een duidelijke link naar collaborative engineering in mechatronica: het werk van de werktuigbouwer, elektrotechneut, meet- en regeltechnicus en natuurkundige moeten we op enig ogenblik kunnen samenvoegen.
Essentieel stuk infrastructuur
Geconfronteerd met deze problemen heeft de software-engineeringwereld tools gecreëerd die softwareontwikkeling in teamverband gecontroleerd laten verlopen en traceerbaar maken en die bovendien de mogelijkheid bieden om eenvoudig terug te keren naar een eerdere versie. Daarnaast is het heel normaal dat verschillende sites verschillende klantspecifieke versies (of configuraties) van de geproduceerde software gebruiken. Deze verschillende versies moeten tegelijkertijd worden onderhouden. Denk aan bugs die in de ene versie wel zitten en in de andere niet. Maar denk ook aan een versie A die moet worden onderhouden, maar waar geen nieuwe functionaliteit aan wordt toegevoegd terwijl de nieuwe functionaliteit in een versie B wordt ontwikkeld. Reparaties aan versie A moeten uiteraard ook – en liefst automatisch – worden toegepast in versie B. Hier ligt een duidelijke analogie met de multidisciplinaire ontwikkeling van mechatronica, het onderhoud aan machines en verlenging van de levensduur van een systeem door middel van upgrades.
Versiebeheersoftware voorziet in back-up en restore: de historie van bestanden wordt opgeslagen en een bestand van een willekeurig tijdstip is gemakkelijk terug te halen. De synchronisatiefunctionaliteit maakt het eenvoudig om bestanden te delen met anderen en om up-to-date te blijven met de laatste versie. Ook houdt de software van elke wijziging bij wie deze heeft gedaan, hoe en waarom. Dit maakt het eenvoudig om de evolutie van files te bekijken. Voor het identificeren en documenteren van wijzigingen wordt differencing tooling gebruikt, die twee versies van een bestand vergelijkt. Verder kopieert de programmatuur een complete set bestanden lokaal, waardoor veranderingen lokaal zijn te testen voordat ze definitief worden doorgevoerd. Ten slotte zijn (sub)sets van bestanden, steeds onder versiebeheer, af te splitsen (branching) om veranderingen geďsoleerd van het origineel door te kunnen voeren, waarna de kopie op een later tijdstip weer kan worden samengevoegd met het origineel (merging). Dit maakt parallelle ontwikkeling mogelijk, maar vergemakkelijkt ook het hergebruik van componenten en het onderhoud van varianten van dezelfde component.
In gewone mensentaal betekent dit dat er een centrale plaats is waar alle versies van alle bestanden liggen opgeslagen. Elke engineer kan altijd en eenvoudig een snapshot van projectgerelateerde bestanden pakken om zijn componenten te ontwikkelen en te testen. Er is geen onduidelijkheid meer over wie wat wanneer in welke versie heeft gewijzigd. Als we de discipline kunnen opbrengen om veranderingen te documenteren, kunnen we eenvoudig inzicht krijgen in de evolutie van bestanden. De centrale opslag en het eigendomsbeheer faciliteren hergebruik en maken het mogelijk onderscheid aan te brengen tussen eigenaar en gebruiker van bestanden. De conclusie mag zijn dat versiebeheer een essentieel stuk infrastructuur is – niet alleen voor software-engineers, maar met de virtualisering van ontwerpen ook voor de klassieke engineeringdisciplines.
Niet eng
Het goede nieuws voor deze klassieke disciplines is dat de meeste leveranciers van softwaretools voor engineering interfaces voor versiebeheer en daaraan gerelateerde functionaliteit inbouwen in hun producten. Helaas stopt de ondersteuning voor versiebeheer daar en moet de eindgebruiker het verder zelf uitzoeken. Zonde, want daarmee blijft de modelgebaseerde aanpak die de leveranciers voorstaan te vaak een theoretisch marketingverhaal dat de praktijk niet haalt. Engineeringtools die bewezen de potentie hebben om ontwerpprocessen te faciliteren en te automatiseren, blijven bijgevolg hangen in de sfeer van een tool(tje) voor de individuele engineer. Een uitzondering vormt de Cad/Cam-hoek, met een aanpak als Product Lifecycle Management (PLM). Versiebeheer is veel minder verstrekkend, maar het is wel een belangrijke pijler van PLM.
Waarschijnlijk de snelste en eenvoudigste manier om aan de slag te gaan met versiebeheer is om te gaan praten met de softwaremensen binnen de organisatie. Dikke kans dat bestaande systemen en tools zijn te gebruiken. Een van de basisbenodigdheden is in ieder geval een (servergebaseerd) versiebeheersysteem, commercieel dan wel opensource. Subversion is waarschijnlijk het meest verbreid. Indien gewenst is dit opensource pakket ook commercieel verkrijgbaar of als software as a service (Saas). Verder is een versiebeheerclient belangrijk, aangezien de gebruiker een tool nodig heeft om te communiceren met het versiebeheersysteem. Een dergelijke client is wel versiebeheersysteemgebonden.
Een deel van de engineeringtools produceert bestanden die zijn bedoeld voor grafisch presentatie. Denk aan gereedschappen waarin gebruikers modelleren of programmeren met blokschema’s. De standaard differencing- en merge-functionaliteit in versiebeheerprogramma’s is tekstgebaseerd en daardoor niet geschikt om grafisch verschillen te inspecteren en grafisch verschillende versies samen te voegen. Gelukkig zijn er aanvullende tools beschikbaar die geďntegreerd met het versiebeheersysteem deze functionaliteit wel bieden.
Het beheer van modellen krijgt vaak geen aandacht. Het kost vaak onnodig en een beetje verstopt heel veel tijd en geld. Versiebeheer is niet eng en het zit op geen enkele manier de creativiteit van R&D-engineers in de weg. Zelfs voor eenmansprojecten heeft het enorme toegevoegde waarde. Bestanden zijn altijd terug te vinden en het is altijd mogelijk om terug te keren naar een vorige, werkende versie. Wie wil dat nu niet? Er valt in deze context meer te leren van software-engineering. Denk aan de volgende stappen na versiebeheer: configuratiemanagement, gebruik van tooling voor issue tracking of bijvoorbeeld gebruik van style guides.
Rolf Benschop is directeur van toolspecialist Monkeyproof Solutions uit Nieuwe-Tonge.
