Actualizado en agosto de 28, 2019
As probas adoptáronse como parte do desenvolvemento de software dende que se desenvolveu o software. Con todo, Business Intelligence (BI) foi máis lento para adoptar as probas como parte integrada do desenvolvemento de software de BI como IBM Cognos. Imos explorar por que BI foi máis lento para adoptar prácticas de proba e as consecuencias de NON proba.
Por que as organizacións non proban BI ...
- Restricións de tempo. Os proxectos de BI están baixo presión constante para seren entregados máis rápido. O que algunhas organizacións poden non entender é que a fase máis sinxela para reducir o tempo é a proba.
- Limitacións orzamentarias. O pensamento é que as probas son demasiado caras e non poden dedicar un equipo de probas.
- Máis rápido é mellor. Este non é necesariamente un enfoque "áxil" e só pode levalo ao lugar equivocado máis rápido.
- A mentalidade de "faino ben a primeira vez". Este enfoque inxenuo insiste en que a presenza de control de calidade debería reducir a necesidade de probas.
- Falta de propiedade. Isto é similar ao da bala anterior. O pensamento é que "os nosos usuarios o probarán". Esta visión pode levar a usuarios descontentos e moitos billetes de asistencia.
- Falta de ferramentas. A idea errónea de que non teñen a tecnoloxía axeitada para probar.
- Falta de comprensión das probas. Por exemplo,
- As probas deben avaliar a precisión e validez dos datos, a consistencia dos datos, a puntualidade dos datos, o rendemento da entrega e a facilidade de uso do mecanismo de entrega.
- As probas durante un proxecto de BI poden incluír probas de regresión, probas unitarias, probas de fume, probas de integración, probas de aceptación do usuario, probas ad hoc, probas de tensión / escalabilidade, probas de rendemento do sistema.
Cales son os custos de NON probar BI?
- Deseños ineficientes. É posible que non se descubra unha arquitectura deficiente se se ignoran as probas. Os problemas de deseño poden contribuír á usabilidade, rendemento, reutilización, mantemento e mantemento.
- Problemas de integridade dos datos. A corrupción de datos ou os desafíos de liñaxe de datos poden levar á falta de confianza nos números.
- Problemas de validación de datos. As decisións tomadas sobre datos malos poden ser devastadoras para o negocio. Non hai nada peor que tratar de xestionar mediante métricas baseadas en información incorrecta.
- Diminución da adopción do usuario. Se os números non son correctos ou se a aplicación non é fácil de usar, a comunidade de usuarios simplemente non utilizará o seu novo e brillante software de BI empresarial.
- Aumento dos custos por falta de normalización.
- Aumento dos custos para reparar defectos en etapas posteriores do ciclo de vida do desenvolvemento da BI. Calquera problema descuberto máis alá da fase de requirimentos custará exponencialmente máis que se se descubriu antes.
Agora que expuxemos por que as organizacións non proban e as trampas que se producen cando non probas BI, vexamos algúns estudos sobre probas no desenvolvemento de software.
Os estudos demostran probar a túa plataforma de BI aforrando cartos.
Un estudo de 139 empresas norteamericanas de tamaño comprendido entre 250 e 10,000 empregados, informou de custos anuais de depuración de 5.2 a 22 millóns de dólares. Este rango de custos reflicte as organizacións que non dispoñen de probas unitarias automatizadas. Por separado, a investigación de IBM e Microsoft descubriu que con probas unitarias automatizadas no lugar, o número de defectos pode reducirse entre un 62% e un 91%. Isto significa que os dólares gastados en depuración poderían reducirse desde o rango entre os 5 e os 22 millóns entre os 0.5 e os 8.4 millóns. Isto supón un enorme aforro.
Os custos para solucionar os erros aumentan rapidamente.
Un artigo sobre tácticas de desenvolvemento de software exitosas demostra que a maioría dos erros cométense no inicio do ciclo de desenvolvemento e que canto máis tempo esperas a detectar e corrixir, máis custa solucionalo. Polo tanto, non é preciso que un científico de foguetes saia a conclusión obvia de que canto máis cedo se descubran e corrixan erros, mellor. Falando de ciencia dos foguetes, acontece que a NASA publicou un artigo sobre iso: "Escalación de custos de erro durante o ciclo de vida do proxecto".
É intuitivo que os custos para solucionar erros aumentan a medida que avanza o ciclo de vida do desenvolvemento. O estudo da NASA realizouse para determinar a rapidez con que avanza o custo relativo de arranxar os erros descubertos. Este estudo utilizou tres enfoques para determinar os custos relativos: o método de custo de abaixo cara arriba, o método de desagregación de custos totais e o método de proxecto hipotético de arriba abaixo. Os enfoques e resultados descritos neste artigo presumen o desenvolvemento dun sistema de hardware / software que ten características do proxecto similares ás usadas no desenvolvemento dunha nave espacial grande e complexa, unha aeronave militar ou un pequeno satélite de comunicacións. Os resultados mostran o grao en que aumentan os custos, xa que os erros son descubertos e corrixidos en fases posteriores e posteriores do ciclo de vida do proxecto. Este estudo é representativo doutras investigacións realizadas.
No gráfico anterior, as investigacións de TRW, IBM, GTE, Bell Labs, TDC e outros mostran o custo de arranxar erros durante as distintas fases de desenvolvemento:
- O custo de arranxar un erro descuberto durante a fase de requisitos defínese como unidade de 1
- O custo para solucionar ese erro se se atopa durante a fase de deseño é dobrar Que
- Na fase de código e depuración, o custo para solucionar o erro é unidades 3
- Na fase de proba unitaria e integración, o custo para solucionar o erro faise 5
- Na fase de proba de sistemas, o custo para solucionar o erro salta a 20
- E unha vez que o sistema está en fase de operación, o custo relativo para corrixir o erro subiu a 98, case 100 veces o custo de corrixir o erro se se atopa na fase de requirimentos!
A conclusión é que é moito máis custoso reparar defectos se non se capturan cedo.
Conclusións
Realizáronse importantes investigacións que demostran o valor das probas temperás e continuas no desenvolvemento de software. Na comunidade de BI podemos aprender dos nosos amigos no desenvolvemento de software. Aínda que a maioría das investigacións formais realizáronse relacionadas co desenvolvemento de software, pódense extraer conclusións similares sobre o desenvolvemento de BI. O valor das probas é indiscutible, pero moitas organizacións foron máis lentas para aproveitar as probas formais do seu contorno de BI e integrar as probas nos seus procesos de desenvolvemento de BI. Os custos de non as probas son reais. Os riscos asociados a non as probas son reais.
¿Queres ver en acción algunhas probas automatizadas de Cognos? Vexa os vídeos da nosa lista de reprodución de premendo aquí!
