Indagine Empirica

I casi di studio eseguiti sono 41 su diversi clienti. I casi di studio sono stati eseguiti su progetti di diversa complessità.

Sono rilevate le seguenti misure:

• Cliente indica in esplicito il cliente per cui si esegue il progetto.
• TAM. Soggetto sperimentale. Per privacy e per assicurare che la rilevazione dei dati abbia solo lo scopo di sperimentazione, gli identificatori sono anonimi ed indicati solo con un codice.
• Tempo necessario per eseguire l’intero progetto. Questo si misura a partire da quando il progetto inizia sino a quando il prodotto è consegnato ed accettato dal cliente. Considerato che si possono assimilare i processi eseguiti per ogni processo, il rapporto tra numero di risorse impiegato e complessità del progetto, il mix di esperienza degli sviluppatori messi in campo, allora, questa misura può esprimere la complessità del progetto.
• TBRD: tempo per produrre il BRD. Esso è misurato in hh-persona da quando inizia la produzione a quando il documento si considera definitivo, comprendendo anche i tempi per effettuare i cicli di verifica e validazione e di eventuali modifiche.
• TNBRD = TBRD/Tprog*100 è il tempo per la produzione del BRD normalizzato, esprime la percentuale di tempo-persona impiegato nell’analisi rispetto al Tempo-persona speso per l’intero progetto. La normalizzazione serve per poter paragonare progetti di diversa complessità.

(Figura 2.1. Costo del BRD)

Anzianità. I TAM sono classificati secondo la loro anzianità, in due classi:

Senior = anni di anzianità nel ruolo TAM superiore a tre anni

Junior = anni di anzianità nel ruolo TAM inferiore o uguale a tre anni

I risultati rilevati sono riportati in Figura 2.1.  I dati sono raggruppati per soggetto sperimentale. Le misure per ogni soggetto sperimentale sono esposte in ordine cronologico; per esempio il TAM3 nel suo primo progetto in cui ha usato il BRD ha impiegato per completare l’analisi il 39,76 % del tempo-persona speso totalmente per lo stesso progetto, mentre la seconda volta che ha utilizzato questo standard ha speso il 10,63%. Inoltre, i soggetti sperimentali sono a loro volta raggruppati per classe di anzianità.

La prima osservazione rilevante è che i tempi-persona spesi da ogni TAM nell’analisi diminuiscono percentualmente con l’uso del BRD. Pertanto l’addestramento all’uso dello standard BRD fa diminuire i tempi di analisi in un progetto.

Se si tolgono tre outlier, TAM5, TAM2 e TAM8, i tempi-persona richiesti dall’analisi si mantengono entro limiti migliori di quelli previsti in letteratura. Infatti sono sempre entro il 5-6 % tranne in un caso in cui raggiunge il 10%.

Il coefficiente di correlazione tra Tprog e TNBRD risulta essere -0,48, includendo anche gli outlier. Ciò significa che: non c’è correlazione tra la complessità o la dimensione del progetto ed il tempo-persona richiesto dall’analisi secondo lo standard BRD; il segno negativo afferma che a più complesso/grande progetto corrisponde minore percentuale di tempo-persona per l’analisi.

Si rileva una grande oscillazione di TNBRD nei progetti svolti da un TAM, anche quando questo acquisisce maggiore abilità nell’uso dello standard questo potrebbe derivare da quanto il contenuto del progetto sia innovativo rispetto al dominio applicativo del sistema da modificare. Ciò spiegherebbe anche il valore del coefficiente di correlazione che anche essendo basso è comunque vicino a 0,5. Pertanto per impiegare meno tempo nell’analisi è necessario che l’analista sia aggiornato sulla evoluzione del dominio applicativo.

In figura 2.2 si riporta il grafico delle medie, distinguendo la serie di risultati riportati dai TAM junior da quelli dei senior. Si vede che i valori medi dei senior tendono ad essere minori di quelli degli junior. Questo conferma che la profondità di conoscenza del dominio applicativo fa diminuire il tempo persona necessario per l’analisi.

(Tavola 2.2. Distribuzione delle medie)

Un buon BRD deve dare la possibilità di progettare ed eseguire un test di sistema soddisfacente, per cui l’UAT deve dare minori fallimenti.

Sono stati eseguiti casi di studio su diversi clienti:

• Intesa Sanpaolo- ISP: 16 casi di test di cui 8 prima dell’introduzione del BRD e 8 dopo l’introduzione del BRD.
• Consorzio servizi Bancari - CSE: 24 casi di test di cui 12 prima dell’introduzione del BRD e 12 dopo l’introduzione del BRD.
• Millenium-MIL: 16 casi di test di cui 9 prima dell’introduzione del BRD e / dopo l’introduzione del BRD.

