Ingenier

1
Ingeniería de Software I

• Proceso Racional Unificado (RUP)

2
Qué es el RUP?

• RUP es un proceso de desarrollo de software
• Forma disciplinada de asignar tareas y
  responsabilidades en una empresa de desarrollo
  (quién hace qué, cuándo y cómo).
• Objetivos
• Asegurar la producción de software de calidad
  dentro de plazos y presupuestos predecibles.
  Dirigido por casos de uso, centrado en la
  arquitectura, iterativo (mini-proyectos) e
  incremental (versiones).

3
Beneficios del RUP

• Aumenta la productividad de los desarrolladores
  mediante acceso a
• Base de conocimiento, plantillas y herramientas.
• Se centra en la producción y mantenimiento de
  modelos del sistema más que en producir
  documentos.
• RUP es una guía de cómo usar UML de la forma más
  efectiva.

4
Fases y Flujos de Trabajo
5
Fase de Inicio

• Su objetivo
• Lo que deberá hacer el producto
• Reducción de los peores riesgos
• Preparación para el análisis del negocio inicial

6
Fase de Inicio

• Un documento de visión general
• Requerimientos generales del proyecto
• Características principales
• Restricciones
• Caso de negocio
• Contexto
• Criterios de éxito
• Pronóstico financiero
• Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.

7
Fase de Inicio

• Modelo inicial de casos de uso (10 a 20
  listos).
• Glosario.

8
Fase de Elaboración

• Objetivos
• Obtener la línea base de la arquitectura
• Capturar la mayoría de los requisitos
• Reducir los peores riesgos
• Estimar costos y fechas
• Planificar la fase de construcción con algún
  detalle

9
Fase de Elaboración

• Modelo de casos de uso (80 completo) con
  descripciones detalladas.
• Otros requerimientos no funcionales o no
  asociados a casos de uso.
• Descripción de la Arquitectura del Software.
• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos y del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.

10
Fase de Construcción

• Objetivos
• El desarrollo del sistema
• Garantía de que el producto puede comenzar su
  transición a los clientes

11
Fase de Construcción

• El producto de software integrado y corriendo en
  la plataforma adecuada.
• Manuales de usuario.
• Una descripción del release actual.

12
Fase de Transición

• Objetivos
• Garantizar que se tiene el producto preparado
  para su entrega (versión del producto)
• Entrenar a los usuarios a utilizar el sistema.

13
Fase de Transición

• Pruebas Beta para validar el producto con las
  expectativas del cliente
• Ejecución paralela con sistemas antiguos
• Conversión de datos
• Entrenamiento de usuarios
• Distribuir el producto

14
Fases e Hitos (Milestones)
Inicio
Elaboración
Construción
Transición
Capacidad Operacional Inicial
Objetivos (Visión)
Arquitectura
Release del Producto
tiempo
Hito Punto de terminación de la iteración
cuando se toma alguna decisión o evaluación
importante
15
Proceso de Ingeniería de Software Workflows
(Disciplinas)
16
Proceso de Ingeniería de Software Workflows
(Disciplinas)

• Workflows Primarios
• Business Modeling (Modado del Negocio)
• Requirements (Requisitos)
• Analysis Design (Análisis y Diseño)
• Implementation (Implementación)
• Test (Pruebas)
• Deployment (Despliegue)
• Workflows de Apoyo
• Environment (Entorno)
• Project Management (Gestión del Proyecto)
• Configuration Change Management (Gestión de
  Configuración y Cambios)

17
Artefactos

• Resultado parcial o final que es producido y
  usado durante el proyecto. Son las entradas y
  salidas de las actividades
• Un artefacto puede ser un documento, un modelo o
  un elemento de modelo
• Conjuntos de Artefactos

• Business Modeling Set
• Requirements Set
• Analysis Design Set
• Implementation Set
• Test Set

• Deployment Set
• Project Management Set
• Configuration Change Management Set
• Environment Set

18
Proceso Iterativo e Incremental

• El ciclo de vida iterativo se basa en la
  evolución de prototipos ejecutables que se
  muestran a los usuarios y clientes
  (mini-proyectos)
