Automatizacón de la Gestión de Requisitos de MEDEA
Alumno
Facultad de Informática
-
Recursos Alumno
Recursos MNCS
Reuniones
04-03-2014
10-03-2014
30-10-2014
Asistentes: Jorge, Joaquín, Paco y Juan Luis.
Resumen: Duración 1h45m.
Se confirma que la dedicación del Jorge al TFG son 320h (20h/semana, 80h/mes, durante 4 meses, desde el 1-10-2014).
Jorge se compromete a dedicarle el tiempo necesario y terminar el TFG para Febrero del 2015.
ATICA ofrece una mesa en el despacho de MNCS (1.07) para que Jorge pueda trabajar en el TFG. Jorge cree q le puede venir bien cuando empiece con el desarrollo de la aplicación con FundeWEB.
Jorge se compromete a aplicar MEDEA a la gestión del proyecto, empezando por “traducir” el plan de trabajo a artefactos MEDEA (actas de reuniones, cronograma, documento visión, etc).
Jorge incluirá en el análisis (dependencias, flujos, etc) la interacción con Jira, y se compromete a q la aplicación sea capaz de generar los jiras de la gestión de requisitos.
-
28-1-2015
Asistentes: Jorge, Joaquín, Paco, Pedro y Juan Luis.
Resumen: Duración 2h20m.
Estado del Proyecto: Jorge dice q ha terminado el análisis y tiene casi terminadas las pantallas de mantenimiento de la aplicación, con persistencia en BD.
Revisión de la aplicación en “
http://medeapruebas.um.es”: le hacemos sugerencias de mejora, incluyendo remodelación del acceso a las opciones, para q sea más intuitivo, y siga el “workflow” de MEDEA.
Lo que falta: además de implementar la sugerencias de mejora q le hemos hecho, hay q terminar los mantenimientos, pues no están todos terminados, y tb tiene q desarrollar la generación de documentos con BIRT, así como permitir la grabación de documentos en Alfresco, y crear los Jiras correspondientes a las tareas de Gestión de Requisitos.
Hemos quedado para la semana del 9-2-2015 deberían estar terminados todos los mantenimientos, y aplicadas las mejoras q le hemos hecho de cara a q la aplicación sea más intuitiva y usable.
Tanto ATICA como la Facultad (Joaquín) deberíamos revisar a fondo la aplicación (
http://medeapruebas.um.es) para comprobar su correcto funcionamiento.
25-2-2015
Asistentes: Jorge, Joaquín, Paco, Pedro y Juan Luis.
Resumen: Duración 2h20m.
Revisamos la aplicación y proponemos mejoras en organización de campos, longitudes, usabilidad, informes, etc.
26-3-2015
Asistentes: Pacom, Juan Luis.
A partir de varias dudas q le surgen a Joaquín y Jorge sobre el versionado de requisitos y documentos, me reúno con Pacom para elaborar una lista de requisitos q debe cumplir la aplicación en este sentido (versionado de requisitos y documentos).
1.- VERSIONADO general, da igual q sea de requisitos o de documentos:
Cuando manejamos un requisito/documento realmente siempre trabajamos con una versión concreta del requisito/documento, por lo tanto a partir de ahora si hablamos de requisito/documento realmente estamos hablando de una versión concreta de un requisito/documento.
Una versión puede estar “abierta” o “cerrada”, y solo se pueden modificar los datos si está abierta.
Si tengo varias versiones solo podré tener “abierta” la última versión.
Al cerrar una versión la app me avisará de q “una vez cerrada no podré modificarla”, y solo podré “crear nueva versión”.
Excepcionalmente, el Jefe de Proyecto podrá abrir una versión cerrada si ésta es la última.
Para “crear una nueva versión” todas las anteriores deben estar cerradas.
2.- REQUISITOS, da igual q sea de alto nivel (visión) o de bajo nivel (historias, casos de uso, requisitos no funcionales),:
Un requisito se crea dentro de un Catálogo reutilizable, o bien en un Proyecto, nunca de forma aislada.
En un proyecto puedo copiar los requisitos de un Catálogo.
En un catálogo puedo copiar uno, varios o todos los requisitos de un Proyecto.
3.- APROBACIÓN DE REQUISITOS:
A nivel requisito, vamos a separar la acción de “Aprobar” (visto bueno del usuario) de la de “Cerrar Versión”, aunque al pulsar el botón “Aprobar” por defecto se lanzará tb la acción “Cerrar Versión”. De este modo una versión aprobada de un requisito NO se podrá modificar.
Al “Aprobar” un requisito la app debe preguntar si “estoy seguro de hacerlo” avisando de q implica q “dicho requisito no se podrá modificar, a no ser q crees una nueva versión”.
Para adaptarnos a la realidad del trabajo diario, mientras no exista una versión posterior del requisito, vamos a habilitar un botón “Abrir Versión” q nos permitirá hacer un cambio en un requisito ya aprobado. Esta opción de “Abrir Versión” debería requerir permisos especiales (rol “Jefe Proyecto”), ya q podré modificar un requisito aprobado por el cliente.
4.- VERSIONADO DE REQUISITOS (se aplica el punto 1 de VERSIONADO general de más arriba):
5.- DOCUMENTOS, da igual q sea de Visión o de Requisitos.
Un documento sirve para definir qué requisitos voy a abordar, ya sean de alto nivel (visión) o de bajo nivel (historias, casos de uso, requisitos no funcionales), y tb es una herramienta para comunicárselo al cliente.
Un requisito de un proyecto solo puede aparecer en un Documento de dicho proyecto (ya sea de Visión o de Requisitos). Obviamente, los requisitos de visión solo pueden estar en un documento de visión.
Una versión de un requisito puede aparecer en varios versiones del mismo documento.
Un Documento debe un atributo para recoger la “Versión de la Aplicación” a la q se corresponde.
Puedo añadir requisitos del proyecto a un Documento (solo la última versión de cada requisito q quiera añadir), de modo q NO SE COPIA el requisito en el documento, pues el versionado (abierto/cerrado) de cada requisito es el q define si dicho requisito está “vivo” o no. Por lo tanto, en el documento solo tengo la relación de requisitos del proyecto q he seleccionado con su versión correspondiente.
6.- VERSIONADO DE DOCUMENTOS (se aplica el punto 1 de VERSIONADO general):
4-6-2015
Asistentes: Jorge, Joaquín, Juanma, Pedro, Pacom, Juan Luis.
Resumen: hablamos de la revsión técnica q ha hecho Pedrody al código de la aplicación (ver más abajo), y hacemos una revisión de la aplicación de la que surgen los siguientes bugs (B) y peticiones de cambio (N):
(B) (Hecho) Rich Editor a veces no se carga: Pedrody sugiere actualizar a última versión de Primefaces para ver si se soluciona, pues recuerda haber visto bug similar al usar el editor en pestañas, como es el caso.
(B) (Hecho) Componente tabla editable: en los convocados a una reunión permite crear una línea en blanco y guardarla, lo q provoca q luego la app falle.
(B) (Hecho) Gestión de Reuniones: el botón “Abrir Versión” debe tener el texto “Abrir Reunión”.
(B) (Hecho) Historias: donde dice “Como probarlo” debe ser “Cómo probarlo” (con tilde).
(B) (Hecho) Botón “Volver”: debe estar siempre a la derecha.
(B) (Hecho) Gestión de Reuniones: en la lista de Asistentes, el check “Asistido” debe ser clicacle sin editar la línea.
(N) (Hecho) Listado de documentos del proyecto (y cualquier lista): los botones de paginación deben estar debajo, incluyendo la selección del nº de elementos por página, y la selección del nº de página a la q quiero ir directamente.
(N) (Hecho) Edición de requisitos: los campos Nombre, Texto y Breve Descripción deben ser Código, Resumen y Descripción.
(N) (Hecho) Lista de documentos: incluir un botón para descargar el documento (Pedrody le tiene q pasar captura de pantalla con el icono en cuestión).
(N) (Hecho) Requisitos Proyecto: importar Catálogo, debe traerse los requisitos del catálogo y aprobarlos, cerrando la v1.0.0. De modo q si se quieren modificar requerirá crear nueva versión de cada uno.
(N) (Hecho) Listado Requisitos: los campos a mostrar por defecto son Proyecto, Tipo, Código, Resumen, Versión y Aprobado (Quién y Fecha).
(N) (Hecho) Generar Documento con Requisitos de un Catálogo: hacerlo de forma similar al Documento de Requisitos, en lugar de en un listado tipo tabla. Para ello, Jorge tendrá q copiar y pegar la plantilla del doc. de requisitos y modificarla.
(N) (Hecho) Filtros: incluir icono “embudo” cuando se aplique un filtro, y q se cierre el filtro al aplicarlo. Pedrody tiene q paasrle captura de pantalla con el “icono del embudo”.
(N) (Hecho) Generar Documento: al generar cualquier documento hay q tener en cuenta q si una sección del mismo está vacía, se debe incluir el texto “No hay datos.”, de forma q quede claro q NO se ha rellenado la sección en cuestión.
(N) (Hecho) Añadir un tooltip a iconos para descargar los pdfs de Acta y Orden del Día (y saber cual es cada uno).
Además, Pedrody ha hecho una revisión técnica del código de la aplicación, de modo que habría que revisar lo siguiente:
(Hecho) Los métodos “getLog()” no deben devolver nulos, sino el log
(Hecho) Quitar todos los “TODO” y todo el código comentado innecesario
(Hecho) Quitar las variables que no se utilicen
(Hecho) Mover los métodos getter y setter al final del código
(Hecho) Quitar accesos a rutas absolutas. Ejemplo: C:\out.pdf en el Manejador de reuniones.
(Hecho) A la hora de recuperar el usuario cambia identiy.getUsername() por identiy.getCredentials().getUsername()
(Hecho) He adjuntado dos imágenes una del botón de filtrado y otra de un pequeño mantenimiento que tiene los iconos de buscar y limpiar. Sobre el botón de filtrado, aunque en apium no está hecho, resalta en rojo el icono para que llame la atención mejor.
(Hecho) Eliminar import que no hacen falta.
(Hecho) No poner llaves en los condicionales.
(Hecho) Poner Javadoc a principales métodos.
(Hecho) Poner una salida de log en todas las excepciones que se capturen.
(Hecho) Quitar los printStackTrace.
(
Hecho) Para actualizar a primefaces 5.2 cambia en el pom.xml del módulo web el bloque de primefaces por:
<!-- Primefaces -->
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>5.2</version>
</dependency>
<dependency>
<groupId>org.primefaces.themes</groupId>
<artifactId>all-themes</artifactId>
</dependency>
<dependency>
<groupId>rome</groupId>
<artifactId>rome</artifactId>
</dependency>
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
</dependency>
<dependency>
<groupId>org.primefaces.extensions</groupId>
<artifactId>primefaces-extensions</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>org.primefaces.extensions</groupId>
<artifactId>resources-ckeditor</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
</dependency>
<!-- FIN - Primefaces -->
El compromiso de Jorge es tener solucionado todo ésto para el 15-6-2015 (Bugs y Cambios resultantes de la revisión, más las mejoras propuetas por Pedrody al código)
Plan de Trabajo
Preparar Infraestructura
MNCS tiene que preparar la infraestructura de recursos necesaria que debe proporcionar Atica (Wiki, lista-correo, SVN, BD, Web, etc):
El 10-3-2014 Jorge recibe formación sobre nuestro entorno de desarrollo FundeWEB 2.0, por parte de Pedrody.
Instalado FundeWEB-2.0 en su portátil, y solucionados los problemas del IDE y tb de accesos.
Comenta q va a cambiar de portátil a un Mac, por lo q se le recomienda trabajar con una máquina virtual, en la q tendrá q instalarlo todo de nuevo (ya sabe cómo).
El 11-3-2014 Jorge continua con la formación sobre el entorno de desarrollo FundeWEB 2.0. En primer lugar, repasa todo lo explicado por Pedro la mañana anterior y una vez repasado ahonda más en la configuración del proyecto semilla que se le instaló en el portátil para poder comprender a la perfección el funcionamiento y poder seguir con el estándar de aplicación que se propone desde ATICA.
En cuanto al cambio de portátil, este es debido a dos motivos. Por una parte la velocidad de su actual ordenador y por otro que el hecho de trabajar con un entorno FundeWEB implica cambios en la configuración actual de su portátil.
El 9-12-2014, Pedrody estuvo con Jorge por la tarde, y le solucionó el problema q tenía con FDW2 (estaba usando el mismo proyecto FDW1), creando de nuevo el proyecto con FDW2; y le explicó cómo hacer las pantallas, con qué componentes, y tb cómo implementar la persistencia, generando las clases a partir de la BD.
El 5-2-2015, Pedrody estubo con Jorge por la mañana, solucionando dudas técnicas sobre FDW, y enseñándole como hacer un informe BIRT.
Soporte MNCS
Sprints
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Sprint 6
Sprint 7
Funcionalidad de la aplicación
Roadmap
Versión 1.0
Funcionalidades generales a implementar:
Detalle de las funcionalidades a implementar:
Mantenimiento de Proyectos: requisitos del proyecto (mantenimiento, importación desde catálogo, versionado), reuniones (generación de órden del día y acta) y documentos visión/requisitos (mantenimiento, generación de pdf y versionado).
Mantenimiento de Catálogos: requisitos del catálogo (mantenimiento y generación de listado pdf).
Consulta de Requisitos: para listar requisitos por proyecto, catálogo, tipo, nombre, descripción, etc, de modo q pueda seleccionar un requisito de la lista y editarlo, lo q me llevará a la pantalla de edición del requisito en el proyecto/catálogo según donde esté.
Gestión de Identificación de Personas: copiarlo de APIUM, de modo q se obtengan/busquen los datos de cualquier persona involucrada en la Gestión de Requisitos, como responsables funcionales, expertos, etc. No incluya gestión de cargos, q será abordada en versiones siguientes.
Gestión de Usuarios y Roles: hay operaciones q solo las puede hacer determinado rol, como por ejemplo, Abrir una versión cerrada de un requisito aprobado. Replanificado para versión 1.1.
Ajustes necesarios:
Ajuste del Modelo de Datos en BD: ajustarlo a todos los cambios q se hayan hecho, de modo q las tablas tengan los nombres correctos y las columnas necesarias. Finalmente el modelo debe estar impoluto, con las entidades necesarias bien nombradas, y los atributos requeridos bien dimensionados.
Ajuste de todas las pantallas (estilo y usabilidad, como puede ser ajuste de campos o q el botón Volver te lleve a la pantalla de la q vienes).
Validación de TODOS los campos, tanto en la vista como en la capa de persistencia.
Fecha de entrega: 30 de /Junio
Cierre de la version: puesta en producción de la versión 1.0 (en los servidores de producción de BD y Web, pasando antes todas las pruebas en los servidores de tests). Deben incluirse los cambios propuestos en la reunión del 4-6-2015.
Versión cerrada a 29-6-2015, en servidor de Desarrollo (no está en Test ni Producción).
Versión 1.1
Gestión de cargos, similar a como se hace en ApiUM.
Gestión de Usuarios y Roles: hay operaciones q solo las puede hacer determinado rol, como por ejemplo, Abrir una versión cerrada de un requisito aprobado.
Versión 2.0
Conexión JIRA para la gestión de tareas.
Conexión ALFRESCO para guardar documentos generados.
Conexión APIUM para la trazabilidad con aplicaciones.
Conexión Agenda UMU para la gestión de reuniones.
Requisitos parametrizados (propuesta Joaquín Fac.Inf.).
Gestión completa de trazas para reutilización (propuesta Joaquín Fac.Inf.).
Etiquetas (propuesta Joaquín Fac.Inf.).
Patrones de requisitos predefinidos (propuesta Joaquín Fac.Inf.).