CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

Transcripción

1 CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7) Fax: + 53 (7) ip@uci.cu

2 Control del Documento Título: Configuración de la Versión: 1.0 Nombre Cargo Elaborado por: Yulainne Alonso Hernández Asesora de Calidad Reglas de Confidencialidad Clasificación: <USO INTERNO> Forma de distribución: <PDF Digital> Control de Cambios Versión Sección, Figura, Tabla Tipo A, B, M Fecha Autor del cambio Descripción del Cambio Indicar el tipo de cambio: A Alta; B Baja; M Modificación i

3 Índice de contenidos 1 Introducción Objetivo Alcance Definiciones y acrónimos Referencias Desarrollo Descripción de la Metodología Por qué usar OpenUP Fases definidas en OpenUP Principales roles y responsabilidades de OpenUP Artefactos generados en los diferentes flujos... 12

4 1 Introducción 1.1 Objetivo El propósito de este documento es enunciar las principales características de la metodología que se utilizará en los proyectos del dpto. SINI. Se describen los principales artefactos y roles que intervienen en la misma. 1.2 Alcance En este documento se describe la información referente a la configuración de la metodología OpenUP que todos los proyectos deben cumplir. 1.3 Definiciones y acrónimos 1.4 Referencias Código Título 1

5 2 Desarrollo 2.1 Descripción de la Metodología OpenUP - un proceso ágil y unificado, que contiene el conjunto mínimo de prácticas que ayudan a los equipos a ser más eficaces en el desarrollo de software. OpenUP abraza una filosofía pragmática y ágil que se centra en la naturaleza colaborativa de desarrollo de software. Es un proceso iterativo que es Mínimo, Completo y Extensible que puede utilizarse tal cual o ampliarse para tratar una amplia variedad de tipos de proyecto. Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Está organizada dentro de cuatro áreas principales de contenido: Comunicación y Colaboración, Intención, Solución y Administración. El OpenUP está organizado en dos dimensiones diferentes pero interrelacionadas: el método y el proceso. El contenido del método es donde los elementos del método (roles, tareas, artefactos y lineamientos) son definidos, sin tener en cuenta como son utilizados en el ciclo de vida del 2

6 proyecto. El proceso es donde los elementos del método son aplicados de forma ordenada en el tiempo. Muchos ciclos de vida para diferentes proyectos pueden ser creados a partir del mismo conjunto de elementos del método. OpenUP se caracteriza por cuatro principios básicos que se soportan mutuamente: Colaboración para alinear los intereses y un entendimiento compartido. Balance para confrontar las prioridades (necesidades y costos técnicos) para maximizar el valor para los stakeholders. Enfoque en articular la arquitectura para facilitar la colaboración técnica, reducir los riesgos y minimizar excesos y trabajo extra. Evolución continua para reducir riesgos, demostrar resultados y obtener. 2.2 Por qué usar OpenUP Metodología de desarrollo de software de código abierto diseñado para pequeños equipos organizados quienes quieren tomar una aproximación ágil del desarrollo. 3

7 Proceso iterativo e incremental que es Mínimo, Completo y Extensible. Se valora la colaboración y el aporte de los stakeholders sobre los entregables y las formalidades innecesarias. Practicantes de desarrollo de software (desarrolladores, administradores de proyectos, analistas y probadores) trabajan juntos como un equipo de proyecto. No define un modelo de negocio ni de dominio necesario. 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. 2.3 Fases definidas en OpenUP Inicio: El propósito en esta fase es lograr concurrencia entre todos los stakeholders sobre los objetivos del ciclo de vida para el proyecto. Hay cuatro objetivos para la fase de Inicio que clarifican el alcance, los objetivos del proyecto y la viabilidad de la solución proyectada. 1. Entender qué construir. Determine la Visión, el alcance del sistema y sus límites. Identifique quién está interesado en este sistema y por qué. 2. Identifique la funcionalidad clave del sistema. Decida qué requerimientos son los más críticos. 3. Determine al menos una posible solución. Identifique al menos una arquitectura candidata y su viabilidad. 4. Entienda el costo, el cronograma y los riesgos asociados al proyecto. 4