Nei casi di studio sono state rilevate le seguenti misure

NCT = numero di casi test totali nel piano UAT;

NCF= numero di casi di test falliti che non siano falsi positivi in un piano UAT;

NFN= numero di casi di test falliti in un piano UAT, normalizzati = NCF/NCT*100.

Essendo NFN normalizzato può essere utilizzato per confrontare software consegnati anche di dimensioni diverse.

È noto che per superare i casi di test falliti durante l’UAT il costo di correzione è molto più alto di quelli dei corrispondenti nel Test di Sistema (TS). Inoltre, i casi di test falliti nello UAT hanno anche un costo di reputazione almeno per il sistema di qualità dell’impresa produttrice che, anche se non valutabile esattamente, è molto dannoso.

Lo standard BRD è concepito per poter fare un piano di ST formalizzato e sistematico. Pertanto, si attende che il suo uso faccia diminuire i casi di test falliti durante lo UAT.

Nelle figure 2.3 sono riportati i dati rilevati dai casi di studio citati e la media come indicatore della tendenza centrale.

(Figura 2.3.a Efficacia del BRD in ISP)

(Figura 2.3.a-g Grafico dell’Efficacia del BRD in ISP )

(Figura 2.3.b Efficacia del BRD in CSE)

(Figura 2.3.b-g Grafico dell’Efficacia del BRD in CSE)

(Figura 2.3.c Efficacia del BRD in Millenium)

(Figura 2.3.c-g Grafico dell’Efficacia del BRD in Millenium)

La prima osservazione rilevante è che le medie di NFN si abbassano quando si introduce il BRD. Nonostante ciò si deve rilevare che:

In ISP la linea di tendenza sul grafico 2.3.a-g tende addirittura a salire, o quantomeno ad essere stabile tra i casi di studio prima e quelli dopo l’introduzione del BRD; questo deriva dal fatto che il cliente ha sempre richiesto un UAT molto approfondito ed informazioni specifiche sui test effettuati dal produttore di sw prima dello UAT, questo ha indotto Auriga a fare sempre un TS molto approfondito anche se non sistematizzato come quello che si è potuto introdurre dopo l’uso del BRD.

In MIL la media non scende significativamente, probabilmente questo deriva dal comportamento del cliente che ha progettato piani di UAT con criteri che non li rendono efficaci, quindi quando il TS in Auriga diventa più sistematico non si evince un grande vantaggio nell’UAT.

Dalla figura 2.4 si evince che la dispersione di NFN diminuisce tra prima e dopo l’adozione del BRD, tranne che per ISP, per i motivi già detti. Ma la dispersione risulta sempre relativamente alta. Questo può derivare da due cause: il BRD deve essere prodotto con maggiore accuratezza per poter progettare un TS efficace, onde far diminuire le failure scoperte nell’UAT, oppure deve essere migliorata la competenza nella progettazione del TS.

In ogni caso l’economia deriva essenzialmente dalla capacità di progettare un TS sistematico che richiede minor tempo persona a parità di efficacia che grazie al BRD.

(Figura 2.4. Dispersione di NFN)

Il Numero di rilievi (NR) associato ad ogni progetto è normalizzato sul costo dell’intero progetto (T_prog). Nella ipotesi che il costo del progetto sia un indicatore significativo della complessità dello stesso.

Numero di Rilievi Normalizzato =NRN = NR/T_prog*100

I casi di studio eseguiti sono 41 su diversi clienti che sono stati eseguiti su progetti di diversa complessità (Tprog) che hanno, quindi richiesto differenti impegni-persona per la produzione del BRD. I TAM osservati sono 10. Per privacy e per assicurare che la rilevazione dei dati abbia solo lo scopo di indagine, essi sono identificati con un codice.  In figura 2.5 sono mostrati i dati rilevati.

(Figura 2.5. Intensità dei rilievi nei BRD)

I rilievi nella Verifica e Validazione (V&V) del BRD consentono di eliminare difetti iniettati nel software già nell’analisi evitando così sprechi dovuti alla maggiorazione dei costi che comporterebbero le modifiche richieste dagli stessi difetti se rilevati durante lo UAT. Infatti, i rilievi nella V&V dell’analisi aumenta la probabilità di correttezza e completezza del BRD che è la base di partenza per la progettazione del TS. Un buon progetto di TS diminuisce la probabilità di rilevare failure durante lo UAT che, come è stato detto, hanno un costo di riparazione molto alto.

(Figura 2.5-g. Intensità dei rilievi)

In figura 2.5-g sono mostrati la box plot della distribuzione dei rilievi in tutti i progetti oggetto di indagine. Si rileva che esclusi gli outlier, il numero di rilievi si mantiene entro i 20 rilievi, ma esiste una dispersione rilevante che evidenzia la necessità di miglioramento nel processo di produzione del BRD, ovvero nella fase di analisi. La box plot della distribuzione degli NRN mostra una soddisfacente dispersione ma molti outlier, quindi suggerisce sempre un miglioramento del processo di produzione del BRD.

