Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Qualità del software: la tua azienda è matura?

pittogramma Zerouno

Qualità del software: la tua azienda è matura?

19 Feb 2009

di Patrizia Fabbri, Paolo Pasini

La figura del Demand Manager e il processo di Demand Management “collaborativo” sono due elementi chiave della gestione delle richieste applicative da parte dell’azienda. I processi di controllo e di gestione della qualità delle applicazioni esistono, sono abbastanza strutturati, ma sono applicati solo ove la criticità dell’applicazione giustifica l’impegno. Sono due delle principali evidenze emerse dall’inchiesta realizzata da Zerouno attraverso un questionario molto articolato, pubblicato sul nostro sito, alla quale hanno partecipato 72 aziende italiane. I risultati sono stati elaborati e analizzati da Zerouno e commentati da Paolo Pasini, Professore Senior della Unit It e responsabile dell’Osservatorio Bi di Sda Bocconi

Una corretta gestione della qualità applicativa non solo mette l’azienda al riparo da eventuali problemi nella messa in produzione delle applicazioni, ma rappresenta la concretizzazione del reale allineamento tra It e business. Per capire come le aziende italiane si stanno muovendo in quest’area e a quale livello di un ideale modello di maturità nella gestione della qualità del software possono collocarsi, ZeroUno ha realizzato, in collaborazione con Hp, l’inchiesta “Qualità del software: la tua azienda è matura?” .
L’indagine, alla quale hanno risposto 72 aziende, è stata svolta tramite un articolato questionario online (32 domande) sul sito www.zerounoweb.it nei mesi di luglio-settembre 2008.Questa indagine si inserisce in un ciclo di tre inchieste dedicate alla misurazione della qualità e delle prestazioni dei sistemi informativi aziendali. I risultati della prima inchiesta, svoltasi nei mesi marzo-aprile, sono disponibili nell’area dell’Osservatorio Quality & Performance Management del sito www.zerounoweb.it, mentre la terza inchiesta, dedicata alla sicurezza nello sviluppo applicativo, è online in questi giorni: chi parteciperà riceverà i risultati dettagliati, ricchi di grafici e commenti.
I risultati dell’indagine “Qualità del software: la tua azienda è matura?”sono stati elaborati e analizzati da ZeroUno e successivamente commentati da Paolo Pasini, Professore Senior della Unit SI e responsabile dell’Osservatorio BI di Sda Bocconi School of Management.

Le principali evidenze
Prima di analizzare nel dettaglio alcuni dei risultati emersi (la ricerca completa è riservata a chi ha partecipato rispondendo al questionario) riassumiamo le principali evidenze emerse.
1. Il contesto generale delle aziende utenti del campione indagato si presenta ancora prevalentemente orientato alla gestione interna dell’infrastruttura Ict e del parco applicativo (72% per le aziende non appartenenti al comparto Ict), mentre nei processi di sviluppo applicativo prevalgono le situazioni di mix e di collaborazione tra la funzione It interna e gli outsourcer applicativi.
2. La figura del Demand Manager e il processo di Demand Management “collaborativo” (con i process owner) sono due elementi chiave della gestione delle richieste applicative da parte dell’azienda.
3. I processi di controllo e di gestione della qualità delle applicazioni esistono, sono abbastanza strutturati, ma sono applicati solo ove la criticità dell’applicazione giustifica l’impegno, in un contesto generale dove l’unità di Quality management dell’It è poco presente. Il campione di fornitori Ict indagati fanno da benchmark presentando una situazione sensibilmente migliore e possono, quindi, rappresentare lo stato dell’arte di riferimento.
4. Gli strumenti di office sono ancora molto diffusi per la gestione dei requisiti funzionali, per la progettazione dei casi di test funzionale e per il tracciamento dei risultati e delle anomalie; seguono le soluzioni di repository centrali. Gli strumenti di mercato specializzati per il Demand management, il Test management e il Bug Tracking presentano un’adozione ancora limitata. Anche in questo caso i fornitori Ict presentano practice decisamente migliori.
5. L’esecuzione dei test funzionali relativi alla manutenzione evolutiva e correttiva viene prevalentemente svolta da team di test (e non da chi ha sviluppato l’applicazione), ma con scarso impiego di strumenti automatici.
6. I test di performance delle applicazioni al primo rilascio, o modificate in modo sostanziale, non vengono effettuati oppure vengono effettuati con l’ausilio di strumenti automatici ma solo per le applicazioni business critical.
7. Il processo di testing nel suo complesso è gestito prevalentemente all’interno; chi si affida a servizi di outsourcer, generalmente si limita a consegnare i requisiti funzionali dell’applicazione e, in casi ancora minori, anche i casi di test da svolgere per l’accettazione finale dell’applicazione.
8. Un team interno e indipendente che verifica i requisiti funzionali e di performance delle applicazioni esiste raramente e dove esiste opera in prevalenza sulle applicazioni più business critical.
9. Nella gestione del portafoglio iniziative/progetti e per la consuntivazione/avanzamento degli stessi, in generale si impiegano più strumenti software non integrati tra di loro.

 

