Cosa comprende la manutenzione delle applicazioni

Harsh Joshi

Co-founder & Technical Director

La manutenzione delle applicazioni va ben oltre la semplice correzione dei bug. Scopri le otto aree che rientrano in un ambito completo, cosa di solito ne rimane escluso e in che modo i livelli di servizio e i fattori di costo determinano ciò che ottieni.

La manutenzione delle applicazioni comprende le attività necessarie per garantire che il software rimanga sicuro, affidabile, compatibile e funzionale dopo il lancio. Comprende la correzione di bug, l’applicazione di patch di sicurezza, l’aggiornamento delle dipendenze, il miglioramento delle prestazioni, la manutenzione dell’integrazione, il monitoraggio e piccoli miglioramenti.

Per le aziende che si affidano ad applicazioni personalizzate, la manutenzione rappresenta una responsabilità ingegneristica continua. Senza di essa, il software può diventare vulnerabile alle minacce alla sicurezza, incompatibile con le piattaforme più recenti, più lento con l’aumentare dei dati o più costoso da aggiornare. Ecco perché i servizi di ingegneria del software di Monarch Innovation includono un supporto strutturato anche dopo il rilascio, non solo lo sviluppo.

Tuttavia, sapere che un’applicazione necessita di manutenzione è solo il punto di partenza. Le aziende devono anche comprendere cosa comprende la manutenzione, quali attività ne esulano e cosa aspettarsi da un contratto di manutenzione.

Questa guida illustra l'ambito di applicazione, le tipologie, i livelli di servizio, i costi e gli aspetti da considerare nella pianificazione che i CTO, i responsabili IT e i product owner dovrebbero conoscere prima di scegliere un approccio alla manutenzione delle applicazioni.

Cosa comprende la manutenzione delle applicazioni?

La manutenzione delle applicazioni comprende in genere otto attività principali: correzione dei difetti, applicazione delle patch di sicurezza, aggiornamento delle dipendenze, mantenimento dell'integrazione, ottimizzazione delle prestazioni, monitoraggio, miglioramenti minori e aggiornamento della documentazione.

Ogni attività affronta un rischio diverso che può emergere con l'evoluzione del software.

Risoluzione di bug e correzione di difetti: individuare e risolvere gli errori che compromettono il funzionamento dell'applicazione, l'accuratezza dei dati o l'esperienza utente.
Applicazione delle patch di sicurezza: risolvere le vulnerabilità note nel codice delle applicazioni, nei framework, nelle librerie e negli ambienti di esecuzione.
Aggiornamenti delle dipendenze e delle piattaforme: aggiornare i componenti software e adattare le applicazioni alle modifiche apportate ai sistemi operativi, ai browser, alle piattaforme mobili e ai servizi cloud.
Manutenzione delle integrazioni: garantire il corretto funzionamento delle connessioni con i sistemi ERP, le piattaforme CRM, i gateway di pagamento e le API di terze parti, anche in caso di modifiche a tali sistemi.
Ottimizzazione delle prestazioni: analizzare le query lente del database, le perdite di memoria e i colli di bottiglia che emergono con l'aumentare dell'utilizzo e dei volumi di dati.
Monitoraggio e risposta agli incidenti: monitorare la disponibilità delle applicazioni, gli errori e i tempi di risposta, quindi analizzare gli avvisi e le interruzioni del servizio.
Miglioramenti minori: apportare piccole modifiche ben definite, come l'aggiunta di un filtro per i report, l'ottimizzazione di un flusso di lavoro o il miglioramento di un messaggio di errore.
Aggiornamenti della documentazione: gestire la documentazione tecnica, le istruzioni di implementazione, i runbook e i registri delle modifiche, in modo che i futuri interventi di manutenzione possano essere eseguiti in sicurezza.

Si consideri un’applicazione per l’assistenza sul campo utilizzata da centinaia di tecnici. Una nuova versione di Android modifica le autorizzazioni relative alla localizzazione, un fornitore di servizi di pagamento ritira una versione dell’API e una dashboard di reportistica diventa più lenta man mano che si accumulano i record relativi agli interventi.

Questi problemi richiedono soluzioni ingegneristiche diverse, ma possono tutti rientrare nell'ambito della manutenzione delle applicazioni. L'obiettivo è mantenere l'applicazione esistente funzionante, sicura e affidabile nonostante i cambiamenti dell'ambiente operativo.

