Que es RUP

El proceso unificado racional (Rational Unified Process o RUP) es un proceso de ingeniería de software, entregado a través de una base de conocimiento de búsqueda habilitada para la web. El proceso mejora la productividad del equipo y ofrece las mejores prácticas de software a través de pautas, plantillas y mentores de herramientas para todas las actividades críticas del ciclo de vida del software. La base de conocimientos permite que los equipos de desarrollo obtengan todos los beneficios del lenguaje de modelado unificado (Unified Modeling Language o UML) estándar de la industria.

El RUP proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es garantizar la producción de software de alta calidad que satisfaga las necesidades de sus usuarios finales, dentro de un calendario y presupuesto predecibles.

El RUP es un producto de proceso, desarrollado y mantenido por Rational Software. El equipo de desarrollo de RUP está trabajando en estrecha colaboración con clientes, socios, grupos de productos  de Rational y la organización consultora de Rational, para garantizar que el proceso se actualice y mejore continuamente para reflejar experiencias recientes y mejores prácticas probadas y en evolución.

El RUP es una guía sobre cómo usar UML de manera efectiva. El UML es un lenguaje estándar de la industria que nos permite comunicar claramente los requisitos, las arquitecturas y los diseños. El UML fue creado originalmente por Rational Software y ahora lo mantiene el grupo de gestión de objetos de la organización de estándares (Object Management Group o OMG).

RUP captura muchas de las mejores prácticas en el desarrollo de software moderno en una forma adecuada para una amplia gama de proyectos y organizaciones. La implementación de estas prácticas recomendadas mediante la guía de anuncios de RUP ofrece a los equipos de desarrollo una serie de ventajas clave.

El RUP describe cómo implementar de manera efectiva enfoques probados comercialmente para el desarrollo de software para equipos de desarrollo de software. Estas se denominan "mejores prácticas" no tanto porque se puede cuantificar con precisión su valor, sino más bien porque se observa que las organizaciones exitosas las usan comúnmente en la industria.

Tharian, M. (2002). Rational unified process part-1. Mapana Journal of Sciences, 1(1), 81-94. doi:https://doi.org/10.12723/mjs.1.8

Inicio: Objetivos y Alcance del Proyecto

Que establece la fase de inicio?...

Durante la fase de inicio, establece el caso de negocio para el sistema y delimita el alcance del proyecto para lograr esto debe identificar todas las entidades externas con las que el sistema interactuara (Actores) y definir la naturaleza de esta interacción a un alto nivel.

esto implica identificar todos los casos de uso y describir algunos significativos.

el caso de negocio incluyo criterios de éxito, evaluación de riesgos y estimulación de los recursos necesarios, y un plan de fases que muestra la fecha de los principales hitos.

El resultado de la fase de inicio es:

• Un documento de visión: una visión general de los requisitos del proyecto central, las características clave y las principales limitaciones. 
• Un modelo de caso de uso especial (10%  20% completo).
• Un glosario inicial del proyecto (opcionalmente puede expresarse parcialmente como un modelo de dominio).
• Un caso comercial inicial, que incluye el contexto comercial, los criterios de éxito (proyección de ingresos, reconocimiento del mercado, etc.) y el pronostico financiero.
• Una evaluación inicial de riesgos.
• Un plan de proyecto, que muestra las fases y las iteraciones.
• Un modelo de negocios, si es necesario.
• Uno o varios prototipos.

  Cuales son las disciplinas que se usan con mas frecuencia en la fase "inicio"?

  -Modelado de negocios: Descripción de negocios procesos y la estructura interna de una empresa con el fin de:

  (a) Comprender mejor la empresa.

  (b) Poder llegar a los requisitos adecuados para los sistemas de software que se construirán para la                empresa en cuestión.

  -Gestión de requisitos: Obtención, Organización y documentación de requisitos.

  -Configuración y gestión de cambios: Cubre todas las tareas relacionadas con

  (a) La gestión de versiones y lanzamientos

  (b) Con la gestión de solicitudes de cambio.

  

  -Entorno: Adaptar el proceso a las necesidades de un proyecto (o de una organización) y seleccionando introducir y apoyar herramientas de desarrollo.  

Fin de la fase de inicio.

    Los criterios de evaluación para la fase de inicio son:

