TITULUS - MIGRAZIONE DA VERSIONE 2 A VERSIONE 3

Il presente documento ha lo scopo di descrivere le attività necessarie per il passaggio dalla versione 2 alla versione 3 di TITULUS e TITULUS ORGANI.
Pur non potendo entrare nel dettaglio delle attività di migrazione degli archivi, si ritiene che questa pagina rappresenti un utile strumento tramite il quale elaborare il piano di migrazione di ogni singolo ateneo.

Come noto la versione 3 di TITULUS non rappresenta un semplice aggiornamento di programmi, ma il passaggio ad altra tecnologia e ad altro database. Pertanto, per poter far uso della versione 3 di TITULUS si rende necessario il completamento di un progetto di migrazione.
Di seguito si descrivono le diverse attività necessarie per portare a termine il progetto:

I nostri sistemisti sono a disposizione per verificare i requisiti hardware e indicare le caratteristiche per un eventuale nuovo server, qualora si rendesse necessario un aggiornamento dell’hardware.

I referenti tecnici dell’ateneo concorderanno con i nostri sistemisti le modalità di installazione di una versione perfettamente funzionante di TITULUS 3, con archivi vuoti, su server dell’Ateneo.
La configurazione dell’applicativo (repertori, opzioni attivate, ecc.) rispecchierà quella in esercizio (versione 2).
Ogni eventuale variazione nella configurazione dell’applicativo in esercizio, effettuata dopo questa fase, dovrà essere comunicata a KION per assicurarne il porting sulla nuova versione.
In questa fase si procederà anche a configurare i criteri di autenticazione per far sì che gli utenti autorizzati ad accedere a TITULUS e TITULUS ORGANI possano accedere analogamente anche sull’ambiente di test.

Solo per gli atenei dotati di TITULUS ORGANI
È necessario procedere al porting, di configurazioni e workflow, dalla versione in esercizio alla nuova versione 3 di TITULUS ORGANI.
In pratica saranno riconfigurati tutti gli organi accademici, i relativi componenti ed i modelli usati dall’applicativo per la produzione di ordini del giorno, delibere e verbali.
L’adozione di un nuovo motore di workflow, dotato di designer, rende necessario il ridisegno di tutti i workflow predisposti con la precedente piattaforma (per la gestione dell’iter di approvazione delle proposte).

In data da concordare, successiva al completamento delle fasi precedenti, verranno scaricati su server KION i database di TITULUS (esclusi file associati alla registrazione), per migrare gli stessi alla nuova versione.
Di fatto il contenuto dei database sarà esportato ed elaborato per produrre una struttura XML compatibile con la DTD definita per la versione 3 di TITULUS. I file XML così prodotti verranno inseriti all’interno dei nuovi database di TITULUS, ed indicizzati, quindi saranno eseguite una serie di procedure di controllo volte a verificare la corretta e completa migrazione dei dati.

Una volta completata la migrazione degli archivi e verificato l’esito positivo delle procedure di controllo, si passerà ad una verifica manuale del contenuto degli archivi, compiendo accessi su entrambe le versioni di TITULUS (2 e 3) e verificando a campione la corrispondenza dei risultati ottenuti dalle due interfacce. Questa attività è volta ad individuare eventuali incongruenze non riscontrate dalle procedure automatizzate di controllo, per poterle poi riverificare con queste, a tappeto su tutta la banca dati, una volta individuate e raffinate le corrispondenti procedure.

Completati i controlli automatici ed i test a campione, gli archivi vengono trasferiti sul server di test dell’Ateneo; a completamento dell’attività di migrazione, si procede alla copia dei file associati alle registrazioni dal server di esercizio al server di test, per garantire una verifica anche per le funzioni riferite agli allegati (download, visualizzazione, ecc.).

Messo in opera l’ambiente di test si può procedere alla formazione del personale di ateneo, in merito all’uso della nuova versione di TITULUS.
Di fatto possiamo distinguere fra tre categorie di utenti ai quali proporre differenti programmi formativi:

