Metodología OpenUP

Metodología Open UP

Introducción

La presente información tiene como objetivo tratar de explicar en qué consiste la metodología de desarrollo de software denominada OpenUP, que anteriormente fue creada por IBM pero esta pasó a manos de la empresa Eclipse quien en 2006 fue lanzada bajo una licencia gratuita.

OpenUP (Open Unified Process)

Es un proceso modelo y extensible, dirigido a gestión y desarrollo de proyectos de software basados en un desarrollo iterativo, ágil e incremental apropiado para proyectos pequeños y de bajos recursos; y es aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo.

Sin embargo OpenUP es completa en el sentido de que manifiesta por completo el proceso de construir un sistema. Para atender las necesidades que no están cubiertas en su contenido OpenUP  es extensible a ser utilizado como base sobre la cual se pueden añadir o adaptarse a contenido de otro proceso que sea necesario.

Proceso iterativo

• Mínimo: Solo incluye el contenido del proceso fundamental
• Completo: Puede ser manifestado como proceso entero para construir un sistema.
• Extensible: Puede ser utilizado como base para agregar o para adaptar más procesos.

Características de OpenUP

• Desarrollo incremental
• Uso de casos de uso y escenarios.
• Manejo de riesgos.
•  Diseño basado en la arquitectura.

Principios de OpenUP

• Colaborar para sincronizar intereses y compartir conocimiento. Este principio promueve prácticas que impulsan un ambiente de equipo saludable, facilitan la colaboración y desarrollan un conocimiento compartido del proyecto.
• Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados en el proyecto. Este principio promueve prácticas que permiten a los participantes de los proyectos desarrollar una solución que maximice los beneficios obtenidos por los participantes y que cumple con los requisitos y restricciones del proyecto.
• Centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el desarrollo.
• Desarrollo evolutivo para obtener retroalimentación y mejoramiento continuo. Este principio promueve prácticas que permiten a los equipos de desarrollo obtener retroalimentación temprana y continua de los participantes del proyecto, permitiendo demostrarles incrementos progresivos en la funcionalidad a los clientes.

Roles

El analista

Representa al cliente y el usuario final, se refiere a la obtención de requerimientos de los interesados, por medio de comprender el problema a resolver capturando y creando las prioridades de los requerimientos.

El arquitecto 

Es el responsable del diseño de arquitectura de software, tomando las decisiones técnicas claves, las cuales limitaran el conjunto de diseño y la implementación del proyecto.

El desarrollador

Es el que tiene la responsabilidad del desarrollo de una parte del sistema o el sistema completo dependiendo de la magnitud del mismo, se encarga del diseño ajustándolo a la arquitectura y de la implementación de pruebas unitarias y de integración para los componentes.

El líder del proyecto Dirige la planificación del proyecto en colaboración con las partes interesadas y el equipo, coordina las interacciones de los interesados, manteniendo al equipo del proyecto enfocado en los objetivos del mismo.

Las partes interesadas (Stakeholders) 

Representan al grupo que está interesado en el proyecto, cuyas necesidades deberán ser satisfechas por el proyecto en curso. Este papel lo puede jugar cualquier persona que puede ser materialmente afectada por los objetivos del proyecto.

El comprobador 

Es el responsable de las actividades básicas y de realizar las pruebas, se encarga de larias. Así como el ingreso de pruebas y el análisis de resultados.

Cualquier otro rol, representa a cualquier otra persona en el equipo que puede realizar tareas generales.a identificación, definición, implementación y conducción de las pruebas neces

Ciclo de Vida

Iteración de Fase de Inicio.

En esta fase, las necesidades de cada participante del proyecto son tomadas en cuenta y plasmadas en objetivos del proyecto. Se definen para el proyecto: el ámbito, los limites, el criterio de aceptación, los casos de uso críticos, una estimación inicial del coste y un boceto de la planeación.

Objetivos.

• Entender qué construir.

• Identificar funcionalidad Clave.

• Determinar al menos una posible solución.

• Entender costos, calendario y riesgos del proyecto.

Iteración de Fase de Elaboración.

En esta fase se realizan tareas de análisis del dominio y definición de la arquitectura del sistema. Se debe elaborar un plan de proyecto, estableciendo unos requisitos y arquitectura estables. Al final de la fase se debe tener una definición clara y precisa de los casos de uso, actores, la arquitectura del sistema y un prototipo ejecutable.

Objetivos:

• Obtener un entendimiento con mayor nivel de detalle de los requerimientos

• Diseñar, implementar y validar la línea base arquitectónica.

• Mitigar riesgos y lograr estimaciones de costos y calendarios más precisos.

Iteración de Fase de Construcción.

En esta fase todos los componentes y funcionalidades del sistema que falten por implementar son realizados, probados e integrados. Los resultados obtenidos en forma de incrementos ejecutables deben ser desarrollados de la forma más rápida posible sin dejar de lado la calidad de lo desarrollado.

Objetivos.

• Iterativamente desarrollar un producto completo que pueda ser transicionado a la comunidad usuaria.

• Minimizar los costos de desarrollo y lograr cierto nivel de paralelismo.

Iteración de Fase de Transición.

Esta fase corresponde a la introducción del producto en la comunidad de usuarios, cuando el producto esta lo suficiente maduro. La fase de la transición consta de las sub-fases de pruebas beta, pilotaje y capacitación de los usuarios finales  de los encargados del mantenimiento del sistema. En función a la respuesta obtenida por los usuarios puede ser necesario realizar cambios en las entregas finales o implementar alguna funcionalidad más solicitada por la mayoría.

Objetivos.

• Realizar Beta Testing para determinar si se alcanzaron las expectativas de los usuarios.
• Alcanzar la concordancia con los stakeholders de que el producto está terminado.
• Mejorar la performance futura a través del análisis retrospectivo del proyecto.

Beneficios del uso de OpenUP

• Ya que es apropiado para proyectos pequeños y de bajos recursos permite disminuir las probabilidades de fracaso en los proyectos pequeños e incrementar las probabilidades de éxito.

• Permite detectar errores tempranos a través de un ciclo iterativo.

• Evita la elaboración de documentación, diagramas e iteraciones innecesarios requeridos en la metodología RUP.

• Por ser una metodología ágil tiene un enfoque centrado al cliente y con iteraciones cortas.

Ventajas

• Es una metodología ágil

• Se puede adaptar con otros procesos.

Desventajas

• A veces omite contenido que puede ser de interés en el proyecto.

• Se espera que cubra un amplio sistema de necesidades para los proyectos de desarrollo en un plazo muy corto.

• Al ser una metodología de bajo formalismo existirá la posibilidad, si no se tiene cuidado, de que el proyecto pueda perder rumbo debido a la desorganización

Conclusión

    OpenUP es una metodología gratis, ágil, modificable  y evolutiva que se puede integrar con otras metodologías ya que pueden resolverse las tareas de desarrollo utilizando las prácticas de XP (Pair Programing, TDD, Refactoring) y pueden realizarse las iteraciones utilizando las actividades de SCRUM. Además brinda una referencia clara y simplificada para la inducción de nuevo personal.

Archivos de Descarga

Trabajo Word
https://www.dropbox.com/s/7m0bub7u84vxnmq/IS.Exp.5.333113.docx

Trabajo Power Poin
https://www.dropbox.com/s/28uelac93ks0icz/IS.Exp.5.333113.pptx

TrabajoTriptico
https://www.dropbox.com/s/rbm5qos2ocs4bfr/IS.Exp.5.333113.pub