Category / RUP

Gestion de cambios y de la configuracion 15 Agosto 2009 at 21:53

Despues de mucho tiempo que me animo a escribir, dado que el calendario del presente año anda muy apretado. En este post, quisiera informar con respecto a la gestion de la configuracion aplicando RUP. Configuracion y gestion del cambio es una de las disciplinas del RUP, el cual realiza flujos de trabajos y tareas especificas. Esta disciplina explica cómo controlar y sincronizar la evolución del conjunto de productos de trabajo que componen un sistema de software. El control ayuda a evitar confusiones costosas y garantiza que los productos de trabajo resultantes no sean conflictivos debido a algún problema de los tipos siguientes:

Actualización simultánea

Cuando dos o más miembros del equipo trabajan por separado en el mismo producto de trabajo, el último en realizar cambios destruye el trabajo del anterior. El problema básico es que si un sistema no da soporte a las actualizaciones simultáneas ello conduce a cambios en serie y ralentiza el proceso de desarrollo. Sin embargo, con las actualizaciones simultáneas, el reto es detectar las actualizaciones que se han producido simultáneamente y resolver las cuestiones de integración cuando se incorporen estos cambios.

Notificación limitada

Cuando se resuelve un problema en los productos de trabajo compartidos por varios desarrolladores y no se notifica a algunos de ellos del cambio.

Versiones múltiples

La mayoría de programas grandes se desarrollan mediante releases evolutivos. Un release puede ser utilizado por el cliente, mientras otro se está probando y un tercero sigue todavía desarrollándose. Si se detectan problemas en alguna de las versiones, deben propagarse las soluciones entre ellas. Las confusiones pueden conducir a arreglos costosos y a trabajos de rediseño a menos que los cambios tengan un cuidadoso control y gestión.

Las lineas anteriores son una traduccion de la documentacion oficial de la metodologia RUP.

ROL: Integrador Segun Rup 12 Febrero 2009 at 19:34

Continuando con los roles de la metodologia RUP, en este post voy a escribir acerca de las funciones y tareas que tiene un Integrador.

Este rol dirige la planificación y la ejecución de la integración del elemento de implementación (funcionalidad nueva o funcionalidad modificada, talvez un simple mantenimiento) para producir compilaciones(versiones estables). Realiza las siguientes actividades:

  • Integrar el sistema (el trabajo de dos implementadores o desarrolladores por separado).
  • Integrar el subsistema.
  • Planificar la integracion del sistema (elaborar un plan en donde se encuentren las actividades y tareas a realizarse).
  • Planificar la integracion del susbsitema.

A la vez es responsable del plan de compilacion (integracion) y generar una nueva compilacion (version).

Las habilidades y conocimientos apropiados para este rol incluyen:

  • conocimiento del sistema o de parte del sistema que se integra (conocimiento a nivel de componentes de software, datos, etc). Concretamente, el integrador necesita conocer las interdependencias entre elementos de implementación y las interdependencias entre subsistemas de implementación, y cómo se espera que el desarrollo y las dependencias cambien a lo largo del tiempo .
  • familiaridad con las herramientas de integración

Los integradores deben tener buenas dotes de coordinación, ya que suelen trabajar con varios desarrolladores para garantizar una integración satisfactoria.

Roles Segun Rational Unified Process - RUP 25 Julio 2008 at 21:29

En la imagen se muestran todos los conjuntos de roles validos para Rational Unified Process. Esta recopilación de roles proporcionan una forma de agrupar los roles en unidades organizativas superiores.

roles.JPG

Estos roles son:

  • Analistas.
  • Desarrolladores.
  • Gestores.
  • Produccion y Soporte.
  • Roles Generales.
  • Verificadores.

Para conocer más de estos roles, se entraran en mas detalles en otros post bajo la cateogria RUP.

ROL: IMPLEMENTADOR SEGUN RUP 20 Julio 2008 at 0:30

Este rol desarrolla los componentes de software y efectúa las pruebas de desarrollador para la integración en subsistemas más grandes, de acuerdo con los estándares adoptados de proyecto.

Descripción Principal:

El rol del implementador es responsable de los componentes de desarrollo y de prueba, de acuerdo con los estándares aprobados por el proyecto, para la integración en subsistemas más grandes. Cuando los componentes de prueba, como controladores o fragmentos para simulación, deben crearse para dar soporte a las pruebas, el implementador también es responsable del desarrollo y las pruebas de los componentes de prueba y los subsistemas correspondientes.

Habilidades:

Las habilidades y conocimientos apropiados para el implementador incluyen:

  • Conocimiento del sistema o aplicación que se somete a prueba
  • Familiaridad con las herramientas de prueba y de automatización de prueba
  • Habilidades de programación.

Propuestas de Asignación:

A un implementador se le puede asignar la responsabilidad de implementar una parte estructural del sistema (como un subsistema de implementación o de clases), o una parte funcional del sistema, como la ejecución de casos de uso o sus características.

Es habitual que una persona actúe como implementador y diseñador, desempeñando las responsabilidades de ambos roles.

Es posible que dos personas actúen como implementador de un único componente del sistema, dividiendo las responsabilidades entre ellos o efectuando las tareas conjuntamente, como en un enfoque de programación en parejas.

ROL: ARQUITECTO DE SOFTWARE SEGUN RUP 3 Julio 2008 at 23:05

Este rol dirige el desarrollo de la arquitectura de software del sistema, que incluye la promoción y la creación de soporte para las decisiones técnicas clave que restringen el diseño global y la implementación para el proyecto

Descripción General:

El arquitecto de software tiene la responsabilidad global de dirigir las principales decisiones técnicas, expresadas como la arquitectura de software. Esto habitualmente incluye la identificación y la documentación de los aspectos arquitectonicamente significativos del sistema, que incluye las “vistas” de requisitos, diseño, implementacion y despliegue del sistema.

El arquitecto también es responsable de proporcionar el fundamento de estas decisiones, equilibrando las preocupaciones de los diferentes interesados, reduciendo los riesgos técnicos, y garantizando que las decisiones se comunican, y validan con eficacia, y que se acatan

Desde el punto de vista de la experiencia, el arquitecto de software también necesita compaginar las capacidades de Diseñador. Sin embargo, a diferencia del diseñador, el arquitecto de software:

  • tiende a ser generalista en lugar de especialista, conoce muchas tecnologías a un alto nivel en lugar de pocas tecnologías a nivel de detalle
  • toma decisiones técnicas mas amplias y, por lo tanto, un amplio conocimiento y experiencia, así como habilidades de comunicación y liderazgo, son esenciales.

Propuestas de Asignación:

Si el proyecto es suficientemente grande para garantizar un equipo de arquitectura, el objetivo es tener una buena combinación de talentos, cubriendo un amplio espectro de experiencia y compartiendo la comprensión común del proceso de ingeniería de software. El equipo de arquitectura no debe ser un comité de representantes de varios equipos, dominios o contratistas. La arquitectura de software es una función de tiempo completo, con personal dedicado permanentemente a ella.

Para proyectos mas pequeños, una única persona puede actuar como gestor de proyectos y arquitecto de software. Sin embargo, si es posible, es mejor que estos roles los realicen personas separadas, para garantizar que la presión del tiempo en un rol no provoca descuidos en el otro rol.