Nei 41 casi di studio considerati nelle precedenti osservazioni sono stati rilevati il Tipo e la Tassonomia dei rilievi nelle rispettive V&V, secondo le classi standard definite in Auriga e riportate nell’intestazione delle colonne delle rispettive tavole (Figura 2.6.a e Figura 2.6.b).

I TAM osservati sono sempre gli stessi 10. Per privacy e per assicurare che la rilevazione dei dati abbia solo lo scopo di sperimentazione, sono anonimi. Anche in questi casi di studio i TAM sono classificati nelle stesse due classi di anzianità dette prima.

(Figura 2.6.a Distribuzione dei rilievi per Tipo)

In figura 2.6.a-g è riportata la box plot della distribuzione dei rilievi tra i diversi tipi definiti dallo standard del BRD. Si rileva che i più numerosi e con maggiore dispersione sono gli “Info ambigua” e gli “omissione”. I primi indicano che il miglioramento del processo di analisi deve curare l’abilità nell’uso dello standard. Entrambi suggeriscono che deve essere curata anche l’approfondimento della conoscenza del dominio applicativo.

(Figura 2.6.a-g Distribuzione grafica dei rilievi per Tipo)

(Figura 2.6.a-g-junior Distribuzione grafica dei rilievi per Tipo per gli Junior)

Le figure che mostrano la distribuzione dei rilievi per tipo dettagliata per i Tam Junior (Figura 2.6.a-g-junior) e senior (Figura 2.6.a-g-senior) confermano la necessità di approfondire la conoscenza del dominio applicativo. Infatti gli Junior hanno entrambi i tipi di rilievi (“info ambigua” e “Omissione”) messi in evidenza con maggiore rilevanza e dispersione dei senior.

L’analisi dei dati in figura 2.6.b è più agevole se fatta attraverso la sua rappresentazione grafica per box-plot (figura 2.6.b-g). Questa evidenzia molti outlier e l’incombenza dei rilievi per “documentazione”, “funzione” e dei  “dati”. La presenta di molti outlier suggerisce che lo standard BRD è conosciuto in modo diversificato tra i soggetti sperimentali, ovvero è necessario rafforzare la conoscenza e l’abilità all’uso dello standard BRD.

(Figura 2.6.a-g-senior Distribuzione grafica dei rilievi per Tipo per i senior)

La distribuzione non cambia rilevantemente se la si dettaglia per junior e senior. Anzi sembrerebbe che i senior producano BRD di qualità inferiore in quanto a “documentazione”, a “funzione” e a Dati”. Assunto che i senior conoscano il dominio applicativo meglio che gli Junior, l’unica spiegazione ragionevole è che lo standard BRD, in termini di contenuti e di processo di produzione debba essere approfondito in Auriga.

(Figura 2.6.b-g Distribuzione grafica dei rilievi per Tassonomia)

(Figura 2.6.b-g-senior Distribuzione grafica dei rilievi per Tipo per i Senior)

(Figura 2.6.b-g-junior Distribuzione grafica dei rilievi per Tipo per gli Junior)

(Figura 2.6.b. Distribuzione dei rilievi per Tassonomia)

Sono stati eseguii 5 casi di studio da 5 TAM diversi. Poiché i BRD prodotti non hanno progetti gemelli, i tempi di produzione del BRD di Progetto sono stati confrontati con i tempi che l’analista prevede che sarebbe stato necessario per sua esperienza a produrre gli stessi BRD di Progetto. Il tempo stimato è concordato durante la V&V tra il TAM autore del BRD di progetto e i TAM che sono chiamati a ispezionare lo stesso BRD.

Le misure rilevate sono:

TBRD = tempo di produzione del BRD di Progetto con l’uso del BRD Legacy;

TPREV = tempo previsto per la produzione stesso BRD di progetto senza il BRD Legacy

TRBRD = (TPREV-TBRD)/TPREV*100 tasso di risparmio per la produzione del BRD con e senza il BRD Legacy.

La Figura 2.7 mostra i dati rilevati dai casi di studio.

(Figura 2.7. Raffronto dell’effort di produzione del BRD di Progetto con e senza il BRD Legacy)

Ai risultati numerici, è necessario aggiungere i pareri soggettivi dei TAM che hanno prodotto i BRD, i quali sostengono unanimemente che il risparmio risulta tanto più elevato quanto più vecchia è la documentazione legacy a cui si fa riferimento perché in tal caso la documentazione legacy contiene maggiore conoscenza del dominio applicativo specifico dell’ambito inerente il progetto di cambiamento. L’analisi dei risultati è immediata: il BRD legacy consente un risparmio considerevole con una media pari al 32,4% rispetto all’impegno uomo richiesto in assenza di BRD legacy.

