Harsh Joshi
Co-founder & Technical Director
Vedligeholdelse af applikationer omfatter langt mere end blot fejlrettelser. Se de otte områder, der indgår i et komplet omfang, hvad der normalt ligger uden for dette, og hvordan serviceniveauer og omkostningsfaktorer er med til at bestemme, hvad du får.
Vedligeholdelse af applikationer omfatter det arbejde, der er nødvendigt for at sikre, at softwaren forbliver sikker, pålidelig, kompatibel og brugbar efter lanceringen. Det omfatter fejlrettelser, sikkerhedsopdateringer, opdateringer af afhængigheder, ydeevneforbedringer, vedligeholdelse af integrationer, overvågning og mindre forbedringer.
For virksomheder, der er afhængige af skræddersyede applikationer, er vedligeholdelse en løbende teknisk opgave. Uden vedligeholdelse kan softwaren blive sårbar over for sikkerhedstrusler, uforenelig med nyere platforme, langsommere i takt med at datamængden vokser eller dyrere at ændre. Derfor omfatter Monarch Innovations softwareudviklingsydelser struktureret support efter lanceringen – ikke blot udviklingen.
At vide, at et program kræver vedligeholdelse, er dog kun udgangspunktet. Virksomhederne skal også forstå, hvad vedligeholdelsen omfatter, hvilke aktiviteter der falder uden for dens anvendelsesområde, og hvad de kan forvente af en vedligeholdelsesaftale.
Denne vejledning beskriver omfang, typer, serviceniveauer, omkostninger og planlægningsmæssige overvejelser, som CTO’er, IT-ledere og produktejere bør have kendskab til, inden de vælger en tilgang til vedligeholdelse af applikationer.
Hvad omfatter vedligeholdelse af applikationer?
Vedligeholdelse af applikationer omfatter typisk otte kerneaktiviteter: fejlretning, sikkerhedsopdateringer, opdatering af afhængigheder, vedligeholdelse af integrationer, ydeevneoptimering, overvågning, mindre forbedringer og opdatering af dokumentation.
Hver aktivitet tager fat på en anden risiko, der kan opstå i takt med, at softwaren udvikler sig.
- Fejlrettelser og afhjælpning af fejl: Identificere og afhjælpe fejl, der påvirker applikationens funktionalitet, datanøjagtigheden eller brugeroplevelsen.
- Sikkerhedsopdateringer: Afhjælp kendte sårbarheder i applikationskode, rammeværker, biblioteker og kørselsmiljøer.
- Afhængigheds- og platformopdateringer: Opdater softwarekomponenter og tilpas applikationer til ændringer i operativsystemer, browsere, mobile platforme og cloudtjenester.
- Vedligeholdelse af integrationer: Sørg for, at forbindelserne til ERP-systemer, CRM-platforme, betalingsgateways og tredjeparts-API’er fortsat fungerer, selv når disse systemer ændres.
- Ydelsesoptimering: Undersøg langsomme databaseforespørgsler, hukommelseslækager og flaskehalse, der opstår i takt med stigende brug og datamængder.
- Overvågning og håndtering af hændelser: Overvåg applikationers tilgængelighed, fejl og responstider, og undersøg derefter alarmer og serviceforstyrrelser.
- Mindre forbedringer: Foretag små, klart definerede forbedringer, f.eks. at tilføje et rapportfilter, finjustere en arbejdsgang eller forbedre en fejlmeddelelse.
- Opdatering af dokumentation: Vedligeholdelse af teknisk dokumentation, installationsvejledninger, driftsmanualer og ændringsprotokoller, så fremtidigt vedligeholdelsesarbejde kan udføres på en sikker måde.
Tænk på en app til feltarbejde, der bruges af hundredvis af teknikere. En ny Android-version ændrer tilladelserne vedrørende placering, en betalingsudbyder udfases en API-version, og et rapporteringsdashboard bliver langsommere, efterhånden som opgaveregistreringerne hober sig op.
Disse problemer kræver forskellige tekniske løsninger, men de kan alle falde inden for rammerne af vedligeholdelse af applikationer. Målet er at sikre, at den eksisterende applikation forbliver funktionsdygtig, sikker og pålidelig, selvom dens driftsmiljø ændrer sig.
Hvad er de fire hovedtyper af applikationsvedligeholdelse?
De fire almindeligt anerkendte typer af softwarevedligeholdelse er korrektiv, adaptiv, perfektiv og forebyggende vedligeholdelse. Hver af disse typer tager højde for en anden årsag til at ændre softwaren efter udgivelsen.
| Type | Formål | Eksempel |
|---|---|---|
| Forebyggende vedligeholdelse | Afhjælp en eksisterende fejl | Løs en betalingsfejl, der afviser gyldige betalinger |
| Adaptiv vedligeholdelse | Tilpas softwaren til ændringer i omgivelserne | Opdater en applikation til et nyt operativsystem eller en ny API-version |
| Perfekt vedligeholdelse | Forbedre funktionaliteten, brugervenligheden eller ydeevnen | Optimer et langsomt dashboard eller forenkle en formular |
| Forebyggende vedligeholdelse | Mindsk risikoen for fremtidige fejl | Omstrukturér ustabil kode, forbedr testdækningen eller fjern forældede afhængigheder |
Disse kategorier er i overensstemmelse med den etablerede terminologi inden for softwarevedligeholdelse, herunder ISO/IEC/IEEE 14764:2022, den internationale standard for softwarevedligeholdelse.
Nogle vedligeholdelsesrammer omhandler også additiv vedligeholdelse, som går ud på at tilføje nye funktioner til software, der allerede er i brug. Den nøjagtige klassificering, der anvendes, kan afhænge af den ramme eller standard, der følges.
En afbalanceret vedligeholdelsesplan omfatter mere end blot produktionsfejl. Korrigerende indsatser genopretter funktionaliteten, mens tilpasnings- og forebyggende tiltag bidrager til at mindske fremtidige afbrydelser. Forbedrende indsatser sikrer, at applikationen fortsat er tilpasset de skiftende bruger- og forretningsbehov.
Vedligeholdelse af applikationer kontra applikationssupport
Vedligeholdelse af applikationer fokuserer på at ændre og forbedre software. Applikationssupport fokuserer på at hjælpe brugerne, undersøge driftsproblemer og sikre, at den daglige brug af applikationerne forløber problemfrit.
Selvom aktiviteterne overlapper hinanden, er denne skelnen vigtig, når man fastlægger ansvarsfordelingen i en serviceaftale.
Applikationssupport er normalt opdelt i tre niveauer:
- Niveau 1 (L1): Håndterer grundlæggende brugerhenvendelser, nulstilling af adgangskoder, anmodninger om vejledning og indberetning af indledende supportanmeldelser.
- Niveau 2 (L2): Undersøger problemer med applikationer, gennemgår logfiler og konfigurationer og implementerer kendte løsninger eller midlertidige løsninger.
- Niveau 3 (L3): Håndterer komplekse tekniske problemer, der kræver ingeniørmæssig ekspertise, analyse af årsagen eller ændringer i koden.
Afgrænsningerne varierer fra organisation til organisation. For eksempel kan en L3-ingeniør diagnosticere en fejl, mens vedligeholdelsesteamet udvikler, tester og implementerer den permanente løsning.
Regressionstest er ligeledes afgørende. Hver eneste ændring i koden bør kontrolleres for at sikre, at løsningen af et problem ikke har medført et nyt. Derfor bør kvalitetssikring og softwaretest være en del af vedligeholdelsesprocessen.
Når du sammenligner tjenester inden for vedligeholdelse af applikationer, skal du kontrollere, om brugerstøtte, overvågning, tekniske rettelser og releasehåndtering er inkluderet i prisen eller faktureres separat.
Hvad indgår normalt ikke i vedligeholdelse af applikationer?
Rutinemæssig vedligeholdelse af applikationer fokuserer generelt på et eksisterende system. Medmindre det udtrykkeligt fremgår af aftalen, kan større udviklingsprojekter, omfattende moderniseringer og drift af infrastruktur kræve en separat afgrænsning af omfanget og prisfastsættelse.
Typiske undtagelser omfatter:
- Vigtige nye funktioner: Opbygning af en ny kundeportal, en prisberegningsmotor eller et omfattende forretningsmodul kræver som regel et særskilt udviklingsoverslag.
- Modernisering af applikationer: Overførsel af et ældre system til en ny arkitektur, udskiftning af vigtige komponenter eller flytning af en applikation til en anden platform udgør typisk et særskilt moderniseringsprojekt.
- Infrastruktur og hostingdrift: Serveradministration, hostingstyring, sikkerhedskopiering og genopretning efter nedbrud falder muligvis uden for vedligeholdelsesomfanget, selvom mange udbydere tilbyder disse tjenester som tillægsydelser.
- Produktfejl hos tredjeparter: Problemer i en leverandørstyret SaaS-platform eller et licenseret produkt skal muligvis løses af leverandøren. Vedligeholdelsesteamet kan undersøge problemet og, hvor det er muligt, iværksætte en passende midlertidig løsning.
- Forretningsdrift: Dataindtastning, rutinemæssige indholdsopdateringer og administrativ brugeradministration varetages ofte af forretningsafdelinger eller supportmedarbejdere.
Den vigtigste forskel ligger i, om man skal opretholde den eksisterende funktionalitet eller levere en væsentlig ny funktion.
For eksempel kan tilføjelsen af et simpelt rapportfilter betragtes som en mindre forbedring. Udviklingen af et nyt rapporteringsmodul med yderligere datakilder, tilladelser og forretningslogik vil sandsynligvis kræve et separat tilbud.
En vedligeholdelsesaftale bør klart fastlægge denne grænse. Angiv omfangsgrænsen for mindre ændringer, godkendelsesprocessen for yderligere arbejde samt ansvaret for infrastruktur, sikkerhedskopier, certifikater og tredjepartstjenester.
Tjekliste for vedligeholdelse af applikationer opdelt efter hyppighed
En struktureret vedligeholdelsesplan hjælper teams med at opdage problemer, inden de udvikler sig til kostbare hændelser. Den rette hyppighed afhænger af applikationens kritikalitet, sikkerhedskrav, udgivelsespraksis og driftsrisiko.
| Frekvens | Typiske aktiviteter |
|---|---|
| Dagligt | Gennemgå overvågningsadvarsler, prioriter hændelser, undersøg kritiske fejl og bekræft, at planlagte opgaver og sikkerhedskopieringsprocesser er afsluttet |
| Ugentligt | Gennemgå ophobede fejl, undersøge tilbagevendende fejl, kontrollere sårbarhedsadvarsler og udgive godkendte rettelser med lav risiko |
| Månedligt | Gennemgå sikkerhedsopdateringer, opdateringer af afhængigheder, tendenser i ydeevnen, adgangsrettigheder samt udløbsdatoer for certifikater og licenser |
| Kvartalsvis | Vurdere opgraderinger af rammeværk og runtime, teste gendannelse af sikkerhedskopier, gennemgå teknisk gæld og planlægge kapacitetsforbedringer |
| Årligt | Gennemføre en tilstandsvurdering af applikationen, gennemgå udløbsdatoer for komponenter og opdatere vedligeholdelsesplanen og budgettet |
Denne tidsplan er et udgangspunkt, ikke en universel regel. Kritiske sårbarheder og driftsforstyrrelser kræver, at der handles straks, i stedet for at man venter på et planlagt vedligeholdelsesvindue. Nogle applikationer kræver desuden hyppigere opdateringer og adgangskontrol på grund af lovgivningsmæssige eller driftsmæssige krav.
Automatisering kan mindske den rutinemæssige arbejdsbyrde. CI/CD-pipelines, scanning af afhængigheder, automatiserede regressionstests og overvågningsadvarsler hjælper teams med at opdage problemer og levere ændringer på en mere konsekvent måde.
For applikationer, der er afhængige af cloud-infrastruktur og hyppige udgivelser, kan cloud, DevOps og sikkerhedsudvikling supplere vedligeholdelsesprocessen.
Hvordan fungerer serviceniveauerne for applikationsvedligeholdelse?
En serviceaftale (SLA) fastlægger den service, som en vedligeholdelsesudbyder forpligter sig til at levere. Den angiver typisk supporttider, prioriteter for hændelser, reaktionsmål, forventninger til løsning, eskaleringsprocedurer og rapporteringskrav.
En almindelig alvorlighedsmodel omfatter fire niveauer.
| Alvorlighed | Eksempel | Typisk fremgangsmåde |
|---|---|---|
| P1: Kritisk | Applikationen er utilgængelig for alle brugere, eller der er opstået en alvorlig sikkerhedshændelse | Øjeblikkelig reaktion, eskalering og kontinuerligt arbejde, indtil tjenesten er genoprettet, eller det aftalte genopretningsmål er nået |
| P2: Høj | En central forretningsfunktion bryder sammen, hvis der ikke findes en brugbar løsning | Prioriteret undersøgelse og en aftalt målsætning for afhjælpning eller midlertidig løsning |
| P3: Medium | En funktion virker ikke, men der findes en midlertidig løsning | Planlagt undersøgelse og løsning i henhold til den aftalte prioritet |
| P4: Lav | Et kosmetisk problem eller en anmodning om en mindre forbedring | Håndtering af ordrereserve og planlagt levering |
Dette er vejledende kategorier og ikke garanterede responstider på tværs af branchen. De nøjagtige mål bør afspejle forretningsmæssige konsekvenser, applikationens kritikalitet, supportdækningen og vedligeholdelseskontrakten.
En betalingsplatform rettet mod kunder kan have behov for dækning af kritiske hændelser døgnet rundt. Et internt rapporteringsværktøj, der anvendes i åbningstiden, kan have andre krav.
Hvilke nøgletal kan bruges til at måle vedligeholdelsesresultaterne?
De rette nøgletal viser, om vedligeholdelsen forbedrer applikationens pålidelighed og mindsker driftsrisikoen.
- Gennemsnitlig tid til løsning (MTTR): Måler, hvor lang tid det tager at løse hændelser, baseret på organisationens fastlagte målemetode.
- Tilgængelighed: Registrerer den andel af tiden, hvor applikationen er tilgængelig til brug.
- Fejlfrekvens ved ændringer: Måler andelen af implementeringer, der medfører fejl, der kræver indgriben eller afhjælpning.
- Forsinkelse ved opdateringer: Måler tiden fra en sikkerhedsopdatering bliver tilgængelig, til den implementeres.
- Alderen på opgaverne i opgavelisten: Viser, hvor længe fejl og vedligeholdelsesanmodninger forbliver uafklarede.
Vurder disse nøgletal sammen med hændelsernes alvorlighed og indvirkningen på forretningen. Et lavere antal supportanmodninger betyder ikke nødvendigvis bedre vedligeholdelse, hvis alvorlige problemer forbliver uløste.
Hvad bestemmer omkostningerne ved vedligeholdelse af applikationer?
Omkostningerne til vedligeholdelse af et program afhænger af programmets tilstand, kompleksiteten af dets teknologiske stack, den nødvendige supportdækning samt det risikoniveau, som virksomheden skal håndtere.
De vigtigste omkostningsfaktorer omfatter:
- Kodekvalitet og testdækning: Velstrukturerede og grundigt testede applikationer er generelt nemmere og mere sikre at ændre.
- Teknologitiden: Rammer, der ikke længere understøttes, og forældede kørselsmiljøer kan kræve mere undersøgelse, opgraderinger og kompatibilitetsarbejde.
- Kompleksitet ved integration: Hvert eksternt API, hver betalingstjeneste, hvert ERP-system eller hver CRM-platform medfører afhængigheder, der kan ændre sig uafhængigt af hinanden.
- Krav til overholdelse og sikkerhed: Gældende forpligtelser, såsom GDPR, HIPAA eller PCI DSS, kan medføre øget arbejdsbyrde i forbindelse med dokumentation, test, adgangskontrol og sikkerhed.
- Supportdækning: Håndtering af hændelser døgnet rundt kræver generelt flere ressourcer end support inden for normal arbejdstid.
- Dokumentationens kvalitet: Manglende arkitekturbeskrivelser, implementeringsvejledninger eller hændelsesrapporter kan forlænge undersøgelsestiden.
- Applikationens kritikalitet: Systemer, der understøtter væsentlige driftsfunktioner, kan kræve mere omfattende test, overvågning, genopretningsplanlægning og eskalering af hændelser.
Vedligeholdelsesudbydere benytter sig typisk af månedlige fastprisaftaler med fastlagte timer, prissætning baseret på tid og materialer eller dedikerede ingeniørteams. Den rette model afhænger af, hvor forudsigelig arbejdsbyrden er, applikationens kompleksitet og den nødvendige ingeniørkapacitet.
Ved vurderingen af de langsigtede omkostninger ved at eje software bør man også tage højde for vedligeholdelse. Det oprindelige udviklingsbudget afspejler ikke i sig selv den løbende indsats, der er nødvendig for at sikre, at softwaren forbliver sikker, kompatibel og brugbar.
For at få et bredere overblik over disse beslutninger kan du læse Monarch Innovations vejledning om udvikling, køb eller outsourcing af virksomhedssoftware.
Bør du vælge intern, outsourcet eller hybrid vedligeholdelse?
Den bedste model for vedligeholdelse af applikationer afhænger af den interne tekniske kapacitet, applikationens betydning for virksomheden og omfanget af den nødvendige specialiserede support.
Intern vedligeholdelse
Et internt team kan være et godt valg, når applikationen er central for produktet, og udviklerne allerede har indgående kendskab til dens arkitektur. Udfordringen ligger i at finde den rette balance mellem vedligeholdelsesarbejde og udvikling af nye funktioner samt andre prioriteter i udviklingsplanen.
Udset vedligeholdelse
En ekstern leverandør kan stille dedikeret ingeniørkapacitet til rådighed, uden at virksomheden behøver at ansætte alle specialister internt. Succesen afhænger af en struktureret videnoverførsel, klare adgangskontrolforanstaltninger, dokumenterede ansvarsforhold og enighed om serviceniveauer.
Hybridvedligeholdelse
En hybridmodel kombinerer internt ejerskab med ekstern teknisk support. Det interne team kan stå for produktbeslutninger og prioriteringer, mens en partner varetager de aftalte ansvarsområder, såsom sikkerhedsopdateringer, ydeevneforbedringer, opgraderinger, test og fejlretning.
Inden du vælger en model, skal du afklare, hvem der skal have ansvaret for kodebasen, driftsmiljøerne, adgangsoplysningerne, dokumentationen, eskalering af hændelser og godkendelse af udgivelser. Disse ansvarsområder skal være klart definerede, uanset hvem der udfører vedligeholdelsesarbejdet.
Sådan udarbejdes en vedligeholdelsesplan for et program
En effektiv vedligeholdelsesplan for applikationer tager udgangspunkt i en forståelse af softwareporteføljen og de dermed forbundne driftsmæssige risici. En kontrakt bør bygge videre på denne vurdering i stedet for at erstatte den.
Følg disse trin for at udarbejde en praktisk plan:
- Lav en oversigt over jeres applikationer. Registrer de systemer, der er i brug, deres forretningsmæssige formål, teknologiske platforme, integrationer og tekniske ansvarlige.
- Vurder forretningskritikaliteten. Identificer, hvilke applikationer der understøtter væsentlige processer, og hvilke konsekvenser en afbrydelse ville have for organisationen.
- Definer vedligeholdelsesomfanget. Angiv de aktiviteter, der er omfattet, undtagelser, grænser for mindre forbedringer samt ansvaret for afhængigheder over for tredjeparter.
- Fastlæg serviceniveauer. Definer alvorlighedsgrader, mål for reaktionstid og løsningstid, supportåbningstider samt eskaleringsprocedurer.
- Tildel ejerskab. Afklar ansvaret for kildekode, infrastruktur, adgangsoplysninger, sikkerhed, test, udgivelser og koordinering med leverandører.
- Definer præstationsmålinger. Overvåg hændelser, tilgængelighed, forsinkelser ved patch-installation, fejl ved ændringer og uafsluttet vedligeholdelsesarbejde.
- Gennemgå planen regelmæssigt. Vurder på ny prioriteter, teknologiske risici, omkostninger og serviceniveauer i takt med, at applikationen og virksomheden udvikler sig.
En klar plan mindsker uklarheden og hjælper virksomhederne med at skelne mellem nødvendig vedligeholdelse og arbejde, der kræver et særskilt udviklingsprojekt.
Monarch Innovation støtter virksomheder og industrielle teams gennem sine digitale ingeniørydelser, herunder udvikling af skræddersyet software, cloud-løsninger og DevOps samt kvalitetssikring. Ved at koordinere disse kompetencer kan man mindske antallet af overdragelser, når ændringer i applikationer omfatter kode, infrastruktur og test.
Er du ikke helt sikker på, hvad dit nuværende vedligeholdelsesomfang dækker?
Tal med Monarch Innovation om din applikation, dens integrationer og de serviceniveauer, som din virksomhed har brug for.
Tal om din ansøgning