Quali sono i quattro tipi principali di manutenzione delle applicazioni?

I quattro tipi di manutenzione del software comunemente riconosciuti sono: manutenzione correttiva, adattiva, perfezionante e preventiva. Ciascuno di essi risponde a una diversa motivazione alla base delle modifiche apportate al software dopo il rilascio.

Tipo	Scopo	Esempio
Manutenzione correttiva	Risolvere un guasto esistente	Risolvere un errore di checkout che rifiuta pagamenti validi
Manutenzione adattiva	Adattare il software ai cambiamenti ambientali	Aggiornare un'applicazione per un nuovo sistema operativo o una nuova versione dell'API
Manutenzione perfezionata	Migliorare la funzionalità, l'usabilità o le prestazioni	Ottimizzare una dashboard lenta o semplificare un modulo
Manutenzione preventiva	Ridurre il rischio di guasti futuri	Rifattorizzare il codice fragile, migliorare la copertura dei test o rimuovere le dipendenze obsolete

Queste categorie sono in linea con la terminologia consolidata in materia di manutenzione del software, compresa la norma ISO/IEC/IEEE 14764:2022, lo standard internazionale per la manutenzione del software.

Alcuni modelli di manutenzione trattano anche la manutenzione additiva, che consiste nell’aggiungere funzionalità al software già in uso. La classificazione esatta utilizzata può dipendere dal modello o dallo standard seguito.

Un piano di manutenzione equilibrato non si limita a risolvere i bug di produzione. Gli interventi correttivi ripristinano la funzionalità, mentre le attività adattive e preventive contribuiscono a ridurre le interruzioni future. Gli interventi di perfezionamento mantengono l’applicazione in linea con le mutevoli esigenze degli utenti e dell’azienda.

Manutenzione delle applicazioni vs. Assistenza alle applicazioni

La manutenzione delle applicazioni si concentra sulla modifica e sul miglioramento del software. L'assistenza alle applicazioni si concentra invece sull'aiuto agli utenti, sull'analisi dei problemi operativi e sul garantire il corretto funzionamento quotidiano delle applicazioni.

Sebbene le attività si sovrappongano, tale distinzione è importante ai fini della definizione delle responsabilità in un contratto di servizio.

Il supporto alle applicazioni è solitamente suddiviso in tre livelli:

Livello 1 (L1): Gestisce le domande di base degli utenti, il ripristino delle password, le richieste di assistenza e la registrazione iniziale dei ticket.
Livello 2 (L2): analizza i problemi relativi alle applicazioni, esamina i log e le configurazioni e applica le soluzioni o le soluzioni alternative già note.
Livello 3 (L3): Gestisce problemi tecnici complessi che richiedono competenze ingegneristiche, analisi delle cause alla radice o modifiche al codice.

I confini variano a seconda dell'organizzazione. Ad esempio, un ingegnere di livello L3 può individuare un difetto, mentre il team di manutenzione sviluppa, testa e implementa la soluzione definitiva.

Anche i test di regressione sono fondamentali. Ogni modifica al codice dovrebbe essere verificata per assicurarsi che la risoluzione di un problema non ne abbia causato un altro. Ecco perché il controllo qualità e i test del software dovrebbero far parte del flusso di lavoro di manutenzione.

Quando si confrontano i servizi di manutenzione delle applicazioni, verificare se l’assistenza agli utenti, il monitoraggio, le correzioni tecniche e la gestione delle versioni siano tutti inclusi o se abbiano un costo separato.

Cosa non è solitamente incluso nella manutenzione delle applicazioni?

La manutenzione ordinaria delle applicazioni si concentra generalmente su un sistema esistente. A meno che non siano espressamente inclusi nel contratto, i progetti di sviluppo di ampia portata, gli interventi di modernizzazione su larga scala e la gestione delle infrastrutture potrebbero richiedere definizioni separate dell’ambito di intervento e dei costi.

Tra le esclusioni più comuni figurano:

