UNIVERSIDAD PRIVADA JOSE CARLOS MARIATEGUI

RUP: FASE TRANSICIN

2011
ANALISIS Y DISEO DE SISTEMAS II

La transicin es la etapa final de nuestro desarrollo de software, es la parte donde implantamos nuestro software a la comunidad, es decir a los usuarios.

CURSO: ANALISIS Y DISEO DE SISTEMAS II

I.

INTRODUCCION

Requisitos del Usuario

Proceso de Desarrollo

Sistema de Software

1) RUP es un proceso de desarrollo de software: - Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quin hace qu, cundo y cmo).

2) Objetivos: - Asegurar la produccin de software de calidad dentro de plazos y presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (miniproyectos) e incremental (versiones).

3) Es tambin un producto: - Desarrollado y mantenido por Rational. - Actualizado constantemente para tener en cuenta las mejores prcticas de acuerdo con la experiencia.

4) Aumenta la productividad de los desarrolladores mediante acceso a: - Base de conocimiento - Plantillas - Herramientas

5) Se centra en la produccin y mantenimiento de modelos del sistema ms que en producir documentos.

6) RUP es una gua de cmo usar UML de la forma ms efectiva.

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II

II.

DESARROLLO
RUP El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniera de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una metodologa de desarrollo iterativo enfocada hacia los casos de uso, manejo de riesgos y el manejo de la arquitectura.

El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad especfica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visin y el mismo proceso acerca de cmo desarrollar software.

Ciclo de Vida de RUP En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con un producto intermedio. Al terminar cada fase se realiza una evaluacin para determinar si se ha cumplido o no con los objetivos de la misma. Las fases son: Inicio (Inception), Elaboracin, Construccin y Transicin.

En la Ilustracin 1 las iteraciones estn representadas como franjas verticales delimitadas por lneas punteadas y marcadas por una letra que corresponde a la inicial de la fase y un ndice consecutivo. La fase inicial generalmente tiene una sola iteracin. El ciclo de vida iterativo ha comprobado ser uno de los ms efectivos para llevar una buena administracin de los proyectos de software.

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II CICLO DE VIDA DE UN SOFTWARE

En el ciclo de vida RUP veremos una implementacin del desarrollo en espiral. Con el ciclo de vida se establecen tareas en fases e iteraciones. El RUP maneja el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una base de inicio. Las 6 mejores prcticas de desarrollo que aplica RUP Desarrollo de software en forma iterativa Gestin de requerimientos Uso de arquitecturas basadas en componentes Modelizacin visual del software Verificacin de calidad del software Control de cambios

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II 1. Desarrollo de software en forma iterativa Dada la complejidad de los sistemas de software modernos no es posible definir el problema entero en forma secuencial, disearlo en su totalidad, construirlo y testearlo. El enfoque iterativo permite ir creciendo en el entendimiento del problema.a travs de refinamientos sucesivos. Esto tambin permite introducir cambios tcticos en los requerimientos, caractersticas del sistema o en los tiempos. 2. Gestin de requerimientos Las nociones de casos de uso y escenarios resultaron ser una forma excelente de capturar requerimientos funcionales y de asegurar que estos rijan el diseo, la implementacin y el testeo de software; haciendo ms probable que el sistema final cumpla exactamente con lo que pidi el cliente. 3. Uso de arquitecturas basadas en componentes RUP apoya el desarrollo de software basado en componentes. Los componentes son mdulos no triviales, subsistemas que satisfacen una funcin definida. RUP proporciona un acercamiento sistemtico definiendo una arquitectura usando componentes nuevos y existentes. stos estn montados en una arquitectura bien definida, o bien ad hoc, o en una infraestructura de componentes reutilizables tal como el Internet, el CORBA, y J2EE 4. Modelizacin visual del software El proceso le demuestra cmo modelar visualmente software para capturar la estructura y el comportamiento de arquitecturas y de componentes. Esto permite que usted oculte los detalles y que escriba cdigo usando bloques de construccin grficos. Las abstracciones visuales le ayudan a comunicar diversos aspectos del software, ayudan a mantener la consistencia entre un diseo y su puesta en marcha; y favorecen la comunicacin inequvoca. El UML es la base de esta modelizacin visual. 5. Verificacin de calidad del software Una performance y una confiabilidad pobres son los factores comunes que inhiben dramticamente la aceptabilidad de los usos del software hoy en da. Por lo tanto, la calidad se debe revisar con respecto a los requerimientos basados en la confiabilidad, funcionalidad, performance de la aplicacin y del sistema. RUP le asiste en el planeamiento, el diseo, la puesta en marcha, la ejecucin, y la evaluacin de estos tipos de pruebas. El estudio de la calidad est incorporado como parte del proceso, en todas las actividades, implicando a todos los participantes, usando medidas y criterios objetivos, y no se trata de una actividad separada realizada por otro grupo.

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II 6. Control de cambios La capacidad de manejar los cambios - asegurndose que cada cambio sea aceptable, y pudiendo continuar con los mismos- es esencial en un ambiente en el cual el cambio es inevitable. El proceso describe cmo controlar, seguir y supervisar cambios para permitir el desarrollo iterativo acertado. Tambin gua sobre cmo establecer los espacios de trabajo seguros para cada desarrollador proporcionando el aislamiento de los cambios realizados en otros espacios de trabajo y controlando los cambios de todos los dispositivos de software (modelos, cdigo, documentos, etc.). Describiendo cmo automatizar la integracin, hace que el equipo trabaje como una sola unidad

