Introduzione di nuove logiche di

Transcript

1 Introduzione di nuove logiche di Romano Brida Venezia Mestre, 6 Ottobre 01 1

2 Obiettivi del documento Presentare l'approccio NTT DATA al Performance & Quality Management lungo il ciclo di vita del software Condividere evidenze raccolte su alcuni casi svolti sul campi e i principali punti di attenzione

3 : La gestione della produttività PER DISCUSSIONE Storicamente le imprese gestiscono le tematiche legate alla produttività in base a tre paradigmi: L effort necessario viene stimato in giorni uomo da erogare: in base alle esperienze precedenti o omogenee per complessità viene stimato un carico di lavoro emergente, senza valutare il potenziale errore dovuto proprio alle esperienze La produttività è funzione solo della presenza fisica delle risorsa: ogni risorsa viene equiparata ad un valore del 100% senza considerare la sua reale produttività intrinseca o i possibili ambiti di challenge verso il Fornitore Il valore della produttività è il costo della risorsa: la risorsa viene considerata un costo quando si trova fisicamente nell ambito operativo per cui è stata ingaggiata In contesti di mercato altamente competitivi e con dinamiche strutturali di riduzione dei margini, la ricerca di livelli di servizio adeguati non può restare ancorata a logiche poco flessibili e standardizzate, con obiettivi legati al costo unitario e non al valore complessivo di erogazione

4 : Ambiti di implementazione PER DISCUSSIONE 1 Tattico - Approccio contingente a situazioni critiche su aree applicative - Intervento con obiettivo diagnostico e definizione aree di risoluzioni criticità in modo puntuale - Diversi possono essere gli ambiti di Monitoraggio terze parti - Approccio finalizzato al monitoraggio costante e strutturato di terze parti (fornitori, outsourcer) - Interventi finalizzati al mantenimento di competenze all interno anche su aree applicative esternalizzate azione di nuove logiche di misurazione della produttività - In base all ambito di azione identificato, diversi saranno gli impatti sull organizzazione aziendale e i Centro di Qualità - Approccio finalizzato alla creazione di unità interna dedicata al miglioramento della Fabbrica del Software - Intervento finalizzato sia verso le risorse interne che potenziali partner esterni tempi di messa a regime del modello 4

5 : Considerazioni sugli obiettivi del monitoraggio qualità Ambiti di azione Obiettivi monitoraggio PER DISCUSSIONE Nuovo Sviluppo Aderenza Standard Qualitativi - Definire standard qualitativi per ogni nuovo sviluppo software, con la possibilità di introdurre a livello contrattualistico un allegato tecnico che specifica il livello di servizio atteso dal fornitore - Individuare metriche per la misura della qualità del software (nuovo sviluppo) in base a tipizzazione delle applicazioni (target vs. tattiche) e classi di violazione Change Management Monitoraggio Regressioni - Garantire la non regressione della qualità del software a fronte delle modifiche effettuate - Definire delle soglie minime di accettabilità per le classi di applicazioni individuate (target vs. tattiche) Continuous Improving Individuazion e azioni di miglioramento - Garantire un supporto al miglioramento del software particolarmente critico rispetto all importanza dell applicazione - Correlare le indicazioni emergenti dai processi ITSM (p.es. Incident Management) con la storia e il percorso di sviluppo dei diversi ambiti applicativi 5

6 Approccio evolutivo monitoraggio della qualità Software Development Life Cycle Requisiti & Analisi Sviluppo Test Rilascio Manutenzione Performance & Quality Management Miglioramento qualità 1 Monitoraggio Qualità e Performance SW 1 - Il Monitoraggio del SW si avvia a valle dello sviluppo/rilascio in produzione, in questa fase la versione software in produzione viene aggiornata con le metriche / soglie correlate - Le metriche sono diversificate in base alle caratteristiche dell applicazione (target o tattica): - Applicazione Target, il cui obiettivo è definire un percorso di miglioramento continuo - Applicazione Tattica, il cui obiettivo è il monitoraggio del non degrado dell applicazione e attivare azioni di mitigazione - Momento formale di controllo e accettazione del software sviluppato e pronto alle fase di test - I parametri vengono segmentati in base a due caratteristiche - Bloccanti per il rilascio: livelli che non posso essere al di sotto di un certo valore - Alert non vincolanti per il rilascio: segnalazioni che in base alle caratteristiche dell applicazione (tecniche, funzionali) evidenziano un livello più basso della soglia di accettabilità ma non bloccano il rilascio - Al fine di creare un percorso proattivo verso le fabbriche di sviluppo (interne o esterne all organizzazione), si possono rilasciare strumenti di simulazione del livello qualità del software già durante le fasi di sviluppo - I diversi gruppi di produzione potranno così simulare / verificare lo stato: il monitoraggio della qualità deve essere percepito come un reale supporto e non come un audit - Obiettivo finale del processo è anche sensibilizzare le fasi immediatamente precedenti allo sviluppo (es. formalizzazione requisiti) 6