Principali novità: la realizzazione di un nuovo portale clienti, di un motore di determinazione dei prezzi o di un modulo aziendale di ampia portata richiede solitamente un preventivo di sviluppo a parte.
Modernizzazione delle applicazioni: la migrazione di un sistema legacy verso una nuova architettura, la sostituzione di componenti principali o il trasferimento di un'applicazione su una piattaforma diversa costituiscono in genere un progetto di modernizzazione dedicato.
Infrastruttura e operazioni di hosting: l'amministrazione dei server, la gestione dell'hosting, i backup e il ripristino di emergenza potrebbero non rientrare nell'ambito della manutenzione, sebbene molti fornitori li offrano come servizi aggiuntivi.
Difetti dei prodotti di terze parti: eventuali problemi all’interno di una piattaforma SaaS gestita dal fornitore o di un prodotto concesso in licenza potrebbero dover essere risolti dal fornitore stesso. Il team di manutenzione può analizzare il problema e, ove possibile, implementare una soluzione alternativa adeguata.
Attività aziendali: l'inserimento dei dati, gli aggiornamenti periodici dei contenuti e la gestione amministrativa degli utenti sono spesso affidati ai team aziendali o al personale di supporto.

La distinzione più importante è quella tra il mantenimento delle funzionalità esistenti e l'introduzione di una nuova funzionalità sostanziale.

Ad esempio, l'aggiunta di un semplice filtro per i report potrebbe essere considerata un miglioramento minore. Lo sviluppo di un nuovo modulo di reportistica con fonti di dati, autorizzazioni e logica di business aggiuntive richiederà molto probabilmente un preventivo a parte.

Un contratto di manutenzione dovrebbe definire chiaramente tali limiti. È necessario specificare il limite di impegno per le modifiche minori, la procedura di approvazione per i lavori aggiuntivi e le responsabilità relative all'infrastruttura, ai backup, ai certificati e ai servizi di terze parti.

Lista di controllo per la manutenzione delle applicazioni in base alla frequenza

Un programma di manutenzione strutturato aiuta i team a individuare i problemi prima che si trasformino in incidenti costosi. La frequenza adeguata dipende dalla criticità dell'applicazione, dai requisiti di sicurezza, dalle procedure di rilascio e dal rischio operativo.

Frequenza	Attività tipiche
Giornaliero	Esaminare gli avvisi di monitoraggio, classificare gli incidenti, verificare gli errori critici e accertarsi che i processi pianificati e le operazioni di backup siano stati completati
Settimanale	Esaminare gli arretrati relativi ai difetti, analizzare gli errori ricorrenti, verificare gli avvisi di vulnerabilità e rilasciare le correzioni approvate a basso rischio
Mensile	Esaminare le patch di sicurezza, gli aggiornamenti delle dipendenze, l'andamento delle prestazioni, le autorizzazioni di accesso e le date di scadenza dei certificati o delle licenze
Trimestrale	Valutare gli aggiornamenti dell'infrastruttura e del runtime, testare il ripristino dei backup, esaminare il debito tecnico e pianificare miglioramenti della capacità
Annuale	Effettuare una valutazione dello stato di salute delle applicazioni, esaminare le date di fine vita dei componenti e aggiornare la roadmap di manutenzione e il budget

Questo programma rappresenta un punto di partenza, non una regola universale. Le vulnerabilità critiche e le interruzioni del servizio richiedono un intervento tempestivo, senza attendere la finestra di manutenzione programmata. Alcune applicazioni richiedono inoltre l'applicazione di patch e revisioni degli accessi più frequenti a causa di requisiti normativi o operativi.

L'automazione può ridurre il carico di lavoro di routine. Le pipeline CI/CD, l'analisi delle dipendenze, i test di regressione automatizzati e gli avvisi di monitoraggio aiutano i team a individuare i problemi e a implementare le modifiche in modo più coerente.

Per le applicazioni che si basano su infrastrutture cloud e richiedono aggiornamenti frequenti, il cloud, il DevOps e l'ingegneria della sicurezza possono integrare il processo di manutenzione.

Come funzionano i livelli di servizio relativi alla manutenzione delle applicazioni?

Un accordo sul livello di servizio (SLA) definisce il servizio che un fornitore di servizi di manutenzione si impegna a fornire. In genere specifica gli orari di assistenza, le priorità degli incidenti, gli obiettivi di risposta, le aspettative di risoluzione, le procedure di escalation e i requisiti di rendicontazione.

