Modelo RUP (Proceso Unificado de Rational)
Es un proceso de ingeniería de software, que hace una
propuesta orientada por disciplinas para lograr las tareas y responsabilidades
de una organización que desarrolla software.
Su meta principal es asegurar la producción de software de
alta calidad que cumpla con las necesidades de los usuarios, con una planeación
y presupuesto predecible.
Características:
Dirigido por Casos de Uso:
Los casos de uso son los artefactos primarios para establecer
el comportamiento deseado del sistema.
Centrado en la Arquitectura:
La arquitectura es utilizada para conceptualizar,
construir, administrar y evolucionar el sistema en desarrollo.
Iterativo e Incremental:
Maneja una serie de entregas ejecutables.
Integra continuamente la arquitectura para producir nuevas
versiones mejoradas.
Conceptualmente amplio y diverso.
Enfoque orientado a objetos.
En evolución continua.
Adaptable.
Repetible.
Permite mediciones:
Estimación de costos y tiempo, nivel de avance, etc.
Fases y sus artefactos correspondientes del modelo RUP
Inicio:
Documento Visión
Diagramas de casos de uso
Especificación de Requisitos
Diagrama de Requisitos
Elaboración:
Documento Arquitectura que trabaja con las siguientes
vistas:
Vista Lógica:
Diagrama de clases
Modelo
E-R (Si el sistema así lo requiere)
Vista de Implementación:
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboración
Vista Conceptual:
Modelo
de dominio
Vista física:
Mapa de
comportamiento a nivel de hardware
Diseño y desarrollos de casos de uso, o flujos de casos de uso
arquitectónicos
Pruebas de los
casos de uso desarrollados, que demuestran que la arquitectura documentada
responde como se esperaba
Construcción:
Especificación de requisitos
faltantes
Diseño y desarrollo de casos de uso y/o
flujos de acuerdo con la planeación iterativa
Pruebas de los casos de uso desarrollados, y
pruebas de regresión según sea el caso
Transición:
Pruebas finales de aceptación
Puesta en producción
Estabilización
Rubén
Ballesteros. (2018). Metodología RUP (Proceso Racional Unificado). 29 de
noviembre de 2021, de YouTube Sitio web:
https://youtu.be/omewCjnWV3M
Roles del modelo RUP
Definición:
Un rol es la función que una persona desempeña en un lugar o en una situación. En RUP, un rol define el comportamiento y responsabilidades de un individuo o de un grupo de individuos trabajando juntos como un equipo.
Una persona puede desempeñar diversos roles, así como un rol puede ser interpretado por varias personas.
Los roles se distribuyen entre los miembros del proyecto y son los que definen las tareas de cada uno y el resultado (artefactos) que se espera de cada uno de ellos.
Las responsabilidades de un rol son tanto llevar a cabo un conjunto de actividades, así como ser el dueño de un conjunto de artefactos.
Diferentes roles en el modelo RUP:
Hay diversos roles en RUP los cuales sirven para establecer que tarea le tocara desempeñar a que persona, estos roles son los que se enlistan a continuación:
Jefe de Proyecto:
Establece un conjunto de prácticas que
aseguran la integridad y calidad de los artefactos del proyecto. Se encargará
de supervisar el establecimiento de la arquitectura del sistema.
Sus funciones son:
Llevar la planificación y control del proyecto.
Asignar los recursos.
Gestionar las prioridades.
Coordinar las interacciones con los clientes y usuarios.
Mantener el equipo del proyecto enfocado en los objetivos.
Gestión de riesgos.
Analista de Sistemas:
Sus funciones son:
Captura, especificación y validación de requisitos,
interactuando con el cliente y los usuarios mediante entrevistas.
Recomienda las mejores opciones y sistemas para cumplir los
requerimientos.
Elaboración del modelo de Análisis y Diseño.
Colaboración en la elaboración de las pruebas funcionales y
el modelo de datos.
Diseñador:
Funciones y propósitos:
El propósito del diseño es el de crear una estructura
interna limpia y relativamente simple, llamada arquitectura.
Generar prototipos rápidos del sistema.
Diseñar el documento arquitectónico y mantenerlo actualizado
durante el proyecto.
Velar por que el producto final se ajuste al diseño
realizado.
Programador:
Los programadores deben convertir la
especificación del sistema en código fuente ejecutable utilizando uno o más
lenguajes de programación, así como herramientas de software.
Especialista en pruebas (Tester):
Se divide en analista de pruebas y diseñador
de pruebas:
Un analista de pruebas es el rol que identifica y define
las pruebas necesarias, supervisa el proceso de prueba necesario y los
resultados de cada ciclo de prueba y evalúa la calidad global.
El diseñador de pruebas es responsable de definir el
enfoque de pruebas y garantizar su satisfactoria implementación.
Cliente:
El cliente es quien especifica los requisitos
del sistema.
Gabriela Navarro. (2016). Roles de RUP. 29 de noviembre de 2021, de YouTube Sitio web: https://youtu.be/OPNX7CtEiAU
Disciplinas del modelo RUP
Diferentes disciplinas:
Administración de Proyectos.
La administración de proyectos de software es el arte
de balancear los objetivos, los riesgos y las restricciones para entregar un
producto que satisfaga las necesidades del cliente y los usuarios finales.
Sus propósitos son:
– Proveer de un marco de trabajo para administrar proyectos de
software.
– Proveer líneas guía para planear, organizar, ejecutar y controlar
proyectos.
– Proveer un marco de trabajo para administrar el riesgo.
Modelado Negocio.
Sus propósitos son:
– Entender la estructura y la dinámica de la organización
en que el sistema se desarrollará.
– Entender el problema correcto en la organización destino e identificar
mejoras potenciales.
– Asegurar que los clientes, usuarios finales, y desarrolladores tengan un
común entendimiento en la organización destino.
– Identificar los requerimientos del sistema para apoyar la organización
destino.
Requerimientos.
Describe cómo definir la visión del sistema y
traducir la visión a un modelo de casos de uso que, con el apoyo
de especificaciones suplementarias, defina los requerimientos detallados de
software.
Las metas son:
– Establecer y mantener el acuerdo con los clientes y los
demás stakeholders de lo que debe hacer el sistema y por qué.
– Provee a los desarrolladores del sistema un mejor entendimiento de los
requerimientos del sistema.
– Define los límites del sistema.
– Provee una base para la planeación de cada iteración.
– Provee una base para estimar el costo y tiempo de desarrollo del sistema.
Análisis y Diseño.
Su propósito es traducir los requerimientos a
especificación que describan cómo implementar el sistema. Para hacer esta
traducción, se debe entender los requerimientos y transformarlos a un diseño de
sistema para seleccionar la mejor estrategia de implementación.
Implementación.
Sus propósitos son:
– Definir la organización del código en términos de implementación de
subsistemas organizados en capas.
– Implementar clases y objetos en términos de componentes (archivos fuente,
binarios, ejecutables, y otros).
– Probar los componentes desarrollados como unidades.
– Integrar en un sistema ejecutable los resultados producidos por
implementadores individuales o por equipos.
Pruebas.
Esta disciplina es un proveedor de servicios a otras
disciplinas. Las pruebas se enfocan principalmente en evaluar y
asegurar la calidad del producto, usando ciertas prácticas principales:
– Encontrar y documentar las fallas en el producto de software: defectos y
problemas.
– Aconsejar a la administración desde una perspectiva de calidad del software.
– Validar que el producto de software trabaje como se diseñó.
– Validar que los requerimientos están implementados apropiadamente.
Administración de Cambios y la
Configuración.
Su propósito es rastrear y mantener la integridad de la
evolución de los activos del proyecto.
Durante el desarrollo muchos productos de trabajo son creados, los cuales son
activos importantes que deben ser salvaguardados y estar disponibles para
volver a usarlos.
Estos productos de trabajo evolucionan, especialmente en un desarrollo
iterativo, son actualizados una y otra vez. Al menos que una persona sea
usualmente responsable de un artefacto, no podemos confiar en la memoria
individual para guardar los activos de cada proyecto.
Ambiente.
Su propósito es apoyar el desarrollo de la
organización con procesos y herramientas.
Esto incluye lo siguiente:
– Seleccionar y adquirir herramientas.
– Configurar las herramientas en la organización.
– Configurar el proceso.
– Mejorar el proceso.
– Proporcionar apoyo técnico a los procesos de: infraestructura de tecnologías
de información, administración de contabilidad, recuperación.
Despliegue.
Su propósito es llevar el producto de software al
usuario, lo que involucra las siguientes actividades:
Probar el software en ambiente final de operación.
– Empaquetar el software para su entrega.
– Distribuir el software.
– Instalar el software.
– Capacitar a los usuarios finales y a los vendedores.
– Migrar software existente o convertir bases de datos.
Video que profundiza un poco más en esto:
Cristian
Valle Ronceros. (2020). Comprender RUP - UML en 10 minutos. 29 de noviembre de
2021, de YouTube Sitio web: https://youtu.be/hv6YmJpxeWA
Pros y contras
Ventajas:
·
Evaluación en cada fase que permite cambios de
objetivos
·
Funciona bien en proyectos de innovación
·
Es sencillo, ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software
·
Seguimiento detallado en cada una de las fases
Desventajas:
·
La evaluación de riesgos es compleja
·
Excesiva flexibilidad para algunos proyectos
·
El cliente se ubica en una posición que puede
no ser muy agradable para él
Mane
S. Rivera. (2017). Metodologías: Ventajas y Desventajas. 29 de noviembre de
2021, de YouTube Sitio web: https://youtu.be/gn_cNvGTHGg
Comentarios
Publicar un comentario