Figura 1: Aziende nelle quali le richieste da parte del business vengono raccolte da figure di Demand Manager
(clicca sull’immagine per ingrandirla)

Demand manager: figura chiave
Come sottolineato nel precedente punto 2. e come evidenziato nella figura 1, nelle aziende utenti si conferma l’attenzione e la sempre maggiore diffusione delle figure di Demand Manager (53% dei casi), figura critica e molto complessa come posizionamento organizzativo, come ruoli nel processo di Demand Management, come skill e capacità di gestione delle relazioni con i clienti interni. A sorpresa si scopre che nel campione indagato, le grandi (oltre 1.000 dipendenti) e le medio-piccole (fino a 250 dipendenti) aziende sono molto simili come presenza dei Demand manager, 69% nelle prime e 75% nelle seconde, contrariamente alle medio-grandi (da 250 a 1.000) nelle quali solo nel 17% dei casi il Demand manager ha un ruolo reale e continuativo.

 

Figura 2: Come vengono gestite le richieste da parte del business
(Cliccare sull’immagine per ingrandirla)

Riguardo la gestione delle richieste del business (figura 2) è interessante notare che nelle aziende utenti è relativamente più impiegato il processo di Demand management (61% dei casi) che non il processo di It portfolio management (39%), che ne è, in teoria, il suo naturale proseguimento: la necessità di comprendere bene prima il contenuto e i benefici della richiesta, nonché la tendenza generalizzata delle aziende italiane ad utilizzare relativamente poco strumenti come quello dell’It portfolio management, sono probabilmente le spiegazioni di questa situazione.
Al contrario, per il 53% dei fornitori Ict la gestione delle richieste dei loro clienti viene inserita direttamente nel processo di It portfolio management più che nel processo di Demand management (47%), probabilmente perché per queste aziende è prioritario capire la saturazione delle risorse umane che si genera dal portafoglio dei progetti in corso, in avviamento e in valutazione.

Processo e metodologia di controllo e di gestione della qualità
Analizzando quanto vengono ritenuti strutturati e applicati il processo e la metodologia di controllo e di gestione della qualità delle applicazioni all’interno dell’azienda, l’indagine rileva che un quarto dei fornitori Ict presenta, coerentemente al loro core business, processi e metodologie di controllo e di gestione della qualità del software.

 

Figura 3: Quanto vengono ritenuti strutturati e applicati il processo e la metodologia di controllo e di gestione della qualità delle applicazioni all’interno dell’azienda
(Clicca sull’immagine per ingrandirla)

 

 

 

 

D’altro canto le aziende utenti (figura 3) dichiarano in prevalenza (56% dei casi) l’esistenza di processi e di metodologie di controllo e gestione della qualità del software. ma che vengono applicati in modo selettivo solo ai progetti applicativi più rilevanti, mentre nel 36% dei casi (8% + 28%) essi sono inesistenti o poco strutturati. Le practice sensibilmente migliori si presentano nelle grandi imprese ove il 69% (56% + 13%) dichiara processi e metodologie di controllo e gestione della qualità delle applicazioni ben strutturati e utilizzati in ogni progetto applicativo o ai progetti più rilevanti; nelle piccole la percentuale scende al 48%.

