Overview Cloudify NoiPA

Транскрипт

1 Overview Cloudify NoiPA Formazione PPO Febbraio 2018 Realizzato nel quadro del Programma Realizzato Azione nel Coesione quadro Complementare del Programma al PON Azione Governance Coesione e Capacità Complementare Istituzionale al PON Governance e Capacità Istituzionale

2 Abstract Il documento, preparato per la formazione dei PPO (Proxy Product Owner) fornisce un quadro d insieme del programma Cloudify NoiPA. In particolare, vengono descritti l architettura e gli elementi fondanti, la metodologia Agile, le logiche di personalizzazione su servizi, user interface e processi, per concludere con la conformità agli elementi fondanti, alle linee guida e ai requisiti di sistema. 2

3 Agenda High Level Design: Architettura ed elementi fondanti di Cloudify Agile per Cloudify NoiPA Le logiche di personalizzazione su servizi, user interface e processi Conformità ad elementi fondanti, linee guida e requisiti di sistema 3

4 Agenda High Level Design: Architettura ed elementi fondanti di Cloudify Agile per Cloudify NoiPA Le logiche di personalizzazione su servizi, user interface e processi Conformità ad elementi fondanti, linee guida e requisiti di sistema 4

5 Le Main Capabilities Metering Garantire un controllo costante delle risorse impiegate da ciascun client, da gruppi di client e dai singoli servizi Flessibilità e personalizzazione Attraverso l utilizzo di un BPM/BRMS è possibile attivare e personalizzare in self-provisioning i servizi di business disponibili a catalogo secondo le specifiche esigenze delle amministrazioni aderenti. Agilità e scalabilità Assicurare una crescita dell infrastruttura in linea con la diffusione del servizio e garantire un provisioning dinamico delle risorse ("on-demand") in funzione dell utilizzo dei singoli servizi Affidabilità Assicurare la continuità d esercizio valorizzando al massimo le risorse infrastrutturali disponibili e sfruttando la virtualizzazione delle piattaforme Microservizi e API I servizi disponibili all interno del catalogo sono prodotti dell aggregazioni delle funzionalità elementari della piattaforma sviluppate secondo il modello a microservizi e erogati (anche verso l esterno) attraverso una API Platform Cloud Only Sicurezza Garantire la sicurezza mediante un approccio Security by Design. Centralizzazione dei dati, monitoraggio delle risorse e autenticazione distribuita attraverso un controllo degli accessi integrato che sfrutta token rinnovati ad ogni chiamata API. Catalogo Servizi Mediante il Catalogo gli Amministratori degli Enti pubblici locali potranno operare in completa autonomia andando ad acquistare e configurare i servizi di interesse disponibili a catalogo Interoperabilità infrastrutturale Garantire l interoperabilità tra i diversi elementi infrastrutturali (materiali ed immateriali) attraverso logiche di federation con gli Enti Multi-tenancy Possibilità di istanziare servizi allo specifico Ente preservando riservatezza e sicurezza di accesso 5

6 Il Catalogo Servizi Attraverso il catalogo servizi, gli Amministratori degli Enti potranno attivare e configurare in completa autonomia, secondo logiche di self-provisioning, i servizi di Cloudify NoiPA disponibili a catalogo. Macro famiglie dei servizi (in corso definizione) Servizi Built-In Gestione Giuridica Gestione Presenze Gestione Economica Gestione del Capitale Umano Sistema Conoscitiv o Servizi Aggiuntivi Formazion e sui servizi erogati Assistenza (base e premium) Gli utenti dotati del profilo di Amministratore, attraverso il portale di amministrazione del catalogo servizi di Cloudify NoiPA, potranno: Attivare il profilo di servizio ( Service Pack ) dell Ente amministrato andando a selezionare i servizi disponibili all interno dello store oltre che attivare l integrazione di servizi esposti mediante l API Gateway"; Configurare servizi ed API attivi nel profilo di servizio rispetto a specifiche esigenze verticali dell Ente come ad esempio regole di accesso ai servizi o di visibilità sui dati; Personalizzare aspetti legati alla user interface come ad esempio: header, footer, loghi, palette colori, etc. Dotazione di uno strumento di Control Room in grado di centralizzare il controllo e monitoraggio degli Enti Possibilità di personalizzazione grafica e funzionale Possibilità di selezionare i servizi disponibili all interno dello store oltre che attivare l integrazione di servizi esposti 6

