Recetario IBM 839

Este es otro post de Recetario, por lo que podrán inferir que ya obtuve la certificación IBM Certified Solution Designer - IBM Rational Unified Process V7.0. Una vez más, procedo a contarles lo que tuve que hacer para tener este diploma en mi colección.

Si es que son asiduos del blog ya sabrán que venía de obtener la IBM Certified Solution Designer - Object Oriented Analysis and Design, vUML 2 y me encontraba en búsqueda de otra certificación con orientación a Ingeniería de Software y no tanto a Programación. Había pensado en un momento en la Certified ScrumMaster, pero para obtenerla es requisito haber asistido a un curso -bastante caro- antes de poder de dar el examen; así que mejor opté por la muy accesible certificación RUP de IBM: Un sólo examen y sin pre-requisitos.

Había visto un poco de RUP en la universidad, pero eso fue hace muchos años y mi memoria es bastante frágil, así que el primer paso era conseguirme un libro que refresque esos conocimientos que creía ya perdidos. Buceando en Amazon me topé con The Rational Unified Process: An Introduction de Philippe Kruchten, que viene a ser una guía para principiantes -o para jefes de proyecto, según se vea xD- del proceso RUP. Me leí hasta la última página del libro, y creyéndome ya un Dios en RUP me dispuse a probar suerte con los mocks de Elite Certify, solamente para fracasar y darme cuenta que aún faltaba mucho por leer.

Probando con los mocks me di cuenta que el contenido de las disciplinas de RUP (o sea, lo que había visto en la universidad y lo que había leído en el libro de Kruchten) es sólamente una pequeña parte del examen, y que más de la mitad del mismo trata sobre elementos del proceso y de temas de desarrollo iterativo. Recurrí entonces al material del curso IBM Essentials of the Rational Unified Process V7.0, que ya trataba más a detalle el desarrollo iterativo y los work products del proceso pero aún obviaba los elementos del método y del proceso, por lo que seguía reprobando los mocks que intentaba resolver.

La solución una vez más vino de los amigos de Javaranch. Un forista que ya había obtenido la certificación recomendaba la web de Hans Admiraal, así que de curioso fui a echarle una ojeada. Hans es un consultor especializado en RUP, y ofrece entrenamiento -lógicamente a un costo- para poder obtener la certificación que estaba buscando. Como "bonus track", Hans a colocado también un documento PDF donde indica que contenidos del Rational Method Composer había que revisar para cubrir todos los temas de la certificación. Yo tenía instalado el RMC desde que me encontraba estudiando para el IBM 833-834, por lo que grande fue mi sorpresa al descubrir que TODOS los temas de la certificación estaban descritos ahí, y a detalle. Seguí al pie de la letra los consejos de Hans y leí lo que él indicó, gracias a eso ya no tuve problemas con los mocks.

Sintiéndome bastante confiado, fui a decirle a la gente de mi trabajo que quería dar la certificación, que me encontraba listo y que esperaba que al tratarse de un partner de IBM me pagasen el examen - como había ocurrido con los exámenes 833 y 834. Contra todo pronóstico, me dijeron que esta vez no podían afrontar el gasto, y que si quería certificarme los 240$ (200$ del examen y 40$ de gastos administrativos de New Horizons) tendrían que salir de mi bolsillo. Habiéndole dedicado ya tanto tiempo a la certificación, no me quedó otra que aceptar, así que este fin de mes mi salario estará más chiquito que de costumbre.

Programé el examen para el martes pasado, me acerqué a las instalaciones de New Horizons para dar el examen y lo aprobé con una calificación que me deja satisfecho. Ahora pienso tomarme otro descanso, y probablemente al certificación que venga sea la IBM Certified SOA Associate, aunque ahora que no es gratis no estoy tan seguro. ¡Hasta otra!

Demostrar valor iterativamente

(Imagen: El Greco - Visión del Apocalipsis)