Un modello di gravità comunemente utilizzato prevede quattro livelli.

Gravità	Esempio	Approccio operativo tipico
P1: Critico	Applicazione non disponibile per tutti gli utenti o grave incidente di sicurezza	Risposta immediata, escalation e intervento continuo fino al ripristino del servizio o al raggiungimento dell'obiettivo di ripristino concordato
P2: Alto	Una funzione aziendale fondamentale smette di funzionare senza una soluzione alternativa valida	Indagine prioritaria e obiettivo concordato di correzione o soluzione alternativa
P3: Medio	Una funzionalità non funziona, ma è disponibile una soluzione alternativa	Analisi e risoluzione programmate in base alla priorità concordata
P4: Basso	Una questione estetica o una richiesta di miglioramento di lieve entità	Gestione degli ordini arretrati e consegne programmate

Si tratta di categorie indicative, non di tempi di risposta garantiti a livello di settore. Gli obiettivi precisi dovrebbero tenere conto dell’impatto sull’attività, della criticità dell’applicazione, della copertura dell’assistenza e del contratto di manutenzione.

Una piattaforma di pagamento rivolta ai clienti potrebbe necessitare di una copertura per gli incidenti critici 24 ore su 24, 7 giorni su 7. Uno strumento di segnalazione interno utilizzato durante l'orario di lavoro potrebbe avere requisiti diversi.

Quali indicatori consentono di misurare le prestazioni della manutenzione?

Le metriche giuste indicano se la manutenzione sta migliorando l'affidabilità delle applicazioni e riducendo il rischio operativo.

Tempo medio di risoluzione (MTTR): misura il tempo necessario per risolvere gli incidenti, in base al metodo di misurazione definito dall'organizzazione.
Disponibilità: monitora la percentuale di tempo in cui l'applicazione è disponibile per l'uso.
Tasso di fallimento delle modifiche: misura la percentuale di implementazioni che danno luogo a errori che richiedono un intervento o una correzione.
Latenza delle patch: misura il tempo che intercorre tra la disponibilità di una patch di sicurezza e la sua implementazione.
Anzianità degli arretrati: indica da quanto tempo i difetti e le richieste di manutenzione rimangono irrisolti.

Valutate questi indicatori tenendo conto della gravità degli incidenti e dell'impatto sul business. Un numero inferiore di ticket non implica necessariamente una migliore manutenzione se permangono problemi gravi irrisolti.

Cosa determina i costi di manutenzione delle applicazioni?

Il costo di manutenzione di un'applicazione dipende dalle condizioni dell'applicazione stessa, dalla complessità del suo stack tecnologico, dalla copertura di assistenza richiesta e dal livello di rischio che l'azienda deve gestire.

Tra i principali fattori di costo figurano:

Qualità del codice e copertura dei test: le applicazioni ben strutturate e accuratamente testate sono in genere più facili e sicure da modificare.
L'era della tecnologia: i framework non supportati e i runtime obsoleti possono richiedere ulteriori analisi, aggiornamenti e interventi di compatibilità.
Complessità dell'integrazione: ogni API esterna, servizio di pagamento, sistema ERP o piattaforma CRM introduce dipendenze che possono subire modifiche in modo indipendente.
Requisiti di conformità e sicurezza: gli obblighi applicabili, quali il GDPR, l’HIPAA o il PCI DSS, possono comportare un aumento del carico di lavoro in termini di documentazione, test, controllo degli accessi e sicurezza.
Copertura dell'assistenza: la gestione degli incidenti 24 ore su 24 richiede in genere più risorse rispetto all'assistenza fornita durante l'orario di lavoro.
Qualità della documentazione: la mancanza di note sull’architettura, istruzioni di implementazione o registrazioni degli incidenti può allungare i tempi di indagine.
Criticità dell'applicazione: i sistemi che supportano operazioni essenziali potrebbero richiedere test, monitoraggio, piani di ripristino e procedure di escalation degli incidenti più rigorosi.

I fornitori di servizi di manutenzione ricorrono solitamente a contratti mensili con un numero prestabilito di ore, a tariffe basate su tempo e materiali oppure a team di ingegneri dedicati. La scelta del modello più adatto dipende dalla prevedibilità del carico di lavoro, dalla complessità dell’applicazione e dalla quantità di risorse ingegneristiche necessarie.

