archivo

Archivo de la etiqueta: pruebas de integración

Cuando se desarrolla una serie de módulos de una aplicación por parte de un equipo de trabajo dentro de un equipo de proyecto y/o la producción se encuentra delegada en diferentes equipos existe un cierto temor por cada uno de ellos por integrar su trabajo dentro de la línea principal del producto (a incluso más bajo nivel los propios programadores tiene un cierto respeto a consolidar sus desarrollos dentro de la línea de trabajo en la que colabora).

Si este temor se traduce en retrasar todo lo posible el proceso de integración, no solo no conseguiremos evitar lo inevitable (que es tener que integrar) sino que además el número de problemas que nos encontraremos será, por regla general, mucho mayor que si hubiéramos realizado una integración continua o, al menos, con una periodicidad razonable. Algo que lo mismo obliga a tirar buena parte del trabajo realizado.

La programación defensiva es el resultado de la aplicación de una serie de técnicas que tienen como objetivo minimizar el número de errores que puede presentar un sistema de información, así como presentar una arquitectura y código que además de servir de soporte al objetivo anterior permita realizar un mantenimiento del sistema de la forma más limpia posible y minimizando o eliminando posibles efectos colaterales.

Aplicar esta técnica requiere incrementar notablemente el número de controles y comprobaciones que se realizan desde el código ya que se querrán dar respuesta al mayor número de casuísticas posibles, así como ser muy metódico en la aplicación de pruebas unitarias, pruebas de integración y pruebas de sistema desde etapas muy tempranas del desarrollo.

Todo lo anterior sin olvidarnos de las correspondientes pruebas de seguridad y pruebas de rendimiento.

Este testing será realizado tanto por el equipo de proyecto como por uno o varios equipos externos los cuales inclusos pueden estar especializados en un área concreta de testing.

De igual forma se requerirá que las especificaciones estén lo más cerradas y validadas posibles por el cliente o por el usuario, en este caso, el margen de error y la aproximación mediante la combinación feedback e iteraciones es mucho menor, por lo menos a nivel del producto en producción, donde deberá entrar con plenas garantías de acabado y funcionamiento.

También, el uso de componentes externos o de la delegación de competencias en terceros sistemas requerirá tener de los mismos unas garantías similares a la del sistema que se está desarrollando (toda cadena se rompe por el eslabón más débil).

En sistemas considerados críticos, donde se ponga en juego la vida o la integridad de las personas, así como aquellos que pueden afectar de manera sensible al funcionamiento de una organización y a su economía, la aplicación de este tipo de estrategias cobra especial sentido.

Es importante tener en cuenta que no solo es cuestión de técnicas, también es cuestión de un cambio de actitud cuando nos enfrentamos a este tipo de desarrollos, por eso es importante que un porcentaje elevado de personas que participan en estos proyectos tengan experiencia en los mismos, así como que ocupen todos los puestos críticos del proyecto.

Martin Fowler creó el concepto de integración continua como una técnica o estrategia que consiste en programar automáticamente el proceso de compilación y ejecución de pruebas unitarias de un software que se está desarrollando.

El objetivo de la técnica consiste en detectar errores unitarios y de integración lo antes posible. Si se dejan estas comprobaciones para etapas muy tardías del proyecto los costes de corrección de estas incidencias se disparan) sobre todo en equipos de proyecto de tamaño medio o grande que trabajan en diferentes localizaciones).

No es una estrategia exclusiva de metodologías ágiles (podría ser utilizada perfectamente en metodologías del proceso unificado como RUP o en la fase de construcción de metodologías clásicas como por ejemplo el ciclo de vida en cascada), si bien su aplicación en las mismas resulta de gran importancia tanto en el proceso de desarrollo como para reducir los tiempos de implantación del sistema.

Se entiende integración continua cuando el proceso se programa para que se ejecute automáticamente. También podría considerarse cuando la integración se realice de forma planificada, aunque se realice de forma manual, en intervalos razonablemente cortos de tiempo. No es integración continua si se ejecuta de manera esporádica o en momentos próximos a la entrega.

Si problemático resulta el desarrollo de software, el paso a producción en muchos casos no lo es menos. La implantación de un sistema de información con una cierta envergadura no es un proceso trivial y es necesario, en el caso de que el tiempo que se tarde no sea bueno, medir y mejorar el proceso para intentar alcanzar una mejora continua que lleve a unos umbrales aceptables.

Jim Highsmith, firmante del manifiesto ágil, hace una reflexión sobre este tema en su artículo “Shortening the tail“.

Este autor denomina como “tail” a todo el proceso posterior a que una evolución de un producto se considere terminada por parte del equipo de proyecto. En este proceso se incluirían las actividades de testing, pruebas de regresión, integración, pruebas de integración, documentación, corrección de incidencias de la entrega y paso a producción.

De hecho la definición exacta que da de tail es todavía más elocuente (voy a dejar algunas palabras en inglés para no restar significado): Es el tiempo transcurrido desde el “code slush” o “feature freeze” hasta el despliegue del producto.

Comenta Jim Highsmith que el tail más largo que encontró fue de dieciocho meses. Afortunadamente no he tenido uno tan largo, los peores tiempo con que me he encontrado han sido de tres o cuatro meses, si bien, ha sido debido generalmente a que el proceso de desarrollo lo había fraccionado en varias entregas, lo que daba lugar a que el tiempo se repartiera entre las mismas. Probablemente si sumara los tiempos de las mismas serían muy superiores a los meses que he indicado.

