PÁGINA INCOMPLETA

ANÁLISIS Y DISEÑO DE LA APLICACIÓN MEDEA-TOOL

Introducción

Se pretende crear un prototipo funcional de MEDEA-TOOL, una herramienta de soporte para un repositorio de requisitos reutilizables basada en la metodología actual de ATICA, MEDEA. Para la parte reutilizable de la aplicación nos basaremos en el análisis que se hizo el año anterior para la aplicación PANTALLASA, adaptándolo para cumplir los requisitos de MEDEA.

El prototipo, se desarrollará en un entorno tecnológico compatible con los desarrollos actuales de ATICA:

• Oracle para implementar el repositorio derequisitos
• Alfresco como gestor documental para almacenar documentos de requisitos
• JIRA como herramienta de gestión de tareas (incidencias).

Exportar Requisitos

Se plantea la exportación de estos requisitos en el gestor documental Alfresco. Por lo tanto, una de las tareas será definir la estructura que queremos que tengan los requisitos que se almacenen en Alfresco. Siendo una posible la siguiente:

• Proyecto (Espacio dentro de Alfresco)
  • Requisito (Espacio dentro de Alfresco)
    • Documentos del Requisito (Documento dentro de Alfresco) (Pueden ser casos de uso, historias de usuario …)

También podemos querer una estructura diferente:

• Proyecto (Espacio dentro de Alfresco)
  • Requisito (Espacio dentro de Alfresco)
    • Documentos Maestro (Espacio dentro de Alfresco)
      • Documentos Hijos (Documento dentro de Alfresco) (Pueden ser casos de uso, historias de usuario …)

Existen infinitas formas de almacenamiento en Alfresco, siendo estas dos las opciones más comunes e intuitivas.

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. Operaciones de creación del documento Orden del día según la plantilla.
2. Crear Acta. Operaciones de creación del documento Orden del día según la plantilla.
3. Crear Documento de Visión. Operaciones de creación del documento de visión.
4. Gestionar Documento Maestro de Requisitos. Operaciones de creación, consulta, modificación y borrado de documentos maestros de requisitos.
5. Gestionar Requisitos Funcionales. Operaciones de creación, consulta, modificación y borrado de requisitos funcionales.
6. Gestionar Caso de Uso. (¿Pasos de CDU 5?). Operaciones de creación, consulta, modificación y borrado de casos de uso.
7. Gestionar Historia. (¿Pasos de CDU 5?). Operaciones de creación, consulta, modificación y borrado de historias.
8. Gestionar Requisito No Funcional. Operaciones de creación, consulta, modificación y borrado de requisitos no funcionales.
9. Validar Requisito Técnicamente. Operaciones de validación de requisitos.
10. Aprobar Requisitos. Operaciones de aprobación de los requisitos.
11. Aprobar Diseño. Operación de aprobación del diseño de los requisitos.
12. Modificar(Gestionar) Requisitos. Operaciones de modificación de requisitos.

Dudas y comentarios.

Fase “Determinar el Alcance”.

• Los CDU (1 y 2) puede que no sean necesarios a priori. No obstante, con vistas al futuro, quizás sea necesario almacenar los órdenes del día y las actas tanto en la base de datos como en un CMS como puede ser Alfresco. Por eso, y a no ser que el cliente diga lo contrario, vamos a contemplar este caso de uso en la aplicación. Como añadido personal, creo que es necesario llevar un control de las reuniones y por lo tanto estoy de acuerdo en el tratamiento de estos CDU en la aplicación.

• El CDU 3 es, quizás, el más importante, ya que como salida del CDU tendremos el documento de visión que será el documento de partida para la fase de elicitación de los requisitos. Por lo tanto, creo que es necesario la gestión de este documento en la aplicación. Como detalle, destacar una duda, estos documentos, ¿se van a modificar posteriormente? Si la respuesta es sí, deberíamos modificar este CDU para que no fuese sólo para la creación sino también para la gestión de este tipo de documentos.

Fase “Elicitar Requisitos”

• El CDU 4 es uno de los grandes cambios respecto a la aplicación anterior PANTALLASA, ya que ahora, los requisitos tendran un documento padre llamado “Documento maestro de requisitos”.

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

Fase “Validar Requisitos”

• El CDU 9 “llama” al CDU Modificar Requisito al final de sus pasos.

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

• En el CDU 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