Modello di Controllo Qualità Applicativa Offerta Assioma.net

Transcript

1 V2.2 Modello di Controllo Qualità Applicativa Offerta Assioma.net Tel / Via Rimembranze, Cesano Boscone (MI) / Via G. Spano, 6/ Torino 2014

2 Benefici Descrizione Servizi Proposti 2 AGENDA

3 Benefici introduzione modello Qualità Applicativa Sviluppo Abbattimento dei costi per: Diminuzione degli interventi di correttiva da produzione Diminuzione dei rilasci in emergenza Miglioramento caratteristiche: Manutenibilità Robustezza Efficienza Sicurezza Contratto di Servizio Miglioramento della gestione dei costi: Dimensione Volumi del Change Technical Debt residuo SLA con metriche oggettive sulla qualità di prodotto 3 - Modello di Controllo Qualità Applicativa Modello Controllo Qualità Applicativa Esercizio Diminuzione dei costi di gestione applicativa per: Aumento efficienza Aumento dell affidabilità Aumento della sicurezza Gestione Fornitori Classificazione Dimensione delle applicazioni Distribuzione per tecnologia Volumi del Change Aderenza a standard Governance Portfolio Dimensione del Portfolio applicativo Distribuzione per Unità Organizzative Distribuzione per tecnologia Volumi del Change Correlazione con altre metriche di gestione del Parco Software: Incident Costo

4 Iceberg Quality la nostra visione Sintomi Visibili Radice Invisibile On-time delivery Difettosità durante il processo di sviluppo Difettosità in produzione Costi di manutenzione Manutenibilità Accoppiamento Flessibilità Leggibilità Riusabilità Complessità Testabilità Program Practice Requirement Validation Acceptance Test System Test Regression Test Integration Test Unit Test Code Review Bug Pattern Analysis Programming Style Tecniche di Intervento Robustezza 34 - Modello Introduzione di Controllo Qualità Applicativa

5 Qualità del coding: i 7 debiti dello sviluppo Bugs potenziali Talvolta gli sviluppatori introducono nel codice potenziali problemi che hanno effetti sulla robustezza e sicurezza dell applicazione Programming Practice Spesso la mancanza di linee guida chiare porta ad avere del codice poco chiaro e scarsamente manutenibile N. Potential bugs Rules Compliance Source Code Complessità Codice troppo complesso è indice di bassa manutenibilità e scarsa testabilità Duplicazioni Spesso il codice viene duplicato per mancanza di tempo o coraggio al refactoring, rendendo poco manutenibile l applicazione %Complexity %Duplication Unit Test La verifica unitaria del codice sviluppato è spesso assente o con livelli di copertura molto bassi, rendendo il codice poco robusto Architettura Talvolta l architettura con la quale l applicazione è stata pensata non viene rispettata con implicazioni sulla manutenibilità Commenti L assenza di commenti rende il codice poco leggibile e scarsamente manutenibile %Unit test Coverage Package Index %Comment 5 - Modello di Controllo Qualità Applicativa 5

6 Continuous Improvement Model High Continuous Improvement Continuous Improvement Typical Use Case: Monitoring and improving the quality of mission critical applications on an ongoing basis Frequency of Use: Analysis on applications is done during development phase, whenever major changes are done to the code base (often daily, weekly or based on the build schedule) Time Frequency Application Assessment Application Assessment Typical Use Case: Assessing or auditing the quality of applications to use as a quality gate, help in portfolio level decisions, or providing visibility to management Frequency of Use: Analysis is done very in-frequently (1-4 times a year) or on-demand Low Supplier Quality Gate Quality Improvement Effectiveness High Supplier Quality Gate Typical Use Case: Evaluating the quality of deliverables from vendors against existing Service Level Agreements Frequency of Use: Analysis is done at every major code drop by the vendor either for Quality Assurance or User Acceptance Testing (QA or UAT) 36 - Modello Introduzione di Controllo Qualità Applicativa

