DiseñO De Sistemas
Upcoming SlideShare
Loading in...5
×
 

DiseñO De Sistemas

on

  • 9,708 views

esta muy buena

esta muy buena

Statistics

Views

Total Views
9,708
Views on SlideShare
9,531
Embed Views
177

Actions

Likes
3
Downloads
600
Comments
1

8 Embeds 177

http://www.slideshare.net 53
http://aulavirtual.utel.edu.mx 51
http://gc.scalahed.com 48
https://www.coursesites.com 18
http://gc.initelabs.com 3
http://comunidad.itsae.edu.ec 2
http://10.1.47.15 1
https://es.coursesites.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Muy completa la presentación.
    Buen trabajo.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DiseñO De Sistemas DiseñO De Sistemas Presentation Transcript

  • Rational Unified Process Oswaldo E. Eusebio Rojas Universidad Garcilaso de la Vega
  • Temario
    • Introducción
      • Concepto
      • Vista Dinámica y Estática
      • Características de RUP
    • Las seis mejores prácticas
    • Disciplinas y Flujos de Trabajo
    • Fases
    • RUP y CMMI
    • Conclusiones
  • ¿Qué es un Proceso de Desarrollo de SW? Requisitos nuevos o modificados Sistema nuevo o modificado Proceso de Desarrollo de Software
    • Define Quién debe hacer Qué , Cuándo y Cómo debe hacerlo
    • No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable
    View slide
  • El Problema
    • Si un proceso es utilizado, equipos funcionales diferentes normalmente utilizan procesos y lenguajes de modelación inconsistentes.
    Requerimientos Pruebas Análisis Diseño
    • La mayoría de los proyectos de software utilizan procesos que no están bien definidos. En su lugar los miembros del equipo (re)inventan sus propios procesos.
    ? ? ? ? ? ? ?
    • Los procesos no están apropiadamente relacionados con herramientas, ó no están propiamente automatizados.
    ? Proceso Herramienta View slide
  • Conceptos fundamentales
    • Proceso :
      • Es un marco de trabajo común compuesto por actividades de trabajo (conjuntos de tareas, hitos, productos y puntos de garantía de calidad) y actividades de protección (garantía de calidad, gestión de configuración y medición) (Pressman 2001).
    • Producto:
      • Es el resultado previsto y consistente del proceso.
  • Conceptos fundamentales
    • Ciclo de vida del software :
      • Es el conjunto de fases por las que pasa el software, que abarcan desde su creación u origen, hasta su eliminación o liquidación formal.
    • Modelo de desarrollo:
      • También denominado Modelo de Proceso .
      • Estrategia de desarrollo basada en el ciclo de vida, naturaleza del proyecto y metodología, que determina las características específicas del proceso (Pressman 2001).
  • Rational Unified Process “ RUP es un marco de trabajo genérico que puede especializarse para una variedad de tipos de sistemas, diferentes áreas de aplicación, tipos de organizaciones y diferentes tamaños de proyectos”. JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James 2000 El proceso unificado de desarrollo de software , Addison Wesley
  • Noción de Proceso Rol que puede ser desempeñado por un individuo o conjunto de individuos en la organización de desarrollo Trabajador/Quién? Diseñador Actividad/Cómo? Describe una unidad de trabajo que puede ser asignada a un trabajador. Pieza de información que es producida, modificada, ó utilizada por un proceso Artefacto/Qué? responsable de Diseño de Casos de uso Paquete de Caso de Uso Caso de Uso
  • Rational Unified Process
    • Creado por los 3 amigos: Grandy Booch (creador de “The Booch Method”), Ivar Jacobson e James Rumbag (creador de “Object Modeling Technique” = OMT)
    • Aparece por primera vez en Junio de 1998 con el nombre de Rational Unified Process 5.0 (RUP)
    • Fue puesto a disposición pública entre finales de 1998 e inicios de 1999.
    • Centrado en tres Puntos:
      • Personas
      • Procesos
      • Herramientas y métodos
  • Evolución de RUP
  • Estructura de RUP
    • El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes:
      • El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en términos de ciclos , fases , iteraciones , y metas .
      • El eje vertical representa el aspecto estático del proceso; como está descrito en términos de disciplinas: actividades , artefactos , trabajadores y flujos de trabajo .
  • El Ciclo de Vida del Software en RUP
  • El Ciclo de Vida del Software en RUP
  • El Ciclo de Vida del Software en RUP
  • El Ciclo de Vida del Software en RUP
  • Relación entre Diagramas UML y Disciplinas de RUP Disciplina Diagrama Requerimientos Diagramas de Casos de Uso Análisis Refinamiento y documentación de los casos de usos Definición preliminar de clases y Diagramas de Interacción (Secuencia y Colaboraciones) Diseño Empaquetamiento Diagramas de Interacción de diseñ o (Secuencia y Colaboraciones) Diagrama de Clases de diseñ o Modelo de Datos Implementación Diagrama de Componentes Diagrama de Despliegue
  • RUP Visión Estática
    • En su visión estática, el modelo RUP está compuesto por:
      • Roles : analista de sistemas, diseñador, diseñador de pruebas, roles de gestión y roles de administración.
      • Actividades : RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de horas o de algunos días; y son elementos base de planificación y progreso.
  • RUP Visión Estática
    • En su visión estática, el modelo RUP está compuesto por:
      • Artefactos : Son los elementos de entrada y salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, código, ejecutables…)
      • Flujos de trabajo : son el “pegamento”de los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.
  • RUP Visión Estática
    • En su visión estática, el modelo RUP está compuesto por:
      • Disciplinas : son “contenedores” empleados para organizar las actividades del proceso. RUP comprende 6 disciplinas de proceso y 3 de soporte. Proceso : modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo. Soporte : gestión de proyecto, gestión de configuración y cambio, y entorno.
  • RUP Visión Dinámica
    • En su visión dinámica, la visión de la estructura del ciclo de vida RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo.
    • Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP:
      • 1.- Inicio . Es la fase de la idea, de la visión inicial de producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el “hito de objetivo”.
      • 2.- Elaboración . Comprende la planificación de las actividades y del equipo necesario. La especificación de las necesidades y el diseño de la arquitectura. Termina con el “hito de Arquitectura”.
  • RUP Visión Dinámica
      • 3.- Construcción . Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el “hito del inicio de la capacidad operativa”.
      • 4.- Transición . Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el mantenimiento hasta lograr la satisfacción de los usuarios. Termina con el “hito de entrega del producto”.
  • RUP Visión Dinámica Administración Ambiente Modelación de Negocios Implementación Prueba Análisis y Diseño Iteración(es) Preliminar Iter. #1 Fases Disciplinas de Procesos Iteraciones Disciplinas de Soporte Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Despliegue Admin. Configuración Requerimientos Elaboración Transición Inicio Construcción Estática Dinámica
  • Conformaci ón del Equipo ROLES TAREAS ASIGNADAS Gestor del proyecto Establecer Condiciones de Trabajo Analista del sistema Encontrar Actores y Casos de Uso Estructurar el Modelo de Casos de Uso Arquitecto del sistema Priorizar los Casos de Uso Efectuar el An álisis Arquitectural Efectuar el Diseño Arquitectural Efectuar la Implementación Arquitectural Especificador de casos de uso Detallar un Caso de Uso Dise ñador de interfaz de usuario Prototipar una Interfaz de Usuario Ingeniero de casos de uso Analizar un Caso de Uso Dise ñar un Caso de Uso
  • Conformaci ón del Equipo ROLES TAREAS ASIGNADAS Ingeniero de componentes Analizar una Clase Analizar un Paquete Dise ñar una Clase Diseñar un Subsistema Implementar un Subsistema Implementar una Clase Realizar una Prueba de Unidad Implementar una Prueba Integrador del sistema Integrar el Sistema Ingeniero de pruebas Planear las Pruebas Dise ñar las Pruebas Evaluar las Pruebas Verificador de integraci ón Realizar una Prueba de Integraci ón Verificador del sistema Realizar las Pruebas del Sistema
  • Características de RUP Dirigido por los Casos de Uso Centrado en la Arquitectura Iterativo e Incremental
  • Dirigido por Casos de Uso
    • Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema.
    • Los casos de uso también guían el proceso de desarrollo (diseño, implementación y pruebas).
    • De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, que avanza a través de una serie de flujos de trabajo.
  • Dependencia entre los Casos de Uso y los demás modelos Modelo de análisis Modelo de diseño Modelo de despliegue Modelo de implementación Modelo de prueba Especificado por Realizado por Distribuido por Implementado por Verificado por X OX X OX X OX
  • Iterativo e incremental
    • Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento.
    • Las iteraciones deben seleccionarse y ejecutarse de forma planificada. Esta selección se basa en dos cosas:
        • El conjunto de casos de uso que amplían funcionalidad
        • En los riesgos mas importantes que deben mitigarse
    • En cada iteración se identifica y especifica los casos de uso relevantes, se crea un diseño utilizando la arquitectura seleccionada como guía, para implementar dicho caso de uso.
  • Desarrollo “en cascada” tradicional retarda la reducción del Riesgo R I E S G O T I E M P O Test Subs. Test. Sistema Cod. & Test U. Diseño An. Requer.
  • Aplicando cascada iterativamente
    • Las primeras iteraciones reducen los principales riesgos
    • Cada iteración produce una versión ejecutable, un incremento adicional al sistema
    • Cada iteración incluye integración y test
    T C D R T I E M P O Iteración 1 Iteración 2 Iteración 3 T C D R T C D R
  • Centrado en la Arquitectura
    • La arquitectura se describe mediante diferentes vistas del sistema en construcción. Incluye aspectos estáticos y dinámicos.
    • La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando de los detalles de lado.
    • La arquitectura debe permitir el desarrollo de todos los casos de uso requeridos actualmente y a futuro, y los casos de uso deben encajar en la arquitectura.
    • 5 Vistas
    • 9 Diagramas
    Organización de Modelos Vistas de UML: Arquitectura 4 + 1
  • Diagramas de Casos de Uso casos de uso
      • Proporciona c r edibilidad en una etapa inicial del desarrollo del sistema
      • Asegura una comprensión mutua de los requisitos
      • Que se hayan capturado todos los requ erimientos
      • Que los desarrolladores hayan entendido los requ erimientos
    • Usados Para Verificar
    • Usados Para Comunicarse con el Usuario Final y el Experto de Dominio
    Diagramas de Casos de Uso
  • Diagramas de Casos de Uso incluye caso de uso actor extiende Límite
  • Diagramas de Clases
    • Usados para mostrar la Estructura Estática de un sistema computacional o una parte relevante del mundo real
    • Son los diagramas más frecuentemente usados. Y se les puede considerar con Tres Perspectivas posibles :
      • Conceptual – muestra las entidades del mundo real con sus relaciones
      • Especificación – muestra la estructura del sistema o sus partes, destacando las interfaces
      • Implementación – el dise ño del código fuente
    Diagramas de Clases
  • Diagramas de Clases Cliente Bebida Barmen Pedido Venta - valor: Doble + ImprimirBoleta() Bodega Jugo Natural Gaseosa 1 1..* 1 realiza 0..* 1 tiene 1..* 1 almacena 0..* asociación multiplicidad atributo operación herencia clase
  • Diagramas de Secuencia
    • Usados para representar el comportamiento del sistema
    • Muestran colaboración a través de mensajes entre los objetos del sistema
    • Destacan:
      • Mensajes enviados entre los objetos
      • Orden secuencial entre los mensajes
      • Un escenario concreto, sin condiciones
    • Útiles tanto en análisis (identificación de clases), como en diseño (especificación de componentes)
    Diagramas de Secuencia
  • Diagramas de Secuencia mensaje objeto línea de vida {x N} Pepe :Barmen Interfaz Barmen (from Use Case View) Motor Venta (from Use Case View) BD de Ventas (from Use Case View) Frambuesa :Jugo Natural (from Logical Model) 12345 :Venta (from Logical Model) Ingresar Datos Venta Confirmar Venta Ejecutar Venta Crear Venta Crear Bebida Ingresar Venta destrucción de objeto creación de objeto ciclos
  • Diagramas de Colaboraci ó n
    • Usados para representar el comportamiento del sistema
    • Muestran colaboración entre los objetos del sistema
    • Destacan:
      • Mensajes enviados entre los objetos
      • Enlaces entre los objetos
      • Un escenario concreto, sin condiciones
    • Útiles tanto en análisis (identificación de clases), como en diseño (especificación de componentes)
    Diagramas de Colaboraci ó n
  • Diagramas de Colaboraci ó n Pepe : Barmen Bucarest :Sistema de Bodega Interfaz Barmen Comunicador Bodega Motor Venta Interfaz Bodega El cálculo dió la cantidad bajo la mínima permitida - hay que pedir bebida de la bodega 1 Vender Jugo Natural 1.1 Vender Jugo Natural 1.2 Calcular Cantidad Bebida 1.3 Pedir Bebida 1.4 Pedir Bebida 1.5 Pedir Bebida enlace objeto mensaje
  • Diagramas de Actividades
    • Usados para representar el comportamiento del sistema o negocio
    • Muestran actividades y procesos
    • Destacan:
      • Condiciones y flujos alternativos
      • Tareas y procesos concurentes
      • Responsabilidades sobre ciertas actividades
    • Útiles en análisis de negocio para capturar procesos de alto nivel
    Diagramas de Actividades
  • Diagramas de Actividades actividad decisión sincronización
  • Diagrama de Estados
    • Usados para representar el comportamiento INTERNO de un objeto o de un módulo del sistema
    • Muestran estados en los cuales un objeto se puede encontrar
    • Destacan:
      • Estados
      • Transiciones y condiciones de las transiciones
      • Actividades realizadas
    • Típicamente usados para describir ciclo de vida de un objeto
    Diagrama de Estados
  • Diagrama de Estados Inicio a Pedidos Cobrados INGRESADO SERVIDO COBRADO PERDIDO CANCELADO a Pedidos Anulados A Pedidos Perdidos Si el estado no se cámbia durante 1 día servir cancelar 1 día cobrar estado transición inicio fin
  • Diagrama de Componentes
    • Usados para mostrar los Módulos Físicos de software :
      • Los ejecutables y librerías dinámicas
      • Las páginas WEB y los scripts
      • Los módulos o funciones, etc.
    • Sin embargo se usan más bien para capturar la Organización de los Componentes de Software (EXE, DLL, EJB, etc)
    • Destacan Dependencias entre los Componentes
    Diagrama de Componentes
  • Diagrama de Componentes dependencia componente interfaz
  • Diagrama de Distribuci ón
    • Usados Para Modelar las Relaciones entre el Software y el Hardware
    • Mapeo de los Componentes de Software a los Nodos de Hardware
    • Típicamente contienen elementos tales como
      • Servidores
      • Procesadores
      • Impresoras
      • Redes computacion a l e s
      • Etc.
    Diagrama de Distribuci ón
  • Diagrama de Distribución nodo enlace
  • Modelos y Flujos de Trabajo
  • Seis Mejores Prácticas
  • Seis “Mejores Prácticas” Controlar Cambios Administrar requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente
    • El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada.
    • Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema.
    • RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero.
    • Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.
    Desarrollo Iterativo
  • Desarrollo Iterativo
    • Cada iteración resulta en un release ejecutable
    Planeamiento Inicial Planeamiento Requerimientos Análisis y Diseño Implementación Prueba Distribución Evaluación Ambiente de Administración
    • RUP describe cómo:
      • Obtener los requerimientos
      • Organizarlos
      • Documentar requerimientos de funcionalidad y restricciones
      • Rastrear y documentar decisiones
      • Captar y comunicar requerimientos del negocio
    • Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseño, la implementación y las pruebas.
    Administración de requerimientos
  • Administración de requerimientos Req. 10 Aprobado Bajo Alta Req. 13 Propuesto Medio Baja Req. 40 Obligatorio Alto Alto $$$ $$ $ Costo Esfuerzo Riesgo Status Prioridad    
  • Arquitecturas basadas en componentes
    • El proceso se basa en diseñar tempranamente una arquitectura base ejecutable.
    • La arquitectura debe ser:
      • Flexible
      • Fácil de modificar
      • Intuitivamente comprensible
      • Promueve la reutilización de componentes
    • RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.
  • Arquitecturas basadas en componentes Database CRM Funciones de cliente/ productos Mecanismos de interfaces Cliente Producto Comprado Existente Nuevo Funciones de licenciamiento Licencia
  • Modelamiento Visual
    • Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes.
    • Bloques de construcción:
      • Permiten la comunicación en el equipo de desarrollo
      • Permiten analizar la consistencia:
        • entre las componentes
        • entre diseño e implementación
    • UML es la base del modelamiento visual de RUP.
    • Diagramas de Casos de Uso
    • Diagramas de Clases
    • Diagramas de Estados
    • Diagramas de Componentes
    • Diagramas de Implementación
    Modelización Visual eleva el nivel de abstracción Modelamiento Visual Código Clases Subsistemas
  • Verificación de la Calidad
    • La actividad fundamental de esta práctica es el testing
    • Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance
    • El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.
  • Plan de actividades de aseguramiento de la calidad
    • Conjunto de actividades que serán ejecutadas para generar confianza en que el producto cumplirá con los requerimientos y el proceso es efectivo
    Verificación de la Calidad Cliente Necesidades Requisitos Revisiones Verificaciones Validaciones Producto
    • Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto.
    • RUP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo.
    • Las solicitudes de cambios formales facilitan la claridad de comunicación
    • La propagación del cambio es evaluable y controlable
    • Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo
    Control de cambios
  • Control de cambios Administración de configuración y cambios Fallas reportadas Órdenes de Trabajo Petición de nuevas características Petición de cambios y arreglo de defectos Administración de configuración Calidad del producto
  • Disciplinas y Flujos de Trabajo
  • Disciplinas
    • Una disciplina es una colección de actividades relacionadas vinculadas con un área específica del proyecto.
    • Este agrupamiento de actividades en disciplinas es principalmente para facilitar la comprensión del proyecto desde la perspectiva tradicional del modelo en cascada.
    Flujo de Trabajo
    • Un flujo de trabajo describe la secuencia en que se realizan las actividades en una disciplina, quienes la realizan (trabajadores) y que artefactos producen. .
    • Modelado del negocio : describe la estructura y la dinámica de la organización.
    • Requisitos : describe el método basado en casos de uso para extraer los requisitos.
    • Análisis y diseño : describe las diferentes vistas arquitectónicas.
    • Implementación : tiene en cuenta el desarrollo de software, la prueba de unidades y la integración.
    • Pruebas : describe los casos de pruebas, los procedimientos y las métricas para evaluación de defectos.
    • Despliegue : cubre la configuración del sistema entregable.
    Disciplinas de Proceso
    • Gestión de configuraciones : controla los cambios y mantiene la integridad de los artefactos de un proyecto.
    • Gestión del Proyecto : describe varias estrategias de trabajo en un proceso iterativo.
    • Entorno : cubre la infraestructura necesaria para desarrollar un sistema.
    Disciplinas de Soporte
  • Disciplinas y Flujos de Trabajo Disciplinas de Proceso Disciplinas de Soporte
  • Modelamiento de Negocio
    • Los objetivos son:
      • Entender la estructura y la din ámica del negocio .
      • Asegurar que los clientes, usuarios y desarrolladores tengan un entendimiento común de la organización.
      • Un Modelo de Casos de Uso del Negocio describe los proceso de negocio de una empresa en términos de
        • casos de uso del negocio y
        • actores del negocio
      • que se corresponden con los procesos del negocio y los clientes respectivamente .
  • Modelamiento de Negocio – Flujo de Trabajo
  • Requerimientos
    • Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer:
      • Relevar requerimientos
      • Documentar funcionalidad y restricciones
      • Documentar decisiones
      • Identificar actores
      • Identificar casos de uso
    • Los requerimientos no funcionales se incluyen en una especificación complementaria.
  • Requerimientos – Flujo de Trabajo
  • Análisis y Diseño
    • Objetivos:
    • Ejecutar las tareas y funciones descritas en los casos de uso
    • Satisfacer todos los requerimientos
    • Flexible a cambios
    • El diseño se centra en la noción de arquitectura
    • Diseñar y validar la arquitectura es una tarea esencial.
    • El modelo de diseño consta de
            • Clases estructuradas en paquetes
            • Diseños de subsistemas con interfaces definidas (componentes)
            • Forma de colaboración entre las clases.
  • Análisis y Diseño – Flujo de Trabajo
  • Implementación
    • Objetivo:
      • Definir la organización del código
      • Implementar clases y objetos en forma de componentes (fuente, ejecutables, etc.)
      • Probar las componentes desarrolladas
      • Integrar las componentes en un sistema ejecutable
  • Implementaci ón – Flujo de Trabajo
  • Test
    • Objetivo:
      • Verificar la interacción entre los objetos
      • Verificar la integración apropiada de componentes
      • Verificar que se satisfacen los requerimientos
      • Identificar los defectos y corregirlos antes de la instalación
    • RUP describe como planear y ejecutar estas pruebas.
    • RUP propone probar los componentes desde el principio: Confiabilidad, funcionalidad y performance.
  • Test – Flujo de Trabajo
  • Despliegue
    • Producir un producto y hacerlo llegar a sus usuarios finales.
    • Incluye varias actividades:
      • Producir un “release”
      • Empaquetar el software
      • Distribuir el software
      • Realizar pruebas beta
      • Instalar el software
      • Apoyar a los usuarios
      • Migración de datos
  • Despliegue – Flujo de Trabajo
  • Administración y Configuración de Cambios
    • Forma de controlar los artefactos producidos por las personas que trabajan en el proyecto.
    • Algunos problemas habituales:
      • Actualizaciones simultáneas
      • Múltiples versiones
    • RUP da guías para:
      • Desarrollos en paralelo
      • Automatizar la construcción
      • Administrar defectos
  • Administración y Configuración de Cambios – Flujo de Trabajo
  • Administración del Proyecto
    • Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios.
    • Existen pocos proyectos realmente exitosos.
    • RUP incluye:
      • Un framework para manejo de proyectos de software
      • Guías para planificación, provisión de personal, ejecución y monitoreo de planes
      • Un framework para manejar riesgos
  • Administración del Proyecto – Flujo de Trabajo
  • Entorno
    • Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto.
    • RUP guía en la configuración de un ambiente de proceso apropiado a cada proyecto.
    • Se debe seleccionar un conjunto de artefactos para el proyecto, esta elección se puede recoger en un documento breve llamado Marco de Desarrollo
  • Entorno
  • Requerimientos
    • El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto.
    • Hay diferentes puntos de partida para la captura de requisitos.
      • En algunos casos comenzamos haciendo un modelo del negocio o partimos de uno ya desarrollado.
      • En otros casos el cliente puede ya haber desarrollado una especificación completa de requisitos no basada en objetos, de la cual podemos partir.
  • Requerimientos - Workflow Analista Arquitecto Especificador de Casos de uso Diseñ ador de interface
  • Requerimientos Trabajador Responsable de (artefacto) Analista de sistemas Modelo de casos de uso Actores Glosario Especificador de casos de uso Caso de uso Dise ñador de Interfaz de Usuario Prototipo de interfaz de usuario Arquitecto Descripci ón de la arquitectura (vista del modelo de casos de uso)
  • Análisis
    • Durante el análisis, revisamos los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos.
    • El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.
  • An álisis - Workflow Arquitecto Ing de Casos de Uso Ing de Componentes
  • An álisis Trabajador Responsable de (artefacto) Arquitecto Modelo de An álisis Descripci ón de la arquitectura Ingeniero de Casos de Uso Realizaci ón de casos de usos - Análisis - Ingeniero de Componentes Clases del An álisis Paquete del an álisis
  • Dise ñ o
    • Durante el diseño modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseño es el modelo de análisis.
    • El diseño es el centro de atención al final de la fase de elaboración y comienzo de las iteraciones de construcción .
  • Dise ñ o Modelo de An álisis Modelo de Dise ño Modelo conceptual. Modelo f ísico (implementación) Gen érico respecto al diseño (aplicable a varios diseños) Espec ífico para una implementación Tres estereotipos: entidad, control, interface. Cualquier nro. de estereotipos f ísicos. Menos formal. Mas formal. Menos caro de desarrollar M ás caro.
  • Dise ñ o Modelo de An álisis Modelo de Dise ño Menos capas. M ás capas. Din ámico (no muy centrado en la secuencia) Din ámico (muy centrado en la secuencia) Creado principalmente como trabajo manual Creado fundamentalmente como "programaci ón visual" en ing.de ida y vuelta. Puede no mantenerse todo el ciclo de vida. Debe ser mantenido todo el ciclo de vida.
  • Dise ñ o - Workflow Arquitecto Ing de Casos de Uso Ing de Componentes
  • Dise ñ o Trabajador Responsable de (artefacto) Arquitecto Modelo de dise ño Modelo de despliegue Descripci ón de la arquitectura Ingeniero de Casos de Uso Realizaci ón de casos de usos - Diseño - Ingeniero de Componentes Clases del dise ño Subsistema de Dise ño Interfaz
  • Implementación
    • Se inicia con el resultado del diseño y se implementa el sistema en término de componentes, es decir, ficheros de código fuente, scripts, ficheros de código binario, ejecutables, y similares.
    • Es el centro durante las iteraciones de construcción.
    • Aunque también se realiza durante :
      • La fase de elaboración, para crear la línea base ejecutable de la arquitectura
      • La fase de transición para tratar defectos tardíos.
  • Implementación Trabajador Responsable de (artefacto) Arquitecto Modelo de implementaci ón Modelo de despliegue Descripci ón de la arquitectura Integrador de sistema Integraci ón de sistema Ingeniero de Componentes Componente Implementaci ón de subsistema Interfaz
  • Implementación - Workflow Arquitecto Integrador del Sistema Ingeniero de Componentes
  • Prueba
    • Los objetivos de la prueba son:
      • Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y las pruebas de sistema.
      • Diseñar e implementar pruebas creando:
        • Casos de prueba (especifican qué probar), Procedimientos de prueba (especifican cómo realizar las pruebas),
        • Componentes de prueba para automatizar las pruebas.
      • Realizar las pruebas.
  • Prueba Trabajador Responsable de (artefacto) Dise ñador de Pruebas Modelo de pruebas Casos de Prueba Procedimientos de prueba Evaluaci ón de pruebas Plan de pruebas Ingeniero de Componentes Componente de pruebas Ingeniero de Pruebas de Integraci ón Defecto Ingeniero de Pruebas de Sistema Defecto
  • Fases
  • Fase de Inicio
    • Durante la fase de inicio se desarrolla la descripción del producto final, y se presenta el análisis del negocio.
    • Esta fase responde las siguientes preguntas:
    • • ¿Cuáles son las principales funciones del sistema para los usuarios mas importantes?
    • • ¿Cómo podría ser la mejor arquitectura del sistema?
    • • ¿Cuál es el plan del proyecto y cuanto costará desarrollar el producto?
    • En esta fase se identifican y priorizan los riesgos mas importantes.
  • Fase de Inicio
    • Los objetivos son:
      • Poner en marcha el proyecto
      • Desarrollar el análisis del negocio hasta justificar la puesta en marcha plan de proyecto
    • Para ello
        • Esbozar una arquitectura
        • Mitigar los riesgos
        • Análisis inicial del negocio (coste, agenda, recuperación de la inversión)
    • Un documento de visión general:
      • Requerimientos generales del proyecto
      • Características principales
      • Restricciones
    • Modelo inicial de casos de uso (10% a 20 % listos).
    • Glosario.
    • Caso de negocio:
      • Contexto
      • Criterios de éxito
      • Pronóstico financiero
    • Identificación inicial de riesgos.
    • Plan de proyecto.
    • Uno o más prototipos.
    Artefactos Fase de Inicio
  • Inicio Elaboración Construcción Transición Objetivos del Ciclo de Vida
    • Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo.
    • Comprensión de los requerimientos plasmados en casos de uso.
    Hito: Fase de Inicio
  • Fase de Elaboración
    • Durante la fase de elaboración se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura.
    • Las iteraciones en la fase de elaboración:
      • Establecen una firme comprensión del problema a solucionar.
      • Establece un plan detallado para las siguientes iteraciones.
      • Elimina los mayores riesgos.
    • El resultado de esta fase es la línea base de la arquitectura.
  • Fase de Elaboración
    • Los objetivos son:
      • Recopilar la mayor parte de los requisitos definiéndolos como casos de uso
      • Establecer una arquitectura sólida para guiar las fases posteriores
      • Continuar la observación y control de los riesgos críticos
      • Completar el plan de proyecto
    • Para ello
        • Se toman decisiones considerando la comprensión global del sistema: ámbito, requisitos funcionales y no funcionales
    • Modelo de casos de uso (80% completo) con descripciones detalladas.
    • Otros requerimientos no funcio-nales 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.
    Fase de Elaboración Artefactos:
    • Condiciones de éxito de la elaboración:
      • ¿Es estable la visión del producto?
      • ¿Es estable la arquitectura?
      • ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos?
      • ¿Están de acuerdo con el plan todas las personas involucradas?
    Concepción Elaboración Construcción Transición Arquitectura de Ciclo de Vida Hito: Fase de Elaboración
    • En esta fase todas las componentes restantes se desarrollan e incorporan al producto.
    • Todo es probado en profundidad.
    • El énfasis está en la producción eficiente y no ya en la creación intelectual.
    • Puede hacerse construcción en paralelo, pero esto exige una planificación detallada y una arquitectura muy estable.
    Fase de Construcción
  • Fase de Construcción
    • Los objetivos son:
      • Línea base de la arquitectura crece hasta convertirse en el sistema completo
      • Riesgos reducidos o rutinarios
      • Implementación de los casos de uso
      • Prototipo
    • Para ello
        • A través de sucesivas iteraciones e incrementos se desarrolla un producto software, listo para operar, éste es frecuentemente llamado versión beta
    • El producto de software integrado y corriendo en la plataforma adecuada.
    • Manuales de usuario.
    • Una descripción del “release” actual.
    Artefactos: Fase de Construcción
    • Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos.
    • Condiciones de éxito:
      • ¿El producto está maduro y estable para instalarlo en el ambiente del cliente?
      • ¿Están los interesados listos para recibirlo?
    Concepción Elaboración Construcción Transición Capacidad Operacional Hito: Fase de Construcción
  • Fase de Transición
    • Los objetivos son:
      • Cumplir requisitos
      • Gestionar todos los aspectos de implantación
      • Pruebas de aceptación
    • Para ello
      • Las iteraciones en esta fase continúan agregando características al sw.
      • El equipo se encuentra ocupado en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior.
    • El objetivo es traspasar el software desarrollado a la comunidad de usuarios.
    • Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos).
    • Incluye:
      • 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
    Fase de Transición
    • Condiciones de éxito:
      • ¿ Se han alcanzado los objetivos fijados en la fase de Inicio ?
      • ¿ El usuario está satisfecho ?
    Concepción Elaboración Construcción Transición Hito: Fase de Transición Producto
  • RUP y CMMI
    • Capability Maturity Model Integration.
    • Modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.
    • Desarrollado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versión en enero de 2002.
    • Para los usuarios es difícil especificarlos en forma cuantitativa
    Modelo CMMI
    • CMMI se desarrolló para facilitar y simplificar la adopción de varios modelos de forma simultánea, y su contenido integra y da relevo a la evolución de sus predecesores:
      • CMM-SW (CMM for Sofwtare)
      • SE-CMM(Systems Engineering Capability Maturity Model)
      • IPD-CMM(Integrated Product Development)
    Modelo CMMI
  • CMMI – Niveles de Madurez NIVEL Descripción 1-Inicial Punto base. La organización tiene procesos ad-hoc o caóticos. El éxito se debe a personas heroícas. 2-Repetible La organización empieza a guardar información. Ya hay definiciones, pueden repetirse éxitos anteriores. 3-Definido Se conocen procesos estándares para desarrollar o mantener software. Hay prácticas de Ingeniería de Software y de Administración de procesos. 4-Administrado Se usan datos recolectados. Las decisiones están basadas en datos cuantitativos. Los procesos son medidos, hay retroalimentación. 5-Optimizado La organización se dedica a mejorar contínuamente. Se localizan debilidades y fortalezas.
  • CMMI Areas Clave de Proceso (KPAs) NIVEL Áreas Clave de Proceso 1-Inicial 2-Repetible Gestión de Requisitos (REQM) , Planificación de proyecto, Monitorización y control de Proyectos, Gestión y acuerdo de suministros, Medición y Análisis, Gestión de la calidad de procesos y productos, Gestión de la configuración 3-Definido Desarrollo de requisitos (RD) , Solución técnica, Verificación, Validación, Integración de producto, Procesos orientados a la organización, Formación, Gestión Integrada de proyecto, Gestión de riesgos, Análisis y resolución de decisiones 4-Administrado Gestión cuantificada de proyectos, Rendimiento de los procesos de la organización 5-Optimizado Innovación y desarrollo
  • Análisis RUP – CMMI
    • RUP es un proceso
      • que define quién debe hacer las cosas, qué debe hacerse, cómo y cuándo.
      • Dado su enfoque mantiene modelos en lugar de gran cantidad de documentación, utiliza un lenguaje concreto y bien definido (UML).
    • CMMI es un modelo estático
      • que define áreas claves (PA) en las que se deben llevar a cabo prácticas específicas o genéricas, por lo tanto el hecho de implementar RUP en el desarrollo de un proyecto implica que ciertas KPA de CMMI sean alcanzadas y otras no.
  • Análisis RUP – CMMI Áreas Clave de Proceso Revisi ón Gestión de Requisitos RUP define claramente el proceso de administración de requerimientos y aporta herramientas como los casos de uso, es una de las bases de RUP Planificación de proyecto RUP habla de la planeación del proyecto de manera iterativa y del control de riesgos. Monitorización y control de Proyectos RUP define cómo debe ser el control del proyecto. Gestión de la configuración RUP es muy claro cuando se habla de administración de la configuración incluso es una de las mejores prácticas recomendada.
  • Análisis RUP – CMMI Áreas Clave de Proceso Revisi ón Gestión y acuerdo de suministros RUP no menciona nada sobre administración de acuerdos, es algo no considerado. Medición y Análisis La medición y análisis no están contemplados detalladamente en RUP. Gestión de la calidad de procesos y productos En la etapa de transición se lleva a cabo la verificación de la calidad aunque no tan detallada como lo exige CMMI. La verificación de calidad del producto está bien definida pero la evaluación de calidad del proceso no está considerada.
  • Conclusiones
    • La aplicación formal del Proceso Unificado supone:
      • Desventajas:
        • Grandes esfuerzos en la construcción de modelos.
        • Necesidad del soporte de herramientas informáticas.
      • Ventajas:
        • Disminuye el riesgo del error de análisis / diseño acumulado.
        • Aligera el esfuerzo en implementación.
        • Proporciona la documentación del ciclo de vida en el mismo proceso.
    Conclusiones
    • El Proceso Unificado es flexible y se puede adaptar al grado de complejidad del modelo de proceso de desarrollo (descarte de algunos modelos o flujos).
    • El Proceso Unificado es abierto y permite la incorporación de enfoques y artefactos complementarios:
      • Patrones de diseño.
      • Patrones de implementación.
      • Combinación de varios modelos de proceso.
      • Arquitecturas Dirigidas por Modelos ( Model Driven Architectures ).
    Conclusiones
    • Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado, Addison-Wesley, Madrid, 1999.
    • Bruegge B., Dutoit A.H. Ingeniería de Software Orientado a Objetos, Prentice Hall– Pearson educación, México, 2002.
    • Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de Software, Addison-Wesley, Madrid, 2000.
    • Pressman R.S. Ingeniería del Software. Un enfoque práctico (5ª ed.) Mc Graw-Hill; New York , 2001.
    • Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000.
    • Sommerville I. Ingeniería de software, 6ª edición, Prentice Hall – Pearson educación, México, 2002.
    • Stevens P., Pooley R. Utilización de UML en Ingeniería del Software con Objetos y Componentes, Addison-Wesley, Madrid, 2002.
    Bibliografía