Tail de larga duración para entregas o evoluciones simples son un problema, ya que marcan el tiempo en el que un usuario por término medio podrá disfrutar de una evolución del producto (no cuento los posibles parches rápidos que se puedan instalar, ya que estos, generalmente tienen otro proceso de implantación).

Estas evoluciones en muchos casos no son caprichos, sino necesidades que si no son cubiertas provocan una ineficacia en el trabajo desarrollado por los usuarios y en consecuencia un impacto en los resultados del departamento y en consecuencia de la organización. Es por ello que se debe dar la importancia que se merece la optimización de estos tiempos.

Uno de los aspectos que más me preocupan en el desarrollo de proyectos informáticos es que el producto llegue al entorno de producción con el menor número de errores funcionales, que tenga un buen rendimiento y sea fácilmente mantenible a nivel de código y de documentación.

Esto que parece de perogrullo, es tremendamente difícil sobre todo si nos encontramos con proyectos de una gran envergadura con un parque de usuarios heterogéneo en localizaciones dispersas con distintos nivel de calidad en su ancho de banda.

Después de analizar las metodologías de desarrollo clásicas como Métrica v.3 y tratar de hacer uso de ella en mis proyectos (más bien un subconjunto de ella, pero aunque sea un subconjunto, por definición de Métrica v.3 sigue siendo Métrica v.3) he llegado a la conclusión de que sin ser una mala opción, hay algunos aspectos que sí es conveniente centrarse y en otros menos:

– Plan de proyecto. Contendrá el cronograma del proyecto (lo mejor es que ese cronograma se mantenga con una herramienta informática compartida: Redmine, dotProject, etc…), por lo que valdrá con una referencia a la url donde se puede seguir el cronograma del proyecto, el equipo de proyecto (igualmente lo mejor es que ese equipo de proyecto se vaya actualizando, por tanto lo mejor es una herramienta informática compartida y si es la misma que la del cronograma, mejor que mejor y se sepa si así lo desea el cliente su imputación de horas al proyecto) y la documentación que deberá acompañar al proyecto.

– Lo fundamental en un proyecto de desarrollo de software son los requisitos. La empresa que posea analistas con la suficiente capacidad para obtener del usuario lo que quiere (cosa tremendamente difícil) tienen una ventaja muy importante respecto a sus competidores. Este catálogo de requisitos es fundamental tenerlo actualizado en todas las fases del proyecto, incluido el mantenimiento. Si es necesario dedicar tiempo a una fase del proyecto concreta esta es el análisis de requisitos. El catálogo de requisitos debe ser completo y fácilmente inteligible por el usuario. Si hay presupuesto en el proyecto y puede facilitar el proceso de desarrollo el analista puede trabajar con los diagramas de casos de uso.

– Modelo de datos. Muy importante tenerlo documentado en la versión 1 del proyecto. Para posteriores versiones, si en el mantenimiento hay presupuesto y tiempo (aspectos no siempre disponibles) se puede mantener la documentación del modelo de datos, en caso contrario no pasa nada, siempre hay herramientas que te los puede obtener por ingeniería inversa a través de la base de datos.

– Interfaz de usuario. Es fundamental que el usuario conozca y valide la interfaz de usuario, ya que es donde ellos van a trabajar, de nada vale saber lo que quiere el usuario si después la interfaz de usuario no es ágil. Por este motivo también conviene invertir en esta fase del proyecto. Cuanto más se aproxime esta interfaz de usuario a su implementación real, más conciencia tendrá el usuario de lo que se va a encontrar y por tanto más posibilidades de éxito existen en el proyecto.

– Arquitectura del sistema. Debe ser breve, conciso y cuanto más gráfico mejor. Es importante para proyectos donde se deleguen funcionalidades en terceras herramientas (motor de tramitación, plataformas de autenticación y firma electrónica, etc…).

– Plan de pruebas (unitarias, integración, sistema, implantación y aceptación). Aunque es una realidad que nosotros, los clientes, tengamos nuestros propios medios para garantizar la calidad de las entregas, son absolutamente necesarias dos premisas: Que la empresa desarrolladora realice un primer filtro de pruebas muy importante (nunca es perdido el tiempo que se dedica a probar) y que se entregue un manual de pruebas al cliente donde como mínimo se pueda garantizar, tras realizar las pruebas, que el sistema funciona y que además verifica los requisitos funcionales y no funcionales más importantes.

– Manual de usuario. Debe estar siempre actualizado. Ser muy completo y tener casos de uso reales en los que se refleje, al menos, el 90% de la casuística del programa. Si el manual está accesible on-line por los usuarios mejor que mejor, independientemente de eso es aconsejable que sea también fácilmente imprimible.

A todo lo anterior es necesario sumar la necesidad de utilizar un sistema de control de versiones buenos, como por ejemplo Subversion y hacer un buen uso del mismo (política correcta de etiquetado de versiones, etc…), utilizar unos mecanismos estándar para el despliegue de los proyectos: MAVEN + Hudson + Artifactory, por ejemplo y algo fundamental, un libro blanco de desarrollo que homogeinice los desarrollos que se realizan para tu organización.