El Proceso Unificado Racional (Rational Unified

METODOLOGIA RUP
El Proceso Unificado Racional (Rational Unified Process en inglés,
habitualmente resumido como RUP) 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 un conjunto de metodologías
adaptables al contexto y necesidades de cada organización.
PRINCIPIOS DE DESARROLLO
El RUP está basado en 5 principios clave que son:
Adaptar el proceso: El proceso deberá adaptarse a las características del
proyecto u organización. El tamaño, así como su tipo o las regulaciones que
lo condicionen, influirán en su diseño específico. También se deberá tener
en cuenta el alcance del proyecto.
Equilibrar prioridades: Los requerimientos de los diversos participantes
pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe
encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este
equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente: Los proyectos se entregan, aunque sea
de un 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.
Colaboración entre equipos: El desarrollo de software no lo hace una
única persona sino múltiples equipos. Debe haber una comunicación fluida
para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados,
etc.
Elevar el nivel de abstracción: Motiva el uso de conceptos reutilizables
tales como patrón del software, lenguajes 4GL o marcos de referencia
(frameworks). Esto evita que los ingenieros de software vayan directamente
de los requisitos a la codificación de software a la medida del cliente, sin
saber con certeza qué codificar para satisfacer de la mejor manera los
requerimientos y sin comenzar desde un principio pensando en la
reutilización del código.
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue
creado ensamblando los elementos en secuencias semi-ordenadas. Organiza
las tareas en fases e iteraciones. Divide el proceso en cuatro fases, dentro
de las que se realizan varias iteraciones en número variable según el
proyecto y en las que se hace un mayor o menor hincapié en las distintas
actividades.
METODOLOGIA EN ESPIRAL
Es un modelo de ciclo de vida del software definido por primera vez por
Barry Boehm en 1988, utilizado generalmente en la Ingeniería de software.
Las actividades de este modelo se conforman en una espiral, en la que cada
bucle o iteración representa un conjunto de actividades. Las actividades no
están fijadas a priori, sino que las siguientes se eligen en función del
análisis de riesgo, comenzando por el bucle interior.
En cada vuelta o iteración hay que tener en cuenta:
a. Los Objetivos: Que necesidad debe cubrir el producto.
b. Alternativas: Las diferentes formas de conseguir los objetivos de forma
exitosa, desde diferentes puntos de vista como pueden ser:
1. Características: experiencia del personal, requisitos a cumplir, etc.
2. Formas de gestión del sistema.
3. Riesgo asumido con cada alternativa.
c. Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras
o funcionalidades:
Se planificaran los siguientes pasos y se comienza un nuevo ciclo espiral.
Tiene una forma de caracola y se dice que mantiene dos dimensiones, la
radial y la angular:
1. Angular: Indica el avance del proyecto software dentro de un ciclo.
2. Radial: Indica el aumento del coste del proyecto, ya que con cada
nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos grandes y complejos como la
creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice
que uno de los aspectos fundamentales de su éxito radica en que el equipo
que lo aplique tenga la necesaria experiencia y habilidad para detectar y
catalogar correctamente los riesgos.
Tareas: Para cada ciclo habrá cuatro actividades:
Determinar objetivos




Fijar también los productos definidos a obtener: requerimientos,
especificación, manual de usuario.
Fijar las restricciones.
Identificación de riesgos del proyecto y estrategias alternativas para
evitarlos.
Hay una cosa que solo se hace una vez: planificación inicial o previa.
Análisis del riesgo: Se estudian todos los riesgos potenciales y se
seleccionan una o varias alternativas propuestas para reducir o eliminar los
riesgos.
Desarrollar, verificar y validar (probar): Tareas de la actividad
propia y de prueba.


Análisis de alternativas e identificación resolución de riesgos.
Dependiendo del resultado de la evaluación de los riesgos, se elige un
modelo para el desarrollo, el que puede ser cualquiera de los otros
existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si
los riesgos en la interfaz de usuario son dominantes, un modelo de
desarrollo apropiado podría ser la construcción de prototipos
evolutivos. Si lo riesgos de protección son la principal consideración,
un desarrollo basado en transformaciones formales podría ser el más
apropiado.
Planificar: Revisamos todo lo hecho, evaluándolo, y con ello decidimos si
continuamos con las fases siguientes y planificamos la próxima actividad.
METODOLOGIA EN CASCADA
En Ingeniería de software el desarrollo en cascada, también llamado modelo
en cascada, es el enfoque metodológico que ordena rigurosamente las
etapas del ciclo de vida del software, de tal forma que el inicio de cada
etapa debe esperar a la finalización de la inmediatamente anterior.
Un ejemplo de una metodología de desarrollo en cascada es:
1. Análisis de requisitos
2. Diseño del Sistema
3. Diseño del Programa
4.
5.
6.
7.
Codificación
Pruebas
Implantación
Mantenimiento
De esta forma, cualquier error de diseño detectado en la etapa de prueba
conduce necesariamente al rediseño y nueva programación del código
afectado, aumentando los costes del desarrollo. La palabra cascada sugiere,
mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario
para introducir un cambio en las fases más avanzadas de un proyecto.
Fases del modelo:
Análisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software
para determinar qué objetivos debe cubrir. De esta fase surge una memoria
llamada SRD (documento de especificación de requisitos), que contiene la
especificación completa de lo que debe hacer el sistema sin entrar en
detalles internos.
Diseño del Sistema
Se descompone y organiza el sistema en elementos que puedan elaborarse
por separado. Como resultado surge el SDD (Documento de Diseño del
Software), que contiene la descripción de la estructura relacional global del
sistema y la especificación de lo que debe hacer cada una de sus partes, así
como la manera en que se combinan unas con otras.
Es conveniente distinguir entre diseño de alto nivel o arquitectónico y
diseño detallado. El primero de ellos tiene como objetivo definir la
estructura de la solución, identificando grandes módulos y sus relaciones.
Con ello se define la arquitectura de la solución elegida. El segundo define
los algoritmos empleados y la organización del código para comenzar la
implementación.
Diseño del Programa
Es la fase en donde se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario así como también los
análisis necesarios para saber que herramientas usar en la etapa de
Codificación.
Codificación
Es la fase de programación o implementación. Aquí se implementa el código
fuente, haciendo uso de prototipos así como pruebas y ensayos para
corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las
bibliotecas y componentes reutilizables dentro del mismo proyecto para
hacer que la programación sea un proceso mucho más rápido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y
se comprueba que funciona correctamente y que cumple con los requisitos,
antes de ser puesto.
Implantación
El software obtenido se pone en producción. Se implantan los niveles
software y hardware que componen el proyecto. La implantación es la fase
con más duración y con más cambios en el ciclo de elaboración de un
proyecto. Es una de las fases finales del proyecto.
Durante la explotación del sistema de software pueden surgir cambios, bien
para corregir errores o bien para introducir mejoras.
Variantes
Existen variantes de este modelo; especialmente la que hace uso de
prototipos y en la que se establece un ciclo antes de llegar a la fase de
mantenimiento, verificando que el sistema final este libre de fallos.
Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea
una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
Ventajas
Se tiene todo bien organizado y no se mezclan las fases. Es perfecto para
proyectos que son rígidos, y además donde se especifiquen muy bien los
requerimientos y se conozca muy bien la herramienta a utilizar
METODOLOGIA XP
Se diferencia de las metodologías tradicionales principalmente en que pone
más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de
XP consideran que los cambios de requisitos sobre la marcha son un
aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.
Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier
punto de la vida del proyecto es una aproximación mejor y más realista que
intentar definir todos los requisitos al comienzo del proyecto e invertir
esfuerzos después en controlar los cambios en los requisitos.
Características De La Metodología XP
• Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras.
• Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión.
• Programación en parejas: se recomienda que las tareas de desarrollo se
lleven a cabo por dos personas en un mismo puesto. De esta manera el
código es revisado y discutido mientras se escribe.
• Frecuente integración del equipo de programación con el cliente o usuario.
Se recomienda que un representante del cliente trabaje junto al equipo de
desarrollo.
• Corrección de todos los errores antes de añadir nueva funcionalidad.
Hacer entregas frecuentes.
• Refactorización del código, es decir, reescribir ciertas partes del código
para aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento.
• Propiedad del código compartida: Este método promueve el que todo el
personal pueda corregir y extender cualquier parte del proyecto. Las
frecuentes pruebas de regresión garantizan que los posibles errores serán
detectados.
• Simplicidad en el código: es la mejor manera de que las cosas funcionen.
Cuando todo funcione se podrá añadir funcionalidad si es necesario. Con
más comunicación resulta más fácil identificar qué se debe y qué no se debe
hacer. Mientras más simple es el sistema, menos tendrá que comunicar
sobre este, lo que lleva a una comunicación más completa, especialmente si
se puede reducir el equipo de programadores