viernes, 30 de noviembre de 2012

Economizar con Software Quality Assurance: Parte II

Parte II, por Hernan Gil

Análisis de costos
Implementar alguna o todas las actividades descriptas en la entrega anterior, implica tiempo, esfuerzo y, sin dudas, dinero. Por esa razón, es necesario analizar el ROI de esta implementación, para lo cual nos basaremos en un estudio que analiza las etapas de un proyecto tradicional, y los defectos introducidos, los encontrados y el costo de su reparación. Como se puede apreciar, la introducción del 85% de los defectos de la aplicación se produce al inicio de la etapa de construcción, pero estos defectos se van encontrando paulatinamente, en etapas posteriores.
Mientras más se demore en encontrar un error, más costoso será repararlo. Por eso se propone establecer actividades que acompañen al proceso de desarrollo (en vez de puntos de control), para maximizar la detección de defectos en cada etapa, y minimizar la cantidad y el impacto de los defectos que se encuentran en las etapas finales. Es importante tratar de calcular el costo de un defecto encontrado durante el testing versus encontrarlo luego de la puesta en producción, ya que el costo asociado a este último no es sólo el que se produce al generar una nueva versión, sino que también se le suma el del test de regresión, la nueva puesta en producción y el tiempo que esté bajo el sistema.

¿Por dónde empezamos?
Implementar todas las actividades de SQA al mismo tiempo es costoso e impráctico. Es mejor empezar por las actividades en las que se vean resultados de forma más rápida y efectiva.
Además, una implementación paulatina y retroalimentada ayudará a que el proceso sea más armonioso y fácilmente aceptado. Si se está en las etapas iniciales del proyecto, conviene empezar por la verificación de requerimientos y la validación de arquitectura, mientras que si ya se está avanzado, es mejor revisar el diseño o, directamente, el código.


Fases y disciplinas de UP: relación con las actividades de SQA.

Métricas de calidad
La única manera de mostrar cuáles son los beneficios que aportan las actividades de SQA es a través de métricas que reflejen la evolución del proceso de desarrollo. Si no podemos medir las mejoras, no podremos evaluar la efectividad del proceso de SQA y tampoco será posible mejorarlo. Ejemplos de este tipo de métricas podrían ser:

  • Número de incidencias reportadas en producción.
  • Número de incidencias reportadas en testing.
  • Cantidad de ciclos de testing/retrabajo necesarios.
  • Tiempo necesario para realizar un cambio (categorizado por impacto).

Conclusiones
SQA es un conjunto de actividades que tienen como objetivo bajar el costo de desarrollo para alcanzar los parámetros de calidad establecidos.
Es factible alcanzar calidades y costos determinados, pero es necesario saber que no es posible insertar calidad deseada al final del proceso de desarrollo, sino que se debe crear a lo largo de todo el proceso. Cuanto antes se comience con las actividades de SQA, mayores serán los beneficios obtenidos.