Crear software es una tarea de la que día con día incrementan su demanda y su complejidad. Por su naturaleza, un software se puede crear de una infinidad de maneras posibles, lo que dificulta la su implementación «limpia» en los centros de trabajo. Un día estamos en la empresa «Soft», donde trabajamos a cierto ritmo, con metas, con tiempos, con diseños… pero cuando dejamos la empresa y llegamos a trabajar a «ware» entonces comienzan los problemas. Soft tiene una metodología y ware tiene otra. ¿Cómo solucionar esto? Estandarizando metodologías. Un estándar en los procesos de análisis, desarrollo, implementación y todo lo que involucra la creación de software es precisamente lo que pensaron en Rational Software, una empresa de desarrollo. La metodología se llama RUP y nos ayuda a tener un lenguaje común de desarrollo en toda la comunidad. Os presento:
¿Qué es RUP?
Por sus siglas significa Rational Unified Process (proceso unificado de Rational), que no es otra cosa que una serie de pasos propuestos para ser comunes en cualquier ambiente de desarrollo, un proceso de ingeniería de software.
En palabras sencillas: es una manera de organizar quien diablos hará que actividad y que significa esa actividad.
RUP puede llegar a considerarse un framework para desarrollo de software, pues presenta una estandarización (bien documentada) del proceso.
Fases de RUP
RUP se separa en cuatro fases, que se repetirán hasta terminar el proyecto. Cada repetición se llama iteración.
1. Inicio
Durante esta fase se busca definir los objetivos principales de la iteración o del proyecto en general. Se hacen las primeras modelaciones, se toman requerimientos (para saber más de requerimientos, te recomiendo ¿Requerimientos? ¿Casos de usuario? ¡Más despacio cerebrito!) y se diseña una primera vista de la interfaz de usuario (un prototipo básico). También se planea la manera en que se trabajará en el proyecto en adelante.
2. Elaboración
Se especificarán con mayor detalle los requerimientos definidos al inicio de la iteración. Deben ser lo suficientemente detallados para identificar los riesgos del proyecto (si quieres saber más sobre riesgos, te recomiendo mi post Iniciando nuevos proyectos) y poder entender los requerimientos para las siguientes planeaciones. También se construye un esqueleto de lo que será el producto final, con el fin de poder hacer pruebas fiables en él.
3. Construcción
Quizá conocías esta fase y no lo sabías. Es la etapa de código, donde se desarrollará toda la aplicación a tal punto de poder lanzarla al público. Lo importante aquí es que la implementación sea acorde a los requerimientos, de tal forma que podamos satisfacerlos, pero para ello requerimos, por cada requerimiento, hacer un análisis a profundidad, diseñar una solución que lo satisfaga y finalmente escribir el código y hacer las pruebas correspondientes. Si es necesario, se hacen pequeñas distribuciones del proyecto con el fin de obtener retroalimentación de los usuarios.
4. Transición
Esta fase busca entregar el sistema. Debe haber pruebas tanto de los programadores como de los usuarios con el fin de dejar la aplicación a punto. Además es importante planear, si se requiere, la siguiente iteración.
A grandes rasgos, esto es RUP. En las referencias habrá mucha más información de la que podría colocar en este post sin hacerlo aburrido. En fin, este es el objetivo del internet: tener información de muchas (en serio muchas) fuentes distintas para así lograr un panorama más amplio.
Referencias
Haz clic para acceder a 1251_bestpractices_TP026B.pdf
Esta publicación de Scott W. Ambler describe a profundidad lo que es RUP formalmente.
Este post habla sobre el mismo tema. Lo publica un compañero de universidad.
Y también de otro compañero tenemos esta joya de publicación.
Doctor Profesor Alexis Freud 