Yo hace algún tiempo he venido buscando esta guía en internet y no la había encontrado, hasta el día de antes de ayer, que pude encontrarlo por esas casualidades de la vida, así que si a alguien le interesa pues les dejo la dirección para que puedan aprovecharla.

URL: RoadpMap de RUP en línea

Cabe recordar que para poder ver de forma correcta este roadmap, se necesita instalar java en el pc y lo pueden conseguir de forma gratuita en http://www.java.com/es/.

Saludos.

Aquí quien tiene la mayor responsabilidad es el Jefe del Proyecto, ya que será él quien administre todos los recursos y determine para un proyecto específico las etapas, los roles y demás necesarios; recordemos que un proyecto puede ser, desde un Backup de una BD hasta el desarrollo de un sistema distribuido completo.

Para no dilatar mas, aquí los roles que faltaban:

1. Stakeholder El rol StakeHolder se define como cualquier persona que sea afectada materialmente por el resultado del proyecto.Solucionar con eficacia cualquier problema complejo implica el satisfacer las necesidades de un grupo diverso de stakeholders. Típicamente, los stakeholders tendrán diversas perspectivas del problema y diversas necesidades que se deben tratar para la solución. Muchos stakeholders son usuarios del sistema. Otros stakeholders son solamente usuarios indirectos del sistema o son solo afectados por los resultados del negocio que el sistema influencia. Una comprensión de quienes son los stakeholders y sus necesidades particulares son elementos dominantes al desarrollar una solución eficaz.
   • Cliente o representante del cliente.
   • Usuario o representante del usuario.
   • Inversionista.
   • Accionista.
   • Encargado de la producción.
   • Comprador.
   • y así sucesivamente.
2. Any Role Cualquier rol identificado en RUP puede, dar privilegios de acceso, “chek-in” y “check-out” a cualquier artefacto relacionado con el producto para el mantenimiento en el sistema de control de configuración. Cualquier rol puede también enviar peticiones de cambio y hacer actualizaciones a las peticiones de cambio de las cuales es el dueño.

   

3. Course Developer El rol Course Developer desarrolla el material del entrenamiento para enseñar a usuarios cómo utilizar el producto. Esto incluye crear las diapositivas, notas del estudiante, ejemplos, clases particulares, y así sucesivamente para realzar la comprensión de los usuarios del producto.

   

4. Graphic Artist El artista gráfico crea las ilustraciones del producto que son incluidas como parte del empaquetado del producto.

   

5. Tool Specialist El especialista de herramientas es responsable de los instrumentos de apoyo en el proyecto. Esto incluye seleccionar y adquirir las herramientas. El especialista de herramienta también configura herramientas y verifica que funcionen correctamente.

   

6. System Administrator El rol administrador de sistema mantiene el ambiente de desarrollo, ambos: hardware y software, administración del sistema, backups, y así sucesivamente. En organizaciones más grandes, la gente asignada a este rol pertenece típicamente a un pool de recursos fuera del proyecto, y será responsable de apoyar el ambiente de desarrollo en proyectos múltiples.

   

7. Technical Writer El escritor técnico produce el material de ayuda del usuario final tal como guías del usuario, textos de ayuda, notas del lanzamiento, y así sucesivamente.

   

Ahora que hemos terminado con los roles veremos algunos otros puntos de RUP, ya que es extenso, para entenderlo mejor.

Saludos.

Entonces los roles incluidos dentro del rol genérico Manager en RUP son los siguientes:

1. Process Engineer El rol ingeniero de procesos es responsable del proceso de desarrollo de software. Esto incluye configurar el proceso antes inicio del proyecto y continuamente mejorar el proceso durante el desarrollo del proyecto.

   

2. Project Manager El rol encargado del proyecto asigna recursos, forma prioridades, coordina interacciones con los clientes y los usuarios, y generalmente mantiene al equipo de proyecto centrado en el objetivo correcto. El encargado de proyecto también establece un sistema de las prácticas que aseguran la integridad y la calidad de los artefactos del proyecto.

   