Fases de Ciclo de Vida a Modo de Referencia antes de tocar el tema Principal 1. Inicio (Inception). 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 ms breve y se centra en asegurar que vale la pena y es posible, desarrollar el proyecto. 2. Elaboracin El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseo e implementacin en la siguiente fase. La arquitectura debe abarcar todos las consideraciones de mayor importancia de los requerimientos y una evaluacin del riesgo. 3. Construccin El objetivo de la fase de construccin 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 administracin de recursos y control de las operaciones para optimizar costos, tiempo y calidad. 5

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II 4. Transicin Esta fase se enfoca en asegurar que el software este disponible para sus usuarios. Esta fase se puede subdividir en varias iteraciones, adems incluye pruebas del producto para poder hacer el entregable del mismo, as como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario. En este punto, la retroalimentacin de los usuarios se centra en depurar el producto, configuraciones, instalacin y aspectos sobre utilizacin. Durante esta fase de transicin busca garantizar que se tiene un producto preparado para su entrega al usuario. El objetivo es traspasar el software desarrollado a la comunidad de usuarios. Una vez instalado surgirn nuevos elementos que implicarn nuevos desarrollos (ciclos). Incluye: Pruebas Beta para validar el producto con las expectativas del cliente Ejecucin paralela con sistemas antiguos Conversin de datos Entrenamiento de usuarios Distribuir el producto

Objetivos: - Obtener autosuficiencia de parte de los usuarios. - Concordancia en los logros del producto de parte de las personas involucradas. - Lograr el consenso cuanto antes para liberar el producto al mercado.

PRINCIPALES CARACTERISTICAS

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso). Especificacin de las Fases

Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: Proceso: Las etapas de esta seccin son:

Modelado de negocio Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue

Soporte: En esta parte nos conseguimos con las siguientes etapas:

Gestin del cambio y configuraciones Gestin del proyecto Entorno

La estructura dinmica de RUP es la que permite que este sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

Inicio(Tambin llamado Incepcin) Elaboracin Desarrollo(Tambin llamado Implementacin, Construccin) Cierre (Tambin llamado Transicin)

Artefactos RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema estos artefactos son los siguientes: Inicio:

Documento Visin 7

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II

Especificacin de Requerimientos

Elaboracin:

Diagramas de caso de uso

Construccin:

Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica:

Diagrama de clases Modelo E-R (Si el sistema as lo requiere)

Vista de Implementacin:

Diagrama de Secuencia Diagrama de estados Diagrama de Colaboracin

Vista Conceptual:

Modelo de dominio

Vista fsica: Mapa de comportamiento a nivel de hardware. Roles -

Un Rol define el comportamiento y las responsabilidades de un individuo. Es como un "sombrero" que la persona usa durante el proyecto: Una persona puede tener varios sombreros Es el trabajo que desempea en un momento dado Responsabilidades: Hacer una serie de actividades Ser el responsable de una serie de artefactos

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II Actividades

Una actividad es una unidad de trabajo que se asigna a un trabajador. Ejemplo: Crear o modificar un artefacto

Una actividad lleva entre un par de horas y un par de das, involucra un solo trabajador y un nmero pequeo de artefactos.

Las actividades se consideran en la planificacin y evaluacin del progreso del proyecto.

Ejemplos: - Planificar una iteracin - Administrador de proyecto - Encontrar actores y casos de uso - Analista - Revisar el diseo - Revisor de diseo - Ejecutar pruebas de performance - Ing. de pruebas de performance

Recurso

Rol

Actividad

Grfico de asignacin de actividades Artefactos - Elementos de informacin producidos, modificados o usados por el proceso. - Son los productos tangibles del proyecto. - Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades. - Ejemplos: Un modelo, como el modelo de casos de uso o el modelo de diseo. Un elemento del modelo, como una clase o un caso de uso. Un documento tal como el Caso del Negocio o la Arquitectura del Software.

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEO DE SISTEMAS II Cdigo fuente. Cdigo ejecutable.

