otra información de la rup

1.  Delia Santiago Ponte
2012

2.  La metodología RUP se basa en un conjunto de
habilidades por equipo y algunos modelos de
documentos clave. Las organizaciones que
desarrollan software por lo general adecuan este
marco de trabajo de acuerdo a sus necesidades para
producir software de calidad que cumpla con los
criterios del proyecto a los que está supeditado. La
metodología RUP unifica el equipo que incluye
elementos de las seis disciplinas de la ingeniería de
software.

3.  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. El RUP no es un sistema con
pasos firmemente establecidos, sino que trata de un
conjunto de metodologías adaptables al contexto y
necesidades de cada organización, donde el software es
organizado como una colección de unidades atómicas
llamados objetos, constituidos por datos y funciones,
que interactúan entre sí.
 RUP es un proceso para el desarrollo de un proyecto de
un software que define claramente quien, cómo,
cuándo y qué debe hacerse en el proyecto.

6.  Adaptación del proceso
 El proceso deberá adaptarse a las características propias de la organización. El tamaño del mismo, así
como las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener
en cuenta el alcance del proyecto.
 Balancear prioridades
 Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse
recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.
 Colaboración entre equipos
 El desarrollo de software no hace una única persona sino múltiples equipos. Debe haber una
comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.
 Demostrar valor iterativamente
 Los proyectos se entregan, aunque sea de modo interno, en etapas iteradas. En cada iteración se
analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del
proyecto así como también los riesgos involucrados.
 Elevar el nivel de abstracción
 Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software,
lenguajes 4GL o esquemas (Frameworks) por nombrar algunos. Estos se pueden acompañar por las
representaciones visuales de la arquitectura, por ejemplo con UML.
 Enfocarse en la calidad
 El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la
producción.

7.  Analistas:
 · Analista de procesos de negocio.
 · Diseñador del negocio.
 · Analista de sistema.
 · Especificador de requisitos.
 Desarrolladores:
 · Arquitecto de software.
 · Diseñador.
 · Diseñador de interfaz de usuario
 · Diseñador de cápsulas.
 · Diseñador de base de datos.
 · Implementador.
 · Integrador.
 Gestores:
 · Jefe de proyecto
 · Jefe de control de cambios.
 · Jefe de configuración.
 · Jefe de pruebas
 · Jefe de despliegue
 · Ingeniero de procesos
 · Revisor de gestión del proyecto
 · Gestor de pruebas.
 Apoyo:
 · Documentador técnico
 · Administrador de sistema
 · Especialista en herramientas
 · Desarrollador de cursos
 · Artista gráfico
 Especialista en pruebas:
 · Especialista en Pruebas
 · Analista de pruebas
 · Diseñador de pruebas

8.  · Stakeholders
 · Revisor
 · Coordinación de revisiones
 · Revisor técnico
 Gestión del proyecto
 Se vigila el cumplimiento de los objetivos, gestión de riesgos y restricciones para desarrollar un
producto que sea acorde a los requisitos de los clientes y los usuarios.
 · Proveer un marco de trabajo para la gestión de proyectos de software intensivos.
 · Proveer guías prácticas realizar planeación, contratar personal, ejecutar y monitorear el proyecto.
 · Proveer un marco de trabajo para gestionar riesgos.
 Configuración y control de cambios
 El control de cambios permite mantener la integridad de todos los módulos que se crean en el proceso,
así como de mantener información del proceso evolutivo que han seguido.
 Entorno
 La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas, procesos y
métodos. Brinda una especificación de las herramientas que se van a necesitar en cada momento, así
como definir la instancia concreta del proceso que se va a seguir.
 En concreto las responsabilidades de este flujo de trabajo incluyen:
 · Selección y adquisición de herramientas.
 · Establecer y configurar las herramientas para que se ajusten a la organización.
 · Configuración del proceso.
 · Mejora del proceso.
 · Servicios técnicos.

9.  Primer nivel de documentación
 Especifica en términos generales qué actividades deberán integrar el Sistema de Aseguramiento de Calidad, que
será implantado en la organización. Este nivel contiene los siguientes elementos:
 • Declaración de Visión: Proyecciones de la administración sobre el lugar que ocupará la organización en el futuro.
 • Declaración de Misión: Compromiso de la administración para alcanzar la Visión.
 • Política de Calidad: Posición de la organización, en cuanto a la manera en que la calidad afectará la manera de
cumplir con la Misión.
 • Requerimientos de Calidad: Conjunto de actividades que la organización debe llevar a cabo, para asegurar la
calidad tanto del proceso como el producto que desarrolla
 La Visión, Misión y Políticas de Calidad fueron desarrolladas a partir de los lineamientos estratégicos del
Departamento de Sistemas de Información.
 El Requerimiento de Calidad se identifica en modelos de calidad como ISO 9000.
 Segundo nivel de documentación
 Este nivel incluye especificaciones detalladas, orientadas a la administración, para explicar cómo se llevarán a cabo
las actividades que integran el Sistema de Aseguramiento de Calidad. Este nivel está compuesto básicamente por
procedimientos Administrativos, que son declaraciones de direcciones sistemáticas, sobre cómo la organización
debe llevar a cabo cada uno de los Requerimientos de Calidad, definidos en el Primer Nivel de Documentación.
 Tercer nivel de documentación
 Este nivel incluye especificaciones punto a punto, explícito y conciso para llevar a cabo cualquier tarea en la