7 I Microservizi Il singolo servizio offerto sarà frutto della configurazione di un miniservizio e della composizione di microservizi secondo un processo strutturato e consolidato composto dalle fase di Acquisizione, Alimentazione, Elaborazione, Produzione Artefatti, Estrazione e Fruizione. Lifecycle di riferimento dei microservizi Caratteristiche del microservizio: Versione: identificativo univoco della versione del microservizio all interno di Cloudify NoiPA; Referenced Version: lista degli identificativi delle versioni precedenti del microservizio con relativo change log; Deprecated Version: lista degli identificati delle versioni precedenti del microservizio deprecate; Tempo di dismissione: tempo di dismissione di un microservizio (se deprecato). I microservizi possono essere soggetti a evoluzioni Nel caso in cui le evoluzioni del microservizio comportino delle modifiche alle sarà necessaria la pubblicazione di nuove versioni tra loro indipendenti Le nuove versioni devono essere erogate tramite un endpoint/container dedicato; È necessario che al massimo due versioni siano attive contemporaneamente; Il Service Registry dovrà notificare ai servizi utilizzatori la disponibilità di una nuova versione del microservizio. Il cambiamento di un microservizio non deve avere impatto sugli altri microservizi 7

8 Continuous Integration & Continuous Delivery La piattaforma Cloudify NoiPA si basa su un approccio a microservizi in logica di containerizzazione, prevedendo l integrazione di soluzioni CaaS (Container as a Service) che è in grado di coniugare le capability offerte dalla IaaS e dalla PaaS. IaaS CaaS PaaS Fornisce risorse come Compute as a Service, Storage as a Service o Network as a Service Offre tutti gli strumenti indispensabili per garantire l integrazione tra IaaS e PaaS Fornisce l ambiente indispensabile per lo sviluppo di servizi ed applicazioni Il CaaS permette l adozione della metodologia DevOps, auspicabile per gestire in maniera efficiente ed efficace l intero ciclo di vita di applicazione e servizi in ambito Cloud Computing La metodologia DevOps ha come obiettivo quello di semplificare, standardizzare e automatizzare il processo di sviluppo software sia in termini di Operations che di Developing, attraverso strumenti quali: Continuous Integration Metodologie e processi che automatizzano l integrazione di progetto, ad ogni check-in o ad intervalli schedulati. Le attività ingegneristiche coinvolte sono: controllo codice sorgente, versioning configuration, integrazione continua e testing di unità. Continuous Delivery Metodologie e processi atti al miglioramento continuo del software prodotto. Le attività ingegneristiche coinvolte, oltre a quelle già evidenziate nella fase di continuous integration, prevendono il deploy automatico in ambienti di staging (pre-produzione). Continuous Deployment Metodologie e processi atti a garantire il continuo allineamento degli ambienti di produzione. Le attività ingegneristiche coinvolte, oltre a quelle già evidenziate nella fase di continuous delivery, prevendono il deploy automatico in ambienti di produzione a seguito dei test di accettazione dell utente. 8

9 Agenda High Level Design: Architettura ed elementi fondanti di Cloudify Agile per Cloudify NoiPA Le logiche di personalizzazione su servizi, user interface e processi Conformità ad elementi fondanti, linee guida e requisiti di sistema 9

10 Metodologie di sviluppo: Predittivo vs Adattivo L Agile si presenta come un cambio di paradigma rispetto alla gestione tradizionale dei progetti. «NON PIÙ LO SCOPO COME ELEMENTO FISSO MA IL TEMPO ED I COSTI» APPROCCIO PREDITTIVO Waterfall APPROCCIO ADATTATIVO Agile Scope fisso (Requisiti) Qualità Costi (fissi) Qualità Scope stimato (Features) Tempi (fissi) Costi (stimati) Tempi (stimati) LEGEND: Parametri Vincolati Parametri Stimati L approccio predittivo, utilizzato nei progetti tradizionali, prevede di costruire un pezzo per volta in forma già definitiva. Tale approccio richiede la perfetta conoscenza del risultato finale, ogni rework richiederà la rilavorazione del prodotto finito. L approccio adattativo, proposto per i progetti agile, prevede di costruire il prodotto non avendo ancora definiti i dettagli all avvio del progetto. Tale approccio consente di elaborare la versione finale in corso d opera attraverso l interazione frequente con tutti gli stakeholder. Approccio Predittivo Approccio Adattivo 10

