Migrazione di applicazioni legacy
Decenni di regole dentro un programma che nessuno sa più leggere.
Le ritroviamo una per una, le portiamo nel programma nuovo, e vi lasciamo la documentazione che non avete mai avuto. Con voi che validate ogni passaggio, non solo il risultato.
Ognuna si chiude con documenti che ricevete e validate, non con un aggiornamento a voce.
Ogni regola del programma vecchio ha un nome e si segue fino al test che la verifica.
La stessa persona vi segue dal primo incontro alla consegna.
Il problema
Perché è ancora lì
Il programma funziona. Fa girare una parte del vostro lavoro, ci passano operazioni vere ogni giorno, e proprio per questo sostituirlo è sempre sembrato più rischioso che tenerlo.
Il punto è che nessuno sa più dire con certezza che cosa fa. Chi lo ha scritto è andato altrove, la documentazione si è fermata a una versione di quindici anni fa, e il comportamento vero — le eccezioni, gli arrotondamenti, i casi particolari aggiunti negli anni — è rimasto scritto solo dentro il codice.
Riscriverlo senza prima averlo capito significa scoprire le differenze in produzione, sulle operazioni dei clienti. È il motivo per cui il progetto viene rimandato di anno in anno.
Il nostro lavoro comincia esattamente da lì: dal ricostruire, riga per riga, che cosa quel programma fa davvero.
Alcune delle tecnologie da cui partiamo
e molte altre: l'elenco non è un limiteIl vostro portale
Non consegnate il programma e aspettate
Il timore, legittimo, è di affidare i sorgenti e rivedere qualcosa solo alla fine, quando ormai o va bene o si ricomincia.
Qui succede il contrario. Ogni fase produce documenti che arrivano a voi mentre il lavoro procede: l'analisi di che cosa fa oggi il vostro programma, il progetto di come sarà fatto quello nuovo, le scelte tecniche, le verifiche. Li leggete e li approvate voi, uno per uno, in un'area riservata alla vostra commessa.
Quando arriva la consegna finale, non c'è niente che vediate per la prima volta.
Come lavoriamo
Sei tappe, e sapete sempre a che punto siamo
Le tappe in oro sono quelle in cui il passo tocca a voi.
Materiali
Ci consegnate il codice e tutto ciò che aiuta a capirlo. Prima di ogni altra cosa lo analizziamo alla ricerca di dati personali rimasti dentro.
Analisi
Ricostruiamo il comportamento reale del programma. Ogni regola che troviamo riceve un identificativo.
Stima
Ricevete tempi e costi documentati, e li approvate prima che si tocchi una riga di codice.
Validazioni
Fase per fase ricevete i documenti sulla logica e sulla tecnologia del vostro software, e li approvate.
Riscrittura
Il programma nuovo viene costruito regola per regola, con i test che verificano ciascuna.
Collaudo
Il vostro personale verifica seguendo i casi di prova che vi consegniamo, con il nostro affiancamento.
L'analisi
Leggere tutto, non a campione
Un sistema di trent'anni può contenere centinaia di migliaia di righe. Leggerle tutte, incrociare ogni riferimento e ricostruire ogni regola è un lavoro che a mano non si farebbe mai per intero: si campiona, si va per priorità, e le eccezioni restano dove sono.
Usiamo strumenti di analisi automatica assistiti da intelligenza artificiale per fare quel passaggio per esteso, con una rilettura completa di controllo su tutto il progetto. Il risultato non è una sintesi: è un inventario.
Le persone restano dove servono davvero — nel decidere, nel verificare, e nel rispondere di quello che viene consegnato.
Tracciabilità
Ogni regola ha un nome, e si può seguire
Ogni comportamento che troviamo nel programma vecchio riceve un identificativo. Quello stesso identificativo lo ritrovate nel progetto del programma nuovo, nel codice che lo realizza, nel test che lo verifica e nel confronto finale.
Se fra tre anni qualcuno chiederà perché il sistema si comporta in un certo modo, la risposta si trova risalendo la catena — e non dipende da chi se lo ricorda.
Che cosa ci serve
Il codice, e tutto quello che lo circonda
Il codice sorgente è il punto di partenza obbligato, perché è l'unico posto dove il comportamento vero è scritto per intero. Ma da solo racconta il come, non il perché.
Per questo prendiamo volentieri tutto il resto: documentazione anche vecchia e incompleta, struttura e dati di esempio della base dati, casi di prova, manuali d'uso, procedure operative, persino note interne e vecchie corrispondenze.
Una nota di quindici anni fa spesso spiega in due righe un'eccezione che dal codice da sola richiederebbe giorni per essere interpretata — e che altrimenti diventerebbe una domanda da farvi.
Più materiale ci date, meno domande vi facciamo e più preciso è il risultato.
Le decisioni
Dove il programma vecchio è ambiguo, decidete voi
Capita spesso, ed è la parte più interessante del lavoro: un arrotondamento che segue una regola non scritta, un controllo che sembra un errore ma forse era voluto, un caso particolare che qualcuno aggiunse per una ragione che nessuno ricorda.
Quando succede, la domanda arriva a voi sul portale: con le alternative possibili e la nostra raccomandazione motivata. Rispondete, la risposta rientra nel lavoro, e resta registrata con il vostro nome e la data.
È quello che vi permette, a distanza di anni, di sapere non solo come si comporta il programma, ma perché.
Alla consegna
Che cosa vi resta
Quello che manca oggi al vostro programma è la documentazione. Non ve lo riconsegniamo con lo stesso problema.
Il programma nuovo
Sulla tecnologia concordata, con il codice sorgente e tutto ciò che serve a compilarlo e metterlo in esercizio.
L'analisi del programma vecchio
Che cosa faceva davvero, regola per regola: il documento che non esisteva.
L'analisi del programma nuovo
Come è fatto e come si comporta, con la corrispondenza puntuale al vecchio.
Il confronto fra i due
L'elenco di ogni differenza rilevata, comprese quelle che avete scelto voi durante il lavoro.
I manuali e i casi di prova
La documentazione per chi usa il programma e l'elenco strutturato delle verifiche per il collaudo.
Il registro delle decisioni
Tutte le domande che vi abbiamo posto e le risposte che avete dato, con nome e data.
Dopo la migrazione
Il programma torna a poter crescere
Per anni ogni richiesta di modifica si è scontrata con la stessa risposta: meglio non toccarlo. Con il programma su una tecnologia attuale e con la documentazione in mano, aggiungere una funzione torna a essere un lavoro ordinario.
Se avete requisiti nuovi rimasti in attesa — un adempimento, un'integrazione, una funzione che serviva da tempo — possiamo affrontarli subito dopo la migrazione, sfruttando il fatto che a quel punto il sistema lo conosciamo a fondo. Oppure può farlo il vostro reparto, o un altro fornitore: la documentazione è pensata anche per questo.
Una cosa che non facciamo durante la migrazione
Non cambiamo l'architettura del sistema. Se oggi è un programma unico, tale
resta: passare a un'architettura diversa — a servizi separati, per esempio — è un
altro tipo di progetto, con altre scelte e altri rischi, e mescolarlo alla
migrazione significherebbe non sapere più a quale dei due attribuire una
differenza di comportamento.
Ma diventa molto più semplice dopo: su un
programma moderno e documentato, il cambio di architettura è un intervento
pianificabile, e possiamo occuparcene come lavoro successivo.
I vostri dati
Dove vanno i materiali che ci affidate
Chi siamo
Un mestiere solo, fatto bene
Migrasoft è il marchio con cui opera WORLDFIN S.r.l.s. Ci occupiamo di una cosa sola: portare applicazioni costruite decenni fa su tecnologie che si possono ancora mantenere, senza cambiare quello che il programma fa.
Il metodo che usiamo non è nato in astratto. È il risultato di una convinzione semplice: in un lavoro come questo il valore non sta nella rapidità con cui si consegna, ma nel fatto che ogni scelta compiuta lungo la strada sia scritta, datata e ritrovabile — da noi come da voi.
Per questo su ogni commessa avete un interlocutore unico dall'inizio alla fine, e per questo la documentazione che vi lasciamo vale quanto il programma.
Domande
Quello che ci chiedono più spesso
Da dove si comincia?
Da una conversazione, poi dai materiali. Con il codice in mano possiamo dirvi quanto è grande il lavoro davvero — cosa che prima nessuno può fare onestamente.
La prima cosa che vi consegniamo è la stima, ed è anche il primo punto in cui decidete se andare avanti.
Quanto costa?
Dipende da quanto è grande e complicata l'applicazione. Chi vi dà una cifra prima di aver guardato il codice sta tirando a indovinare, e lo scoprireste a metà lavoro.
Per questo la stima è un passaggio formale del metodo: la ricevete documentata, la approvate, e solo allora si comincia a scrivere.
Possiamo fermarci dopo la stima?
Sì, ed è previsto. La stima è un punto di uscita naturale: a quel punto avete in mano l'analisi di quello che il vostro programma fa e una valutazione documentata dell'intervento.
Se decidete di non proseguire, quel materiale resta comunque vostro.
Vediamo qualcosa prima della consegna finale?
Continuamente. Ogni fase produce documenti che arrivano a voi mentre il lavoro procede — l'analisi del programma esistente, il progetto di quello nuovo, le scelte tecniche, le verifiche — e li approvate uno per uno sul portale della commessa.
È la differenza fra partecipare alla costruzione e ricevere un risultato a scatola chiusa.
Cambiate anche l'architettura del sistema?
Durante la migrazione no, ed è una scelta precisa. Se mescolassimo il cambio di architettura alla riscrittura, davanti a una differenza di comportamento non sapremmo più a quale dei due attribuirla — e perderemmo l'unica cosa che rende verificabile il lavoro.
Dopo, però, diventa molto più semplice: su un programma moderno e documentato il passaggio a un'architettura diversa è un progetto pianificabile, e possiamo occuparcene come intervento successivo.
Come verificate che il programma nuovo si comporti come il vecchio?
Ogni regola trovata nel vecchio viene collegata al codice che la realizza nel nuovo e al test che la verifica. Alla fine produciamo un confronto puntuale fra i due sistemi, che elenca ogni differenza rilevata.
Il collaudo finale lo esegue il vostro personale, con i casi di prova che vi consegniamo e con il nostro affiancamento: è l'unico modo perché la verifica valga davvero.
Usate l'intelligenza artificiale?
Sì, come supporto all'analisi e alla scrittura del codice, e lo dichiariamo in contratto. L'applicazione che vi consegniamo, però, è software convenzionale: non contiene componenti di intelligenza artificiale.
Nessuna modifica che cambia il comportamento del programma viene applicata senza che una persona l'abbia approvata, e dove serve una conoscenza del vostro lavoro che noi non possiamo avere, la domanda arriva a voi.
Il nostro codice contiene dati reali di clienti. È un problema?
È la norma, e ce lo aspettiamo: nei sistemi con decenni di storia restano quasi sempre dati veri usati per le prove — un IBAN in un modulo di collaudo, un indirizzo in un commento, un codice fiscale in uno script.
Li cerchiamo prima che il materiale entri nella lavorazione e vi diciamo quanti sono e di che tipo. Poi decidete voi come procedere.
Come vi collocate rispetto agli obblighi DORA?
Come fornitori terzi di servizi ICT. Sappiamo che dovete iscriverci nel registro delle informazioni che trasmettete a Banca d'Italia, e vi forniamo i dati che vi servono nei tempi che vi servono.
Il contratto prevede il diritto di accesso e audit vostro e dell'autorità, la notifica degli incidenti, le strategie di uscita e la dichiarazione dei nostri fornitori.
Chi mantiene il programma dopo la consegna?
Potete farlo voi: è esattamente il motivo per cui la documentazione e la tracciabilità fanno parte della consegna, e per cui la tecnologia di arrivo si sceglie insieme al vostro reparto.
Se preferite che ce ne occupiamo noi — per la manutenzione, per nuovi requisiti o per le evoluzioni di cui parliamo sopra — si concorda a parte.
Parliamone
Mezz'ora, e capite se ha senso
Non serve preparare niente: ci raccontate a grandi linee di che sistema si tratta e da quali difficoltà nasce l'esigenza. Il resto lo capiamo insieme.
Scriveteci
info@migrasoft.itRispondiamo entro un giorno lavorativo.
Numero verde
800 034 400Gratuito da tutta Italia.