Determinare i costi della software quality, contenendo al massimo i rischi di malfunzionamenti e non rispondenza alle aspettative delle applicazioni, è un aspetto di estrema rilevanza in una situazione economica complessa nella quale le giuste scelte, in termini di metodologie e tecnologie di sviluppo software, si possono trasformare rapidamente in vantaggi competitivi. Sono questi gli aspetti che hanno animato la Cio Conference 2012 promossa da Cast iniziata con gli interventi di due dei massimi esponenti a livello globale in tema di Software Quality: Caper Jones, Founder and Former Chiarman of Software Productivity Research, e Bill Curtis, Cast Senior Vice President and Chief Scientist, noto a livello internazionale per aver ideato e sviluppato la metodologia CMM (Capabilty Maturity Model), il framework metodologico divenuto ormai uno standard internazionale nell’ambito dell’ingegneria del software che definisce il modello organizzativo e i processi per la creazione del software.
Jones ha focalizzato il suo intervento sugli economics della qualità del software puntando il dito sulla ricerca del miglior bilanciamento possibile tra software risk, valore delle soluzioni (soprattutto in termini di produttività ed efficienza del business) e ritorno degli investimenti, ribadendo come “ancora poco si faccia nelle aziende per introdurre un sistema di qualità strutturato e con una vista business oriented che intervenga fin dalle fasi di ingegnerizzazione, sviluppo e testing”.
Temi su cui è tornato più volte anche Curtis, che ha sottolineato l’importanza del controllo e della misurazione, nonché della standardizzazione applicativa e metodologica, evidenziando, ricorrendo ad una nota frase, come “sia pressoché impossibile migliorare ciò che non si conosce e non si riesce a misurare”.
In particolare, Curits ha ribadito il concetto di qualità strutturale del software (che si riferisce alla validità ingegneristica dell’architettura e del codice di un’applicazione, nonché alla sua corretta implementazione in funzione dei business requirement e dei requisiti funzionali degli utenti), ambito sul quale le aziende dovrebbero maggiormente investire e concentrarsi “perché il risultato finale di una soluzione impatta direttamente sull’operatività degli utenti e sui livelli dei servizi erogati dall’It (disponibilità del servizio applicativo, calo delle performance, violazioni da parte di user non autorizzati, alterazione dei dati associati alle applicazioni, ecc.).
Ed è proprio sugli aspetti più legati al business che si è poi focalizzata la tavola rotonda coordinata da Stefano Uberti Foppa, direttore di ZeroUno, che ha visto intervenire Debora Guma, Cio di Carrefour Italia, Alessandro Musumeci, Cio di Gruppo Ferrovie dello Stato, Paolo Manzoni, It Director di A2A, Romano Brida, Vice President di NTT Data e Roberto Zanatta, Sales Director di CapGemini.
Indice degli argomenti
Innovare e migliorare la qualità del software: l’obiettivo è di business
“Ci troviamo in una fase di cambiamento molto importante – ha esordito Uberti Foppa – all’interno della quale la trasformazione dei dipartimenti It verso una più efficace proposta di servizi di valore per il business passa anche attraverso ragionamenti e scelte sul piano infrastrutturale delle applicazioni. Logiche e caratteristiche di robustezza, performance, sicurezza e qualità non possono più essere viste solo dalla prospettiva tecnologica; le applicazioni vanno analizzate, sviluppate o trasformate con una vista nuova che è quella relativa alla produttività del business e alla capacità dell’azienda di rifocalizzarsi in nuovi contesti, geografici ed economici, così come impongono le nuove regole della competitività”.
“In un periodo competitivo complesso, quali sono i ragionamenti da parte dell’It sul rapporto tra qualità del software ed efficacia delle soluzioni sul piano del business?”, ha chiesto Uberti Foppa ai partecipanti alla tavola rotonda.
“In ambito Retail sono immediati i risultati negativi e gli impatti che può avere una cattiva qualità del software – risponde Guma -. Si tratta di conseguenze che ricadono a cascata sui vari reparti dell’azienda ma che finiscono poi per procurare un disservizio anche al cliente finale: pensiamo, ad esempio, ad un sistema di controllo del magazzino o gestione degli ordini che non funziona come dovrebbe. Il risultato è che nei punti vendita al dettaglio non arrivano i prodotti nei tempi e nei modi stabiliti dal business. Un effetto che oggi non ci possiamo permettere: la clientela cambia negozio e trova subito altrove ciò che gli serve”.
Effetti diretti sull’utente finale anche nel caso di Ferrovie dello Stato: “Oggi la concorrenza nell’ambito del trasporto è sempre più agguerrita e non si gioca solamente sul prezzo del servizio ma sulla sua qualità – spiega Musumeci -; una qualità direttamente proporzionale a quella del software su cui si regge il business. Nel nostro caso lo sviluppo software è affidato in outsourcing ma con una governance e un controllo centralizzato necessari proprio per garantire che i risultati siano conformi ai requisiti (tecnologici ma soprattutto di business)”.
“In contesti altamente competitivi – riflette Brida – la qualità del software rappresenta un vero e proprio differenziale competitivo, per cui ragionare sull’ottimizzazione dei processi di sviluppo, sulla maggior efficacia del testing, sulle performance applicative negli ambienti di produzione diventa un must imprescindibile”.
Le criticità: ‘paura’ dell’integrazione e mancanza di competenze chiave
Quando si pensa alla qualità del software, in particolare sul piano dell’innovazione che porta oggi le aziende a ragionare su applicazioni di nuova generazione, virtualizzate, basate sul cloud, fruibili attraverso dispositivi mobili, ecc. le criticità maggiormente riscontrate, convergono i relatori della tavola rotonda, sono da attribuire all’enorme mole di dati che contribuiscono allo sviluppo delle soluzioni (e alla loro ‘alimentazione’ una volta messe in produzione) e alle problematiche inerenti l’integrazione e la correlazione tra più applicazioni e tra queste e le architetture sottostanti (anch’esse in continua evoluzione). Tempi stretti e budget ridotti non sono comunque meno sentiti: “La valenza del
software è ormai un fatto imprescindibile dalla normale vita quotidiana di ognuno di noi – interviene Manzoni -. Purtroppo a questa valenza non è corrisposta, nel tempo, un’adeguata valorizzazione delle applicazioni ed oggi risulta molto difficile, a noi dell’It, spiegare che una soluzione qualitativamente performante richiede tempi e sforzi non sempre compresi dal business. È chiaro a tutti che la costruzione di una casa richiede una fase progettuale con gli skill adeguati, un percorso evolutivo ben definito con tutta una serie di pratiche e accorgimenti; stessa cosa vale per le applicazioni, ma questo non è facile da far comprendere. È indubbio che i contesti in cui si muovono oggi le aziende stiano riportando in evidenza la valenza strategica delle tecnologie, soprattutto per sviluppare e attuare piani di business e raggiungere gli obiettivi; tuttavia, la pressione sui costi e sui tempi di rilascio è tale che può impattare in modo negativo sul risultato finale”.
“La metafora della casa mi pare appropriata – interviene Zanatta -. Noi spesso parliamo di ‘costruzione di una città nuova sulle basi di una città vecchia’ per spiegare la fotografia classica che troviamo all’interno delle aziende, dove gli strati tecnologici sono stati costruiti, negli anni, innovando, da un lato, ma salvaguardando l’esistente, dall’altro, com’è giusto e normale che sia. ‘Abbattere e ricostruire’ è impensabile: non è stato possibile in tempi economici fortunati, figuriamoci ora. La sfida critica più grande, oggi, è dunque legata all’integrazione: la qualità deve essere misurata non solo sulla base delle caratteristiche della singola soluzione (queste rappresentano solo la punta dell’iceberg) ma anche del suo ‘comportamento’ una volta introdotta nel sistema informativo aziendale”.
“La qualità del software, oggi, deve essere valutata non più tenendo conto del contesto della singola applicazione ma della sua interazione con gli altri sistemi”, osserva Guma. “Un aspetto, questo, che solleva un altro problema non banale: la mancanza di figure chiave come quelle degli analisti del software (con skill tecnologici ma anche con una forte capacità di vista di business) e gli architetti di sistema (in grado di integrare conoscenze sia in ambito software sia hardware), per sviluppare soluzioni di qualità sia sotto il profilo tecnologico sia sul piano della produttività e, quindi, dell’efficacia per il business”.
Condivide tale visione anche Musumeci: “Nel nostro caso – dice – non abbiamo gli analisti ma avendo scelto l’outsourcing ci siamo dovuti ristrutturare al nostro interno per avere, da un lato, figure in grado di governare e controllare i processi interessati dall’outsourcing con competenze spiccate nell’ambito del demand management e, dall’altro, skill tecnici di implementazione e integrazione”.
“Anche dalla prospettiva di un system integrator queste sono le considerazioni principali – aggiunge Brida – motivo per cui, nel nostro caso, ci siamo da tempo mossi per definire delle best practice e costruire delle esperienze utente che fungano da benchmark per meglio guidare le aziende nel processo di trasformazione applicativa (soprattutto laddove mancano le competenze interne). Un processo che supportiamo, naturalmente, con l’aiuto delle tecnologie che non solo offrono una vista sulla qualità delle applicazioni ma anche un controllo più efficace sui costi, con obiettivi senz’altro di saving ma soprattutto di innovazione per non ‘sprecare’ gli interi budget It in manutenzione”.
L’importanza dei contratti e della relazione vendor-utente
Un ultimo importante punto dibattuto nel corso della tavola rotonda riguardava la relazione tra vendor It e aziende utenti, che ha fatto emergere alcune interessanti considerazioni anche sulla contrattualistica.
“Gli aspetti contrattuali andrebbero gestiti senza timore e senza ritrosie – sostiene Guma -. Spesso vediamo la parte contrattuale come un ‘male necessario’ quando, al contrario, andrebbe definita in modo chiaro e trasparente e trattata come una componente strategica del progetto, tenendo conto delle esigenze di profitto/produttività e beneficio per entrambi”.
“Tendiamo a ‘prendere in mano’ i contratti solo quando si verificano dei problemi – aggiunge Manzoni – quando, invece, dovremmo imparare a lavorare bene prima; se si impara a stendere contratti chiari, puntuali ma al tempo stesso flessibili, allora i problemi si possono risolvere insieme, senza dover impugnare clausole e specifiche in un secondo momento”.
Dello stesso parere Musumeci che, avendo optato per l’outsourcing applicativo, deve necessariamente focalizzare l’attenzione sugli accordi in termini di Sla affinché la strategia di provisioning risulti ben bilanciata tra rischi, cost saving, qualità delle soluzioni, profitti e non si traduca, invece, in un disservizio. “Naturalmente, il buon rapporto con il vendor va costruito anche dall’interno – evidenzia Musumeci -. Dalla nostra parte, per esempio, dobbiamo essere precisi nel formulare le richieste e avere ben chiaro verso quale strada vogliamo andare. In questo modo si riesce a instaurare un rapporto collaborativo con il vendor che diventa davvero un partner quando è in grado di condividere il rischio e di formalizzarlo in contratti, per esempio, basati solo sul pay-per-use”.
Puntano sui concetti di trasparenza, chiarezza e condivisione degli obiettivi anche Zanatta e Brida che, in rappresentanza della parte di offerta It, parlano di supporto consulenziale per l’avvicinamento di due culture (It e business) affinché si possano vedere e condividere entrambe le viste sulla base delle quali disegnare il percorso evolutivo più opportuno. “Dal nostro punto di vista c’è bisogno non solo dei demand manager che siano in grado di interpretare la domanda per poi tradurla in tecnologia – osserva Zanatta – ma anche di figure che facciano il percorso inverso, che dalla posizione strategica si calino nella prospettiva tecnologica; e questo lo possono fare i consulenti esterni”.
“La tecnologia può rappresentare un valore non solo per la capacità di rispondere ad una o più esigenze delle aziende utenti – aggiunge Brida – ma anche per ‘dimostrare’ il valore del vendor che su quella tecnologia costruisce le proprie competenze. Certo non basta. Il vendor deve conoscere bene i contesti di mercato per saper proporre le soluzioni più adatte: non le migliori tecnologie, ma quelle più adatte al contesto aziendale del cliente”.