7 : Valutazione posizionamento e percorso di crescita METODOLOGICA Qualità Rilevata* * Alta Bassa - Produttività da monitorare - Valutare azioni di revisione modello operativo Bassa Ambito obiettivo - Qualità da migliorare - Valutare azioni di revisione del modello di produzione e QA Alta Produttività Rilevata** Qualità rilevata: definita tramite strumenti di misurazione con CAST ** Produttività rilevata: Function Point gestiti da un FTE in una anno; la valutazione viene fatta su Centri di Competenza o Gruppi di Lavoro (non sulla singola risorsa) Al fine di migliorare progressivamente l effort correlato alla gestione delle diverse applicazioni, si propone un monitoraggio periodico basato sull analisi di 4 dimensioni: 1. Produttività per la singola Applicazione misurata in base a: Sizing dell Applicazione (p.es. in Function Points) N di Risorse mediamente impegnate per la gestione dell applicazione. Qualità Tecnica fornita dalla Dashbord di CAST. Livello di Servizio : misurato sul N di difetti per migliaia di Function Points (Defect Density), rilevati nell anno precedente al momento della misurazione 4. Strategicità Applicazione : Definita come l importanza dell Applicazione in base all esigenza di erogare servizi di diversa importanza strategica a specifiche aree di Business / Clienti Rappresenta la quarta dimensione di analisi a supporto delle decisioni dei Responsabili del Parco Applicativo, che potranno stabilire le priorità di intervento (p.es: applicazioni strategiche / in dismissione) nell ambito di iniziative / progetti, volte ad innalzare le performance delle applicazioni 7

8 Qualità Tecnica (TQI)* : Considerazioni sul modello di monitoraggio CASE HISTORY ** Applicazione Tattica * TQI 1. Inaccetta : bile ApplicazioneTarget. A rischio;. Accettabil e 4 4. Eccellent e; 1 Q 4 DD : 9 Q Applicazione 1 Defect Density: (N Incident / FP).957** Target Zone* Applicaz. DD : 8 Productivity Target Zone:.957 FP/Fte (Fonte Gartner) Produttività (FP/FTE) *** Defect Density Benchmark : 9 Inc./FP (Fonte Gartner) Dato disponibile solo al momento del rilascio della versione N+1 **** Q 1 Applic. Q DD: **** - L Applicazione 1 (strategica) risulta la più scadente in termini di prestazioni: - Qualità Tecnica compresa tra la soglia di rischio e la soglia di accettabilità - Produttività inferiore alla media dell Area; - Defect Density inferiore alla media di Area - Alcune considerazioni di metodo : - La Target Zone è un ambito obiettivo che permette di evidenziare anche casi di eccessiva varianza positiva: nel caso dell applicazione la produttività risulta eccessivamente alta (potenziale errore nella consuntivazione dell effort) - In organizzazioni particolarmente strutturate, il Benchmark di mercato risulta essere un punto di partenza per valutare le diverse aree operative: in un contesto a regime è la stessa organizzazione che definisce Benchmark interni in base ai casi migliori presenti - Al fine di evitare errori nella stima della produttività, i Function Point sono valutati al netto del codice morto e del codice non utilizzato negli ultimi 18 mesi 8

9 : Punti di attenzione CASE HISTORY Nei casi evoluzione del Gruppo di Lavoro o presa in carico di applicazioni da parte di un altro fornitore si devono considerare alcuni punti di attenzione Valutare l impatto sulla qualità percepita dall utente di business - Disservizi di natura funzionale possono innescare nell utente di business la sensazione di un degrado progressivo della qualità del servizio erogato (al di là del reale livello di qualità effettiva del software ) - Dalle analisi eseguibili con CAST indicatori che possono fornire elementi in quest ambito sono sicuramente Robustness, Perfomance e Security Valutare la sostenibilità delle applicazioni nella gestione a medio termine - La presa in carico di applicazioni risulta sostenibile (anche per azioni di miglioramento o riscrittura di parti del codice) in presenza di regole e documentazione a supporto - Dalle analisi eseguibili con CAST indicatori in che possono fornire elementi in quest ambito sono gli indicatori primari Trasferability e Changeability, e i secondari Programming Practices, Architectural Design e Documentation 9

10 : Punti di attenzione Qualità percepita dal Business App. A App. B App. C Size (LOC) 1,600,000 60, ,000 CASE HISTORY Driver primari Transferability,,88,78 - Robustness: per quanto riguarda la facilità di introdurre malfunzionamenti a fronte di modifiche, sicuramente Changeability,0,66,79 App. C evidenzia un rischio alto e App. A e App.B un rischio moderato Robustness,04,14,9 - Performance: App.B e App.C risultano con un rischio Performance,67,66,9 alto e App.A con un rischio moderato per quanto riguarda la possibile presenza di colli di bottiglia che Security,11,8 1,6 possono determinare un peggioramento dell applicazione Driver secondari Programming Practices,07,77,77 - Security: App.C risulta con un rischio molto alto, App.B con un rischio alto e App.A con un rischio moderato per Architectural Design,56,4,7 quanto riguarda la fragilità di una applicazione in ambito sicurezza (soprattutto se applicazione di rete Documentation,6,9,17 con utenti naviganti che accedono direttamente da internet) 10

