PÁGINA INCOMPLETA

Análisis y Diseño de la aplicación MEDEA-TOOL

Se comienza con el análisis y diseño de la aplicación junto con la definición de los CDU del sistema. La principal funcionalidad de la aplicación es gestionar los requisitos y su posterior almacenamiento en un gestor documental como puede ser Alfresco. Por lo tanto, una de las principales tareas que definir es la estructura que queremos que se almacene en Alfresco. Siendo una posible la siguiente:

También podemos querer una implementación de este modo:

Una vez que tenemos planteada la estructura de almacenamiento …

Revisión, validación y refinación de CDU definidos para la aplicación PANTALLASA

Creación de nuevos casos de uso para seguir la disciplina MEDEA:

  1. Crear Orden del Día.
  2. Crear Acta.
  3. Crear Documento de Visión.
  4. Crear Documento Maestro de Requisitos.
  5. Crear Requisitos Funcionales.
  6. Crear Caso de Uso
  7. Crear Historia
  8. Crear Requisito No Funcional.
  9. Validar Requisito Técnicamente.
  10. Aprobar Requisitos.
  11. Aprobar Diseño.
  12. Modificar(Gestionar) Requisitos.

Fase “Determinar el Alcance” Los dos primeros casos de uso puede que no sean necesarios. No obstante, con vistas al futuro, quizás sea necesario almacenar los órdenes del día y las actas en un CMS como puede ser Alfresco. Por eso, y a no ser que el cliente diga lo contrario, vamos a contemplar ese caso. Añado que es necesario para llevar un control de las reuniones.

El tercer punto es muy importante, el documento de visión será el documento de partida para la fase de elicitación de los requisitos y es necesario su tratamiento y posterior almacenamiento.

Fase “Elicitar Requisitos” El punto cuatro es el que tengo algo de dudas, ya que puede interesar tener un documento maestro cuyos hijos sean los casos de uso, historias… o quizás nos interese tenerlo como documentos separados.

Los puntos 6 y 7 todavía son dudosos, ya que, o bien pueden ser pasos del punto 5, o bien pueden realizarse por separado.

Fase “Validar Requisitos” El punto 9 “llama” al CDU Modificar Requisito al final de sus pasos.

En este apartado quizás podríamos añadir un cdi: “Crear documento de Acta de Aprobación Requisitos”. Pero pienso que este es parte del CDU 10. “Aprobar Requisito”

En el punto 11 sucede lo mismo que con el 10: “Crear documento de Acta de Aprobación Diseño”

Fase “Gestionar Requisitos”

Anotar que en esta fase, cuando se recibe una solicitud de modificación se debe mantener la trazabilidad. Quizás este caso sea diferente al de modificación de un requisito cuando se realiza una validación técnica, y debemos llamarle gestión de requisitos y hacer otro (o no) con el nombre de modificación de requisitos.

Refinación de casos de uso de la aplicación PANTALLASA:

  1. Gestionar catálogos
  2. Gestionar tipos de parámetros
  3. Gestionar proyecto
  4. Gestionar grupos de trabajo
  5. Exportar documento de requisitos
  6. Gestionar usuarios de un proyecto
  7. Crear versión base de documento
  8. Gestionar hilos de discusión
  9. Gestionar secciones del documento
  10. Participar en hilos de discusión
  11. Usar un catálogo de requisitos
  12. Crear parámetro
  13. Consultar proyecto
  14. Gestionar patrones de requisitos

Exportar documentos de requisitos necesita validación por el cliente por si se sigue deseando esa funcionalidad.

Eliminación de casos de uso de la aplicación PANTALLASA:

  1. Gestionar documentos de requisitos.
  2. Gestionar requisitos
  3. Gestionar secciones del documento. (POSIBLE)

Explicación:

  1. Requisito eliminado, ya que la implementación de la inserción se va a realizar de otra manera definida en el primer requisito
  2. Requisito eliminado, ya que la implementación de la inserción se va a realizar de otra manera definida en el primer requisito