Tareas: Construir Lista de Riesgos

La lista de riesgos es el enunciado de todas las posibles situaciones que pueden perjudicar el proyecto. Es elaborada con ayuda de los stakeholders y del personal de la empresa de desarrollo, considerando la visión del sistema para poder prever, ya desde el principio del proyecto, cuales son esos riesgos posibles.

La identificación por si sola no es suficiente para tener control de los riesgos, sin embargo no se puede mitigar aquello que no se tiene identificado, por lo que toda la gestión de riesgos debe comenzar por construir la lista de riesgos principales. Tarea que debe ser revisada de tanto en tanto, probablemente luego de cada iteración o cierre de fase. Con todo, es meta del ciclo de vida para la fase de elaboración, que para entonces ya hayamos tomado medidas contra los principales riesgos con miras a que estos no molesten durante la fase de construcción.

El siguiente diagrama SPEM ilustra la tarea:

Fig. 1 – Diagrama SPEM de la tarea Construir Lista de Riesgos

Para cuando la lista de riesgos se va a crear por primera vez, se puede considerar seguir los siguiente pasos:

1. Convocar a los trabajadores y stakeholders relevantes.
2. Iniciar la reunión con una inducción de los tipos de riesgos comunes.
3. Dar a los asistentes unos minutos para que realicen individualmente una primera lista de riesgos.
4. Pedir a los asistentes que ordenen sus riesgos identificados por orden de importancia.
5. Tomar los tres o cinco primeros riesgos de cada lista.
6. Identificar los riesgos más nombrados, estos son los que más preocupación causan.
7. Enriquecer la lista común con sugerencias y ampliaciones.
8. Clasificar y ordenar los riesgos de la lista común según los criterios pertinentes.
9. Presentar la lista de riesgos en la forma de un documento.

Por otra parte, si la lista ya está realizada, se puede entonces la tarea se vuelve un trabajo de revisión y actualización, algo definitivamente más simple, que bien puede no necesitar de una reunión expresa para el punto.

Por ultimo comento que es típico que el rol de analista de riesgos sea asumido por el Jefe de Proyecto. No hay buena razón para tener a alguien dedicado exclusivamente a esto y de todos modos, el Jefe de Proyecto es de seguro, uno de los invitados a la reunión de identificación de riesgos.

Tareas: Análisis de Caso de Uso

Entiendo por análisis la habilidad de ver partes en aquello que se ha visto como un todo, en concreto, el análisis de casos de uso ha de visualizar instancias de objetos por ahora de clase indeterminada, que por medio de su colaboración dan lugar a la funcionalidad especificada en el caso de uso.

A esto se le llama también Realización de Caso de Uso al nivel de Modelo de Análisis, un nombre largo que en verdad no sé a que se debe. El siguiente diagrama de UML muestra la relación de realización entre un caso de uso y su escenario de análisis.

Fig. 1 – Realización de Caso de Uso

Si contamos con un modelo de dominio bien hecho, el análisis de casos de uso puede ser realizado por medio de la identificación de cuales de las clases de aquel modelo que participan en el caso de uso, y presentar estas en un diagrama de interacción: ya sea de colaboración o más normalmente, de secuencia.

El siguiente diagrama SPEM muestra la estructura de esta tarea:

Fig. 2 – Diagrama SPEM de la Tarea Analizar Caso de Uso
(Versión con Modelo de Dominio)

Por otra parte, RUP nos sugiere una aproximación alternativa: utilizar las llamadas clases de análisis; que son clasificadores de UML estereotipados en tres tipos básicos: control, entidad e interfaz. Esta técnica no presupone la existencia de un modelo de dominio y aunque en su momento daré un ejemplo, no es la aproximación que considero mejor integrada con el resto del método.

El siguiente diagrama ilustra la estructura de la Tarea Encontrar Clases de Análisis, que es la variedad del Análisis de Caso de Uso que utiliza clases de análisis de RUP en lugar de un modelo de dominio.

Fig. 3 – Diagrama SPEM de la Tarea Encontrar Clases de Análisis
(Versión de Análisis de Caso de Uso sin Modelo de Dominio)

Dejando de lado la diferencia en el producto, quiero que se note que en el primer caso la entrada es un Caso de Uso y un Actor, por oposición al Modelo de Casos de Uso completo, que si es la entrada de la segunda aproximación.

Justamente lo anterior es lo que rescata la técnica de las clases de análisis a mis ojos; uno puede tomar no uno, sino varios casos de uso relacionados por algún concepto, y analizarlos en su conjunto; lo que nos lleva a conclusiones diferentes y útiles.

Tareas: Desarrollar Vocabulario del Cliente