7 Continuous Improvement Model: the best overall value Continuous Improvement Model (daily, weekly) Application Assessment Model (1-4 times/year) Less remediation work: Development teams receive monthly for weekly feedback they internalize and incorporate best practices the first time the code it written, resulting in drastic reduction of new violations introduced Sooner identification of violations, results in cheaper and quicker fixing of violations More frequent analysis and remediation results in less reactive work, more proactive attitude of development teams Increased innovation: Once the initial cleaning is done, ongoing remediation becomes a breeze as there are fewer violations and teams can focus on adding innovative new features for business. More remediation work: Developers forget quickly the mistakes they make and keep reintroducing same errors and violation, unless the best practices are reinforced more frequently If violations are not identified fixed immediately, contexts are forgotten so cost of fixing violations becomes high Remediation effort can be seen as a burden and painful because of the high volume of the piled up defect if the analysis is done only once every quarter or semester Increased developer interruptions: Development teams can spend entire weeks to clean the mess rather than focusing on adding new features daily, weekly Q1 Q2 Q3 Q4 Introduction of new violations Software quality improvement Remediation workload 37 - Modello Introduzione di Controllo Qualità Applicativa

8 Technical Debt Il Debito Tecnico è una metafora per riferirsi alle eventuali conseguenze di uno sviluppo poco curato del software. Il debito può essere pensato come ad una attività che deve essere fatta prima che un progetto possa essere considerato completo. Se il debito non viene sanato, tenderà ad accumulare interessi, il che rende difficile attuare le modifiche in seguito. La non gestione del Debito Tecnico aumenta l'entropia del codice software aumentandone i costi di manutenzione. Il debito tecnico di un applicazione tende a crescere nel tempo se non tenuto sotto controllo, aumentando i Costi legati agli Incident ed alla Manutenibilità 8 - Modello di Controllo Qualità Applicativa

9 Servizi proposti da Assioma.net Assessment Base L Assessment Base consente una verifica una tantum del codice applicativo di una determinata applicazione. Ha l obiettivo di valutare la bontà di una applicazione in un momento qualsiasi. Assessment a Progetto L Assessment a Progetto consente la verifica, durante il rilascio, del codice di una determinata applicazione. Il contesto è pensato per introdurre un Gate di qualità sul codice applicativo durante la fase di Verifica di un progetto software. Nel momento in cui la software factory (interna o esterna), rilascia in ambiente di test, viene pianificata e realizzata un attività di verifica formale del codice sorgente. Le non conformità rilevate verranno segnalate e, durante la fase di test, verrà verificata la chiusura o meno delle Issue aperte Governance Portfolio Applicativo Il servizio di Governance del Portfolio Applicativo consente di mettere sotto controllo un elevato numero di applicazione in modalità Continuous Inspection, ovvero intervenendo per periodi di tempo lunghi, nei quali si vuole mettere sotto controllo l applicazione per verificarne le variazioni rispetto alle metriche di qualità nel tempo. Fornisce informazioni utili al management per conoscere il perimetro e la qualità del proprio Parco Applicativo Modello Introduzione di Controllo Qualità Applicativa

10 Assessment Base L Assessment Base è pensato per una verifica una tantum del codice applicativo di una determinata applicazione. Ha l obiettivo di valutare la bontà di una applicazione in un momento qualsiasi. L Assessment Base prevede: Raccolta e studio dei sorgenti dell applicazione, a seguito incontro con gruppi applicativi del Cliente Configurazione ed analisi del codice sorgente su infrastruttura messa disposizione da Assioma.net Realizzazione di una Dashboard web accessibile da parte del Cliente per 6 mesi, contenente i risultati dell analisi di una specifica versione dell applicazione Realizzazione di un documento di Action Plan contenente le anomalie riscontrate durante la fase di analisi, organizzate e descritte sulla base del modello di qualità SQALE Applicazioni Abstract Syntax Tree (AST) Metriche: LOC, Num Files, Num Classes Complessità ciclomatica Duplicazioni Commenti Regole: Manutenibilità Robustezza Performance Efficienza Portabilità Dashboard online 310 -Introduzione Modello di Controllo Qualità Applicativa