Figura 4: Presenza di un’unità di Quality management dell’It
(Cliccare sull’immagine per ingrandirla)

 

La presenza dell’unità Quality management dell’It differenzia i fornitori Ict rispetto alle aziende utenti: nei primi esiste nel 56% (39%+17%) dei casi, nelle seconde (figura 4) nel 33% (25%+8%). Produrre Ict come core business induce ovviamente a presidiare il più possibile la qualità dei prodotti o dei servizi per il mercato, assegnandone la responsabilità a un’unità formale interna (nella funzione It o fuori, poco importa).

 

Figura 5: Modalità di gestione dei requisiti funzionali
(Cliccare sull’immagine per ingrandirla)

La gestione dei requisiti
Per quanto riguarda la modalità di gestione dei requisiti funzionali, nel campione di aziende utenti (figura 5), per certi versi si presenta una polarizzazione dei casi, dove il 38% delle aziende impiega uno strumento più di tipo general purpose come Word e il 26% crea un ambiente sofisticato di gestione degli stessi, costituito soprattutto da un repository centrale; interessante notare che anche un altro 17% dei casi li gestisce in un ambiente ancora più sofisticato, in quanto oltre al repository centrale, questi requisiti vengono messi in relazione ai requisiti di business, ai test case e alle anomalie rilevate.
Uno strumento software di mercato per il Demand management in cui raffrontare i requisiti funzionali dell’applicazione con i requisiti di business è presente solo nel 13% dei casi, comunque sensibilmente superiore al 7% dei fornitori Ict.

Dai test funzionali a quelli di performance: come e quali
La fase di testing è certamente una della fasi nel processo di Application development che più condiziona la qualità del software applicativo: il 39% dei fornitori Ict progetta i casi test con l’impiego di uno strumento specializzato di test management (che possiede funzionalità dedicate allo scopo) e un altro 39% con l’impiego del foglio elettronico (che, come strumento general purpose, non presenta funzionalità specifiche per lo scopo).  Da non sottovalutare il 22% dei fornitori Ict che non progetta in assoluto i casi di test funzionale (di nuovo, è molto probabile che essi non si occupino di sviluppo di software).
Un terzo quasi delle aziende utenti non progetta i casi di test funzionale del software applicativo e la maggioranza (56%) impiega allo scopo il foglio elettronico più a scopo di inventario e tracciamento che altro. Gli strumenti specializzati di test management sono poco diffusi (14% dei casi).
È altrettanto rilevante il 31% delle aziende utenti che non progetta in assoluto i casi di test funzionale affidandosi di conseguenza a test più generici o casuali.
Per quanto riguarda l’esecuzione dei test funzionali della manutenzione evolutiva e correttiva, i fornitori Ict impiegano in prevalenza un team specializzato di testing che opera in modo manuale (39% dei casi) o il team che ha sviluppato le nuove funzionalità, senza rispetto quindi della differenziazione dei ruoli (39%). In tutti questi casi (78%) però non viene impiegato alcuno strumento automatico che possa evitare la non regressione.
Le aziende utenti si presentano maggiormente attente al tema della differenziazione dei ruoli rispetto ai fornitori Ict: infatti il 56% dei casi (contro il 39% dei fornitori Ict) fa effettuare i test funzionali della manutenzione evolutiva e correttiva a team specifici di testing e non a chi ha sviluppato le nuove funzionalità (scelta che si presenta nel 28% dei casi). L’uso di strumenti automatici che possano evitare la non regressione dei test è ancora poco diffuso, solo nel 14% dei casi.
Per quanto riguarda i test di performance delle applicazioni al primo rilascio o dopo una modifica rilevante, la situazione dichiarata dal campione di fornitori Ict è abbastanza negativa: il 39% dichiara di non effettuare mai i test con strumenti automatici. Il restante 61% effettua i test di performance con strumenti automatici, ma in modi e in contesti diversi: il 22% solo se l’applicazione è mission critical, il 17% con strumenti proprietari di mercato, il 14% con strumenti open source, e infine l’8% dichiara di effettuare i test, ma dichiara altresì di non aver chiari i requisiti di performance necessari.
Per quanto riguarda le aziende utenti, la medesima percentuale dei fornitori Ict, il 39%, dichiara di non effettuare alcun test di performance delle applicazioni dopo il primo rilascio o dopo interventi significativi sulle stesse con strumenti automatici. La criticità delle applicazioni in oggetto guida l’utilità percepita delle aziende utenti nell’esecuzione dei test di performance nel 39% dei casi. Solo il 6% impiega strumenti software di mercato per l’esecuzione dei test di performance, il 3% strumenti open source. Infine un 14% effettua i test in oggetto, ma in modo quasi casuale, non mirato, non avendo chiari i requisiti di performance necessari.

