archivo

Archivos diarios: octubre 8, 2011

Existe un cierto grado de confusión entre lo que es smoke testing y sanity testing, sin embargo, las diferencias entre ambas técnicas son significativas, ya que sanity testing consiste en realizar pruebas de regresión tras un cambio menor que se realizan sobre una funcionalidad o un conjunto de funcionalidades concretas del sistema (constituye por tanto, un subconjunto del total de pruebas de regresión que se pueden definir o realizar sobre la aplicación).

Este testing se debe realizar con detalle pero sin salirse de lo que es el nivel de validación funcional.

Sin un plan, unos objetivos, el funcionamiento de una organización, un departamento o un proyecto va a la deriva y se guía exclusivamente por las contingencias del corto plazo y estás a merced, como un títere, de los que tienen más claro que tú lo que quieren.

Para ir a algún sitio tenemos que saber a dónde dirigirnos y determinar las acciones que tenemos que realizar para llegar allí. Para un jefe de proyectos es esencial tener claro esos objetivos y ese plan de acción. El problema de todo esto es que hasta que no te pegas unas cuantas tortas, no terminas de darte cuenta que en los proyectos necesitas tomar una dirección, que puede ser equivocada, pero una dirección.

Esa es la base, tener un plan, pero después toca sortear los obstáculos, tanto los que vienen de atrás (de la fase de venta y/o negociación del desarrollo con el cliente) como los que se producen durante el desarrollo. Si en el proyecto andamos en círculo o sin rumbo, nos tendremos que enfrentar al mismo obstáculo más de una vez y dada la complejidad que rodea al desarrollo de software y los presupuestos con los que se suele contar para llevar a cabo esta tarea, no está la cosa para invertir esfuerzos que no producen ningún tipo de avance en el proyecto.

CMMI está formado por un conjunto de áreas de proceso cuya adecuada aplicación definen un determinado nivel de madurez a una organización.

En esta serie de artículos estamos revisando los diferentes niveles de madurez con sus áreas de proceso asociadas, para la constelación de procesos orientados al desarrollo de software.

El hecho de que esté orientado a organizaciones o departamentos dentro de las mismas dedicados a esta actividad no quiere decir que se centre exclusivamente en mejorar el proceso de desarrollo de software, sino también en mejorar el propio funcionamiento de esas organizaciones o esos departamentos mediante la aplicación de los procesos definidos en CMMI y la búsqueda de la mejora continua.

No se trata solo, por tanto, de normalizar, homogeneizar, ordenar, racionalizar y armonizar el proceso de desarrollo, sino que una vez se hayan estabilizado estos procesos y haya comenzado el cambio de cultura (es lo más complicado, desde mi punto de vista, de la implantación de CMMI y, en general, de cualquier modelo organizativo orientado a los procesos, cambiar del casi todo vale a un entorno de trabajo donde se marcan unas directrices de cómo enfocar las diferentes actividades del proceso de desarrollo, ya que se confunde el paso del caos al orden con la burocracia), el siguiente paso es la mejora continua de los procesos y con ello de la organización (otros posibles pasos pueden ser la incorporación de nuevas áreas de proceso para seguir adquiriendo un mayor nivel de madurez).

En el nivel 2, ya se contemplaba la necesidad de mejora continua a nivel organizativo y orientada al conjunto de procesos definidos y a los proyectos en los que se estaba trabajando. Esto se hacía mediante el área de proceso de Medición y Análisis, por lo que se entiende que la aplicación de este área de proceso y otros áreas de proceso relacionadas (como veremos en artículos posteriores) cuentan ya con una cierta estructura a nivel de metodologías, estrategias y planes, con una cierta experiencia y con personal que ya ha participado la definición y aplicación de este tipo de procesos.

En el nivel 3, el área de proceso de Enfoque en el proceso organizativo, lo que pretende es definir, en pocas palabras, un proceso orientado a la mejora del resto de procesos en la organización, para ello es necesario:

– Determinar las oportunidades o posibilidades de mejora en los procesos de la organización (obtención de un modelo objetivo a partir del estudio de las fortalezas, debilidades, amenazas y oportunidades de los procesos implantados)

– Establecer un plan de acción que lleve de la situación actual al modelo objetivo definido.

Es necesario tener en cuenta que estas mejoras no deben situarse exclusivamente en un contexto estratégico, ya que una mejora integral y armonizada de los procesos que tenga un impacto sensible puede ser cuestión de años, sino que es necesario definir ciertas metas a un nivel táctico, para poder obtener y medir resultados a más corto plazo.

Cuando traté sobre el área de proceso de verificación, comenté su estrecha relación con este área de proceso del nivel 3 de CMMI.

La verificación comprueba que cada artefacto se ha obtenido/construido como debe y en la validación se comprueba si es correcto, por ejemplo, si un artefacto son las historias de usuario o los casos de uso, la verificación constata si se ha seguido el procedimiento y técnica definida para la obtención de los mismos, lo cual no quiere decir que sean correctos o que realmente vayan alineados con las expectativas del usuario en el sistema que se está construyendo.

Por tanto en este proceso se define, qué se valida, cómo realizar las validaciones, dónde se realizan, qué técnicas aplicar, quienes participan y qué hacer con los resultados obtenidos de la misma.