Bestaande software & audits

Een bestaande codebase overnemen: eerst begrijpen wat moet blijven werken

Bereid softwareovername voor met bedrijfsroutes, accountbezit, reproduceerbaar bouwen, dataverantwoordelijkheid en een begrensde eerste wijziging.

Op deze pagina

Een repository ontvangen is nog geen softwareovername. De organisatie moet ook weten hoe de applicatie wordt gepubliceerd, wie toegang beheert en welke dagelijkse werkzaamheden ervan afhangen. De eerste opdracht is daarom meestal het opbouwen van een controleerbare uitgangssituatie. Een moderniseringsplan kan daaruit volgen, maar hoeft niet op de eerste dag vast te staan.

Deze gids gaat over een beheerste technische overdracht. De voorbeelden zijn fictief. Ze helpen een gesprek met de huidige leverancier en toekomstige beheerder voorbereiden, zonder te suggereren dat ieder oud systeem onveilig is of dat een nieuwe ontwikkelaar onmiddellijk alle verantwoordelijkheid kan dragen.

Leg de werkelijke bedrijfsroutes vast

Vraag medewerkers een normale werkdag te laten zien. Hoe komt een aanvraag binnen, wie wijzigt de status en wanneer ontstaat een factuur of externe melding? Noteer ook handelingen die buiten de applicatie plaatsvinden. Een spreadsheet met correcties kan een belangrijk onderdeel van het proces zijn, terwijl die nergens in de repository voorkomt. Zo ontstaat een kaart van het werk dat behouden moet blijven.

Kies vervolgens enkele routes die bij uitval direct gevolgen hebben. Beschrijf voor iedere route invoer, verwachte uitvoer, verantwoordelijke en controlebewijs. Gebruik geanonimiseerde of speciaal gemaakte voorbeelden. Een schermafbeelding bewijst hoe iets eruitziet, maar niet welke gegevens achter de schermen wijzigen. Vraag daarom welke records en berichten bij de handeling horen.

Verbind de repository met de draaiende omgeving

Laat vaststellen welke codeversie daadwerkelijk draait. Een map met de naam productie kan verouderd zijn; een lokaal werkende versie kan nog niet gepubliceerde wijzigingen bevatten. Leg commit of versie, configuratiebron en publicatiemethode naast elkaar. Onverklaarde verschillen zijn onderzoekspunten, geen reden om direct de server te vervangen.

Maak een inventaris van domeinen, hosting, databases, opslag, e-mail, geplande taken en externe koppelingen. Noteer per onderdeel de eigenaar en relatie met de applicatie. Een vergeten taak kan iedere nacht gegevens aanpassen zonder zichtbare gebruikersactie. Vraag daarom naar achtergrondwerk en leveranciersportalen, niet uitsluitend naar de webserver. Beperk de eerste inventaris tot wat nodig is om de gekozen bedrijfsroutes te verklaren.

Regel toegang via herkenbare eigenaren

Onderscheid toegang voor onderzoek van toegang om productie te wijzigen. Voor veel eerste controles volstaan leesrechten of een geïsoleerde kopie. Spreek expliciet af wie een uitbreiding van rechten goedkeurt en hoe tijdelijke toegang eindigt. Laat bestaande beheerders niet zomaar verdwijnen voordat is aangetoond dat de nieuwe organisatie kan publiceren en herstellen.

Accountbezit is ook een continuïteitsvraag. Een domein op een persoonlijk account van een voormalige medewerker vraagt een andere overdracht dan een bedrijfsaccount met meerdere beheerders. Verzamel geen wachtwoorden in een rapport. Leg vast waar toegangen veilig worden beheerd, wie ze kan herstellen en welke accounts later moeten worden vervangen. Rechten controleren vraagt concrete tests; alleen een lijst met accountnamen is daarvoor onvoldoende.

Gebruik de eerste inventarisatie om het vervolgonderzoek af te bakenen: Een software-audit afbakenen: welke beslissing moet het onderzoek ondersteunen?.

OWASP Application Security Verification Standard ↗

Maak een schone bouw en testomgeving mogelijk

Vraag een nieuwe ontwikkelaar de applicatie volgens de beschikbare instructies te bouwen. Noteer ontbrekende afhankelijkheden, configuratie en handmatige stappen. Het doel is geen wedstrijd in snelheid, maar ontdekken welke kennis uitsluitend bij één persoon zit. Bewaar foutmeldingen en oplossingen zodat een tweede poging herhaalbaar wordt.

Een bruikbare testomgeving heeft herkenbare voorbeeldgegevens en veroorzaakt geen echte facturen, berichten of betalingen. Controleer daarom ook achtergrondtaken en externe aansluitingen. Een andere database alleen maakt een omgeving niet automatisch geïsoleerd. Laat aantonen dat de gekozen voorbeeldroute veilig kan worden uitgevoerd en dat het resultaat zichtbaar te controleren is. Als dit nog niet lukt, hoort dat als expliciete beperking bij de overdracht.

Onderzoek de betekenis van belangrijke gegevens

Vraag wie kan uitleggen wat statussen, datums en identifiers betekenen. Twee velden met vergelijkbare namen kunnen verschillende gebeurtenissen vastleggen. Een datum kan de oorspronkelijke invoer, laatste wijziging of zakelijke ingangsdatum voorstellen. Een nieuwe ontwikkelaar die dat verschil mist kan technisch correcte code schrijven die de bedrijfsvoering verstoort.

