Restauro Software
Subentro su gestionali e applicazioni web esistenti
Quando il precedente sviluppatore non è più disponibile o il rapporto con il fornitore deve terminare, non è sempre necessario sostituire il software.
Restauro Software prende in carico gestionali e applicazioni web aziendali esistenti, ricostruendone progressivamente il funzionamento e verificando le condizioni necessarie per mantenerli, correggerli e farli evolvere.
Il subentro non inizia dalle nuove funzionalità. Inizia dalla comprensione di ciò che esiste, dalla disponibilità degli accessi e dalla possibilità di intervenire senza compromettere dati e continuità operativa.
Quando serve un nuovo sviluppatore
Un nuovo sviluppatore può essere necessario quando:
- il professionista o la società che ha realizzato il software non è più disponibile;
- il rapporto con il fornitore deve concludersi;
- gli interventi richiesti restano bloccati per lunghi periodi;
- il gestionale continua a funzionare, ma nessuno vuole più modificarlo;
- il codice esiste, ma non è documentato;
- le conoscenze sul sistema sono concentrate in una sola persona;
- l'applicazione è diventata difficile da aggiornare;
- occorre integrare il software con nuovi servizi;
- l'azienda vuole ridurre una dipendenza tecnica o organizzativa dal precedente fornitore.
Cambiare sviluppatore non significa cambiare gestionale
La necessità di cambiare sviluppatore non implica automaticamente la sostituzione del gestionale.
Molte applicazioni contengono anni di regole aziendali, dati, procedure e adattamenti costruiti sul lavoro reale degli utenti. Una riscrittura completa può essere opportuna in alcuni casi, ma deve essere il risultato di un'analisi, non una conclusione presa prima di conoscere il sistema.
Quando il software è recuperabile, il primo obiettivo è stabilizzarlo e rendere nuovamente possibili interventi controllati. Solo dopo è possibile definire un percorso di manutenzione o modernizzazione.
Approfondite anche cosa verificare prima di cambiare sviluppatore.
Cosa deve essere recuperato prima del subentro
La presa in carico richiede di identificare e, quando disponibili, raccogliere gli elementi che permettono al software di funzionare:
- codice sorgente;
- database e procedure di backup;
- accessi a server, hosting o servizi cloud;
- dominio, DNS e certificati;
- repository e storico delle modifiche;
- configurazioni dell'applicazione;
- credenziali tecniche;
- servizi esterni e API;
- processi pianificati;
- caselle email utilizzate dal sistema;
- ambienti di test e produzione;
- procedure di pubblicazione;
- documentazione;
- licenze e diritti di utilizzo o modifica.
La mancanza di uno o più elementi non rende sempre impossibile il subentro, ma incide sulle verifiche, sui rischi e sui tempi necessari. La checklist per il passaggio di consegne aiuta a organizzare la raccolta.
Come avviene la presa in carico
Il percorso viene organizzato per fasi.
Raccolta delle informazioni
Ricostruiamo lo scopo dell'applicazione, le funzioni essenziali, gli utenti coinvolti e le criticità note.
Verifica degli asset
Controlliamo quali accessi, dati, file, account e servizi siano realmente disponibili e sotto il controllo dell'azienda.
Analisi tecnica iniziale
Esaminiamo struttura del codice, database, configurazioni, dipendenze, integrazioni e modalità di rilascio.
Valutazione dei rischi
Individuiamo gli elementi che potrebbero compromettere continuità, sicurezza, recuperabilità o manutenzione.
Piano di subentro
Definiamo attività prioritarie, prerequisiti, responsabilità e limiti dell'intervento.
Stabilizzazione
Quando possibile, predisponiamo backup verificabili, tracciamento delle modifiche, ambienti di test, log e procedure di rilascio più controllate.
Manutenzione e sviluppo evolutivo
Solo dopo la fase di presa in carico vengono pianificati correzioni, adeguamenti, integrazioni o nuove funzionalità.
Se la documentazione non esiste
L'assenza di documentazione è frequente nei software sviluppati nel tempo.
In questi casi la conoscenza deve essere ricostruita attraverso il codice, il database, le configurazioni, i log, il comportamento dell'applicazione e il confronto con chi la utilizza.
Questa attività non produce automaticamente una documentazione completa di tutto il sistema. L'obiettivo iniziale è documentare ciò che serve per intervenire in sicurezza sulle aree prioritarie e ridurre progressivamente la dipendenza da conoscenze non formalizzate.
Se mancano codice o accessi
Prima di assumere che un software sia recuperabile occorre verificare cosa sia realmente disponibile.
Se mancano il codice sorgente, l'accesso al database o il controllo dell'infrastruttura, può essere necessario coinvolgere il precedente fornitore, il gestore dell'hosting o altri soggetti.
In alcune situazioni il subentro può essere parziale. In altre, l'assenza degli asset essenziali può rendere più ragionevole una migrazione o una sostituzione. La valutazione deve distinguere con chiarezza ciò che è tecnicamente possibile da ciò che sarebbe troppo rischioso.
Prime attività dopo il subentro
Le prime attività non sono uguali per ogni applicazione. Possono includere:
- verifica e consolidamento dei backup;
- introduzione o recupero del controllo di versione;
- raccolta delle configurazioni;
- analisi degli errori ricorrenti;
- revisione dei log;
- predisposizione di un ambiente di test;
- mappatura delle integrazioni;
- controllo delle dipendenze obsolete;
- definizione di una procedura di rilascio;
- correzione delle criticità che impediscono interventi successivi.
Subentro, manutenzione e modernizzazione
Il subentro è il punto di partenza.
Dopo aver ricostruito il funzionamento del software, l'azienda può scegliere se limitarsi alla manutenzione, introdurre nuove funzioni, rinnovare l'interfaccia o avviare una modernizzazione progressiva.
Quando la tecnologia è nota e l'applicazione utilizza PHP e MySQL, il percorso può proseguire con la nostra attività di manutenzione e presa in carico tecnica di applicazioni PHP/MySQL esistenti.
Quando invece il problema riguarda soprattutto obsolescenza, integrazioni o difficoltà evolutive, può essere opportuno valutare la modernizzazione di applicazioni web e gestionali.
Quanto costa il subentro
Il costo non può essere determinato soltanto dal numero di pagine o funzioni del gestionale.
Dipende dalla disponibilità del codice, dalla qualità degli accessi, dalla struttura del database, dalle integrazioni, dalle dipendenze, dalla documentazione e dal livello di rischio operativo.
Per questo il primo intervento è generalmente un check-up delimitato, con obiettivi e perimetro concordati. Il risultato deve permettere di distinguere le attività necessarie per la presa in carico da quelle evolutive che potranno essere pianificate successivamente.
Situazioni tipiche che possiamo esaminare
Gli scenari seguenti sono esempi ipotetici e non casi studio reali.
Sviluppatore non più disponibile
Un gestionale interno continua a essere utilizzato, ma il professionista che lo ha sviluppato non è più reperibile. Sono disponibili hosting, database e una copia del codice, ma non esistono repository, documentazione o ambiente di test.
In una situazione di questo tipo il primo obiettivo non è introdurre nuove funzioni, ma verificare gli asset, ricostruire la struttura e rendere possibili interventi controllati.
Passaggio programmato a un nuovo fornitore
L'azienda vuole interrompere il rapporto con l'attuale fornitore senza sostituire il gestionale.
Il passaggio deve chiarire proprietà del codice, accessi, servizi esterni, procedure di rilascio, backup e attività ancora aperte, così che il nuovo sviluppatore possa valutare il sistema prima di assumere responsabilità operative.
Richiedere una prima valutazione
Per valutare un possibile subentro servono alcune informazioni iniziali: funzione del software, tecnologie note, accessi disponibili, soggetti coinvolti, criticità e obiettivi.
Non è necessario disporre già di tutta la documentazione. È invece importante distinguere ciò che è disponibile da ciò che deve ancora essere recuperato.
Richiedere un confronto preliminare
Descrivete il software, le criticità note e gli accessi disponibili. Il primo confronto serve a comprendere il contesto e a verificare se esistono le condizioni per un intervento.