Aggiungo: dato che ne ho visti di sistemi smontati e trasferiti su nuove architetture, con brindisi e discorsone a progetto concluso, salvo lancio di coltelli nei giorni successivi...
Fatto il progetto pilota e stabilita l'architettura, penserei a come implementare il nuovo sistema in modo che possa convivere con quello vecchio, in parallelo. Tramite condivisione delle basi dati o replica.
Alcuni utenti continueranno ad utilizzare il vecchio sistema, altri utenti saranno assegnati ad utilizzare il nuovo sistema, segnalare le anomalie e valutare l'impatto sul loro lavoro quotidiano.
Per iterazioni successive gli sviluppatori affineranno e miglioreranno il sistema, in collaborazione con gli lo utilizza, fino ad arrivare a un prodotto perfettamente funzionante e gradito dagli operatori (utenti).
Successivamente il sistema potrà essere migrato dal veccio al nuovo.
Esatto, e' proprio quello che ho suggerito, da avviare dopo avere risolto le perplessita' di base.
Ha un nome specifico una interazione di questo tipo (scrum,agile,lean software development.....) ?
Vorrei fare bella figura con il mio amico.
....salvo lancio di coltelli nei giorni successivi...
Dovrei essere quello preposto ad evitare cio'.
Ed anche poter ricreare artificialmente situazioni particolari che potrebbero non verificarsi durante l'affiancamento
perchè è proprio brutto sentirsi dire :
"sì questo va bene ma c'è quest'altro caso che non succede spesso ... ma può capitare ed il sistema non funziona bene"
... e cominciano a scorrere i brividi di freddo lungo la schiena
E chiaramente ci vuole anche la disponibilità e fattiva collaborazione
degli utenti che devono sobbarcarsi il lavoro sui due sistemi in parallelo
... cosa non scontata neanche questa
E' proprio quello di cui abbiamo discusso l'ultima volta con il mio amico.
La collaborazione dal lato utente c'e', dobbiamo verificare quale potra' essere quella dal lato fornitore perche' di "casi strani" ce ne sono a bizzeffe (l'azienda ha sempre cercato di accontentare i clienti, per cui sono nate nel tempo millemila casistiche differenti).
Ah, vorrei chiedevi se e' una modalita' diffusa.
Non mi risulta sia una regola aurea
Male.
il minimo sindacale sia un fornitore serio ed un cliente che non pretenda un'aragosta per due euro
In questo caso il problema sarebbe solo il fornitore (a volte e' ingolosito dalla commessa e trascura certe difficolta', specie se manda il commerciale a fare una prima analisi).
perchè se gli arriva un foglio scritto dal supermario di qua
che ha parlato solo con il supermario di là rischi di ritrovarti con un sistema
che va bene sul pc di sviluppo ma che si siede in produzione
Ehmm, non capisco cosa tu intenda per supermario, ma io credo che una migrazione del genere si possa fare non tanto scambiandosi fogli ma interagendo di persona tra personale del committente e personale del fornitore.
Aggiungo: dato che ne ho visti di sistemi smontati e trasferiti su nuove architetture, con brindisi e discorsone a progetto concluso, salvo lancio di coltelli nei giorni successivi...
Se non sono indiscreto mi piacerebbe sapere poi come e' andata a finire:il cliente si e' rassegnato o il fornitore ha posto rimedio ?
p.s.
Vorrei fare presente che al mio amico avevo consigliato di crearsi un reparto informatico in house per fare la transizione, piuttosto che affidarsi ad un fornitore esterno.
Credo che sia una soluzione meno veloce, ma alla lunga piu' performante.
Purtroppo non e' riuscito a trovare qualcuno (uno o piu') che avesse le competenze architetturali necessarie (dall'hardware da comprare al linguaggio/framework da adottare) per impiantare da zero la transizione.