11 Case History: Assessment Base Esigenza del Cliente Attività svolta Obiettivi raggiunti Ad un anno dalla scelta di esternalizzare le attività di sviluppo tramite un processo di outsoucing il Cliente necessita di: un assessment sulla qualità del codice al fine di comprendere i rischi correlati un modello di ottimizzazione dei costi del progetto dare rilievo agli aspetti di Robustezza e Performance valutare un processo di verifica continua su tecnologia JAVA e COBOL Raccolta dei sorgenti e suddivisione degli stessi in aree funzionali Configurazione di un infrastruttura presso Assioma.net in grado di analizzare l applicazione Introduzione nella piattaforma del modello SQALE per la misurazione del Technical Debt sulle applicazioni analizzate Realizzazione di un assessment su una applicazione di oltre 5 Milioni LOC Segnalazione di oltre 50 violazioni di tipo bloccante (in grado di causare crash del sistema) Realizzazione di un Action Plan contenente gli aspetti di maggior criticità presenti a sistema Nell arco di 2 mesi è stato: migliorato il livello della robustezza dell applicazione grazie all individuazione (e successivo fix) di problematiche bloccanti migliorato il controllo del lavoro svolto dai fornitori esterni messo sotto controllo il fenomeno della duplicazione del codice che risultava superare la soglia del 40% Applicazione del modello SQALE per la misurazione del Technical Debt Evidenza delle violazioni bloccanti 11 - Modello di Controllo Qualità Applicativa

12 Assessment a Progetto L Assessment a Progetto consente di verificare la qualità del codice applicativo di una determinata applicazione durante la fase di System Test. E pensato per introdurre un Gate di qualità sul codice applicativo durante la fase di Verifica di un progetto software. Nel momento in cui la software factory (interna o esterna), rilascia in ambiente di test, viene pianificata e realizzata un attività di verifica formale del codice sorgente. Le non conformità rilevate verranno segnalate e, durante la fase di test, verrà verificata la chiusura o meno delle Issue aperte. Contiene le stese attività previste per l Assessment Base, ma per un periodo di tempo più ampio. Baseline a inizio progetto Rilasci in Test Passaggio in produzione, l eventuale TD residuo viene portato come Action Plan per il progetto successivo Rilascio in Produzione 28/08/ /09/ /10/ /11/2013 t Added technical debt: +8 g/u Added technical debt: +6 g/u Added technical debt: 4 g/u Quality Gate Rischio Accettabile? Controllo su Progetto - Fine Sviluppo 12 - Modello di Controllo Qualità Applicativa Controllo su Progetto - iterazioni di Sviluppo Blocco rilascio

13 Case History: Assessment a Progetto Esigenza del cliente IT Attività svolta Obiettivi raggiunti Definizione di un Quality Gate verso il fornitore attraverso l introduzione di più fasi di controllo formale all interno del processo di sviluppo software Assegnazione Evolutiva al FORNITORE Condivisione documento di richiesta Evolutiva Creazione Ticket su TRAC in Milestone Creazione di un Folder/ Branch SVN del codice Condivisione Folder/Branch Evolutiva Versionamento iniziale sul Branch Sviluppo e test Evolutiva Controllo preventivo Commit del codice sul Folder/Branch SVN Invio Action Plan NOT OK NEW Richiesta di Change Midrange SI Rilascio con fermo sistemi? Compilazione Esito NO Controllo formale su Branch NEW Comunicazione ad AMS di fine sviluppo Rilascio in Certificazione OK Condivisione risultati con AVIO Certificazione Comunicazione ad AVIO del rilascio in certificazione Eventuale merge su SVN del codice del Folder/Branch Generazione Action Plan NOT OK Esito Comunicazione ad AMS dell esito della certificazione e formalizzazione della data di rilascio Commit del codice su SVN Rilascio con fermo sistemi? Quality Gate Superato? Richiesta di Change Midrange Rilascio in Produzione Controllo formale Produzione 13 - Modello di Controllo Qualità Applicativa NO OK SI NO NEW Analisi del processo attuale e proposta di un nuovo processo di sviluppo in grado di integrare le fasi di: ~ Controllo preventivo da parte degli sviluppatori sul codice sviluppato ~ Controllo formale sul codice rilasciato prima del passaggio in ambiente di certificazione ~ Controllo formale sull intera applicazione con cadenza bimestrale Configurazione di un infrastruttura in grado di supportarne il processo Definizione di un applicazione (Java, C/C++) sulla quale mettere a punto il processo e relativa analisi della stessa Realizzazione dell Action Plan in grado di indirizzare i miglioramenti qualitativi Estensione di nuove regole custom su linguaggio C/C++ Distribuzione delle linee di codice per competenza Nell arco di 4 mesi è stato: formalizzato il nuovo processo e messa in opera dello stesso all interno del gruppo di sviluppo contenente un Quality Gate in grado di controllare la qualità apportato un miglioramento qualitativo dell ordine del 10% rispetto alla baseline iniziale realizzata una forte integrazione ed interazione con i gruppi di sviluppo KPI per tecnologia JAVA Gate superato se Violazioni Bloccanti e Critiche = 0 Rules Compliance > 80% Commenti (%) > 10% Linee duplicate (%) < 30% Complessità ciclomatica < 10 media per singolo metodo KPI per tecnologia C Gate superato se Violazioni Bloccanti e Critiche = 0 Rules Compliance > 80% Commenti (%) > 10% Linee duplicate (%) < 30% Complessità ciclomatica per < 20 singola funzione/procedura Definizione del Quality Gate