Ya hablamos algo de la fase de Transicin, indicando que la actividad principal era la PRUEBA del sistema, evidentemente es la actividad principal al inicio de la fase, sin embargo hay varias actividades que no dejan de ser menos importantes y que se las debe realizar en la Etapa de Implementacin, previo a la puesta en productivo del sistema. a continuacin damos un vistazo a estas actividades:

Preparacin de los datos para la carga inicial del sistema. Consiste en que el equipo institucional o equipo de usuarios involucrados en el proyecto, preparen la informacin necesaria para su carga inicial al sistema, antes de que ste entre en productivo. Para ello primero nosotros como analistas, debemos preparar los formularios o plantillas con los formatos de datos para que sean llenados por los usuarios, por lo general se usan hojas Excel, y una vez que se dispone de la informacin validada, se ingresa al sistema manualmente o si la informacin tiene un volumen considerable a travs de un programa de carga de datos, estos programa debemos desarrollarlos nosotros, estos programas se denominan "programas de batchinput", muy usados en el Sistema SAP, son programas que por lo general se usan una sola vez para cargar datos masivos, ya sea de hojas excel, archivos TXT o tambin para transferir los datos de un sistema antiguo al nuevo sistema. Para clarificar con un ejemplo, supongamos que estamos desarrollando un Sistema de gestin de Almacenes, que actualmente maneja sus procesos manualmente, para la carga inicial de datos se debern preparar plantillas en excel con las columnas de datos de acuerdo a lo requerido por nuestras pantallas de ingresos de datos, por ejemplo: Tabla de Unidades de Medida, tabla de grupos de materiales, lista de almacenes, datos tcnicos de los materiales, lista de centros solicitantes, lista de proveedores, etc.

Preparacin del plan de capacitacin de usuarios. Ya dijimos varias veces que RUP es para sistemas grandes, por lo tanto ser natural que hayan varios mdulos o subsistemas y obviamente muchos usuarios de diferentes reas de la empresa. Por lo tanto, nuestra responsabilidad es la preparacin del plan de formacin o capacitacin de los usuarios, ya sea por mdulos o por procesos relacionados.

Alumno: Franklin Cappa Ticona

10

CURSO: ANALISIS Y DISEO DE SISTEMAS II

Elaboracin de los manuales de usuario. Para la formacin de usuarios es importante ya disponer de los manuales de usuario y tambin para que este material sirva de soporte durante la puesta en productivo del sistema.

Configuracin y parametrizacin de las cuentas de usuario. Ser importante la definicin de los perfiles de usuario, cuentas de usuario, polticas de seguridad, control y auditora de usuarios, etc.

Migracin de los datos del sistema actual al nuevo sistema. Consiste en pasar los datos del sistema actual al nuevo sistema, usando las plantillas definidas previamente.

Puesta en Productivo del sistema. Consiste en empezar a operar el nuevo sistema, esta etapa requiere de dar mucho soporte a los usuarios hasta que estos tomen confianza y destreza con el nuevo sistema, es la etapa en la que hay un costo intangible que puede traer muchas complicaciones al equipo informtico. Cualquier cambio implica tensin y resistencia, que deberemos manejar con mucha habilidad.

Alumno: Franklin Cappa Ticona

11

CURSO: ANALISIS Y DISEO DE SISTEMAS II

III.

CONCLUSIONES
Consideramos que el Proceso Unificado es una metodologa completa y bien documentada. Lo utilizamos como una interesante fuente de ideas y herramientas y con una amplia disponibilidad de formacin tcnica y prctica. Siendo que estamos bien entrenados en esta tecnologa es que nos sentimos con la confianza de utilizarla, aumentando as significativamente nuestra probabilidad de xito al adaptar este proceso al presente proyecto. La metodologa RUP es ms apropiada para proyectos grandes (Aunque tambin pequeos), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios.

Alumno: Franklin Cappa Ticona

12

CURSO: ANALISIS Y DISEO DE SISTEMAS II

IV.

BIBLIOGRAFIA
Universidad de Chile - Departamento de Ciencias de la Computacin Presentacin IBM Desarrollo de Software Orientado a Objetos Internet: http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational http://www.slideshare.net/dersteppenwolf/la-ingeniera-de-software-yrup http://74.125.47.132/search?q=cache:G00C7bQVAt0J:biblioteca.usac.edu. gt/tesis/08/08_7691.pdf+metodologia+RUP&hl=es&ct=clnk&cd=6&gl=co &client=firefox-a http://www.scribd.com/doc/297224/RUP http://www.slideshare.net/msch/utilizando-metodologia-rup-parte1 http://www.iteraprocess.com/index.php?option=com_content&task=vie w&id=18&Itemid=42&limit=1&limitstart=1 http://www.conexionit.com/blog/metodologias/que-es-rup.html http://www.slideshare.net/willy0303/ads-sesion1-rup http://rolandojaldin.blogspot.com/2010/11/fase-de-transicion-etapade.html

Alumno: Franklin Cappa Ticona

13