Este principio explica los beneficios del desarrollo iterativo de software. Un proceso iterativo hace posible acomodarse al cambio, obtener retroalimentación y adaptarla al proyecto, reducir riesgos de manera temprana y ajustar el proceso dinámicamente.

Beneficios
  • Reducción temprana del riesgo
  • Mayor capacidad de predicción a lo largo del proyecto.
  • Confianza entre los stakeholders
Patrón
  1. Permitir retroalimentación al incrementar el valor para el usuario en cada iteración
  2. Adaptar los planes usando un proceso iterativo
  3. Aceptar el cambio y administrarlo
  4. Atacar los mayores riesgos técnicos, de negocio y de programación tempranamente.
Anti-patrones
  • Planear todo el ciclo de vida a detalle, controlar las variaciones respecto al plan (esto puede contribuir al fracaso del proyecto)
  • Evaluar el estado en los primeros dos tercios del proyecto confiando en la revisión de especificaciones, en vez de evaluar el estatus de resultados de pruebas y demostraciones de software funcionando.
Basado en el navegador de proceso del IBM Rational Method Composer

Colaboración entre equipos

(Imagen: El Greco - La Sagrada Trinidad)

Este principio resalta la importancia de promover uno óptima comunicación entre miembros del proyecto. Esto se logra a través de una organización del equipo apropiada y configurando entornos de colaboración efectivos.

Beneficios
  • Productividad del equipo
  • Mejor acoplamiento entre las necesidades del negocio y el desarrollo y operaciones de los sistemas software.
Patrón:
  1. Motivar a la gente para que realice su mejor esfuerzo
  2. Crear equipos auto-administrados
  3. Promover la colaboración horizontal entre funciones (como analistas, desarrolladores, testers)
  4. Proveer entornos de colaboración efectivos.
  5. Integrar a los equipos de negocios, software y de operación.
Anti-patrones
  • Explotar a los desarrolladores, haciéndolos trabajar largas jornadas, incluyendo fines de semana
  • Tener gente altamente especializada equipada con las mejores herramientas para realizar su trabajo, con colaboración limitada entre miembros del equipo e integración limitada entre sus herramientas. Se asumo que si cada uno realiza bien su trabajo el resultado será bueno.
Basado en el navegador de proceso del IBM Rational Method Composer

Disciplina: Requerimientos

(Imagen: El Greco - Vista de Toledo)

Propósito
  • Establecer y mantener acuerdos entre los clientes y otros stakeholders sobre lo que el sistema debe hacer
  • Proveer a los desarrolladores del sistema de un mejor entendimiento de los requerimientos del sistema.
  • Definir los límites del sistema
  • Proveer las bases para planificar el contenido técnico de cada iteración
  • Proveer las bases para estimar el costo y el tiempo del desarrollo del sistema.
  • Desarrollar una interfaz de usuario para el sistema, centrándose en las necesidades y objetivos de los usuarios.
Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Disciplina: Modelamiento del Negocio

(Imagen: Diapostitivas del curso de IBM)

Propósito:
  • Comprender los problemas de la organización objetivo e identificar oportunidades de mejora.
  • Asegurarse que los clientes y los usuarios finales tengan una comprensión similar de la organización objetivo.
  • Obtener requerimientos del sistema para dar soporte a la organización objetivo.
  • Comprender la estructura y la dinámica de la organización en donde se va a desplegar el sistema.

Esta disciplina usa un enfoque similar al de desarrollo de sistemas.

El modelamiento de negocio sirve de entrada a la disciplina de Requerimientos, dado que los modelos de caso de uso del negocio ayudan a comprender los requerimientos del sistema e identificar casos de uso del sistema. Sirve también de entrada a la disciplina de análisis y diseño, ya que las entidades de negocio del modelo de análisis del negocio ayudan a identificar clases entidad del modelo de análisis

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Balancear las prioridades de stakeholders

(Imagen: El Greco - El expolio)

Este principio hace énfasis en la importancia de balancear las necesidades de los stakeholders y del negocio, así como balancear el desarrollo a medida con la reutilización de activos para satisfacer estas necesidades.

