Casos de uso y descomposición funcional

Imaginemos que estamos capturando requerimientos para una página web que tiene que incluir un foro. Hablamos con el usuario líder, y nos cuenta que es necesario que  el administrador del sistema esté en capacidad de bloquear el acceso a los usuarios que repetidamente muestren un comportamiento inadecuado en el foro (escriban en mayúsculas, resuciten threads antiguos, utilicen palabras malsonantes y otras exquisiteces de los foristas). Después de la entrevista vamos a nuestra oficina, iniciamos nuestra herramienta CASE y aplicamos la técnica de casos de uso según lo que nos enseñaron en la universidad para producir este diagrama:

Diagrama construido con StarUML

Esta primera versión tiene algunos inconvenientes. Por definición, un caso de uso debe producir valor para los actores con los que interactúa (según Kurt Bittner) y no creo que el Administrador encuentre mucho valor a la tarea de "Buscar Usuarios" o de "Mostrar Información de Usuario". A menos que se trate de reportes -y no es el caso- el Administrador del Foro no va a entrar a nuestra aplicación sólamente a realizar una búsqueda o a consultar información de un usuario, sino lo que desea es estar en capacidad de bloquear a los usuarios rebeldes. Por ahí ya tenemos problemas.

Ahora, tal vez nuestra intención inicial de agregar tantos casos era para poner en evidencia que para bloquear a un usuario es necesario primero buscarlo, luego mostrar un formulario con su información básica, después  ingresar los motivos por los que se le va a bloquear para finalmente realizar el bloqueo. Si ese fue el caso caimos en otro error, dado que los casos de uso no "invocan" a otros casos de uso y mucho menos se comunican entre ellos. Realizar esto es intentar convertir los casos de uso en funciones, lo que nos lleva al problema de la descomposición funcional: Descomponer un problema en partes pequeñas y aisladas entre sí, que trabajando juntas nos proveen de una funcionalidad del sistema.

La descomposición funcional de casos de uso hace que estos pierdan contexto, como el caso de uso "Asignar motivos de bloqueo" que no tiene sentido sin el resto de casos de uso del diagrama. También está el tema del valor para los actores que mencionábamos al inicio, el  mismo caso de uso "Asignar motivos de bloqueo" no le va a servir al Administrador si es que el usuario al final no termina bloqueado.

Ahora ¿qué hacemos para no caer en esto?. Navegando me topé con un documento de Kurt Bittner en el que nos sugiere tres cosas:

1. Centrarse en casos de uso que provean valor real a los stakeholders. En el caso de nuestra administrador, buscando usuarios no gana mucho.
2. Limitar el uso de "includes" sólamente para representar descripciones comunes entre caso de uso. Y usarlas con muchísimo cuidado.
3. Limitar el uso de "extends" sólamente para agregar comportamientos opcionales a casos de uso existentes que por si mismos generen valor. Personalmente, no me gusta mucho utilizar esta relación.

Entonces, sabiendo esto borramos nuestro primer borrador defectuoso y lo cambiamos por este mucho más simple y elegante:

Este diagrama también lo hice con StarUML

En la especificación de caso de uso ya podemos explayarnos describiendo el flujo deseado.  Recuerden que un modelo de casos de uso es principal y mayoritariamente texto. Eso sería todo en esta entrega, hasta otra!

Leer más

Recetario IBM 669

Hace unas semanas obtuve la certificación SOA de IBM de SOA, así que ahora puedo poner en el resumé que soy IBM Certified SOA Associate. En realidad, no creo que la forma en la que me preparé sea un ejemplo a seguir -por eso la demora en el post- pero igual la comentaré para que sirva de referencia a la gente que se lo quiera tomar más en serio.

Comenzó Marzo y con él la temporada de certificaciones gratuitas en la empresa en la que trabajo. En esos días andaba bastante ocupado con un software en producción bastante problemático, por lo que si quería certificarme tenía que ser en algo que no me demande demasiado tiempo (de preferencia, algo que ya conozca xD). Opté por la de SOA porque mis fundamentos de Web Services están bastante sólidos -modestia aparte xD- y un par de compañeros ya tenían la certificación así que podrían facilitarme orientación y material. Programé la certificación para fin de mes porque parecía un tiempo razonable.

Como siempre, revisé lo que la gente de Javaranch recomendaba para la certificación. Muchos coincidían en que SOA for Dummies de Judith Hurwitz era un buen punto de partida, así que me conseguí el libro y lo revisaba cuando podía. Como todo libro For Dummies, era bastante didáctico, elemental y bastante bueno para un novicio como yo. Encontrándome ya por el capítulo 10 caí en la cuenta que ya faltaban dos semanas para el día D por lo que necesitaba enfocarme más en el examen y en los temas en los que me iban a evaluar (el libro de Hurwitz es bastante amplio, y no contiene exactamente lo que IBM evalúa). Recurrí nuevamente a JavaRanch donde me recomendaron SOA Fundamentals in a Nutshell, un documento IBM de 34 páginas especialmente orientado a la certificación. Lo leí completo, con lo que tuve una mejor idea de qué es lo que IBM espera que uno sepa.

Revisé también la web del examen y me percaté que aún me quedaban muchos objetivos por cubrir. Entonces, era necesario revisar las lecturas que IBM sugería. El listado era inmenso, e incluye Redbooks, artículos de DeveloperWorks y cursos en línea. Dado que no disponía de mucho tiempo -ni ganas, que el tema de SOA no me emociona mucho- revisé solamente esto:

• Best Practices for SOA Management (Capítulos 1 - 3)
• Understanding SOA Security Design and Implementation (Capítulo 1)
• WebSphere Service Registry and Repository Handbook (Capítulo 1)

Ya con esto me quedó más claro que es lo que IBM entiende por SOA. Ahora que ya tenía más confianza me puse a buscar mocks para hacerme una idea de cómo era el examen (y desistir si es que estaba muy difícil xD). Una vez más por Javaranch me topé con un grupo Yahoo de prepaparación para el examen SOA, donde estaban colgadas algunas preguntas de ejemplo. La mayoría de preguntas eran "de opinión" y a mi parecer eran bastante relativas; por ejemplo "¿Porqué la característa X es importante?" o "¿Cúales son los beneficios de utilizar Y?". En los documentos que había leído no se encontraban exactamente estas definiciones, pero tenía ya el suficiente conocimiento para hacerme una idea y responder a estas preguntas de acuerdo a mi criterio. Para sorpresa mía, parecía que mi criterio coincidía con el de IBM xD.

El 31 de Marzo me acerqué a New Horizons a dar mi examen. Como ya me habían anticipado los mocks, las preguntas "de opinión" eran mayoría, y las respondí con lo que me dictaba el sentido común. Las preguntas técnicas fueron poquísimas, y casi en su totalidad eran sobre temas de Web Services. Terminé el examen, y en el reporte de Prometric decía que había aprobado.

Eso sería todo. Espero les sea de utilidad.

Hasta otra!

Leer más

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!

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más

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

Leer más