• Consecuencia de las partes interesadas en la definición del alcance y la estimación de costos.
• Comprensión de los requisitos como lo muestra la fidelidad de los casos de uso primarios.
• Credibilidad de las estimaciones de costos/programas , prioridades, riesgos y proceso de desarrollo.
• Profundidad y amplitud de cualquier prototipo arquitectónico que se desarrolle.
• Gastos reales contra los gastos planificados.

            ***El proyecto puede cancelarse o repensarse considerablemente si no logra pasar este hito***

Resumen general de la fase "Inicio" (video).

Fuentes bibliográficas:

Manoj Tharian.(2002 may-oct)."RATIONAL UNIFED PROCESS PART-1".mapana journal of Sciences.https://journals.christuniversity.in/index.php/mapana/article/view/92/67

Elaboración: Arquitectura del sistema

El propósito de la fase de elaboración es analizar el dominio del problema, establecer una base arquitectónica sólida, desarrollar el plan de proyecto y eliminar los elementos de mayor riesgo del proyecto. Para lograr estos objetivos, debe tener la vista de "milla ancha y pulgada de profundidad" del sistema. Las decisiones arquitectónicas deben tomarse con un entendimiento de todo el sistema: su alcance, funcionalidad mayor y no funcional requisitos como los requisitos de rendimiento.

   Es fácil argumentar que la fase de elaboración es la más crítica para el cuatro fases. Al final de esta fase, se considera la dura "ingeniería" completada y el proyecto se somete a su día de cuentas más importante: la decisión sobre si se compromete o no con la construcción y la transición etapas. Para la mayoría de los proyectos, esto también corresponde a la transición de una operación móvil, ligera y ágil y de bajo riesgo a un alto costo y alto riesgo operación con inercia sustancial. Mientras que el proceso siempre debe acomodar los cambios, las actividades de fase de elaboración aseguran que el la arquitectura, los requisitos y los planes son lo suficientemente estables, y los riesgos están suficientemente mitigados, por lo que puede determinar previsiblemente el costo y programar para completar el desarrollo. Conceptualmente, esto el nivel de fidelidad correspondería al nivel necesario para una organización comprometerse con una fase de construcción de precio fijo.

El resultado de la fase de elaboración es:

• Un modelo de caso de uso (al menos 80% completo): todos los casos de uso y actores han sido identificados, y la mayoría de las descripciones de casos de uso han sido desarrollado.

• Requisitos complementarios que capturan lo no funcional  y cualquier requisito que no esté asociado con un caso de uso especifico.

• Una descripción de la arquitectura de software.

• Un prototipo arquitectónico ejecutable.

• Una lista de riesgos revisada y un caso de negocios revisado.

• Un plan de desarrollo para el proyecto general, incluido el grueso-Plan de proyecto de grano, que muestra iteraciones "y criterios de evaluación para cada iteración.

• Un caso de desarrollo actualizado que especifique el proceso que se utilizará.

• Un manual de usuario preliminar (opcional)

Bibliografia:

Tharian, M. (2002). Rational unified process part-1. Mapana Journal of Sciences, 1(1), 81-94. doi:https://doi.org/10.12723/mjs.1.8

Construcción: culminar la funcionalidad del sistema

 En la fase de construcción, es donde se empieza a realizar las pruebas, en los componentes y funciones, para comprobar que no tenga errores el sistema y tuviera una buena funcionalidad, para que a la hora de ser entregado al cliente todo estuviera en orden. También se empieza a ensamblar todo lo que se realizo en la fase de elaboración, y se empieza a analizar el sistema para identificar todos los puntos que se tendrán en cuenta en la fase de depuración.

Esta es la penúltima fase, donde se termina de elaborar el sistema , y se analiza para identificar problemas en el sistema que resolverán el la ultima fase. Algunos de los puntos importantes de la construcción son: gestión de recursos y control de operaciones, estos se encargan en la optimización de costes, tiempos y calidad en la elaboración. En la construcción se puede notar un cambio entre inicio y la transición; ya que pasa por varios procesos y problemas que obligan que el planeamiento cambie de dirección mas optima para el proyecto.

Cada proyecto es distinto, y su elaboración igual; cuando un proyecto es demasiado grande se realizan en construcción en paralelo, y como se dice su nombre se realizan procesos de forma paralela, para realizar el proyecto de una forma mas rápida, pero pueden complicar la gestión de recurso. Una de las cualidades de la arquitectura es la facilidad que tiene en la elaboración de la construcción, y la arquitectura robusta, que esta muy relacionada con los planes comprensibles, resultan en una de las construcciones mas seguras.