1. Sistemisti: si propone una giornata di formazione (presso l’ateneo o presso KION) sulla manutenzione e gestione sistemistica della nuova piattaforma (gestione dei servizi, procedure di backup, ecc.);
2. Amministratori di TITULUS: si propone una/due giornate di formazione (presso l’ateneo o presso KION) sulla gestione dell’applicativo;
3. Utenti TITULUS: si propongono due giornate di formazione da due sessioni ciascuna (presso l’ateneo) nel corso delle quali sarà mostrata la nuova versione di TITULUS e saranno evidenziate le differenze funzionali e di interfaccia rispetto alla versione precedente.

In merito a TITULUS ORGANI, possiamo prevedere due ulteriori categorie di utenti:

1. Amministratori di TITULUS ORGANI: si propone una giornata di formazione (presso l’ateneo o presso KION) sulla gestione della nuova versione di TITULUS ORGANI;
2. Utenti TITULUS ORGANI: si propone una giornata di formazione, divisa in due sessioni da mezza giornata ciascuna, nel corso delle quali sarà mostrata la nuova versione di TITULUS ORGANI e saranno evidenziate le differenze funzionali e di interfaccia rispetto alla versione precedente.

L’ambiente di test sarà messo a disposizione del personale dell’ateneo, secondo modalità da concordare con i responsabili applicativi di TITULUS e TITULUS ORGANI. Sull’ambiente di test gli operatori e gli amministratori potranno compiere tutte le prove che desiderano, in quanto i database saranno sostituiti all’atto della migrazione definitiva.
Il periodo di test sarà concentrato in due settimane, trascorse le quali, se non verranno evidenziate particolari problematiche dovute alla migrazione o malfunzionamenti dell’applicativo, si procederà alla migrazione definitiva degli archivi.
Eventuali problematiche relative alla migrazione dei dati saranno risolte con massima priorità per rispettare, se possibile, i termini per la migrazione definitiva concordati con l’Ateneo.

Una volta a disposizione il nuovo server di esercizio, e comunque prima del completamento della fase di test funzionale da parte dell’Ateneo, il personale di KION installerà sul nuovo server di esercizio quanto precedentemente installato e configurato sul server di test (programmi, configurazioni, ecc.).
L’attività di installazione deve terminare con la redazione di un verbale di collaudo nel quale si evidenzia l’esecuzione di una sequenza di procedure standard di collaudo.

Completati i test da parte dell’Ateneo, si procederà alla migrazione definitiva degli archivi. Per ridurre al massimo il tempo di sospensione del servizio di protocollo, si procederà alla migrazione nel corso del primo weekend successivo al periodo pianificato per i test da parte dell’Ateneo.
Di seguito si riporta una proposta di piano temporale delle attività, da verificare e concordare:

N.B.: Solo nel caso di migrazione con TITULUS ORGANI:
è importante che prima della migrazione dei db di protocollo vengano completati tutti i workflow che gestiscono l’iter di approvazione di una proposta. I workflow avviati e non completati saranno infatti annullati all’atto della migrazione. Per ogni proposta rimasta in sospeso sarà comunque sufficiente avviare manualmente uno dei workflow di approvazione configurati in TITULUS ORGANI (ad esempio il workflow associato alle proposte fuori sacco).

In corrispondenza dei primi giorni di avviamento della nuova versione, si propone l’affiancamento di un nostro consulente applicativo. Il consulente sarà a disposizione dei responsabili applicativi di TITULUS e TITULUS ORGANI per assistere gli utenti nelle prime giornate di utilizzo della nuova versione del programma.

Di seguito si riporta un gantt di esempio che descrive un arco temporale adeguato per il completamento del progetto di migrazione, ipotizzando la disponibilità immediata di server di test e di esercizio:

Come si può dedurre dal grafico, si ritiene che, generalmente nell’arco di un mese, possano essere portate a termine tutte le attività necessarie per il passaggio alla versione 3 di TITULUS.

Questo piano di massima sarà soggetto a verifiche con ogni singolo cliente in attesa di migrazione e potrà essere soggetto a modifiche in presenza di situazioni particolari riscontrate presso il cliente stesso.