Vicente Merino preguntaba en el último post sobre la complejidad y el esfuerzo de QA: «¿Cómo evaluar el esfuerzo cuando no tienes ya código» y «¿Es posible decidir al principio del proyecto si es suficientemente importante para requerir un equipo de control de calidad independiente y formalizar un plan de pruebas? »
Imaginamos que eres responsable de TI en una empresa de telecomunicaciones. Por tanto, es de tu responsabilidad:
- que los clientes puedan conectarse en el sitio web de la empresa para ver su factura, su número de puntos, adquirir nuevos servicios, un nuevo movil, etc.
- que los empleados que atienden a estos clientes puedan conectarse al mismo sitio, sino también a otras aplicaciones para verificar la cuenta de un cliente, un problema de pago, etc.
- pues que las aplicaciones comerciales permiten vender y que las aplicaciones financieras permiten cobrar.
Un día, el director comercial y el director financiero te avisan «Vamos a tener una importante nueva oferta comercial. Las aplicaciones deben estar listas para eso dentro de dos meses»
Claro que tienes algunas preguntas para aclarar las características de esta nueva oferta con el fin de preparar un plan de proyecto y movilizar a tus equipos. Y claro que las respuestas son poco precisas: entiendes que los cambios necesarios son significativos y tocan a muchas aplicaciones. No es simplemente crear una nueva oferta pero modificar los mecanismos de venta, de promoción, de pago, etc. y las estructuras de datos para estos tratamientos.
En este ejemplo, no es posible esperar que las especificaciones están suficientemente definidas para poder iniciar el proyecto, hay que empezar lo antes posible y trabajar con los usuarios en ciclos iterativos para crear especificaciones y desarrollar a medida que se vuelven más claras. Una metodología de tipo Agile será más eficaz en esta situación.
Hemos visto en este post ‘Casos de uso – Encajar a la perfección’ como un ciclo de integración continua permite a los programadores probar el código de manera continua cuando se desarrolla. Con una estimación de la complejidad de las diferentes evoluciones para las diferentes aplicaciones, será posible decidir lo antes posible en el proyecto si se necesita una Quality Gate y un equipo dedicado para realizar pruebas de control de calidad y para cuales modulos aplicativos.
En este ejemplo, el proyecto ya se ha iniciado, lo cual no es exactamente responder a la pregunta de Vicente, pero yo sólo quería indicar que es posible determinar cuanto antes si se necesitarán los servicios de un equipo de QA y hacer una evaluación de la magnitud de esta fase y del esfuerzo de pruebas.
Consideramos ahora el caso en que la evaluación de este esfuerzo, y de hecho, de todo el proyecto, se debe realizar antes de que comience. Esta vez, el director comercial habla de un proyecto para un producto completamente nuevo y el director financiero te pregunta cuál sería el coste para desarrollar nuevas aplicaciones para los clientes y los servicios al cliente, y si sería posible reutilizar las actuales aplicaciones financieras o si se necesita crear otras nuevas.
¿Cómo evaluar las actividades y las cargas de desarrollo y de control de calidad? En tal caso, se procederá por analogía.
Incluso si se trata de un nuevo proyecto para el que no tenemos especificaciones, ya hemos hecho aplicaciones para casos de negocios similares, y podemos tratar de evaluar el tamaño y la complejidad del proyecto basándonos en los puntos de los que tenemos datos de referencia. Aqui tengo una lista proporcionada por Gustavo Terrera, con un muy buen blog dedicado a estos temas: testingbaires.com.
- Número de aplicaciones, número de módulos nuevos o a cambiar, número de funciones por módulo: tenemos un conocimiento de nuestro negocio suficiente para saber crear la cadena de las diferentes aplicaciones necesarias para esta nueva oferta e identificar módulos funcionales.
- La criticidad de cada aplicación / módulo, la criticidad de los principales tratamientos en cada módulo, a nivel de desarrollo / de pruebas, perfiles de usuario. Una vez que se ha establecido la mapa de las aplicaciones y de los módulos, podemos tratar una evaluación de la complejidad de cada uno de ellos, de nuevo procediendo por analogía con otras aplicaciones similares que conocemos bien.
- Número de bases de datos, número de programas batch, número de interfaces, número de navegadores que probar, tecnologías, lenguajes de desarrollo, pruebas de rendimiento, de seguridad … Ahora estamos interesados en la dimensión técnica, con el fin de evaluar el esfuerzo de pruebas. Podemos pedir esta evaluación al equipo de control de calidad que tiene más referencias o experiencia.
Basandonos en estos datos, se puede ahora realizar una evaluación del tiempo necesario para definir y realizar los casos de pruebas y su documentación.
Esta estimación por analogía no es necesariamente muy precisa, pero podemos conseguir uno o más escenarios para el director financiero y justificar cada uno con datos basados en nuestro conocimiento de casos similares.
Estos dos ejemplos diferentes normalmente deberían cubrir la mayoría de los casos:
- Cuando la necesidad a nivel de negocio es bastante crítica, es usual de ver el proyecto empezar sin un análisis de costes y sin una evaluación precisa de los esfuerzos de desarrollo y de control de calidad. Algunas metodologías o procesos, sin embargo, nos permiten especificar estos costes lo antes posible en el ciclo de vida del proyecto.
- Más importante el proyecto o más riesgoso para la empresa, y más se necesita calcular el retorno de la inversión. Se procederá a un análisis más riguroso de los costes potenciales, lo cual será posible con nuestro conocimiento práctico y nuestra experiencia. El problema puede ser en la existencia o la recolección de los datos, en número suficiente para poder crear un repositorio que permite la evaluación por comparación con ellos.
Sigue todavia un caso, probablemente más inusual, pero que puede ocurrir. Esta vez, el director comercial y el director financiero están estudiando la posibilidad de desarrollar una nueva estrategia en un nuevo mercado: la venta de seguros por teléfono a todos los clientes, seguro de viaje, seguro médico, seguro de accidentes, etc …
Esta vez, no tenemos referencias que nos permiten estimar, por analogía, el coste de alcanzar tal sistema, ni tenemos los conocimientos funcionales por este nuevo negocio. ¿Qué hacer?
Le pregunté a Capers Jones, sin duda la persona más experta en la estimación de costes (y puntos de función) que me envió un documento a disposición en su sitio web Namcook.com con respecto a la estimación de costes en un tal caso, utilizando un método (patentado). Se basa en un cuestionario sobre datos normalmente disponibles antes del inicio del proyecto, como por ejemplo:
- Salario promedio y cargas de trabajo del equipo del proyecto.
- Fecha de inicio y fecha de entrega del proyecto.
- Metodología de desarrollo: Agile, RUP, etc.
- Nivel CMMI del equipo del proyecto.
- Lenguajes de programación: C #, Java, SQL, etc.
- Tipo de proyecto: nuevo, de evoluciones, etc.
- Categoría del proyecto: interno, comercial, etc.
- Tipo de proyecto: cliente-servidor, aplicaciones web, etc.
- Alcance del proyecto: sub-programa, programa, sistema, etc.
- Complejidad funcional, complejidad de código, de datos, etc.
Las respuestas a estas preguntas constituyen un ‘pattern’, que se compara con un repositorio de más de 13 000 proyectos, con la idea de que los proyectos con patrones idénticos normalmente tienen un tamaño y un nivel de esfuerzo similar.
Pues se puede beneficiar de un repositorio con los datos que faltan y un método para estimar el tamaño del proyecto y el nivel de costos y riesgos. Encontrarás en el sitio Namcook todas las informaciones sobre este mñetodo ‘Software Risk Master’.
Último punto: los tres ejemplos que hemos visto se pueden combinar.
Y tú, ¿qué métodos utilizas para estimar el esfuerzo para el desarrollo y el control de calidad del proyecto?