Certified (en Español)

Mock: Use-Case Analysis Overview

2009-09-15T12:21:00.003-05:00

(Imagen: Diapostitivas del curso de IBM)

An architect is responsible for creating an Analysis Model for a system. Which area of focus is essential for the creation of this model?

A. hardware on which the system will be deployed
B. behavior of the objects that comprise the system
C. evolution of analysis classes into design classes
D. performance requirements of the system

El modelo de análisis describe la realización de los casos de uso, y sirve como una abstracción del modelo de diseño. Contiene a las clases de análisis y sus relaciones. En caso de mantener los modelos de análisis y de diseño separados, este modelo es un artefacto del análisis de casos de uso. Caso contrario, las clases de análisis identificadas y sus relaciones se colocan en el modelo de diseño. Estas clases serán afinadas en elementos de diseño (como clases, paquetes y subsistemas) durante las actividades de diseño.

En muchos casos, el modelo de análisis solamente existe durante la duración del análisis de casos de uso. Una vez que las clases de análisis se transforman en clases/subsistemas de diseño, el modelo por lo general desaparece. El modelo de análisis resultante nos brinda una visión general de la distribución de responsabilidades y como esa distribución se traduce en colaboraciones entre clases.

Entonces, la alternativa B sería la más adecuada.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Pregunta tomada de Elite Certify

Los mandamientos del desarrollo de software

2009-12-04T17:43:00.002-05:00

Buceando en la web me topé con el artículo "Frequently Forgottenn Fundamental Facts about Software Engineering" de Robert L. Glass, en las que el autor enumera los que él considera los "teoremas" básicos a tener en cuenta al momento de construir software, y que lamentablemente parece que nadie considera. El listado que menciona lo realizó en base a su experiencia profesional y muchas de los principios que menciona han sido violentados en mi compañía, y a veces por mi persona. Paso a enumerar los que me llamaron la atención, junto a unos apuntes de mi parte:

Los buenos programadores son por lo general 30 veces mejores que los programadores mediocres. Dado esto, no se debe escatimar en los salarios de los programadores buenos, dado que siempre producen más de lo esperado

En una compañía en la que estuve, empezaron a reemplazar Analistas Programadores (gente con experiencia) por practicantes (novatos o "trainees"), bajo la excusa de reducir costos y aumentar la productividad -más programadores con menos presupuesto-. Lógicamente, un practicante demoraba 2 semanas en hacer lo que un AP podía hacer en un día, así que no creo que les haya resultado beneficioso.

El uso de una nueva herramienta o técnica reduce la productividad de los programadores y la calidad del producto inicialmente. Se obtienen beneficios una vez superada la curva de aprendizaje.

El arquitecto de donde trabajo es bastante "creativo", y constantemente incluye nuevas tecnologías en las aplicaciones que desarrollamos. El documentarnos sobre la tecnología nos toma como una semana, y cuando nos ponemos a desarrollar definitivamente lo hacemos más lento que con tecnologías más familiares. Pero ver cosas nuevas siempre es divertido xD.

El mejorar un atributo de calidad generalmente perjudica a otro atributo de calidad. Por ejemplo, el mejorar la eficiencia perjudica la flexibilidad a cambios de la aplicación.

Se me viene a la mente el uso de procedimientos almacenados en base de datos: disminuyen el tiempo de respuesta pero te hacen imposible el cambiar de DBMS. Como dicen por ahí, nada es gratis en la vida.

La detección y solución de errores representan el 40% de los costos de desarrollo. Por eso es una de las fases más importantes del ciclo de vida del desarrollo.

Yo me arriesgaría a decir que hasta el 50% de los costos.

De un software -que según un programador promedio ha sido exhaustivamente probado- sólamente se han ejecutado el 55%-60% de sus rutas lógicas. El soporte automático, como analizadores de cobertura, puede elevar este número a 85%-90%. Las pruebas al 100% son imposibles.

Es por esto que el personal de control de calidad no nos cae nada bien. Siempre salen con casos que uno nunca pensaba que se iban dar, y que generan un nada discreto mensaje de error. Aunque como se dice por acá, es mejor que lo vea un tester a que lo vea el usuario xD.

