1. Il Change Managemet Applicativo
in ambiente distribuito
POLARION USER CONFERENCE 2010
Badia di Campoleone Green Resort - Capolona (AR)
5 - 6 ottobre 2010
Relatore: Roberto Padello
E-mail: roberto.padello@realemutua.it
Sito Internet: www.realemutua.it

2. Agenda
 Il Gruppo Reale Mutua
 Il contesto organizzativo e tecnologico
 Gli interventi progettuali per il Change
Management
 Possibili evoluzioni
2

3. Reale Mutua Assicurazioni
La più grande assicurazione in forma di mutua italiana
• Reale Mutua Assicurazioni è la più grande compagnia italiana in forma di
mutua, autorizzata ad esercitare tutti i rami di assicurazione.
• Gli assicurati prendono il nome di “soci” e ricevono annualmente, su
delibera del Consiglio di Amministrazione, i benefici di mutualità, ovvero
sconti di polizza per i rami che hanno registrato le migliori performances nel
corso dell’anno precedente.
Dati di Reale Mutua
• Costituita il 31/12/1828: 180 anni di storia
• Sede Centrale: Torino
• 1.235 dipendenti
• 350 agenzie, dislocate su tutto il territorio nazionale
• Circa 1.430.000 soci-assicurati
• 45 C.L.D. (Centri Liquidazione Danni) ubicati su tutto il territorio italiano
3

4. Dati del Gruppo Reale Mutua
Reale Mutua è Capogruppo di un Gruppo Italo – Spagnolo operante
nei settori assicurativo, bancario ed in quelli derivati
• Dipendenti: circa 2.800
• Agenzie: 850 (in Italia)
• Raccolta premi 2009: 3.375 milioni di Euro
• Utile 2009: 43 milioni di Euro
• Margine di solvibilità: 1.500 Milioni di Euro
Le realtà italiane e quelle spagnole sono supportate da due funzioni
informatiche distinte
4

5. Il Gruppo RMA
5

6. Agenda
 Il Gruppo Reale Mutua
 Il contesto organizzativo e tecnologico
 Gli interventi progettuali per il Change
Management
 Possibili evoluzioni
6

7. Struttura della Direzione I.C.T. del Gruppo RMA
Sistemi Informativi
Integrazioni soluzioni IT Architetture
Sicurezza e continuità del
Gestione tecnica contratti
business
Governo IT
Canali di vendita Servizi applicativi Servizi tecnologici
7

8. Struttura della Direzione I.C.T. del Gruppo RMA
Servizi applicativi
Servizi e
Danni Vita Test
amministrazione
Servizi tecnologici
Gestione del
Evoluzione
Esercizio Servizi di supporto cambiamento
tecnologica
e della config.
8

9. Ciclo di vita del software
DEMAND MANAGER SERVIZI APPLICATIVI
Accettazione richiesta Analisi e sviluppo
ESERCIZIO TEST
Modifica in produzione Verifica
GESTIONE DEL
CAMBIAMENTO E
DELLA CONFIG.
Approvazione change
9

10. Ciclo di vita del pacchetto standard
10

11. L’esigenza
MAIN FRAME SISTEMI
DISTRIBUITI
SVILUPPO SVILUPPO
UNIT
UNIT
INTEGRATION INTEGRATION
INTEGRATION
SYSTEM SYSTEM
SYSTEM
ESERCIZIO ESERCIZIO
ESERCIZIO
11

12. Agenda
 Il Gruppo Reale Mutua
 Il contesto organizzativo e tecnologico
 Gli interventi progettuali per il Change
Management
 Possibili evoluzioni
12

13. Gli obiettivi degli interventi effettuati
Gli interventi effettuati si sono basati POLARION, SUBVERSION e
IBM TWS avvalendosi della consulenza di EMERASOFT.
Gli obiettivi perseguiti si possono riassumere in:
• Uniformità del repository dei sorgenti
• Standardizzazione nella messa in produzione degli applicativi sui sistemi
distribuiti
• Incremento della qualità obbligando il passaggio in tutta la filiera di test
• Conformità al modello organizzativo previsto
• Sincronizzazione dei passaggi in produzione tra ambienti diversi (in
corso di realizzazione)
13