11 : Punti di attenzione Sostenibilità nella gestione a medio termine Driver primari Transferability Changeability Robustness Performance Security Programming Practices Architectural Design Documentation App. A,,0,04,67,11,07,56,6 App. B,88,66,14,66,8,77,4,9 App. C Size (LOC) 1,600,000 60, ,000 Driver secondari,78,79,9,9 1,6,77,7,17 - Trasferabily: per quanto riguarda la possibilità di presa in carico efficace dell applicazione da parte di un nuovo gruppo di lavoro, App.B e App.C risultano avere un rischio alto mentre App.A un rischio moderato - Changeability: rispetto la facilità di modificare velocemente l applicazione, App.B e App.C risultano avere un rischio elevato e App.A un rischio moderato - Programming Practices: riguardo gli standard di programmazione App.B e App.C risultano con una potenziale alta complessità di gestione e App.A moderato/ tendente all alta: impatto correlato riguarda i tempi per la sistemazione di anomalie - Architectural Design: riguardo il rispetto di standard architetturali / applicativi, App.B e App.C risultano avere un alto scostamento rispetto alle Best Practicies di mercato - Documentation: per quanto riguarda la conformità con il naming/style convention e a quantità di righe di commento presenti, App.B e App.C risultano con un alto scostamento rispetto gli obiettivi attesi (in ogni caso risulta da verificare la presenza di documenti tecnici sostitutivi) CASE HISTORY 11

12 1 : Considerazioni sul piano di implementazione Assessment Applicazioni - Al fine di ottenere una prima valutazione di size applicativa complessivamente gestita - Quest azione non deve per forza essere svolta con strumenti articolati/profondi come CAST ma anche con altre soluzioni più leggere che diano indicazioni di minima sulle caratteristiche delle applicazioni in termini di volumi (LOCs) e tecnologie METODOLOGICA Individuazion e Applicazioni Target Processo Performance & Quality Management - In base alle evidenze emerse in fase uno e secondo le indicazioni dei diversi Stakeholder, sarà fatta una categorizzazione e classificazione del parco applicativo - Su queste evidenze sarà fatta una selezione delle applicazioni critiche e/o coerenti con il processi di monitoraggio performance (p.es. che non verranno sostituite a breve termine, servizi utilizzati da più applicazioni target, applicazioni core, ) - Pianificazione di dettaglio dei tempi necessario per le valutazione e dei momenti di condivisione e valutazione evidenze con gli Stakeholder di riferimento per le singole applicazione - Avvio del processo di definito, rilevando in corso d opera eventuali punti di attenzione e criticità volti a migliorare il processo stesso - Validazione dei risultati emergenti con gli Stakeholder e identificazione di possibili azioni correttive volte a migliorare le evidenze emergenti (qualità, produttività, ) 4 Presentazione evidenze - Le evidenze emergenti verranno presentate al Management al fine di - Condividere approccio e lesson learned (in logica di miglioramento continuo) - Indirizzare coerentemente le possibili aree di miglioramento in ottica sia di processo che di standard/metodologie di produzione 1

13 : Lesson Learned PER DISCUSSIONE - Il percorso di introduzione del processo di monitoraggio performance/qualità SW risulta, dalle esperienze maturate (UniCredit, Mediolanum, Zurich, Generali), un cambiamento piuttosto articolato ma con risultati significativi se seguito con dedizione - Da casi svolti sul campo si evidenzia come l introduzione di tale precorso è fortemente influenzato da: - Commitment del management, inteso come spinta verso i diversi Stakeholders, che possono dimostrare forti resistenze al cambiamento e all introduzione di un nuovo modello di monitoraggio - Maturità dei processi strettamente correlati, quali gestione della domanda (Demand Management), registrazione timesheet (consuntivazione) e Incident management (difettosità) - Esperienze in ambito evidenziano che le principali dimensioni su cui viene effettuato il monitoraggio sono inizialmente la qualità e la produttività:, ma già nel medio termine può essere tuttavia introdotta la difettosità SW per collegare il prodotto rilasciato in produzione agli Incident correlati - Di sicuro la valutazione del perimetro applicativo (volumi, risorse) ha permesso in diversi casi di comprendere la reale complessità del parco applicativo : dimensione, risorse interne/ esterne rispetto le applicazioni critiche, dimensione effettiva dei carichi di lavoro rispetto la complessità operativa - A seconda degli approcci scelti in fase progettuale i risultati evidenziano che: - il focus sulle performance garantisce risultati nel breve termine, supportando scelte di evoluzione / dimensionamento dei Centri di Sviluppo (Fabbriche, Competence Center) - il focus sulla qualità del parco SW, richiede un percorso evolutivo piuttosto consistente, garantendo un omogeneo sviluppo del parco applicativo nel tempo (metodi di produzione e monitoraggio, valutazione delle terze parti, gestione della complessità del parco applicativo lungo il ciclo di vita delle diverse applicazioni) 1