3. Change Control Manager El rol encargado del control del cambio supervisa el proceso de control del cambio. Este rol es desempeñado por un tablero de control de configuración (o cambio) (Configuration Control Board – CCB) y consta generalmente de representantes de todas las partes interesadas, incluyendo clientes, desarrolladores, y usuarios. En un proyecto pequeño, un solo miembro del equipo, como el encargado de proyecto o el arquitecto del software, puede desempeñar este papel.

   

   El encargado del control del cambio es también responsable de definir el Requerimiento de Cambio del Proceso de Gerencia, que se documenta en el Plan de Configuración de la Gerencia.

4. Configuration Manager El encargado de la configuración proporciona la infraestructura y el ambiente completo de la gerencia de configuración (CM) al equipo de desarrollo del producto. La función del CM es la de apoyar la actividad del desarrollo del producto de modo que los desarrolladores y los integradores tengan espacios de trabajo apropiados para construir y para probar su trabajo, y de modo que todos los artefactos estén disponibles para la inclusión en la unidad de despliegue cuando sea necesario. El encargado de la configuración también tiene que asegurarse de que el ambiente del CM facilite la revisión del producto, y las actividades de seguimiento de los cambios y defectos. El encargado de la configuración es también responsable de escribir el plan del CM y de divulgar la estadística del progreso basada en las solicitudes de cambio.

   

5. Deployment Manager El rol encargado del despliegue planea la transición del producto a la comunidad de usuarios y sus documentos en varios documentos asociados.

   

6. Project Reviewer El rol revisor del proyecto es responsable de evaluar los artefactos del planeamiento del proyecto y los artefactos del gravamen del proyecto en los puntos importantes de la revisión en el ciclo de vida del proyecto. Éstos son acontecimientos significativos de la revisión porque marcan los puntos en los cuales el proyecto puede ser cancelado si el planeamiento es inadecuado o si el progreso es inaceptablemente pobre.

   

7. Test Manager El rol encargado de prueba es el tasked con la responsabilidad total del éxito del esfuerzo de la prueba. El papel implica defensa de la calidad y de la prueba, el planeamiento y la gerencia del recurso, y la resolución de las ediciones que impiden el esfuerzo de la prueba. Esto cubre:
   • Negociar el propósito y los entragables en curso de las prueba de estres.
   • Asegurar el planeamiento y la gerencia apropiados de los recursos de la prueba.
   • Determinar el progreso y la eficacia de la prueba de estres.
   • Abogar el nivel apropiado de calidad para la resolución de defectos importantes.
   • Abogar un nivel apropiado de pruebas enfocado en el proceso de desarrollo del software.

     

Listo entonces, con esto ya casi hemos visto todos los roles de RUP, aunque como ya se habrán dado cuenta aún faltan algunos genéricos, pero eso los pondré en el siguiente post sobre este tema de Roles en RUP.

Saludos.

Siguiendo con la secuencia de roles en RUP, ahora toca ver el rol Tester, este rol es más sencillo de describir porque es único y tiene la responsabilidad de ejecutar las pruebas unitarias y de integración del software que se esta desarrollando.

A diferencia de los otros roles vistos, como el del analista o el del desarrollador, en este caso hay un único rol, pero no esta solo, apoyan al tester otro roles que se han comentado y/o se irán comentando conforme avancemos.

El rol Tester es responsable de las actividades básicas de ejecución de pruebas, que implica el conducir las pruebas necesarias y el registrar los resultados de aquello que prueba. Esto cubre:

• Identificar la implementación más apropiada para una prueba efectuada.
• Implementar pruebas individuales.
• Crear y ejecutar las pruebas.
• Registrar los resultados verificar la ejecución de la prueba.
• Analizar y recuperar errores de ejecución.

Saludos.

Los roles para el Desarrollador son:

1. Capsule Designer El rol Diseñador de Cápsula centra su atención en asegurar que el Sistema pueda responder a los eventos de una manera oportuna de acuerdo a los requerimientos. El principal vehículo para solucionar estos problemas es el artefacto Cápsula (Una cápsula es un patrón de diseño específico que representa un hilo de control encapsulado en el sistema).

   

2. Code Reviewer El rol revisor de código asegura la calidad del código fuente y planea y conduce revisiones de código fuente. El revisor de código es responsable de cualquier feedback de la revisión realizada.

   

