P. 1
RUP: FASE DE TRANSICION

RUP: FASE DE TRANSICION

|Views: 3.646|Likes:
Ingenieria de software y RUP, dentro de las fases, la final es la transicion, y he aqui un poco de contenido sobre ello.

Con una refrencia a la utilidad y necesidad de todas las demas fases del RUP
Ingenieria de software y RUP, dentro de las fases, la final es la transicion, y he aqui un poco de contenido sobre ello.

Con una refrencia a la utilidad y necesidad de todas las demas fases del RUP

More info:

Published by: Franklin Silvestre Cappa Ticona on Aug 18, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/21/2013

pdf

text

original

UNIVERSIDAD PRIVADA JOSE CARLOS MARIATEGUI

RUP: FASE TRANSICIÓN

2011
ANALISIS Y DISEÑO DE SISTEMAS II

La transición 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 DISEÑO 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 (quién hace qué, cuándo y cómo).

2) 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 (miniproyectos) e incremental (versiones).

3) Es también un producto: - Desarrollado y mantenido por Rational. - Actualizado constantemente para tener en cuenta las mejores prácticas 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 producción y mantenimiento de modelos del sistema más que en producir documentos.

6) RUP es una guía de cómo usar UML de la forma más efectiva.

Alumno: Franklin Cappa Ticona

1

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II

II.

DESARROLLO
RUP El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniería de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una metodología 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 específica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visión y el mismo proceso acerca de cómo 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 evaluación para determinar si se ha cumplido o no con los objetivos de la misma. Las fases son: Inicio (Inception), Elaboración, Construcción y Transición.

En la Ilustración 1 las iteraciones están representadas como franjas verticales delimitadas por líneas 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 iteración. El ciclo de vida iterativo ha comprobado ser uno de los más efectivos para llevar una buena administración de los proyectos de software.

Alumno: Franklin Cappa Ticona

2

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II CICLO DE VIDA DE UN SOFTWARE

En el ciclo de vida RUP veremos una implementación 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 número variable Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una base de inicio. Las 6 mejores prácticas de desarrollo que aplica RUP       Desarrollo de software en forma iterativa Gestión de requerimientos Uso de arquitecturas basadas en componentes Modelización visual del software Verificación de calidad del software Control de cambios

Alumno: Franklin Cappa Ticona

3

CURSO: ANALISIS Y DISEÑO 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, diseñarlo en su totalidad, construirlo y testearlo. El enfoque iterativo permite ir creciendo en el entendimiento del problema.a través de refinamientos sucesivos. Esto también permite introducir cambios tácticos en los requerimientos, características del sistema o en los tiempos. 2. Gestión 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 diseño, la implementación y el testeo de software; haciendo más 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 módulos no triviales, subsistemas que satisfacen una función definida. RUP proporciona un acercamiento sistemático definiendo una arquitectura usando componentes nuevos y existentes. Éstos están 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. Modelización visual del software El proceso le demuestra cómo 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 código usando “bloques de construcción gráficos.” Las abstracciones visuales le ayudan a comunicar diversos aspectos del software, ayudan a mantener la consistencia entre un diseño y su puesta en marcha; y favorecen la comunicación inequívoca. El UML es la base de esta modelización visual. 5. Verificación de calidad del software Una performance y una confiabilidad pobres son los factores comunes que inhiben dramáticamente la aceptabilidad de los usos del software hoy en día. Por lo tanto, la calidad se debe revisar con respecto a los requerimientos basados en la confiabilidad, funcionalidad, performance de la aplicación y del sistema. RUP le asiste en el planeamiento, el diseño, la puesta en marcha, la ejecución, y la evaluación 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

4

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II 6. Control de cambios La capacidad de manejar los cambios - asegurándose 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 cómo controlar, seguir y supervisar cambios para permitir el desarrollo iterativo acertado. También guía sobre cómo 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, código, documentos, etc.). Describiendo cómo automatizar la integración, 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 más breve y se centra en asegurar que vale la pena y es posible, desarrollar el proyecto. 2. Elaboración 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. 3. Construcción 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. 5

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II 4. Transición 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 ajuste menores propuestos por el usuario. En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización. Durante esta fase de transición 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 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

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 (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software

Alumno: Franklin Cappa Ticona

6

CURSO: ANALISIS Y DISEÑO 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 código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso). Especificación 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 sección son:
     