Beneficios
  • Alinear las aplicaciones con las necesidades del usuario y del negocio
  • Reducir el desarrollo a medida
  • Optimizar el valor de negocio
Patrón
  • Definir, comprender y priorizar las necesidades del negocio y de los usuarios.
  • Priorizar los proyectos y requerimientos y relacionarlos con capacidades de software
  • Comprender que activos podemos aprovechar
  • Balancear la reutilización de activos con las necesidades del negocios.
Anti-patrones
  • Negociar cualquier cambio en los requerimientos, donde cada cambio puede incrementar el costo y duración del proyecto.
  • Desarrollar principalmente desarrollo a medida
  • Realizar la arquitectura del sistema para satisfacer solamente las necesidades de los stakeholders más importantes.
Basado en el navegador de proceso del IBM Rational Method Composer

Rol

(Imagen: Diapostitivas del curso de IBM)

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando como equipo. Dentro de un equipo, cada miembro puede desempeñar más de un rol, y un rol puede ser desempeñado por más de un miembro.

Los roles tienen un grupo cohesivo de actividades que realizan. Estas actividades están bastante relacionadas y acopladas funcionalmente. Las actividades son cohesivas en el sentido que se desarrollan mejor si son completadas por una sóla persona. Sin embargo, es posible que un rol sea desempeñado por más de un integrante del equipo, en cuyo caso ese grupo de personas sería responsable de las actividades y artefactos relacionados. También es posible que un miembro del equipo se desenvuelva en más de un rol.

Al desarrollar el plan de proyecto, el jefe de proyecto asigna roles a los individuos de acuerdo a sus habilidades. El jefe de proyecto asigna a cada individuo del proyecto uno o más roles. La asociación de individuos a roles es dinámica y varía en el tiempo.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Disciplina: Entorno

(Imagen tomada de The Rational Unified Process: An Introduction de Philippe Kruchten )

Propósito: Se centra en las actividades necesarias para configurar el proceso para un proyecto. Define que mejoras son realistas bajo las circunstancias del proyecto:
  • Procesos actuales
  • Herramientas actuales
  • Habilidades actuales del personal y capacidad de cambio
  • Problemas actuales y objetivos posibles de mejora.
La disciplina de entorno da soporte a la organización de desarrollo con procesos y herramientas. Muchas de las tareas dentro del proceso se pueden beneficiar con el uso de herramientas. Estas herramientas pueden ser usadas para modelamiento, pruebas, gestión de requerimientos, programación, planeamiento y control. Algunas herramientas pueden ser desarrolladas internamente.

La configuración del proceso implica adaptar el proceso a las necesidades de la organización de desarrollo. RUP es un framework que debe ser modificado para una organización.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Tipos de Requerimientos

(Imagen tomada de The Rational Unified Process: An Introduction de Philippe Kruchten )
  • Características: Usadas para definir el alcance del proyecto
  1. Audiencia principal: Stakeholders
  2. Documentados en el artefacto de visión
  • Requerimientos funcionales: Especifican interacciones con los usuarios del sistema.
  1. Audiencia principal: Usuarios y el equipo del proyecto
  2. Modelados en el artefacto de Modelo de Casos de Uso
  • Especificación suplementaria: Especifica requerimientos de funcionalidad, usabilidad, confianza, rendimiento y restricciones de diseño
  1. Audiencia principal: Arquitectos y diseñadores
  2. Documentados en el artefacto de Especificaciones suplementarias

La disciplina de requerimientos describe como crear una visión y transformarla en un modelo de casos de uso. Junto a las especificaciones suplementarias, los casos de uso definen los requisitos del sistema.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Disciplina: Despliegue


(Imagen: Diapostitivas del curso de IBM)