• En el ciclo de vida iterativo a cada iteración se
  reproduce el ciclo de vida en cascada a menor
  escala
• Los objetivos de una iteración se establecen en
  función de la evaluación de las iteraciones
  precedentes

19
Proceso Iterativo e Incremental

• Las actividades se encadenan en una mini-cascada
  con un alcance limitado por los objetivos de la
  iteración

Req.
Análisis
Diseño
Imple.
Pruebas e Integración
n veces
20
Proceso Iterativo e Incremental

• Cada iteración comprende
• Planificar la iteración (estudio de riesgos)
• Análisis de los Casos de Uso y escenarios
• Diseño de opciones arquitectónicas
• Codificación y pruebas. La integración del nuevo
  código con el existente de iteraciones anteriores
  se hace gradualmente durante la construcción
• Evaluación de la entrega ejecutable (evaluación
  del prototipo en función de las pruebas y de los
  criterios definidos)
• Preparación de la entrega (documentación e
  instalación del prototipo)

21
Las iteraciones sobre el ciclo de vida

• Cada una de las cuatro fases termina con hito
  principal.

22
Plan de iteraciones

• El número de iteraciones planeado para cada fase
  depende, básicamente de la complejidad del
  sistema propuesto. Un proyecto simple puede
  realizarse con una sola iteración por fase. Un
  proyecto mas complejo podría comprender el
  siguiente numero de iteraciones.

23
Plan de iteraciones

• Fase de Inicio una iteración, principalmente
  dedicada a definir el ámbito del sistema
• Fase de elaboración dos iteraciones, la primera
  para esbozar la arquitectura y la segunda para
  completar la línea base de la arquitectura

24
Plan de iteraciones

• Fase de construcción dos iteraciones, para
  asegurar que los incrementos resultantes
  funcionan satisfactoriamente
• Fase de transición una iteración

25
Proceso Iterativo e Incremental
Enfoque Secuencial
Enfoque Iterativo e Incremental
26
Iteraciones

• Cada fase consiste en las iteraciones del
  desarrollo en las cuales un subconjunto del
  sistema se desarrolla. En general, estas
  iteraciones
• Reducen los riesgos técnicos
• Proporcionan versiones tempranas
• Permiten mayor flexibilidad para el lanzamiento
  de cada característica y
• Permiten controlar los cambios con respecto al
  alcance de manera efectiva con las iteraciones
  durante los ciclos.

27
Proceso Centrado en la Arquitectura

• Arquitectura de un sistema es la organización o
  estructura de sus partes más relevantes
• Un arquitectura ejecutable es una implementación
  parcial del sistema, construida para demostrar
  algunas funciones y propiedades
• RUP establece refinamientos sucesivos de una
  arquitectura ejecutable, construida como un
  prototipo evolutivo

Inception
Elaboration
Construction
Transition
28
Fases, Base Line, Versión, Release
ciclo de desarrollo
ciclo de evolución
versión (subconjunto de artefactos estable y
ejecutable)
release (producto al final de una iteración,
lanzado para su puesta en producción)
base line (release asociada a un hito)
29
Base Line

• Conjunto de artefactos revisados y aprobados que
  constituyen una base convenida para la evolución
  y desarrollo adicional y que se puede cambiar
  solamente a través de la administración de
  cambios.
• Asegurarse qué subsistemas, cuándo alcanzan un
  nivel especifico de la madurez, son la línea base
  para que esté disponible para el release
  (liberación), o la reutilización en iteraciones
  subsecuentes del proyecto y/o otros proyectos.

30
Base Line

• Se considera como candidato para una Línea Base
  el conjunto de archivos y directorios bajo
  control de versión que son desarrollados,
  integrados y puestos juntos en un release.
• Una línea base se crea al final de cada iteración

31
Versiones

• Identifican el estado de un elemento de
  configuración o una configuración en un punto
  definido en el tiempo
• Conjunto de artefactos relativamente completo y
  consistente que incluye posiblemente una
  construcción- entregado a un usuario interno o
  externo

32
Versiones