Si bien es responsabilidad de todos en la organización el respetar y utilizar el vocabulario común con el cliente, es en el disciplina de requisitos que esto se hace con más fuerza. De hecho, donde para todos tenemos la tarea de Desarrollar Vocabulario Común, para la disciplina de requisitos hablamos de Capturar Vocabulario del Cliente.

La diferencia no es solo una cuestión de énfasis. Desarrollar Vocabulario Común se refiere tanto a aprender los términos del cliente como de enseñar la terminología técnica mínima necesaria para comprender y utilizar los resultados de nuestro trabajo. Es decir, Desarrollar Vocabulario Común es un camino de doble vía.

Por otra parte, Capturar Vocabulario del Cliente es una actividad de aprendizaje para la organización de desarrollo y en particular para su Analista de Requisitos; quien debe hacer un esfuerzo por detectar, documentar y aplicar correctamente todos los conceptos especiales en uso en la actividad del cliente que lleguen a entrar en contacto con el desarrollo.

Fig. 1 – Diagrama SPEM de la tarea Capturar Vocabulario del Cliente

Sin embargo, ambas tareas son definitivas similares, por lo que en la ilustración anterior, además de la asignación de roles y las salidas esperadas, vemos que existe una relación de herencia que nos dice: todo lo que sabes de Desarrollar Vocabulario Común aplica lo también en Capturar Vocabulario del Cliente. La diferencia será que ahora vamos a dedicar tiempo en documentar este vocabulario, misión para la cual vamos a tomar la Plantilla de Glosario como punto de partida.

Control de Calidad: Revisión de Forma

Como parte de todo proceso de control de calidad es necesario verificar primero la forma de los artefactos puestos a revisión antes de poder ir al fondo de lo expresado en ellos.

Esta revisión de forma toca entre otros puntos, los siguientes:

• Buen uso del idioma español: redacción, ortografía, puntuación; tal como en la escuela.
• Buen uso del vocabulario técnico común.
• Buen uso del lenguaje UML.
• Respeto de la estructura de las plantillas utilizadas.
• Presentación de los documentos.
• Uso de logotipos e imagen corporativa.
• Cualquier otro aspecto general de los artefactos.

Según lo que se diga en el Plan de Control de Calidad del proyecto, esta tarea será realizada con mayor o menor frecuencia, pero ciertamente es necesario que sea realizada de tanto en tanto incluso en proyectos muy pequeños, ya que un documento con faltas de ortografía o que confunda el significado de palabras comunes ciertamente va a ser rechazado por cualquier cliente.

La siguiente ilustración muestra la tarea:

Fig. 1 – Diagrama SPEM de la Tarea Revisión de Forma de Artefactos

Una nota para los proyectos muy pequeños: recordemos que un rol puede ser asumido por cualquier persona en la organización, no necesariamente es una persona dedicada solo a cumplir con ese rol; por lo cual es posible instruir a una secretaria o personal no técnico que tenga algo de tiempo que pueda dedicarse a la revisión de forma de los documentos. Claro que para verificar el buen uso del UML ha de contar con algo de instrucción técnica, pero la ortografía y la claridad de la redacción pueden ser verificados con facilidad por personal de una formación distinta de la ingeniería del software.

Tareas: Construir Modelo de Dominio

Llamamos Modelo de Dominio a la representación de los conceptos de importancia en el área de la aplicación, así como de las relaciones entre estos; en la forma de clases UML simplificadas.

Convencionalmente la construcción del Modelo de Dominio es responsabilidad del Analista de Sistema, quien ejecuta esta tarea con ayuda de la Visión del Sistema y del Glosario de Requisitos.

El siguiente diagrama ilustra la tarea:

Fig. 1 – Diagrama SPEM de la Tarea Construcción del Modelo de Dominio

El Modelo de Dominio, cuando es correctamente construido, es una poderosa forma de análisis, llegando a ser tan expresivo y lleno de significado que incluso en algunos métodos de desarrollo llega a sustituir al propio Modelo de Requisitos.

Ejemplo de lo anterior es el novedoso Desarrollo Guiado por Modelos, donde se parte de un Modelo de Dominio para la construcción del sistema. Claro que en la jerga propia del método este modelo recibe un nombre distinto; un detalle que podemos pasar por alto por hoy.

Otro punto digno de mención es la ausencia del Modelo de Casos de Uso entre las entradas de la tarea de Construcción del Modelo de Domino. Lo cierto es que los requisitos funcionales claramente son algo a analizar, pero como todos los conceptos importantes mencionados en los casos de uso ya están contenidos en el Glosario del Sistema no hay mayor uso de estos aquí.