Propósito:
Administrar las actividades relacionadas con asegurar que el producto software se encuentre disponible para los los usuarios finales. Así:
  • Despiegue del producto: Se debe producir una unidad de despligue (ejecutable, documentación e instalación) que está lo suficientemente completa como para ser descargable y ejecutable desde un nodo
  • Pruebas en los sitios de instalación y de destino.
  • Pruebas Beta: Implementar una versión beta y solicitar opiniones del producto a desarrollar de un grupo particular de usuarios
  • Crear material de soporte para el usuario final.
  • Crear material de entrenamiento para el usuario
  • Entrega al usuario (de forma empaquetada, desde un sitio de descarga, etc.): Se debe tomar la unidad de despliegue, los scripts de instalación y los manuales de usuario y empaquetarlos para producción masiva. También se debe habilitar la compra o descarga del producto por internet, o como un producto empaquetado.
Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Disciplina: Gestión de configuración y cambio

(Imagen: Diapostitivas del curso de IBM)
  • Gestión de Pedidos de Cambio (CRM): Busca la infraestructura organizacional requerida para evaluar los costos, cronograma e impacto de una solicitud de cambio para el producto existente. La gestión de solicitudes de cambio tiene que ver con el Equipo de Revisión de Cambios y el Comité de Control de Cambios.
  • Medición: Se utilizan para describir el estado del producto basados en el número, nivel y severidad de los defectos encontrados, y arreglados, durante el transcurso del desarrollo del producto. Las mediciones son útiles para determinar el nivel de avance del proyecto.
  • Gestión de Configuración (CM): Describe la estructura del producto e identifica los elementos de configuración que lo constituyen, que son tratados como entidades versionables en el proceso de gestión de la configuración. La CM se encarga de definir configuraciones, construyendo, etiquetando y recolectando artefactos versionados en grupos constituidos manteniendo la trazabilidad entre versiones.
Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Adaptar el proceso

(Imagen: Navegador de proceso del IBM Rational Method Composer )

Este principio indica que es crítico el ajustar el proceso de desarrollo a las necesidades del proyecto. Más no es mejor, menos no es mejor: Por el contrario, la cantidad de ceremonia, precisión y control presente en un proyecto debe ajustarse de acuerdo a una variedad de factores incluyendo el tamaño y distribución de los equipos, la cantidad de restricciones externas y la fase en la que se encuentra el proyecto.

Beneficios:
  • Eficiencia en el ciclo de vida
  • Incremento en la agilidad del proyecto
  • Planes y estimaciones realistas
Patrón:
  1. Ajustar el proceso a las necesidades del proyeto incluyendo: el tamaño y distribución del equipo del proyecto, la complejidad de la aplicación, la necesidad de conformidad
  2. Adaptar la ceremonia del proceso a cada fase del ciclo de vida (permitir que el formalismo evolucione de ligero a pesado según se resuelvan las incertidumbres)
  3. Mejorar el proceso continuamente
  4. Balancear los planes y estimaciones con cierto nivel de incertidumbre.

Anti-patrones
  • Siempre pensar que más proceso y más planeamiento es mejor
  • Forzar a estimar temprano, y a seguir estos estimados
  • Desarrollar planes precisos y a manejar el proyecto siguiendo estos planes estáticos.
Basado en el navegador de proceso del IBM Rational Method Composer

Elevar el nivel de abstracción

(Imagen: Navegador de proceso del IBM Rational Method Composer )

La complejidad es un tema central en el desarrollo de software. El elevar el nivel de abstracción ayuda a reducir la complejidad así como la cantidad de documentación requerida por el proyecto. Esto puede lograrse a través de reutilización, del uso de herramientas de modelamiento de alto nivel, y estabilizando la arquitectura tempranamente.

Beneficios
  • Productividad
  • Reducción de la complejidad
Patrón
  • Reusar activos ya existentes
  • Usar herramientas y lenguajes de alto nivel para reducir la cantidad de documentación.
  • Enfocarse primero en la arquitectura
  • Realizar la arquitectura pensando en resiliencia, calidad, simplicidad y control de la complejidad.
