Proceso Unificado de Rational

Transcripción

1 RUP: El Proceso Unificado de Rational XP: Programacion Extrema EAP: Computación Científica Ciencia de la Computación V Prof. Oscar Brnito Pacheco Proceso Unificado de Rational Orígenes Modelo original Objectory definido por Ivan Jacobson (1987) Rational Software compra la empresa de Objectory (1995) Surge la primera versión de UML (1997) Se publica la primera versión del Proceso Unificado de Rational - RUP (junio 1998) 1

2 Casos de uso Dirigido por casos de uso Se centra en la funcionalidad que el sistema debe poseer para satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interactua con él Casos de uso como el hilo conductor que orienta las actividades de desarrollo <<definenecesidades>> Análisis Recopilar, Clarificar y Validar los requerimientos Casos de Uso Diseño Realizar los casos de uso <<realiza>> <<verifica>> Pruebas Verificar que se satisfacen los casos de uso Arquitectura Centrado en la arquitectura Concepto similar a la arquitectura de un edificio Varios planos con diferentes aspectos del edificio Tener una imagen completa del edificio antes que comience la construcción Arquitectura en software Diferentes vistas del sistema: estructural, funcional, dinámico, etc. Plataforma en la que va a operar Determina la forma del sistema Arquitectura: determina la forma del sistema Casos de uso: determinan la función del sistema 2

3 Modelo que implementa Iterativo e incremental Descomposición de un proyecto grande en mini-proyectos Cada mini-proyecto es una iteración Las iteraciones deben estar controladas Cada iteración trata un conjunto de casos de uso Ventajas del enfoque iterativo Detección temprana de riesgos Administración adecuada del cambio Mayor grado de reutilización Mayor experiencia para el grupo de desarrollo Estructura Dinámica Ciclo: cada ciclo una nueva versión del producto Fase: Etapas de un ciclo que finalizan en un HITO Iteración: Proceso de ingeniería sobre una funcionalidad limitada del sistema Estática - Flujos de trabajo Artefactos Actividades Roles 3

4 Estructura Roles Actividades Artefactos Flujo de Trabajo QUIÉN? CÓMO? QUÈ? CUÁNDO? diseñador realiza responsable de diseño de caso de uso diagrama de secuencia Roles Definición del comportamiento y responsabilidades de los participantes Propietario de una serie de artefactos Recurso Rol Actividad Artefacto Patricia Juan Mónica Pedro Diseñador Diseño de Objetos DC Analista Definición de CU DCU Dominio Diseñador Diseño de CU DS Funcional 4

5 Actividades Unidad de trabajo que puede ejecutar un individuo en un rol específico Tiene un propósito claro y se expresa en términos de actualizar artefactos La granularidad de la actividad es generalmente de horas o pocos días Ejemplos de actividades Planear una iteración (administrador del proyecto) Encontrar caso de uso y actores (analista del dominio) Revisión del diseño (probador) Artefactos Pieza de información producida, modificada y utilizada en un proceso Productos tangibles del proyecto Utilizados por los roles como entrada para la realización de sus actividades Resultado de las actividades realizadas por los roles Metamodelo: Clase rol tiene como métodos las actividades y como parámetros los artefactos 5

6 Flujos de trabajo Forma de describir significativamente la secuenciencias de actividades que producen resultados y las interacciones entre cargos En términos de UML se puede utilizar: diagrama de actividades, de secuencia, de colaboración En RUP hay nueve tipos de flujos de trabajo De ingeniería Negocio, Requerimiento, Análisis, Diseño, Pruebas, Liberación De soporte Administración del proyecto, Administración del cambio, Ambiente Dimensión dinámica fase ciclo Concepción Elaboración Construcción Transición hito 1 hito 2 hito 3 hito 4 Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6 Hito: punto en el tiempo en donde se evaluan objetivos logrados y se pueden tomar decisiones críticas 6

7 Desarrollo iterativo Construcción Ciclo de desarrollo 1 Ciclo de desarrollo 2 Ciclo de desarrollo n Perfeccionar el plan Sincronizar Artefactos Análisis Diseño Construcción Pruebas Fase de concepción Objetivo: definir la razón de ser y el alcance del proyecto. Estudio de oportunidad. Visión = QUÉ + PARA QUÉ + CUÁNTO Actividades Especificación de los criterios de éxito del proyecto Definición de los requerimientos Estimación de los recursos necesarios Cronograma inicial de fases Artefactos Documento de definición del proyecto 7

8 Fase de elaboración Objetivo: establecer un plan de proyecto y una arquitectura correcta del sistema Actividades Análisis del dominio del problema Definición de la arquitectura básica Análisis de riesgos Planificación del proyecto Artefactos Modelo del dominio Modelo de procesos Modelo funcional de alto nivel Arquitectura básica Fase de construcción Objetivo: desarrollar el sistema a lo largo de una serie de iteraciones Actividades Análisis Diseño Codificación Pruebas (individuales, de integración) 8

9 XP: extreme Programming extreme Programming Es una metodología ágil Diseñada para entornos dinámicos Pensada para equipos pequeños (hasta 10 programadores) Orientada fuertemente hacia la codificación Énfasis en la comunicación informal, verbal 9