11 Prerequisiti per il successo di un progetto AGILE Agile si propone di scomporre la complessità di progetto in una serie di piccoli item che possono essere affrontati e risolti in maniera più efficiente. Affinché un progetto Agile abbia successo è necessario un forte coinvolgimento di tutti gli attori coinvolti. 1. LA BASE Coloro che operano all interno del progetto in maniera significativa (Scrum Master, Product Owner, team di sviluppo) Devono credere nel progetto e nella nuova metodologia, cercando di supportare gli stakeholder nella comprensione della metodologia Agile. In alcuni contesti operativi è necessario adeguare la metodologia Agile alle esigenze del contesto, ma più che assorbire passivamente le richieste è necessario far sì che l Agile venga recepito. 2. LA COMMITTENZA I responsabili delle varie aree dell organizzazione, che impegnano parte del loro capitale nei progetti per ottenere al più presto i benefici attesi La committenza deve poter vedere i primi risultati tangibili dei primi sprint al fine di fornire le garanzie di raggiungimento degli obiettivi. 3. LA DIREZIONE I primi livelli aziendali, focalizzati nel mettere in atto i progetti necessari al conseguimento della strategia desiderata e nel dirimere i conflitti di priorità tra le varie iniziative. La Direzione è orientata al business e l adozione di un progetto Agile deve poter fornire le sufficienti garanzie rispetto all approccio di gestione tradizionale dei progetti. 3 Driver fondamentali per il successo: ADATTAMENTO Decidere quali azioni devono essere eseguite nella prossima iterazione, basandosi sui feedback. Inseguire sempre l'eccellenza ISPEZIONE Analizzare approfonditamente (e saggiamente) i risultati delle azioni precedenti, per vedere se hanno raggiunto con successo gli obiettivi pianificati TRASPARENZA Agire come deciso, seguire regole chiare, conoscere le responsabilità di tutti, puntare a obiettivi chiari, comunicare efficacemente, avere libero accesso a informazioni e progressi del progetto 11

12 Best Practice: Sviluppi AGILE Plan Design Plan Design Plan Design Deploy Sprint 1 Test Deploy Sprint 2 Test Deploy Sprint 3 Test Accept Build Accept Build Accept Build PLANNING RELEASE PLANNING MEETING Meeting opzionale da tenersi all inizio di una Release in cui il Product Owner indica la vision del progetto e della release. SPRINT PLANNING MEETING E il meeting di avvio dell iterazione (SPRINT). E composto da due parti di 2 ore ciascuna. Prima parte: Il Product Owner descrive le storie in ordine di priorità. Il team di sviluppo, sulla base degli sprint precedenti seleziona le storie da implementare. Qualora siano presenti nuove storie o sia necessario si procede alla stima fine delle storie Seconda parte (riservata al team di sviluppo) il team scompone le storie in task tecnici ai quali assegna una stima in ore. Al termine il team popola la taskboard. Il Product Owner resta a disposizione per eventuali chiarimenti. EXECUTION È il periodo in cui il team di sviluppo effettua i task ed aggiorna il backlog e la burndown chart. Il team lavora sulle storie selezionate per trasformarle in prodotto funzionante rilasciabile. A fine sprint viene rilasciato un «pezzo» di prodotto funzionante. È articolata da due tipologie di eventi: DAILY STAND UP MEETING Tutto il team si trova in piedi ad un preciso orario ed ognuno indica: cosa ha fatto il giorno precedente, cosa farà il giorno corrente quali impedimenti sono stati trovati Durante il meeting non si risolvono i problemi ma li si indirizzano verso lo scrum master. Al termine il team aggiorna la burndown chart BACKLOG REFINEMENT Non ha una durata definita e vi partecipano il Product Owner ed il Development Team. Serve per fornire una spiegazione ad alto livello delle storie per il prossimo sprint effettuando una stima ad alto livello di nuove storie Il meeting può essere usato per un eventuale rivisitazione di stime precedenti a seguito dell esperienza acquisita REVIEW SPRINT REVIEW MEETING Al termine di ogni iterazione il Team di sviluppo mostra, le attività sviluppate al Product Owner, allo Scrum Master, ed a tutti gli stakeholder coinvolti. Al termine dello sprint demo meeting vengono condivisi i dati e le metriche (Burndown chart, Velocità di sviluppo, eventuali bug.) ed i problemi riscontrati. SPRINT REVIEW DEMO La Sprint Review si compone anche della fase di demo, separata da quella del meeting, in cui vengono mostrate tutte le funzionalità implementate sul software funzionante, in cui vengono raccolti i feedback dai partecipanti che possono influenzare lo sviluppo del prodotto. SPRINT RETROSPECTIVE Al termine dello sprint il team e lo Scrum Master si riuniscono per analizzare l andamento dello sprint concluso, cos è andato bene (da ripetere) e cos è andato male (da evitare). 12

