archivo

Archivo de la etiqueta: Preproducción

Hace poco expuse en un artículo lo que eran las pruebas de aceptación. En muchos casos, se utiliza indistantemente un término u otro para referirse a lo mismo, en otros, su alcance está solapado. Respeto a quien maneja dichos conceptos como crea conveniente. Tanto en este artículo como en el anterior, les voy a dar el sentido (acertado o no) que creo más adecuado para cada uno.

Para empezar, ¿por qué la confusión entre un término y otro? Pues principalmente porque suelen venir en el mismo plan de pruebas y ejecutado por las mismas personas, sin embargo la orientación de un tipo de pruebas y la otra es distinta.

Las pruebas de implantación están orientadas a una revisión de requisitos no funcionales del producto en un entorno de preproducción de calidad. ¿Por qué de calidad? Un entorno de estas características que sea muy distinto al de producción o cuyos resultados no sean extrapolables al mismo provocará en muchos casos conclusiones erróneas y en otro generará muchas dudas sobre el cumplimiento o no de las especificaciones no funcionales.

De esta forma, se considerarán pruebas de implantación por ejemplo, las pruebas de carga o stress, las relacionadas con la seguridad del sistema, etc…

Si un producto no supera las pruebas de implantación establecidas (para ello se requiere la definición de umbrales de cada métrica cualitativa o cuantitativa que se decida medir) no debería pasarse a producción aunque supere las pruebas de aceptación (que se podrían desarrollar en paralelo a las pruebas de sistema), de las cuales también se podría obtener un feedback interesante para las pruebas de implantación, ya que las acciones de los usuarios en las aplicaciones son imprevisibles y el valor de su testing (adicional a la propia validación de requisitos) puede ser muy importante.

Las pruebas de aceptación son aquellas realizadas por los usuarios con carácter previo al paso a producción de una nueva versión del producto. Se trata de pruebas de caja negra en un entorno de preproducción en la que se verifican si las funcionalidades pactadas para la entrega y recogidas en catálogos de requisitos, casos de uso, historias de usuario u otro hito documental, cumplen las expectativas del usuario.

El problema de este tipo de pruebas es que en demasiadas ocasiones los usuarios (o sus jefes) rechazan invertir tiempo suficiente para realizar estas tareas de testing y en otras, los equipos de desarrollo tampoco ponen demasiado interés en ello.

En desarrollos siguiendo metodologías clásicas o en cascada si no se ha hecho participar al usuario en fases posteriores al análisis y no se han hecho ajustes, las pruebas de aceptación servirán para poco porque probablemente, salvo que el desarrollo sea de poco alcance, habrán variado las condiciones iniciales o bien el usuario se encontrará con una implementación que aún respetando los requisitos (que está por ver) será complicado que verifique lo que se imaginaba que iba a hacer el sistema.

Sin embargo en mantenimiento evolutivos o correctivos pequeños, ciclos de vida iterativos incrementales (con sprints de corta duración) o mediante la aplicación de metodologías ágiles, este tipo de pruebas sí que tendrían una gran utilidad porque se evita pasar evoluciones a producción que pueden afectar a un trabajo eficiente de los usuarios con la aplicación.

En el artículo anterior vimos las actividades que definían al proceso de implantación y de las consecuencias de que el tiempo necesario para realizar esa actividad superasen unos umbrales admisibles para el proyecto de desarrollo de software en cuestión.

La aplicación de una metodología o enfoque ágil o la utilización, en general, de alternativas iterativas e incrementales suponen por su propia naturaleza una disminución de los tiempos de implantación, sobre todo, una vez que ya se han realizado varias evoluciones del sistema.

Sin embargo, si el tiempo necesario para realizar las implantaciones resulta superior al tiempo de iteración definido tenemos un problema ya que provoca una acumulación de las entregas y que buena parte del tiempo invertido en el proceso de implantación se pierda. Esta situación no debería mantenerse mucho tiempo y para solucionarla sería necesario retrasar una entrega hasta que se pueda subir una acumulación de evoluciones a producción.

Estas situaciones pueden producirse en más ocasiones de las que podemos pensar, ya que lo mismo los trabajos siguiendo metodologías ágiles, parten de una versión del producto avanzada y que no ha sido implantada todavía (o no se han implantado con éxito), los equipos encargados de testing y de paso a producción tienen una carga de trabajo elevada, otras prioridades, etc…

Soy de la opinión de que para poder trabajar de manera adecuada hay que estabilizar la situación, es decir, si la implantación de un producto resulta compleja o está dando problemas, hay que centrar los esfuerzos en ella y adaptar los desarrollos que se están haciendo a esa circunstancia.

Además de la aplicación de enfoques ágiles, ayuda mucho la existencia de unos entornos de integración y de preproducción los más parecidos posibles a los de reales, la aplicación de la integración continua, la utilización de técnicas de desarrollo guiadas por las pruebas (TDD) o al menos la aplicación de una estrategia adecuada de aplicación de pruebas unitarias, para reducir de esta forma la aparición de efectos colaterales y disminuir los tiempos necesarios para las pruebas de regresión y la corrección de este tipo de incidencias.

Además de lo anterior es importante que con carácter previo a la entrega el producto haya sido probado de manera adecuada por el equipo de proyecto (nada de entregas a ciegas o de pruebas superficiales).

También resulta muy adecuado el establecimiento de itinerarios de testing (todas las aplicaciones no requieren el mismo nivel de testing, ni todas las circunstancias son similares), la aplicación de testing ágil, proporcionar a los proveedores información detallada sobre las características de nuestro entorno de producción, la aplicación de una política de prioridades a los equipos encargados del paso a producción acorde a la problemática existente en cada momento, etc…