La fase de construcción, tiene como prioridad que el producto cumpla con ciertos puntos, los cuales son:

• El software debe de estar integrado a las plataformas de forma adecuada
• Manuales para usuario
• Descripción detallada de la versión actual

Es muy importante que el producto denote un alto estándar de calidad y trabajo, y que cumpla con las especificaciones y exigencias, del cliente y los usuarios.

Transición: Depurar y entregar al usuario

El propósito de la fase de transición es hacer la transición del producto de software a la comunidad de usuarios. Una vez que el producto ha sido entregado al usuario final, generalmente surgen problemas que requieren desarrollar nuevas versiones, corregir algunos problemas o finalizar las funciones que se pospusieron.

Se ingresa a la fase de transición cuando una línea de base está lo suficientemente madura para implementarse en el dominio del usuario final. Por lo general, esto requiere que algún subconjunto utilizable del sistema se haya completado con un nivel aceptable de calidad y que la documentación del usuario esté disponible para que la transición al usuario brinde resultados positivos para todas las partes. Esto incluye:

• "beta testing" para validar el nuevo sistema frente a las expectativas de los usuarios
• operación paralela con un sistema heredado que se está reemplazando
• conversión de bases de datos operativas
• formación de usuarios y mantenedores
• lanzar el producto a los equipos de marketing, distribución y ventas

La fase de transición se enfoca en las actividades requeridas para poner el software en manos de los usuarios. Por lo general, esta fase incluye varias iteraciones, incluidas versiones beta, versiones de disponibilidad general, así como versiones de corrección de errores y mejoras. Se dedica un esfuerzo considerable al desarrollo de documentación orientada al usuario, la capacitación de los usuarios, el apoyo a los usuarios en el uso inicial del producto y la reacción a los comentarios de los usuarios. Sin embargo, en este punto del ciclo de vida, los comentarios de los usuarios deben limitarse principalmente a problemas de ajuste, cofiguración, instalación y usabilidad del producto.

Los objetivos principales de la fase de transición incluyen:

• Lograr la autosuficiencia del usuario
• Lograr el acuerdo de las partes interesadas de que las líneas base de implementación están completas y son consistentes con los criterios de evaluación de la visión.
• Lograr la línea de base del producto final de la manera más rápida y rentable posible

Esta fase puede variar desde muy simple hasta extremadamente compleja, dependiendo del tipo de producto. Por ejemplo, una nueva versión de un producto de escritorio existente puede ser muy simple, mientras que reemplazar el sistema de control de tráfico aéreo de una nación sería muy complejo.

Bibliografía:

Tharian, M. (2002). Rational unified process part-1. Mapana Journal of Sciences, 1(1), 81-94. doi:https://doi.org/10.12723/mjs.1.8

Roles

 Que son los roles en RUP...

Los proyectos de software siempre aumentan su complejidad. La complejidad de los proyectos    surge debido a la creciente sofisticación de las aplicaciones de software y de sus características implementadas. 

Sin embargo, la mayoría de los proyectos son desarrollados por pequeñas organizaciones. Dado que estas empresas tienen una dimensión reducida, el número de personas que constituyen cada uno de los equipos de desarrollo de software y estas personas cumplen un un rol dentro del equipo especifico.

                           (responsabilidades de cada rol)💬👀

Como se definen los Roles dentro un equipo en RUP?

Un trabajador define el comportamiento y las responsabilidades de un individuo o de un grupo de individuos que trabajan juntos como un equipo. Podría considerar a un trabajador como un "sombrero" que una persona puede usar el el proyecto. Un individuo puede usar muchos sombreros diferentes Esta es una distinción importante porque es natural pensar en un trabajador como el individuo o el equipo en si mismo, pero en el proceso unificado el trabajador es mas el Rol que define como los individuos deben realizar el trabajo. Las responsabilidades que le asignamos a un trabajador incluyen tanto la realización de determinadas actividades como la de ser propietario de un conjunto de artefactos.

Los roles en RUP se distribuyen de la siguiente manera...

Desarrolladores:

Arquitecto de software.

Diseñador

Diseñador de interfaz de usuario

Diseñador de cápsulas.

Diseñador de base de datos.

Implementador.
Integrador.

Analistas: 