Nel valutare i costi di possesso a lungo termine del software occorre tenere conto anche della manutenzione. Il budget iniziale destinato allo sviluppo, da solo, non riflette l'impegno costante necessario per garantire che il software rimanga sicuro, compatibile e funzionale.

Per una visione più ampia di queste decisioni, consulta la guida di Monarch Innovation sulla creazione, l'acquisto o l'esternalizzazione del software aziendale.

È meglio optare per una manutenzione interna, esternalizzata o ibrida?

Il modello di manutenzione delle applicazioni più adatto dipende dalle risorse tecniche interne, dall'importanza dell'applicazione per l'azienda e dal livello di supporto specialistico richiesto.

Manutenzione interna

Un team interno può rappresentare una scelta valida quando l'applicazione è fondamentale per il prodotto e gli ingegneri ne conoscono già l'architettura. La sfida consiste nel trovare un equilibrio tra il lavoro di manutenzione, lo sviluppo di nuove funzionalità e le altre priorità della roadmap.

Manutenzione in outsourcing

Un fornitore esterno può mettere a disposizione risorse ingegneristiche dedicate senza che l'azienda debba assumere internamente ogni singolo specialista. Il successo dipende da un trasferimento strutturato delle conoscenze, da chiari controlli di accesso, da responsabilità documentate e da un accordo sui livelli di servizio.

Manutenzione ibrida

Un modello ibrido combina la gestione interna con il supporto tecnico esterno. Il team interno può occuparsi delle decisioni relative al prodotto e delle priorità, mentre un partner si fa carico delle responsabilità concordate, quali gli aggiornamenti di sicurezza, i miglioramenti delle prestazioni, gli aggiornamenti, i test e la risoluzione dei difetti.

Prima di scegliere un modello, occorre stabilire chi sarà responsabile del codice sorgente, degli ambienti di distribuzione, delle credenziali, della documentazione, dell’escalation degli incidenti e delle approvazioni delle versioni. Tali responsabilità devono rimanere ben definite, indipendentemente da chi si occupi delle attività di manutenzione.

Come elaborare un piano di manutenzione delle applicazioni

Un piano efficace di manutenzione delle applicazioni inizia con la comprensione del portafoglio software e dei relativi rischi operativi. Il contratto dovrebbe essere il risultato di tale valutazione, piuttosto che sostituirla.

Segui questi passaggi per elaborare un piano concreto:

Fai un inventario delle tue applicazioni. Registra i sistemi in uso, la loro finalità aziendale, gli stack tecnologici, le integrazioni e i responsabili tecnici.
Valutare la criticità aziendale. Identificare quali applicazioni supportano i processi essenziali e quali conseguenze avrebbe un’interruzione per l’organizzazione.
Definire l'ambito della manutenzione. Specificare le attività incluse, le esclusioni, i limiti relativi ai miglioramenti minori e le responsabilità relative alle dipendenze da terze parti.
Definire i livelli di servizio. Stabilire le definizioni di gravità, gli obiettivi di risposta e risoluzione, gli orari di assistenza e le procedure di escalation.
Assegnare la titolarità. Chiarire le responsabilità relative al codice sorgente, all’infrastruttura, alle credenziali, alla sicurezza, ai test, alle versioni e al coordinamento con i fornitori.
Definire gli indicatori di prestazione. Monitorare gli incidenti, la disponibilità, i tempi di applicazione delle patch, gli errori nelle modifiche e gli interventi di manutenzione non completati.
Rivedere il piano regolarmente. Rivalutare le priorità, i rischi tecnologici, i costi e i livelli di servizio man mano che l'applicazione e l'attività aziendale si evolvono.

Un piano ben definito riduce le ambiguità e aiuta le aziende a distinguere la manutenzione essenziale dagli interventi che richiedono un progetto di sviluppo a sé stante.

Monarch Innovation supporta i team aziendali e industriali attraverso i propri servizi di ingegneria digitale, tra cui lo sviluppo di software personalizzato, il cloud e il DevOps, nonché il controllo qualità. Il coordinamento di queste competenze può contribuire a ridurre i passaggi di consegne quando le modifiche alle applicazioni coinvolgono il codice, l’infrastruttura e i test.

Non sai bene cosa comprenda il tuo attuale programma di manutenzione?