13 AGILE in Cloudify NoiPA PLANNING EXECUTION REVIEW Si pianificano la release (a livello di epiche) Si verificano le tempistiche di implementazione della release Si aggiorna la roadmap della release da sviluppare La fase di Execution si articola nello sviluppo di più epiche, ognuna composta da più Feature Feature 1 User Story 1 Task tecnici User Story n Task tecnici Feature 2 User Story 1 Task tecnici User Story n Task tecnici Si esaminano (ispezione) i prodotti dei diversi sprint della release, in particolare si: Collauda il software prodotto nella release (cross sprint) Presenta quanto realizzato Testa la qualità sw (opzionale per Cloudify, test misure di qualità non testabili in Execution come KPI integrazione, coupling ecc.) Rilascia in ambiente collaudo Rilascia in ambiente preesercizio (o esercizio) RETROSPECTIVE Release i Feature n Si analizzano i fattori causali e si identificazione azioni di miglioramento 13

14 Principali Attività Coaching alle attività di pianificazione; Coaching all organizzazione e gestione incontri di approfondimento tra PO/PPO/DevTeam 1 Formalizzazione delle attività di coaching Allineamento sullo stato della configurazione dello strumento di gestione requisiti Definizione e condivisione tempistiche di processo relative all utilizzo delle funzionalità dello strumento Definizione strumenti per tracciatura esiti delle fasi graficate Integrazione dello strumento nei processi di governance e coordinamento delle attività di sviluppo monitoraggio e test Condivisione dei processi, strumenti e best practice da adottare Supportare Amministrazione e Sogei per l allineamneto tra i team di progettazione tecnica/funzionale e i team di sviluppo Coaching su Pianificazione Analisi e Progettazione User-Story ESERCIZIO Superata la fase di staging su ambiente di pre-esercizio la release/sprint viene resa disponibile su ambiente di esercizio ad utente finale. 2 Planning (Sprint-Release) Acquisizione dei EXECUTION Integrazione: Durante la fase di sviluppo grazie, all ambiente di integrazione, oltre ad essere verificate il dialogo con sistemi interni ed esterni verranno eseguite le accettazione FORMALI secondo la DoD. Requisiti Coaching su attività di monitoraggio sviluppi e verifica corretto utilizzo degli strumenti (sistema di gestione dei requisiti, XLS, PPT, DOC ); Coaching all attività di verifica rispetto ai diversi momenti PRE-ESERCIZIO Durante la fase di staging verranno eseguiti tutti i test long-running tra cui: performance test, security & vulnerability assessment, quality assessment, etc... 3 REVIEW Collaudo: Gli sviluppi effettuati, qualora dovessero superare i test sull ambiente di integrazione, verranno resi disponibili sull ambiente di collaudo per i test di accettazione funzionale Coaching all organizzazione e gestione incontri di approfondimento tra PO/PPO/DevTeam Utenti Finali Demand Utenza Amica

15 Agenda High Level Design: Architettura ed elementi fondanti di Cloudify Agile per Cloudify NoiPA Le logiche di personalizzazione su servizi, user interface e processi Conformità ad elementi fondanti, linee guida e requisiti di sistema 15