10 Valores que fomenta XP Comunicación Simplicidad Retroalimentación Coraje Roles Programador (Programmer) Responsable de decisiones técnicas Responsable de construir el sistema Sin distinción entre analistas, diseñadores o codificadores En XP, los programadores diseñan, programan y realizan las pruebas Jefe de Proyecto (Manager) Organiza y guía las reuniones Asegura condiciones adecuadas para el proyecto Cliente (Customer) Es parte del equipo Determina qué construir y cuándo Establece las pruebas funcionales 10

11 Roles Encargado de Pruebas (Tester) Ayuda al cliente con las pruebas funcionales Se asegura de que las pruebas funcionales se superan Rastreador (Tracker) Metric Man Observa sin molestar Conserva datos históricos Entrenador (Coach) Responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura Captura de requisitos Historias del Usuario (User-Stories) Establecen los requisitos del cliente Trozos de funcionalidad que aportan valor Se les asignan tareas de programación con un nº de horas de desarrollo Las establece el cliente Son la base para las pruebas funcionales 11

12 Planificación Planificación por entregas (releases) Se priorizan aquellas user-stories que el cliente selecciona porque son más importantes para el negocio Entregas: Son lo más pequeñas posibles Se dividen en iteraciones (iteración = 2 o 3 semanas) Están compuestas por historias A cada programador se le asigna una tarea de la userstory Programación La programación de tareas se realiza por parejas La pareja diseña, prueba, implementa e integra el código de la tarea Código dirigido por las pruebas Código modular, intentando refactorizar siempre que se pueda 12

13 Modelo de un proyecto Prácticas El juego de la planificación Entregas pequeñas Metáfora Diseño simple Pruebas Refactoring Programación en parejas Propiedad colectiva Integración contínua Semana de 40 horas Cliente in situ Estándares de programación 13

14 El juego de la planificación Decisiones de negocio (cliente): Alcance Cuándo debe estar listo el producto para que sea valioso en producción? Prioridad Prioriza la incorporación de las user-stories Composición de entregas Qué se necesita para que el negocio sea mejor antes de tener el sw? Fechas de entrega Fechas cuando el software funcionando causaría una gran diferencia El juego de la planificación Decisiones técnicas (programadores y otros): Estimaciones Cuánto tiempo tardará en implementarse una user-story? Consecuencias Tener en cuenta las consecuencias técnicas de determinadas decisiones de negocio Proceso Organización del proceso y el equipo Planificación detallada Dentro de una entrega, qué user-stories se realizan primero. Intentar trasladar los segmentos de desarrollo más arriesgados al principio, intentando respetar las prioridades del negocio 14

15 Entregas pequeñas Cada entrega es lo más corta posible: Contenga requisitos más valiosos del sistema (básicos) Reducen el riesgo mayor retroalimentación desde el cliente, y más frecuente Minimizar el nº de user-stories que componen una entrega No realizar user-stories a medias Diseño simple Se diseña la cosa más simple que pueda funcionar Uso de tarjetas CRC Diseño de software correcto, es aquel que: Supera todas las pruebas No tiene lógica duplicada Pone de manifiesto las intenciones importantes de los programadores Tiene el mínimo número de clases y métodos 15

16 Pruebas Las pruebas unitarias se escriben ANTES que el código Pruebas automatizadas Permiten el desarrollo de proyectos de forma rápida y segura Pruebas unitarias programadores Pruebas funcionales cliente Resultado Un programa cada vez más seguro NUnit Framework para pruebas unitarias Escritura de pruebas Ejecución de pruebas Hacer un Assert de los resultados Mostrar los fallos o éxitos Mantener un código que pase los tests 16

17 Ejemplo de un test en NUnit Fallo en ejecución de los tests 17

18 Éxito en ejecución de los tests Refactoring Refactorización = Mejora del código Intentar eliminar complejidad Código duplicado Refactorización Se plantea su aplicación después de implementar cada user-story 18

19 C# Refactoring Herramientas integradas con Visual Studio Simplifican la refactorización del código Métricas para el análisis del código Integración con Visual Studio 19

20 Métricas de análisis del código Refactoring con C# Refactory 20

21 Programación en parejas Toda el código se escribe en parejas Se produce código de mayor calidad Extiende el conocimiento Se realiza el trabajo de 1 persona en casi la mitad del tiempo y mejor (cuestionable) Propiedad colectiva Cualquiera puede modificar el código en cualquier momento Se evitan cuellos de botella en la codificación Todos asume las responsabilidades sobre el conjunto del sistema Todos conocen algo sobre todas las partes y conocen muy bien aquéllas en las que trabajan 21

22 Integración contínua El código se integra y se prueba después de pocas horas Existe una ordenador dedicado para la integración Cada pareja integra su código en dicho ordenador Cliente in situ Cliente real = Aquel que usará el sistema cuando esté en producción El cliente real debe estar con el equipo de trabajo: Responder preguntas Resolver disputas Establecer prioridades Discutir mejoras 22

23 Estándares de programación Son fundamentales cuando los programadores cambian de pareja o hacen refactoring del código de otros Se consigue un código con el mismo estilo, homogéneo, legible 23