Hvordan kan man spare 80% af omkostningerne på udvikling?

Hvordan kan man spare 80% af omkostningerne på udvikling?

Hvordan kommer man hurtigst i mål med at lave robust software? Hos GPower er genbrugelighed nøgleordet, men som med så mange andre ting skal det gøres med omtanke.

Det offentlige rum er fyldt med eksempler på for dyr og forsinket software. Man kunne liste en masse eksempler, men det rækker vist at bemærke, at fordyrelser i 100-mio.-klassen er velkendte inden for offentlige IT-systemer (Klik her for mere information). Der er naturligvis en række af omstændigheder, der gør, at softwareudvikling bliver en dyr affære, men hvor kan man sætte ind, hvis man vil gøre det hurtigere og billigere?

Genanvendelse

Hvis man kigger på selve udviklingsfasen, så er der en ting, der kan gøre projektet hurtigere og billigere: Genbrug. Hvis man er i stand til at genanvende kode fra tidligere projekter, er der store besparelser at vinde. Mange af de tidskrævende opgaver ligger i at udvikle kodeblokke, der er meget generiske – og ikke er unikke for det enkelte projekt. Hvis disse dele kan udvikles på forhånd, reduceres udviklingsarbejdet markant. Faktisk viser vores erfaring, at op mod 80% af kodebasen til et projekt kan etableres på forhånd, så der er ganske store gevinster på spil.

For at kunne høste disse besparelser kræver det en meget struktureret tilgang til genanvendelse. Hvis ens tilgang er den klassiske ”cut and paste”, så er der store farer gemt i genanvendelse. Det kræver et dybdegående kendskab til den oprindelige kode, så man er helt klar over kodens formål og de begrænsninger, den måtte have.

Modulær software

Derudover er det vigtigt at indkapsle koden effektivt. For hvis koden skal bruges flere gange, vil der helt sikkert komme ændringer i den. Derfor bør al kode ligge i velafgrænsede moduler, så der er klare interfaces, og de bør generelt designes efter SOLID-principperne. I det hele taget bør koden ikke ses som ”et flagrende stykke kode”, men som et værktøj. Og som med alt andet værktøj er det værd at bruge tid på at lave det ordentligt, så det holder og kan bruges i mange situationer.

Når vi snakker om op til 80% besparelse, så begrænser det sig naturligvis ikke kun til udviklingsfasen. Hvis 80% af koden kan genbruges giver det selvfølgelig tilsvarende besparelse i testfasen, hvis koden er lavet modulært. Designfasen kan også gennemføres væsentligt hurtigere, hvis man har et godt overblik over sine værktøjer. For ikke at tale om vedligehold: Alt, hvad der sker efter endt udvikling, gavnes også af genanvendelse, da byggeblokkene når at køre i mange flere timer, så koden er gennemtestet i langt højere grad. Og da vedligehold er en fortløbende opgave, er der massive besparelser at vinde i det lange løb.

Book et uforpligtende møde

Lyder det interessant i forhold til jeres forretning? Lige nu har du muligheden for at booke et helt uforpligtende møde med os! Ring eller skriv til os: +45 51 90 57 90 eller gpower@gpower.io.

Fem ting, du bør gøre, når du opgraderer TestStand

Fem ting, du bør gøre, når du opgraderer TestStand

Hvad gør man, når ens testsystem kører på en gammel version af TestStand, og man ikke er helt tryg ved bare at overføre koden til den nyeste udgave af TestStand? Her er der fem råd til at få opgraderet dit testsystem.

Skal man ændre på et testsystem, hvis det ikke er i stykker? De fleste vil nok svare nej, og derfor får teststationer tit lov til at køre i mange år, uden at der bliver rørt ved det. For det fungerer jo – for det meste. Men der kommer et tidspunkt, hvor opgradering af systemet ikke kan udskydes længere pga. eksempelvis udefrakommende krav, kompatibilitetsproblemer eller internt pres.

Systemet er blevet hægtet af udviklingen, og der er sikkert adskillige versioner op til den nyeste udgave af TestStand. Det kan være fristende bare lige at skrue en version op, så man holder skuden flydende, men den mest fremtidssikrede løsning er at opgradere til den nyeste version af TestStand.

Det kan godt virke som en uoverskuelig opgave, og man kan frygte, at testsystemet ikke længere fungerer i den nye version af TestStand. Den gode nyhed er til gengæld, at i 99% af tilfældene vil der ikke være nogen fejl. Den gamle software er helt kompatibel med f.eks. TS2019, og man kunne bare flytte sine sekvenser og kodemoduler direkte over i det nye udviklingsmiljø (medmindre du arbejder i TS 4.2.1 eller ældre, så skal du manuelt migrere dine sekvenser og konfigurationsfiler mm. (se her). Det ville til gengæld bare lade de latente problemer i koden være, og man ville ikke få nogen reel gavn af at opgradere TestStand. Derfor kommer her en håndfuld gode råd til at få mest muligt ud af at opgradere TestStand:

  1. Undersøg nye features

    Før du begynder på opgraderingen, så afsæt noget tid til at gennemgå, hvilke features, der er kommet til. Kig dokumentationen igennem på NI’s hjemmeside og kig gerne på nogle af de eksempler, der bliver udgivet af NI’s application engineers. Måske er der blevet implementeret nogle features, der løser nogle af udfordringer, som du selv har bøvlet med – og måske kun fundet en halv løsning til.

  2. Brug ikke gammel kode ukritisk

    Sørg for at have helt styr på, hvad du genbruger, og hvorfor du kan genbruge det. I udgangspunktet kan du ikke genbruge det, før det modsatte er bevist. Er koden lavet efter best practices? Dette er jo et begreb som også kan have ændret sig, siden koden oprindeligt blev lavet.

  3. Få betalt den ”tekniske gæld”

    Benyt lejligheden til at få ryddet op i det, der igennem tiden lige var den nemmeste løsning til at få noget til at virke i en fart. Her er man typisk sprunget over nogle meget lave gærder, og dermed måske kun fået løst et problem halvt. Mange af disse handlinger vil over tid summere til en stor mængde af det, vi kalder for teknisk gæld.

  4. Undersøg jeres egen proces

    Hvordan fungerer tingene i praksis? Er det en optimal proces? Ville vi måske i virkeligheden hellere gøre det anderledes? Ofte kan et af de største problemer være kulturen i firmaet og at overkomme ”sådan-plejer-vi-at-gøre-det”-paradigmet.

  5. Involvér de folk, der skal bruge systemet

    Det er også vigtigt ikke kun at involvere testudviklerne i opgraderingen, men også operatører og andre folk, der bruger systemet til hverdag. Måske er der nogle af de nye features, som løser de irritationsmomenter, de lever med i deres arbejdsdag.

Alt i alt så se det som et serviceeftersyn. For hånden på hjertet; hvornår får du igen lejlighed til at få lavet om på systemet? Udnyt chancen til at komme på forkant igen, så opgaven ikke bliver endnu sværere om yderligere et par år.

Skulle du stå med uafklarede spørgsmål, så tøv ikke med at kontakte os. Vi har erfaring med alle dele af processen: Opkvalificering af medarbejdere til nyeste version af TestStand, review af kode og best practices i udvikling og vedligehold af kode.