14 Governance Portfolio Applicativo Il servizio di Governance del Portfolio Applicativo consente di mettere sotto controllo un elevato numero di applicazione in modalità Continuous Inspection, ovvero intervenendo per periodi di tempo lunghi, nei quali si vuole mettere sotto controllo l applicazione per verificarne le variazioni rispetto alle metriche di qualità nel tempo. Fornisce informazioni utili al management per conoscere il perimetro e la qualità del proprio Parco Applicativo. App 1 CRM System App 2 App 3 J2EE Environment App 4 Billing System App 5 Order Management System App 6 App 7 App 8 App 9 COBOL Enviroment Tutto il portfolio Dashboard online Possibilità di aggregare il portfolio applicativo a qualsiasi livello e profilarlo per viste utenti differenti Possibili aggregazioni: - Per Tecnologia - Per Sistema - Per Unità di Business - Per Fornitore - App 10 App 11 App 12 App 13 App 14 App 15 App 16 SAP Enviroment.NET Enviroment 314 -Introduzione Modello di Controllo Qualità Applicativa

15 Case History: Governance Porfolio Applicativo Esigenza del cliente IT Attività svolta Obiettivi raggiunti Difficoltà nell individuazione e raccolta organica di metriche legate al Parco Software con conseguente impossibilità di: avere un Controllo della qualità del codice realizzato dai gruppi applicativi definire un modello per la rappresentazione del parco applicativo in termini quantitativi e qualitativi definire un processo in grado di migliorare la qualità abbattendo i costi di licenza di Software poco efficaci nell ambito della Governance Raccolta delle metriche del software già in uso Tuning dell infrastruttura sulla quale basare basare la soluzione a supporto del processo Tuning della piattaforma sulla base delle metriche definite Incontri con i gruppi applicativi al fine di condividere i risultati Implementazione della metrica relativa alla movimentazione del parco software Introduzione di un modello di maturità delle applicazioni in funzione dei livelli di qualità raggiunti Supporto ai run quindicinali sull intero parco software Nell arco dei primi 6 mesi: aumentata l efficienza del processo di governance grazie alla dismissione delle licenze relative ad altri prodotti aumentata l efficacia del processo di raccolta delle metriche con estensione del controllo a tutto il parco software (circa 30 Milioni di LOC) ridotto il tempo di analisi del parco software (da settimane a circa 20 h) introdotto un processo di maturità delle applicazioni basato su diverse soglie migliorato il controllo del lavoro svolto dai fornitori esterni Dashboard aggregate dei sistemi software 15 - Modello di Controllo Qualità Applicativa Modello basato su classi di qualità per la riduzione del rischio Misurazione della movimentazione del parco software

16 I NOSTRI CONTATTI Let s start improving your quality application and reduce risk and cost of software lifecycle!!! Torino Via G. Spano, 6/ Torino Tel Fax Milano Via Rimembranze, Cesano Boscone (MI) Tel Fax Claudio Gaiani claudio.gaiani@assioma.net info@assioma.net