El hecho de RUP siga un ciclo de vida que se puede considerar iterativo e incremental no implica que se le pueda considerar una metodología ágil y eso que sobre el papel podría considerarse que verifica los principios del manifiesto ágil.

Por ese motivo quien considere que RUP es ágil tienen una buena coartada. Se esté o no de acuerdo con que se considere una metodología ágil, lo que no deja dudas es que se trata de una metodología de carácter adaptativo, fruto de su vocación iterativa, incremental y unificada.

¿Por qué no lo considero una metodología ágil? Principalmente porque el marco de trabajo que define, implica liberaciones muy tardías en entornos de producción. Es cierto que en la etapa de construcción en cada iteración se pueden liberar versiones en entornos de desarrollo (o incluso preproducción) y que en las etapas finales de la construcción se pueden incluso hacer implantaciones en producción (si bien esta es la responsabilidad principal de la siguiente, la de transición).

Es decir, los usuarios seleccionados para participar en el proyecto de desarrollo de software, pueden proporcionar feedback en todas las etapas, siendo el más importante el que pueden proporcionar cuando están probando/trabajando con el sistema. Sin embargo, este feedback cuando resulta realmente valioso es cuando se está haciendo un uso real del sistema en un entorno de producción.

Esta característica, junto al hecho de que RUP plantea un marco de trabajo donde el proceso cobra una importancia especial, hace que la respuesta al cambio no sea ágil, ya que principalmente en la etapa de transición es donde se itera sobre el producto para ir adaptando el sistema a las necesidades y expectativas del usuario en aquellos aspectos en los que no se ha acertado en fases anteriores o como consecuencia de cambios en el negocio que se hayan producido durante el proceso de desarrollo.

Estas iteraciones se hacen sobre la versión del producto en la que se ha trabajado durante el ciclo de vida RUP, por lo que el esfuerzo necesario para hacer las modificaciones es mayor y en consecuencia el tiempo que tarda el usuario en poder disfrutar de ellos en el entorno de producción.

También se puede plantear el desarrollo como una secuencia de RUP, de manera que el proceso de desarrollo sea más liviano, de esta forma sí que se acercaría más a las metodologías ágiles, sin embargo, soy de la opinión de que RUP en origen tenía un enfoque más tipo big bang, orientándose a la entrega de una versión finalista del producto.

No es la primera vez que trato este tema.

Ya lo hice en el artículo “El paso a producción”, donde exponía algunas de las circunstancias que provocan que el proceso de implantación y aceptación de un sistema de información sea uno de los muros más complicados de escalar en los proyectos de desarrollo de software.

También lo hice, en el artículo “Un buen entorno de preproducción” donde exponía la necesidad de contar con una plataforma que permitiera hacer una implantación y un testing que no tuviera una desviación (o no fuera excesivamente significativa) de un entorno de explotación.

En esta entrada quiero destacar algunos aspectos que considero importantes para que la escalada del muro sea menos complicada:

– No solo son importantes entornos de preproducción que se asemejen a los entornos de producción. También resulta de gran interés disponer de entornos de desarrollo con infraestructuras similares a preproducción y producción (no necesariamente garantizando el mismo rendimiento y disponibilidad) y ponerlos a disposición de los proveedores para que de manera ágil y flexible puedan realizar implantaciones en entornos similares a donde tiene que funcionar el producto y así sea necesario recordar en menos ocasiones la siguiente cita de Vidiu Platon.

Proporcionar entornos de estas características requiere un esfuerzo, ya que supone otro nivel más de infraestructura a mantener, a la que hay que sumar la de producción (que además requiere un cuidado especial en lo que al rendimiento, disponibilidad y seguridad se refiere) y la de preproducción.

Es cuestión de analizar el esfuerzo que se requiere en los pasos a prueba y producción y determinar si es rentable hacer esta inversión. Desde mi punto de vista, en entornos donde tenemos un buen número de sistemas que interoperan entre sí (entre los que están aquellos en los que se delegan competencias) es recomendable.

Desarrollos iterativos e incrementales. Permiten que la complejidad del proceso de implantación se reparta entre diferentes entregas.

Un problema que ocurre desgraciadamente con relativa frecuencia consiste en no tener dentro del departamento TIC de una organización un entorno de preproducción.

En muchos casos, existe un entorno que se utiliza para probar aplicaciones, pero que dista mucho de ser considerado entorno de preproducción, ya que suelen tener las siguientes características:

– No se tiene seguridad al 100% que si un producto funciona en el entorno de pruebas funcione en el entorno de producción. Esto va a provocar que se produzcan casos donde una misma versión de una aplicación funcione correctamente en pruebas y no en el entorno de producción y al revés, es decir, que funcione en producción, pero que no funcione en pruebas.

– Además del problema de la falta de coherencia con el entorno de producción, se le suelen dedicar muy poco recursos hardware, esto hace que tampoco resulten muy significativas las pruebas de rendimiento que se realicen. Esto provoca además, que la realización de pruebas funcionales o pruebas de aceptación sean desesperantes, ya que suelen ser entornos con un mal tiempo de respuesta.

Es cierto que mejor tener un entorno así que nada (pero la diferencia entre eso y la nada no es mucho), pero no es conveniente conformarse con eso. La inversión en un entorno de preproducción es algo esencial, evitará muchísimos problemas y además posee un rápido retorno de la inversión.

Por tanto un entorno de preproducción resulta esencial en todo departamento TIC, por lo que no hay que mimar solo las infraestructuras de producción, debiéndose dotar de recursos hardware, software y humanos suficientes al entorno de preproducción para que sea coherente con el de producción, garantizándose que si el producto funciona correctamente en preproducción, además de cumplir los requisitos de seguridad, rendimiento, etc…, tendrá un comportamiento similar en el entorno de producción.