martes, 8 de noviembre de 2016
INTRODUCCION
El RUP
de desarrollo de software fue desarrollado por la IBM Corporation, de propiedad
de Rational Software en 2003.
La Figura 1 ilustra la historia de
RUP. El antecedente más importante se ubica en 1967 con la Metodología Ericsson
(Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo
basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años
de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de
desarrollo Objectory (abreviación de Object Factory).
Modelo de
Desarrollo de Software 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 y de mayor calidad para satisfacer
las necesidades de los usuarios que
tienen un cumplimiento al final dentro de un limite de tiempo y presupuesto previsible. Es una
metodología de desarrollo iterativo que es enfocada hacia “diagramas de los casos
de uso, y manejo de los riesgos y el manejo de la arquitectura” como tal.
El RUP
mejora la productividad del equipo ya que permite que cada miembro del grupo
sin importar su responsabilidad específica pueda acceder a la misma base de
datos incluyendo sus conocimientos.
¿PARA QUIÉN ES RUP?
Diseñado para:
ü Profesionales en el
desarrollo de software.
ü Interesados en productos
de software.
ü Profesionales en la
ingeniería y administración de procesos de software.
¿POR QUÉ USAR RUP?
ü Provee un entorno de
proceso de desarrollo configurable, basado en estándares.
ü Permite tener claro y
accesible el proceso de desarrollo que se sigue.
ü Permite ser configurado
a las necesidades de la organización y del proyecto.
ü Provee a cada
participante con la parte del proceso que le compete directamente, filtrando el
resto.
CARACTERÍSTICAS
ESENCIALES
Los
autores de RUP destacan que el proceso de
software propuesto por RUP tiene
tres características esenciales: está dirigido por los Casos de Uso, está
centrado en la arquitectura, y es iterativo e incremental.
1. Proceso dirigido por Casos de Uso
Los Casos
de Uso son una técnica de captura de requisitos que fuerza a pensar en términos
de importancia para el usuario y no sólo en términos de funciones que sería
bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad
del sistema que proporciona al usuario un valor añadido. Los Casos de Uso
representan los requisitos funcionales del sistema.
En RUP
los Casos de Uso no son sólo una herramienta para especificar los requisitos
del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso
constituyen un elemento integrador y una guía del trabajo.
Los Casos de Uso integran el trabajo
Los
Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un
hilo conductor, permitiendo establecer trazabilidad entre los artefactos que
son generados en las diferentes actividades del proceso de desarrollo.
2. Proceso centrado en la arquitectura
La
arquitectura de un sistema es la organización o estructura de sus partes más
relevantes, lo que permite tener una visión común entre todos los involucrados
(desarrolladores y usuarios) y una perspectiva clara del sistema completo,
necesaria para controlar el desarrollo.
La
arquitectura involucra los aspectos estáticos y dinámicos más significativos
del sistema, está relacionada con la toma de decisiones que indican cómo tiene
que ser construido el sistema y ayuda a
determinar en qué orden. La arquitectura se ve influenciada por la plataforma
software, sistema operativo, gestor de bases de datos, protocolos,
consideraciones de desarrollo como sistemas heredados. Muchas de estas
restricciones constituyen requisitos no funcionales del sistema.
En el
caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta
especial atención al establecimiento temprano de una buena arquitectura que no
se vea fuertemente impactada ante cambios posteriores durante la construcción y
el mantenimiento.
3. Proceso iterativo e incremental
La
estrategia que se propone en RUP es tener un proceso iterativo e incremental en
donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo
que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante
cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini
proyecto se puede ver como una iteración (un recorrido más o menos completo a
lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un
incremento que produce un crecimiento en el producto.
Una
iteración puede realizarse por medio de
una cascada de etapas, se pasa por los flujos fundamentales (Requisitos,
Análisis, Diseño, Implementación y Pruebas), también existe una planificación
de la iteración, un análisis de la iteración
y algunas actividades específicas de la iteración. Al finalizar se
realiza una integración de los resultados con lo obtenido de las iteraciones
anteriores.
Una iteración
El
proceso iterativo e incremental consta de una secuencia de iteraciones. Cada
iteración aborda una parte de la funcionalidad total, pasando por todos los
flujos de trabajo relevantes y refinando la arquitectura.
CICLO DE DESARROLLO
El
RUP divide un ciclo de desarrollo en
cuatro fases consecutivas:
Fase Inicial
Durante
la fase inicial, se establece el modelo de negocio para el sistema y delimitar
el alcance del proyecto. Para ello se debe identificar todas las entidades
externas con las que el sistema va a interactuar (actores) y definir la
naturaleza de esta interacción en un alto nivel. Esto implica identificar todos
los casos de uso y que describe una los pocos significativos. El caso de
negocio incluye criterios de éxito, evaluación de riesgos y estimación de los
recursos necesarios y un plan de eliminación con las fechas de los hitos más
importantes.
Elaboración de Fase
El
propósito de la fase de elaboración es analizar el dominio del problema,
establecer una base arquitectónica de sonido, desarrollar el plan del proyecto,
y eliminar los elementos de mayor riesgo del proyecto. Para lograr estos
objetivos, que debe tener la "milla de ancho y una pulgada de
profundidad" vista del sistema. Las decisiones de arquitectura que se hace
con una la comprensión de todo el sistema: su alcance, la funcionalidad y los
principales requisitos no funcionales, tales como requisitos de desempeño.
Fase de Construcción
Durante
la fase de construcción, todos los demás componentes y características de las
aplicaciones se desarrollan y se integran en el producto, y todas las
características están ampliamente probadas. La fase de construcción es, en
cierto sentido, un proceso de fabricación donde se hace hincapié en la gestión
de recursos y control de las operaciones para optimizar costos, horarios y de
calidad. En este sentido, la mentalidad de gestión experimenta una transición
desde el desarrollo de la propiedad intelectual durante el inicio y
elaboración, para el desarrollo de productos de despliegue durante la
construcción y en transición.
La Transición de Fase
El
propósito de la fase de transición es la transición del producto de software
para la comunidad de usuarios. Una vez que el producto ha dado al usuario
final, suelen surgir problemas que requieren para desarrollar las nuevas
versiones, corregir algunos problemas, o acabado de las características que
fueron aplazadas.
DISCIPLINAS DEL
MODELO RUP
Primero
que nada ¿Qué es una disciplina?, claro está que en este ámbito. Una disciplina
es una colección de actividades relacionadas con un área de atención dentro de
todo el proyecto. El grupo de actividades que se encuentran dentro de una
disciplina principalmente son una ayuda para entender el proyecto desde la
perspectiva clásica de cascada. Están inspiradas en las etapas de un proceso de
desarrollo en cascada. Es una secuencia parcialmente ordenada de actividades
que son realizadas para lograr un resultado particular, representado en un
conjunto de artefactos, y las Disciplinas son:
ü Modelado de Negocios
ü Requerimientos
ü Análisis y Diseño
ü Implementación
ü Pruebas
ü Transición
ü Configuración y
Administración del Cambio
ü Administración de
Proyectos
ü Ambiente
Modelado de Negocios
Los propósitos que tiene el Modelo
de Negocios son:
ü Entender los problemas
que la organización desea solucionar e identificar mejoras potenciales.
ü Medir el impacto del
cambio organizacional.
ü Asegurar que clientes,
usuarios finales, desarrolladores y los otros participantes tengan un
entendimiento compartido del problema.
ü Derivar los
requerimientos del sistema de software, necesarios para dar soporte a los
objetivos de la organización.
ü Entender como el sistema
a ser desarrollado entra dentro de la organización.
Requerimientos
Esta disciplina tiene el propósito
de:
ü Establecer y mantener un
acuerdo con los clientes y los otros interesados acerca de que debe hacer el
sistema.
ü Proveer a los
desarrolladores del sistema de un mejor entendimiento de los requerimientos del
sistema.
ü Definir los límites (o
delimitar) del sistema.
ü Proveer un base para la
planeación de los contenidos técnicos de las iteraciones.
ü Proveer una base para la
estimación de costo y tiempo necesarios para desarrollar el sistema.
ü Definir una interfaz de
usuario para el sistema, enfocada en las necesidades y objetivos del usuario.
Análisis y Diseño
El propósito del Análisis y Diseño
es:
ü Transformar los
requerimientos a diseños del sistema.
ü Desarrollar una arquitectura robusta para el sistema.
ü Adaptar el diseño para
hacerlo corresponder con el ambiente de implementación y ajustarla para un
desempeño esperado.
Implementación
El propósito de la implementación
es:
ü Definir la organización
del código, en términos de la implementación de los subsistemas organizados en
capas.
ü Implementar el diseño de
elementos en términos de los elementos (archivos fuente, binarios, ejecutables
y otros)
ü Probar los componentes
desarrollados como unidades.
ü Integrar los resultados
individuales en un sistema ejecutable.
Pruebas
Actúa
como un proveedor de servicios a las otras disciplinas en muchos aspectos. Se
enfoca principalmente en la evaluación y aseguramiento de la calidad del
producto, desarrollado a través de las siguientes prácticas:
ü Encontrar fallas de
calidad en el software y documentarlas.
ü Recomendar sobre la
calidad percibida en el software.
ü Validar y probar las
suposiciones hechas durante el diseño y la especificación de requerimientos de
forma concreta.
ü Validar que el software
trabaja como fue diseñado.
ü Validar que los
requerimientos son implementados apropiadamente.
para desarrollar el sistema.
ü Definir una interfaz de
usuario para el sistema, enfocada en las necesidades y objetivos del usuario.
Transición
Esta
disciplina describe las actividades asociadas con el aseguramiento de la
entrega y disponibilidad del producto de software hacia el usuario final.
Administración y Configuración del Cambio
Consiste
en controlar los cambios y mantener la integridad de los productos que incluye
el proyecto. Incluye:
ü Identificar los
elementos configurables.
ü Restringir los cambios
en los elementos configurables.
ü Auditar los cambios
hechos a estos elementos.
ü Definir y mantener las
configuraciones de estos elementos.
como fue diseñado.
Los
métodos, procesos y herramientas usadas para proveer la administración y
configuración del cambio pueden ser consideradas como el sistema de
administración de la configuración.
Administración de Proyectos
El propósito de la Administración de
Proyectos es:
ü Proveer un marco de
trabajo para administrar los proyectos intensivos de software.
ü Proveer guías prácticas
para la planeación, soporte, ejecución y monitoreo de proyectos.
ü Proveer un marco de
trabajo para la administración del riesgo.
Ambiente
ü Se enfoca en las
actividades necesarias para configurar el proceso al proyecto.
ü Describe las actividades
requeridas para desarrollar las líneas guías de apoyo al proyecto.
ü El propósito de las
actividades de ambiente es proveer a las organizaciones de desarrollo de
software del ambiente necesario (herramientas y procesos) que den soporte al
equipo de desarrollo.
