CICLOS DE VIDA ORIENTADO A OBJETOS VERSUS CICLOS DE VIDA TRADICIONALES

CICLOS DE VIDA ORIENTADO A OBJETOS VERSUS CICLOS DE VIDA TRADICIONALES

  Objetos

Introducción

La Ingeniería del Software y la Orientación a Objetos son dos áreas cuya intersección produce un amplio abanico de técnicas y metodologías que pretenden facilitar la construcción de software. Este artículo revisa algunas de estas técnicas, que pueden ser de gran utilidad para el desarrollo de proyectos complejos con éxito.

Los Ciclos de Vida

El desarrollo de software no es fácil: las técnicas son relativamente nuevas, los sistemas actuales son complejos y los requisitos de los clientes cambian con bastante más frecuencia de lo que muchos desearíamos. Cualquier organización que desarrolle software debería plantearse qué proceso le interesa seguir para la realización de sus productos, ya sea para todos o para cada uno en particular.

En los últimos años, una tecnología orientada a resolver este problema que ha sonado con mucha fuerza es la gestión de workflows. De forma más concreta, el

Proceso Unificado de Rational (RUP) y la Programación eXtrema (XP) son dos de las aproximaciones al proceso  de desarrollo más populares. Démosle un rápido vistazo a los ciclos de vida tradicionales antes de repasar estas técnicas.

 Ciclos Tradicionales

Con el primer ciclo tradicional con el que nos encontramos es con el ciclo de vida

Clásico o en Cascada:

Análisis→Diseño→Implementación→Testing

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.

Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.

Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:

·         Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document).

·         Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)

·         Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.

·         Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.

Ventajas

·         La planificación es sencilla.

·         La calidad del producto resultante es alta.

·         Permite trabajar con personal poco cualificado.

Desventajas

·         Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas.

·         Si se han cometido errores en una fase es difícil volver atrás.

·         No se tiene el producto hasta el final, esto quiere decir que:

o    Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el consiguiente gasto inútil de recursos.

o    El cliente no verá resultados hasta el final, con lo que puede impacientarse.

·         No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).^1.1

·         Es comparativamente más lento que los demás y el coste es mayor también.

 Modelo de ciclo de vida en espiral

Este modelo de ciclo de vida en espiral consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores en la implementación.

En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:

·         Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.

·         Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista

o    Características del producto.

o    Formas de gestionar el proyecto.

·         Restricciones:

o    Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.

o    Desde el punto de vista organizativo: Coste, tiempo, personal, etc.

·         Riesgos: Lista de riesgos identificados.

·         Resolución de riesgos: La técnica más usada es la construcción de prototipos.

·         Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.

·         Planes: Lo que se va a hacer en la siguiente fase.

·         Compromiso: Decisiones de gestión sobre como continuar.

Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.

Ventajas

·         El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).

·         No necesita una definición completa de los requisitos para empezar a funcionar.

·         Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.

Desventajas

·         Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.

·         Es difícil evaluar los riesgos.

·         Necesita de la participación continua por parte del cliente.

 

CICLO DE VIDA EN  V

EL ciclo de vida en V fue diseñado por Alan Davis, y contiene las mimas etapas que el ciclo cascada puro, A diferencia de aquel, a este se le agregaron dos subetapas de retroalimentación entre las etapas de análisis y mantenimiento, y entre las de diseño y debubgging.

Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si bien son simples (pequeñas transacciones sobre base de datos por ejemplo), necesitan una confiabilidad muy alta. Un ejemplo claro en el que no nos podemos permitir el lujo de cometer errores es una aplicación de facturación, en la que si bien los procedimientos vistos individualmente son de codificación e interpretación sencilla, la aplicación en su conjunto puede tener matices complicados.

Ciclos de vida orientados a objetos.

Este ciclo de vida orientado a objetos fue  creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientación a objetos y posiblemente el más seguido. Un proyecto se divide en las fases:

·         Planificación del negocio

·          Construcción: Es la más importante y se divide a su vez en otras cinco actividades

·         Planificación

·         Investigación

·         Especificación

·         Implementación

·         Revisión

·         Entrega

La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos. Además de las tres fases, existen dos periodos:

·         Crecimiento: Es el tiempo durante el cual se construye el sistema

·         Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificación del negocio, Construcción y Entrega.

Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. 

Ventajas de ciclos de vida orientados a objetos

·         Los ciclos basados en objetos tienen la particularidad de crear componentes que se relacionan entre ellos a través de interfaces

·         Al ser modulares se los puede dividir en mini proyectos de tal forma que no es muy restrictivo a la hora de escoger que proyecto realizar primero o incluso es posible realizarlo simultáneamente

·         La ventaja de usar componentes hace posible la reutilización de código para ahorrar tiempo y esfuerzo.

·         Reduce la cantidad de riesgos al ser un modelo que siempre ofrece prototipos de forma temprana debido a la facilidad de manipularlo en módulos.

Conclusión

Inicialmente el desarrollo de software era orientado a las estructuras, esto se  debía a que los clientes estaban educados de forma que se pensaba que el producto se utilizaría por mucho tiempo y por tal motivo se invertiría más dinero y tiempo para realizar todas las tareas del ciclo de vida, pero hoy en dia el mercado  para el software es competitivo ya no es suficiente demostrar calidad en el producto, es muy  importante  poder satisfacer todas las  necesidades del cliente con la mayor calidad posible y en el menor tiempo esto se debe por las nuevas tecnologías para desarrollar software