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 

 

 

METODOLOGIAS DE DESARROLLO DE SOFTWARE TRADICIONALES VERSUS METODOLOGIAS AGILES

METODOLOGIAS DE DESARROLLO DE SOFTWARE TRADICIONALES VERSUS  METODOLOGIAS AGILES

1.    Introducción.-

Para desarrollar e implementar un  software necesitamos muchos pasos a seguir, desde la planificación elaboración y puesta en marcha se deben de seguir un gran número  de actividades. E         n  la actualidad existen diversas metodologías para seleccionar cual será la más adecuada para realizar el software, sin embargo es necesario definir primero la naturaleza del software antes de elegir un determinado ciclo de vida.

En esta investigación  se describe  dos tipos de metodologías de desarrollo de software como ser la metodología tradicionales y metodologías ágiles, las primeras están pensadas para el uso exhaustivo de documentación durante todo el ciclo del proyecto por lo tanto la metodología ágil  ponen vital importancia en la capacidad de respuesta a los cambios, la confianza recae en las habilidades y una buena comunicación con el equipo de desarrolladores y otro punto muy importante es mantener una buena comunicación  con el cliente, o de otro forma que el cliente también participe en el desarrollo del software  que es una de sus principales actividades de la metodología agiles.

2.     Metodologías Agiles.-

2.1.        Scrum.-

Scrum se basa en buenas prácticas aceptadas por la industria, usadas y probadas durante décadas. Se establece como una teoría empírica de proceso. Como Jim Coplien comentó una vez a Jeff, "A todo el mundo le gustará Scrum; es lo que ya hacemos cuando estamos entre la espada y la pared.

El marco de Scrum se compone de un conjunto de Equipos Scrum y sus roles asociados; así como de Bloques de Tiempo, Artefactos, y Reglas.

Los Equipos Scrum están diseñados para optimizar la flexibilidad y la productividad, para lo cual, son auto-gestionados, multifuncionales, y trabajan en iteraciones. Cada Equipo Scrum tiene tres roles: 1) el ScrumMaster, que es responsable de asegurar que el proceso es comprendido y seguido, 2) el Propietario del Producto, que es responsable de maximizar el valor del trabajo realizado por el Equipo Scrum, y 3) el Equipo, que hace el trabajo. El equipo está formado por desarrolladores con todos los conocimientos necesarios para convertir los requerimientos del Propietario del Producto en un incremento potencialmente utilizable del producto al final del Sprint

 

2.2.        Extreme Programming (XP)

Basada en la simplicidad, la comunicación y el reciclado continúo de código.

Ha sido probada por muchas compañías, de diferentes dimensiones, desde 1998.

La programación extrema es una metodología reciente en el desarrollo de software. La filosofía de X.P es satisfacer al completo las necesidades del cliente, por eso lo integra como una parte más del equipo de desarrollo.

Fue inicialmente creada para el desarrollo de aplicaciones dónde el cliente no sabe muy bien lo que quiere, lo que provoca un cambio constante en los requisitos que debe cumplir la aplicación. Por este motivo es necesaria una metodología ágil como X se adapta a las necesidades del cliente y dónde la aplicación se va reevaluando en periodos cortos de tiempo.

Los que trabajan con Extreme Programming XP, tienen a considerar  que los cambios de requisitos sobre la marcha son un aspecto natural, que es inevitable durante el desarrollo de proyectos. Estas personas creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

3.    Metodologías tradicionales.-

Entre las metodologías tradicionales más conocidas tenemos RUP y MSF entre otros, esta metodología tradicional centran su atención en llevar una documentación precisa y exhaustiva de todo el proyecto y enfocan  su atención en realizar y cumplir un plan de proyecto.

Las metodologías tradicionales se enfocan en documentación, planificación y procesos. (Plantillas, técnicas de administración, revisiones continuas, y otras.), unas de las metodologías más usadas  dentro de las tradicionales tenemos las siguientes:

    3.1  Proceso Unificado Rational (RUP)

Es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo.

FasesLas cuatro fases del ciclo de vida son:

