1. Open UP(Open Unified Process)
1.1. Es completa en el sentido de que manifiesta por completo el proceso de construir un sistema
1.2. Es aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo.
1.3. Esta 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
1.4. Es extensible a ser utilizado como base sobre la cual se pueden añadir o adaptarse a contenido de otro proceso que sea necesario.
2. Proceso iterativo
2.1. Mínimo
2.1.1. Solo incluye el contenido del proceso fundamental
2.2. Completo
2.2.1. Puede ser manifestado como proceso entero para construir un sistema.
2.3. Extensible
2.3.1. Puede ser utilizado como base para agregar o para adaptar más procesos.
3. Principios de Open UP
3.1. El contenido metodológico
3.2. El contenido procedimental
4. Ciclo de vida
4.1. según la metodología OpenUP, permite que los integrantes del equipo de desarrollo aporten con micro-incrementos, que pueden ser el resultado del trabajo de unas pocas horas o unos pocos días.
4.2. El objetivo de OpenUP es ayudar al equipo de desarrollo, a lo largo de todo el ciclo de vida de las iteraciones.
4.3. Iteración de Fase de Inicio.
4.3.1. En esta fase, las necesidades de cada participante del proyecto son tomadas en cuenta y plasmadas en objetivos del proyecto.
4.3.2. 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.
4.3.2.1. Ojetivos
4.3.2.1.1. Entender qué construir.
4.3.2.1.2. Identificar funcionalidad Clave.
4.3.2.1.3. Determinar al menos una posible solución.
4.3.2.1.4. Entender el costos, calendario y riesgos del proyecto.
4.4. Iteración de Fase de Elaboración.
4.4.1. Análisis del dominio y definición de la arquitectura del sistema.
4.4.2. Se debe elaborar un plan de proyecto, estableciendo unos requisitos y arquitectura estables.
4.4.3. 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.
4.4.3.1. Objetivos
4.4.3.1.1. Obtener un entendimiento con mayor nivel de detalle de los requerimientos.
4.4.3.1.2. Diseñar, implementar y validar la línea base arquitectónica.
4.4.3.1.3. Mitigar riesgos y lograr estimaciones de costos y calendarios más precisos.
4.5. Iteración de Fase de Construcción.
4.5.1. Todos los componentes y funcionalidades del sistema que falten por implementar son realizados, probados e integrados.
4.5.1.1. Objetivos
4.5.1.1.1. Iterativamente desarrollar un producto completo que pueda ser transicionado a la comunidad usuaria.
4.5.1.1.2. Minimizar los costos de desarrollo y lograr cierto nivel de paralelismo.
4.6. Iteración de Fase de Transición.
4.6.1. Corresponde a la introducción del producto en la comunidad de usuarios, cuando el producto esta lo suficiente maduro.
4.6.1.1. Objetivos
4.6.1.1.1. Realizar Beta Testing para determinar si se alcanzaron las expectativas de los usuarios.
4.6.1.1.2. Alcanzar la concordancia con los stakeholders de que el producto está terminado.
4.6.1.1.3. Mejorar la performance futura a través del análisis retrospectivo del proyecto.
5. INTRODUCCIÓN
5.1. Open UP
5.1.1. Metodología de Proceso Unificado que aplica enfoques iterativos e incrementales dentro de un ciclo de vida estructurado, utiliza una filosofía ágil que se enfoca en la naturaleza de colaboración para el desarrollo de software, basada en RUP (Rational Unified Process).
5.2. Open UP: basado
5.2.1. En RUP (Rational Unified Process), que contiene el conjunto mínimo de prácticas que ayudan a un equipo de desarrollo de software a realizar un producto de alta calidad, de una forma eficiente.
5.3. Open UP: Colaboradores
5.3.1. Grupo de empresas conformado por: IBM Corp, Telelogic AB, Armstrong Process Group Inc., Number Six , Software Inc. y Xansa; quienes la donaron a la Fundación Eclipse en el año 2007, que la ha publicado Bajo licencia libre.
6. Características de Open UP
6.1. Desarrollo incremental
6.2. Uso de casos de uso y escenarios.
6.3. Manejo de riesgos.
6.4. Diseño basado en la arquitectura
7. ROLES
7.1. El analista
7.1.1. 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.
7.2. El arquitecto
7.2.1. 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.
7.3. El desarrollador
7.3.1. 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
7.4. El líder del proyecto
7.4.1. 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.
7.5. Las partes interesadas (Stakeholders)
7.5.1. 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
7.6. El comprobador
7.6.1. : Es el responsable de las actividades básicas y de realizar las pruebas, así como el ingreso de pruebas y el análisis de resultados.
7.7. Cualquier otro rol
7.7.1. 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 necesarias(en colaboración)
8. Beneficios del uso de Open UP
8.1. 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.
8.2. Permite detectar errores tempranos a través de un ciclo iterativo.
8.3. Evita la elaboración de documentación, diagramas e iteraciones innecesarios requeridos en la metodología RUP.
8.4. Por ser una metodología ágil tiene un enfoque centrado al cliente y con iteraciones cortas.
8.5. Ventajas
8.5.1. Es una metodología ágil
8.5.2. Se puede adaptar con otros procesos.
8.6. Desventajas
8.6.1. A veces omite contenido que puede ser de interés en el proyecto.
8.6.2. Se espera que cubra un amplio sistema de necesidades para los proyectos de desarrollo en un plazo muy corto.
8.6.3. 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