Softwareoverdracht: wat een nieuw team zelf moet kunnen

Een volledige softwareoverdracht hoort te worden beoordeeld op de vraag of een ander team de applicatie kan opzetten, gericht wijzigen en in een testomgeving uitrollen. Broncode is nodig. De zelfstandige poging laat zien of de aanvullende kennis ook is overgedragen.

Voor de opdrachtgever is de praktische vraag hoeveel nog van een bepaalde persoon of computer afhangt. Een beschikbare download beantwoordt dat niet.

Een schone omgeving toont de gaten

In een fictief voorbeeld krijgt het nieuwe team de goedgekeurde versie R-1 van een bestelportaal. Op de oude laptop start alles. Op een schoon testsysteem ontbreken echter de exacte runtimeversie, de inrichting van een lege database en de betekenis van twee omgevingsvariabelen. De code is aangekomen; een deel van de installatie blijft onduidelijk.

Een lang algemeen document kan hetzelfde gat laten bestaan. Nuttig is een handleiding waarmee het team de werkelijk nodige stappen kan volgen. Twelve-Factor-principes scheiden veranderlijke configuratie van code en bevorderen vergelijkbare ontwikkel- en productieomgevingen. Ze geven richting, maar vormen geen volledig overdrachtsverslag voor elke techniek.

Een kleine wijziging als bewijs

In de proef wordt R-1 met vastgelegde afhankelijkheden geïnstalleerd. Het team maakt een lege testdatabase, gebruikt kunstmatige inloggegevens en rondt testorder T-31 af. Productiesleutels horen niet in de repository of handleiding.

Daarna verandert het ‘Referentie’ in ‘Klantreferentie’, bouwt de applicatie opnieuw en rolt deze uit in de testomgeving. Ten slotte zet het de vorige versie terug. Deze kleine ingreep toetst of opbouw, wijziging, uitrol en terugkeer samen worden begrepen. Hij bewijst geen beheersing van elke toekomstige functie.

Moet het vorige team ontbrekende stappen aanleveren, neem die dan in de overdracht op en probeer opnieuw. Een mondelinge uitleg kan het moment oplossen; het gat is pas duurzaam gedicht als de kennis beschikbaar blijft voor de volgende poging.

Wanneer een kleinere omvang volstaat

Bij een beperkte uitbreiding van een al gezamenlijk beheerd platform kan overdracht van de gewijzigde code een nuttige tussenstap zijn. Een geheel nieuwe beheeromgeving maken kan buiten verhouding staan. Dan moet duidelijk zijn welke platformkennis en toegang al aanwezig zijn en wie daarvoor verantwoordelijk blijft.

Testdiensten zijn ook geschikt als echte koppelingen niet gebruikt mogen worden. Leg vast welk deel daardoor niet is getoetst. Een gesimuleerde betaling bewijst geen werkende productiekoppeling.

Voor een volledige teamwissel is de zelfstandige proef de sterkere maatstaf. Die maakt resterend overdrachtswerk zichtbaar voordat de vorige contactpersoon niet meer beschikbaar is. Het acceptatieverslag hoort versie, afgeronde werkstroom en open afhankelijkheden te noemen.

Bronnen

• The Twelve-Factor App: Config

• The Twelve-Factor App: Dev/prod parity