Gå til indholdet

Softwareoverdragelse: hvad et nyt team selv skal kunne

En selvstændig installation og en lille ændring viser, om kode, konfiguration og driftsviden hænger sammen.

Katharina Weber2 min. læsetid
Blå projektmappe med afkrydset mærke og en lille sølvfarvet nøgle.

En fuld softwareoverdragelse bør vurderes på, om et andet team kan sætte applikationen op, lave en målrettet ændring og lægge den i et testmiljø. Kildekoden er nødvendig. Det selvstændige forsøg viser, om den øvrige viden også er overdraget.

For kunden er det praktiske spørgsmål, hvor meget der stadig afhænger af en bestemt person eller computer. En tilgængelig download besvarer det ikke.

Et rent miljø viser hullerne

I et fiktivt eksempel får det nye team den godkendte version R-1 af en bestillingsportal. På den tidligere bærbare starter alt. På et rent testsystem mangler dog den præcise runtimeversion, opsætningen af en tom database og betydningen af to miljøvariabler. Koden er ankommet; noget af opsætningen er stadig uklart.

Et langt generelt dokument kan lade samme hul stå åbent. En nyttig vejledning gør det muligt at følge de trin, der faktisk behøves. Twelve-Factor-principper skiller variabel konfiguration fra kode og anbefaler ensartede udviklings- og produktionsmiljøer. De giver retning, ikke en fuld overdragelsesrapport til enhver teknologi.

En lille ændring som bevis

I forsøget installeres R-1 med fastlagte afhængigheder. Teamet opretter en tom testdatabase, bruger kunstige adgangsoplysninger og gennemfører testordre T-31. Produktionsnøgler hører ikke til i kodearkivet eller vejledningen.

Derefter ændres feltet »Reference« til »Kundereference«, applikationen bygges igen og lægges i testmiljøet. Til sidst gendannes den tidligere version. Det lille indgreb prøver, om opbygning, ændring, udrulning og tilbagerulning er forstået samlet. Det beviser ikke, at alle fremtidige funktioner beherskes.

Må det tidligere team levere manglende trin, skal de indgå i overdragelsen og afprøves igen. En mundtlig forklaring kan løse øjeblikket; hullet er først varigt lukket, når viden er tilgængelig ved næste forsøg.

Hvornår et mindre omfang er nok

Ved en begrænset udvidelse af en platform, der allerede drives sammen, kan aflevering af den ændrede kode være et nyttigt deltrin. Et helt nyt driftsmiljø kan være uforholdsmæssigt. Så skal det være klart, hvilken platformviden og adgang der allerede findes, og hvem der fortsat har ansvaret.

Testtjenester er også rimelige, når rigtige integrationer ikke skal bruges i forsøget. Angiv, hvad der dermed ikke er afprøvet. En simuleret betaling dokumenterer ikke en fungerende produktionsforbindelse.

Ved et fuldt teamskifte er det selvstændige forsøg det stærkere mål. Det gør resterende arbejde synligt, før den tidligere kontakt ikke længere er tilgængelig. Godkendelsen bør nævne versionen, det gennemførte forløb og åbne afhængigheder.

Kilder

Skrevet af

  • Katharina WeberRedaktør for software og teknologiKatharina Weber står for artiklerne om softwareudvikling hos ASES. Hun skriver om de spørgsmål, virksomheder står over for, når de vælger software, udvikler nye applikationer og moderniserer eksisterende systemer.

Følg ASES

Læs videre

Alle artikler

Softwareudvikling med ASES

Skræddersyet software, web- og mobilapps