Metodología Proceso Unificado

UNIVERSIDAD AUTONOMA DE CHIHUAHUA
FACULTAD DE CONTADURA Y ADMINISTRACIN

SECRETARA DE POSGRADO
MAESTRIA EN SISTEMAS DE INFORMACIN
METODOLOGAS DE ANLISIS Y
DISEO DE SISTEMAS DE
INFORMACIN
METODOLOGA PROCESO UNIFICADO

(RUP)
ASESOR: M.C. FRANCISCO JAVIER MARISCAL FLORES

ALUMNO: CARLOS URIEL ARAGN MANCERA
MATRICULA: 185096
17 DE JUNIO DEL 2016

CHIHUAHUA, CHIH.
INTRODUCCIN
En este tema se describe a groso modo el proceso unificado, indicando sus
caractersticas generales. Por otra parte, en el de este tema, y, en general, en el
contexto del proceso de desarrollo de un sistema informtico, se entiende por
proceso el conjunto de pasos ordenados que se realizan para alcanzar un
objetivo.
El Proceso Unificado (PU) puede verse como una metodologa adaptable. Esto
quiere decir que se puede modificar para adaptarlo al sistema concreto que se va
a desarrollar en cada momento. Por otra parte se puede decir que el PU es una
tcnica para elaborar modelos que se adapta especialmente a UML. Su objetivo
es producir un software de calidad. Por definicin, PU utiliza buenas prcticas de
desarrollo, siendo adaptable a un amplio rango de aplicaciones y sistemas. Este
proceso no slo considera aspectos de desarrollo de un sistema, sino tambin los
de gestin del mismo.
HISTORIA
Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la
investigacin. En 1995 Rational Software compr una compaa sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos
de uso a los mtodos de desarrollo orientados a objetos. El Rational Unified
Process fue el resultado de una convergencia de Rational Approach y Objectory
(el proceso de la empresa Objectory AB). El primer resultado de esta fusin fue el
Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado
en 1998, siendo el arquitecto en jefe Philippe Kruchten.
Qu es?
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de
modelado UML, constituye la metodologa estndar ms utilizada para el anlisis,
implementacin y documentacin de sistemas orientados a objetos.
Objetivos
Proporcionar
una
gua
de
orden
en
las
actividades
de
los
equipos.
Especificar cules artefactos deben ser desarrollados y cuando deben ser

desarrollados.
Dirigir las tareas de desarrolladores individuales y equipos como una sola.
Caractersticas
Desarrollo Iterativo.
Administracin de requisitos.
Uso de arquitectura basada en componentes.
Control de cambios.
Modelado visual de software.
Enfoque orientado a objetos.
Ciclo de Vida
El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida
organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o
menor hincapi en las distintas actividades.
FASES DEL CICLO DE VIDA

1. Fase de Inicio
En esta fase tenemos como propsito definir y acordar el alcance del proyecto con
los patrocinadores, se identifican los riesgos asociados al proyecto, se proponen
visiones muy generales de la arquitectura de software y se produce el plan de las
fases e iteraciones posteriores.
El objetivo de esta fase, y el establecer el modelo de negocio es entender las
funciones de la organizacin del cliente, tanto en estructura como en sus
procesos. Su objetivo es modelar funciones y roles que realiza la organizacin
para realizar ms fcilmente la reingeniera de procesos o la implantacin del
nuevo sistema.
2. Fase de Elaboracin
En esta fase se seleccionan los casos de uso que permiten definir la arquitectura
base del sistema y se desarrollaran en esta fase. En esta fase tambin se disea
la solucin preliminar.
Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan
los riesgos. Planificar las actividades necesarias y los recursos requeridos,
especificando las caractersticas y el diseo de la arquitectura.
En esta fase se especifican los requerimientos y se describen sobre cmo se van
a implementar en el sistema: transformar los requisitos al diseo del sistema,
desarrollar una arquitectura para el sistema, y adaptar el diseo para que sea
consistente con el entorno de implementacin.
En esta fase las iteraciones se orientan al desarrollo de la arquitectura, que incluye
los flujos de trabajo de requerimientos, modelo de negocios (refinamiento),
anlisis, diseo y una parte de implementacin orientado a la arquitectura.
3. Fase de Construccin
El propsito de esta fase es completar la funcionalidad del sistema, para ello se
deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo
a las evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.
El propsito de esta fase es completar la funcionalidad del sistema, para ello se
deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo
a las evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.
4. Fase de Transicin
Durante esta fase de transicin busca garantizar que se tiene un producto
preparado para su entrega al usuario.
El propsito de esta fase es asegurar que el software est disponible para los
usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se
debe verificar que el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto.
Se realiza la instalacin del producto en el cliente y se procede al entrenamiento
de los usuarios. Realizar la transicin del producto a los usuarios, lo cual incluye:
manufactura, envo, entrenamiento, soporte y mantenimiento del producto, hasta
que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios.
PRINCIPIOS CLAVE
1. Adaptacin del proceso
El proceso debe adaptarse a las caractersticas de la organizacin para la que se
est desarrollando el software.
2. Balancear prioridades
Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo,
evaluaciones, planes, resultados, entre otros.
3. Colaboracin entre equipos
Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo,
evaluaciones, planes, resultados, entre otros.
4. Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas.
En cada iteracin se evaluar la calidad y estabilidad del producto y analizar la
opinin y sugerencias de los inversores.
5. Elevar el nivel de abstraccin
Motivar el uso de conceptos reutilizables.
6. Enfocarse en la calidad
La calidad del producto debe verificarse en cada aspecto de la produccin.
Ventajas
Reduce riesgos del proyecto.