14. Fasi progettuali
Sono state avviate, in momenti successivi, due fasi progettuali con
risultati concretamente misurabili:
• La prima fase ha visto la creazione di una banca del software utilizzando
Subversion come unico repository per contenere tutti i sorgenti dei
software applicativi che precedentemente erano dispersi in diversi
contenitori. Questa fase ha messo al sicuro in nostro patrimonio software
anche sul sito di Disaster Recovery.
• La seconda fase, attualmente in fase di roll out, consiste nell’inserimento
in Polarion delle varie applicazioni gestite sull’ambiente distribuito
rendendone il rilascio conforme con il modello organizzativo previsto.
14

15. Come si lavorava prima …
• I sorgenti venivano depositati in vari contenitori, in casi estremi lo stesso
pc dello sviluppatore
• I rilasci in test potevano avvenire in qualunque momento
• Non esisteva alcun modo di mettere in relazioni rilasci su diversi ambienti
e/o applicazioni
• Il rilascio in Esercizio poteva essere effettuato senza il passaggio da test e
non era in alcun modo legato all’attività batch
• Gli ambienti di test erano spesso indisponibili per via dei rilasci in corso
• Il coordinamento del rilascio in Esercizio avveniva solamente per via
organizzativa e non strumentale
15

16. … e come si è lavorato dopo
• I sorgenti sono su un unico repository replicato in sito di Disaster
Recovery
• I rilasci in test avvengono in precisi momenti governati da applicazioni
TWS
• Si possono creare dipendenze e legami tra rilasci di applicazioni anche in
ambienti diversi
• Il rilascio in Esercizio avviene nella finestra notturna coordinato con
l’attività batch attraverso il TWS
• Gli ambienti di test sono stabili
• Il coordinamento dei rilasci viene coadiuvato dagli strumenti
• Il gestore dei rilasci ha sotto controllo la situazione
16

17. Come lo abbiamo fatto
INTEGRATION SYSTEM ESERCIZIO
17

18. Attività su Polarion
• Integration Testing
• Test Waiting for Approval
• System Testing
• Waiting for Test
• Production Deploy
• Test Running
• Test completed | Test Failed
• Closed
18

19. Ruoli e funzionalità assegnate
Sono stati definiti su Polarion alcuni ruoli per la gestione del pacchetto
di rilascio:
• Sviluppatore: può creare un nuovo work item e inserire il deploy e
richiedere il rilascio in un ambiente di test
• Responsabile dell’applicazione: oltre alle fasi precedenti può decidere
di saltare l’ambiente di integration e system e richiedere il passaggio in
esercizio
• Change manager: approva il passaggio nei vari ambienti
19

20. Cosa avviene in pratica
Creazione
pacchetto
Richiesta
Deploy
Approvazione
Deploy
Pronto per
il Deploy
si
si
Deploy OK? Esercizio
Test OK?
no no
Closed Closed
20

21. Cosa avviene in pratica
Creazione
pacchetto
Richiesta
Deploy
Approvazione
Deploy
Il Deploy avviene attraverso il TWS che,
Pronto per
in orari prestabiliti, analizza i rilasci da
il Deploy
effettuare, li raggruppa per application si
server e predispone i task e le
si
applicazioni per realizzare l’installazione.
Deploy OK? Esercizio
Test OK?
Al termine verifica il risultato e lo
no no
comunica a Polarion modificando lo
stato del workitem.
Closed Closed
21

22. Agenda
 Il Gruppo Reale Mutua
 Il contesto organizzativo e tecnologico
 Gli interventi progettuali per il Change
Management
 Possibili evoluzioni
22

23. Esperienze future
• L’introduzione della build con controllo di qualità
• La gestione dei test
• Il collegamento con il sistema di demand e ticketing
• La gestione delle change tecnologiche
• La gestione del CMDB
23