Contatta Monarch Innovation per discutere della tua applicazione, delle sue integrazioni e dei livelli di servizio di cui la tua azienda ha bisogno.

Parla della tua candidatura

Con quale frequenza dovrebbe essere effettuata la manutenzione delle applicazioni?

La manutenzione delle applicazioni è un’attività continua, non un evento annuale. Il monitoraggio e la classificazione degli incidenti possono avvenire quotidianamente, mentre l’applicazione delle patch di sicurezza e la verifica delle dipendenze seguono un calendario basato sul rischio, spesso mensile per gli aggiornamenti di routine. Le vulnerabilità critiche e le interruzioni del servizio richiedono un intervento tempestivo, indipendentemente dal ciclo di manutenzione pianificato, in base alle regole di gravità concordate nell’accordo sul livello di servizio.

La manutenzione delle applicazioni è la stessa cosa dei servizi di gestione delle applicazioni?

No. La manutenzione delle applicazioni si concentra sulle modifiche tecniche necessarie a garantire l’affidabilità e l’aggiornamento del software. Il termine “servizi di gestione delle applicazioni” (AMS) è più ampio e può comprendere, oltre alla manutenzione, anche l’assistenza agli utenti, il monitoraggio e i servizi di hosting o operativi. Quando si confrontano le proposte relative agli AMS, è importante verificare quali di questi elementi siano effettivamente inclusi da ciascun fornitore, piuttosto che basarsi semplicemente sulla denominazione.

La manutenzione dell'applicazione comprende l'aggiunta di nuove funzionalità?

Può includere piccole migliorie concordate, come un filtro per i report o una modifica al flusso di lavoro. Le funzionalità principali, i nuovi moduli e le integrazioni di rilevanza richiedono solitamente un preventivo di sviluppo a parte. L’accordo dovrebbe definire chiaramente i limiti, ad esempio stabilendo un limite di impegno per ogni richiesta di modifica e una procedura di approvazione per le richieste di maggiore entità.

Cosa succede quando gli sviluppatori originali non sono più disponibili?

Un nuovo team può subentrare dopo un passaggio di consegne ben strutturato. Ciò comporta in genere l’accesso al codice sorgente, ai repository, alle pipeline di distribuzione, agli ambienti, alla documentazione sull’architettura, ai problemi noti e alle procedure operative. Un periodo dedicato al trasferimento delle conoscenze aiuta il nuovo team a comprendere il sistema prima di assumerne la piena responsabilità.

Come si fa a capire se la manutenzione di un'applicazione è diventata troppo costosa?

Tra i segnali di allarme figurano l’aumento dell’impegno richiesto per la manutenzione, frequenti regressioni, rallentamenti crescenti nell’implementazione delle modifiche, incidenti ricorrenti e componenti tecnologici non più supportati. Quando la maggior parte del budget viene destinata al mantenimento dell’applicazione piuttosto che al suo miglioramento, è opportuno confrontare i costi e i rischi legati alla manutenzione con quelli della modernizzazione o della sostituzione su un arco temporale compreso tra i tre e i cinque anni.

Cosa dovrebbe prevedere un contratto di manutenzione delle applicazioni?

Dovrebbe definire le applicazioni e gli ambienti coperti, le attività incluse, le esclusioni, i livelli di gravità, gli obiettivi di risposta e risoluzione, gli orari di assistenza, i limiti relativi ai miglioramenti, le responsabilità in materia di sicurezza, la rendicontazione, gli indicatori di prestazione e le modalità di passaggio di consegne. Le esclusioni chiare sono importanti tanto quanto le inclusioni, poiché la maggior parte delle controversie deriva da attività che ciascuna parte riteneva fossero di competenza dell’altra.

È possibile automatizzare la manutenzione delle applicazioni?

Sì, in parte. Il monitoraggio, l’analisi delle dipendenze, le pipeline CI/CD, i test di regressione automatizzati e i controlli programmati dei certificati e dei backup possono gestire molte attività di routine. Gli ingegneri sono comunque necessari per individuare le cause alla radice, stabilire le priorità dei rischi e valutare se una modifica sia sicura per l’azienda; pertanto, l’automazione riduce lo sforzo di manutenzione piuttosto che sostituire il team di manutenzione.