Actualitzat 28 d'agost, 2019
Les proves s’han adoptat àmpliament com a part del desenvolupament de programari des que s’ha desenvolupat el programari. No obstant això, Business Intelligence (BI) ha estat més lent a adoptar les proves com a part integrada del desenvolupament de programari de BI com IBM Cognos. Explorem per què BI ha estat més lent a adoptar pràctiques de proves i les conseqüències de NO proves.
Per què les organitzacions no proven BI ...
- Restriccions de temps. Els projectes de BI estan sotmesos a una pressió constant perquè es lliurin més ràpidament. El que algunes organitzacions poden no adonar-se és que la fase més senzilla per reduir el temps és la prova.
- Restriccions pressupostàries. El pensament és que les proves són massa costoses i no poden dedicar un equip de proves.
- Més ràpid és millor. No és necessàriament un enfocament “àgil” i només us pot portar al lloc equivocat més ràpidament.
- La mentalitat de "fer-ho bé la primera vegada". Aquest enfocament ingenu insisteix que la presència de control de qualitat hauria de reduir la necessitat de proves.
- Falta de propietat. Això és similar a la vinyeta anterior. El pensament és que "els nostres usuaris ho provaran". Aquest enfocament pot provocar usuaris descontents i moltes entrades d'assistència.
- Manca d’eines. La idea errònia que no tenen la tecnologia adequada per fer proves.
- Manca de comprensió de les proves. Per exemple,
- Les proves haurien d’avaluar la precisió i la validesa de les dades, la coherència de les dades, l’actualitat de les dades, el rendiment de la publicació i la facilitat d’ús del mecanisme de publicació.
- Les proves durant un projecte de BI poden incloure proves de regressió, proves d’unitats, proves de fum, proves d’integració, proves d’acceptació d’usuaris, proves ad hoc, proves d’estrès / escalabilitat, proves de rendiment del sistema.
Quins són els costos de NO provar BI?
- Dissenys poc eficients. És possible que no es descobreixi una arquitectura deficient si s’ignoren les proves. Els problemes de disseny poden contribuir a la usabilitat, rendiment, reutilització, manteniment i manteniment.
- Problemes d’integritat de les dades. La corrupció de dades o els desafiaments del llinatge de dades poden provocar la manca de confiança en les xifres.
- Problemes de validació de dades. Les decisions sobre males dades poden ser devastadores per al negoci. No hi ha res pitjor que intentar gestionar mitjançant mètriques basades en informació incorrecta.
- Disminució de l'adopció d'usuaris. Si els números no són correctes o si l'aplicació no és fàcil d'utilitzar, la vostra comunitat d'usuaris no utilitzarà el vostre nou i brillant programari de BI empresarial.
- Augment dels costos per manca d’estandardització.
- Augment dels costos per reparar defectes en les etapes posteriors del cicle de vida del desenvolupament de BI. Qualsevol problema descobert més enllà de la fase de requisits costarà exponencialment més que si es descobrís abans.
Ara que hem exposat per què les organitzacions poden no provar i les trampes que es produeixen quan no proveu BI, anem a veure alguns estudis sobre les proves en el desenvolupament de programari.
Els estudis demostren que la prova de la vostra plataforma de BI estalvia diners.
Un estudi de 139 empreses nord-americanes amb una mida que oscil·lava entre 250 i 10,000 empleats, va informar de costos anuals de depuració de 5.2 a 22 milions de dòlars. Aquest rang de costos reflecteix les organitzacions que no tenen instal·lades les proves d’unitats automatitzades. A part, la investigació d'IBM i Microsoft va trobar això amb una prova automàtica d’unitat al seu lloc, el nombre de defectes es pot reduir entre un 62% i un 91%. Això significa que els dòlars invertits en depuració es podrien reduir del rang de 5 a 22 milions de dòlars a l'interval de 0.5 a 8.4 milions de dòlars. Això suposa un estalvi enorme!
Costos per solucionar errors ràpidament.
Un article sobre tàctiques de desenvolupament de programari reeixides demostra que la majoria dels errors es cometen al començament del cicle de desenvolupament i que, quant més temps espereu a detectar i corregir, més costarà solucionar-los. Per tant, no cal que un científic coet arribi a la conclusió òbvia que, com més aviat es detectin i es corregeixin els errors, millor. Parlant de ciència dels coets, passa que la NASA va publicar un article sobre això: "Escalada de costos d'error a través del cicle de vida del projecte".
És intuïtiu que els costos per solucionar els errors augmenten a mesura que avança el cicle de vida del desenvolupament. L'estudi de la NASA es va realitzar per determinar la rapidesa amb què avança el cost relatiu de la correcció d'errors descoberts. Aquest estudi va utilitzar tres enfocaments per determinar els costos relatius: el mètode del cost ascendent, el mètode de desglossament del cost total i el mètode hipotètic del projecte descendent. Els enfocaments i els resultats descrits en aquest article suposen el desenvolupament d’un sistema de maquinari / programari que tingui característiques del projecte similars a les utilitzades en el desenvolupament d’una nau espacial gran i complexa, d’un avió militar o d’un petit satèl·lit de comunicacions. Els resultats mostren el grau d’escalada dels costos, ja que es van descobrint i corregint errors en fases posteriors i posteriors del cicle de vida del projecte. Aquest estudi és representatiu d'altres investigacions realitzades.
A partir del gràfic anterior, la investigació de TRW, IBM, GTE, Bell Labs, TDC i altres mostra el cost de la correcció d'errors durant les diferents fases de desenvolupament:
- El cost de solucionar un error descobert durant la fase de requisits es defineix com 1 unitat
- El cost de solucionar aquest error si es troba durant la fase de disseny és doble que
- A la fase de codi i depuració, el cost per solucionar l’error és de unitats 3
- A la fase de prova i integració de la unitat, es converteix en el cost per solucionar l’error 5
- A la fase de prova de sistemes, el cost per solucionar l’error puja a 20
- I un cop el sistema estigui en fase d’operació, el cost relatiu per corregir l'error s'ha elevat a 98, gairebé 100 vegades el cost de corregir l'error si es troba a la fase de requisits!
La conclusió és que és molt més costós reparar defectes si no es detecten aviat.
Conclusions
S'han dut a terme investigacions significatives que demostren el valor de les proves primerenques i contínues en el desenvolupament de programari. A la comunitat de BI, podem aprendre dels nostres amics en el desenvolupament de programari. Tot i que la majoria d’investigacions formals s’han fet relacionades amb el desenvolupament de programari, es poden extreure conclusions similars sobre el desenvolupament de BI. El valor de les proves és indiscutible, però moltes organitzacions han estat més lentes en aprofitar les proves formals del seu entorn de BI i integrar les proves en els seus processos de desenvolupament de BI. Els costos de no les proves són reals. Els riscos associats no les proves són reals.
Voleu veure algunes proves automatitzades de Cognos en acció? Mireu els vídeos de la nostra llista de reproducció de fer clic aquí!