organización. Está compuesto básicamente por Procedimientos de Operativos que describen cada paso que se debe
realizar para concretar una tarea o actividad; y Estándares que se utilizan con el fin de registrar datos o
información de algo específico. Estos procedimientos y estándares han sido divididos en tres grupos:
 1. Los relacionados con el desarrollo del curso Proyecto de Título.
 2. Los relacionados con el desarrollo de producto de software.
 3. Los que guían la implantación y mejoramiento del Sistema de Aseguramiento de Calidad.
 Esta división facilita el uso y mantención del sistema. Por ejemplo, si hay cambios en las normas administrativas
que afecten el desarrollo de los cursos en general, entonces sólo se verán afectados los procedimientos y estándares
relacionados con el desarrollo del proyecto.


10. Ciclo de iteraciones de la metodología RUP
(Proceso Unificado Racional)
 · Ingeniería de Negocios: Entendiendo las necesidades del negocio.
 · Requerimientos: Trasladando las necesidades del negocio a un sistema
automatizado.
 · Análisis y Diseño: Trasladando los requerimientos dentro de la
arquitectura de software.
 · Implementación: Creando software que se ajuste a la arquitectura y que
tenga el comportamiento deseado.
 · Pruebas: comportamiento requerido es el correcto y que todo lo
solicitado está presente.
 Disciplina de Soporte
 · Configuración y administración del cambio: Guardando todas las
versiones del proyecto.
 · Administrando el proyecto: Horarios y recursos.
 · Ambiente: Ambiente de desarrollo.

11.  · Actividades: Procesos que es llegan a
determinar en cada interacción
 · Trabajadores. Personas o entes involucrados
 · Artefactos. Un documento, un modelo o un
elemento de modelo.

12.  Los roles se distribuyen entre los miembros del proyecto y
que definen las tareas de cada uno y el resultado (artefactos)
que se espera de ellos.
 Dimensiones del RUP
 1· El eje horizontal representa tiempo y demuestra los
aspectos del ciclo de vida del proceso, expresado en términos
fases elaboración, construcción y transición.
 2· El eje vertical representa las disciplinas, flujos de trabajo,
actividades, artefactos y roles que agrupan actividades
definidas lógicamente por la naturaleza. Representa los
aspectos estáticos del proceso. Describe el proceso en
términos de componentes de proceso.

13.  Proceso Dirigido por los CU: Un CU, es una secuencia de
pasos a seguir para la realización de un fin o propósito, y se
relaciona directamente con los requerimientos. La
utilización de estos sirven para la utilización y desarrollo
de las disciplinas con los artefactos, roles y actividades
necesarias.
 Proceso Iterativo e Incremental: Es el modelo utilizado por
RUP para el desarrollo de un proyecto de software. Este
modelo plantea la implementación del proyecto a realizar
en Iteraciones, con lo cual se pueden definir objetivos por
cumplir en cada iteración y así poder ir completando todo
el proyecto iteración por iteración, con lo cual se tienen
varias ventajas, entre ellas se puede mencionar la de tener
pequeños avances del proyectos que son entregables al
cliente el cual puede probar mientras se está desarrollando
otra iteración del proyecto, con lo cual el proyecto va
creciendo hasta completarlo en su totalidad.

14.  A.S: Es la organización o estructura de sus partes más relevantes. Una 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.
 Alcance de la metodología RUP
 La metodología RUP es apropiada para proyectos grandes y pequeños, dado que
requiere un equipo de trabajo capaz de administrar un proceso complejo en varias
etapas. En pequeños, es posible que no se puedan cubrir los costos de dedicación
del equipo de profesionales necesarios.
 Antecedentes del RUP
 Los orígenes 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
investigación. En 1995 Rational Software compró una compañía sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos
de uso a los métodos de desarrollo orientados a objetos. El Rational Unified
Process fue el resultado de una convergencia de Rational Approach y Objectory. El
primer resultado de esta fusión fue el Rational Objectory Process, la primera
versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe
Philippe Kruchten. Desde allí hasta la actualidad es la metodología más empleada
en el mundo.

15.  Mismo modo, necesita terminar el esqueleto
RUP y sus bibliotecas para adaptarlos a la
organización.
 Necesidades únicas del negocio, así como el
contexto (complejidad técnica y de gestión),
medida de procesos. RUP proporciona un
Fundación arquitectónica y gran cantidad de la
organización adoptando configurar y ampliar
esa fundación como desee

16.  Flujos de trabajo de fase RUP
 Actividades de todas las diversas disciplinas se
pueden realizar para alcanzar los objetivos del
hito fase respectivos.
 Fases RUP frente a las fases de la cascada
 Organizaciones a adoptar el RUP. El hecho es
que las fases en el RUP no equivalen a las
disciplinas.

17.  Basado en el Estándar J2EE de la universidad
San Carlos de GuatemalaJavier Dolado Cosín
Caracas, Venezuela N°10 año 2007 cualitativa y
pedagógicamente definidos. De la colección
VITOR Escruto por Erla Mariela MORALES
MORGADO

18.  Metodología RUP es la mejor al momento de
obtener calidad en un software. más pequeño que
este sea. Recursos en cada una de ellas. individuos
que intervienen en el desarrollo del software.los
requerimientos de la empresa y que cumpla con el
objetivo primordial que es obtener un software de
calidad.
 Individuos que intervienen en el desarrollo del
software los requerimientos de la empresa y que
cumpla con el objetivo primordial que es obtener
un software de calidad.