Werk één record van invoer tot rapportage uit. Noteer welke koppelingen het record gebruiken en welke correcties medewerkers achteraf uitvoeren. Controleer ook bewaarbehoeften en de bruikbaarheid van exports. Dit is nog geen volledige datamigratie. Het is een gerichte inventaris van de betekenis die bij toekomstige wijzigingen behouden moet blijven. Een kleine steekproef toont bovendien niet dat de volledige historische dataset dezelfde kwaliteit heeft.

Lees de code vanuit een concrete onderzoeksvraag

Een eerste codeverkenning kan zich richten op authenticatie, foutafhandeling of de route die een order verwerkt. Benoem welke onderdelen daadwerkelijk zijn bekeken en welke nog niet. De aanwezigheid van een oud framework is een aanwijzing om onderhoud en ondersteuning te onderzoeken, geen zelfstandig bewijs dat alle functionaliteit moet worden herschreven.

Koppel bevindingen aan de gekozen bedrijfsroutes. Een onduidelijke module is relevant wanneer die wijzigingen vertraagt of fouten moeilijk verklaarbaar maakt. Een afhankelijkheid zonder eigenaar kan relevant zijn voor updates. Houd aangetoonde fouten, waarschijnlijke risico’s en ontbrekende informatie afzonderlijk zichtbaar. Daarmee kan de opdrachtgever beslissen wat eerst onderzocht of aangepast moet worden zonder een algemeen oordeel over de hele codebase te overschatten.

Kies een eerste wijziging met een terugweg

Begin niet automatisch met de grootste achterstand. Een kleine, afgebakende verbetering kan aantonen dat de nieuwe beheerder begrijpt hoe ontwikkeling, controle en publicatie samenhangen. Kies bijvoorbeeld een duidelijk foutbericht bij een ontbrekende referentie, mits de relevante route voldoende begrepen en getest is.

Leg vooraf vast hoe het bestaande gedrag wordt gecontroleerd, wie de wijziging beoordeelt en hoe een ongewenst effect wordt teruggedraaid. Een terugkeer naar oude code herstelt niet vanzelf al gewijzigde gegevens. Benoem daarom of de wijziging data schrijft en wat daarvoor de herstelroute is. Als de eerste wijziging onverwachte afhankelijkheden laat zien, pas dan de vervolgscope aan in plaats van de oorspronkelijke schatting als belofte te blijven behandelen.

Google SRE: Testing for Reliability ↗

Voorbeeld: een planningsapplicatie overdragen

Fictief voorbeeld: een dienstverlener neemt een planningsapplicatie over nadat de oorspronkelijke ontwikkelaar stopt. De repository bevat de website, maar de nachtelijke import staat op een afzonderlijke server. Tijdens de inventaris blijkt dat medewerkers ontbrekende opdrachten iedere ochtend handmatig aanvullen. Die werkwijze staat niet in de technische documentatie.

De eerste opdracht wordt daarom het verklaren van één importcyclus, het veilig testen met voorbeeldbestanden en het vastleggen van accountbezit. Pas daarna volgt een voorstel voor verbeterde foutmeldingen. Het opgeleverde bewijs bestaat uit een traceerbare voorbeeldopdracht, een herhaalbare bouw, een verantwoordelijke voor de import en open vragen over historische fouten. Dat is bruikbare vooruitgang zonder meteen een volledige vervanging te verkopen.

Vraag om bewijs dat een ander kan gebruiken

Een bruikbare overdracht bevat niet alleen uitleg maar ook een uitvoerbare route. Laat een tweede persoon de instructies volgen voor een afgesproken handeling, zoals een testversie publiceren of een fout opzoeken. Noteer waar begeleiding nodig was. Dat maakt overdracht toetsbaar zonder te eisen dat alle kennis in één document past.

Sluit af met een lijst van wat is ontvangen, wat is aangetoond en wat nog ontbreekt. Verbind ieder open punt aan een eigenaar en mogelijke vervolgstap. Maak onderscheid tussen direct beheer kunnen voeren en alle toekomstige wijzigingen kunnen overzien. Die tweede zekerheid ontstaat niet door één overdrachtsmoment. Wel kan de organisatie zorgen dat nieuwe kennis, wijzigingen en incidenten vanaf nu op een herhaalbare manier worden vastgelegd.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

Open de voorbereidingstool ↗

Vragen over dit onderwerp

Moet oude software altijd worden vervangen?

Nee. Onderzoek eerst bruikbaarheid, onderhoudbaarheid en de concrete grenzen. Behouden, gericht verbeteren of gedeeltelijk vervangen kunnen passende uitkomsten zijn. Een oude technieknaam alleen beslist dat niet.

Hoe lang duurt een overname?

Dat hangt af van toegang, documentatie, complexiteit en de gewenste verantwoordelijkheid. Spreek eerst een begrensde inventaris af en herzie de planning op basis van het gevonden bewijs.

Is repositorytoegang voldoende?

Nee. Ook configuratie, publicatie, gegevens, domeinen, externe diensten en herstel moeten verklaard kunnen worden. Beperk de benodigde toegang tot de afgesproken onderzoeks- en beheertaken.

Verder met een aansluitende vraag

Bronnen en technische achtergrond

Bespreek je project met Ricardo ↗