3. Database Designer El rol Diseñador de Base de Datos define las tablas, indices, vistas, constraints, triggers y otros objetos específicos de la base de datos necesarios para almacenar, recuperar y eliminar objetos persistentes.

   

4. Implementer El rol Implementador es responsable de desarrollar y de probar componentes de acuerdo con los estándares adoptados del proyecto para la integración en subsistemas más grandes. Cuando los componentes de prueba, tales como drivers o partes se deben crear para apoyar la prueba, el implementador es también responsable de desarrollar y de probar los componentes de prueba y los subsistemas correspondientes.

   

5. Integrator Los implementadores entregan sus componentes probados dentro de un espacio de trabajo de integración, mientras que los integradores los combinan para producir una estructura. Un integrador es también responsable de planear la integración, que ocurre en los niveles del subsistema y de sistema con cada uno teniendo un espacio de trabajo separado de integración. Los componentes probados son entregados desde un espacio de trabajo privado de desarrollo dentro de un espacio de trabajo de integración del subsistema, mientras que la implementación de los subsistemas integrados se entregan del espacio de trabajo de integración del subsistema hacia el espacio de trabajo de la integración del sistema.

   

6. Software Architect El rol Arquitecto de Software conduce y coordina las actividades y los artefactos técnicos a través del proyecto. El Arquitecto de Software establece la estructura total para cada visión arquitectónica: la descomposición de la vista, la agrupación de elementos, y las interfaces entre agrupaciones mayores. Por lo tanto, en contraste con otros roles, la visión del Arquitecto de Software es mas amplia en comparación con otras.

   

7. Architecture Reviewer El rol Revisor de la Arquitectura planea y conduce las revisiones formales de la arquitectura del software en general.

   

8. Design Reviewer El rol revisor de diseño planea y conduce las revisiones formales del artefacto: Modelo de diseño.

   

9. Designer El rol Diseñador define las responsabilidades, las operaciones, los atributos, y las relaciones de una o varias clases y determina cómo serán ajustadas al ambiente de implementación. Además, el rol diseñador puede tener la responsabilidad de unos o más paquetes de diseño, o de diseño del subsistemas, incluyendo cualquiera contenido por los paquetes o los subsistemas.

   

10. Test Designer El rol diseñador de pruebas es responsable de definir el test de acercamiento y asegurar su implementación satisfactoria. El rol implica el identificar las técnicas apropiadas, herramientas y pautas para implementar las pruebas requeridas, y para dar las guias en los correspondientes requisitos de recursos para el esfuerzo de la prueba. Este papel también se refiere a veces como el Arquitecto de Pruebas, el Arquitecto de Automatización de Pruebas o Especialista de Automatización de Prueba. Este rol es responsable de:
    • Identificar y describir las técnicas de prueba apropiadas.
    • Identificar los instrumentos de apoyo apropiados.
    • Definir y mantener una arquitectura de automatización de pruebas.
    • Especificar y verificar las configuraciones requeridas del ambiente de prueba.
    • Verificar y determinar el acercamiento de la prueba.

    

Espero que esta segunda parte les ayude acomprender mejor el tema de RUP. Ojalá no demore demasiado para postear los siguientes roles.

Saludos.

Blogalaxia Tags: RUP Metodologías Software Desarrolladores

En estos días estaré posteando los demás roles ya que primero debo traducirlos porque todo esta en inglés, así mismo lo haré acompañado de las imágenes correspondientes.

Saludos.

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.

Esta es una definición tomada de Wikipedia que explica muy bien el sentido de RUP, esta metodología es bastante mencionada pero muy poco utilizada por el desconocimiento acerca del tema. Como se lee, RUP es adpatable al contexto y necesidades de cada organización, y eso es lo bueno ya que seguirla fielmente resultaría en un trabajo bastante engorroso.

Lo que pretendo es hacer una descripción de RUP basándome en la plantilla de la propia Rational, empezaré definiendo los roles para entender un poco más esta metodología.

¿Que es un Rol? Un rol es una definición abstracta de un conjunto de actividades realizadas y de artefactos obtenidos. Los roles son realizados típicamente por un individuo, o un conjunto de individuos, trabajando juntos en equipo. Un miembro del equipo de proyecto cumple normalmente muchos roles. Los roles no son individuos; en lugar de ello, describen cómo los individuos se comportan en el negocio y qué responsabilidades tienen estos individuos.

