Introducción
¿Qué es una
metodología?
Es un conjunto de
métodos, principios y reglas que
permiten enfrentar de manera sistemática el desarrollo de un programa que
resuelve un problema algorítmico. Estas metodologías generalmente se
estructuran como una secuencia de pasos que parten de la definición del
problema y culminan con un programa que lo resuelve.
Rational
Unified Process (RUP)
El RUP tiene dos dimensiones:
La primera dimensión (eje horizontal)
representa el aspecto dinámico del proceso y se expresa en términos de fases, iteraciones
y la finalización de las fases.
La segunda dimensión (eje vertical) representa
el aspecto estático del proceso: cómo se describe en términos de componentes de
proceso, disciplinas, actividades, flujos de trabajo, artefactos, y los roles.
Características principales
El
RUP contiene tres características principales:
Proceso dirigido por Casos de Uso
Según
Kruchten Philippe (2000), “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”.
Los
casos de uso no son sólo una herramienta para especificar los requisitos del sistema, sino que
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 Inician el proceso de
desarrollo y proporcionan un hilo conductor, permitiendo establecer
trazabilidad entre los artefactos que son generados en las diferentes
actividades del proceso de desarrollo.
Basándose en los casos de uso, se
crean los modelos de análisis y diseño, luego la implementación que los lleva a
cabo, y se verifica que efectivamente el producto implemente adecuadamente cada
caso de uso.
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.
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.
Existe una interacción entre los casos
de uso y la arquitectura, los casos de uso deben encajar en la arquitectura
cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos
los casos de uso requeridos, actualmente y en el futuro.
La arquitectura dentro de RUP se
representa en varias vistas. Todas las vistas juntas forman el llamado modelo
4+1 de la arquitectura. Según Kruchten Philippe
(1998) “el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de
proceso y de despliegue, más la de
casos de uso que es la que da cohesión a todas”.
Al final de la fase de elaboración se
obtiene una “baseline” (base de
referencia) de la arquitectura donde fueron seleccionados una serie de
casos de uso arquitectónicamente relevantes (aquellos que ayudan a mitigar los
riesgos más importantes, aquellos que son los más importantes para el usuario y
aquellos que cubran las funcionalidades significativas).
Proceso iterativo e
incremental
El equilibrio correcto entre los casos
de uso y la arquitectura es muy parecido al equilibrio de la forma y la función
en el desarrollo de un producto, lo cual se consigue con el tiempo. Para esto,
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. 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.
Cada iteración aborda una parte de la
funcionalidad total, pasando por todos los flujos de trabajo relevantes y
refinando la arquitectura. Cada iteración se analiza cuando se termina. Durante
la planificación de los detalles de la siguiente iteración, el equipo también
examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la
retroalimentación de la iteración pasada permite reajustar los objetivos para
las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya
finalizado por completo con la versión actual del producto.
RUP divide el proceso en cuatro fases,
dentro de las cuales se realizan varias iteraciones (que son una cantidad
variable) según el proyecto, y en las que se hace un mayor o menor hincapié en
los distintas actividades.
Las primeras iteraciones (en las fases
de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la
tecnología, la delimitación del ámbito del proyecto, la eliminación de los
riesgos críticos, y al establecimiento de una “baseline” (base de referencia) de la arquitectura.
Para cada iteración se escogen algunos
casos de uso, se refina su análisis y diseño, y se procede a su implementación
y pruebas. Se realizan tantas iteraciones hasta que se termine la
implementación de la nueva versión del producto.
En la fase de transición se pretende
garantizar que se tiene un producto preparado para su entrega a la comunidad de
usuarios. Como se puede observar, en cada fase participan todas las
disciplinas, pero, dependiendo de la fase, es el esfuerzo dedicado a una disciplina.
Fases
El ciclo de vida del software del RUP
se descompone en cuatro fases secuenciales. En cada extremo de una fase se
realiza una evaluación para determinar si los objetivos de la fase se han
cumplido. Una vez que la evaluación obtiene los resultados deseados, se procede
a la siguiente fase.
Planeando
las fases
El ciclo de vida consiste en una serie
de ciclos, cada uno de los cuales produce una nueva versión del producto, cada
ciclo está compuesto por fases y cada fase está compuesta por un número de
iteraciones.
1.- Concepción,
Inicio o Estudio de oportunidad
Define el ámbito y objetivos del
proyecto, además de la funcionalidad y capacidades del producto.
2.- Elaboración
Tanto la funcionalidad como el dominio
del problema se estudian a profundidad. Se define una arquitectura básica y se
planifica el proyecto considerando recursos disponibles.
3.- Construcción
El producto se desarrolla a través de
iteraciones donde cada iteración involucra tareas de análisis, diseño e
implementación Las fases de concepción y elaboración sólo dieron una
arquitectura básica que es refinada aquí de manera incremental conforme se
construye (se permiten cambios en la estructura). Gran parte del trabajo es
programación y pruebas, se documenta tanto el sistema construido como el manejo
del mismo En esta fase se hace una documentación junto con el producto.
4.- Transición
Se libera el producto y se entrega al
usuario para un uso real. Se incluyen tareas de mercadotecnia, empaquetado atractivo,
instalación, configuración, entrenamiento, soporte, mantenimiento, etc.
Los manuales de usuario se completan y
refinan con la información anterior.
Ninguna fase es idéntica en términos
de tiempo y esfuerzo. Aunque esto varía significativamente dependiendo del
proyecto, un ciclo de desarrollo inicial típico para un proyecto de tamaño
mediano debe anticipar la distribución siguiente del esfuerzo y horario:
Conforme un proyecto avanza y se
intenta mejorar, llega un momento en que el ciclo (las cuatro fases) debe
repetirse. Estos ciclos subsecuentes se llaman los ciclos de la evolución.
Mientras que el producto pasa durante varios ciclos, se producen las nuevas
generaciones.
Esfuerzo respecto de los flujos de
trabajo (o disciplinas)
En la imagen posterior del documento se muestra el
porcentaje el esfuerzo que se tiene que realizar por cada una de las
disciplinas o flujos de trabajo, y los dos porcentajes que se muestran de forma
horizontal son para todo el proyecto.
Se puede observar que para la obtención de requisitos en la
fase de concepción se empiezan a conseguir, en la fase de elaboración tiene su
auge, y va declinando en la fase de construcción. Con las demás sucede algo
similar en distintas iteraciones.
Esfuerzo respecto de las fases
Disciplinas
Las disciplinas son los flujos del
trabajo, los cuales son una secuencia de pasos para la culminación de cada
disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo.
Las primarias son las necesarias para la realización de un proyecto de software, aunque para proyectos no
muy grandes se pueden omitir algunas; entre ellas se tienen: modelado del negocio,
requerimientos, análisis y diseño, implementación, pruebas y despliegue. Las de
apoyo son las que complementan y brindan mejoras a las primarias y especifican
otras características en la realización de un proyecto de software; entre estas se tienen:
entorno, gestión del proyecto, gestión de configuración y cambios.
Modelado del
negocio
Tiene como objetivos comprender la
estructura y la dinámica de la organización, comprender problemas actuales e
identificar posibles mejoras, comprender los procesos del negocio.
Requerimientos
Sus objetivos son: establecer lo que
el sistema debe hacer, se definen los límites del sistema, y una interfaz de
usuario. También realiza una estimación del costo y tiempo de desarrollo.
Análisis y
diseño
Define la arquitectura del sistema y
tiene como objetivos trasladar requisitos en especificaciones de
implementación, al decir análisis se refiere a transformar CU (casos de uso) en
clases, y al decir diseño se refiere a refinar el análisis para poder
implementar los diagramas de clases de análisis de cada CU, los diagramas de
colaboración de cada CU, el de clases de diseño de cada CU, el de secuencia de
diseño de CU, el de estados de las clases, etc.
Implementación
Tiene como objetivos implementar las
clases de diseño como componentes, asignar los componentes a los nodos, probar
los componentes individualmente (pruebas unitarias) e integrar los componentes
en un sistema ejecutable.
Pruebas
Verificar la integración de los
componentes (prueba de integración), verificar que todos los requisitos han
sido implementados (pruebas del sistema), asegurar que los defectos detectados
han sido resueltos antes de la distribución.
Despliegue
Sus objetivos son asegurar que el
producto está preparado para el cliente, para proceder a su entrega y recepción
por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final
(Prueba Beta), empaquetarlo, distribuirlo e instalarlo, así como la tarea de
enseñar al usuario.
Gestión y
configuración de cambios
Éste es esencial para controlar el
número de artefactos producidos por la cantidad de personal que trabajan en un
proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya
que evitan confusiones costosas, como la compostura de algo que ya se había
arreglado.
Entorno
Esta disciplina se enfoca sobre las actividades necesarias
para configurar el proceso que engloba el desarrollo de un proyecto y describe
las actividades requeridas para el desarrollo de las pautas que apoyan un
proyecto.
Su propósito es proveer a la organización que desarrollará
el software, un ambiente en el cual basarse, el cual provee procesos y
herramientas para poder desarrollar el software.
Organización y elementos del RUP
Ya conociendo varias partes del RUP
nos concentraremos ahora en los elementos que lo componen, entre estos se
tienen: flujos de trabajo, detalle de los flujos de trabajo, actores,
actividades (o acciones) y artefactos.
Actores o
roles
Son los personajes encargados de la
realización de las actividades definidas dentro de los flujos de trabajo de
cada una de las disciplinas del RUP
Analistas
- Analista del Proceso del Negocio.
- Diseñador del Negocio.
- Revisor del Modelo del Negocio.
- Revisor de Requerimientos.
- Analista del Sistema.
- Especificador de Casos de Uso.
- Diseñador de Interfaz del Usuario.
Desarrolladores
- Arquitecto.
- Revisor de la Arquitectura.
- Diseñador de Cápsulas.
- Revisor del Código y Revisor del
Diseño.
- Diseñador de la Base de Datos.
- Diseñador.
- Implementador y un Integrador.
Probadores
Profesionales
- Diseñador de Pruebas.
- Probador.
Encargados
- Encargado de Control del Cambio.
- Encargado de la Configuración.
- Encargado del Despliegue.
- Ingeniero de Procesos.
- Encargado de Proyecto.
- Revisor de Proyecto.
Otros
- Cualquier trabajador.
- Artista Gráfico.
- Stakeholder.
- Administrador del Sistema.
- Escritor técnico.
- Especialista de Herramientas.
Artefactos
Los artefactos son el resultado
parcial o final que es producido y usado por los actores durante el proyecto.
Son las entradas y salidas de las actividades, realizadas por los actores, los
cuales utilizan y van produciendo estos artefactos para tener guías. Un
artefacto puede ser un documento, un modelo o un elemento de modelo.
Conjunto de
artefactos:
1.- Modelado
del negocio
Capturan y presentan el contexto del
negocio del sistema. Los artefactos del modelado del negocio sirven como
entrada y como referencia para los requisitos del sistema.
2.- Requerimientos
Capturan y presentan la información
usada en definir las capacidades requeridas del sistema.
3.- Análisis
y diseño del sistema
Capturan y presenta la información
relacionada con la solución a los problemas que se presentaron en los
requisitos fijados.
4.- Implementación
Capturan y presentan la realización de
la solución presentada en el análisis y diseño del sistema.
5.- Pruebas
Los artefactos desarrollados como
productos de las actividades de prueba y de la evaluación son agrupadas por el
actor responsable, con el cual se lleva un conjunto de documentos de
información sobre las pruebas realizadas y las metodologías de pruebas
aplicadas.
6.- Despliegue
Capturan y presentan la información relacionada
con la transitividad del sistema, presentada en la implementación en el
ambiente de la producción.
7.- Administración
del proyecto
Capturan los artefactos asociados con
el proyecto, el planeamiento y a la ejecución del proceso.
8.- Administración
de cambios y configuración
Capturan y presentan la información
relacionada con la disciplina de configuración y administración del cambio.
9.- Entorno
o ambiente
Presenta los artefactos que se utilizan
como dirección a través del desarrollo del sistema para asegurar la consistencia
de todos los artefactos producidos.
Grado de finalización de
artefactos
Con grado de finalización nos referimos a cuántos de esos lineamientos
del artefacto hemos completado o llenado, esto en cada una de las disciplinas,
de acorde a la fase en que se. En la fase de concepción, en la disciplina de
implementación del sistema los artefactos tienen una poca finalización y van
aumentando progresivamente en cada fase hasta llegar a su culminación en la
fase de transición.
Con esto se puede mostrar el aumento progresivo de los
artefactos en cada disciplina en la fase dada, teniendo una idea un poco más
amplia sobre el desenvolvimiento del proyecto hablando en términos de sus
artefactos.
Desventajas de la metodología:
No capturar un caso de uso a tiempo puede causar una
reconstrucción parcial de la arquitectura.
La falta de especificaciones en los requisitos por parte del
usuario puede causar ciertas discrepancias.
Se
requiere mucho personal (dependiendo del proyecto).
Ventajas
de la metodología:
Es el proceso de desarrollo más
general de los existentes actualmente.
Es una forma disciplinada de asignar
tareas y responsabilidades en una empresa de desarrollo (quién hace qué,
cuándo y cómo).
Reutilización
El diseñador piensa en términos del
comportamiento de objetos y no en detalles de bajo nivel
Confiabilidad,
Integridad y Estabilidad.
Mantenimiento más sencillo.
Modificaciones locales.
Conclusión
La
planeación de un proyecto de programación que pretende dar un beneficio en
algún servicio ya existente o en uno nuevo requiere definitivamente de una
buena organización. RUP es eficaz para atacar los asuntos de organización y de
ejecución de un sistema de desarrollo de software. Ayuda a percibir el problema
desde distintos puntos de vista y ahorra el tiempo de demora para un proyecto
que tenga alguna continuidad y necesite modificaciones o adiciones.
Referencias