Anti - patrones
  • Ir directamente de requerimientos vagos de alto nivel a código hecho a mano:
  • Dado que se utilizan pocas abstracciones, existen conflictos entre el nivel de código y el nivel conceptual, por lo que se pierden oportunidades de reutilización
  • La captura informal de requerimientos y de otra información hace necesario el revisar las especificaciones continuamente.
  • Si se hace poco énfasis en la arquitectura se incurrirá en retrabajos en el futuro.
Basado en el navegador de proceso del IBM Rational Method Composer

Hacer énfasis continuamente en la calidad

(Imagen: Navegador de proceso del IBM Rational Method Composer )

Este principio enfatiza que, para lograr la calidad, esta debe buscarse a lo largo de todo el ciclo de vida del proyecto. Un proceso iterativo esta adaptado para lograr la calidad desde que ofrece muchas oportunidades de medición y de corrección de errores.

Beneficios:
  • Elevada calidad
  • Entendimiento temprano del progreso y la calidad
Patrón:
  1. La calidad del producto es propiedad del equipo
  2. Probar temprano y continuamente con integración de capacidades demostrables
  3. Contruir pruebas automatizadas incrementalmente
Anti-patrón:
  • Revisar todos los artefactos y completar todas las pruebas unitarias antes de las pruebas de integración
  • Realizar pruebas exhaustivas a artefactos intermedios, lo que es contra producente debido a que demora las pruebas de aplicación y la identificación de incidencias mayores.
Basado en el navegador de proceso del IBM Rational Method Composer

Tarea

(Imagen: El Greco - Entierro del Conde de Orgaz)

Una tarea describe una unidad de trabajo. Cada tarea es desarrollada por roles específicos. La granularidad de una tarea es de generalmente unas horas o de algunos días. Por lo general afecta pocos productos de trabajo, o sólo uno. Las tareas no se utilizan como bases para el planeamiento o control del progreso - son muy a detalle para ese fin; por esto se agrupan las tareas en actividades como unidades de planeamiento y control.

Una tarea posee un propósito claro, usualmente en términos de crear o actualizar algunos productos de trabajo, como modelos, clases o planes. Dentro de cada tarea, cada rol debe lograr un objetivo bien definido. Una tarea provee una explicación paso a paso del trabajo requerido para lograr el objetivo. Esta descripción es completa, independiente del momento en el ciclo de vida en el que se realizará el trabajo.

Basado en el navegador de proceso del IBM Rational Method Composer

Descriptor

(Imagen: Navegador de proceso del IBM Rational Method Composer )

Un descriptor representa una ocurrencia de un elemento de contenido concreto (como una tarea, un rol o un producto de trabajo) en una actividad. Los descriptores proveen una representación de estos elementos de contenido dentro de una estructura de despliegue. Además de sólo hacer referencia a los elementos de contenido, también nos permite sobreescribir las relaciones estrcturales de los elementos de contenidos al definir su propio grupo de asociaciones.

Los descriptores son un concepto clave para realizar la separación entre procesos y contenido del método. Un descriptor puede representarse como una referencia para un elemento de contenido en particular, que posee sus propias relaciones y propiedades. Cuando se crea un descriptor, posee las mismas relaciones que el elemento de contenido al que hace referencia. Sin embargo, los usuarios pueden modificar estas relaciones para la situación especial para la que se ha creado el descriptor. El concepto de descriptor nos permite definir nuevas relacionesy especificar nuevas propiedades- Los descriptores no son elementos de contenido y no contienen descripciones propias completas. Ellos hacen referencia al elemento de contenido en el que se basaron.

Basado en el navegador de proceso del IBM Rational Method Composer

Producto de Trabajo


(Imagen: Navegador de proceso del IBM Rational Method Composer )

Un Producto de Trabajo es una abstracción general que representa el resultado de un proceso. Los Productos de Trabajo incluyen:
  • Artefactos
  • Entregables
  • Resultados