Integra desarrollo con mantenimiento.
Alto progreso en las primeras etapas.
Temprana retroalimentacin que se ajuste a las necesidades reales.
Desventajas
Genera demasiados costos.
No es recomendable para proyectos pequeos.

Maneja un alto grado de complejidad.
Requiere conocimientos de proceso y de UML.
Artefactos
La metodologa RUP en cada una de sus fases realiza una serie de artefactos que
sirven para comprender mejor tanto el anlisis como el diseo del sistema. Estos
artefactos (entre otros) son los siguientes:
Inicio:
Documento Visin
Diagramas de caso de uso
Especificacin de Requisitos
Diagrama de Requisitos
Elaboracin:
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.
Diseo y desarrollo de casos de uso, o flujos de casos de uso

arquitectnicos
Pruebas de los casos de uso desarrollados, que demuestran que la

arquitectura documentada responde adecuadamente a requerimientos
funcionales y no funcionales.
Construccin:
Especificacin de requisitos faltantes
Diseo y desarrollo de casos de uso y/o flujos de acuerdo con la planeacin

iterativa
Pruebas de los casos de uso desarrollados, y pruebas de regresin segn

sea el caso
Transicin:
Pruebas finales de aceptacin
Puesta en produccin
Estabilizacin
CONCLUSIN
La metodologa RUP como se pudo observar es la mejor al momento de obtener
software de calidad. Tambin la complejidad que lleva el desarrollar un software ya
sea grande o chico como su base fundamental que son las iteraciones y la
reutilizacin de recursos, los roles que tiene la metodologa cada uno tiene
impartido las prioridades que conlleva el desarrollar software por este medio, y
concluimos que al momento de elegir cualquier metodologa es la que mejor se
adapte a los requerimientos de las empresas y que cumpla con un software de
calidad.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin; es por
esto que permite la personalizacin de acuerdo con las necesidades.
REFERENCIAS
Stephen R. Schach. D. Mc Graw Hill. ISBN 970-10-4982-9.
2005.
Javier Tuya, Isabel Ramos Romn, JAvier Doblado Cosn.
(2007). TCNICAS CUANTITATIVAS PARA LA GESTIN DE LA
INGENIERA DEL SOFTWARE. Espaa: NETBIBLO, S.L.

Metodología Proceso Unificado

Cargado por

Copyright:

Formatos disponibles

Metodología Proceso Unificado

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodología Proceso Unificado

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD AUTONOMA DE CHIHUAHUA

FACULTAD DE CONTADURA Y ADMINISTRACIN

MAESTRIA EN SISTEMAS DE INFORMACIN

METODOLOGA PROCESO UNIFICADO

ASESOR: M.C. FRANCISCO JAVIER MARISCAL FLORES

17 DE JUNIO DEL 2016

Especificar cules artefactos deben ser desarrollados y cuando deben ser

FASES DEL CICLO DE VIDA

Reduce riesgos del proyecto.

Genera demasiados costos.

No es recomendable para proyectos pequeos.

Diagramas de caso de uso

Documento Arquitectura que trabaja con las siguientes vistas:

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

Mapa de comportamiento a nivel de hardware.

Diseo y desarrollo de casos de uso, o flujos de casos de uso

Pruebas de los casos de uso desarrollados, que demuestran que la

Especificacin de requisitos faltantes

Diseo y desarrollo de casos de uso y/o flujos de acuerdo con la planeacin

Pruebas de los casos de uso desarrollados, y pruebas de regresin segn

Pruebas finales de aceptacin

Stephen R. Schach. D. Mc Graw Hill. ISBN 970-10-4982-9.

También podría gustarte