3 Caso Studio – Realizzazione delle Evolutive di un Software Web Responsive
3.3 La Piattaforma Danni e le Evolutive di Progetto
3.2.2 Le Evolutive di Progetto della Piattaforma Dann
Presentato il quadro generale in cui operiamo andrò ora a spiegare nel dettaglio le attività che mi hanno coinvolto in prima persona; ricordo che la modalità di approccio fa riferimento al V Model presentato al paragrafo precedente. Affinché sia possibile l’implementazione delle funzionalità richieste e necessario documentare quanto analizzato e validato in ciascuna fase di sviluppo; i documenti che io e il mio collega stiliamo sono i seguenti e saranno descritti nel dettaglio in seguito:
• Capitolato e Assunti • Schermate di Navigazione • Analisi Funzionale
• Casi di Test
• Report sull’avanzamento della sessione di testing
Il processo di analisi e sviluppo si innesca in seguito al recepimento mediante mail del Requisito Utente (RU); il RU è un documento word in formato (.docx) così organizzato:
• Front:
o Codice demand - codice identificativo dell’intervento richiesto (es – 123456789)
o Titolo dell’intervento o Compagnia di Riferimento
o Versioni - tabella in cui si tiene traccia di tutte le modifiche apportate al documento, la data in cui è stata effettuata e il referente della modifica • Regole e assunzioni - sezione in cui si delinea ciò che rimane invariato rispetto a
quanto già in essere sul Sulla Piattaforma Danni
• Tipologia di intervento – sezione in cui viene descritto il desiderato dell’utente • Eventuali sezioni aggiuntive a supporto della sezione “Tipologia dell’intervento”
In fig. 37 e fig. 38 sono riportati le sezioni rilevanti estratte da Requisiti Utente pervenuti duranti la mia collaborazione in Accenture:
Caso Studio – Requisito Utente
51 Figura 37: Front Requisito Utente
Figura 38: Estratto da Requisito Utente
Una volta pervenuto il Requisito Utente si dà il via alle attività connesse all’Analisi per soddisfare il Requisito. L’analisi sull’impatti dei diversi servizi delle nuove operazioni, effettuata mediante Brainstorming, viene condotta da me e il mio collega, membri diretti del Cantiere Funzionale (CF) interessati all’implementazione e monitoraggio delle Evolutive di Progetto; talvolta, nel caso di impatti destabilizzanti, viene coinvolto anche il Cantiere Tecnico (CT) per trovare congiuntamente la soluzione in termini di efficienza e di ottimizzazione delle risorse.
Caso Studio -System Design
53 Al termine dell’analisi, le soluzioni identificate vengono riportate nel Documento “Capitolato e Assunti”; il documento è una presentazione PowerPoint formata da una slide inziale in cui sono riportati:
• Codice demand - codice identificativo dell’intervento richiesto (es – 123456789) • Titolo dell’intervento
• Compagnia di Riferimento
Nelle slide successive a quella iniziale saranno riportati invece gli impatti dei servizi necessari per l’implementazione degli interventi richiesti; generalmente per ogni impatto la slide sarà formata da due sezioni:
• Sezione inferiore “Assunti di Stima” – ciò che, con l’implementazione del nuovo intervento, rimane invariato
• Sezione superiore “Capitolato” – sono riportati tutti gli interventi che devono essere effettuati per la realizzazione di quanto richiesto
Il documento “Capitolato e Assunti” contiene la descrizione degli impatti ad un livello alto d’analisi per poter valutare assieme al Cantiere Tecnico la portata degli interventi in termini di tempistiche ed effettuare i primi kick off con tutti i Gruppi di Lavoro coinvolti. Talvolta, sono presenti dei punti aperti (OP.) lato Utente oppure da parte degli owner dei sistemi. In fig. 39 è riportato un estratto del Documento “Capitolato e Assunti” redatto per un intervento rilasciato nella release di Febbraio 2019:
Figura 39: Esemplificativo di Capitolato e Assunti - Documento di sintesi delle analisi condotte
Redatto il documento “Capitolato e Assunti” ci interessiamo poi della pretotipazione della soluzione target identificata, tale documento prenderà il nome di “Schermate di Navigazione”. La pretotipazione viene effettuata mediante il tool Office – Power Point con il fine di emulare la navigazione completa dell’intervento richiesto dall’Utente.
In fig. 40 e fig. 41 sono riportati immagine di dettaglio tratte dal documento “Schermate di Navigazione” di interventi rilasciati in febbraio:
Caso Studio -System Design
55 Figura 41: Slide tratta dall’esemplificativo delle Schermate di Navigazione
I documenti “Capitolato e Assunti” e “Schermate di Navigazione” saranno utili in sessione di Kick Off. Letteralmente kick Off significa “incontro al calcio d’inizio” ed è la prima riunione convocata a monte di nuovo intervento organizzata al termine della definizione del progetto, quando sono stati definiti gli impatti dei singoli interventi per la realizzazione del deliverable richiesto dall’utente. Al meeting partecipa l’utente e tutte le risorse che concorreranno alla realizzazione del progetto, o comunque tutti i responsabili dei vari sistemi che impattano con la realizzazione del deliverable. Il fine dell’incontro è quello di:
• definire gli obiettivi del progetto, le motivazioni e i risultati attesi; • delineare in maniera precisa le responsabilità;
• chiarire eventuali dubbi e informare in maniera dettagliata su come si intende procedere;
• condividere la pianificazione delle scadenze da rispettare in modo da traguardare la release concordata dal cliente;
Le “Schermate di Navigazione” presentate e condivise in sessione di Kick Off potrebbero presentare eventuali punti aperti; i punti aperti sono relativi ad alcuni impatti previsti per i quali ancora sono in corso le analisi per delineare la soluzione migliore a parità di effort.
La sessione di Kick Off si conclude con la validazione della soluzione identificata.
In fig. 42 è possibile visionare un estratto dalle “Schermate di Navigazione” con i punti aperti relativi al richiamo di alcuni servizi al click sul pulsante “Avanti”:
Figura 42: Punti Aperti relativi a soluzioni ancora non definite
Quanto definito in “Capitolato e Assunti” e rappresentato nelle “Schermate di Navigazione” saranno il punto di partenza per la redazione del documento “Analisi Funzionale” in cui sarà espresso in modo formale ciò che è stato definito e pretotipato. L’Analisi Funzionale è quella fase del processo di sviluppo del software, durante la quale vengono identificati e descritti i processi che compongono il sistema informativo analizzato; è l'attività attraverso la quale vengono ottenute le specifiche delle componenti software da realizzare nell'ambito del sistema informatico. Il documento stabilisce cosa è richiesto agli sviluppatori del sistema; definito dal Requisito Utente il “cosa” dovrebbe fare il sistema con l’Analisi Funzionale definiamo il “come” deve essere fatto affinché il sistema soddisfi le richieste dell’Utente.
Più in generale gli obiettivi del documento sono quelli di:
• formalizzare i requisiti di business ed i vincoli progettuali; • elaborare soluzioni di alto livello comprensibili all’utente finale;
Caso Studio -System Design
57 • fornire indicazione agli sviluppatori per poter redigere l’analisi tecnica; • progettare il software/funzionalità che sarà sviluppato;
• essere sufficiente agli sviluppatori per poter implementare il software
In apertura nel documento definiamo lo scopo dello stesso con una presentazione generale degli impatti a livello macro che saranno poi definiti in modo dettagliato nelle diverse sezioni definendo anche gli attori coinvolti nell’implementazione. In apertura è presente anche il Glossario in cui sono definiti tutti i termini tecnici che utilizziamo per facilitare la lettura e la comprensione del documento.
Nel secondo capitolo invece presentiamo in modo più dettagliato ciò che sarà abilitato a valle dell’intervento. Ad esempio, nel caso di un intervento rilasciato a febbraio era previsto lo sviluppo di nuove pagine di navigazione, nel secondo capitolo dell’Analisi Funzionale abbiamo, quindi, definito:
• il layout delle pagine;
• la presenza di stepper – componente utile per orientare l’utente durante la navigazione;
• l’utilizzo di breadcrumb – componente che, sotto forma di un menù orizzontale nella parte superiore del sito, composta dal link alla home page del sito e dai link alla categoria e alla sottocategoria della pagina corrente, permette all’utente di passare da una pagina di navigazione all’altra bypassando la Homepage.
Generalmente il secondo capitolo è suddiviso in più sezioni, nel caso dell’implementazione di nuove pagine, in questo capitolo del documento abbiamo ritenuto opportuno organizzare tanti sotto capitoli quante erano le pagine di navigazione da implementare. Nella sezione introduttiva di ogni sotto capitolo, che prende il nome di “Presentazione Pagina XXX60”, sono riportate le “Schermate di Navigazione” come riferimento per ogni campo e tasto funzionale che andremo ad analizzare in modo formale nelle successive sezioni.
In fig. 43 è possibile visionare un estratto del documento “Analisi Funzionale” relativo alla sezione introduttiva di ogni sotto capitolo:
Figura 43: Estratto del documento “Analisi Funzionale”
Ogni sotto capitolo a sua volta è scomposto in altre sezioni in cui viene definito il Contenuto Informativo di ogni campo presente nella relativa sezione di analisi. Per ciascun campo effettuiamo una descrizione sintetica e definiamo la sua natura. La natura dei campi può essere:
• Label testuale – Campo ipertestuale non editabile;
• CheckBox - Controllo grafico con cui l'utente può effettuare selezioni multiple; • Radio Button- controllo grafico che consente all'utente di effettuare una scelta
Caso Studio -System Design
59 • ComboBox - Controllo grafico che permette all'utente di effettuare una scelta
selezionandola da un elenco
Successivamente per gli stessi campi andiamo a definire se sarà possibile editare eventuali dati inseriti, se la valorizzazione del campo è obbligatoria o meno, in quale momento della navigazione viene visualizzato il campo e definiamo i servizi che devono essere richiamati per valorizzare i campi a Front End; quanto riportato è visualizzabile in fig.44:
Delineato il contenuto Informatico di ciascun campo andiamo ad effettuare l’analisi relativa ai tasti funzionali. Delineano il posizionamento dei tasti nella pagina e l’effetto che si ha alla pressione; con effetto si intende la chiamata ai diversi servizi che viene effettuata alla pressione del pulsante. Per ciascun tasto definiamo, inoltre, i controlli funzionali che devono essere previsti, definiamo quindi quando questi si abiliteranno, quando saranno visualizzati e il loro comportamento al variare della valorizzazione dei campi; quanto riportato è visualizzabile in fig.45:
Caso Studio -System Design
61 L’analisi sopra descritta viene effettuata per i campi di tutte le sezioni.
Nella parte finale del documento invece, in formato tabellare, riportiamo tutti i servizi che saranno richiamati con una breve descrizione per ciascuno e i relativi Owner. I punti aperti emersi in fase di analisi li clusterizziamo e li riportiamo nell’ultimo capitolo del documento “Analisi Funzionale” in modo da tener traccia della chiusura di eventuali punti aperti man mano che essi vengono smarcati.
Redatto il documento “Analisi Funzionale” ci interessiamo della condivisione con il Cantiere Funzionale (CT); la condivisione avviene mediante meeting attraverso l’Applicativo Skype for Business poiché il Cantiere Tecnico, il documento deve essere validato formalmente da parte del CT fornendo la fattibilità di tutti gli interventi. Al termine della riunione carichiamo i documenti “Analisi Funzionale”, “Capitolato e Assunti” e le “Schermate di Navigazione” sullo SharePoint aziendale e definiamo una deadline entro la quale il Cantiere Tecnico deve validare il documento e, in base a quanto definito in “Analisi Funzionale”, fornire la stima (ore/uomo) necessaria per l’implementazione dell’intervento richiesto.
Fornita la stima dai diversi Cantieri (Owner dei servizi) viene fornita la pianificazione di dettaglio e richiesta validazione Utente per poi procedere con lo sviluppo del software. Al termine dello sviluppo si ha la scalata inversa del V Model.
La seconda fase del progetto infatti è dedicata alla conduzione dei test nei diversi ambienti; la sessione di testing è articolata in tre fasi. La prima fase di test viene effettuato dal Cantiere Tecnico (CT) e ha lo scopo di verificare la logica interna del codice garantendo, al termine della sessione, un determinato output dato un input. Conclusa la Sessione dei Test d’integrazione dei diversi Sistemi quanto sviluppato viene rilasciato in Ambiente di
Consolidamento avviando la seconda fase durante la quale io e il mio collega, dopo aver
redatto i casi di test, conduciamo i test Funzionali per assicurare che l’output generato dai sistemi e visualizzato a Front End sia coerente con quanto definito e validato in “Analisi
Funzionale”. Qualora si presentassero delle incongruenze tra quanto definito e quanto
implementato attraverso la piattaforma Application Life Management (ALM) le anomalie vengono segnalate ai referenti del sistema che ha generato errore.
Application Life Management (ALM) è un applicativo che permette di reperire informazioni real time garantendo una forte collaborazione fra i team durante il ciclo di sviluppo e di test del software. Mediante tale applicativo viene descritta l’anomalia riscontrata ed è possibile tracciare lo stato di risoluzione della stessa.
Solo dopo aver concluso la sessione dei test funzionali il Cantiere Tecnico provvede al rilascio in ambiente di Certificazione in cui l’utente sarà coinvolto nella fase di test e, in caso di esito positivo, ovvero, dopo aver verificato che quanto richiesto nel documento “Requisito Utente” sia stato implementato, l’utente certifica l’intervento e quanto sviluppato sarà successivamente rilasciato in ambiente di Produzione.
Durante la sessione di testing io e il mio collega ci interessiamo di:
• garantire supporto all’utente in caso di problematiche interfacciandoci per lui con il Cantiere Tecnico (CT) per indirizzare opportunamente le segnalazioni di eventuali criticità e per garantire una tempestiva risoluzione;
• monitorare lo stato di avanzamento dei test effettuati da noi in ambiente di Consolidamento e quelli fatti dall’Utente in ambiente di Certificazione
• verificare che le anomalie fatte presenti al Cantiere Tecnico (CT) siano prese in carico e risolte nei tempi stimati dagli stessi
Le sessioni di testing sono particolarmente importante poiché eventuali criticità non riscontrata durante questa fase potrebbe riscontrarsi in Ambiente di Produzione compromettendo la bontà degli interventi effettuati. Per evitare problemi infatti si cerca di essere molto minuziosi e di aprire i così detti defect anche per incongruenze che apparentemente sembrerebbero disservizi momentanei; la descrizione di ciascun defect deve essere esaustiva e molto precisa e a supporto nella segnalazione possono essere anche inseriti screenshot in modo da guidare e facilitarne la risoluzione al Cantiere Tecnico. Le anomalie riscontrate vengono assegnate ai referenti del servizio che ha generato l’errore il quale, presa in carico la segnalazione, si impegna a risolvere la criticità entra la Data di Risoluzione da lui stimata e tracciata nell’applicativo ALM.
Durante la sessione di testing io e il mio collega giornalmente stiliamo il report di avanzamento dei test in modo da monitorarlo e per assicurarci che la sessione rispetti la pianificazione condivisa con tutti gli stakeholder.
In fig.46 è possibile visionare un estratto di Report fatto per il rilascio di due funzionalità nel mese di febbraio:
Caso Studio -Stato Avanzamento Lavori
63 Figura 46: Report Stato di avanzamento della sessione di Test
Inoltre, per il monitoraggio dello stato di avanzamento del progetto vengono effettuate riunione periodiche in cui discutiamo con l’utente ed eventuali interlocutori coinvolti in merito allo Stato Avanzamento Lavori del progetto (SAL). I temi trattati sono:
• stato attuale del progetto;
• avanzamento del progetto rispetto agli obiettivi prestabiliti; • rispetto dei tempi e dei costi in relazione agli interventi rilasciati;
• analisi delle criticità emerse per apportare azioni correttive per mitigare il rischio che si ripresentino in futuro;
In vista del SAL si stila il documento in cui vengono riassunti tutti le principali evidenze sullo stato attuale del progetto e i passi futuri ipotizzati. Il SAL è così costituito:
• Executive Summary • Master Plan
Nell’Executive Summary per ogni ambito si delineano le principali evidenze, una breve descrizione dell’ambito in questione con evidenza delle problematiche riscontrate e i necessari interventi richiesti per la conclusione dell’operazione; per ogni ambito è inoltre delineato mediante semaforo lo stato di avanzamento dell’attività:
o Di colore rosso se sono emerse delle problematiche per cui l’attività è in ritardo rispetto la pianificazione;
o Di colore giallo se esistono potenziali minacce che potrebbero implicare problematiche e/o ritardi alla conclusione dell’attività
o Di colore verde se invece non sono previste criticità e se si stima la conduzione delle attività in regola con il paino
In fig. 47 è possibili visionare un estratto dell’Executive Summary dal SAL della Piattaforma Danni:
Figura 47: Executive Summary esemplificativo di SAL della Piattaforma Danni
Nella sezione del Master Plan invece si riporta la pianificazione convalidata e condivisa con tutti i soggetti interessati nella realizzazione dell’applicativo per monitorare la corretta corrispondenza in termini di tempistiche con quanto pianificato a monte.
Caso Studio -Stato Avanzamento Lavori
65 Nell’ultima sezione invece si riportano i report dello stato di avanzamento dei test redatto in data più prossima al SAL sia in ambiente di Consolidamento che in ambiente di Certificazione correlato con le evidenze dei defect presenti in ALM per i quali ancora non vi è una risoluzione.
Il progetto si ritiene concluso quando la sessione di testing in ogni singolo ambiente è terminata e tutti i defect segnalati sono stati risolti.
4 Conclusioni
Scopo del presente documento è stato quello di illustrare l’intero ciclo vita del progetto a cui ho preso parte.
In primis è stato presentato il Settore Assicurativo, dalla nascita ai giorni nostri, analizzando, mediante indici finanziari l’andamento di mercato degli attori più rilevanti nel settore; infine, si è delineato l’approccio quasi forzato del settore alla digitalizzazione e all’Internet of Things. Dopo una panoramica generale è stato presentato il caso di studio di un’azienda leader nel settore assicurativo. Sono state presentate le due metodologie di approccio differenti del processo di sviluppo software adottate nei due filoni progettuali seguiti durante la mia esperienza; si è poi presentata una breve panoramica dei diversi steps abilitanti all’implementazione di un sistema informativo. Sono state in fine descritte nel dettaglio tutte le attività in cui sono stata convolta durante la mia esperienza diretta.
La fase del progetto che mi ha colpito di più è stata la fase a monte, ovvero l’analisi del Requisito Utente; il definire gli impatti sui sistemi già presenti e definire se necessario introdurne dei nuovi; non da meno la fase di testing durante la quale si verifica con mano la realizzazione di ciò che è stato definito da me, dal mio team e dai team ingaggiati nello stesso progetto; la concretizzazione e il frutto del lavoro svolto.
Nel settore Assicurativo, sebbene, vi è una netta segmentazione dei clienti: da una parte i giovani che ricercano sempre più l’esperienza digitale e dall’altra la vecchia generazione radicalizzata nel modo tradizionale dell’erogazione del servizio, sono comunque evidente gli sforzi messi in atto dalle compagnie per adattarsi alla tecnologia. Infatti, nonostante si rilevi una crescita sostanziale di dispositivi, come ad esempio le scatole nere, che permettono di raccogliere dati in merito al comportamento dei clienti, e siano sempre più numerose le compagnie che dedicano un’area del proprio sito web alla gestione delle polizze, vi sono ancora molti aspetti da migliorare. Primo tra tutti, la possibilità di sottoscrivere le polizze direttamente online, senza il tramite di un agente, che, almeno per quanto riguarda i prodotti maggiormente standardizzati, che non richiedono un’attività di consulenza, può realizzarsi senza particolari problemi. Risultano, invece, attualmente piuttosto ridotte le compagnie che offrono questa possibilità, se si escludono le compagnie dirette, che operano esclusivamente attraverso Internet o il canale telefonico. Un altro aspetto senza dubbio migliorabile è quello della qualità del servizio
Conclusioni
offerto, poiché, sebbene le aziende assicurative si siano impegnate nell’offrire un servizio di assistenza ai clienti solido ed efficiente, i siti web risultano, in generale, poco interattivi, così come piuttosto limitate sono le compagnie che offrono prodotti letteralmente personalizzati, se si esclude il settore dell’RC auto. È quindi auspicabile che le imprese assicurative adottino un approccio sempre più rigoroso verso il digitale, se non vogliono essere schiacciate dalla concorrenza e vedere i propri clienti.