16 Processo di on-boarding e personalizzazione servizi CONTRATTO COMPARTO CONSOLIDARE DOMINIO INFORMATIVE UTILE ALLA CONFIGURAZIONE SERVIZI Informazioni necessarie per acquisizione, configurazione e attivazione amministrazioni Amm. PROSPECT ACQUISIZIONE INFORMAZIONI AMM. SELEZIONE SERVIZI SELEZIONE PROCESSI E TEMPLATE CONFIGURAZIONE STEP PROCESSO Amm. ATTIVATA Requisiti di Provisioning Requisiti di Processo Granularità di configurazione Identificazione tipologia contratto, comparto e struttura organizzativa Selezione profilo di servizio mediante catalogo (da selfprovisioning eo da operatore) Selezione template di processo in relazione a caratteristiche dell amministrazione. Personalizzazione degli step di processo rispetto a esigenze amministrazione X-1 X-2 X-3 Elementi tecnici configurati AMMINISTRATORE ENTE X-1 X-2 Provisioning Catalogo Servizi Epic/Feature User-Story 16

17 Matrice di configurazione: epica/feature CONTRATTO COMPARTO CONSOLIDARE DOMINIO INFORMATIVE UTILE ALLA CONFIGURAZIONE SERVIZI Informazioni necessarie per acquisizione, configurazione e attivazione amministrazioni Amm. PROSPECT ACQUISIZIONE INFORMAZIONI AMM. SELEZIONE SERVIZI SELEZIONE PROCESSI E TEMPLATE CONFIGURAZIONE STEP PROCESSO Amm. ATTIVATA GESTORE DEL SISTEMA Requisiti di gestione del sistema AMMINISTRATORE CLOUDIFY NOIPA Contratto Comparto Struttura Matrice di Configurazione Epica Feature User-Story Configurazione su userstory e blocchi decisionali Template 1 X-1 Template 2 X-1 X-2 X-3 X-3 A livello di GESTIONE DEL SISTEMA deve essere possibile agire in configurazione abilitando/disabilitando le single user-story definite sul processo oltre che sui diversi blocchi decisionali. 17

18 Matrice di configurazione: user-story CONTRATTO COMPARTO CONSOLIDARE DOMINIO INFORMATIVE UTILE ALLA CONFIGURAZIONE SERVIZI Informazioni necessarie per acquisizione, configurazione e attivazione amministrazioni Amm. PROSPECT ACQUISIZIONE INFORMAZIONI AMM. SELEZIONE SERVIZI SELEZIONE PROCESSI E TEMPLATE CONFIGURAZIONE STEP PROCESSO Amm. ATTIVATA GESTORE DEL SISTEMA Requisiti di gestione del sistema AMMINISTRATORE CLOUDIFY NOIPA Contratto Comparto Struttura Matrice di Configurazione Epica Feature User-Story Livelli Configurativi L1 Ambiti Tipologiche e Varianti Obbligatorietà e Validazione Prerequisiti e Dipendenze L2 Configurazione Workflow Autorizzativi Dati Algoritmi CONSOLIDARE LIVELLO CONFIGURATIVO DI RIFERIMENTO A livello di GESTIONE DEL SISTEMA deve essere possibile agire in configurazione fino a livello della singola user-story in relazione a contratto, comparto e struttura organizzativa dell amministrazione. 18

19 Acquisizione informazioni amministrazione PROVISIONING Amministratore Cloudify NoiPA AMMINISTRATORE ENTE Comparto: Scuola Contratto Applicato segreteria Insegnante Info. 1 Info. 2 Info. 3 Configurazione campi di informazioni per Contratto, Comparto Supplente AMMINISTRATORE CLOUDIFY NOIPA Comparto Contratto Form Scuola Sanità Acquisizione informazioni Amministrazione Applicato Segreteria Insegnante Supplente 1) Scelta comparto 2) Scelta contratto Obbligatorio Dipendente dalla configurazione campi di informazioni per Contratto, Comparto Info Aggiuntive Info. 1 Info. 2 Info. 3 Configurazione informazioni aggiuntive in relazione a Contratto, Comparto 19

20 Selezione Servizi CATALOGO SERVIZI Amministratore Cloudify NoiPA Comparto: Scuola Contratto: Applicato segreteria, Insegnante Catalogo S1 S2 Sn Comparto Contratto Servizi offerti Scuola Configurazione dell offerta Applicato Segreteria S1 S2 Sn AMMINISTRATORE ENTE AMMINISTRATORE CLOUDIFY NOIPA Insegnante Una volta scelto il comparto ed il contratto di appartenenza, l amministratore dell Ente selezionerà dal catalogo i servizi disponibili e compatibili con le configurazioni eseguite negli step precedenti. Servizio Sn Processi Associati Processo A Processo B Processo C Processo n 20

