Cognos e il costo di NON testare la tua BI

Aggiornato 28 di agosto, 2019

I test sono stati ampiamente adottati come parte dello sviluppo del software sin da quando il software è stato sviluppato. La Business Intelligence (BI), tuttavia, è stata più lenta nell'adottare i test come parte integrante dello sviluppo in software di BI come IBM Cognos. Esploriamo perché la BI è stata più lenta nell'adottare pratiche di test e le conseguenze di NON test.

Perché le organizzazioni non testano la BI...

• Vincoli di tempo. I progetti di BI sono costantemente sotto pressione per essere consegnati più velocemente. Ciò che alcune organizzazioni potrebbero non realizzare è che la fase più semplice per ridurre i tempi è il test.
• Limiti di spesa. L'idea è che i test siano troppo costosi e non si possa dedicare un team di test.
• Più veloce è meglio. Questo non è necessariamente un approccio "agile" e potrebbe solo portarti nel posto sbagliato più velocemente.

• La mentalità del "fai bene la prima volta". Questo approccio ingenuo insiste sul fatto che la presenza del controllo di qualità dovrebbe ridurre la necessità di test.
• Mancanza di proprietà. Questo è simile al proiettile precedente. Il pensiero è che "i nostri utenti lo testeranno". Questo approccio può portare a utenti insoddisfatti e molti ticket di supporto.
• Mancanza di strumenti. L'idea sbagliata di non avere la tecnologia giusta per i test.
• Mancanza di comprensione dei test. Per esempio,
  • I test dovrebbero valutare l'accuratezza e la validità dei dati, la consistenza dei dati, la tempestività dei dati, le prestazioni di consegna e la facilità d'uso del meccanismo di consegna.
  • I test durante un progetto BI possono includere test di regressione, test unitari, test del fumo, test di integrazione, test di accettazione dell'utente, test ad hoc, test di stress/scalabilità, test delle prestazioni del sistema.

Quali sono i costi di NON testare la BI?

• Design inefficienti. Un'architettura scadente potrebbe non essere rilevata se il test viene ignorato. I problemi di progettazione possono contribuire all'usabilità, alle prestazioni, al riutilizzo, nonché alla manutenzione e alla manutenzione.
• Problemi di integrità dei dati. La corruzione dei dati o le sfide relative alla derivazione dei dati possono portare alla mancanza di fiducia nei numeri.
• Problemi di convalida dei dati. Le decisioni prese su dati errati possono essere devastanti per l'azienda. Non c'è niente di peggio che cercare di gestire con metriche basate su informazioni errate.

• Diminuita l'adozione da parte degli utenti. Se i numeri non sono corretti o se l'applicazione non è user-friendly, la tua comunità di utenti non utilizzerà il tuo nuovo brillante software di BI aziendale.
• Aumento dei costi a causa della mancanza di standardizzazione.
• Aumento dei costi per riparare i difetti nelle fasi successive del ciclo di vita dello sviluppo della BI. Qualsiasi problema scoperto oltre la fase dei requisiti costerà esponenzialmente di più rispetto a se scoperto in precedenza.

Ora che abbiamo spiegato perché le organizzazioni potrebbero non eseguire i test e le insidie ​​che si verificano quando non si esegue il test della BI, diamo un'occhiata ad alcuni studi sui test nello sviluppo software.

Gli studi dimostrano che testare la tua piattaforma BI consente di risparmiare denaro!

Uno studio su 139 aziende nordamericane di dimensioni comprese tra 250 e 10,000 dipendenti, ha riportato costi di debug annuali da $ 5.2 milioni a $ 22 milioni. Questa fascia di costo riflette le organizzazioni che non si disporre di unit test automatizzati in atto. Separatamente, la ricerca di IBM e Microsoft ha scoperto che con test unitari automatizzati in atto, il numero di difetti può essere ridotto tra il 62% e il 91%. Ciò significa che i dollari spesi per il debug potrebbero essere ridotti da $ 5 milioni a $ 22 milioni a $ 0.5 milioni da $ 8.4 milioni. Questo è un enorme risparmio!

I costi per correggere gli errori aumentano rapidamente.

Un documento sulle tattiche di sviluppo del software di successo dimostra che la maggior parte degli errori viene commessa all'inizio del ciclo di sviluppo e che più tempo si attende per rilevare e correggere, maggiore è il costo per la correzione. Quindi, non ci vuole uno scienziato missilistico per trarre l'ovvia conclusione che prima gli errori vengono scoperti e risolti, meglio è. Parlando di scienza missilistica, si dà il caso che la NASA abbia pubblicato un articolo proprio su questo - "Escalation dei costi di errore durante il ciclo di vita del progetto".

È intuitivo che i costi per correggere gli errori aumentino con il progredire del ciclo di vita dello sviluppo. Lo studio della NASA è stato eseguito per determinare quanto velocemente progredisce il costo relativo della correzione degli errori scoperti. Questo studio ha utilizzato tre approcci per determinare i costi relativi: il metodo del costo bottom-up, il metodo di ripartizione dei costi totali e il metodo del progetto ipotetico top-down. Gli approcci e i risultati descritti in questo documento presuppongono lo sviluppo di un sistema hardware/software con caratteristiche di progetto simili a quelle utilizzate nello sviluppo di un veicolo spaziale grande e complesso, un aereo militare o un piccolo satellite per comunicazioni. I risultati mostrano il grado di escalation dei costi, poiché gli errori vengono scoperti e corretti in fasi sempre più avanzate del ciclo di vita del progetto. Questo studio è rappresentativo di altre ricerche che sono state fatte.

Dal grafico sopra, le ricerche di TRW, IBM, GTE, Bell Labs, TDC e altri mostrano il costo della correzione degli errori durante le diverse fasi di sviluppo:

• Il costo per correggere un errore scoperto durante la fase dei requisiti è definito come 1 unità
• Il costo per correggere quell'errore se riscontrato durante la fase di progettazione è doppio che
• Nella fase di codice e debug, il costo per correggere l'errore è unità 3
• Nella fase di unit test e integrazione, il costo per correggere l'errore diventa 5
• Nella fase di test dei sistemi, il costo per correggere l'errore sale a 20
• E una volta che il sistema è in fase di funzionamento, il costo relativo per correggere l'errore è salito a 98, quasi 100 volte il costo per correggere l'errore se riscontrato in fase di richiesta!

La linea di fondo è che è molto più costoso riparare i difetti se non vengono scoperti in anticipo.

Conclusioni

Sono state condotte ricerche significative che dimostrano il valore di test precoci e continui nello sviluppo del software. Noi, nella comunità BI, possiamo imparare dai nostri amici nello sviluppo del software. Anche se la maggior parte della ricerca formale è stata condotta in relazione allo sviluppo del software, è possibile trarre conclusioni simili sullo sviluppo della BI. Il valore dei test è indiscutibile, ma molte organizzazioni sono state più lente nell'avvantaggiarsi dei test formali del proprio ambiente BI e nell'integrare i test nei propri processi di sviluppo BI. I costi di non i test sono reali. I rischi associati a non i test sono reali.

Vuoi vedere alcuni test Cognos automatizzati in azione? Guarda i video sulla nostra playlist di cliccando qui!