L’organizzazione di testing e la gestione delle iniziative
La presenza di un team di testing indipendente (rispetto a chi ha sviluppato l’applicazione) è certamente una risposta organizzativa alle problematiche illustrate nei risultati della presente ricerca: la sua composizione (mix di utenti e di specialisti It) e la sua forma organizzativa (unità ad hoc nella funzione It o nella funzione Qualità aziendale; unità stabile e formale nell’organigramma o gruppo di lavoro interfunzionale che si forma al bisogno), costituiscono alcune delle scelte critiche di assetto.

 

Figura 6: Presenza all’interno dell’azienda di un gruppo di test indipendente che verifica (test) i requisiti funzionali o di performance per tutte le iniziative progettuali dell’azienda
(Cliccare sull’immagine per ingrandirla)

Presso i fornitori Ict, nel 53% dei casi questo gruppo di test non esiste, similmente nel 50% dei casi delle aziende utenti.Tuttavia nel 19% dei fornitori Ict esso esiste ed è sempre attivo (cioè agisce per tutte le applicazioni che vengono sviluppate), contro l’8% delle aziende utenti.  Da notare però che il 42% delle aziende utenti (figura 6) attiva il gruppo di testing indipendente solo per le applicazioni aziendali più critiche.

Figura 7: Presenza di uno strumento unico per la gestione del portafoglio delle iniziative, dei progetti e della rendicontazione degli effort correlata allo stato di avanzamento delle singole fasi di progetti
(Cliccare sull’immagine per ingrandirla)

Chi opera come core business nel settore Ict, mostra chiaramente una maggiore attenzione all’impiego di un unico strumento integrato di gestione del portafoglio delle iniziative e dei progetti e del controllo del consumo delle risorse nell’avanzamento degli stessi: il 34% dei fornitori Ict utilizza uno strumento di questo tipo, contro il 14% delle aziende utenti (figura 7).
La non integrazione degli strumenti impiegati allo scopo rappresenta comunque la casistica più frequente: il 33% dei fornitori Ict dichiara di utilizzare più strumenti per la gestione del portafoglio iniziative e progetti e per la consuntivazione dell’avanzamento, e addirittura il 58% delle aziende utenti.
Da non sottovalutare comunque il 33% dei fornitori Ict e il 28% delle aziende utenti che dichiarano di non impiegare strumenti ad hoc per questi critici processi It.

Patrizia Fabbri
Giornalista

Patrizia Fabbri è giornalista professionista dal 1993 e si occupa di tematiche connesse alla trasformazione digitale della società e delle imprese, approfondendone gli aspetti tecnologici. Dopo avere ricoperto la carica di caporedattore di varie testate, consumer e B2B, nell’ambito Information Technology e avere svolto l’attività di free lance per alcuni anni, dal 2004 è giornalista di ZeroUno.

Paolo Pasini

SDA Professor, SDA Bocconi School of Management

Articolo 1 di 5