SubirPara Despues

RUP: FASE DE TRANSICION

Cargado por Franklin Silvestre Cappa Ticona el Aug 18, 2011
Intereses relacionados
Software Development ProcessSoftwareSoftware EngineeringSystems
EngineeringTechnology
Calificaci�n y estad�sticas
1Votos positivos
0Votos negativos
5,8K vistas
2/5 puntos
Acciones de documentos
Descarga
Agregar a Guardados
Otras Acciones
COMPARTIR O INCRUSTAR DOCUMENTOS
Opciones para compartir
Compartir en Facebook abre una nueva ventanaCompartir en Twitter abre una nueva
ventanaCompartir en LinkedinCompartir por correo electr�nico abre un cliente de
correo electr�nico
Insertar
Descripci�n: 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
Ver m�s
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
Copyright: Attribution Non-Commercial (BY-NC)
Download as PDF, TXT or read online from Scribd
Flag for inappropriate content
Documentos recomendados
Documents Similar To RUP: FASE DE TRANSICION
RUP-analisis-dise�o
RUP-analisis-dise�o
por Alexander Romero
ENTREGABLES RUP MODELOS Y DIAGRAMAS
ENTREGABLES RUP MODELOS Y DIAGRAMAS
por Mafe Garzon
RUP - UML
RUP - UML
por Eddy Faustor
Documents About Technology
NORMAS DE PUBLICACION DE LA APA
NORMAS DE PUBLICACION DE LA APA
por Samira
Aspectos �ticos y Sociales en el Uso de las TIC
Aspectos �ticos y Sociales en el Uso de las TIC
por Humberto Rivera
Wallwisher
Wallwisher
por Ra�l Diego
More From Franklin Silvestre Cappa Ticona
Guia Visual Studio 2005 - Primera Parte
Guia Visual Studio 2005 - Primera Parte
por Franklin Silvestre Cappa Ticona
Practica 1 Base de datos
Practica 1 Base de datos
por Franklin Silvestre Cappa Ticona
Inform�tica y Turismo
Inform�tica y Turismo
por Franklin Silvestre Cappa Ticona

Buscar documento

7
Est� en la p�gina 7de 14

CURSO: ANALISIS Y DISE�O DE SISTEMAS II4Alumno: Franklin Cappa Ticona

1. Desarrollo de software en forma iterativa
Dada la complejidad de los sistemas de software modernos no es posible definir el
problemaentero en forma secuencial, dise�arlo en su totalidad, construirlo y
testearlo. El enfoque iterativopermite ir creciendo en el entendimiento del
problema.a trav�s de refinamientos sucesivos. Estotambi�n permite introducir
cambios t�cticos en los requerimientos, caracter�sticas del sistema oen los
tiempos.
2. Gesti�n de requerimientos
Las nociones de casos de uso y escenarios resultaron ser una forma excelente de
capturarrequerimientos funcionales y de asegurar que estos rijan el dise�o, la
implementaci�n y el testeode software; haciendo m�s probable que el sistema final
cumpla exactamente con lo que pidi� elcliente.
3. Uso de arquitecturas basadas en componentes
RUP apoya el desarrollo de software basado en componentes. Los componentes son
m�dulos notriviales, subsistemas que satisfacen una funci�n definida. RUP
proporciona un acercamientosistem�tico definiendo una arquitectura usando
componentes nuevos y existentes. �stos est�nmontados en una arquitectura bien
definida, o bien ad hoc, o en una infraestructura decomponentes 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 elcomportamiento 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 undise�o y su puesta en marcha; y favorecen la comunicaci�n
inequ�voca. El UML es la base de estamodelizaci�n visual.
5. Verificaci�n de calidad del software
Una performance y una confiabilidad pobres son los factores comunes que
inhibendram�ticamente la aceptabilidad de los usos del software hoy en d�a. Por lo
tanto, la calidad sedebe 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 puestaen 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 losparticipantes,
usando medidas y criterios objetivos, y no se trata de una actividad
separadarealizada por otro grupo.

CURSO: ANALISIS Y DISE�O DE SISTEMAS II5Alumno: Franklin Cappa Ticona

6. Control de cambios
La capacidad de manejar los cambios - asegur�ndose que cada cambio sea aceptable,
y pudiendocontinuar con los mismos- es esencial en un ambiente en el cual el cambio
es inevitable. El procesodescribe c�mo controlar, seguir y supervisar cambios para
permitir el desarrollo iterativoacertado. Tambi�n gu�a sobre c�mo establecer los
espacios de trabajo seguros para cadadesarrollador proporcionando el aislamiento de
los cambios realizados en otros espacios detrabajo 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 trabajecomo una sola unidad
Fases de Ciclo de Vida a Modo de Referencia antes de tocar el tema Principal1.
Inicio (Inception).
El objetivo general de esta fase es establecer un acuerdoentre todos los
interesados acerca de los objetivos delproyecto. Esta fase es significativamente
primaria para eldesarrollo de nuevo software, ya que se asegura deidentificar los
riesgos relacionados con el negocio yrequerimientos. Para proyectos de mejora de
softwareexistente esta fase es m�s breve y se centra en asegurarque vale la pena y
es posible, desarrollar el proyecto.
2. Elaboraci�n
El objetivo en esta fase es establecer la arquitectura basedel sistema para proveer
bases estables para el esfuerzode dise�o e implementaci�n en la siguiente fase.
Laarquitectura debe abarcar todos las consideraciones demayor importancia de los
requerimientos y unaevaluaci�n del riesgo.
3. Construcci�n
El objetivo de la fase de construcci�n es clarificar losrequerimientos faltantes y
completar el desarrollo delsistema basados en la arquitectura base. Vista de
ciertaforma esta fase es un proceso de manufactura, en el cualel �nfasis se torna
hacia la administraci�n de recursos ycontrol de las operaciones para optimizar
costos, tiempo ycalidad.

CURSO: ANALISIS Y DISE�O DE SISTEMAS II6Alumno: Franklin Cappa Ticona

4. Transici�n
Esta fase se enfoca en asegurar que el software este disponiblepara sus usuarios.
Esta fase se puede subdividir en variasiteraciones, adem�s incluye pruebas del
producto para poderhacer el entregable del mismo, as� como realizar ajuste
menoresde acuerdo a ajuste menores propuestos por el usuario. En estepunto, la
retroalimentaci�n de los usuarios se centra en depurarel producto, configuraciones,
instalaci�n y aspectos sobreutilizaci�n.Durante esta fase de transici�n busca
garantizar que se tiene un producto preparado para suentrega 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

yc�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

CURSO: ANALISIS Y DISE�O DE SISTEMAS II7Alumno: Franklin Cappa TiconaEl RUP es un

producto de Rational (IBM). Se caracteriza por ser iterativo e incremental,
estarcentrado en la arquitectura y guiado por los casos de uso. Incluye artefactos
(que son losproductos tangibles del proceso como por ejemplo, el modelo de casos de
uso, el c�digofuente, etc.) y roles (papel que desempe�a una persona en un
determinado momento, unapersona 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 usoRUP 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

?

EntornoLa estructura din�mica de RUP es la que permite que este sea un proceso de
desarrollofundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases
descritasanteriormente:
?

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 deartefactos que sirven para comprender mejor tanto el an�lisis como el
dise�o del sistemaestos artefactos son los siguientes:
Inicio
:
?

Documento Visi�n

CURSO: ANALISIS Y DISE�O DE SISTEMAS II8Alumno: Franklin Cappa Ticona

?

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�nVista Conceptual:

?

Modelo de dominioVista 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