Las tareas poseen producto de trabajo de entrada y de salida. Los roles utilizan productos de trabajo para realizar tareas, y generar otros productos de trabajo al realizar estas tareas. Los productos de trabajo son de responsabilidad de un solo rol, de modo que las responsabilidades sean fáciles de identificar y comprender, y para promover la idea de que cada pieza de información del proceso requiere un conjunto de habilidades apropiado. Aunque un rol puede poseer un producto de trabajo, otros roles pueden usar ese producto de trabajo, para actualizarlo o para otros fines.

Basado en el navegador de proceso del IBM Rational Method Composer

Gestión de Proyectos: Trabajadores y Artefactos

(Imagen tomada de The Rational Unified Process: An Introduction de Philippe Kruchten )

La figura que acompaña al post muestra al trabajador principal del flujo de trabajo de gestión de proyectos, el jefe de proyecto, y los artefactos del flujo. En la figura no se muestra al revisor del proyecto, que es responsable de evaluar los artefactos de planeamiento y evaluación del proyecto, en los principales puntos de evaluación del ciclo de vida del proyecto.

Los principales artefactos del flujo de trabajo de gestión del proyecto son:

  • El plan de desarrollo de software (SDP), que a su vez contiene a varios artefactos:
  1. Plan de aceptación del producto
  2. Plan de gestión de riegos (y lista de riesgos)
  3. Plan de resolución de problemas
  4. Plan de mediciones
  • Caso de negocio
  • Los planes de iteración (uno por iteración)
  • Evaluación de iteración
  • La evaluación de estado (periódica)
  • La orden de trabajo
Otros planes son también parte del SDP, pero son desarrollados por otros trabajadores. Así:
  • El plan de administración de configuración es desarrollado por el trabajador Administrador de Configuración
  • El caso de desarrollo (el proceso usado para el proyecto) es desarrollado por el trabajador Ingeniero de Procesos
Basado en The Rational Unified Process: An Introduction de Philippe Kruchten

Disciplina de Gestión de Proyectos

(Imagen: El Greco - La asunción de la virgen)

Propósito:
  • Proveer un marco de trabajo para administrar proyectos de software
  • Proveer guías prácticas para planificar, contratar recursos, ejecutar y monitorear proyectos.
  • Proveer un marco de trabajo para la gestión del riesgo
Sus artefactos principales son:
  • Plan de Proyecto: Describe las fases y los hitos principales que el proyecto debe seguir.
  • Plan de Gestión del Riesgo: Detalla como manejar los riesgos asociados al proyecto. Detalla las tareas de gestión del riesgo que deben llevarse a cabo, responsabilidades asignadas y recursos adicionales requeridos para las actividades de gestión del riesgo. Este plan está contenido dentro del Plan de Desarrollo de Software.
  • Caso de Negocio: Provee la información necesaria para determinar si vale la pena invertir en el proyecto desde una perspectiva de negocio.
  • Plan de iteración: Secuencia temporal de actividades y tareas, con recursos asigandos y con dependencias entre tareas, para una iteración. Es un plan detallado.
Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Planeamiento en Desarrollo Iterativo

(Imagen: Diapostitivas del curso de IBM)

El artefacto principal de la disciplina de Gestión de Proyectos es el Plan de Desarrollo de Software, que está compuesto por el Plan de Proyecto, el Plan de fase y el Plan de Iteración.

El plan de proyecto es un plan genérico, y existe sólamente uno por proyecto de desarrollo. Este plan sirve de envoltura del proyecto para un ciclo (y probablemente para los ciclos subsiguientes, si es que aplica).

El plan de proyecto se produce en las etapas iniciales de la fase de Inicio y se actualiza cuando se necesite.

El plan de iteración es una secuencia temporal de actividades y tareas, con recursos asignados y dependencias entre tareas para una iteración en particular. Es un plan detallado, y existe uno por iteración. Un proyecto usualmente tiene dos planes activos:
  • El plan de iteración actual (o sea, el de la iteración vigente) que es usado para monitorear el progreso
  • El plan de iteración siguiente (es decir, el de la iteración sucesora) que es construido en en el transcurso de la segunda mitad de la iteración actual, y está finalizado al terminar la iteración actual.
Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Plan de Iteración

