Guía Metodológica Rup
Guía Metodológica Rup
Guía Metodológica Rup
RUP/Easy
GUÍA METODOLÓGICA DE DESARROLLO DE
SISTEMAS
Setiembre 2004
TABLA DE CONTENIDO
1 INTRODUCCIÓN ................................................................................................................................................1
2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP .......................................................2
2.1 WORKFLOWS ESENCIALES DEL RUP .............................................................................................2
2.2 VISTA GENERAL DEL WORKFLOW DEL RUP...............................................................................2
2.3 PROCEDIMIENTOS DE REVISIÓN.......................................................................................................3
3 LA VERSIÓN RUP/E DE LOS WORKFLOWS ESENCIALES DEL RUP.............................................4
3.1 MODELAMIENTO DE NEGOCIOS .......................................................................................................5
3.2 REQUERIMIENTOS ...................................................................................................................................5
3.3 ANÁLISIS Y DISEÑO ................................................................................................................................8
3.4 IMPLEM ENTACIÓN ................................................................................................................................10
3.5 PRUEBAS ....................................................................................................................................................11
3.6 DESPLIEGUE .............................................................................................................................................13
3.7 ADMINISTRACIÓN DE CONFIGURACIÓN Y CAMBIOS ...........................................................15
4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE .....................................................................17
1 INTRODUCCIÓN
Durante los últimos años, una de las metodologías más populares ha sido el Rational
Unified Process (RUP). RUP, desarrollado por Rational Software Corporation, es un
proceso de ingeniería de software que ofrece un enfoque disciplinado para asignar tareas
y responsabilidades dentro de la organización del desarrollo. RUP captura algunas de
las mejores prácticas de la industria para el desarrollo de software las cuales son para
desarrollar el software en iteraciones, administrar requerimientos, usar arquitecturas
basadas en componentes, verificar la calidad del software, controlar los cambios al
software y modelar el software visualmente usando el Unified Modeling Language
(UML). "El Unified Modeling Language (UML) es un método orientado a objetos y el
lenguaje estándar de la industria para especificar, visualizar, construir y documentar
los artefactos de sistemas de software.".
-2-
Este documento presenta los pasos para aplicar correctamente la metodología RUP en el
proceso de desarrollo de software. RUP es muy amplio y la mayoría de proyectos no
necesitan seguir todo lo que está en el RUP. Esta guía presenta la variación hecha en el
RUP denominada RUP/E para su aplicación en las empresas del Perú.
Esta sección explica cómo leer la adecuación de los Workflows esenciales del RUP
detallados en la sección 3 de este documento.
Esta guía metodológica cubre la adecuación para siete (7) de los nueve (9) workflows :
Modelamiento de Negocios, Requerimientos, Análisis y Diseño, Implementación,
Pruebas, Administración de Configuración y Cambios y Despliegue.
Esta guía metodológica excluye los workflows esenciales del RUP para Administración
de Proyectos y Entorno. Estos workflows, los cuales variarán de acuerdo a las políticas,
procedimientos y operaciones de cada empresa cliente interesada, serán revisados
separadamente.
La Sección 3 da una vista general a cada Workflow esencial del RUP y explica por qué
es importante incluir ése particular Workflow esencial del RUP en su ciclo de vida de
desarrollo de software.. Se presenta cada Workflow de Detalle dentro del Workflow
esencial del RUP y es explicado al igual que los artefactos clave producidos por cada
Workflow de detalle.
Estas subsecciones detallan los cambios aplicados a la estructura de workflows del RUP
en la variación de la metodología de RUP/E.
2.2.2 Artefactos
Revisar Herramientas
Artefactos Created/Revised
Detalles Usadas
Creado / Revisado Califica cómo es usado el Una 'X' en una o más de las celdas
artefacto a través del ciclo de Fase, significa que planeamos
vida congelar ese artefacto en esa fase
particular: Incepción, Elaboración,
Construcción y Transición.
Revisar Detalles Define el nivel de revisión; Decidir el nivel de revisión:
procedimientos de revisión que • Formal-Externo
van a ser aplicados al artefacto. • Formal-Interno
• Informal
• Ninguno
Para detalles vea la Sección 2.3,
Procedimientos de Revisión
Herramientas Usadas Definición de la herramienta (o Referencia a los detalles de las
herramientas) usadas para herramientas usadas para desarrollar
producir el artefacto. y mantener el artefacto.
2.2.3 Reportes
Esta subsección lista los reportes a ser usados por cada Workflow esencial del RUP. La
Tabla 3 muestra el formato que es usado para definir los reportes producidos por cada
Workflow esencial del RUP.
Formal-Externo Este artefacto es un entregable en Por ejemplo, la Visión y el Caso del Negocio
un hito específico. Requiere algún
son artefactos que deberían ser revisados por
tipo de aprobación del cliente, el stakeholders.
patrocinador o algún otro
stakeholder externo. Los resultados de la revisión son manejados en
la configuración junto con el artefacto.
Informal El artefacto es revisado; pero no es Las Clases de Diseño y los Componentes son
aprobado formalmente. ejemplos de artefacto que no son aprobados
formalmente. El artefacto es desarrollado y
mantenido. Normalmente no es descartado
luego que el proyecto termina.
• Modelamiento de Negocios – Una técnica de análisis para modelar los procesos del
negocio y entender mejor las complejidades de éste.
• Requerimientos – Una condición o capacidad que el sistema debe cumplir.
• Análisis y Diseño - Muestra cómo los casos del uso del sistema se realizarán en la
implementación.
• Implementación – Implementar y probar las clases.
-5-
El Modelamiento del Negocio debería hacerse antes del desarrollo de software para
obtener un buen entendimiento de sus procesos del negocio. Sin embargo, el
Modelamiento del Negocio sólo debe ser efectuado si se está cambiando la manera en
que se hace negocio. Si sólo se está añadiendo una nueva característica a un sistema
existente, entonces RUP/E no recomienda que usted empiece con un modelamiento del
negocio. En ese caso, RUP/E recomienda que usted empiece con la Sección 3.2,
Requerimientos.
3.2 REQUERIMIENTOS
Los artefactos clave a desarrollar son : Visión, Modelo de Casos de Uso, Casos de Uso
y Especificaciones Suplementarias. Estos artefactos describen lo que el sistema debe
hacer.
Analizar el Problema
Definir el Sistema
En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso más
completamente y expandir los requerimientos no funcionales definidos en los
documentos de especificaciones suplementarias.
El propósito del Workflow de Análisis y Diseño es empezar a realizar los casos de uso
desarrollados durante el Workflow de Requerimientos. Es decir, tomar el Modelo de
Casos de Uso, el Glosario y las Especificaciones Suplementarias creadas en el
Workflow de Requerimientos y generar un modelo de diseño que pueda ser usado por
los desarrolladores durante el Workflow de Implementación. El Análisis se enfoca en
trasladar los requerimientos funcionales a conceptos de software.
El Workflow de Análisis y Diseño toma los casos de uso documentados del Workflow
de Requerimientos y del Workflow de Modelamiento de Negocios y los traslada a
elementos de diseño que serán usados para construir el sistema. Por medio de usar
varias actividades y modelos el Workflow de Análisis y Diseño busca destilar la
información recogida de los stakeholders en información que los programadores podrán
usar. Al final, un Modelo de Diseño, el documento de Arquitectura del Software, el
Modelo de Despliegue y una Realización de Casos de Uso por cada Caso de Uso
describirán el sistema. El Workflow de Análisis y Diseño está relacionado a otros
workflow del RUP como sigue :
Refinar la Arquitectura
Analizar el Comportamiento
3.4 IMPLEMENTACIÓN
• Requerimientos: Este workflow del RUP captura los requerimientos que deberían
ser cumplidos durante la Implementación.
• Análisis y Diseño: El modelo de diseño desarrollado durante este workflow
representa el intento de la implementación y es el input principal para el Workflow
de Implementación.
• Pruebas: Este workflow describe cómo probar cada Construcción durante la
integración del sistema.
Planificar la Integración
Integrar el Sistema
Por este artefacto se entiende al Prototipo o Producto, según la fase en que se encuentre
el proyecto, resultante de cada iteración.
3.5 PRUEBAS
Rational ofrece su enfoque de pruebas usando el RUP para valorar la calidad del
software por medio de:
En el RUP, las pruebas son enfocadas a través del uso de un proceso iterativo y de
herramientas. Un enfoque iterativo para probar permite a la organización tratar las
pruebas casi de la misma forma que el desarrollo de software es enfocado. Cada
Construcción de software es un objetivo para las pruebas. Según se vayan produciendo
nuevas Construcciones, el cuerpo de pruebas será añadido y refinado. Eventualmente,
todas las pruebas en el cuerpo de pruebas serán acumuladas de tal manera que pueden
ser usadas para las posteriores pruebas de regresión en el ciclo de vida del desarrollo de
software. Este enfoque permite a una organización identificar posibles riesgos al inicio
de un proyecto, reducir el costo de corregir fallas enfocando los recursos cuando y
donde tendrán el mayor impacto, acercarse a los gaps de calidad tempranamente en el
proceso de desarrollo y maximizar la efectividad por medio de adaptar el enfoque, el
proceso o el presupuesto según va progresando el proyecto.
Este workflow del RUP está relacionado a otros workflows del RUP como sigue:
Los principales artefactos producidos son el Modelo de Pruebas (Test Model), los Casos
de Prueba (Test Case), los Procedimientos de Prueba (Test Procedures) y el documento
de Análisis de Carga de Trabajo (Workload Analysis Document).
- 13 -
Los artefactos presentados en la siguiente tabla son productos finales e intermedio que
son producidos y usados durante el Workflow de Pruebas de un proyecto. Loas
artefactos de Pruebas capturan y comunican información de pruebas y pueden tomar la
forma de un documento, un modelo o un elemento de modelo. La Tabla 12 identifica los
artefactos que deben ser desarrollados en el Workflow de Pruebas.
3.6 DESPLIEGUE
• La instalación en el cliente
• Se entrega un “instalador” (generado con algún producto de compresión e
instalación)
• Accesar al software por la Internet
Cualquiera que sea el método escogido para entregar al cliente, la prueba del producto
ocurre en el site de desarrollo seguido por la prueba Beta y finalmente liberando el
producto al cliente.
El Workflow de Despliegue está relacionado a otros workflows del RUP, como sigue:
Planificar el Despliegue
Empaquetar el Producto
Producto en Beta
RUP/E recomienda usar CRM (Change Requeriment Management) en todas las fases
- 16 -
del ciclo de vida después de la Incepción. Aunque CRM puede ser hecho manualmente,
sus mayores beneficios se obtienen cuando se usa una herramienta automatizado para
hacer uso de una base de datos. Existe un número de excelente herramientas de CRM.
ClearQuest de Rational es una buena opción si planea integrarse con otras herramientas
de Rational.
El Plan CM describe todas las actividades a efectuarse durante el curso del ciclo de vida
del proyecto. El Plan CM documenta cómo se planifica, implementa, controla y
organiza las actividades relativas al CM del producto.
La Sección 3 da una versión adecuada genérica del RUP usando la suite de herramientas
de Rational; sin embargo, esto puede no cubrir las necesidades de cada empresa. Las
empresas deberán hacer lo siguiente :