Hace un tiempo pregunte a una persona: ¿que metodología usas para tu desarrollo?, me respondió sin dudar: RUP, cuando le pregunté: ¿Con qué rol de RUP te identificas? me dijo: como Analista… y cual de los roles del analista pregunte inocentemente yo, como analista, me dijo. Si bien es cierto los roles conocidos son Analysts, Developers, Testers y Managers hay que considerar que dentro de estos roles genéricos existen otros roles que son más específicos.

A continuación les mostraré los roles específicos dentro del rol Analista haciendo una descripción de cada uno de ellos:

1. System Analyst Conduce y coordina los requerimientos y los Casos de Uso modelando y delimitando la funcionalidad del sistema y delimitando el sistema; por ejemplo, estableciendo que actores y casos de uso existen y como interactúan.

   

2. Business Designer El diseñador del negocio detalla la especificación de una parte de la organización describiendo el flujo de trabajo (Workflow) de uno o varios casos de uso del negocio. Este rol especifica los trabajadores del negocio y las entidades de negocio necesarios para realizar un caso de uso del negocio y distribuye el comportamiento del caso de uso del negocio a éstos. El diseñador del negocio define las responsabilidades, las operaciones, las cualidades, y las relaciones de uno o varios trabajadores del negocio y entidades de negocio.

   

3. Business-Model Reviewer El revisor del modelo de negocio participa en las revisiones formales del modelo del caso de uso del negocio y del modelo del objeto del negocio.

   

4. Business-Process Analyst El analista del proceso de negocio conduce y coordina el caso de uso del negocio que modela contorneando y delimitando la organización que es modelada; por ejemplo, el establecer que actores del negocio y casos de uso del negocio existen y como trabajan entre ellos. El analista del proceso de negocio es responsable de la arquitectura del negocio.

   

5. Requirements Reviewer El revisor de los requisitos planea y conduce la revisión formal del modelo del caso de uso.

   

6. Requirements Specifier El especificador de requerimientos detalla la especificación de una parte de la funcionalidad del sistema describiendo el aspecto de los requisitos de uno o varios casos de uso y otros requisitos de soporte del software. El especificador de requerimientos puede también ser responsable de un paquete casos de uso, y mantiene la integridad de ese paquete. Se recomienda que el especificador de los requisitos responsable de un paquete de casos de uso sea también responsable de sus casos de uso y actores contenidos.

   

7. Test Analyst El rol analista de pruebas es responsable inicialmente de identificar y posteriormente de definir las pruebas requeridas, de supervisar la cobertura de la prueba y de evaluar la calidad total experimentada al probar los elementos de prueba. Este papel también implica el especificar los datos de prueba requeridos y el evaluar el resultado de la prueba conducida en cada ciclo de la prueba. Este papel también se refiere a veces como el diseñador de prueba o considerado parte del rol Tester. Este rol es responsable de:
   • Identificar los elementos de prueba que se evaluarán por el esfuerzo de la prueba.
   • Definir las pruebas apropiadas requeridas y cualquier dato de prueba asociado.
   • Recopilar y manejar los datos de prueba.
   • Evaluar el resultado de cada ciclo de prueba.

   

8. User-Interface Designer El diseñador de la interfaz de usuario conduce y coordina los prototipos y el diseño de la interfaz de usuario, por ejemplo:
   • Capturando requerimientos de la interfaz de usuario, incluyendo requerimientos de usabilidad.
   • Construyendo prototipos de Interfaces de usuario.
   • Implicando a otros stakeholders acerca de la IU, tales como usuarios finales, en revisiones de la utilidad y sesiones de prueba de uso.
   • Repasando y proporcionando el feedback apropiado en la implementación final de la IU, según lo creado por otros desarrolladores; es decir, diseñadores e implementadores.

   

Espero que esta primera entrega les ayude a entender mejor estos roles, sería muy complicado dar la descripción completa de RUP, de manera que lo haré de a pocos en una próxima oportunidad daré la descripción del rol Developers luego de Testers y así sucesivamente.

Saludos.

Blogalaxia Tags: RUP Metodologías Software Analistas