Analista de procesos de negocio.

Diseñador del negocio.

                                                 Analista de sistema.

                                                         Especificador de requisitos.

Gestores:

Jefe de proyecto

Jefe de control de cambios.

Jefe de configuración.

Jefe de pruebas

Jefe de despliegue

Ingeniero de procesos

Revisor de gestión del proyecto
Gestor de pruebas.

Apoyo:

Documentador técnico

Administrador de sistema

Especialista en herramientas

Desarrollador de cursos Artista  gráfico

Especialista en pruebas:

• Especialista en Pruebas (tester)
• Analista de pruebas
• Diseñador de pruebas

Ejemplo de como pueden ser asignados los roles y las actividades que cada miembro llevara a cabo...

Fuentes bibliográficas:

Manoj Tharian.(2002 may-oct)."RATIONAL UNIFED PROCESS PART-1".mapana journal of Sciences.https://journals.christuniversity.in/index.php/mapana/article/view/92/67

Actividad

Una actividad de un trabajador específico es una unidad de trabajo que un individuo en ese se puede pedir un rol que realice. La actividad tiene un propósito claro, generalmente expresado en términos de crear o actualizar algunos artefactos, como un modelo, una clase, un plan. Cada actividad se asigna a un trabajador específico. La granularidad de una actividad es generalmente de unas pocas horas a unos pocos días, generalmente involucra a un trabajador y afecta a uno o solo un pequeño número de artefactos. Una actividad debe ser utilizable como elementos de planificación y progreso; si es demasiado pequeño, se descuidará, y si es demasiado grande, el progreso tendría que expresarse en términos de partes de una actividad.

Ejemplo de actividades:

• Planifique una iteración, para el trabajador: gerente de proyecto
• Encuentre casos de uso y actores, para el trabajador: analista del sistema
• Revise el diseño, para el trabajador: revisor de diseño
• Ejecutar la prueba de rendimiento, para el trabajador: probador de rendimiento

Bibliografía

Tharian, M. (2002). Rational unified process part-1. Mapana Journal of Sciences, 1(1), 81-94. doi:https://doi.org/10.12723/mjs.1.8

Artefactos

Los artefactos son pates de información, que pueden ser producidas, modificadas o utilizada en un proceso. Los artefactos son los resultados tangibles del proyecto, que pueden estar en medio o al final del proyecto.

Estos artefactos son utilizados por los trabajadores, para realizar actividades o conseguir resultados. En u diseño orientado a objetos, si los trabajadores son objetos, los artefactos son parámetros.

los artefactos se pueden catalogar en:

• Modelo, como modelo de caso o modelo de diseño.
• Elemento de modelo, ósea, un elemento dentro del modelo, ejemplo una clase o subsistema.
• Documento, un contrato de negocio una arquitectura de sistema.
• Código fuente
• Ejecutables

En si, un artefacto es un dato o subproducto del método, pero nunca el producto final; loa artefactos son una parte importante del proceso, ya que normalmente son utilizados en fases o partes del método.

Disciplinas

Una mera enumeración de todos los trabajadores, actividades y artefactos no constituye del todo un proceso. Se necesita una forma de describir secuencias significativas de actividades que produzcan algún resultado valioso y mostrar las interacciones entre los trabajadores.

Una disciplina o flujo de trabajo es una secuencia de actividades que produce un resultado de valor observable. Se puede expresar como un diagrama de secuencia, un diagrama de colaboración o un diagrama de actividad.

Se tiene que tomar en cuenta que no siempre es posible o práctico representar todas las dependencias entre actividades. A menudo, dos actividades están más entrelazadas de lo que se muestra, especialmente cuando involucran al mismo trabajador o al mismo individuo. Las personas no son máquinas, y el flujo de trabajo no puede interpretarse literalmente como un programa para personas, que debe seguirse de manera exacta y mecánica.

Aunque los nombres de los seis flujos de trabajo de ingeniería principales pueden evocar las fases secuenciales de un proceso iterativo, debemos tener en cuenta que las fases de un proceso iterativo son diferentes y que estos flujos de trabajo se revisan una y otra vez a lo largo de estos nueve flujos de trabajo principales y se repiten, con varios énfasis e intensidad en cada iteración.

Tharian, M. (2002). Rational unified process part-1. Mapana Journal of Sciences, 1(1), 81-94. doi:https://doi.org/10.12723/mjs.1.8