MILANO – Nei contesti attuali dove il business di qualsiasi azienda ormai è ‘dipendente’ dal software sia per l’organizzazione e il funzionamento dei processi interni sia per l’erogazione di servizi sempre più ‘digital oriented’ verso clienti, fornitori e partner esterni, le pratiche di analisi e misurazione del software, della sua qualità e produttività rispetto al core business dell’impresa nonché dell’efficacia dei processi di sviluppo e manutenzione, assumono un ruolo decisamente ‘mission critical’.
Tuttavia, introdurre nei processi di sviluppo applicativo un livello di trasparenza basata sull’analisi oggettiva, elevando l’Adm (Application Development Management) a una metodologia di governance strutturata, è tutt’altro che semplice.
Se ne è discusso nel corso della recente Cio Conference 2014 di Cast dalla quale emerge un punto fermo: l’elemento cardine di un Adm efficace sta nella misurazione della qualità del software la quale, come in un più ampio modello di misurazione della produttività e della qualità dell’Ict, dovrebbe basarsi su metriche oggettive più vicine al concetto di ‘valore di business’ piuttosto che all’efficienza tecnologica in sé (ciò non significa che le prestazioni tecnologiche non siano importanti; tutt’altro, dovrebbero essere date ‘per scontate’ a tutti i livelli infrastrutturali e architetturali e perché questo accada servono naturalmente sistemi di misurazione e controllo efficaci).
“Da parte delle aziende vediamo la necessità di avere un It industriale, da un lato, e di sviluppare per offrire servizi innovativi, dall’altro”, sostiene Fabrizio Pessina, Principal di Boston Consulting Group. “Per colmare il gap tra It attuale ed esigenze di business sempre più ‘digital’, bisogna intervenire su almeno tre livelli: architetture dati, modelli di governance e modelli operativi. Un cambiamento che implica un differente sistema di It performance measurement basato su viste e metodi di controllo e misurazione che tengano conto principalmente di tre elementi: velocità/flessibilità, produttività e qualità”.
“Allo stesso modo, nello specifico ambito dello sviluppo software, la produttività e la qualità delle applicazioni si misurano attraverso parametri che tengano conto di affidabilità, performance efficiency, sicurezza e manutenibilità – spiega Bill Curtis, Direttore del Cisq – Consortium for It Software Quality, special group of interest dell’Omg – Object Management Group, nonché Senior Vice President and Chief Scientist di Cast -. Nell’ambito dell’affidabilità, per esempio, vanno misurati elementi quali: disponibilità, maturità, compliance alle normative, rimediabilità e tolleranza alla difettosità. Sul piano dell’efficienza e delle performance andranno sempre più tenuti in considerazione principi di analisi del ‘comportamento’ delle applicazioni nel tempo e dell’utilizzo che queste fanno delle risorse Ict disponibili. Guardando alla sicurezza, la misura della qualità dovrà tener conto di indicatori quali confidenzialità, integrità e autenticità. Infine, la qualità del software dipende sempre più anche dalla sua manutenzione e quindi dalla sua capacità di adattamento, cambiamento ed evoluzione, nonché riutilizzo”.
Bill Curtis, Direttore del Cisq – Consortium for It Software Quality, special group of interest dell’Omg – Object Management Group, nonché Senior Vice President and Chief Scientist di Cast
Dalle parole di Curtis è evidente che nei metodi di misurazione della qualità del software stanno sempre più pesantemente entrando concetti e pratiche ‘care al business’ come quelle di risk management e misurazione della produttività. A testimonianza di ciò interviene Massimo Rapetti, Responsabile Nucleo Qualità dei rilasci di Icbpi – Istituto Centrale delle Banche Popolari Italiane, raccontando come nel loro caso l’adozione di un processo di risk management sia risultato efficace anche, e soprattutto, nella gestione del rapporto con i fornitori di servizi di sviluppo software in outsourcing. “In linea con il piano industriale di sviluppo dell’azienda, la qualità del software ha assunto un ruolo di asset strategico, al punto che nella ‘mission’ del Nucleo Qualità figura anche il maggior coinvolgimento del business nelle pratiche di quality assurance”, descrive Rapetti. “Aumentare la qualità, infatti, significa anche introdurre e diffondere la ‘cultura della qualità’ che non può essere confinata solo all’Ict, ma estesa anche al suo rapporto con i vendor, da un lato, e con il business, dall’altro”.
All’interno di Icbpi ciò sta avvenendo grazie all’introduzione di processi di gestione del rischio standard e condivisi, sia all’interno (tra vari team Ict e tra Ict e business), sia all’esterno (tra Ict e fornitori). “Lo sforzo è riuscire ad avere risultati quantitativi oggettivi comprensibili a tutti”, spiega Rapetti, “lavorando su tracciabilità e automazione (per altro richieste anche dalle normative cui come azienda dobbiamo rispondere). Sul piano della responsabilità, inoltre, dev’esserci una ripartizione dei ‘compiti’ e una condivisione del rischio tra tutte le parti coinvolte, con un modello basato però sul disaccoppiamento dei ruoli: chi sviluppa non può avere anche il ruolo di colui che effettua i test e ‘accetta’ il software. Dev’esserci, a nostro avviso, una netta distinzione tra chi ‘produce’ e chi ‘valuta’. Solo così si riesce a rilasciare un software la cui qualità abbia reale valore di business”.
La misura nella definizione degli Sla: le ‘raccomandazioni’ di Curtis
Anche Curtis insiste sulla ‘vista business’ della misurazione della qualità del software, evidenziando come tale approccio possa divenire strumento di controllo e governo dei fornitori. In particolare, Curtis focalizza l’attenzione sull’efficacia della misurazione nella definizione contrattuale dei livelli di servizio da richiedere ai provider, suggerendo a tal riguardo otto semplici ‘raccomandazioni’:
1) fissare obiettivi di qualità ‘strutturale’ del software: in scenari dove l’Ict deve risultare sempre più flessibile e in grado di ‘adattarsi’ al business, anche il software deve ‘fare la sua parte’; misurarne la qualità strutturale significa tener conto della sua capacità di trasferibilità (da un team di sviluppo all’altro) e changeability (trasformarsi e adattarsi a nuovi contesti);
2) misurare le ‘violazioni inaccettabili’: rispetto ai parametri di robustezza, sicurezza, performance, trasferibilità e adattabilità del software, fissare e misurare i livelli minimi al di sotto dei quali non può esserci tolleranza e, quindi, alcun rilascio applicativo;
3) utilizzare un vocabolario comune: è importante condividere con il fornitore, per esempio, il concetto di qualità e i parametri su cui questa si basa, nonché le soglie minime di accettazione, l’indicazione esatta delle violazioni inaccettabili, ma anche i target e gli obiettivi di business cui tendere;
4) misurare la qualità anche a livello di sistemi infrastrutturali: è fondamentale capire e condividere in che modo le applicazioni impatteranno sulle risorse e i sistemi Ict in modo da stabilire, in anticipo, i parametri per il corretto sviluppo (e quindi gli Sla con il fornitore);
5) definire ruoli e responsabilità: la condivisione di visione e obiettivi non deve avere un impatto negativo su ruoli e responsabilità che devono essere ben distinte tra cliente e fornitore;
6) seguire un processo di misurazione: la misurazione deve seguire un percorso ben definito e strutturato, altrimenti non è efficace. Un esempio di processo potrebbe essere: stabilire una baseline, identificare target e soglie, monitorare i risultati, definire a priori i piani di intervento e aggiornare costantemente gli Sla;
7) valutare i contratti di fornitura: se la pratica di misurazione della qualità al proprio interno è ben strutturata, questa diventa un ottimo strumento di analisi dei contratti di fornitura dato che si introducono parametri già noti e in uso fin dalle valutazioni preliminari;
8) ricorrere ‘saggiamente’ a premi e penalità: in questo caso Curtis parla di ‘maturity shift’ indicando come un sistema di misurazione della qualità condiviso, che preveda una corresponsabilità quantificata attraverso penalità o premi, consenta di avvicinarsi maggiormente al modello di ‘partnership’ azienda utente/vendor tanto osannato, ma altrettanto difficile da mettere in pratica.