8 Consideraciones clave: Los proyectos pueden tener una o más iteraciones en la fase inicial. Estas son algunas de las razones por las múltiples iteraciones: Proyecto es grande, y es difícil de definir su ámbito de aplicación sistema sin precedentes. Demasiados actores que compiten con las necesidades y relaciones complejas. Los principales riesgos técnicos demandan la creación de un prototipo o prueba de concepto. Elaboración: El propósito de esta fase es establecer la línea base de la arquitectura del sistema y proporcionar una base estable para el gran esfuerzo de desarrollo de la siguiente fase. Hay objetivos para la fase de Elaboración que le ayudan a direccionar los riesgos asociados con los requisitos, la arquitectura, los costos y el cronograma. 1. Obtener un entendimiento más detallado de los requisitos. Tener un buen entendimiento de la mayoría de requisitos que le permitan crear un plan más detallado y obtener ganancia de los stakeholders. Asegurar de ganar profundidad en el entendimiento de los requisitos más críticos a ser validados por la arquitectura. 2. Diseñar, implementar, validar y establecer la línea base para la arquitectura. Diseñe, implemente y pruebe un esqueleto estructural del sistema. Aunque la funcionalidad no sea completa aún, muchas de las interfaces entre los bloques de construcción son implementadas y probadas. Esto se refiere a una arquitectura ejecutable. 3. Mitigar los riesgos esenciales y producir un cronograma exacto y unos costos estimados. Muchos riesgos técnicos son dirigidos como un resultado de detallar los requisitos y de diseñar, implementar y probar la arquitectura. Refine y detalle el plan de proyecto de alto nivel. Consideraciones clave: El número de iteraciones en la fase de elaboración es dependiente, pero no se limitan a, factores tales como verde-campo de desarrollo en comparación con el mantenimiento del ciclo, el sistema sin precedentes en comparación con la tecnología bien conocida y arquitectura, y así 5

9 sucesivamente. Por lo general, en la primera iteración, es mejor para diseñar, implementar y probar un pequeño número de escenarios críticos para identificar qué tipo de mecanismos de la arquitectura y la arquitectura que usted necesita, por lo que puede mitigar los riesgos más importantes. También los detalles de alto riesgo, los requisitos que deben abordarse al comienzo del proyecto. Usted prueba suficiente para validar que los riesgos se mitigan arquitectónicos. Durante las iteraciones posteriores, arreglar lo que no estaba bien de la iteración anterior. Puede diseñar, implementar y probar los restantes escenarios de gran importancia arquitectónica, para garantizar que puedas ver todas las áreas principales del sistema (cobertura del suelo), de modo que los riesgos potenciales sean identificados lo más pronto posible. Construcción: El propósito de esta fase es completar el desarrollo del sistema basado en la arquitectura. Hay objetivos para la fase de Construcción que nos ayudan a tener un desarrollo con costoeficiente de un producto completo - una versión operativa del sistema - que pueda ser entregada a la comunidad de usuario. 1. Desarrolle iterativamente un producto completo que esté listo para hacer transición a su comunidad de usuarios. Describa los requisitos restantes, complete en detalles los diseños, complete la implementación y prueba del software. Libere la primera versión operativa del software (beta) del sistema y determine si los usuarios están listos para que la aplicación sea desplegada. 2. Minimice el costo de desarrollo y alcance algún grado de paralelismo. Optimice los recursos y promueva el paralelismo de desarrollo entre desarrolladores o equipos de desarrolladores, por ejemplo, asignar componentes que puedan ser desarrollados independientemente uno del otro. Consideraciones clave: Por lo general, la fase de construcción tiene más iteraciones (dos a cuatro) que en las otras fases, en función de los tipos de proyectos: 6

10 Simple proyecto: Una iteración para construir el producto (para una versión beta) Más importante proyecto: Una iteración para exponer un sistema parcial y uno a madurar a las pruebas beta Gran proyecto: Tres o más iteraciones, dependiendo del tamaño del proyecto (número de requisitos para aplicar para una versión beta) Transición: El propósito en esta fase es asegurarse que el software está listo para entregarse a los usuarios. Hay objetivos para la fase de Transición que le ayudan a afinar elegantemente la funcionalidad, el desempeño y la calidad total de la versión beta del producto desde el final de la fase previa. 1. La prueba beta valida que las expectativas del usuario sean satisfechas. Esto típicamente requiere algunas actividades de afinamiento, tales como depuración de errores y mejora del desempeño y la usabilidad. 2. Lograr que los stakeholders lleguen a un consenso cuando el desarrollo esté terminado. Esto puede implicar diferentes niveles de las pruebas de aceptación del producto, tanto formal como informal pruebas y pruebas beta. 3. Mejorar el desempeño en futuros proyectos a través de lecciones aprendidas. Documentar las lecciones aprendidas y mejorar el ambiente de los procesos y las herramientas para el proyecto. Consideraciones clave: La fase de transición puede incluir la ejecución de los sistemas antiguos y nuevos en paralelo, la migración de datos, los usuarios de formación, y el ajuste de los procesos de negocio. El número de iteraciones en la fase de transición varía de una iteración de un sistema simple que requiere la corrección de errores sobre todo menor de edad, de muchas iteraciones de un sistema complejo, que incluye además de las funciones y la realización de actividades para hacer la transición del negocio de usar el viejo sistema de utilizar el nuevo sistema. Cuando los objetivos de la fase de transición que se cumplan, el proyecto se puede cerrar. Para 7

