Curso de técnicas de desarrollo – Manual del alumno

Ciclo de vida del desarrollo de una aplicación

Para lograr un desarrollo sostenible es importante conocer y respetar el ciclo de vida de una aplicación.

El ciclo explicado enseguida sirve tanto para el desarrollo de nuevas aplicaciones como para modificar una aplicación existente.

Cuando se desea cambiar unas varias partes de una aplicación se agrupan en un proyecto, y el proyecto sigue el ciclo de vida explicado abajo.

Dependiendo del tamaño de la aplicación y de la empresa, las etapas tomarán más o menos importancia. Entre más grande es la aplicación, más importante es de pegarse a cada paso.

Para aplicaciones grande y/o importantes, se utilizan varios ambientes. Es decir que la aplicación existe en varios ejemplares. Debería de tener siempre un mínimo de dos ambientes: producción y desarrollo. Otros ambientes pueden ser el ambiente de integración, el de prueba de usuario, el de capacitación, y el de referencia.

Establecimiento de los requisitos

Es a veces lo más difícil de conseguir, pero es lo más importante. Los usuarios o el cliente deben explicar claramente que es lo que él quiere.

Para eso él debe listar todos sus requisitos de manera detallada.’Haga como en tal otro modulo…’ no se puede aceptar como un requisito válido, pero le concedo que a veces hay que aceptarlo (el cliente es rey…).

Cuando los requisitos no están muy detallados, es muy importante detallarlos en el análisis funcional, para estar seguro que lo que se va a desarrollar es lo deseado.

Estimación de alta nivel

Este paso es opcional. Es una estimación ‘a primera vista’ del esfuerzo (trabajo) necesario para implementar los cambios o desarrollar la aplicación requerida.

Eso sirve para estimar el costo y planificar los recursos necesarios.

Diseño funcional

Es la traducción de los requisitos (punto 2.2) en un diseño ‘informático’. Por ejemplo, se describirá como parecerán las pantallas del GUI, los flujos de pantallas y los flujos de negocios que se implementarán.

La persona que redacta el diseño funcional debe tener una idea general que como se implementará a nivel técnico, para evitar de proponer en el diseño algo que no se puede implementar, o que pediría un esfuerzo demasiado grande para implementar.

Es buena idea que un programador revisa este diseño ante que se le presenta al cliente, para tener un acuerdo tácito de que, a primera vista, se puede implementar al nivel técnico dentro del costo (tiempo) estimado.

En caso que se hizo una estimación de alta nivel, el esfuerzo/costo se puede confirmar, afinar, o modificar aquí.

El objetivo es que el cliente ‘firma’ el diseño funcional como acuerdo de los que se va a desarrollar. Este documento servirá de base para la evaluación (prueba) de la aplicación.

Si al final algo no funciona como esperado, hay que regresar al diseño funcional para averiguar si el punto que da problema estaba presente en el diseño o no. Si no estaba ni en el diseño ni en los requisitos, se trata de un nuevo requisito (a cargo del cliente). Si está presente y funciona como descrito, es se trata de un cambio de requisito (a cargo del cliente). Si está presente pero no funciona como descrito, es un error de programación que hay que corregir (a cargo del desarollador).

Un ejemplo de diseño funcional está disponible en el CD (AF Siminsa en linea.pdf).

Diseño técnico

Es la traducción del diseño funcional en una solución técnica. Se describe la arquitectura técnica que se va a utilizar para programar lo requerido.

El diseño técnico no debería de contener código fuente, si no la estructura del código que se va a utilizar y de los cambios necesarios. Que sean cambios de la base de datos, nuevos objetos Java, servlet, …

Una vez finalizado, este diseño debería ser revisado y aprobado por el analista funcional ante de iniciar el desarrollo.

Desarrollo

Es la aplicación del diseño técnico y el propio desarrollo de la aplicación.

En caso que se hizo una estimación de alta nivel, el esfuerzo/costo se puede confirmar, afinar, o modificar aquí.

En caso que se encuentra algún problema (la solución imaginada no funciona o da problemas), hay que revisar la situación con el analista funcional, y eventualmente el cliente si el impacto es grande.

Pruebas unitarias

Después de haber hecho su desarrollo, el programador debe probar su código de manera unitaria. Es decir, cada código aparte sin tener en cuenta la totalidad de la aplicación. Las pruebas se deberían de hacer en condiciones similar a la producción. Es decir que si la aplicación funciona en 3-tiers, hay que probarla en 3-tiers también.

Las pruebas hechas se deben registrar y presentar al analista funcional para poder concluir que el código está listo para pasar al ambiente de integración.

Plan de prueba

Una vez el diseño funcional aprobado, el analista funcional y los usuarios deberían (cada uno) que escribir un plan de prueba.

El plan de prueba debe contener además de las pruebas del código nueva, pruebas de regresión, para verificar que las principales funciones de la aplicación preexistente no han sido impactadas de manera no deseada.

Integración

Este paso es el puesto en común de todas las modificaciones de la aplicación, ya que varios proyectos diferentes pueden desarrollarse en paralelo, y que más de un programador puede trabajar en el proyecto.

Aquí es que el analista funcional hará sus pruebas para validar la aplicación, antes de entregarla al cliente.

Las pruebas deberían ser documentadas, así como los problemas encontrados.

Además de probar las nuevas funciones o cambios del sistema, se debe siempre efectuar pruebas de regresión para asegurarse que todas las funciones importantes de la aplicación, mismo si no han sido modificada directamente, siguen funcionando como esperado.

Pruebas de usuarios

Aquí son los usuarios que van hacer sus pruebas.

Las pruebas deberían ser documentadas, así como los problemas encontrados.

Una vez las pruebas terminadas, el cliente decide si él está de acuerdo que la aplicación pasa a producción o no.

Pruebas de rendimiento

Aquí se va a probar el rendimiento de la aplicación. Las pruebas de rendimiento se deberían efectuar sobre un ambiente lo más parecido posible a la producción.

Se van a probar entre otros la carga que soporta el sistema, el tiempo de ejecución de los interfaces ‘batch’, y el rendimiento de las diferentes partes del sistema.

El objetivo es detectar antes de producción posibles problemas de rendimientos (por ejemplo consulta SQL no optimizada), y conocer las límites de carga del sistema (usuarios, transacciones, …). Existen programas que permiten generar carga del sistema simulando múltiples usuarios., como JMeter.

Producción

Aquí es donde se usa finalmente la aplicación. Debe ser un ambiente estable. La producción no se debería de modificar muy seguido.

Parches

Los parches son correcciones de códigos por errores que no fueron detectadas antes de producción o que lo fueron pero que no eran críticas y no se podían corregir a tiempo para pasar en producción. También pueden servir para implementar cambios pequeños (requisito modificado en camino del desarrollo del proyecto).

Los parches deben de seguir el mismo ciclo (puntos 2.2 a 2.11), pero más ligeramente.

Seguimiento de problemas

Para seguir el estado de los problemas que fueron reportados, les aconsejo el uso de algún tipo de programa. Lo más simple sería un archivo texto o un tabulador, hasta programas diseñados para este tipo de actividad (por ejemplo Peregrine). Personalmente, he diseñado un programa, basado en mi experiencia con Peregrine, para el seguimiento de actividades (proyectos, parches, problemas…) que de llama VIDA, está escrito en Java (JSP) con base de datos MySQL.

Fuente: Cedric Simon, SolucionJava.com