·         Concepción

·         Elaboración

·         Construcción

·         Transición

Ventajas

·          Evaluación en cada fase que permite cambios de objetivos

·          Funciona bien en proyectos de innovación.

·           Seguimiento detallado en cada una de las fases.

·         Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.

Desventajas

·          La evaluación de riesgos es compleja

·          Excesiva flexibilidad para algunos proyectos

·          El cliente deberá ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con él.

Rational Unified Process (RUP)

Proceso Unificado Rational

3.2  Microsoft Solution Framework (MSF)

Este modelo se basa principalmente en los modelos espiral y cascada (hitos y fases). Como su nombre lo dice fue desarrollado por Microsoft con el objetivo de crear un modelo estructurado basado en una estructura de trabajo en desarrollo de software.

Tiene como principios fundamentales la comunicación (entre cliente/usuario y entre nosotros), una capacitación de las personas (disciplina de disponibilidad) es decir cumple con el proceso de formación de personal, compartir los roles entre todo el equipo de trabajo. MSF es un proceso versionado y se debe crear versiones para el negocio de cada cliente, debe ser ágil, ya que es menos abultado que RUP. Otro principio es la inversión de calidad (tiempo, trabajo, dinero); hay que tomar en cuenta que cada proyecto es una inversión, más no un gasto.

MSF se compone de 2 modelos y 3 disciplinas.

·         Modelo de Equipo

·         Modelo de  Proceso.

·         Disciplina de  Administración de Proyecto, Administración  de Riesgos y Administración de la Preparación.

MSF es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnología de información.

Todo proyecto es separado en cinco principales fases:

·                   Visión y Alcances.

·                   Planificación.

·                   Desarrollo.

·                   Estabilización.

·                   Implantación.

Modelo de Equipo de MSF

3.3. Microsoft Operation Framework.-

MOF ofrece directrices sobre el modo de planear, implementar y mantener procesos operativos de TI que respalden las soluciones de servicio críticas. MOF es un modelo genérico y, por este motivo, debe adaptar muchas de las recomendaciones para usarlas en su empresa. Cuando encuentre referencias a "funciones" en el modelo MOF, tenga en cuenta que se puede asignar a una misma persona a varias funciones, sobre todo en las empresas pequeñas. No obstante, aunque represente a todo el departamento de TI, los procedimientos y recomendaciones de este modelo se pueden aplicar de forma general.

MOF es un modelo estructurado y flexible que está basado en lo siguiente:

• Los equipos de consultoría y soporte técnico de Microsoft y su experiencia de trabajo con clientes empresariales y socios, además de grupos internos de operaciones de TI en Microsoft.
• La Biblioteca de infraestructuras de TI (ITIL), que describe los procesos y las prácticas recomendadas necesarios para el suministro de soluciones de servicio críticas.
• ISO/IEC 15504, de la Organización Internacional de Normalización (ISO), que proporciona un enfoque normalizado para evaluar la madurez del proceso de software.

·         El modelo de proceso MOF está formado por cuadrantes, revisiones de la administración de las operaciones y revisiones de la administración de los servicios. En la figura  se muestra el funcionamiento del ciclo de MOF.

4.    Conclusión.-

·    Una opinión importante es que para que un equipo  de desarrollo de software adquiera una metodología ágil debe tener mucha experiencia de trabajo con metodologías tradicionales, ya que la experiencia de realizar varios proyectos de software es la que se necesita  en los mementos difíciles del proyecto, también se debe tener la habilidad de ser equipos, motivar al equipo de trabajo, innovación e inspiración para realizar proyectos de software.

·     Las metodologías ágiles son más modernas se trabajó mucho en el equipo de desarrolladores y desde mi punto de vista mejores que cualquiera de las tradicionales.

·     Al  inicio en un equipo de desarrollo de software el uso de metodologías tradicionales es esencial.

·     Desde mi punto de vista las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre, por  lo cual los  requisitos no se conocen con exactitud, por lo tanto en las metodologías tradicionales obligan al cliente a tomar las decisiones al iniciar el proyecto.