21 Scelta dei template da adottare Selezione processi e template PROCESSO Amministratore Cloudify NoiPA AMMINISTRATORE ENTE Immatricolazione Template Template AMMINISTRATORE CLOUDIFY NOIPA Comparto Contratto Processo Scuola Sanità Selezione processo Applicato Segreteria Insegnante Immatric. T1 T2 S1 P1 P2 T1 T2 T3 T4 In relazione alle configurazione eseguite negli step precedenti l amministratore dell'ente (self-provisioning) o l operatore (provisioning) potranno selezionare solo Processi/Template compatibili. Template 1 Obb. 2 Opz. S1 P1 P2 T1 T2 T3 T4 T5 Nel caso in cui, in relazione alle configurazione eseguite negli step precedenti, non risultino Processi/Template compatibili a catalogo deve poter essere attivato un processo di richiesta estensione del catalogo. 1 3 Opz. 21

22 Configurazione step processo USER STORY Amministratore Cloudify NoiPA Template 1 S2 Template 1 Configurazione Step Template 1 S2 S1 / S1 S3 S3 AMMINISTRATORE ENTE AMMINISTRATORE CLOUDIFY NOIPA STEP1: User-Story x-1 Nome Cognome C.F. Matricola Configurazione STEP1 del Template (logiche di valorizzazione, tipizzazione, ) Configurazione nodo funzionale Configurazione nodo decisionale 22

23 Sidebar Feature 1,2,3 Architettura tecnica a supporto Autenticazione e Autorizzazione Configurazione Personalizzazione Autenticazione e autorizzazione dell utente sulle singole Feature/User-Story configurate, sulla base dei metadata associati ad utente/ente. Sulla base di uno o più template, ogni componente potrà essere configurato sia in termini funzionali che in termini grafici in relazione ai metadata associate al profilo utente/ente. In relazione alle autorizzazione associate al profilo dell utente, verranno abilitate aspetti funzionalit sulle singole feature/userstory. INTERFACCIA (USER-STORY) User-Story x-1 Cloudify NoiPA Header Cloudify NoiPA Header Cloudify NoiPA Header Nome Cognome C.F. 1 Login 3 Body 5 Feature 1 Matricola Feature x Footer Footer Footer X-2 L utente di amministrazione in relazione alle peculiarità dell'ente lavorerà in configurazione sulle «dimensioni» identificate META DATA 6 X-1 X-3 PROCESSO (FEATURE) Componente NON personalizzato Componente Personalizzato

24 Agenda High Level Design: Architettura ed elementi fondanti di Cloudify Agile per Cloudify NoiPA Il modello SaaS per Cloudify NoiPA e le logiche di personalizzazione su servizi, user interface e processi Conformità ad elementi fondanti, linee guida e requisiti di sistema 24

25 Elementi Fondanti La DEFINITION OF DONE (DoD), indispensabile per Validare quanto realizzato a livello di Release, è applicata durante tutte le fasi del processo di verifica (Passaggio in Collaudo, Pre-Esercizio, Passaggio in Esercizio) e costituisce uno Approfondimento Progressivo al fine di garantire un controllo puntuale dei deliverable Realizzati ed Ottimizzare l impegno Delle Risorse coinvolte nel processo di accettazione della release. Il PIANO DI QUALITÀ definisce le caratteristiche qualitative cui dovranno rispondere, per ogni fase del processo, gli obiettivi di Progetto. Piano di Qualità Obiettivo Documentale Software KPIs Release Requisiti di Business Sviluppo Release SPRINT 1,2 e 3 Build & Packaging Congelamento Artefatto Integrazione* Collaudo Pre-Esercizio Accettazione Esercizio Release Documentale Test & Verifiche Software DoD ambiti principali di verifica * Il rilascio su integrazione dovrà essere eseguito solo al consolidamento degli sviluppi e alla certificazione (da parte del fornitore) degli esiti positivi dei test unitari e di qualità Sviluppo Release Verifica e Accettazione Release 25