(Imagen: Diapostitivas del curso de IBM)

Un plan de iteración está constituido por un conjunto secuencial de actividades y tareas, cada una de las cúales tiene recursos asignados y pùeden depender a su vez de otras tareas. Es un plan detallado, que se realiza una vez por iteración.

El contenido de la iteración puede variar, dependiendo de la posición dentro del ciclo de vida y de la naturaleza del proyecto. El plan de iteración incluye porciones relevantes de todas las disciplinas para cada iteración en particular. Los planes de iteración por lo general muestran un planeamiento detallado de quien va a realizar una tarea/actividad de acuerdo en conformidad a que criterios de evaluación.

Los planes de iteración durante las fases de inicio y elaboración se centran en el alcance del proyecto y en reducción de riesgos, especialmente los riesgos de arquitectura. Durante las fases de construcción y transición, hacen énfasis en eficiencia en el desarrollo y calidad del producto.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Tiempo y esfuerzo por fase

(Imagen: Diapostitivas del curso de IBM)

El perfil de la figura que acompaña el post muestra la duración y esfuerzo por fase. Es aplicable a un proyecto con las siguientes características:
  • Es de un tamaño y esfuerzo moderados
  • Se encuentra en una etapa inicial del ciclo de desarrollo
  • No tiene una arquitectura predefinida
  • Posee un número pequeño de riesgos y situaciones desconocidas
Se observa que se ha realizado una pequeña parte del gasto se ha realizado al final de la fase de elaboración, donde todos los riesgos arquitectónicos han sido removidos y el producto puede construirse con un alto grado de confianza.

Se considera a las fases de Inicio y Elaboración como la etapa de Ingeniería (donde se realiza y se afianza el descubrimiento y la invención), y las fases de Construcción y Transición como la etapa de Implementación (donde el trabajo puede proseguir bajo una base sólida).

Basado en The Rational Unified Process: An Introduction de Philippe Kruchten

Perfiles de Riesgo

(Imagen: Diapostitivas del curso de IBM)

El desarrollo iterativo produce primero la arquitectura, permitiendo que la integración funcione como un actividad de verificación y permitiendo la detección y resolución de errores de diseño en las primeras etapas del ciclo de vida.

La integración continua a través del proyecto reemplaza la integración "big bang" al final del proyecto.

El desarrollo iterativo nos provee un mejor enfoque de calidad, debido a que las características que son inherentes a la arquitectura (como performance, tolerancia a fallas, facilidad de mantenimiento) se hacen tangibles en etapas tempranas del proceso. Así, estos temas son corregibles son poner en riesgo los costos estimados ni los tiempos planificados.

Por esto se prefiere que las iteraciones iniciales ataquen a los riesgos de mayor magnitud. Asimismo, la evaluación de riesgos es un proceso continuo, dado que los riesgos cambian a través del tiempo. Esto se traduce una lista de riesgos constantemente actualizada, que sirve de entrada a la actividad de Desarrollo del Plan de Iteración.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Arquitectura ejecutable


(Imagen: Diapostitivas del curso de IBM)

Definimos como arquitectura ejecutable a una validación verificable de la arquitectura, que puede ser probada mediante casos de uso arquitectónicamente significativos. Esta arquitectura nos sirve de base para el resto del desarrollo, y a sus vez mitiga varios riesgos a futuro.

Los componentes de la arquitectura deben ser validados lo antes posible debido a que tienen un impacto importante en el desarrollo del proyecto. La validación se realiza al ejecutar (no sólamente diagramar) estos componentes, de modo que se verifiquen sus funciones arquitectónicas.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Fase de elaboración


(Imagen: El Greco - Retrato de Giorgio Giulio Clovio)