• La mayoría de los programas grandes se
  desarrollan en release evolutivos. Un release
  podría estar en uso del cliente, mientras que
  otro está en prueba, y el tercero todavía está en
  el desarrollo. Si se encuentran problemas en
  cualquiera de las versiones, los arreglos
  necesitan ser propagados entre ellas. La
  confusión puede acrecentarse conduciendo a
  arreglos costosos y retrabajo a menos de que los
  cambios sean cuidadosamente controlados y
  supervisados.

33
Release

• Es una versión que se ha puesto disponible a los
  usuarios.
• La frecuencia y la formalidad de los releases
  son descritos en el plan del CM (Configuration
  Management ). El grado de la formalidad es
  claramente mucho más alto para un producto que es
  liberado a un cliente, que el que es generado
  para la estructura o la revisión siguiente de la
  iteración.

34
Release

• Regularmente está asociado a un baseline de una
  configuración

35
Esfuerzo y dedicación por Fases en RUP
Inicio Elaboración Construcción Transición
Esfuerzo 5 20 65 10
Tiempo Dedicado 10 30 50 10
36
Distribución de Recursos por Fases en RUP
37
Roles Analista de Sistemas

• El papel del analista de sistemas conduce y
  coordina la captura de requisitos y el modelado
  de casos de uso que definiendo la funcionalidad
  del sistema y delimitando el sistema.

38
Roles Diseñador

• El diseñador define las responsabilidades,
  operaciones, atributos y relaciones entre las
  clases y determina cómo éstas deben ajustarse a
  el ambiente de implantación. Además el diseñador
  puede tener la responsabilidad de uno o más
  paquetes de diseño o diseño de susbsistemas.

39
Roles Diseñador de pruebas

• El Diseñador de pruebas es el responsable de
  definir los métodos de prueba y asegurarse del
  éxito de su implementación. Debe identificar las
  técnicas apropiadas, herramientas y guías para
  implementar las pruebas requeridas, y brindar
  dirección en los requisitos correspondientes al
  esfuerzo de las pruebas.

40
Roles Programador (Implementador)

• El programador es responsable de desarrollar y
  probar los componentes, de acuerdo a los
  estándares adoptados para el proyecto, y la
  integración de los subsistemas.

41
Roles Integrador

• Los desarrolladores entregan sus componentes
  probados en un espacio de trabajo de la
  integración, mientras que los integradores los
  combinan para producir una estructura. Un
  integrador es también responsable de planear la
  integración, que ocurre en los niveles del
  subsistema y de sistema, con cada uno teniendo un
  espacio de trabajo separado de la integración.
  Los componentes probados se entregan del espacio
  de trabajo privado del desarrollo de un ejecutor
  en un espacio de trabajo de la integración del
  subsistema,

42
Roles Administrador de proyecto

• El Administrador de Proyecto asigna recursos,
  asigna prioridades, coordina interacciones con
  los clientes y usuarios, y generalmente mantiene
  al equipo de proyecto centrado en la meta. Además
  establece un conjunto de prácticas que aseguran
  la integridad y calidad de los artefactos del
  proyecto.

43
Roles Administrador de proyecto
44
Roles Administrador de la Configuración

• El Administrador de la Configuración proporciona
  toda la infraestructura y el ambiente la
  administración de la configuración (CM) al
  equipo del desarrollo de producto. La función del
  CM apoya la actividad del desarrollo de producto
  de modo que los desarrolladores y los
  integradores tengan espacios de trabajo
  apropiados para construir y para probar su
  trabajo, y de modo que todos los artefactos estén
  disponibles para la inclusión en la unidad del
  despliegue según lo requerido. El encargado de la
  configuración también tiene que asegurarse de que
  el ambiente del CM facilite la revisión del
  producto, y las actividades que siguen del cambio
  y del defecto. El encargado de la configuración
  es también responsable de escribir el plan del CM
  y de dar a conocer la estadística del progreso
  basada en peticiones del cambio.

45
Roles Administrador de la Configuración
46
Referencias

• El Proceso Unificado de Desarrollo de Software,
  Ivar Jacobson, Grady Booch, James Rumbaugh
• RUP 2001
• UML y Patrones, Craig Larman