Introducción
El Proceso Unificado de Rational (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.
También se conoce por este nombre
al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye
información entrelazada de diversos artefactos y descripciones de las diversas
actividades. Está incluido en el Rational Method Composer (RMC), que permite la
personalización de acuerdo con las necesidades.
Originalmente se diseñó un proceso
genérico y de dominio público, el Proceso Unificado, y una especificación más
detallada, el Rational Unified Process, que se vendiera como producto
independiente...
Principios de desarrollo
El RUP está basado en 6 principios
clave que son los siguientes:
Adaptar el proceso
El proceso deberá adaptarse a las
necesidades del cliente ya que es muy importante interactuar con él. Las
características propias del proyecto u organización. El tamaño del mismo, 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 en un
área subformal.
Equilibrar prioridades
Los requisitos 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 requisitos, desarrollo, evaluaciones, planes, resultados,
etc.
Elevar el nivel de abstracción
Este principio dominante motiva el
uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o
marcos de referencia (frameworks) por nombrar algunos. 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 requisitos y sin comenzar desde un principio
pensando en la reutilización del código. Un alto nivel de abstracción también
permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas
se pueden acompañar por las representaciones visuales de la arquitectura, por
ejemplo con el lenguaje UML.
Enfocarse en la calidad
El control de calidad no debe
realizarse al final de cada iteración, sino en todos los aspectos de la
producción. El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente.
No hay comentarios:
Publicar un comentario