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”.

En el nivel 2 de CMMI se pretende dar un primer paso para normalizar el funcionamiento de la organización mediante la definición de procesos en diferentes áreas de actuación.

Estos procesos se podían definir a nivel de proyecto, con el objeto de que el tránsito del caos al orden fuera asumible por un equipo de personas (y una cultura de empresa) que no estaban habituados a trabajar de esta forma y tampoco perseguían un grado de formalismo y de nivel de detalle importante, sino el establecimiento de una serie de una pautas que pudieran ser seguidas y cumplidas en los diferentes proyectos.

Como ya comenté en las conclusiones sobre el nivel 2, llegar a alcanzar este nivel de madurez está en la mano de prácticamente cualquier organización que se lo plantee, ya que se tratará de darle forma a diferentes procesos que ya se realizan de manera informal (o poco formal) y añadir otros que tampoco supondrán ningún tipo de sobreesfuerzo, de manera que se podrán disfrutar de los beneficios de una gestión de estas características con un coste perfectamente asumible.

En mucha de la bibliografía sobre CMMI se le denomina a esto gestión o administración básica de proyectos. En mi opinión, no se trata de algo básico, sino de un nivel más, que lo mismo es la solución que más conviene en un momento dado para una organización. La palabra básico asociada al nivel 2 de CMMI le resta fuerza, importancia y entiendo que no debe ser así.

El nivel 3 de CMMI pretende dar un paso más, mediante la definición de procesos de ámbito organizativo en los cuales además existirá un mayor nivel de detalle, dejando un menor margen a la interpretación de la definición de los mismos.

Es una consecuencia lógica del nivel 2, es decir, si ya se han consolidado procesos a nivel de proyecto lo siguiente es la abstracción de los mismos y definir una política a nivel de la organización, es más, es muy posible que cuando se decida implantar un nivel 2, se decida que determinados procesos sean de carácter general.

Además de lo anterior el nivel 3 exige un mayor control en el proceso de construcción del producto, ir un paso más allá en las técnicas de gestión de proyectos y dar una mayor formalidad a la mejora continua de los procesos y su ejecución.

Es importante entender que el hecho de que se definan procesos a nivel de organización no quiere decir que en los mismos se especifiquen diferentes escenarios a aplicar en función de la naturaleza del proyecto (el número de escenarios debe ser coherente, controlable y orientado a poder reutilizar todas las técnicas, estrategias, herramientas y procedimientos que sean posibles). Se rompe, por tanto, con la posibilidad que da el nivel 2 de que cada proyecto sea un islote independiente (ordenado, pero independiente), pero existe el margen de que se puedan aplicar estrategias diferentes en función de la naturaleza del proyecto, siempre que, eso sí, proyectos que compartan dicha naturaleza tengan las mismas actuaciones a nivel procedimental.

Fresh software es lo primero que se me viene a la cabeza cuando pienso en la empresa de desarrollo de software que hace poco han abierto mis amigos Javi y Sergio.

Zuinq Studio es el resultado de la creatividad y talento de dos ingenieros de software para los que no existe límite en los retos que se le plantean y que se plantean, de ahí la heterogeneidad de los desarrollos que han realizado hasta ahora, que van desde el desarrollo de soluciones para dispositivos móviles (en las cuales son expertos), desarrollo de soluciones web (otra de sus especialidades), desarrollo de plugins, realidad aumentada, etc…

¿Por qué fresh software? Pues porque la palabra fresh, aúna buena parte de las características del software que desarrollan y del espíritu de ambos: nuevo, fresco, limpio, descarado, etc…

Si queréis conocerlos con mayor detalle, el enlace a su sitio web es el siguiente: Zuinq Studio.

Bogdan Bereza-Jarocinski es un desarrollador de software y psicólogo polaco especializado en la calidad del software, más concretamente en el campo del testing. No obstante, ha pasado prácticamente por los diferentes perfiles clásicos por los que suele pasar un desarrollador: programador, analista, jefe de proyectos…

Me ha resultado interesante una reflexión que realizó en el año 2000, sobre el proceso de automatización del testing (traducción libre): “Introducirse en la automatización de las pruebas es, a veces, como un romance: tormentoso, emocional, en ocasiones un fracaso y en otras un éxito espectacular”.

Esta cita puede ser válida en muchos campos del desarrollo de software cuando existe un cambio de la manera en que tradicionalmente se han hecho las cosas a otra diferente: nunca es fácil, genera un cierto desgaste, siempre aprendes y el resultado puede ser bueno o nefasto.

La automatización del testing, en todos los niveles, no solo a nivel de la definición de pruebas unitarias o la aplicación de técnicas orientadas a las mismas como TDD, supone un cambio de mentalidad importante en el desarrollo de software, ya que es la consecuencia de entender, por fin, que:

– El software es de naturaleza adaptativa o evolutiva, donde los mismos usuarios van refinando con el uso del producto la idea que tenían inicialmente del mismo y donde los mismos procesos de negocio evolucionan, dando lugar a nuevas versiones de la aplicación.

– Donde la calidad del software es un objetivo esencial a conseguir por cualquier desarrollador y que parte de esa calidad final depende de la capacidad de localizar errores en las etapas más tempranas posibles (para reducir los costes asociados a su corrección) y para reducir el número y criticidad de los mismos que llegan a entornos de producción.