Modelado de negocio Requisitos Análisis y Diseño Implementación Pruebas Despliegue

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

Gestión del cambio y configuraciones Gestión del proyecto Entorno

La estructura dinámica 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(También llamado Incepción) Elaboración Desarrollo(También llamado Implementación, Construcción) Cierre (También llamado Transición)

Artefactos RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema estos artefactos son los siguientes: Inicio:

Documento Visión 7

Alumno: Franklin Cappa Ticona

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II

Especificación de Requerimientos

Elaboración:

Diagramas de caso de uso

Construcción:

Documento Arquitectura que trabaja con las siguientes vistas: Vista Lógica:
 

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

Vista de Implementación:
  

Diagrama de Secuencia Diagrama de estados Diagrama de Colaboración

Vista Conceptual:

Modelo de dominio

Vista física:  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 desempeña en un momento dado Responsabilidades:   Hacer una serie de actividades Ser el responsable de una serie de artefactos

-

Alumno: Franklin Cappa Ticona

8

CURSO: ANALISIS Y DISEÑO 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 días, involucra un solo trabajador y un número pequeño de artefactos.

 

Las actividades se consideran en la planificación y evaluación del progreso del proyecto.

Ejemplos: - Planificar una iteración - Administrador de proyecto - Encontrar actores y casos de uso - Analista - Revisar el diseño - Revisor de diseño - Ejecutar pruebas de performance - Ing. de pruebas de performance

Recurso

Rol

Actividad

Gráfico de asignación de actividades  Artefactos - Elementos de información 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 diseño.  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

9

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II   Código fuente. Código ejecutable.

Ya hablamos algo de la fase de Transición, 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 Implementación, previo a la puesta en productivo del sistema. a continuación damos un vistazo a estas actividades:

Preparación 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 información 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 información validada, se ingresa al sistema manualmente o si la información tiene un volumen considerable a través 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 también para transferir los datos de un sistema antiguo al nuevo sistema. Para clarificar con un ejemplo, supongamos que estamos desarrollando un Sistema de gestión de Almacenes, que actualmente maneja sus procesos manualmente, para la carga inicial de datos se deberán 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 técnicos de los materiales, lista de centros solicitantes, lista de proveedores, etc.

Preparación del plan de capacitación de usuarios. Ya dijimos varias veces que RUP es para sistemas grandes, por lo tanto será natural que hayan varios módulos o subsistemas y obviamente muchos usuarios de diferentes áreas de la empresa. Por lo tanto, nuestra responsabilidad es la preparación del plan de formación o capacitación de los usuarios, ya sea por módulos o por procesos relacionados.

Alumno: Franklin Cappa Ticona

10

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II

Elaboración de los manuales de usuario. Para la formación de usuarios es importante ya disponer de los manuales de usuario y también para que este material sirva de soporte durante la puesta en productivo del sistema.

Configuración y parametrización de las cuentas de usuario. Será importante la definición de los perfiles de usuario, cuentas de usuario, políticas de seguridad, control y auditoría de usuarios, etc.

Migración 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 informático. Cualquier cambio implica tensión y resistencia, que deberemos manejar con mucha habilidad.

Alumno: Franklin Cappa Ticona

11

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II

III.

CONCLUSIONES
 Consideramos que el Proceso Unificado es una metodología completa y bien documentada. Lo utilizamos como una interesante fuente de ideas y herramientas y con una amplia disponibilidad de formación técnica y práctica.  Siendo que estamos bien entrenados en esta tecnología es que nos sentimos con la confianza de utilizarla, aumentando así significativamente nuestra probabilidad de éxito al adaptar este proceso al presente proyecto.  La metodología RUP es más apropiada para proyectos grandes (Aunque también pequeños), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.

Alumno: Franklin Cappa Ticona

12

CURSO: ANALISIS Y DISEÑO DE SISTEMAS II

IV.

BIBLIOGRAFIA
 Universidad de Chile - Departamento de Ciencias de la Computación  Presentación 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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->