El propósito de la fase de elaboración es analizar el dominio del problema, establecer los fundamentos arquitectónicos, desarrollar el plan de proyecto y eliminar los elementos de riesgo más importantes del proyecto. Para cumplir estos objetivos, se debe tener una visión general del sistema. Las decisiones de arquitectura deben realizarse con una comprensión total del sistema: su alcance, funcionalidad principal y requerimientos no-funcionales como performance.

Los criterios de evaluación para esta fase son:
  • La visión del producto y los requerimientos están estables
  • La arquitectura está estable
  • Los mayores elementos de riesgo han sido resueltos
  • Los planes de iteración para la fase de construcción tienen el detalle suficiente para proceder a esta fase, y están en base a estimaciones creibles
  • Todos los stakeholders consideran que la visión actual puede lograrse si se sigue el plan vigente para desarrollar todo el sistema, en el contexto de la arquitectura actual.
  • Los recursos empleados versus los recursos planeados se encuentran en un nivel aceptable.
Al final de la fase de elaboración se encuentra el segundo hito importante del proyecto: el hito de arquitectura del ciclo de vida.

Basado en The Rational Unified Process: An Introduction de Philippe Kruchten

Duración de una iteración

(Imagen: El Greco - Muerte de la virgen)

Definimos una iteración como un mini-proyecto en el que se recorren todos los flujos de trabajo principales y resulta en un ejecutable -aún incompleto- del sistema. Una iteración comienza con planemamiento y requerimientos y termina con un ejecutable, ya sea interno o externo.

Una iteración idealmente debe durar de dos a seis semanas, pero esto varía de proyecto a proyecto. Que tan rápido se puede iterar depende principalmente del tamaño de la organización.

Otros factores que también influyen son: el nivel de familiaridad de la organización con el enfoque iterativo, la estabilidad y madurez de la organización, el nivel de automatización del equipo para administrar el código (como la gestión de configuración distribuida) , distribuir información (a través de una Web) y realizar pruebas. Tener en cuenta también que en una iteración se deben considerar tiempos para planeamiento, sincronización y análisis de resultados.

Basado en The Rational Unified Process: An Introduction de Philippe Kruchten

Mock: Productos del desarrollo iterativo


(Imagen: Diapostitivas del curso de IBM)

Este es el primero de una serie de posts dedicados a la certificación RUP de IBM: IBM Certified Solution Designer - IBM Rational Unified Process V7.0. Espero sea de su agrado xD.

The iteration assessment captures the following (select 3)
A) result of an iteration
B) detailed scheduling
C) degree to which evaluation criteria were met
D) lessons learned

En RUP, los los artefactos para planificar una iteración son el plan de Iteración y la Evaluación de Iteración. Estos documentos facilitan las decisiones que nos permiten reducir riesgos, aceptar el cambio y conducir el proyecto a través de cada iteración.

Después de iniciada la iteración, los equipos completan el trabajo definido en el Plan de Iteración.

Cuando el trabajo se ha terminado, se realiza la Evaluación de iteración para determinar si se cumplieron los objetivos de la iteración, usando todas las mediciones objetivas posibles. La evaluación de iteración captura el resultado de la iteración, el grado en el que se cumplieron los criterios de evaluación, las lecciones aprendidas y los cambios a realizar..En base a esta evaluación, se determina si continuar o no con el proyecto.


Si se decide continuar, se debe analizar los cambios al proyecto aprobados por el Comité de Control de Cambios (CCB por sus siglas en inglés), revisar el listado de riesgo y posiblemente modificar los objetivos del producto (requerimientos) o la especificación del mismo (arquitectura y diseño). La especificación revisada del proyecto se convierte en un nuevo objetivo y nos permite conducir el proyecto, tomando en consideración los cambios de requerimientos y del producto. En base a los objetivos modificados, se puede planear la siguiente iteración, creando un nuevo Plan de Iteración.

Por esto, seleccionamos las alternativas A, C y D.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0

Pregunta tomada del sample test para IBM 839