MILANO – Parlare di Productivity e Risk Management all’interno delle divisioni di business, soprattutto se pensiamo alle direzioni finanziarie e amministrative e al top management, è pratica comune e consolidata. Un po’ meno nei dipartimenti tecnici, come l’It, dove non è affatto detto che manchino del tutto questi approcci, tutt’altro, ma spesso asseriscono a processi manuali (soprattutto nel caso del Productivity Management gestito e misurato senza metodologie e framework di riferimento) o per così dire euristici affidati a pochi esperti. Uno scenario molto plausibile, per esempio, nell’ambito dell’Adm, Application and Development Management, anche se proprio in questi contesti Risk e Productivity Management portano benefici riscontrabili anche, e soprattutto, sul piano del business.
Lavorano in questa direzione, infatti, l’Omg (Object Management Group) e il Software Engineering Institute, attraverso il loro consorzio Cisq – Consortium for It Software Quality, da anni impegnati a raccogliere e razionalizzare dai maggiori player Ict mondiali i requirement di misurazione automatica della qualità del software per arrivare alla definizione di uno standard computabile/misurabile che costituisca la ‘prima pietra’ di una reale industrializzazione dei processi di sviluppo software.
Bill Curtis direttore del Cisq, co-autore del Cmm (Capability Maturity Model) e senior vice president e Chief Scientist di CastIn occasione della Cio Conference 2013 di Cast, su questi temi è intervenuto l’esperto mondiale Bill Curtis direttore del Cisq, co-autore del Cmm (Capability Maturity Model) e senior vice president e Chief Scientist di Cast, illustrando i nuovi standard sulle cosiddette ‘Automated Software Measures’ e i loro benefici sulle attività di Risk e Productivity Management. Dopo aver presentato il nuovo standard Omg sugli Automated Function Point (Afp) grazie al quale è possibile calcolare automaticamente i function point (unità di misura utilizzata per valutare i requisiti funzionali di un’applicazione) e la qualità applicativa in termini di affidabilità, performance efficiency, sicurezza e gestione/mantenibilità, Curtis ha introdotto un nuovo framework per la misurazione dei rischi e della produttività. “Traslando all’interno dello sviluppo software il calcolo matematico della produttività – spiega Curtis – otterremo una formula pari a: ‘produttività’ uguale ‘volume del codice sviluppato, modificato o cancellato’ diviso ‘il totale delle risorse spese per tali attività’ (figura 1).
Una formula certamente utile ma che non risulta sufficiente rispetto alla complessità dello sviluppo applicativo odierno”.
Come abbiamo più volte analizzato, le applicazioni enterprise moderne sono costituite da layer tecnologici multipli che incorporano componenti diversi, vari framework infrastrutturali ed architetturali, tecnologie eterogenee e linguaggi diversificati. Se trent’anni fa un’ applicazione era normalmente mono-piattaforma e mono-linguaggio ora questo approccio risulta inefficace a soddisfare le esigenze del business quali la massiccia richiesta di accesso alle applicazioni in mobilità e il cloud computing che stanno complicando lo scenario applicativo prospettando sviluppi sempre più articolati.
Figura 2: Formula per il calcolo della produttività del software con l'introduzione del technical debt Fonte: Cisq – Consortium for It Software Quality
Scenario che si complica ulteriormente se pensiamo al fatto che un’applicazione di tipo enterprise oggi è costituita da un insieme di vecchie componenti legacy e da vari moduli scritti con linguaggi moderni integrati in diversi momenti e tempi. In contesti così complessi, il concetto e la misurazione del cosiddetto ‘technical debt’, secondo Curtis, può ‘tornare utile’ sul fronte della misurazione del rischio e della produttività. Curtis introduce infatti nel framework per la misurazione della produttività il technical debt (ossia il debito derivante da problemi tecnici, codice errato, criticità funzionali misurabile attraverso i costi necessariamente da sostenere per riparare a tali errori/problemi) quale Kpi nella minimizzazione dei rischi operativi e come indicatore economico del degrado di produttività. In questo caso, quindi, la formula diventa molto più complessa (alla formula del calcolo della produttività precedentemente illustrato va dunque associato il technical debt, ossia inseriti tutti gli sforzi e le spese sostenute per sistemare i difetti funzionali – figura 2).
Secondo Curtis, “un processo automatico di misurazione che utilizza Kpi standardizzati consente di integrare facilmente l’analisi della produttività aiutando l’It e le software factory a stimare anche i costi futuri di manutenzione applicativa, da un lato, e minimizzare i rischi di ‘degrado’ e malfunzionamento, dall’altro”.
La qualità strutturale di Carrefour e Rai
Roberto Angelini, Quality Assurance Manager, Carrefour Italy
Nel corso della Cio Conference di Cast si è parlato molto anche del ruolo della ‘qualità strutturale’ nel controllo di progetti critici, una visione raccontata direttamente da Roberto Angelini, Quality Assurance Manager di Carrefour Italy che ha illustrato il progetto ‘Easy’, nato nel 2012 come un insieme “di trentuno progetti che avevano un duplice scopo: risolvere alcuni problemi fondamentali di gestione dei processi core business aziendali e condurre una forte innovazione ed ottimizzazione applicativa e infrastrutturale dei Sistemi Informativi”.
Un’innovazione che ha portato a importanti attività di sviluppo svolte nel biennio nel 2011-2012 sulle applicazioni di gestione prodotti/prezzi, backoffice/riordino e supply chain.
“Per poter mitigare i rischi derivanti dalle implementazioni di questi 31 progetti è stata avviata un’iniziativa di Quality Assurance sostanzialmente per: definire le metodologie di Quality Assurance; effettuare una revisione dei template di documentazione per tutte le fasi (sviluppo, rilascio, training, rollout, ecc.); eseguire audit sulla documentazione fornita; definire e intraprendere addizionali test funzionali e di performance; adottare metodologie per la valutazione della produttività sugli sviluppi (con particolare focus sul codice sviluppato: visibilità oggettiva sulla qualità del software; valutazione e minimizzazione dei rischi operativi; riduzione dei costi di manutenzione)”, spiega Angelini.
“Carrefour Italy, così come l’intero gruppo aziendale, esternalizza interamente i progetti di sviluppo e manutenzione applicativa ma attraverso un processo di governance estremamente maturo (supportato dalle tecnologie Cast, in particolare l’Application Intelligence Platform) riusciamo a controllare la qualità delle forniture dei nostri outsourcer sui progetti più mission critical”, osserva Angelini. “In particolare, riusciamo a: mantenere il livello di Kpi definito per le applicazioni esistenti, identificare i rischi potenziali non noti, verificare il livello di qualità del fornitore che scrive il codice, effettuare una possibile verifica sulla produttività dei fornitori”.
Anna Maria Fassi, Head of Software Engineering della Direzione Ict di Rai
Anche per Rai la qualità applicativa deve ‘fare i conti’ con l’outsourcing strategico, quindi, nella gestione dei contratti di sviluppo applicativo entrano in gioco pratiche di risk e productivity management. A partire dal 2001 l’azienda ha iniziato ad utilizzare le soluzioni Cast per controllare la qualità delle proprie applicazioni, ma da allora ha progressivamente allargato negli anni l’ambito di utilizzo della piattaforma per la Software Analysis and Measurement.
“Rai ha ora integrato un sistema proattivo di misurazione e gestione della qualità software nel proprio processo di delivery, effettuando analisi periodiche che hanno lo scopo di produrre assessment dell’intero portafoglio applicativo (la cui manutenzione è stata recentemente data in gestione ad alcuni system integrator) con lo scopo di verificare la qualità di quanto da essi fornito”, spiega Anna Maria Fassi, Head of Software Engineering della Direzione Ict di Rai. “Abbiamo infatti incluso le misurazioni effettuate attraverso la piattaforma di Cast come veri e propri Sla che ci consentono di controllare l’operato dei fornitori nonché di definire delle penalizzazioni economiche in caso di non rispetto degli stessi”.