11 algunos productos, al final del ciclo de vida del proyecto actual puede coincidir con el comienzo del ciclo de vida siguiente, lo que lleva a la siguiente generación del mismo producto. 2.4 Principales roles y responsabilidades de OpenUP Analista: La persona en este rol representa al cliente y las preocupaciones de los usuarios finales mediante la recopilación de información a los interesados para entender el problema a resolver y por la captura y fijación de prioridades para las necesidades. Adicionalmente realiza: Evaluar los resultados Crear casos de prueba Diseñar la solución Imagina la Arquitectura Implementar pruebas Administrar iteración Plan de Iteración Plan del Proyecto Modifica: Glosario Requisitos del sistema Caso de uso Modelo de Casos de Uso 8

12 Visión Lista de elementos de trabajo Arquitecto: El arquitecto es responsable de definir la arquitectura de software, que incluye tomar las principales decisiones técnicas que limitan el diseño y la implementación del sistema. Adicionalmente realiza: Evaluar los resultados Diseñar la solución Detallar requisitos del sistema Detallar Escenarios de Caso de Uso Desarrollar la visión técnica Identificar y describir los requerimientos Administrar iteración Plan de Iteración Plan del Proyecto Programador: El Desarrollador es responsable del desarrollo de una parte del sistema, incluyendo el diseño que se ajuste a la arquitectura, posiblemente de prototipos de la interfaz de usuario, y luego la aplicación, la unidad de pruebas-, y la integración de los componentes que forman parte de la solución. 9

13 Adicionalmente realiza: Evaluar los resultados Crear casos de prueba Detallar Requisitos del sistema Detallar Escenarios de Caso de Uso Imaginar la Arquitectura Identificar y describir los requerimientos Implementar pruebas Administrar iteración Plan de Iteración Plan del Proyecto Refinar la Arquitectura Líder de proyecto: El director del proyecto lleva a la planificación del proyecto, coordina las interacciones con las partes interesadas, y mantiene el equipo del proyecto se centró en el cumplimiento de los objetivos del proyecto. 10

14 Los entrenadores del equipo para impulsar el éxito del proyecto y la aceptación del producto por el cliente. Es responsable de los resultados del proyecto y la aceptación del producto por el cliente. Es responsable de la evaluación de los riesgos del proyecto y para el control de esos riesgos a través de estrategias de mitigación. Se aplica la gestión del conocimiento, habilidades, herramientas y técnicas para una amplia gama de tareas para obtener el resultado deseado para un proyecto en particular en el momento oportuno. Adicionalmente realiza: Desarrollar la visión técnica Imaginar la Arquitectura Refinar la Arquitectura Modifica: Plan de Iteración Plan de Proyecto Factores de Riesgo Lista de elementos de trabajo Stakeholder: Este papel representa los grupos de interés cuyas necesidades deben ser satisfechas por el proyecto. Se trata de un papel que puede jugar por cualquier persona que es (o será potencialmente) significativamente afectados por el resultado del proyecto. Probador: El probador es responsable de las actividades básicas de la prueba de esfuerzo. Esas actividades incluyen la identificación, definición, implementación y realización de las pruebas necesarias, así como registrar los resultados de las pruebas y análisis de los resultados. 11

15 La identificación de las pruebas que deban llevarse a cabo. Identificar el enfoque de aplicación más adecuado para una prueba determinada. Implementar pruebas individuales. La creación y ejecución de las pruebas. Registro de los resultados y verificar que las pruebas se han ejecutado. Analizar y orientar la recuperación de los errores de ejecución. Comunicar los resultados de prueba para el equipo. Adicionalmente realiza: Evaluar los resultados Diseñar la solución Detallar Requisitos del sistema Detallar Escenarios de Caso de Uso Identificar y describir los requerimientos Implementar pruebas para desarrolladores Implementar la solución Administrar iteración Plan de Iteración Plan del Proyecto Modifica: Caso de prueba Prueba de registro Script de prueba 2.5 Artefactos generados en los diferentes flujos (Cuando se formalice el expediente se describirán) 12

16 13