Embed Size (px)
Citation preview
Universidad de San Martín de Porres
Facultad de Ingeniería y Arquitectura
Curso de Especialización Profesional / 2008 - II
Curso: Ingeniería de Software Orientada a Objetos
Mg. Ing. Géner Zambrano [email protected]
Sesión 03
RUP
Contenido:
Describir las 6 mejores prácticas en desarrollo de software.
Describir el Rational Unified Process (RUP) en términos de sus fases y disciplinas.
Describir el modelo iterativo para desarrollo de software
Comprender los fundamentos del proceso de trabajo del RUP deacuerdo a las necesidades específicas de la organización
RUPRUP
Desarrollo de Sistemas
Notación:UML
Herramientas:Suite Rational
Visual ParadigmPoseidon
Proceso:Rational Unified Process
Métrica 3.0XP
¿Qué es Rup?
El Proceso Unificado de Rational (RUP, el original inglés Rational Unified Process) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. RUP fue creado por Rational software, filial IBM. RUP está basado en el seguimiento de una serie de normas o “mejores prácticas” aplicadas a cuatro etapas del desarrollo software: iniciación, elaboración, construcción y transición.
Objetivos:
Asegurar la producción de software de calidad dentro de plazos.Presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones).
Rup, Evolución:
Rational Unified Process 5.0
Rational Objectory Process 4.1
Rational Objectory Process 4.0
Rational Approach Objectory
Process
Pruebas de rendimiento y carga(Performance Awareness)
Ingeniería de Negocios Ingeniería de Datos(Vigortech)
UML 1.2
Proceso SQA(SQA Inc.)
UML 1.0
Escuela de Requerimientos(Requisite Inc.)
Diseño OO de IU
Administración de Configuración y Cambios
(Pure-Atria)
OMTBooch
UML 0.8
1998
1997
1996
1995
1987Ericsson method1967
RUP, estructura:
Workflow, Workflow Detail , Roles, Actividades y ArtefactosEjemplo
Workflow Detail:Analyse the ProblemWorkflow: Requirements
Actividades
Roles Artefactos
RUP, elementos:
¿Quién lo hace?Rol: System Analyst:
Unidad de trabajo que puede ejecutar un individuo en un rol específicoEjemplo: ¿Cómo?
Actividad: Desarrollo de la visión
¿Qué se produjo?Artefacto: Resultado
Elementos del RUP: Workflows (¿Qué se está haciendo?)
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 ApoyoEnvironment (Entorno)Project Management (Gestión del Proyecto)Configuration & Change Management (Gestión de Configuración y Cambios)
Elementos en RUP: Roles
Definen el comportamiento y responsabilidades de los participantes del equipo de trabajo.
Analyst:Business-Process AnalystBusiness DesignerBusiness-Model ReviewerRequirements ReviewerSystem AnalystUse-Case SpecifierUser-Interface Designer
Developer:ArchitectArchitecture ReviewerCapsule DesignerCode ReviewerDatabase DesignerDesign ReviewerDesignerImplementerIntegrator
...continua, Elementos en RUP: Roles
Other:Course DeveloperGraphic ArtistStakeholderSystem AdministratorTechnical WriterTool Specialist
Testing professional:Test DesignerTester
Manager: Change Control ManagerConfiguration ManagerDeployment ManagerProcess EngineerProject ManagerProject Reviewer
Características del RUP
Características escenciales del RUP:
Guiado y Manejado por Casos de Uso
Centrado en la Arquitectura
Iterativo e Incremental
...continua, Características escenciales del RUP:
Capturar, definir y validar los casos de
usoAnálisis & Diseño
Requisitos
Implementación
Pruebas
Casos de Usointegran el
trabajo
Análisis y Diseño
Guiado y Manejado por Casos de Uso
Realizar loscasos de uso
Verificar que se satisfacen loscasos de uso
...continua, Características escenciales del RUP:
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
Architecture
Iterativo e IncrementalEl ciclo de vida iterativo se basa en la evolución de prototiposejecutables que se muestran a los usuarios y clientesEn el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala
...continua, Características escenciales del RUP:
EnfoqueCascada
EnfoqueIterativo eIncremental
Las mejores prácticas del RUP
MEJORES PRÁCTICAS DEL RUP
VI. Controle los Cambios
II. Administre los II. Administre los RequerimientosRequerimientos
III. Use III. Use Arquitectura Arquitectura
de de ComponentesComponentes
IV. Modele IV. Modele VisualmenteVisualmente
V. Verifique V. Verifique CalidadCalidad
I. Desarrolle Iterativamente
I. Desarrollo iterativo (reducir riesgos y tiempo)
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 va creciendo el sistema. Es necesario utilizar un acercamiento iterativo que permita un entendimiento incremental del problema a través de refinaciones sucesivas, creando de manera incremental una solución efectiva mediante múltiples iteraciones. Con esto se logra reducir los riesgos del proyecto.
Las ventajas principales son:Mitigación de riesgosAcomodación de cambiosAlcanzar la más alta calidadAumento de la reutilización
II. Administración de Requisitos(El primer paso del éxito del proyecto )
El fracaso de un proyecto radica en la mala (o ausencia) administración de los requerimientos.
II. Administración de Requisitos, continua...
Los principales problemas de un mal manejo de requerimientos son:
Incapacidad para manejar los cambios en los requerimientosdurante el desarrollo. Falta de especificación detallada de los requerimientos. Mala organización y control de requerimientos. Requerimientos mal entendidos.
Pasos en la Administración de Requerimientos:
Analizar el problemaEntender las necesidades del inversionistaDefinir el sistemaRefinar la definición del sistemaAdministrar el control de requerimientos
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.
III. Componentes Arquitectónicos(La base para la reutilización de software)
Uno de los peligros en sistemas grandes y complejos es que al hacer cambios a una parte de la aplicación se impacten otras partes con el "efecto dominó". Los equipos de desarrollo exitosos resuelven estas dependencias potenciales a través del uso de arquitecturas basadas en componentes.
El ensamble de aplicaciones mediante módulos manejables crea arquitecturas resistentes y flexibles que evitan que los cambios al software conlleven esfuerzos masivos.
A medida que las organizaciones reutilizan componentes, reducen la cantidad de código a generar para cada aplicación. Así logran acelerar el tiempo de desarrollo y reducen la probabilidad de introducir errores al sistema.
III. Componentes Arquitectónicos, continua...
La arquitectura debe ser:–Flexible–Fácil de modificar–Intuitivamente comprensible–Promueve la reutilización de componentes
Organización de los componentes del sistema
IV. Modelado Visual UML (Los planos del éxito)
Para describir la complejidad de las operaciones actuales, los equipos de desarrollo necesitan una manera altamente descriptiva, intuitiva y precisa para modelar toda la funcionalidad del sistema.
Desarrollar bloques de construcción:–Ocultan detalles–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.
El RUP describe cómo modelar visualmente aplicaciones para capturar la estructura y el comportamiento de la arquitectura y de los componentes.
V. Verificación de la Calidad(Construyendo con calidad de principio a fin)
Calidad:La característica de demostrar el logro de la realización de un producto, que satisface los requerimientos convenidos Según lo estimado y conducido por un proceso conveniente.Es mucho más costoso detectar y arreglar errores ya en producción que encontrarlos en etapas tempranas
Tres Dimensiones de la Calidad:
Funcionalidad: la aplicación hace lo requerido?
Confiabilidad: la aplicación responde aceptablemente?
Rendimiento: la aplicación rinde bajo cargas de producción?
VI. Control de Cambios(Controlar el proyecto y eliminar los retrasos)
Gerencia del espaciode trabajo
Desarrollo paralelo
Gerencia de la estructuraIntegración
Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto.
VI. Control de Cambios, continua...
Los desarrolladores manipulen y controlen con orden y seguridad sus enormes colecciones de archivos y componentes para cada aplicación.
Coordinación de artefactos y actividades
Coordinación de iteraciones y releases
Control de cambios de software
Control de las versiones de los artefactos
El trabajo efectivo requiere de una administración formal de los cambios. Cuando se cuenta con una administración de cambios del software realmente efectiva se logra que:
Estructura del Rup
Estructura del Rup
AdministraciónAmbiente
Modelación de Negocios
Implementación
Prueba
Análisis y Diseño
Iteración(es)Preliminar
Iter.#1
FasesF. Trabajo Procesos
Iteraciones
F. Trabajo Soporte
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Despliegue
Admin. Configuración
Requerimientos
Elaboración TransiciónInicio Construcción
Fases
Disciplinas
La Plataforma Rational
Requirements & Use Cases
Unit TestsModels Code
Test Cases DefectsTest Plan System Tests
TestResults
– ClearCase, ClearQuest
– Rational Unified Process, Rational Developer Network
– SoDA, ProjectConsole
RequisitePro, XDE, Rose XDE, Rose XDE, Rose + IDE
Rose /RQA,Test RT, Purify+
TestManagerTestManager
Robot, Test RT TestManagerTestManager ClearQuest
Software Configuration Management
Progress Metrics and Reporting
Common Process and Guidance
Estructura del RUP, ejes:
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 actividades, artefactos, trabajadores y flujos de trabajo. Representa las disciplinas que agrupan actividades por su naturaleza.
Fases del Rup:
El ciclo de vida del Rup esta representado y organizado por fases:
1. En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 fases secuenciales, cada cual concluye con un producto intermedio.
2. Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la misma.
3. Las fases son: Inicio (Inception), Elaboración, Construcción y Transición.
I. Fase de Inicio (los objetivos del ciclo de vida)Fases del Rup ¿Cuándo se hace?
Objetivo general:
• El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto.
• Esta fase es significativamente primaria para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos. Para proyectos de mejora de software existente esta fase es más breve y se centra en asegurar que vale la pena y es posible, desarrollar el proyecto.
I. Fase de Inicio (los objetivos del ciclo de vida)
Objetivos específicos:
• Establecer el alcance del proyecto, incluyendo la visión operacional, criterio de aceptación, qué se espera del producto y qué no.
• Discriminar los casos de uso críticos del sistema, los escenarios primarios de operación que dirigirán las principales decisiones de diseño.
• Mostrar al menos una arquitectura candidata para alguno de los escenarios primarios.
• Estimar el coste global y planificación para el proyecto completo (estimaciones más precisas se obtendrán en la fase siguiente).
I. Fase de Inicio (los objetivos del ciclo de vida)
Hito:• Las partes interesadas deben acordar el ámbito del
proyecto identificando los principales riesgos y la viabilidad del mismo.
• El alcance y la estimación de tiempo y costo.• Comprensión de los requerimientos plasmados en casos
de uso.
Concepción Elaboración Construcción Transición
Objetivos del Ciclo de Vida
I. Fase de Inicio, productos (artefactos):
Identificación inicial de riesgos.Plan de proyecto.Caso de negocio:
ContextoCriterios de éxitoPronóstico financiero
Un documento de visión general:Requerimientos generales del proyectoCaracterísticas principalesRestricciones
Modelo inicial de casos de uso (10% a 20 % listos).Prototipos.Glosario.
II. Fase de Elaboración (la arquitectura del ciclo de vida)
Objetivo general:
El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase. La arquitectura debe abarcar todos las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo.
II. Fase de Elaboración (la arquitectura del ciclo de vida)
Objetivos específicos:
Analizar el dominio del problema.
Desarrollar un plan de proyecto
Establecer la línea base de la arquitectura sólida obtenida después de tratar los escenarios más significativos.
Establecer el ambiente de soporte para el proyecto. Esto incluye crear los planes de desarrollo, preparar las plantillas de los documentos, instrucciones, y herramientas.
II. Fase de Elaboración, Hito:
Concepción Elaboración Construcción
Arquitectura a desarrollar en el Ciclo de Vida
Transición
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?¿Es el plan del proyecto algo realista?¿Están de acuerdo con el plan todas las personas involucradas?
Obtener una línea base de la arquitectura del sistema, capturar la mayoría de los requisitos y reducir los riesgos principales así como permitir la escalabilidad del equipo del proyecto durante la fase de construcción.
II. Fase de Elaboración, productos:
Modelo de casos de uso (80% completo) con descripciones detalladas.
Otros requerimientos 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.
III. Fase de Construcción (Capacidad operativa inicial)
Objetivo general:
El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base. Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de las operaciones para optimizar costos, tiempo y calidad
III. Fase de Construcción (Capacidad operativa inicial)
Objetivos específicos:
El énfasis está en la producción eficiente y no ya en la creación intelectual.
Obtener versiones útiles (alfa, beta, y otras entregas de prueba).
Desarrollar de forma iterativa e incremental un producto completo que esté listo para su transición hacia la comunidad de usuarios.
Decidir si el software, sitio y usuarios están listos para la instalación de la aplicación.
III. Fase de Construcción, Hito:
Capacidad Operacional
Construcción TransiciónConcepción Elaboración
Condiciones de éxito:¿El producto está maduro y estable para instalarlo en el ambiente del cliente?¿Están los interesados listos para recibirlo?
Desarrollo del sistema con calidad de producción, y puede entonces prepararse para la entrega al equipo de transición. En esta fase, toda la funcionalidad ha sido implementada, y completadas las pruebas para el estado alfa de la aplicación.
III. Fase de Construcción, productos:
Modelo completo de casos de uso y diseño
Liberaciones de productos ejecutables de funcionalidad incremental
Documentación de usuario
El producto de software integrado y corriendo en la plataforma adecuada.
Una liberación “beta” del producto
IV. Fase de Transición, continua...
Objetivo general:
Esta fase se enfoca en asegurar que el software este disponible para sus usuarios. Esta fase se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a los propuestos por el usuario. En este punto, la retroalimentación de los usuariosse centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización
IV. Fase de Transición, continua...
Objetivos específicos:
1. Realizar pruebas para validar el nuevo sistema con las expectativas de los usuarios. Realizar pruebas y la operación en paralelo al sistema anterior que se está reemplazando.
2. Entrenamiento de usuarios y encargados del mantenimiento.
3. Actividades de corrección de errores, mejoras en el funcionamiento y rendimiento y usabilidad.
4. Evaluación de la línea base de la instalación con la visión completa y criterios de la aceptación del producto y lograr el consenso de los involucrados.
5. Ingeniería específica de instalación: comercialización y producción de los paquetes, etc.
IV. Fase de Transición, continua...
Concepción Elaboración Construcción Transición
Producto.Sacar el producto
final
Consiste en decidir si los objetivos se cumplieron y si debe comenzarse otro ciclo de desarrollo. Es el resultado de la revisión y aceptación por parte del cliente de los productos y subproductos que le han sido entregados.
IV. Fase de Transición, productos:
Liberaciones ejecutables de producto (comparación paralela con sistemas antiguos)
“Pruebas beta” para validar el nuevo sistema vs. las expectaciones del usuario
Manuales de usuario actualizados
Documentación de desarrollo actualizada
Entrenamiento de usuarios
Distribución del producto.
Fases del Rup, Hitos:
ConcepciónConcepción ElaboraciónElaboración ConstrucciónConstrucción TransiciónTransición
Compromiso de recursos para fase
elaboración
HitoObjetivos,
visión
HitoArquitectura
HitoCapacidad
Operacional
Aceptacióndel cliente
LiberaciónProducto
Tiempo
Una Iteracción es una secuencia de actividades con un plan establecido y criterio de evaluación, que da como resultado una versión del sistema.
Fases del Rup, Artefactos:
Disciplinas, flujos de trabajo:
I. Modelo del Negocio
Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una colección de datosque son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajodeterminado. Además, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan la estructura de la información y las políticas de la empresa.
La finalidad del modelado del negocio, es describir cada proceso del negocio del cliente, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de negocio.
II. Requerimientos
• Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer:
Relevar requerimientosDocumentar funcionalidad y restriccionesDocumentar decisionesIdentificar actoresIdentificar CU
• Los casos de uso describen la funcionalidad del sistema.
• Los requerimientos no funcionales se incluyen en una especificación complementaria.
• Permite definir la interfaz de usuario (prototipo) del sistema enfocándose en sus necesidades.
III. Análisis y Diseño
• Descripción de cómo se implementará el sistema (planos).
• Debe:– Desarrollar las tareas y funciones descritas en los casos de uso– Satisfacer todos los requerimientos– Ser flexible a cambios
• El diseño se centra en una arquitectura robusta.
• Diseñar y validar la arquitectura es una tarea esencial.
• El modelo de diseño consta de: – Clases estructuradas en paquetes– Diseño de subsistemas con interfaces definidas (componentes)– Colaboración entre las clases.
IV. Implementación
Objetivos:
Definir la organización del códigoImplementar clases y objetos en forma de componentes (fuente, ejecutables, etc.)Probar los componentes desarrolladasIntegrar los componentes (resultados) en un sistema ejecutable
La disciplina de implementación limita su alcance a como las clases individuales serán probadas. Las pruebas del sistema son descritas en futuras disciplinas.
V. Pruebas
Esta disciplina actúa como un proveedor de servicios a las otras disciplinas en muchos aspectos. Pruebas se enfoca principalmenteen la evaluación y aseguramiento de la calidad del producto, desarrollado a través de las siguientes prácticas
Encontrar fallas de calidad en el software y documentarlas.Recomendar sobre la calidad percibida en el software.Validar y probar las suposiciones hechas durante el diseño y la especificación de requerimientos de forma concreta.Validar que el software trabaja como fue diseñado.Validar que los requerimientos son implementados apropiadamente
Su objetivo es encontrar y documentar los defectos en la calidad del software
VI. Distribución
• Incluye varias actividades:Producir un “release”Empaquetar el softwareDistribuir el softwareInstalar el softwareApoyar a los usuarios
• A veces también incluye:Realizar pruebas betaMigración de datosAceptación formal
• La mayor parte de la distribución ocurre durante la transición.
Una vez que el producto de software a sido implementado y probado exitosamente, es momento de hacerlo llegar a sus usuarios finales.
Disciplinas, flujos de soporte:
I. Gestión del Cambio y Configuración
Consiste en controlar los cambios y mantener la integridad de los productos que incluye el proyecto.
El cambio es un factor de riesgo crítico en los proyectos de software. Los artefactos software cambian no sólo debido a acciones de mantenimiento posteriores a la entrega del producto,sino que durante el proceso de desarrollo, especialmente importantes por su posible impacto son los cambios en los requisitos.
Por otra parte, otro gran desafío que debe abordarse es la construcción de software con la participación de múltiples desarrolladores, posiblemente distribuidos geográficamente, trabajando a la vez en una release, y quizás en distintas plataformas.
II. Administración de Proyectos
Es el arte de balancear objetivos en competencia, gestionar los riesgos y sobreponerse a las restricciones para crear con éxito un producto que satisfaga las necesidades tanto de los clientes como de los usuarios finales.
El propósito de la Administración de Proyectos es:
Proveer un marco de trabajo para administrar los proyectos intensivos de software.Proveer guías prácticas para la planeación, soporte, ejecución y monitoreo de proyectos.Proveer un marco de trabajo para la administración del riesgo.
III. Ambiente
Proporciona a la organización el entorno de desarrollo de software apropiado, que contendrá las herramientas de desarrollo y del proceso, plantillas, documentos, convenciones a seguir, y cualquier otro elemento necesario para llevar adelante con éxito el desarrollo del proyecto.
Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto.
Fin de la sesión 03
RUP
