archivo

Archivos Mensuales: septiembre 2011

La definición de smoke testing es sencilla ya que son pruebas rápidas que se realizan sobre aspectos funcionales del software para comprobar a alto nivel si el mismo tiene el comportamiento esperado. Ahora bien, la forma y el momento de aplicación puede variar.

Lo más normal es que se aplique durante el proceso de construcción como un paso más allá a la integración continua y a las pruebas unitarias y pueden ser automáticas, manuales o mixtas, ya que lo que se pretende comprobar es si determinadas funcionalidades tienen el comportamiento adecuado.

Hay que tener en cuenta que el smoke testing más que descubrir errores concretos lo que pretende es verificar que a nivel funcional no se están produciendo incidencias graves.

En otros contextos se aplica smoke testing con caracter previo a pruebas funcionales más exhaustivas con el objeto verificar si merece la pena ponerse con ellas, es decir, si se detectan errores graves (el sistema no funciona, sea cae a la más mínima operación, no abre una pantalla que permite acceder a una funcionalidad esencial, etc…), ¿para qué perder el tiempo haciendo un testing en mayor profundidad del sistema?

También es frecuente aplicar este tipo de testing con carácter previo a una entrega al cliente, de manera que se realice una última comprobación para verificar que a alto nivel todo está bien (antes como es lógico se debería haber realizado unas pruebas en profundidad del sistema de información a todos los niveles, no solo el funcional).

Si en el nivel 3 de CMMI se entra en el detalle de cómo obtener los requisitos resulta razonable que no ignore los procesos de diseño y construcción y de esto trata este área de proceso.

Es muy importante no caer en la trampa de definir procesos poco flexibles que no permitan una adaptación a la tipología de sistemas de información y circunstancias que pueden producirse en el desarrollo y mantenimiento de los mismos. Puede ser razonable hacerlo en entornos controlados, pero en entornos variantes (como son la mayoría) hay que establecer una serie de pautas que normalicen el proceso de diseño y construcción de manera que lo que se marque sea un camino con la suficiente anchura como para elegir dentro de él la trayectoria más adecuada al proyecto pero lo suficientemente estrecho como para tener un control de la manera en que se diseñan y construyen los sistemas.

Dentro de este área de proceso se determina en qué condiciones se deben ofrecer alternativas de solución y cuál es la información que se debe suministrar en cada caso, qué criterios utilizar para seleccionar una de ellas, qué criterios, técnicas, estrategias, precondiciones, etc… tener en cuenta a la hora de realizar el diseño del sistema, qué circunstancias se deben tener en cuenta a la hora de elegir la opción más ventajosa para obtener la solución que se demanda (comprar, reutilizar o construir), qué prácticas se deben seguir para realizar la construcción del sistema y para escribir la documentación de soporte.

¿Se basa este proceso en tener y seguir un libro blanco? Hay aspectos de este área de proceso que escapan de un libro blanco convencional, como aspectos de un libro blanco convencional que van más allá de este área de proceso, no obstante para imaginarnos qué contenido tendría un proceso como este es una buena aproximación, si bien equipararlos, tal y como acabo de comentar sería caer en el error.

La siguiente reflexión de Michael Anthony Jackson muestra uno de los problemas con los que nos encontramos habitualmente cuando nos empezamos a dedicar a este negocio, si bien no todos terminan aprendiendo de la experiencia: “El origen de la sabiduría de un programador (desarrollador) se basa en conocer la diferencia entre un programa que funciona y un programa correcto. Un programa que no funciona es indudablemente incorrecto; pero un programa que funciona no es necesariamente correcto; ya sea porque es difícil de entender (utilizar), porque es difícil de mantener ante cambios en los requisitos, porque su estructura es diferente a la estructura del problema o porque no estemos seguros si funciona”.

La reflexión es del año 1975 y como suele pasar con muchas de estas máximas del desarrollo de software, más de treinta y cinco años después continúa vigente.

Un software de calidad no es un software que corre, necesita más, mucho más. Y ahí es donde está la diferencia entre un desarrollador y otro y entre una empresa de desarrollo de software y otra.

Soy consciente de que en muchas ocasiones el contexto en el que se ha desarrollado el proyecto no permite o no facilita la obtención de un sistema de calidad o de una aplicación totalmente correcta, pero la diferencia está en la intención, es decir, hay equipos de desarrollo que permanecen planos tanto cuando hay cuestas arriba como cuando las hay hacia abajo, en los que solo importa ejecutar trabajo sin preocuparse por la eficiencia del mismo, en los que solo importa que el taxímetro esté funcionando para facturar al cliente, en los que solo importa cerrar el proyecto cuanto antes, caiga quien caiga.