Per rispondere a questo quesito sono stati utilizzati gli stessi casi di studio utilizzati nel Q2.6. In ognuno dei casi di studio si effettua la V&V e si misura lo NFN.

I risultati della misurazione sono mostrati in figura 2.8.

Si rileva chiaramente che gli NRN hanno una media pari a 1,18%, minore della media dei dati rilevati in figura 2.5, che è pari a 5,46%.

(Figura 2.8. Intensità di NRN nei BRD prodotti con l’ausilio del BRD Legacy)

(Figura 2.8-g. Box Plot di NRN nei BRD prodotti con l’ausilio del BRD Legacy)

Ancora più rilevante è il grafico mostrato in figura 2.8 che mostra come la dispersione del valore di NRN è molto più piccola che in 2.5-g.

In conclusione i dati mostrano che i BRD prodotti con l’ausilio del BRD-Legacy sono qualitativamente più alti e che la qualità è più neutrale rispetto all’abilità del TAM ed alla conoscenza del dominio applicativo.

È opportuno aggiungere a questa analisi quantitativa anche quella qualitativa elicitata dall’esperienza dei soggetti sperimentali di questi casi di studio, secondo cui: a maggiore età del BRD legacy corrisponde maggiore qualità del BRD di progetto prodotto. Una spiegazione plausibile di questa constatazione è che la maggiore anzianità del BRD legacy implica che i contenuti di quest’ultimo sono stati sottoposti ad un più alto numero di V&V e quindi hanno avuto maggiori opportunità di essere corretti e di diventare sempre più completi, quindi conferiscono maggiore qualità ai BRD di progetto che lo riusa.

Sono state prese, come sperimentali, 3 funzioni di business del sottosistema Gestionale:

• Lista terminali
• Dettaglio terminali
• Punto di marketing

Queste hanno versioni diverse per tutti i clienti che attualmente le usano. Questa sono state generalizzate nella forma Invarianti+Varianti. È stato rilevato il tempo per effettuare la trasformazione:

Ttrasf = tempo persona impiegato per la trasformazione dalla espressione attuale a quella nella forma invariante + varianti.

Nello specifico per le tra funzioni citate, è risultato Trasf= 91 hh-persona

Queste funzioni sono state implementate in 8 clienti diversi per altrettanti progetti di modifica delle stesse. Per l’ima versione per il cliente i_mo sono stati rilevati:

TBRDi = tempo persona di produzione del BRD di Progetto i_mo con l’uso del BRD Legacy prima della trasformazione in invariante più variante;

TVARi = Tempo persona per la produzione della variante/ delle varianti necessarie per la versione i_ma di una funzione.

Si noti che per ogni cliente la parte invariante ed eventuali parti varianti riusate sono state prodotte dalla trasformazione, quindi il tempo di produzione della parte invariante è pari a

Ttrasf/N= quota parte del tempo-persona da addebitare ad ogni cliente per la produzione della parte invariante. Essendo

N = numero di versioni della stessa funzione prodotte dopo aver trasformato la funzione in parte invariante e variante.

È evidente che maggiore sarà N e minore sarà il costo da addebitare per la produzione della parte invariante (Ttrasf/N).

Con le variabili precedenti si può calcolare il risparmio ottenuto:

Per gli 8 clienti sperimentali sono state prodotte 8 versioni diverse, secondo le esigenze degli stessi. Queste sono state prodotte una volta utilizzando il BRD legacy senza la generalizzazione Invariante+ variante ed una volta con il BRD Legacy e con quest’ultima generazione. I dati rilavati sono mostrati in figura 2.9.

(Figura 2.9 Effort speso per 8 clienti perimentati cone senza la generalizzazione del BRD legacy)

In tavola 9 è stato calcolato lo RP cumulativo man mano che la generalizzazione è riusata negli 8 progetti sperimentali. Come si vede inizialmente c’è una perdita, fin quando l’impegno-perdona speso per la generalizzazione (Ttrasf) non è ammortizzato con il riuso della generalizzazione del contenuto del BRD legacy. Dopo l’ammortamento si verifica il guadagno che aumenta con il riuso delle parti invarianti e varianti che sono state prodotte con la generalizzazione dei contenuti del BRD Legacy.

Pertanto conviene trasformare una funzione in parte invariante e parti varianti quando si presume che questa dovrà essere soggetta a diversi progetti di modifiche. Per un buon bilancio costi benefici: maggiore è l’impegno-persona richiesto per la generalizzazione, maggiore deve essere la frequenza di riuso della funzione nel futuro ciclo di vita del software.