El software siempre contiene defectos residuales, aún después del proceso de eliminación de errores más riguroso. El objetivo es minimizarlos en número y en severidad.

Y sobre todo, que aparezcan después que se haya terminado la garantía xD.

Las mayoría de las tareas de desarrollo de software y de mantenimiento de software son las mismas- excepto por la tarea de mantenimiento adicional "Comprender el producto existente". Esta tarea es de suma importancia, y consume casi el 30% del tiempo de mantenimiento. Por esto, se puede decir que el mantenimiento es más difícil que el desarrollo de software.

Bastante cierto... no hay nada más difícil de entender que el código ajeno. Lo digo con conocimiento de causa, que sufrí 1 año dando mantenimiento a aplicaciones que parecían hechas por chimpancés.

Cuando un proyecto pasa de requerimientos a diseño, la complejidad del proceso de solución produce una exploción de "requerimientos derivados". La lista de requerimientos de la fase de diseño es por lo general 50 veces mayor que la lista de requerimientos original.

Nos pasa todos los días, y ocasiona amanecidas y/o retrasos.

La mayoría de estimaciones de software se desarrollan al inicio del ciclo de vida. Es decir, ocurren antes de la fase de requerimientos y por ende antes de comprender el problema. La estimación por lo general ocurre en el tiempo inapropiado.

Es por esto que los cronogramas de desarrollo son las artefactos más desatendidos e ignorados que conozco. Los hacen por protocolo, pero a la larga nadie los sigue (al menos en mi compañía). Tal vez cronogramas por iteración, como señala RUP, serían la solución.

Esos son los que me parecen más importantes, y creo que si los jefes de proyecto los leyeran nuestros días serían más llevaderos. A ver que opinan ustedes.

Recetario IBM 839

2009-11-21T10:05:00.013-05:00

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!

Colaboración entre equipos

2009-11-06T15:53:00.003-05:00

(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:

Motivar a la gente para que realice su mejor esfuerzo
Crear equipos auto-administrados
Promover la colaboración horizontal entre funciones (como analistas, desarrolladores, testers)
Proveer entornos de colaboración efectivos.
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

Demostrar valor iterativamente

2009-11-06T16:07:00.002-05:00

(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

Permitir retroalimentación al incrementar el valor para el usuario en cada iteración
Adaptar los planes usando un proceso iterativo
Aceptar el cambio y administrarlo
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

Disciplina: Requerimientos

2009-11-06T15:33:00.003-05:00

(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

2009-11-06T14:48:00.003-05:00

(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

2009-11-06T14:07:00.003-05:00

(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

2009-11-06T12:29:00.003-05:00

(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

2009-11-04T19:46:00.004-05:00

(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

2009-11-04T19:33:00.003-05:00

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

Características: Usadas para definir el alcance del proyecto

Audiencia principal: Stakeholders
Documentados en el artefacto de visión

Requerimientos funcionales: Especifican interacciones con los usuarios del sistema.

Audiencia principal: Usuarios y el equipo del proyecto
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

Audiencia principal: Arquitectos y diseñadores
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

2009-11-04T19:20:00.002-05:00

(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

2009-11-04T19:09:00.001-05:00

(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

2009-11-03T19:27:00.002-05:00

(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:

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
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)
Mejorar el proceso continuamente
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

2009-11-03T19:14:00.003-05:00

(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

2009-11-03T19:03:00.002-05:00

(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:

La calidad del producto es propiedad del equipo
Probar temprano y continuamente con integración de capacidades demostrables
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

2009-11-03T18:16:00.002-05:00

(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

2009-11-03T18:02:00.001-05:00

(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

2009-11-03T15:09:00.004-05:00

(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

2009-11-03T14:17:00.003-05:00

(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:

Plan de aceptación del producto
Plan de gestión de riegos (y lista de riesgos)
Plan de resolución de problemas
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

2009-11-03T12:28:00.002-05:00

(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

2009-11-03T12:24:00.002-05:00

(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

2009-11-03T11:21:00.003-05:00

(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

2009-11-02T19:00:00.002-05:00

(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

2009-11-02T18:55:00.003-05:00

(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