Muchas veces se solicitan funcionalidades manifiestamente innecesarias o cuya complejidad (y posterior utilidad) no la hace rentable.

Como sabéis, soy partidario de dejar la imaginación al área usuaria, si bien, es conveniente advertirles de los pros y contras que podría tener el desarrollo de una determinada funcionalidad.

Es cierto que en muchos casos, el área usuaria por mucho que le digas, por mucho que le adviertas, termina tomando la decisión de que la evolución se realice y no quedará otra que ejecutar el trabajo, no obstante, si pasa el tiempo suficiente (y se le vuelve a insistir), lo mismo terminan reconsiderando su decisión inicial.

Sobre el tema del desarrollo de funcionalidades que pueden ser prescindibles, en ocasiones sería conveniente recordarle a los usuarios las reglas de optimización de Michael Anthony Jackson (que si bien las enunció para la optimización de código, son perfectamente válidas para el ámbito que nos ocupa en este artículo y en otros muchos):

“Regla 1: No lo hagas.

Regla 2 (solo para expertos): No lo hagas, todavía”

En ocasiones, ante la ausencia de un gobierno funcional en el proyecto se le encarga al equipo técnico explorar los diversos departamentos afectados por el mismo, ya sea para obtener los requisitos funcionales o para intentar que utilicen el sistema.

Esto es un error, ocasionará mucho trabajo, desgaste y probablemente los resultados estén por debajo de ese esfuerzo y de la inversión realizada en el desarrollo.

Motivos:

1) En el caso de que desde etapas iniciales del proyecto no haya colaboración por parte del área usuaria en la coordinación de la selección de las funcionalidades es un síntoma de que se está desarrollando un sistema que entienden que no necesitan. Lo mismo, a nivel de organización, sí interesa su implementación, pero ese mensaje no ha llegado al área usuaria o no ha sido suficientemente convincente.

2) El problema anterior se seguirá produciendo, si no se soluciona, en las diferentes etapas del proyecto y por supuesto en su puesta en marcha: habrá usuarios que utilicen el sistema, otros que lo usen a su manera y otros que se nieguen a abandonar las herramientas (aplicaciones, soluciones ofimáticas, etc…) que venían utilizando hasta ahora.

Después, entre quienes usen el sistema habrá quienes pidan unas funcionalidades, quienes pidan otras o quienes pidan lo contrario que ha solicitado otro y nos encontraremos con el problema de definir las prioridades, de elegir una opción sobre otra, etc…

Es un mal síntoma para un proyecto de desarrollo de software cuando el personal técnico tiene que ponerse el salacot y utilizar el cazamariposas.

En el nivel 2 de CMMI, en el área de proceso: Gestión de requisitos, se pretendía principalmente:

– Inventariar/Catalogar los requisitos.
– Asegurarse de que las partes involucradas en el proyecto compartían una visión común de los mismos.
– Establecer un mecanismo para que esté controlado el proceso de cambio en los requisitos de manera que solo un grupo reducido de personas tenían la posibilidad de autorizar las modificaciones en los mismos (estando abierto a cualquiera la posibilidad de realizar solicitudes de cambio).
– Asegurar la coherencia entre los artefactos del proyecto ante las modificaciones que se aprueben utilizando como mecanismo facilitador la existencia de una trazabilidad bidireccional entre requisitos y artefactos (pudiendo ser directa o indirecta).

Se puede considerar por tanto que efectivamente lo que se pretendía era una gestión o administración de los requisitos.

En el nivel 3 se considera superado lo anterior y se centra en el proceso de obtención de los requisitos (desde la recogida y análisis de las expectativas del cliente), la asignación de los mismos al producto software y sus componentes y en su validación, por tanto se hace un enfoque en las técnicas y estrategias necesarias, con el objetivo de hacerlas repetibles entre diferentes proyectos y equipos, permitiendo la posibilidad de compartir herramientas, experiencias, disminuyendo la curva de adaptación a nuevos proyectos y propiciando un entorno orientado a la mejora continua.

El movimiento ágil me ha enseñado que afortunadamente hay luz tras la oscuridad de la cascada y los traspiés me han hecho ver que tras los sistemas que consiguen tener éxito se encuentra la simplicidad (entendiéndose como la facultad de no añadir más complejidad a la ya inherente).

Por ese motivo, hay mucho de verdad en la siguiente reflexión de Michael Anthony Jackson: “Los mejores programadores solo escriben programas sencillos”.