Open Unified Process

De WikiCE


OpenUp es un método y un proceso de desarrollo de software propuesto por un conjunto de empresas de tecnología,quienes lo donaron en el año 2007 a la Fundación Eclipse. La fundación lo ha publicado bajo una licencia libre y lo mantiene como método de ejemplo dentro del proyecto Eclipse Process Framework.

Contenido

Introducción

OpenUP/Basic esta diseñado para equipos pequeños, trabajando juntos en la misma localidad. El equipo tiene que participar plenamente en la interacción diaria de manera presencial. Los miembros del equipo incluidos los stakeholders, desarrolladores, arquitectos, gestores de proyecto y testers. Los miembros del equipo participan en una colaboración significativa, tomando sus propias decisiones en cuanto a lo que se necesita trabajar, cuales son las prioridades, y la mejor manera de abordar las necesidades de los stakeholders.La organización debe apoyar al equipo permitiéndoles esta responsabilidad.

Los miembros del equipo colaboran ampliamente. La presencia de los stakeholders como miembros del equipo es critica para realizar exitosamente OpenUP/Basic.

Los miembros del equipo participan a diario en las reuniones stand-up para comunicar el estado y sus asuntos. Los problemas se abordan fuera de las reuniones diarias.

OpenUP/Basic se enfoca en reducir significativamente el riesgo de manera temprana en el ciclo de vida. Esto requiere unas reuniones regulares de revisión de los riesgos y una implementación rigurosa de las estrategias de mitigación.

Todo el trabajo será listado, seguido y asignado a través de la "lista de ítems de trabajo". Los miembros del equipo están en un único repositorio para todas las tareas que necesitan ser registradas y seguidas. Esto incluye todos los requerimientos de cambio, errores y requerimientos de los stakeholder.

Los casos de uso son utilizados para obtener y describir los requisitos. Los miembros del equipo deben desarrollar habilidades para escribir buenos casos de uso. Los Stakeholders son responsables de revisar y certificar que los requerimientos son correctos. Los casos de uso son desarrollados de manera colaborativa.

Los requisitos arquitectónicamente más importantes deben ser identificados y estabilizados dentro de la fase de Elaboración de tal forma que sea creada una arquitectura robusta, la cual es el corazón del sistema. Un cambio de un requisito arquitectonicamente significativo puede surgir posteriormente en el desarrollo, el cual debe ser abordado, pero el riesgo de que esto ocurra es reducido significativamente dentro de la iteración de Elaboración.

Imagen1.jpg

OpenUP/Basic no incluye contenido para el despliegue, gestión del cambio, o entorno. OpenUP/Basic se enfoca en un equipo único, y estas áreas son tratadas a nivel de organización o empresarial.

OpenUP/Basic es un proceso de desarrollo de software que es mínimo, completo y extensible. Está gobernado por cuatro principios básicos:

  • Prioridades compitiendo por un balance para maximizar el valor para los stakeholders.
  • Colaboración para alinear los intereses y un entendimiento compartido
  • Evolucionar para obtener continuamente retroalimentación y mejora
  • Enfoque en articular la arquitectura

Los elementos principales de esta metodología son los roles, tasks y artifacts. Los roles desempeñan tasks ((organizadas por disciplinas) que consumen y producen artifacts (organizados por dominios). OpenUP/Basic describe el conjunto mínimo de roles, tareas y artefactos involucrados en el desarrollo de software

Ciclo de vida

OpenUP/Basic es un proceso iterativo distribuido a través de cuatro phases: Inicio, Elaboración y Transición. Cada fase consiste de una o más iteraciones, donde se trabaja por versiones estables del software que son desarrolladas y liberadas, el completar cada iteración representa un milestone menos para el proyecto y una contribución al éxito arquitectónico del hito mayor de la Fase donde los objetivos de la fase son alcanzados.

El siguiente diagrama muestra el lifecycle de OpenUP/Basic.

Imagen2.jpg

Cada fase podrá tener tantas iteraciones como se requiera dependiendo del grado de novedad del dominio de negocio, de la tecnología a ser utilizada, de la complejidad de la arquitectura de la solución y del tamaño del proyecto, entre otros factores.

Las iteraciones pueden tener duraciones variables dependiento de las características del proyecto. Iteraciones de un mes son las recomendables, ya que este periodo de tiempo proporciona:

   * Una cantidad de tiempo razonable para que los proyectos entreguen incrementos considerables en funcionalidad .
   * Retro alimentación temprana y frecuente por parte de los usuarios.
   * Administración a tiempo de los riesgos y problemas encontrados durante el curso del proyecto.

El OpenUP/Basic esta diseñado para ofrecer guía en el proceso de desarrollo en proyectos pequeños:

   * Equipos de 3 a 6 personas
   * 3 a 6 meses de trabajo

Roles

Los roles de OpenUP representaran a las habilidades necesarias de un equipo pequeño o co-localizado.

Analista

El analista es el que 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

Imagen3.jpg

Arquitecto

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

Imagen4.jpg

Desarrollador

Es quien 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 desarrollados.

Imagen5.jpg

Lider 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

Imagen6.jpg

Takeholder

Representan al grupo que está interesado en el proyecto, quienes necesariamente deberán de ser satisfechos por el mismo. Este papel lo puede jugar cualquier persona que es afectada por los objetivos del proyecto.

Imagen7.jpg

Tester

Es el responsable de las actividades básicas y de realizar las pruebas, se encarga de la identificación, definición, implementación y conducción de las pruebas necesarias. Así como el ingreso de pruebas y el análisis de resultados.

Imagen8.jpg

Otro rol

Representa a cualquier otra persona en el equipo que puede realizar tareas generales.

Imagen9.jpg

Autores

  • Diego García Arriaza
  • Mario Rivas Sánchez

Referencias

Herramientas personales