3 Caso Studio – Realizzazione delle Evolutive di un Software Web Responsive
3.2 Team di lavoro e metriche progettual
In questa sezione sarà presentata l‘organizzazione interna del mio team e i diversi filoni progettuali oggetto di lavoro; sarà delineato lo stato dell’arte, le logiche di approccio dei diversi progetti e i diversi ambienti operativi; successivamente l’analisi continuerà e avrà come focus il progetto a cui mi sono dedicata maggiormente.
3.2.1 Organizzazione Interna del Team e filoni progettuali
Io e il mio team in qualità di cantiere funzionale (CF) seguiamo parallelamente due filoni progettuali relativi all’implementazione di piattaforme digitali al fine di ottimizzare i processi operativi aziendali del cliente:
• Nuova Piattaforma di Servizio – Piattaforma che mediante un’impostazione per working situations e client centric permette l’accesso da un unico punto a tutte le funzionalità commerciali e gestionali
• Piattaforma Danni - Piattaforma, modalità Desktop e modalità Tablet, per l’ottimizzazione delle attività di emissione e le operazioni di post- vendita di polizze assicurative
Internamente il mio team è così organizzato: un Senior Manager e un Manager, garanti di supporto a tutti i membri del team qualora necessitassero, impegnati maggiormente nella supervisione di entrambi i filoni sia a livello economico che organizzativo; due persone impegnate attivamente nelle attività operative del primo filone progettuale, due risorse impegnate sul secondo filone progettuale.
I due progetti non sono a sé stanti, ma uno ingloba l’altro e la fruibilità dei due applicativi è garantita dal richiamare gli stessi sistemi di owner differenti.
3.2.2 Logiche di Approccio dei filoni Progettuali
Le logiche di approccio dei due progetti sono completamente differenti. Il primo presente alla base un approccio di tipo più innovativo denominato Design Thinking il secondo, invece, un approccio più tradizionale: il V Model.
3.2.2.1 Design Thinking
Il Design Thinking è un metodo innovativo utilizzato per il progetto della Nuova
Piattaforma di Servizio; focus di questa metodologia sono le persone invece che i prodotti,
i servizi, i processi o l’organizzazione; questo perché quando le persone sono al centro, si ha la possibilità di scovare nuove opportunità, generare idee creative e progettare soluzioni che creano valore sia per le persone che per le imprese. Si cerca, mediante osservazioni dirette, di capire le esigenze degli utenti. Le esigenze degli utenti vengono poi trasformate in modo formale in bisogni e successivamente vengono definite le caratteristiche tecniche necessarie a soddisfare il desiderato dagli utenti. Le caratteristiche tecniche possono esse antitetiche oppure possono presentare problemi tecnici in fase di sviluppo, per questo dopo aver delineato i possibili problemi si passa poi ad esaminarli da punti di vista differenti e, mediante brainstorming, si considerano le ipotetiche soluzioni. Le possibili soluzioni vengono rappresentate in modo tangibili mediante prototipi per recepire feedback dagli utenti stessi. La suddetta metodologia di progettazione può essere applicata in molteplici ambiti, dal processo di sviluppo software alla realizzazione di un prodotto fisico. Tale approccio è dinamico e a differenze di altri approcci non esistono delle metriche definite da seguire ma esse variano in base al tipo di problema. Il processo quindi non è rigido ma piuttosto sfasato, una fase potrebbe non necessariamente essere eseguita nell’ordine prestabilito. Il processo in linea di massima potrebbe essere definito come in fig. 29:
39 3.2.2.2 V Model
Il V Model, invece, utilizzato per il progetto relativo alla Piattaforma Danni, è una metodologia tradizionale per il processo di sviluppo software; è un processo strutturato in una sequenza lineare di fase che si riversano a cascata l’un l’altra ed ogni fase produce un output che viene usato come input per la fase successiva. La prima fase è il
Requirements Analysis in cui si definiscono e si analizzano i requisiti del sistema. In questa
fase viene stabilito ciò che il sistema dovrebbe idealmente compiere è ciò che l’utente desidera, ma non viene ancora delineato come il processo sarà implementato; il documento in out-put a valle di questa fase è il “Requisito Utente”.
Nella seconda fase, System Design, partendo dal “Requisito Utente” il Cantiere Funzionale (CF) da inizio alla fase di analisi del requisito; vengono delineate le possibili soluzioni per soddisfare il desiderato dell’utente e si valutano gli impatti dei servizi dell’intero sistema. Eventuali problemi legati all’impossibilità di soddisfare i requisiti vengono comunicati all’Utente e si cerca di mediare e di trovare una soluzione condivisa. Al termine di questa fase sarà redatto il documento di “Analisi Funzionale”; in altre parole l’Analisi Funzionale coincide con la stesura della specifica dei requisiti e servirà come piano architetturale per la fase di sviluppo per il Cantiere Tecnico (CT). La specifica dei requisiti può essere affiancata da documenti a supporto contenenti anche pretotipi54, per migliore la comprensione del sistema. In questa fase vengono inoltre redatti documenti contenenti le specifiche per i test di sistema a livello Funzionale.
Fase successiva è quella della progettazione dell'architettura hardware e software,
Architetture and Module Design; in questa fase si realizza tutto ciò che è necessario per
definire l'elenco dei moduli, la funzionalità in breve di ogni modulo, le loro relazioni di interfaccia, le dipendenze, le tabelle delle basi di dati, i diagrammi architetturali ed i dettagli relativi alle tecnologie da usare. In questa fase vengono progettati i test di integrazione di ciascun modulo. La specifica di programma, o documento di progettazione di basso livello, conterrà: la descrizione funzionale dettagliata dei moduli scritti in pseudocodici, le tabelle di database con tutti gli elementi, compresi il loro tipo e dimensione, tutti i dettagli delle interfacce con i riferimenti completi delle Application
Programming Interface (API55). In questa fase viene sviluppata la progettazione dei test di
54Pretotipo: rappresentazione fisica di un’idea, per aiutare l’ideatore nel decidere se e come portare avanti l’idea o per
validare l’usabilità di un prodotto/servizio; realizzato ancora prima della fase di sviluppo e della realizzazione di un prototipo 55 API: Application Programming Interface, sono un insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l’espletamento di un determinato compito all’interno di un certo programma; permettono agli sviluppatori software di accedere a determinate funzioni o dati, altrimenti inaccessibili. Le API sono quindi un’interfaccia per programmatori
unità. Definito nel dettaglio ciò che deve essere programmato per soddisfare il requisito dell’Utente si dà inizio alla fase di codifica, Coding, ovvero all'implementazione dei moduli. Successivamente, si effettuano i test di verifica, Unit testing, metodo mediante il quale le singole unità di codice sorgente vengono testate per determinare se sono idonee per l'uso. I test sono condotti dai programmatori e lo scopo è quello di verificare la logica interna del codice. Una volta effettuati i test sui singoli moduli si passa ai test di integrazione gli ISTT, Integrators of Systems Technology, il cui scopo è quello di individuare eventuali errori nelle interfacce o nell'interazione tra componenti integrati. Conclusi la fase di testing di componenti e moduli condotti generalmente dal Cantiere Tecnico (CT) si passa alla fase di testing di sistema, System testing. La sessione di test di sistema, così chiamata poiché i test vengono eseguiti su un sistema completo e integrato, ha lo scopo di valutare la conformità del sistema con i requisiti funzionali definiti nel documento “Analisi Funzionali”. Il testing viene effettuato dal Cantiere Funzionale (CF) e non richiede alcuna conoscenza del design interno del codice o della sua logica. In linguaggio tecnico questa sessione di test è chiamata ISTF, Integration System testing functional. Superato il test di sistema si giunge all’ultimo step: il testing di accettazione gli UAT, User Acceptance Testing. Sessione di test condotta dagli Utenti, è la fase di test utilizzata per determinare se un sistema soddisfa i requisiti specificati in fase di analisi dei requisiti e tracciati nel documento “Requisito Utente”. Questa è la fase utilizzata dal cliente per determinare se accettare o meno il sistema.
Il processo del V Model è raffigurato in fig. 30:
41
3.2.3 Ambienti di Sviluppo Software
Ciascuna attività descritta nella presentazione delle due metriche utilizzate nell’ approccio di progetto generalmente è svolta in diversi ambienti di sviluppo software allestiti per scopi diversi; ho deciso di riportare una breve panoramica dei diversi ambienti utilizzati e dei relativi team che ne garantiscono la bontà.
È possibile differenziare cinque diversi ambienti: Ambiente di Sviluppo - S, ambiente a monte di tutto il processo, in cui il Cantiere Tecnico (CT) rilascia tutto ciò che è stato programmato in locale ed effettua i test unit (ISTT – Integration System Testing Technique) per garantire la bontà della logica interna del codice; una volta superati i test unit quanto sviluppato viene rilasciato in Ambiente di Consolidamento – K in cui il Cantiere Funzionale (CF) effettua i test di Sistema (ISTF – Integration System testing functional) per verificare che quanto sviluppato sia conferme a quanto redatto in “Analisi Funzionale”. Al termine del superamento dei test di sistema si effettua il rilascio in Ambiente di Certificazione - C in cui gli Utenti svolgono i testi di Accettazione (UAT – User Acceptance Testing). Terminata anche questa sessione di test quanto certificato si rilascia in Ambiente di Produzione - P, il rilascio in produzione coincide con il Go Live e la seguente distribuzione alla rete che usufruirà del software certificato. Il Go Live può anche essere sfasato ovvero il cliente può decidere di rendere fruibile quanto sviluppato ad un numero ristretto di agenzie le cosiddette “Agenzie Pilota” e solo quando la funzionalità sarà totalmente fruibile e a regime non saranno riscontrati problemi l’applicativo si rende fruibile anche alle restanti agenzie operanti. L’Ambiente di Maintenance – M, invece viene utilizzato in seguito ad Incident56 riscontrati in Produzione, i quali necessitano di una risoluzione immediata per cui si sfugge alla burocrazia architetturale e si effettuano rilasci direttamente in ambiente di M; Utenti, Cantiere Funzionale e Cantiere Tecnico lavorano ed effettuano test congiuntamente per risolvere l’anomalia riscontrata nel minor tempo possibile.
I diversi ambienti e i team operanti in ciascuno sono raffigurati in fig. 31:
56Incident: problemi riscontrati in ambiente di Produzione, che prescinde dalla definizione del Requisito Utente o dai
Figura 31: Organizzazione Ambienti di sviluppo