Módulo de gestión de proyectos de GTI

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Módulo de Gestión de Proyectos de GTI Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Autor: Pablo Mora Galindo Tutor: Antonio Luis Delgado González Sevilla, 2020 2 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Módulo de Gestión de Proyectos de GTI Autor: Pablo Mora Galindo Tutor: Antonio Luis Delgado González Profesor asociado Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 4 Trabajo Fin de Grado: Módulo de Gestión de Proyectos de GTI Autor: Pablo Mora Galindo Tutor: Antonio Luis Delgado González El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2020 El Secretario del Tribunal 6 A mi familia A mis profesores A mis compañeros y amigos 8 Agradecimientos Hoy acaba una dura e intensa pero bonita etapa en la que he aprendido mucho. Aparte de los conocimientos académicos adquiridos, me ha enseñado el valor del esfuerzo y la constancia, a ser trabajador y no rendirme a las primeras de cambio, a confiar en mi mismo. Ante todo, gracias a mis padres por su paciencia y todo lo que me han aportado, sin ellos no hubiese sido capaz de llegar hasta aquí. Gracias por vuestros consejos y compresión, siempre habés estado ahí para mí. A mi hermana por todo el apoyo que siempre me ha ofrecido y por creer siempre en mí, incluso hasta cuando yo no lo hacía. A mi tutor Antonio por haber confiado en mí en todo momento para la realización de este trabajo y, además, por su enorme ayuda, enseñanzas y paciencia, sin las cuales no hubiera sido posible realizarlo. Pese a todas las dificultades que se han presentado, siempre ha estado dispuesto a dedicarme una parte de su tiempo y su conocimiento. A mis compañeros y amigos por estar siempre ahí tanto en los momentos difíciles como en los buenos. Especialmente gracias a Álvaro y José Antonio por estos 5 años que me habéis acompañado y en los que hemos pasado muy buenos momentos juntos, así como duros también. Gracias a Francisco por ser una persona y amigo de los que cuesta encontrar y perduran para toda la vida, vales oro. En definitiva, gracias a todos los que me habéis apoyado en cualquier momento de esta etapa. Finalmente, como comenté al principio, hoy acaba una etapa, pero empieza otra en la que seguiré trabajando y mejorando para poder convertirme en mi mejor versión. Me gustaría terminar con una frase corta pero con mucho significado: “Inténtalo y fracasa, pero no fracases en intentarlo” Pablo Mora Galindo Sevilla, 2020 Departamento de Ingeniería Telemática Documento de Análisis . Índice de figuras Ilustración 1: Diagrama informal del sistema......................................................................................5 Ilustración 2: Diagrama informal del módulo de gestión de proyectos...............................................6 Ilustración 3: Requisitos del módulo de gestión de proyectos.............................................................7 Ilustración 4: Diagrama entidad-relación...........................................................................................12 Ilustración 5: Diagrama de estados de una actividad.........................................................................15 Ilustración 6: Unidad de interacción para definir categorías de proyectos.........................................17 Ilustración 7: Tipos de proyectos/actividades y sus campos personalizados......................................18 Ilustración 8: Unidad de interacción para la gestión de ámbitos y administradores..........................18 Ilustración 9: Unidad de interacción para la administración de proyectos.........................................19 Ilustración 10: Edición de proyectos (Detalles).................................................................................20 Ilustración 11: Pestaña Propiedades..................................................................................................20 Ilustración 12: Pestaña Adjuntos.......................................................................................................21 Ilustración 13: Gestión de proyectos (miembros).............................................................................21 Ilustración 14: Gestión de proyectos (Histórico)................................................................................21 Ilustración 15: Edición de actividades (Detalles)...............................................................................22 Ilustración 16: Gestión de proyectos (esfuerzo).................................................................................22 Ilustración 17: Unidad de interacción para la gestión de actividades ampliada.................................23 Ilustración 18: Edición de actividades (Detalles)...............................................................................24 Ilustración 19: Actividades hijas........................................................................................................24 Ilustración 20: Pestaña Propiedades..................................................................................................25 Ilustración 21: Pestaña Adjuntos.......................................................................................................25 Ilustración 22: Edición de actividades (Detalles)...............................................................................26 Ilustración 23: Gestión de proyectos (esfuerzo).................................................................................26 Ilustración 24: Informe del proyecto..................................................................................................27 Ilustración 25: Unidad de interacción para la Gestión de proyectos..................................................28 Ilustración 26: Unidad de interacción para la gestión de proyectos ampliada...................................29 Ilustración 27: Unidad de interacción lista de actividades.................................................................29 Ilustración 28: Informe de actividad...................................................................................................30 Ilustración 29: Unidad de interacción lista de actividades.................................................................31 Ilustración 30: Unidad de interacción para la edición de actividades................................................32 Ilustración 31: Actividades hijas........................................................................................................33 Ilustración 32: Pestaña Propiedades...................................................................................................33 Ilustración 33: Unidad de interacción para la visualización de proyectos.........................................34 Ilustración 34: Pestaña Adjuntos.......................................................................................................34 Ilustración 35: Visualización de proyectos (usuarios).......................................................................35 Ilustración 36: Unidad de interacción para la visualización de proyectos del perfil usuario.............35 Ilustración 37: Unidad de interacción para la visualización de actividades del perfil usuario...........36 Ilustración 38: Pestaña Adjuntos.......................................................................................................37 Ilustración 39: Visualización de proyectos (usuarios).......................................................................37 Ilustración 40: Gestión de proyectos (Histórico)................................................................................37 Ilustración 41: Unidad de interacción para la visualización de proyectos a usuarios sin acceso.......38 Ilustración 42: Unidad de interacción para la visualización de actividades a usuarios sin acceso.....38 Ilustración 43: Modelo de dominio de la aplicación winter................................................................5 3/61 Ilustración 44: Asignación de paneles a usuarios................................................................................6 Ilustración 45: Visualización de paneles.............................................................................................6 Ilustración 46: Interfaz de usuario final para la visualización de paneles...........................................7 Ilustración 47: formulario fdescr.form.descr.......................................................................................8 Ilustración 48: formulario ffkdescr.form.descr....................................................................................9 Ilustración 49: Modelo de datos de wcaval.......................................................................................11 4/61 Departamento de Ingeniería Telemática Documento de Análisis 1. Introducción 1 Introducción El proyecto GTI (Gestión TIC) pretende desarrollar una aplicación web modular que permita controlar los activos TIC de una empresa u organismo y gestionar los procesos, proyectos y servicios ofrecidos por el departamento TIC. Inicialmente se han propuesto cuatro módulos: 1. El módulo común, que será responsable de la gestión y mantenimiento de todos los elementos compartidos entre los diversos módulos de la aplicación. 2. El módulo de gestión de activos, encargado entre otros aspectos del inventario, control de stock, adquisiciones y las entradas y salidas de material. 3. El módulo de gestión de procesos, desde el cual se gestionan los distintos procedimientos que realiza el departamento de informática y los servicios ofrecidos a los usuarios y a las distintas áreas del departamento. 4. El módulo de gestión de proyectos, que permite la definición de los proyectos tipo del departamento y el seguimiento de su ejecución. Este Trabajo de fin de Grado (TFG) trata precisamente sobre este último módulo. La aplicación GTI debe tener un diseño modular, es decir, cada sección de la misma será un módulo, que será empaquetado e integrado en un marco de integración base, la aplicación winter , (ver sección 6.1). El entorno de desarrollo empleado para todos los módulos es WAINE[1][2]. 5/61 Ilustración 1: Diagrama informal del sistema 1.1 El módulo de gestión de proyectos El módulo de gestión de proyectos viene a dar respuesta a una de las necesidades de gestión básicas dentro de la gestión TIC: la planificación, control y seguimiento de los proyectos. Este módulo debe permitir la gestión de proyectos en distintos ámbitos (territoriales, departamentales, de administración, etc. ). También debe permitir la definición de diferentes tipos de proyectos en base a sus actividades, así como establecer los participantes de cada proyecto y sus roles. En la ilustración anterior se muestra cómo un administrador de proyectos crea proyectos dentro del ámbito en el que está autorizado. Los proyectos son vigilados por los gestores de proyectos. Un proyecto puede tener varios gestores. Los proyectos se dividen en actividades de las que es responsable un técnico. Varios técnicos pueden trabajar sobre el conjunto de actividades del proyecto. Los usuarios expertos pueden prestar su asistencia en algunas de estas actividades colaborando de esta manera en la construcción del proyecto. 6/61 Proyecto 1 Proceso 2Proyecto 2 Proyecto 3 Proyecto N Actividad 1.1 Técnico 1 Técnico 2 Técnico 3 Técnico 4 Técnico 5 Técnico 6 Técnico 7 Técnico 8 Gestor A Gestor B Gestor X Gestor C Usuario D Usuario B Usuario A Usuario C CREA CREA Administrador Proyectos A Administrador Proyectos B Ámbito A Ámbito B Actividad 1.2 Actividad 2.1 Actividad 3.1 Actividad 3.1 Actividad N.1 Actividad N.2 Actividad N.3 Ilustración 2: Diagrama informal del módulo de gestión de proyectos Departamento de Ingeniería Telemática Documento de Análisis 1. Introducción 1.2 Objetivos del proyecto 1. Elaborar una aplicación para la gestión de proyectos. 2. Contribuir a la normalización de la gestión de proyectos en los organismos en los que se implante esta aplicación. 3. Contribuir a la construcción de una aplicación que de respuesta a la problemática de la gestión TIC en una empresa u organismo. 4. Desarrollar un aplicación de gran tamaño modularizada que pueda servir como ejemplo al desarrollo de otros proyectos similares en tamaño y complejidad dentro de la plataforma WAINE. 2 Catálogo de requisitos En esta sección se enumeran brevemente los requisitos del módulo de gestión de proyectos. 7/61 Ilustración 3: Requisitos del módulo de gestión de proyectos Requisitos R2. Usuarios R2.6 Usuario sin acceso R2.6.2 Tiene acceso a una información mínima sobre las tareas R2.6.1 Tiene acceso a una información mínima sobre los proyectos del módulo R2.5 Usuario R2.5.4 Podría imputar tiempos en las tareas de los proyectos en los que participa R2.5.3 Puede escribir en el histórico de cualquier tarea de un proyecto del que sea participante R2.5.2 Tiene acceso en modo lectura a las tareas de los proyectos en los que participa R2.5.1 Tiene acceso en modo lectura a cualquier informacion de los proyectos en los que participa R2.4 Técnico R2.4.4 Imputa tiempos en las tareas de los proyectos en los que participa R2.4.3 Puede escribir en el histórico de cualquier tarea de un proyecto del que sea participante R2.4.2 Puede modificar cualquier tarea perteneciente a los proyectos en los que participa R2.4.1 Tiene acceso en modo lectura a cualquier informacion de los proyectos en los que participa R2.3 Gestor de proyectos R2.3.4 Puede asignar participantes a los proyectos que gestiona y establecer sus perfiles R2.3.3 Puede imputar tiempos a cualquier tarea de los proyectos en los que participa R2.3.2 Puede añadir o eliminar actividades de los proyectos que gestiona R2.3.1 Tiene la capacidad de modificar aspectos operativos de los proyectos que gestiona y de sus tareas R2.2 Administrador de proyectos R2.2.4 Puede modificar cualquier proyecto en los ámbitos en los que es administrador R2.2.3 Asigna participantes a los proyectos y les asigna sus perfiles R2.2.2 Elimina proyectos y actividades (para casos de error) R.2.2.1 Puede crear proyectos o copiar proyectos anteriores para generar uno nuevo R2.1 Administrador del módulo R2.1.2 Establece los administradores de proyectos de los distintos ámbitos R2.1.1 Parametriza el módulo de gestión de proyectos R1. Funcionalidad R1.4 Imputaciones R1.4.3 Cualquier participante del proyecto puede hacer imputaciones a las actividades del mismo R1.4.2 Se pueden calcular imputaciones totales por actividades y proyectos R1.4.1 Las imputaciones se clasifican en categorías preestablecidas R1.3 Actividades R1.3.10 Se deben poder adjuntar documentos a una actividad R1.3.9 Se debe poder generar un informe de la actividad con una relación de sus imputaciones R1.3.8 Posibilidad de configurar campos personalizables por cada tipo de actividad R1.3.7 Las actividades tienen asignado un porcentaje de avance: 0%, 25%, 50%, 75%, 100% R1.3.6 Las actividades tienen asignado un estado: Nueva, En curso, Detenida, Finalizada R1.3.5 La visibilidad de los usuarios sobre las actividades será por proyecto y perfil R1.3.4 Una actividad tiene un único responsable R1.3.3 Puede existir una relación jerárquica entre actividades R1.3.2 Debe poderse seguir la "historia" de cada actividad R1.3.1AUna actividad está vinculada a un único proyecto R1.2 Proyectos R1.2.9 Se deben poder adjuntar documentos a un proyecto R1.2.8 Se debe poder generar un informe del proyecto con la evolución de sus actividades R1.2.7 Se podrá asignar un responsable a un proyecto R1.2.6 Los proyectos pueden estar asociados a una unidad organizativa R1.2.5 Los proyectos se clasifican por categorías R1.2.4 Posibilidad de configurar campos personalizables por cada tipo de proyecto R1.2.3 Solo el administrador de proyectos puede eliminar proyectos AAAAAAAAAAAAALos gestores activarán/desactivarán proyectos R1.2.2 Un proyecto puede tener varios gestores R1.2.1 La visibilidad de los usuarios sobre los proyectos se definirá por su perfil R1.1 Ámbitos R1.1.3 Los administradores de proyectos se definen por ámbito R1.1.2 Siempre existirá un ámbito global R1.1.1 Los proyectos deben contemplar ámbitos 2.1 Funcionalidad Entre los requisitos funcionales más importantes se destacan los siguientes: •R1.1 Ámbitos ◦R1.1.1 Los proyectos deben contemplar ámbitos. El módulo de gestión de proyectos de gti debe contemplar ámbitos. Normalmente serán provinciales, regionales o funcionales (departamentos, áreas, etc.) ◦R1.1.2 Siempre existirá un ámbito global. Existirá un ámbito global por defecto. Estará identificado por un código especial y no podrá ser eliminado. ◦R1.1.3 Los administradores de proyectos se definen por ámbito. El administrador del módulo define para cada ámbito los usuarios que tendrán perfil de administrador de proyecto. •R1.2 Proyectos ◦R1.2.1 La visibilidad de los usuarios sobre los proyectos se definirá por su perfil. En un proyecto pueden intervenir tres roles: gestor, técnico y usuario. Estos roles definen las distintas visibilidades que los participantes tienen del proyecto. ◦R1.2.2 Un proyecto puede tener varios gestores. Pueden existir varios gestores para un mismo proyecto. ◦R1.2.3 Sólo el administrador de proyectos puede eliminar proyectos. Los gestores activarán/desactivarán proyectos. Los proyectos nunca pueden ser eliminados por los gestores de proyectos. A éstos sólo se les debe permitir un "borrado lógico" que consiste en marcar el proyecto como inactivo. Los administradores de proyectos si tienen la potestad de eliminar un proyecto de manera real, pero esta opción sólo debería emplearse en principio para proyectos creados por error. ◦R1.2.4 Posibilidad de configurar campos personalizables por cada tipo de proyecto Cada proyecto tendrá una serie de campos fijos: descripción, reponsable, etc., pero se permitirá también definir campos personalizados. Para este desempeño se hará uso del componente wcaval, ver sección 6.4. ◦R1.2.5 Los proyectos se clasifican por categorías. Existirá una categorización jerárquica de dos niveles que permitirá la clasificación de los proyectos. ◦R1.2.6 Los proyectos pueden estar asociados a una unidad organizativa. Un proyecto puede estar vinculado a una determinada unidad de la organización. ◦R1.2.7 Se podrá asignar un responsable a un proyecto. Un proyecto puede tener un usuario responsable pero a efectos de gestión se considerará responsables a aquellos usuarios que tengan el perfil de gestor en el proyecto. 8/61 Departamento de Ingeniería Telemática Documento de Análisis 2. Catálogo de requisitos •R1.3 Actividades ◦R1.3.1 Deben existir auditorías de acceso a cada objeto registrado. Debe quedar anotado qué usuario realizó cada cambio sobre el objeto. ◦R1.3.2 Debe poderse seguir la "historia" de cada actividad. Los distintos participantes de un proyecto pueden añadir entradas en la historia de una actividad. ◦R1.3.3 Puede existir una relación jerárquica entre actividades. Podrían existir relaciones jerárquicas entre actividades, es decir una actividad puede ser "padre" de otras actividades del proyecto. ◦R1.3.4 Una actividad tiene un único responsable. El responsable de una actividad es único, pero sobre una actividad puedes realizar actualizaciones cualquier otro participante del proyecto siempre con las restricciones establecidas a su perfil. ◦R1.3.5 La visibilidad de los usuarios sobre las actividades será por proyecto y perfil. La visibilidad que los distintos participantes tienen sobre las actividadaes del proyecto está determinada por su perfil en el mismo. ◦R1.3.6 Las actividades tienen asignado un estado: Nueva, En curso, Detenida, Finalizada. Los estados en los que puede encontrarse una activadad están determinados. Las transiciones entre estos estados se especifican en la sección 4. ◦R1.3.7 Las actividades tienen asignado un porcentaje de avance: 0%, 25%, 50%, 75%, 100%. Se puede establecer el trabajo realizado en una actividad en porcentajes preestablecidos. ◦R1.3.8 Posibilidad de configurar campos personalizables por cada tipo de actividad Cada actividad tendrá una serie de campos fijos: esfuerzo estimado, fecha de inicio, etc., pero se permitirá también definir campos personalizados. Para este desempeño se hará uso del componente wcaval, ver sección 6.4. •R1.4 Imputaciones ◦R1.4.1 Las imputaciones se clasifican en categorías preestablecidas. Existirán distintas categorías en las que se clasificarán las imputaciones a las actividades de un proyecto. Estas categorías serán: Gestión, Documentación, Análisis, Diseño, Construcción y Otros. ◦R1.4.2 Se pueden calcular imputaciones totales por actividades y proyectos. El sistema debe permitir la extracción de resumenes de las imputaciones totales por actividades y proyectos. ◦R1.4.3 Cualquier participante de un proyecto puede hacer imputaciones a las actividades del mismo. 9/61 2.2 Usuarios Los requisitos desde el punto de vista de los usuarios del sistema son los siguientes: •R2.1 Administrador del módulo ◦R2.1.1 Parametriza el módulo de gestión de proyectos. El administrador del módulo configura el módulo de gestión de proyectos definiendo: 1. Categorías para la clasificación de proyectos 2. Tipos de proyectos y sus campos personalizados 3. Tipos de actividades y sus campos personalizados ◦R2.1.2 Establece los administradores de proyectos de los distintos ámbitos. El administrador del módulo define los distintos ámbitos y establece los administradores de proyectos para cada ámbito. •R2.2 Administrador de proyectos ◦R.2.2.1 Puede crear proyectos o copiar proyectos anteriores para generar uno nuevo. Un administrador de proyectos puede crear proyectos bien dándolos de alta desde cero o bien partiendo de una copia de un proyecto anterior. ◦R2.2.2 Elimina proyectos y actividades (para casos de error). La eliminación de proyectos sólo debería realizarse en estos casos. Cuando un proyecto está finalizado o deja de presentar interés debería marcarse como "inactivo". ◦R2.2.3 Asigna participantes a los proyectos y les asigna sus perfiles. El administrador de proyectos puede asignar participantes a cualquier proyecto en el ámbito que administra. Esta funcionalidad también está disponible a los gestores de los proyectos pero únicamente para aquellos proyectos que gestionan. ◦R2.2.4 Puede modificar cualquier proyecto en los ámbitos en los que es administrador •R2.3 Gestor de proyectos ◦R2.3.1 Tiene la capacidad de modificar aspectos operativos de los proyectos que gestiona y de sus tareas. ◦R2.3.2 Puede añadir o eliminar actividades de los proyectos que gestiona. Puede definir nuevas actividades en el proyecto y modificar o eliminar las ya existentes. ◦R2.3.3 Puede imputar tiempos a cualquier tarea de los proyectos en los que participa. Como participante de un proyecto puede imputar esfuerzo a cualquier actividad del proyecto. ◦R2.3.4 Puede asignar participantes a los proyectos que gestiona y establecer sus perfiles . Al igual que un administrador de proyectos, el gestor puede asignar participantes a los proyectos, pero únicamente a aquellos que gestiona. 10/61 Departamento de Ingeniería Telemática Documento de Análisis 2. Catálogo de requisitos •R2.4 Técnico ◦R2.4.1 Tiene acceso en modo lectura a cualquier informacion de los proyectos en los que participa. El técnico tiene que tener acceso a la información de los proyectos en los que participa pero no podrá modificar ningún aspecto del mismo. ◦R2.4.2 Puede modificar cualquier tarea perteneciente a los proyectos en los que participa. ◦R2.4.3 Puede escribir en el histórico de cualquier tarea de un proyecto del que sea participante. Puede aportar conocimiento en el histórico de las tareas de los proyectos en los que participa. ◦R2.4.4 Imputa tiempos en las tareas de los proyectos en los que participa. Como participante de un proyecto puede imputar esfuerzo a cualquier actividad del proyecto. •R2.5 Usuario ◦R2.5.1 Tiene acceso en modo lectura a cualquier informacion de los proyectos en los que participa. Este rol tiene acceso a información básica del proyecto pero no debe tener permisos para modificarla. ◦R2.5.2 Tiene acceso en modo lectura a las tareas de los proyectos en los que participa. Debe tener acceso a información básica sobre las tareas, pero no debe poder modificarlas. ◦R2.5.3 Puede escribir en el histórico de cualquier tarea de un proyecto del que sea participante. Puede aportar conocimiento en el histórico de las tareas de los proyectos en los que participa. ◦R2.5.4 Podría imputar tiempos en las tareas de los proyectos en los que participa. Como participante del proyecto puede imputar esfuerzo a cualquier actividad del proyecto. •R2.6 Usuario sin acceso Al tratarse de una aplicación que dispone de varios módulos puede ocurrir que un usuario pueda disponer de un enlace o similar a un proyecto sin ser participante del mismo. A estos usuarios que no son participantes del proyecto se les puede ofrecer una información mínima sobre éste y las tareas que lo componen. ◦R2.6.1 Tiene acceso a una información mínima sobre los proyectos del módulo. Este rol tiene acceso a información mínima sobre el proyecto siempre sólo en lectura. ◦R2.6.2 Tiene acceso a una información mínima sobre las tareas. Debe tener acceso a información mínima sobre las tareas, pero no debe poder modificarlas. 11/61 3 Modelo conceptual de datos En esta sección se presenta el modelo conceptual de datos del sistema. A continuación se describen las entidades y relaciones principales de este diagrama. 3.1 Entidades ◦Scope: Ámbito a los que puede ser asociado un objeto (R1.1.1, R1.1.2) ▪descr: Descripción del ámbito, p.e.: Global1, Granada, Andalucía, Distrito 9, etc. ▪rem: Notas 1 El ámbito global deberá existir por defecto en la base de datos, estará identificado por una clave de valor 0, pero podrá ser eliminado de la aplicación por el administrador del registro. 12/61 Ilustración 4: Diagrama entidad-relación Activ ActivType Activ_wcaval_value ActivType_wcaval_attr ∈ ∈ ∈ ∈ Scope _user _group ∈ attach_Item ∈ SpTime ∈ N 1 1 N N N N 1 1 1 N 1N M N P 1 N Entidades aportadas por el RMIU de WAINE Entidades aportadas por el componente wcaval Proj ProjType Proj_wcaval_value ProjType_wcaval_attr ∈ ∈ ∈ ∈ 1 1 N N N 1 1 ∈ Entidades aportadas por el componente attach Entry ∈ REL_proj_u N Rol ∈ ∈ 1 N N 1N PCL2 ∈ 1 N PCL1 ∈ 1 N ∈ SpTimeType N 1 attach_Category ∈ OUL3 OUL2 ∈ OUL1 ∈ ∈ 1 N 1 N 1 N Entidades del modelo común ∈ N R M ∈ 1 1 ∈ REL_scope_u 1 Departamento de Ingeniería Telemática Documento de Análisis 5. Interfaces de usuario 5.2 Aministrador de proyectos El administrador de proyectos crea proyectos y define sus actividades. Las principales interfaces de usuario empleadas por el administrador de proyectos son las siguientes: 5.2.1 Administración de proyectos Con esta interfaz de usuario, un administrador de proyectos puede dar de alta proyectos, definir sus actividades y establecer sus participantes (R2.2.4). Un administrador de proyectos tiene visibilidad sobre todos los proyectos de los ámbitos a los que está asociado. Desde esta interfaz de usuario el administrador del módulo puede lanzar dos acciones no básicas: 1. Clonar: Realiza una copia del proyecto actual con las siguientes características (R2.2.1): ◦Nombre: "Copia de "+<Nombre_original>+ " 9999-99-99 99:99:99" ◦Ámbito: El mismo del proyecto original. ◦Unidad Organizativa, Notas, Responsable: Nulo ◦Actividades: Idénticas a las del proyecto original con las siguientes modificaciones: ▪Estado: Nueva ▪Avance: 0% ▪Fecha de inicio, Fecha de fin, Responsable: Nulo 2. Informe: Genera el informe que se detalla en la sección 5.2.3. 19/61 Ilustración 9: Unidad de interacción para la administración de proyectos Pestaña detalles La pestaña de detalles de un proyecto permite la consulta del resto de campos de la entidad. 5.2.1.1 Pestaña Actividades La pestaña actividades (se muestra en la figura 9) permite gestionar los datos principales de una actividad y posteriormente acceder a la interfaz de usuario de gestión de actividades ampliada (descrita en la sección 5.2.2) para completar información referente a la misma si fuera necesario (R1.3.5, R2.2.2, R2.3.2). 5.2.1.2 Pestaña Propiedades La pestaña propiedades permite asignar valores a los campos personalizados de un proyecto (R1.2.4). Estas propiedades fueron asignadas a cada tipo de proyecto concreto con la interfaz mostrada en la sección 5.1.2. Se hace uso en este caso de la formulario wcaval.form.value del paquete wcaval para asignar valores a los campos personalizables de un proyecto (ver sección 6.4). 20/61 Ilustración 11: Pestaña Propiedades Ilustración 10: Edición de proyectos (Detalles) Departamento de Ingeniería Telemática Documento de Análisis 5. Interfaces de usuario 5.2.1.3 Pestaña Adjuntos La pestaña adjuntos posibilita adjuntar documentos a un proyecto (R1.2.9). Se hará uso en este caso del formulario attach.form.catattach del paquete attach (ver sección 6.5). 5.2.1.4 Pestaña Miembros La pestaña miembros permite especificar los usuarios que participan en el proyecto así como sus roles (R2.2.3). El par usuario-rol debe ser único para los miembros de un proyecto. 5.2.1.5 Pestaña Histórico La pestaña histórico muestra los comentarios de las actividades del proyecto en orden cronológico (R1.3.2). Esta pestaña debe permitir el acceso a la interfaz de usuario de gestión de actividades ampliada para gestionar información referente a la actividad. 21/61 Ilustración 12: Pestaña Adjuntos Ilustración 13: Gestión de proyectos (miembros) Ilustración 14: Gestión de proyectos (Histórico) 5.2.1.6 Pestaña dedicación Se trata de una pestaña meramente informativa. Esta pestaña muestra las imputaciones realizadas al proyecto en orden cronológico (R1.4.3). Esta pestaña debe permitir el acceso a la interfaz de usuario de gestión de actividades ampliada para gestionar información referente a la actividad. 5.2.1.7 Pestaña Esfuerzo Esta pestaña genera un resumen de la dedicación del proyecto en función del tipo de dedicación que se ha realizado (R1.4.2). 22/61 Ilustración 16: Gestión de proyectos (esfuerzo) Ilustración 15: Edición de actividades (Detalles) Departamento de Ingeniería Telemática Documento de Análisis 5. Interfaces de usuario 5.2.2 Gestión de actividades ampliada La unidad de interacción de gestión de actividades ampliada permite a los roles administrador y gestor modificar cualquier aspecto relevante de una actividad (R2.3.1). 23/61 Ilustración 17: Unidad de interacción para la gestión de actividades ampliada Pestaña detalles La pestaña de detalles de una actividad permite la consulta del resto de campos de la entidad. 5.2.2.1 Pestaña histórico Esta pestaña, se muestra en la figura 9, habilita la edición de comentarios (R1.3.2). 5.2.2.2 Pestaña Actividades Hijas La pestaña actividades (se muestra en la figura 9) permite gestionar los datos principales de las actividades hija de la actividad actual y posteriormente acceder a la interfaz de usuario de gestión de actividades ampliada (descrita en la sección 5.2.2) para completar información referente a la misma si fuera necesario. 24/61 Ilustración 18: Edición de actividades (Detalles) Ilustración 19: Actividades hijas Departamento de Ingeniería Telemática Documento de Análisis 5. Interfaces de usuario 5.2.2.3 Pestaña Propiedades La pestaña propiedades permite asignar valores a los campos personalizados de una actividad (R1.3.8). Estas propiedades fueron asignadas a cada tipo de actividad concreta con la interfaz mostrada en la sección 5.1.2. Se hace uso en este caso de la formulario wcaval.form.value del paquete wcaval para asignar valores a los campos personalizables de un proyecto (ver sección 6.4). 5.2.2.4 Pestaña Adjuntos La pestaña adjuntos posibilita adjuntar documentos a una actividad (R1.3.10). Se hará uso en este caso del formulario attach.form.catattach del paquete attach (ver sección 6.5). 25/61 Ilustración 20: Pestaña Propiedades Ilustración 21: Pestaña Adjuntos 5.2.2.5 Pestaña dedicación Se trata de una pestaña meramente informativa. Esta pestaña muestra las imputaciones realizadas a la actividad en orden cronológico (R1.4.3). Esta pestaña debe permitir el acceso a la interfaz de usuario de gestión de actividades ampliada para gestionar información referente a la actividad. 5.2.2.6 Pestaña Esfuerzo Esta pestaña genera un resumen de la dedicación de la actividad en función del tipo de dedicación que se ha realizado (R1.4.2). 26/61 Ilustración 23: Gestión de proyectos (esfuerzo) Ilustración 22: Edición de actividades (Detalles) Departamento de Ingeniería Telemática Documento de Análisis 5. Interfaces de usuario 5.2.3 Informe del proyecto Desde varias unidades de interacción es posible genera el que denominamos informe del proyecto (R1.2.8). Este informe tiene el siguiente formato: 27/61 Ilustración 24: Informe del proyecto 5.3 Gestor de proyectos La dedicación principal de los gestores de proyectos es la gestión de los proyectos que se les han asignado. 5.3.1 Gestión de proyectos La unidad de interacción principal de este rol es la de gestión de proyectos. Esta interfaz permite al gestor visualizar un resumen del estado de los proyectos que gestiona y desde ella acceder al detalle de un proyecto en particular. Desde de esta interfaz, el gestor del proyecto puede acceder a una visión de gestión de proyectos ampliada. 5.3.2 Gestión de proyectos ampliada Esta interfaz de usuario permite al gestor de proyectos manejar toda la información del proyecto, así como tener acceso a la información más relevante de las actividades del mismo (R2.3.1). 28/61 Ilustración 25: Unidad de interacción para la Gestión de proyectos Departamento de Ingeniería Telemática Documento de Análisis 5. Interfaces de usuario 5.4.3.2 Pestaña Miembros La pestaña miembros permite visualizar los participantes del proyecto así como sus roles. 5.5 Usuario Los usuarios regulares tienen una visión de lectura de los proyectos y actividades en los que participan. Únicamente les está permitido realizar anotaciones sobre las actividades. 5.5.1 Visualización de proyectos para el usuario Los usuarios tienen acceso a información básica sobre el proyecto (R2.5.1). 35/61 Ilustración 36: Unidad de interacción para la visualización de proyectos del perfil usuario Ilustración 35: Visualización de proyectos (usuarios) Desde esta la pestaña actividades el usuario tiene acceso a la visualización de actividades (R2.5.2). 36/61 Ilustración 37: Unidad de interacción para la visualización de actividades del perfil usuario Departamento de Ingeniería Telemática Documento de Análisis 5. Interfaces de usuario 5.5.1.1 Pestaña Adjuntos La pestaña adjuntos posibilita al usuario adjuntar documentos a un proyecto (R1.2.9). Se hará uso en este caso del formulario attach.form.catattach del paquete attach. 5.5.1.2 Pestaña Miembros La pestaña miembros permite especificar los usuarios que participan en el proyecto así como sus roles. El par usuario-rol debe ser único para los miembros de un proyecto. 5.5.1.3 Pestaña Histórico La pestaña histórico muestra los comentarios de las actividades del proyecto en orden cronológico (R2.5.3, R2.5.4). Esta pestaña debe permitir el acceso a la interfaz de usuario de gestión de actividades ampliada para gestionar información referente a la misma. 37/61 Ilustración 38: Pestaña Adjuntos Ilustración 39: Visualización de proyectos (usuarios) Ilustración 40: Gestión de proyectos (Histórico) 5.6 Usuario sin acceso al módulo Al tratarse de una aplicación modular, es posible que usuarios de otros módulos alcancen a través de comentarios u otros elementos a la visualización de proyectos a actividades. A ellos únicamente se les permitirá el acceso a la información básica de los mismos. Si necesitan más información deberan solicitarla al responsable bien del proyecto, bien de la actividad.. 5.6.1 Visualización de proyectos para usuarios sin acceso al módulo Esta unidad de interacción permite a usuarios sin acceso al módulo visualizar la información básica de un proyecto (R2.6.1). 5.6.2 Visualización de actividades para usuarios sin acceso al módulo Esta unidad de interacción permite a usuarios sin acceso al módulo visualizar la información básica de una actividad (R2.6.2). 38/61 Ilustración 41: Unidad de interacción para la visualización de proyectos a usuarios sin acceso Ilustración 42: Unidad de interacción para la visualización de actividades a usuarios sin acceso Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos 6 Anexos 39/61 Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos 6.1 Winter 6.1.1 Introducción La gestión de los Sistemas de Información en las grandes organizaciones puede llegar a ser muy compleja. En casos extremos, un organismo puede manejar cientos de aplicaciones que son utilizadas por miles de usuarios. En este tipo de entornos puede ser realmente difícil responder en este a preguntas como: ¿qué sistema de información requiere una inversión estratégica?¿qué equipo de desarrollo mantiene la aplicación X?¿a qué información tiene acceso el usuario U?. Sin embargo, disponer de respuestas a estas preguntas de forma ágil es fundamental para la gobernanza TIC de la organización. En este artículo se propone un modelo de hyper-integración para los sistemas de información. En el modelo propuesto, la información, las aplicaciones, los procesos y las personas (usuarios, desarrolladores, gestores, etc.) conviven en un único entorno de información. La aplicación de este modelo conllevaría interesantes consecuencias que son analizadas en este artículo. Los autores realizan esta propuesta tras la experiencia en el desarrollo de un sistema que pretende dar solución a un problema particular, pero evolucionó de forma radical y fué capaz de adaptarse a nuevas necesidades del cliente conviertiéndose finalmente en un entorno en el que se fue integrando una parte importante del conocimiento del organismo. 6.1.2 El problema original Desde un organismo público del gobierno regional nos solicitaron asesoramiento para la resolución de un problema. En este organismo disponían de un elevadísimo número de bases de datos relacionales y deseaban explotar su información. El cliente deseaba atacar directamente a las bases de datos empleando consultas realizadas a medida. Estas consultas se debían clasificar según su temática y las distintas categorías definidas se pondrían a disposición de los usuarios en función de su perfil. El objetivo final era desarrollar una única aplicación a través de la cual los usuarios tuvieran visibilidad sobre la información ofrecida por los distintos grupos de consultas. En esta figura se presenta un resumen de la problemática planteada. Sobre las bases de datos implicadas (DB1, DB2, etc.) se pueden definir diversas consultas de interés (q1.1, q1.2, q2.1, etc.). Estas consultas son agrupadas en conjuntos según su función (query set 1, query set 2, etc.) . Cada usuario o grupo de usuarios puede acceder a varios de estos conjuntos en función de su perfil. Algunos condicionantes de importancia del sistema eran: 1. El número de consultas a crear era enorme (cientos), así como las bases de datos implicadas. 2. Los plazos para llevar a cabo el desarrollo eran muy ajustados y los módulos finalizados debían ponerse a disposición de los usuarios de 1/61 forma inmediata 3. Las bases de datos origen sufrirían modificaciones continuas durante su vida, por lo que la solución propuesta debía ser flexible y capaz de adaptarse a cambios en los datos fácilmente. 4. El sistema pasaría a ser mantenido por personal del propio organismo una vez fuera entregado, por lo tanto, el mantenimiento de la solución debía ser sencillo y ágil. 6.1.3 La solución propuesta En este escenario se desechó el proceso de desarrollo tradicional formado por fases secuenciales de análisis, diseño y construcción: ● Un desarrollo de este tipo concluiría con la obtención y entrega del producto software finalizado, pero en un plazo de tiempo inadmisible (tras realizar el análisis de cientos de bases de datos y crear una enorme cantidad de consultas e interfaces de usuario). Además, dilatar tanto la entrega del producto final generaría una gran incertidumbre sobre el éxito del proyecto. ● Por otra parte, los productos monolíticos de gran tamaño presentan un mantenimiento complejo. Esto es un inconveniente importante cuando sabemos con antelación que la estará sometida a evoluciones y cambios continuos. Es necesario también tener en cuenta que el mantenimiento sería realizado por personal del propio organismo que no habría participado en el desarrollo del proyecto, por lo tanto, era fundamental asegurarse de que el mantenimiento del proyecto sería un éxito. Desde nuestro punto de vista era primordial proponer un modelo más ágil que permitiera poner a disposición del cliente una aplicación mínima de forma casi inmediata y en la que paulatinamente se irían integrando diferentes módulos. Esto minimizaría la incertidumbre tanto del cliente como del equipo de desarrollo y a su vez permitiría tratar a la aplicación como un conjunto de componentes integrados en lugar de como como un programa monolítico. La aplicación debería gestionar los módulos desarrollados junto con su documentación asociada. Esta información sería la base del proceso de mantenimiento una vez que la aplicación fuera entregada. La naturaleza del problema, en la que los datos provienen de una plétora de orígenes, donde sólo sería necesaria la presentación de los mismos, junto a la necesidad de disponer rápidamente la aplicación en funcionamiento nos impulsó a emplear nuestro MB-UIDE para su construcción. WAINE (Web Application INterface Engine) es un MB-UIDE que genera aplicaciones web basadas en el paradigma del formulario. Aunque originalmente fue diseñado para facilitar el desarrollo sistemático de la interfaz de usuario a estudiantes de ingeniería, ha sido empleado con éxito para desarrollar varios proyectos. Dado que el producto se construiría con WAINE y conceptualmente se trataba de un sistema integrador de módulos decidimos llamar al proyecto WAINE INTEgratoR o WINTER. 6.1.3.1 El proceso de desarrollo Para conseguir nuestro propósito era necesario trabajar en dos líneas de desarrollo paralelas: 1. La construcción de las consultas necesarias junto a su presentación 2. El desarrollo de Winter 2/61 Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos En la primera línea, para cada consulta a integrar sería necesario realizar un estudio profundo de las bases de datos involucradas. El proceso de desarrollo propuesto requeriría de las siguientes actividades: 1. Identificar junto con los usuarios expertos la base de datos afectada y la información a extraer para la consulta. a. Se identificaría la base de datos implicada: nombre, tipo, parámetros de conexión, etc. b. Si no se dispone de documentación de la base de datos a tratar, se procedería a su análisis y documentación. c. Por último se documentaría la consulta a realizar, tablas implicadas, columnas seleccionadas, orden, agrupación, etc. 2. Construcción de la consulta. El producto de esta actividad sería el código SQL necesario para la ejecución de la consulta. 3. Establecer los perfiles/usuarios con acceso a la información. Para definir este aspecto se construye un catálogo de usuarios con acceso a los datos. 4. Especificación de las interfaces de usuario que mostrarán los datos de la consulta. Para ello empleamos Diagramas ER-anotados. 5. Construcción de las Interfaces de usuario. Describiendo cada uno de los contenedores y formularios necesarios en lenguaje ASL. Para el desarrollo de winter (segunda línea) se seguiría el proceso habitual empleado en los proyectos basados en WAINE: 1. Análisis. En esta fase se elabora un documento en el que se describen los roles de los usuarios, las funcionalidades de la aplicación y los bocetos de las principales interfaces de usuario e informes empleados por cada rol. 2. Modelado de conceptos. Tomando como base el documento de análisis se elaboran dos documentos: (a) la tabla de roles/funcionalidades que indica las acciones e interfaces de usuario necesarias para cada rol y (b) el modelo conceptual de la base de datos que se plasma en un Diagrama Entidad-Relación. 3. Anotación del Diagrama Entidad-Relación. El objetivo de esta fase es especificar cada unidad de interacción de la interfaz de usuario. Para ello se toma la porción de Diagrama Entidad-Relación afectada por la unidad de interacción que se está definiendo y se enriquece anotando sobre él los componentes que tomarán parte en su construcción. 4. Especificación en ASL. Los desarrolladores partiendo de la tabla rol/funcionalidad y los Diagramas Entidad-Relación anotados crean un documento codificado en lenguaje ASL. 5. Generación de repositorios y personalización. El proceso finaliza con la generación de los repositorios usados por el Run-time de WAINE y especificando aspectos concretos de la 3/61 interfaz de usuario (colores, bordes, fuentes, etc.) si fuera necesario. 6.1.3.2 La aplicación Winter Pasamos en este apartado a describir los aspectos más relevantes de la aplicación Winter. Tabla Rol/Funcionalidad La aplicación define tres roles posibles: 1. usuario: Accede a los distintos conjuntos de consultas que tiene asignados empleando un elemento que denominamos panel. A través de los paneles los usuarios tienen acceso a la visualización de las consultas así como a la ejecución de acciones. 2. administrador: Administra a los distintos usuarios del sistema y les concede acceso a los paneles disponibles según su perfil. El administrador también aprueba nuevas versiones de la aplicación. 3. desarrollador: Pueden visualizar cualquier panel así como definir nuevos paneles, consultas, interfaces de usuario, etc. En la siguiente tabla se presenta un resumen las funcionalidades de principales asociadas a cada rol: Funcionalidad Usuario Desarrollador Administrador Listado de paneles definidos ✓ ✓ ✓ Visualización paneles asignados ✓ Visualización de todos los paneles ✓ Edición de paneles ✓ Edición de unidades de interacción ✓ Edición de acciones ✓ Configuración de orígenes de datos ✓ Desarrollo ASL ✓ Desarrollo SQL ✓ Definición de versión ✓ Gestión de usuarios ✓ Aprobar versiones ✓ 4/61 Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos Modelo de dominio De forma resumida, el modelo conceptual de datos para soportar la aplicación winter es el siguiente: Los usuarios se clasifican en grupos de acuerdo a su rol. Cada usuario puede tener acceso a varios paneles y un mismo panel puede ser accedido por varios usuarios (la fecha de último acceso de cada usuario a un panel queda recogida en el modelo). Los paneles tienen diversas secciones y en ellas podemos encontrar varios lanzadores. Un lanzador puede tener asociada una acción, una unidad de interacción o una URL. El resto del diagrama sintetiza el proceso de desarrollo. Los desarrolladores, también usuarios del sistema, construyen ficheros ASL, SQL o de cualquier otro tipo que son vinculados a una determinada versión. Las versiones son aprobadas por el administrador del sistema y en ese momento se generan unidades de interacción, acciones, etc. Especificación de las unidades de interacción Para concluir esta sección presentamos la definición de alguna de las unidades de interacción más interesantes de la aplicación. Para la especificación de estas unidades empleamos diagramas ER- anotados. 5/61 Ilustración 43: Modelo de dominio de la aplicación winter •bvs: cadena de inicio de valor •evs: vadena de fin de valor •vq: comillas a usar con el valor •Unidades de interacción y formularios •wcaval.struct.regexp: Unidad de interacción utilizada para la definición de tipos de datos y expresiones regulares. •wcaval.form.attr: Formulario empleado para definir los campos personalizables de un tipo de objeto. •wcaval.form.value: Formulario empleado para asignar valores de los campos personalizables de un objeto. 12/61 Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos •Widgets. wcaval define un par de widgets trabajan colaborativamente en el formulario wcaval.form.value para la validación de los valores de los campos introducidos: •wcaval.Attr •wcaval.Value 6.4.2 Ejemplos •Unidad de interacción para definir atributos para tipos de entidades (tabla Entity_type) <struct id="s_objtypes" type="relation"> <param name="form_split" value="rows=33%,*"/> <param ord="1" name="formid" value="fdescr.form.descr"/> <param ord="1" name="form_source" value="Entity_type"/> <param ord="1" name="form_type" value="form"/> <param ord="1" name="form_caption" value="Tipos de Objetos"/> <param ord="1" name="navigator_position" value="W"/> <param ord="1" name="navigator_fields" value="1"/> <param ord="1" name="button_data" value="1"/> <param ord="2" name="formid" value="wcaval.form.attr"/> <param ord="2" name="form_source" value="Entity_type_wcaval_attr"/> <param ord="2" name="form_type" value="table"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Unidad de interacción que permite la asignación de valores a los campos de una entidad. <struct id="s_objects" type="relation"> <param name="form_split" value="rows=33%,*"/> <param ord="1" name="formid" value="f_object"/> <param ord="1" name="form_type" value="form"/> <param ord="1" name="navigator_position" value="W"/> <param ord="1" name="navigator_fields" value="descr"/> <param ord="1" name="button_data" value="1"/> 13/61 <param ord="2" name="formid" value="wcaval.form.value"/> <param ord="2" name="form_source" value="Entity_wcaval_value"/> <param ord="2" name="form_type" value="table"/> <param ord="2" name="form_theme" value="wcaval_0.1/buttons.cfg"/> <param ord="2" name="button_update" value="1"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Ejemplos de uso de la función Entity_wcaval_linear •HTML: SELECT Entity_wcaval_linear(1,f,'<table>','</table>', '<tr>','</tr>','<td><b>','</b></td>','','<td>','</td>','') <table><tr><td><b>Brand</b></td><td>HP</td></tr><tr><td><b>Model</ b></td><td>Pavilion 15-BC450</td></tr><tr><td><b>Price</b></td><td>645.23</td></tr><tr>< td><b>CPU</b></td><td>Intel Core i5 8300H / 2.3 GHz</td></tr><tr><td><b>RAM size</b></td><td>8</td></tr><tr><td><b>RAM type</b></td><td>DDR4</td></tr><tr><td><b>Hard Disk</b></td><td>SDD</td></tr><tr><td><b>HD size</b></td><td>1024</td></tr></table> •XML : SELECT Entity_wcaval_linear(1,f,'<fields>','</fields>', '<field>','</field>','<attr>','</attr>','','<value>','</value>','') <fields><field><attr>Brand</attr><value>HP</value></field><field><at tr>Model</attr><value>Pavilion 15-BC450</value></field><field><attr>Price</attr><value>645.23</valu e></field><field><attr>CPU</attr><value>Intel Core i5 8300H / 2.3 GHz</value></field><field><attr>RAM size</attr><value>8</value></field><field><attr>RAM type</attr><value>DDR4</value></field><field><attr>Hard Disk</attr><value>SDD</value></field><field><attr>HD size</attr><value>1024</value></field></fields> •CSV : SELECT Entity_wcaval_linear(1,t,'','','','','',';','\'','',';','\'') 'Brand';'HP';'Model';'Pavilion 15- BC450';'Price';'645.23';'CPU';'Intel Core i5 8300H / 2.3 GHz';'RAM size';'8';'RAM type';'DDR4';'Hard Disk';'SDD';'HD size';'1024' •JSON: SELECT Entity_wcaval_linear(1,t,'{','}','','','',':','"','',',','"') {"Brand":"HP","Model":"Pavilion 15- BC450","Price":"645.23","CPU":"Intel Core i5 8300H / 2.3 GHz","RAM size":"8","RAM type":"DDR4","Hard Disk":"SDD","HD size":"1024"} 14/61 Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos •TEXT: SELECT Entity_wcaval_linear(1,f,'','','',E'\n','- ',':','','','','') - Brand: HP - Model: Pavilion 15-BC450 - Price: 645.23 - CPU: Intel Core i5 8300H / 2.3 GHz - RAM size: 8 - RAM type: DDR4 - Hard Disk: SDD - HD size: 1024 15/61 6.5 Paquete attach El paquete attach ofrece interfaces de usuario para el uso de adjuntos en cualquier aplicación WAINE. Los adjuntos pueden estar clasificados y por defecto tienen protección de modificación y borrado, es decir, sólo puede borrar o eliminar un ajunto quien lo creó. Estas restricciones pueden ser eliminadas (ver sección de ejemplos ). 6.5.1 Funcionalides El paquete provee elementos de los modelos de presentación y dominio. En cuanto a la presentación ofrece los siguientes elementos: •attach.struct.category: Administración de categorías de adjuntos •attach.struct.search: Búsqueda de adjuntos •attach.struct.nocatsearch: Búsqueda de adjuntos sin categoría (para los casos en que no se empleen categoría) •attach.struct.listall: Lista de todos los adjuntos del sistema 16/61 Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos •attach.form.catattach: Formulario para la gestión de adjuntos. En la sección de ejemplos puede ver cómo emplearlo en sus aplicaciones •attach.form.category: Formulario para la manipulación de categorías 6.5.2 Ejemplos •Adjunto con todas sus características: categorías, protección de borrado y actualización <struct id="s_catattachpud" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="1"/> <param ord="1" name="source_row" value="0"/> <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> <param ord="2" name="form_type" value="table"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="fields_remove" value="5:7"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Adjunto con categoría prefijada, protección de borrado y actualización <struct id="s_fixcatattachpud" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> 17/61 <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="2"/> <param ord="1" name="source_row" value="0"/> <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> <param ord="2" name="form_type" value="table"/> <param ord="2" name="fields_modify[0]" value="defvalue#2#3"/> <!-- Asignando categoría --> <param ord="2" name="fields_remove" value="5:7"/> <param ord="2" name="fields_readonly" value="3"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Adjunto sin categoría pero con protección de borrado y actualización <struct id="s_uncatattachpud" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="3"/> <param ord="1" name="source_row" value="0"/> <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> <param ord="2" name="form_type" value="table"/> <param ord="2" name="fields_remove" value="3:5:7"/> <!-- Se elimina también el campo categoría --> <param ord="2" name="button_data" value="1"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Adjunto concategorías y protección de borrado <struct id="s_catattachpd" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="1"/> <param ord="1" name="source_row" value="0"/> 18/61 Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> <param ord="2" name="form_type" value="table"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="fields_hidden" value="6"/> <param ord="2" name="fields_remove" value="5:7"/> <param ord="2" name="event_beforeupdate" value="0"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Adjunto con categoría prefijada y protección de borrado <struct id="s_fixcatattachpd" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="2"/> <param ord="1" name="source_row" value="0"/> <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> <param ord="2" name="form_type" value="table"/> <param ord="2" name="fields_modify[0]" value="defvalue#2#3"/> <param ord="2" name="fields_hidden" value="6"/> <param ord="2" name="fields_remove" value="5:7"/> <param ord="2" name="fields_readonly" value="3"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="event_beforeupdate" value="0"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Adjunto sin categoría con protección de eliminación <struct id="s_uncatattachpd" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="3"/> <param ord="1" name="source_row" value="0"/> <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> 19/61 <param ord="2" name="form_type" value="table"/> <param ord="2" name="fields_hidden" value="6"/> <param ord="2" name="fields_remove" value="3:5:7"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="event_beforeupdate" value="0"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Adjunto concategorías sin protección <struct id="s_catattach" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="1"/> <param ord="1" name="source_row" value="0"/> <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> <param ord="2" name="form_type" value="table"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="fields_hidden" value="4:6"/> <param ord="2" name="fields_remove" value="5:7"/> <param ord="2" name="event_beforeupdate" value="0"/> <param ord="2" name="event_beforedelete" value="0"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Adjunto con categoría prefijada sin protección <struct id="s_fixcatattach" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="2"/> <param ord="1" name="source_row" value="0"/> <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> <param ord="2" name="form_type" value="table"/> <param ord="2" name="fields_modify[0]" value="defvalue#2#3"/> <param ord="2" name="fields_hidden" value="4:6"/> <param ord="2" name="fields_remove" value="5:7"/> <param ord="2" name="fields_readonly" value="3"/> 20/61 Departamento de Ingeniería Telemática Documento de Análisis 6. Anexos <param ord="2" name="button_data" value="1"/> <param ord="2" name="event_beforeupdate" value="0"/> <param ord="2" name="event_beforedelete" value="0"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> •Adjunto sin categorías ni protección <struct id="s_uncatattach" type="relation"> <param name="form_split" value="rows=18%,*"/> <param ord="1" name="formid" value="f_entry"/> <!-- Formulario con datos genéricos --> <param ord="1" name="form_type" value="table"/> <param ord="1" name="fields_readonly" value="1"/> <param ord="1" name="source_filter_field" value="pk"/> <param ord="1" name="source_filter_value" value="3"/> <param ord="1" name="source_row" value="0"/> <param ord="2" name="formid" value="attach.form.catattach"/> <!-- Formulario con adjuntos a los datos anteriores --> <param ord="2" name="form_type" value="table"/> <param ord="2" name="fields_hidden" value="4:6"/> <param ord="2" name="fields_remove" value="3:5:7"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="event_beforeupdate" value="0"/> <param ord="2" name="event_beforedelete" value="0"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> Bibliografía 1: , , , http://www.waine.org 2: A. Delgado, A. Estepa, J.A. Troyano, R. Estepa, Reusing UI elements with Model-Based User Interface Development, 2016 21/61 Departamento de Ingeniería Telemática Plan del trabajo de fin de grado 3. Ejecución temporal Como se puede observar en el diagrama de Gantt las diferentes fases del proyecto han sido: 1. Formación y Aprendizaje. 2. Análisis. 3. Diseño. 4. Implementación. 5. Implantación. 6. Cierre. La primera fase, Formación y Aprendizaje, ha durado en torno a un mes (17/07/19-20/08/19). Para aprender a utilizar el entorno de desarrollo WAINE y el lenguaje ASL se han realizado 3 ejercicios de ejemplo así como una lectura de artículos y documentos relacionados con el proyecto y WAINE. Después, se realizó una recopilación de información sobre la creación de interfaces de usuario visualizando otras aplicaciones creadas con WAINE. Asimismo, se realizó una lectura y comprensión de códigos ASL de aplicaciones de ejemplo. Finalmente, para terminar esta fase se realizó una búsqueda de información sobre el empleo de base de datos PostgreSQL así como un repaso al lenguaje SQL. La segunda fase, Análisis, ha durado poco tiempo ya que únicamente se tuvo que realizar el Plan de Proyecto. El Documento de Análisis fue realizado por el tutor del proyecto. Las dos siguientes fases (Diseño e Implementación) se han ido realizando paralelamente ya que algunas partes de una fase dependían de otra partes de la otra fase y viceversa. La tercera fase, Diseño, fue más compleja ya que se tuvo que crear un DER anotado por cada espacio de trabajo de la interfaz de usuario mediante un proceso de refinamiento a partir del DER (Diagrama Entidad-Relación) obtenido en la fase de Análisis. Además, como durante casi todo el ciclo de vida del proyecto se ha estado en continúa retroalimentación dichos DER anotados se han tenido que ir modificando según las necesidades. Finalmente, para dar por concluida esta fase se ha realizado el Documento de Diseño explicando y aclarando cada parte de sí mismo para una mejor comprensión del proyecto. La cuarta fase, Implementación, fue la más complicada ya que primero se tuvo que crear, a partir del DER, el código SQL para generar las tablas del módulo de gestión de proyectos para la BD (Base de Datos). Después, tomando la tabla rol/funcionalidad y los DER anotados se creó el correspondiente código ASL donde especificamos los modelos de la interfaz de usuario de WAINE. Debido a los continuos problemas y necesidades que fueron apareciendo se tuvo que adaptar el código SQL y realizar una codificación paralela de ambos ficheros (código SQL y código ASL), como se puede observar en el diagrama de Gantt. Estos dos códigos fueron la parte del proyecto en la que se empleó mayor esfuerzo debido a la gran complejidad de las funcionalidades necesarias. Según el diagrama de Gantt, parece que los Manuales de Usuario acapararon bastantes días (06/01/20-23/06/20), pero no fue el caso. Del 06/01/20-10/01/20 se realizó una primera versión de los Manuales de Usuario y, debido a algunas modificaciones que se tuvieron que realizar en las interfaces de usuario, se tuvieron que modificar dichos manuales y realizar la versión final del 20/01/20-23/01/20. El tiempo dedicado a cada fase se ha medido utilizando el programa TaskCoach que permite realizar un seguimiento de las tareas. 7/8 4 Recursos En este apartado detallamos los recurssos hardware y software que se emplearán en este trabajo de fin de grado. Recursos hardware •masai.us.es (193.147.162.156) ◦Dell PoweEdge 860 ◦CPU ◦RAM ▪2 x 1GB 2RX8 NANYA PC2-5300E (NT1GT72U8PB0BY-3C) ▪2 x 1GB 2RX8 Kingston PC2-5300E (KD6502-ELG) ◦Almacenamiento ▪2 x 2TB Western Digital Red (WD20EFRX) ▪WCC4M2FEJT74 ▪WCC4M5KTJKS6 •waine.us.es (193.147.162.180) ◦Máquina virtual ◦Servicios ▪SSH (22) ▪Web (80) Recursos software •Dia 0.97.2 •Visual Studio Code •LibreOffice 5.0.5.2 •Notepad++ •Pencil 2.0.5 •TaskCoach 1.4.3 •Gantt Project 2.8.10 •FreeMind 0.9.0 •Lucidchart •tohtml.com 8/8 Departamento de Ingeniería Telemática Documento de Diseño Documento de diseño de Módulo de Gestión de Proyectos de GTI Pablo Mora Galindo, [email protected] 10/02/2020 Índice 1 Introducción.......................................................................................................................................5 2 Arquitectura del sistema....................................................................................................................5 3 Modelo físico de datos.......................................................................................................................7 4 Arquitectura de módulos del sistema...............................................................................................12 4.1 Funciones.................................................................................................................................12 4.1.1 TPROC_Activ_pents().....................................................................................................12 4.1.2 TPROC_Proj_ets()...........................................................................................................12 4.1.3 TPROC_Proj_etsnull().....................................................................................................12 4.1.4 CopyProj(bigint, bigint, bigint)........................................................................................12 4.2 Eventos.....................................................................................................................................13 4.2.1 TRI_Activ_pents..............................................................................................................13 4.2.2 TRI_Proj_ets....................................................................................................................13 4.2.3 TRI_Proj_etsnull..............................................................................................................13 4.2.4 Evento "Eliminar actividad"............................................................................................13 4.2.5 Evento "Eliminar imputaciones"......................................................................................14 4.2.6 Evento "Inserción de usuarios"........................................................................................14 5 Diseño de las interfaces de usuario.................................................................................................15 5.1 Administrador del módulo.......................................................................................................16 5.1.1 Clasificación de proyectos – gti.pm.cprojcatalog1..........................................................16 5.1.2 Definición de tipos de proyectos - gti.pm.ctiposproy......................................................17 5.1.3 Definición de tipos de actividades - gti.pm.ctiposactiv...................................................17 5.1.4 Ámbitos y administradores - gti.pm.cscope.....................................................................18 5.2 Administrador de proyectos.....................................................................................................18 5.2.1 Administración de proyectos - gti.pm.cproj.....................................................................18 5.2.2 Gestión de actividades ampliada - gti.pm.cactiv..............................................................20 5.3 Gestor de proyectos.................................................................................................................22 5.3.1 Gestión de proyectos - gti.pm.cprojsearch.......................................................................22 5.3.2 Gestión de proyectos ampliada - gti.pm.cproj2_ro..........................................................22 5.3.3 Gestión de actividades - gti.pm.cactivsearch...................................................................23 5.3.4 Gestión de actividades ampliada - gti.pm.cactiv..............................................................24 5.4 Técnico.....................................................................................................................................24 5.4.1 Lista de actividades - gti.pm.cactivlist.............................................................................24 5.4.2 Visualización de proyecto - gti.pm.cproj2_ro2................................................................25 5.4.3 Edición de actividades - gti.pm.cactiv_ro........................................................................25 5.5 Usuario.....................................................................................................................................26 5.5.1 Visualización de proyectos para usuarios - gti.pm.cprojuser...........................................27 1/54 5.5.2 Visualización de actividades para usuarios - gti.pm.cactiv_user.....................................27 5.6 Usuario sin acceso al módulo..................................................................................................28 5.6.1 Visualización de proyectos para usuarios sin acceso al módulo - gti.pm.cprojuser_na...29 5.6.2 Visualización de actividades para usuarios sin acceso al módulo - gti.pm.cactivuser_na ...................................................................................................................................................29 6 Casos de uso reales..........................................................................................................................30 6.1 Definir administrador de proyectos por ámbito.......................................................................30 6.2 Creación de un proyecto..........................................................................................................32 6.3 Búsqueda y Gestión de proyectos............................................................................................34 6.4 Búsqueda de actividades por parte de un Técnico...................................................................37 6.5 Visualización de una actividad por parte de un Usuario..........................................................40 7 Especificaciones de Construcción...................................................................................................42 8 Carga inicial de datos......................................................................................................................43 9 Plan de pruebas técnico...................................................................................................................45 9.1 Tabla de Pruebas......................................................................................................................45 9.2 Matriz de Trazabilidad.............................................................................................................53 10 Requisitos de implantación...........................................................................................................54 Índice de figuras Figura 1: Diagrama de despliegue........................................................................................................5 Figura 2: Modelo físico de datos..........................................................................................................7 Figura 3: Esquema ejemplo Función Clonar......................................................................................13 Figura 4: Esquema Menú Admin. del módulo....................................................................................16 Figura 5: ERD anotado Clasificación de proyectos...........................................................................16 Figura 6: ERD anotado Def. tipos de proyectos.................................................................................17 Figura 7: ERD anotado Def. tipos de actividades..............................................................................17 Figura 8: ERD anotado Ámbitos y Administradores..........................................................................18 Figura 9: Esquema Menú Admin. de proyectos.................................................................................18 Figura 10: ERD anotado Administración de proyectos......................................................................19 Figura 11: ERD anotado Gestión de actividades ampliada................................................................21 Figura 12: Esquema Menú Gestor de proyectos.................................................................................22 Figura 13: ERD anotado Gestión de proyectos..................................................................................22 Figura 14: ERD anotado Gestión de proyectos ampliada..................................................................23 Figura 15: ERD anotado Gestión de actividades................................................................................23 Figura 16: Esquema Menú Técnico....................................................................................................24 Figura 17: ERD anotado Lista de actividades....................................................................................24 Figura 18: ERD anotado Visualización de proyecto..........................................................................25 Figura 19: ERD anotado Edición de actividades................................................................................26 Figura 20: Esquema Menú Usuario....................................................................................................26 Figura 21: ERD anotado Visualización de proyectos para usuarios...................................................27 Figura 22: ERD anotado Visualización de actividades para usuarios................................................28 Figura 23: Esquema Menú Usuario Sin Acceso.................................................................................28 Figura 24: ERD anotado Visualización de proy para usuarios sin acceso..........................................29 Figura 25: ERD anotado Visualización de activ para usuarios sin acceso.........................................29 Figura 26: Caso de uso (Admin. del módulo)....................................................................................30 Figura 27: Caso de uso (Admin. de proyectos)..................................................................................32 Figura 28: Caso de uso (Gestor de proyectos)....................................................................................35 2/54 Departamento de Ingeniería Telemática Documento de Diseño Figura 29: Caso de uso (Técnico).......................................................................................................39 Figura 30: Caso de uso (Usuario).......................................................................................................43 Figura 31: Diagrama de paquetes.......................................................................................................45 3/54 Índice de tablas Tabla 1: Tabla Rol – Unidad de interacción.......................................................................................15 Tabla 2: CU-01 Establecer admin. de proyectos del ámbito 0-Global...............................................31 Tabla 3: CU-02 Crear Proyecto ETSI en la categoría Software-Desarrollo.......................................34 Tabla 4: CU-03 Búsqueda de proyectos por parte de un gestor.........................................................37 Tabla 5: CU-4 Gestión del proyecto Proyecto ETSI..........................................................................39 Tabla 6: CU-05 Búsqueda de actividades de Proyecto ETSI y En Curso por parte de un técnico.....41 Tabla 7: CU-06 Visualizar actividad Plan de evacuación de Proyecto ETSI por parte de un técnico43 Tabla 8: CU-07 Visualizar actividad Plan de evacuación de Proyecto ETSI por parte de usuario....45 Tabla 9: Tabla de Pruebas...................................................................................................................54 Tabla 10: Matriz de Trazabilidad (Prueba01-Prueba18).....................................................................55 Tabla 11: Matriz de Trazabilidad (Prueba9-Prueba35).......................................................................56 4/54 Departamento de Ingeniería Telemática Documento de Diseño 1 Introducción 1 Introducción Este documento expone una explicación detallada del proceso de diseño del módulo de gestión de proyectos de la aplicación GTI. El proceso de diseño consta de las siguientes actividades: •La definición de la arquitectura del sistema. •El modelo físico de datos de la Base de datos empleada en el módulo. •La definición de eventos y funciones necesarias para la construcción del módulo. •El diseño de las interfaces de usuario mediante diagramas entidad-relación anotados. •La descripción de casos de uso reales. •La generación de especificaciones de construcción. •El diseño del procedimiento de la carga inicial de datos. •La especificación técnica del plan de pruebas. •La definición de los requisitos de implantación. En las siguientes secciones de este documento se detalla el resultado de cada una de las actividades anteriores. 2 Arquitectura del sistema En el diagrama de despliegue mostrado en la siguiente figura se pueden observar los elementos hardware y software que componen el sistema: 5/54 Figura 1: Diagrama de despliegue Se pueden observar los 3 nodos que conforman nuestro sistema: •Servidor BD: contiene la base de datos de la aplicación GTI desarrollada en PostgreSQL 8.1.19. Esta base de datos contendrá todos los datos que el usuario va a manejar en la aplicación a través de la interfaz de usuario. •Servidor de aplicaciones: contiene el sistema integrador de módulos WINTER 0.2 que integra el módulo común gti y el módulo de gestión de proyectos (gti.pm). Además, la aplicación que conforman estos módulos, GTI, se enlaza con el motor de WAINE[1]. Esta aplicación tendrá ligada un repositorio de modelos de la interfaz de usuario (RMIU, o MDB) en la que se almacenará los modelos de usuario, diálogo y presentación. Este repositorio permitirá al motor WAINE generar los diversos elementos que conforman la interfaz de usuario final: menús, unidades de interacción, formularios, etc. •Cliente IU: representa las propias interfaces de usuario finales desde el navegador web, por el cual el usuario puede realizar las diversas acciones proporcionadas por la aplicación GTI. Cuando el servidor de aplicaciones reciba una petición a través de Internet, accederá a la MDB de la aplicación y a partir de la información almacenada en ella generará automáticamente las interfaces de usuario enviadas al cliente. Asimismo, accederá a la DB de la aplicación para ejecutar tanto las acciones básicas (create, update y delete) como las acciones y eventos definidos para los usuarios y seleccionados por ellos. 6/54 Departamento de Ingeniería Telemática Documento de Diseño 3 Modelo físico de datos 3 Modelo físico de datos En la Figura 1 se ilustra el modelo físico de datos del módulo de gestión de proyectos. Puede observar en él las tablas, campos y relaciones de la Base de datos del módulo. A continuación, se describen las tablas que integran el modelo físico de datos del módulo: •PCL1: Contiene las distintas categorías de proyectos. Cada registro de esta tabla tiene la siguiente estructura: ◦pk: Identificador de la categoría de proyecto. Un entero rellenado de forma automática. ◦descr: Nombre descriptivo de la categoría. Hasta 80 caracteres. ◦rem: Notas. Campo de texto limitado a 1024 caracteres. 7/54 Figura 2: Modelo físico de datos •PCL2: Define las distintas subcategorías de proyectos relacionadas con la tabla anterior (PCL1). Una subcategoría pertenece a una categoría de proyecto. Cada registro de esta tabla contiene: ◦pk: Identificador de la subcategoría de proyecto. Un entero rellenado de forma automática. ◦descr: Nombre descriptivo de la subcategoría. Hasta 80 caracteres. ◦rem: Notas. Campo de texto libre limitado a 1024 caracteres. ◦fk: número entero que referencia al identificador de la categoría de proyecto a la que pertenece la subcategoría (PCL1). •ProjType: Especifica los distintos tipos de proyecto existentes en la aplicación. Cada fila de esta tabla se define de la siguiente manera: ◦pk: Identificador del tipo de proyecto. Un entero rellenado de forma automática. ◦descr: Nombre descriptivo del tipo de proyecto. Hasta 80 caracteres. ◦rem: Notas. Campo de texto libre limitado a 1024 caracteres. •Proj: Contiene los proyectos. Un proyecto pertenece únicamente a una subcategoría, a un ámbito y a un tipo de proyecto concreto. Puede pertenecer o no a una unidad organizativa de la aplicación. Cada registro de esta tabla contiene: ◦pk: Identificador del proyecto. Un entero rellenado de forma automática. ◦name: Nombre del proyecto. Hasta 80 caracteres. ◦descr: Temática o descripción del proyecto. Campo de texto libre limitado a 1024 caracteres. ◦rem: Notas. Campo de texto libre limitado a 1024 caracteres. ◦ena: Proyecto habilitado o deshabilitado. Un booleano que puede ser true o false. Por defecto estará a true. ◦fk: número entero que referencia al identificador del tipo de proyecto al que pertenece el proyecto. ◦fkpcl2: número entero que referencia al identificador de la subcategoría a la que pertenece el proyecto. ◦fkscope: número entero que referencia al identificador del ámbito al que está asociado el proyecto. ◦fkou: número entero que referencia al identificador de la unidad organizativa a la que pertenece el proyecto. ◦cts: Instante de creación del proyecto. ◦cun: Nombre del usuario creador del proyecto. Hasta 80 caracteres. ◦run: Nombre del usuario responsable del proyecto. Hasta 80 caracteres. ◦ets: Instante de finalización del proyecto. •ActivType: Define los distintos tipos de actividad existentes en la aplicación. Cada registro de esta tabla contiene: 8/54 Departamento de Ingeniería Telemática Documento de Diseño 5 Diseño de las interfaces de usuario 5 Diseño de las interfaces de usuario Las unidades de interacción accesibles a los usuarios del sistema se pueden observar en la siguiente Tabla 1: Administrador del módulo Administrdor de proyectos Gestor de proyectos Técnico Usuario Usuario sin acceso al módulo Clasificación de proyectos cprojcatalog1 Definición de tipos de proyectos ctiposproy Definición de tipos de actividades ctiposactiv Ámbitos y administradores cscope Administración de proyectos cproj Gestión de proyectos cprojsearch Gestión de proyectos ampliada cproj2_ro Gestión de actividades cactivsearch Gestión de actividades ampliada cactiv cactiv Lista de actividades cactivlist Edición de actividades cactiv_ro Visualización de proyecto cproj2_ro2 Visualización de proyectos para usuarios cprojuser Visualización de actividades para usuarios cactiv_user Visualización de proyectos para usuarios si acceso al módulo cprojuser_na Visualización de actividades para usuarios sin acceso al módulo cactivuser_na Tabla 1: Tabla Rol – Unidad de interacción A continuación, se especifica cada unidad de interacción empleando diagramas entidad-relación anotados [2]. 15/54 5.1 Administrador del módulo El usuario administrador del módulo puede: •Determinar las categorías y subcategorías pertinentes para los proyectos. •Definir los distintos tipos de proyectos y actividades con sus campos personalizables. •Establecer los usuarios con permiso de administración de proyectos en cada uno de los ámbitos. El menú que se propone para este usuario es el siguiente: 5.1.1 Clasificación de proyectos – gti.pm.cprojcatalog1 A continuación, se muestra el ERD anotado para la unidad de interacción gti.pm.cprojcatalog1: 16/54 Figura 4: Esquema Menú Admin. del módulo Figura 5: ERD anotado Clasificación de proyectos Departamento de Ingeniería Telemática Documento de Diseño 5 Diseño de las interfaces de usuario 5.1.2 Definición de tipos de proyectos - gti.pm.ctiposproy En la Figura 6 se presenta el ERD anotado para la unidad de interacción gti.pm.ctiposproy: 5.1.3 Definición de tipos de actividades - gti.pm.ctiposactiv En la Figura 7 se presenta el ERD anotado para la unidad de interacción gti.pm.ctiposactiv: 17/54 Figura 7: ERD anotado Def. tipos de actividades Figura 6: ERD anotado Def. tipos de proyectos 5.1.4 Ámbitos y administradores - gti.pm.cscope A continuación, se presenta el ERD anotado para la unidad de interacción gti.pm.cscope: 5.2 Administrador de proyectos El usuario administrador de proyectos puede crear/eliminar/modificar proyectos y sus respectivas actividades, asi como establecer los miembros de cada proyecto. 5.2.1 Administración de proyectos - gti.pm.cproj A continuación, se presenta el ERD anotado para la unidad de interacción gti.pm.cproj: 18/54 Figura 9: Esquema Menú Admin. de proyectos Figura 8: ERD anotado Ámbitos y Administradores Departamento de Ingeniería Telemática Documento de Diseño 5 Diseño de las interfaces de usuario Se puede observar que será necesaria la creación de tres vistas para la construcción de esta interfaz de usuario: •VIEW_PCL: Muestra las distintas relaciones categoría-subcategoría de los proyectos. Cada dupla de esta vista contiene: ◦pk: Identificador de la subcategoría de proyecto. Campo pk de la tabla pm.PCL2. ◦descr: Nombre descriptivo de la relación categoría-subcategoría. Unión de los campos descr de las tablas pm.PCL1 y pm.PCL2. •VIEW_ProjEntry: Muestra las anotaciones de las actividades de cada proyecto. Cada fila de esta vista contiene: ◦pk: Identificador de la actividad a la que pertenece la anotación. Campo pk de la tabla pm.Activ. ◦subj: Asunto de la actividad a la que pertenece la anotación. Campo subj de la tabla pm.Activ. ◦fkproj: Número entero que referencia al identificador del proyecto al que pertenece la actividad. Campo fkproj de la tabla pm.Activ. ◦cts: Instante de creación de la anotación. Campo cts de la tabla gti.Entry. ◦cu: Nombre del usuario creador de la anotación. Campo cu de la tabla gti.Entry. ◦rem: Notas de la anotación. Campo rem de la tabla gti.Entry. 19/54 Figura 10: ERD anotado Administración de proyectos •VIEW_PSp: Muestra las imputaciones realizadas a cada proyecto. Cada fila de esta vista contiene: ◦pk: Identificador de la actividad a la que pertenece la imputación. Campo pk de la tabla pm.Activ. ◦subj: Asunto de la actividad a la que pertenece la imputación. Campo subj de la tabla pm.Activ. ◦cts: Instante de creación de la imputación. Campo cts de la tabla gti.SpTime. ◦cu: Nombre del usuario creador de la imputación. Campo cu de la tabla gti.SpTime. ◦cat: Nombre descriptivo del tipo de imputación. Campo descr de la tabla gti.SpTimeType. ◦descr: Descripción de la imputación. Campo descr de la tabla gti.SpTime. ◦h: Tiempo dedicado a la imputación en horas. Campo h de la tabla gti.SpTime. ◦fkproj: Número entero que referencia al identificador del proyecto al que pertenece la actividad. Campo fkproj de la tabla pm.Activ. •VIEW_EffortProj: Muestra las imputaciones realizadas a cada proyecto en función del tipo de imputación realizado. Cada fila de esta vista contiene: ◦cat: Nombre descriptivo del tipo de imputación. Campo descr de la tabla gti.SpTimeType. ◦fkproj: Número entero que referencia al identificador del proyecto al que pertenece la actividad que tiene la anotación con la imputación. Campo fkproj de la tabla pm.Activ. ◦sumh: Suma de las horas dedicadas a un proyecto en función del tipo de imputación. Campo h de la tabla gti.SpTime. 5.2.2 Gestión de actividades ampliada - gti.pm.cactiv Esta interfaz de usuario es accesible a partir de la interfaz Administración de proyectos explicada en el apartado 5.2.1, pulsando sobre el identificador de la actividad deseada (campo ID). A continuación, se presenta el ERD anotado para esta unidad de interacción: 20/54 Departamento de Ingeniería Telemática Documento de Diseño 5 Diseño de las interfaces de usuario Se puede observar que será necesaria la creación de una vista para poder construir esta interfaz de usuario: •VIEW_ASp: Muestra las imputaciones realizadas a cada actividad. Cada fila de esta vista contiene: ◦pk: Identificador de la imputación. Campo pk de la tabla gti.SpTime. ◦cts: Instante de creación de la imputación. Campo cts de la tabla gti.SpTime. ◦descr: Descripción de la imputación. Campo descr de la tabla gti.SpTime. ◦h: Tiempo dedicado a la imputación en horas. Campo h de la tabla gti.SpTime. ◦cu: Nombre del usuario creador de la imputación. Campo cu de la tabla gti.SpTime. ◦fktype: Número entero que referencia al identificador del tipo de imputación. Campo fktype de la tabla gti.SpTime. ◦fkactiv: Número entero que referencia al identificador de la actividad a la que pertenece la anotación de la imputación. Campo fkactiv de la tabla gti.Entry. •VIEW_EffortActiv: Muestra las imputaciones realizadas a cada actividad en función del tipo de imputación realizado. Cada fila de esta vista contiene: ◦cat: Nombre descriptivo del tipo de imputación. Campo descr de la tabla gti.SpTimeType. ◦fkactiv: Número entero que referencia al identificador de la actividad a la que pertenece la anotación con la imputación. Campo fkactiv de la tabla pm.Entry. ◦sumh: Suma de las horas dedicadas a una actividad en función del tipo de imputación. Campo h de la tabla gti.SpTime. 21/54 Figura 11: ERD anotado Gestión de actividades ampliada 5.3 Gestor de proyectos El usuario gestor de proyectos puede visualizar tanto un resumen del estado de los proyectos que gestiona como un resumen de todas las actividades de estos proyectos. Además de acceder a la gestión de dichos proyectos y actividades. 5.3.1 Gestión de proyectos - gti.pm.cprojsearch A continuación, se presenta el ERD anotado para la unidad de interacción gti.pm.cprojsearch: 5.3.2 Gestión de proyectos ampliada - gti.pm.cproj2_ro Esta interfaz de usuario es accesible a partir de la interfaz Gestión de proyectos del apartado 5.3.1, pulsando sobre el identificador del proyecto deseado (campo ID) de la tabla inferior Proyecto. El ERD anotado para esta unidad de interacción es: 22/54 Figura 13: ERD anotado Gestión de proyectos Figura 12: Esquema Menú Gestor de proyectos Departamento de Ingeniería Telemática Documento de Diseño 5 Diseño de las interfaces de usuario Se puede observar que será necesario el uso de las vistas VIEW_ProjEntry, VIEW_PSp y VIEW_EffortProj comentadas anteriormente en el diseño de la interfaz de usuario Administración de proyectos y comentadas en el apartado 5.2.1. 5.3.3 Gestión de actividades - gti.pm.cactivsearch A continuación, se presenta el ERD anotado para la unidad de interacción gti.pm.cactivsearch: 23/54 Figura 14: ERD anotado Gestión de proyectos ampliada Figura 15: ERD anotado Gestión de actividades 5.3.4 Gestión de actividades ampliada - gti.pm.cactiv En el perfil Gestor de proyectos esta interfaz de usuario es accesible tanto a partir de la interfaz Gestión de actividades comentada en el apartado anterior 5.3.3 como a partir de la interfaz Gestión de proyectos ampliada descrita en el apartado 5.3.2, pulsando sobre el identificador de la actividad (campo ID). Para observar el diseño de esta interfaz de usuario véase el apartado 5.2.2. 5.4 Técnico El usuario técnico se centra únicamente en las actividades. Puede visualizar un resumen del estado de todas las actividades de los proyectos en los que participa. Además de acceder a ellas con los permisos correspondientes del perfil Técnico. 5.4.1 Lista de actividades - gti.pm.cactivlist A continuación, se presenta el ERD anotado para dicha unidad de interacción: 24/54 Figura 16: Esquema Menú Técnico Figura 17: ERD anotado Lista de actividades Departamento de Ingeniería Telemática Documento de Diseño 6 Casos de uso reales CU-01 Establecer administrador de proyectos del ámbito 0-Global Dependencias •R1.1.2 Siempre existirá un ámbito global. •R1.1.3 Los administradores de proyectos se definen por ámbito. •R2.1.2 Establece los administradores de proyectos de los distintos ámbitos. Precondición Tanto el administrador del módulo gestión de proyectos como el administrador de proyectos seleccionado para el ámbito 0-Global tienen que estar registrados en la aplicación. Descripción El sistema deberá comportarse como se describe en el siguiente caso de uso cuando el administrador del módulo define un administrador de proyectos del ámbito 0-Global. Secuencia normal Paso Acción 1 El usuario administrador del módulo inicia sesión en la aplicación. 2 El usuario administrador del módulo selecciona la opción Ámbitos y Administradores del menú. 3 El usuario administrador del módulo selecciona en el navegador el ámbito 0-Global. 3.1 Si el ámbito no existe se realiza el caso de uso Crear ámbito. No obstante, en este caso de uso real se utiliza el ámbito 0-Global el cuál siempre existe. 4 El usuario administrador del módulo escoge en el combo de la tabla Administradores el usuario administrador de proyectos deseado para dicho ámbito. Postcondición El sistema registra al usuario elegido por el usuario administrador del módulo con el perfil de administrador de proyectos en el ámbito 0-Global. Excepciones Paso Acción 3 Si el usuario elegido por el usuario administrador del módulo ya existe en dicha tabla Administradores. E.1 El sistema informa de la situación con el siguiente mensaje de error: "Inserción abortada. Esa relación ya existe". E.2 Se cancela el caso de uso. Comentarios No hay número máximo de usuarios administradores de proyectos del ámbito 0-Global. Tabla 2: CU-01 Establecer admin. de proyectos del ámbito 0-Global 31/54 6.2 Creación de un proyecto El usuario administrador de proyectos es el único que puede crear proyectos en los ámbitos a los que está asociado. CU-02 Crear proyecto denominado Proyecto ETSI en la categoría Software- Desarrollo. Dependencias •R1.1.1 Los proyectos deben contemplar ámbitos. •R1.1.3 Los administradores de proyectos se definen por ámbito. •R1.2.2 Un proyecto puede tener varios gestores. •R1.2.4 Posibilidad de configurar campos personalizables por cada tipo de proyecto. •R1.2.5 Los proyectos se clasifican por categorías. •R1.2.6 Los proyectos pueden estar asociados a una unidad organizativa. •R2.2.1 Puede crear proyectos o copiar proyectos anteriores para generar uno nuevo. •R2.2.2 Puede activar/deshabilitar proyectos creados por él. •R2.2.4 Asigna participantes a los proyectos y les asigna sus perfiles. Precondición Tanto el administrador de proyectos como los miembros del proyecto creado tienen que estar registrados en la aplicación. Asimismo, el usuario administrador de proyectos debe estar asociado a algún ámbito. Descripción El sistema deberá comportarse como se describe en el siguiente caso de uso cuando el administrador de proyectos crea un proyecto concreto. Secuencia normal Paso Acción 1 El usuario administrador de proyectos inicia sesión en la aplicación. 2 El usuario administrador de proyectos selecciona la opción 32/54 Figura 27: Caso de uso (Admin. de proyectos) Departamento de Ingeniería Telemática Documento de Diseño 6 Casos de uso reales Administración de proyectos del menú. 3 El usuario administrador de proyectos selecciona en el combo superior Categoría la categoría Software-Desarrollo. 3.1 Si la categoría deseada no existe, se debe elegir otra categoría y reportar dicha necesidad de categoría al administrador del módulo, el cuál evaluará dicho reporte. 4 El usuario administrador de proyectos pulsa el botón Nuevo del navegador. 5 El usuario administrador de proyectos cumplimenta los campos del formulario Proyecto. 5.1 Si en el campo Categoría elige cualquier otra categoría distinta a Software-Desarrollo, automáticamente pasa a pertenecer a dicha categoría seleccionada. 5.2 En el campo Ámbito únicamente aparecen los ámbitos a los que está asociado dicho usuario. 5.3 En el campo Responsable aparecen todos los usuarios de la aplicación, únicamente pueden ser responsables de un proyecto los usuarios con perfil Gestor de proyectos. 6 El usuario administrador de proyectos pulsa el botón Añadir y dicho proyecto será creado con un identificador único determinado por el sistema automáticamente. 7 El usuario administrador de proyectos debe realizar el caso de uso Definir miembros, el cuál asigna los participantes del proyecto con un rol concreto. 7.1 Dicho caso de uso también está disponible para los participantes del proyecto con el rol de Gestor de proyectos. 8 El usuario adminitrador de proyectos puede crear actividades pertenecientes a dicho proyecto creado si lo desea, realizando el caso de uso Crear actividades. 8.1 Dicho caso de uso también está disponible para los participantes del proyecto con el rol de Gestor o Técnico. Postcondición El sistema registra el proyecto creado en la base de datos y éste será visible para todos sus miembros. Excepciones Paso Acción 7 Si la pareja usuario-rol elegida por el usuario administrador de proyectos ya existe en dicha tabla Miembros. E.1 El sistema informa de la situación con el siguiente mensaje de error: "Inserción abortada. Esa relación ya existe". E.2 Se cancela el caso de uso. 33/54 Comentarios No hay número máximo de proyectos en una categoría o ámbito. Asimismo, tampoco hay límite ni de participantes ni de actividades en los proyectos. Tabla 3: CU-02 Crear Proyecto ETSI en la categoría Software-Desarrollo 6.3 Búsqueda y Gestión de proyectos El usuario gestor de proyectos puede buscar y visualizar proyectos en los que participa con el perfil de Gestor. Además, puede acceder a cada uno de estos proyectos y gestionarlo. CU-03 Búsqueda de proyectos de categoría Software-Desarrollo y ámbito Sevilla por parte de un gestor. 34/54 Figura 28: Caso de uso (Gestor de proyectos) Departamento de Ingeniería Telemática Documento de Diseño 6 Casos de uso reales Dependencias •R1.2.1 La visibilidad de los usuarios sobre los proyectos se definirá por su perfil. •R1.2.5 Los proyectos se clasifican por categorías. •R1.2.6 Los proyectos pueden estar asociados a una unidad organizativa. •R2.3.1 Tiene la capacidad de modificar cualquier aspecto de los proyectos que gestiona y de sus actividades. •R2.3.4 Puede asignar participantes a los proyectos que gestiona y establecer sus perfiles. Precondición El gestor de proyectos tiene que estar registrado en la aplicación y pertenecer a algún proyecto con el rol de Gestor. Descripción El sistema deberá comportarse como se describe en el siguiente caso de uso cuando el gestor de proyectos busque proyectos. Secuencia normal Paso Acción 1 El usuario gestor de proyectos inicia sesión en la aplicación. 2 El usuario gestor de proyectos selecciona la opción Gestión de proyectos del menú. 3 El usuario gestor de proyectos cumplimenta únicamente los campos por los que desea filtrar del filtro superior Búsqueda y Visualización de proyectos. En este caso de uso, se deben cumplimentar los campos Categoría y Ámbito. 4 El usuario gestor de proyectos pulsa el botón Filtrar de dicho filtro superior. 5 El usuario gestor de proyectos visualiza el resultado teniendo en cuenta que únicamente puede ver los proyectos en los que participa con el perfil de Gestor. 5.1 Tiene la capacidad de modificar el nombre y la unidad organizativa de los proyectos visualizados. 5.2 Si pulsa sobre el identificador de un proyecto accede a la gestión ampliada de dicho proyecto concreto. 6 El usuario gestor de proyectos accede a la gestión ampliada de un proyecto de los mostrados en el resultado. 6.1 Se realiza el caso de uso Gestionar proyectos. Postcondición Excepciones Paso Acción 3 Si la categoría o ámbito deseado no existen. E.1 Se cancela el caso de uso. Comentarios El usuario gestor de proyectos tiene casi los mismos permisos de modificación de un proyecto que el usuario administrador de proyectos, salvo que el usuario gestor de proyectos no puede crear/eliminar proyectos. 35/54 Tabla 4: CU-03 Búsqueda de proyectos por parte de un gestor CU-04 Gestión del proyecto Proyecto ETSI. Dependencias •CU-03 Búsqueda de proyectos de categoría Software-Desarrollo y ámbito Sevilla. •R1.2.2 Un proyecto puede tener varios gestores. •R1.2.4 Posibilidad de configurar campos personalizables por cada tipo de proyecto. •R1.2.5 Los proyectos se clasifican por categorías. •R1.2.6 Los proyectos pueden estar asociados a una unidad organizativa. •R1.3.3 Puede existir una relación jerárquica entre actividades. •R1.3.4 Una actividad tiene un único responsable. •R1.3.6 Las actividades tienen asignado un estado: Nueva, En curso, Detenida,Finalizada. •R1.3.7 Las actividades tienen asignado un porcentaje de avance: 0%, 25%, 50%, 75%,100%. •R2.3.1 Tiene la capacidad de modificar cualquier aspecto de los proyectos que gestiona y de sus actividades. •R2.3.2 Puede añadir o eliminar actividades de los proyectos que gestiona. •R2.3.4 Puede asignar participantes a los proyectos que gestiona y establecer sus perfiles. Precondición Tanto el gestor de proyectos como los restantes miembros del proyecto Proyecto ETSI tienen que estar registrados en la aplicación. Asimismo, el usuario gestor de proyectos debe pertenecer a dicho proyecto con el rol de Gestor. Se debe haber realizado el caso de uso CU-03. Descripción El sistema deberá comportarse como se describe en el siguiente caso de uso cuando el gestor de proyectos gestione el proyecto Proyecto ETSI. Secuencia normal Paso Acción 1 El usuario gestor de proyectos accede a la gestión ampliada del proyecto Proyecto ETSI. 2 El usuario gestor de proyectos visualiza y gestiona las actividades de dicho proyecto desde la pestaña Actividades. 3 El usuario gestor de proyectos crea una actividad denominada Plan de evacuación cumplimentando los campos de la tabla Actividad. 3.1 En el campo Tipo aparecen los tipos de actividad establecidos por el administrador del módulo. 3.2 En el campo Responsable aparecen todos los usuarios de la aplicación, únicamente pueden ser responsables de una actividad los usuarios con perfil Técnico. 3.3 En el campo Estado sólo se puede seleccionar el valor Nueva o En Curso al crear la actividad. 36/54 Departamento de Ingeniería Telemática Documento de Diseño 6 Casos de uso reales 3.4 El campo T.estimado es obligatorio. 4 El usuario gestor de proyectos asigna valores a los campos personalizables (Coste estimado, Coste final) del proyecto Proyecto ETSI. 5 El usuario gestor de proyectos puede añadir algún participante más en el proyecto o, por el contrario, eliminar algún participante. También puede modificar sus roles. Postcondición El sistema registra la actividad creada del proyecto Proyecto ETSI en la base de datos y ésta será visible para todos sus miembros. Excepciones Paso Acción 5 Si la pareja usuario-rol elegida por el usuario gestor de proyectos ya existe en dicha tabla Miembros. E.1 El sistema informa de la situación con el siguiente mensaje de error: "Inserción abortada. Esa relación ya existe". E.2 Se cancela el caso de uso. Comentarios El usuario gestor de proyectos no puede crear/eliminar proyectos, pero sí actividades. Tabla 5: CU-4 Gestión del proyecto Proyecto ETSI 6.4 Búsqueda de actividades por parte de un Técnico El usuario Técnico puede buscar y visualizar cualquier actividad de los proyectos en los que participa con el perfil de Técnico. Además, puede acceder en modo lectura a cualquiera de estos proyectos. Así como modificar el estado y avance de sus actividades y realizar las oportunas anotaciones. 37/54 Figura 29: Caso de uso (Técnico) CU-05 Búsqueda de actividades del proyecto Proyecto ETSI y estado En Curso por parte de un técnico. Dependencias •R1.3.6 Las actividades tienen asignado un estado: Nueva, En curso, Detenida,Finalizada. •R1.3.7 Las actividades tienen asignado un porcentaje de avance: 0%, 25%, 50%, 75%,100%. •R1.3.8 Posibilidad de configurar campos personalizables por cada tipo de actividad. •R1.4.1 Las imputaciones se clasifican en categorías preestablecidas. •R1.4.2 Se pueden calcular imputaciones totales por actividades y proyectos. •R1.4.3 Cualquier participante de un proyecto puede hacer imputaciones a las actividades del mismo. •R2.4.1 Tiene acceso en modo lectura a cualquier informacion de los proyectos en losque participa. •R2.4.3 Puede escribir en el histórico de cualquier actividad de un proyecto del que sea participante. •R2.4.4 Imputa tiempos en las actividades de los proyectos en los que participa. Precondición El técnico tiene que estar registrado en la aplicación y pertenecer a dicho proyecto con el rol de Técnico. Descripción El sistema deberá comportarse como se describe en el siguiente caso de uso cuando el técnico busque las actividades del proyecto Proyecto ETSI. Secuencia normal Paso Acción 1 El usuario técnico inicia sesión en la aplicación. 2 El usuario técnico selecciona la opción Lista de actividades del menú. 3 El usuario técnico cumplimenta únicamente los campos por los que desea filtrar del filtro superior Lista de actividades. En este caso de uso, se deben cumplimentar los campos Categoría Proyecto y Estado. 4 El usuario técnico pulsa el botón Filtrar de dicho filtro superior. 5 El usuario técnico visualiza el resultado teniendo en cuenta que únicamente puede ver los proyectos en los que participa con el perfil de Técnico. 5.1 Tiene la capacidad de modificar el estado y avance de las actividades visualizadas. 5.2 Si pulsa sobre el identificador del proyecto accede a la visualización de dicho proyecto concreto. 5.3 Si pulsa sobre el identificador de una actividad accede a la visualización de dicha actividad concreta. 38/54 Departamento de Ingeniería Telemática Documento de Diseño 6 Casos de uso reales 6 El usuario técnico accede a la visualización de una actividad de las mostradas en el resultado. En este caso accede a la actividad Plan de evacuación. 6.1 Se realiza el caso de uso Visualizar actividades. Postcondición Excepciones Paso Acción 3 Si el proyecto deseado no existe. E.1 Se cancela el caso de uso. Comentarios El usuario técnico tiene mínimos permisos de modificación, únicamente los campos Estado y Avance de las actividades. Tabla 6: CU-05 Búsqueda de actividades de Proyecto ETSI y En Curso por parte de un técnico CU-06 Visualizar actividad Plan de evacuación del proyecto Proyecto ETSI por parte de un técnico. Dependencias •CU-05 Búsqueda de actividades del proyecto Proyecto ETSI y estado En Curso. •R1.3.6 Las actividades tienen asignado un estado: Nueva, En curso, Detenida, Finalizada. •R1.3.7 Las actividades tienen asignado un porcentaje de avance: 0%, 25%, 50%, 75%,100%. •R1.3.8 Posibilidad de configurar campos personalizables por cada tipo de actividad. •R1.4.1 Las imputaciones se clasifican en categorías preestablecidas. •R1.4.2 Se pueden calcular imputaciones totales por actividades y proyectos. •R1.4.3 Cualquier participante de un proyecto puede hacer imputaciones a las actividades del mismo. •R2.4.1 Tiene acceso en modo lectura a cualquier informacion de los proyectos en losque participa. •R2.4.3 Puede escribir en el histórico de cualquier actividad de un proyecto del que sea participante. •R2.4.4 Imputa tiempos en las actividades de los proyectos en los que participa. Precondición El técnico tiene que estar registrado en la aplicación y pertenecer a dicho proyecto con el rol de Técnico. Se debe haber realizado el caso de uso CU-05. Descripción El sistema deberá comportarse como se describe en el siguiente caso de uso cuando el técnico visualice la actividad Plan de evacuación. Secuencia normal Paso Acción 1 El usuario técnico accede a la visualización de la actividad. 2 El usuario técnico visualiza las anotaciones de la actividad y sus imputaciones desde la pestaña Histórico. 39/54 3 El usuario técnico crea una anotación denominada Plano del edificio. 4 El usuario técnico pulsa el botón Filtrar de dicho filtro superior. 5 El usuario técnico visualiza el resultado teniendo en cuenta que únicamente puede ver los proyectos en los que participa con el perfil de Técnico. 6 El usuario técnico debe pulsar de nuevo la pestaña Histórico y el botón Seleccionar de la anotación creada. 7 El usuario técnico crea una imputación denominada Estudio del plano en dicha anotación cumplimentando los campos de la tabla Dedicación en la pestaña inferior Dedicación perteneciente al histórico. 7.1 Una anotación sólo puede ser eliminada por su creador, salvo si se tiene el rol de administrador o gestor. 8 El usuario técnico visualiza todas las imputaciones de las anotaciones de la actividad desde la pestaña Dedicación perteneciente a la actividad. Postcondición El sistema registra la anotación creada de la actividad Plan de evaluación del proyecto Proyecto ETSI en la base de datos y ésta será visible para todos sus miembros. Comentarios Las anotaciones creadas no se pueden eliminar. Si se ha producido alguna equivocación se debe crear una nueva anotación explicando el motivo. Tabla 7: CU-06 Visualizar actividad Plan de evacuación de Proyecto ETSI por parte de un técnico 6.5 Visualización de una actividad por parte de un Usuario El usuario regular únicamente posee una visión de lectura de los proyectos y actividades en los que participa con el perfil de Usuario. 40/54 Departamento de Ingeniería Telemática Documento de Diseño 9 Plan de pruebas técnico PRU-13 Adjuntar un documento a un proyecto por parte del administrador de proyectos. El administrador de proyectos accede a la interfaz Administración de proyectos, selecciona una categoría, selecciona un proyecto en el Navegador, selecciona la pestaña Adjuntos, selecciona el archivo a adjuntar, añade una descripción y pulsa el botón Añadir. PRU-14 Establecer los miembros de un proyecto por parte del administrador de proyectos. El administrador de proyectos accede a la interfaz Administración de proyectos, selecciona una categoría, selecciona un proyecto en el Navegador, selecciona la pestaña Miembros y define las relaciones usuario-rol convenientes. PRU-15 Establecer los miembros de un proyecto por parte del gestor de proyectos. El gestor de proyectos accede a la interfaz Gestión de proyectos, filtra todos los proyectos que gestiona, selecciona el identificador de un proyecto cualquiera. Se despliega dicho proyecto escogido, selecciona la pestaña Miembros y define las relaciones usuario-rol convenientes. PRU-16 Eliminar miembro de proyecto por parte del administrador de proyectos. El administrador de proyectos accede a la interfaz Administración de proyectos, selecciona una categoría, selecciona un proyecto en el Navegador, selecciona la pestaña Miembros y pulsa el botón Eliminar del miembro (relación usuario-rol) que desee borrar. PRU-17 Eliminar miembro de proyecto por parte del gestor de proyectos. El gestor de proyectos accede a la interfaz Gestión de proyectos, filtra todos los proyectos que gestiona, selecciona el identificador del proyecto al que pertenece el miembro a eliminar. Se despliega el proyecto escogido, selecciona la pestaña Miembros y pulsa el botón Eliminar del miembro (relación usuario-rol) que desee borrar. 47/54 PRU-18 Proceso de creación de anotación con imputación por parte del administrador de proyectos. El administrador de proyectos accede a la interfaz Administración de proyectos, selecciona una categoría, selecciona un proyecto en el Navegador, selecciona la pestaña Actividades y pulsa sobre el identificador de la actividad en la que quiere realizar la anotación. Se despliega la actividad escogida, selecciona la pestaña Histórico, crea la anotación, vuelve a seleccionar la pestaña Histórico y el botón Seleccionar de la anotación creada, selecciona la pestaña Dedicación inferior e imputa un tiempo a dicha anotación con la categoría correspondiente. PRU-19 Proceso de creación de anotación con imputación por parte del gestor de proyectos. El gestor de proyectos accede a la interfaz Gestión de actividades, filtra todas las actividades de los proyectos que gestiona, selecciona el identificador de la actividad a la que quiere añadir una anotación. Se despliega la actividad escogida, selecciona la pestaña Histórico, crea la anotación, vuelve a seleccionar la pestaña Histórico y el botón Seleccionar de la anotación creada, selecciona la pestaña Dedicación inferior e imputa un tiempo a dicha anotación con la categoría correspondiente. PRU-20 Proceso de creación de anotación con imputación por parte del técnico. El técnico accede a la interfaz Lista de acttividades, filtra todas las actividades de los proyectos en los que participa, selecciona el identificador de la actividad a la que quiere añadir una anotación. Se despliega la actividad escogida, selecciona la pestaña Histórico, crea la anotación, vuelve a seleccionar la pestaña Histórico y el botón Seleccionar de la anotación creada, selecciona la pestaña Dedicación inferior e imputa un tiempo a dicha anotación con la categoría correspondiente. 48/54 Departamento de Ingeniería Telemática Documento de Diseño 9 Plan de pruebas técnico PRU-21 Proceso de eliminación de imputación creada por cualquier usuario por parte del administrador de proyectos. El administrador de proyectos accede a la interfaz Administración de proyectos, selecciona una categoría, selecciona un proyecto en el Navegador, selecciona la pestaña Actividades y pulsa sobre el identificador de la actividad que tiene la anotación con la imputación a eliminar. Se despliega la actividad escogida, selecciona la pestaña Histórico y el botón Seleccionar de la anotación que tiene dicha imputación a eliminar, selecciona la pestaña Dedicación inferior y pulsa el botón Eliminar de la imputación que desea borrar. PRU-22 Proceso de eliminación de imputación creada por cualquier usuario por parte del gestor de proyectos. El gestor de proyectos accede a la interfaz Gestión de actividades, filtra todas las actividades de los proyectos que gestiona, selecciona el identificador de la actividad que tiene la anotación con la imputación que desea eliminar. Se despliega la actividad escogida, selecciona la pestaña Histórico y el botón Seleccionar de la anotación que tiene dicha imputación a eliminar, selecciona la pestaña Dedicación inferior y pulsa el botón Eliminar de la imputación que desea borrar. PRU-23 Proceso fallido de eliminación de imputación creada por cualquier usuario excepto por sí mismo por parte del técnico. El técnico accede a la interfaz Lista de actividades, filtra todas las actividades de los proyectos en los que participa, selecciona el identificador de la actividad que tiene la anotación con la imputación que desea eliminar. Se despliega la actividad escogida, selecciona la pestaña Histórico y el botón Seleccionar de la anotación que tiene dicha imputación a eliminar, selecciona la pestaña Dedicación inferior y pulsa el botón Eliminar de la imputación que desea borrar y salta el siguiente mensaje de error por pantalla: No puede eliminar imputaciones realizadas por otros usuarios. 49/54 PRU-24 Proceso de eliminación de imputación creada por sí mismo por parte del técnico. El técnico accede a la interfaz Lista de actividades, filtra todas las actividades de los proyectos en los que participa, selecciona el identificador de la actividad que tiene la anotación con la imputación que desea eliminar. Se despliega la actividad escogida, selecciona la pestaña Histórico y el botón Seleccionar de la anotación que tiene dicha imputación a eliminar, selecciona la pestaña Dedicación inferior y pulsa el botón Eliminar de la imputación que desea borrar. PRU-25 Adjuntar un documento a una actividad por parte del administrador de proyectos. El administrador de proyectos accede a la interfaz Administración de proyectos, selecciona una categoría, selecciona un proyecto en el Navegador, selecciona la pestaña Actividades y pulsa sobre el identificador de la actividad a la que quieres adjuntar un archivo. Se despliega la actividad escogida, selecciona la pestaña Adjuntos, selecciona el archivo a adjuntar, añade una descripción y pulsa el botón Añadir. PRU-26 Buscar todos los proyectos de una categoría específica por parte del gestor de proyectos. El gestor de proyectos accede a la interfaz Gestión de proyectos, selecciona una categoría concreta en el campo Categoría del filtro, pulsa el botón de Filtrar y en la tabla inferior Proyecto aparecen los resultados de dicha búsqueda. PRU-27 Visualizar las imputaciones totales de un proyecto por parte del administrador de proyectos. El administrador de proyectos accede a la interfaz Administración de proyectos, selecciona una categoría, selecciona un proyecto en el Navegador, selecciona la pestaña Dedicación y visualiza un resumen de todas las imputaciones realizadas en dicho proyecto. PRU-28 Visualizar las imputaciones totales de una actividad por parte del administrador de proyectos. El administrador de proyectos accede a la interfaz Administración de proyectos, selecciona una categoría, selecciona un proyecto en el Navegador, selecciona la pestaña Actividades y pulsa sobre el identificador de la actividad deseada. Se despliega la actividad escogida, selecciona la pestaña Dedicación superior y visualiza un resumen de todas las imputaciones realizadas en dicha actividad. 50/54 Departamento de Ingeniería Telemática Documento de Diseño 9 Plan de pruebas técnico PRU-29 Proceso de modificación de actividad por parte del gestor de proyectos. El gestor de proyectos accede a la interfaz Gestión de actividades, filtra todas las actividades de los proyectos que gestiona, selecciona el identificador de una actividad. Se despliega la actividad escogida y modifica algún/os campo/s del formulario Actividad. PRU-30 Proceso de creación de actividad por parte del gestor de proyectos. El gestor de proyectos accede a la interfaz Gestión de proyectos, filtra todos los proyectos que gestiona, selecciona el identificador de un proyecto. Se despliega el proyecto escogido, selecciona la pestaña Actividades, cumplimenta los campos de la tabla Actividad y pulsa el botón Añadir. PRU-31 Proceso de eliminación de actividad por parte del gestor de proyectos. El gestor de proyectos accede a la interfaz Gestión de proyectos, filtra todos los proyectos que gestiona, selecciona el identificador de un proyecto. Se despliega el proyecto escogido, selecciona la pestaña Actividades, y pulsa el botón Eliminar de la actividad que desee borrar. PRU-32 Buscar todas las actividades en estado En curso de los proyectos en los que participa por parte del técnico. El técnico accede a la interfaz Lista de actividades, selecciona el estado En curso en el campo Estado del filtro, pulsa el botón Filtrar y en la tabla inferior Actividad aparecen los resultados de dicha búsqueda. PRU-33 Ver un resumen de todas las anotaciones de un proyecto por parte del usuario regular. El usuario accede a la interfaz Visualización de proyectos para usuarios, filtra todos los proyectos en los que participa, selecciona un proyecto en el Navegador y después la pestaña Histórico. 51/54 PRU-34 Proceso de creación de anotación con imputación por parte del usuario regular. El usuario accede a la interfaz Visualización de proyectos para usuarios, filtra todos los proyectos en los que participa, selecciona un proyecto en el Navegador,selecciona la pestaña Actividades y selecciona el identificador de la actividad a la que quiere añadir una anotación. Se despliega la actividad escogida, selecciona la pestaña Histórico, crea la anotación, vuelve a seleccionar la pestaña Histórico y el botón Seleccionar de la anotación creada, selecciona la pestaña Dedicación inferior e imputa un tiempo a dicha anotación con la categoría y descripción correspondiente. PRU-35 Proceso de eliminación de imputación creada por sí mismo por parte del usuario regular. El usuario accede a la interfaz Visualización de proyectos para usuarios, filtra todos los proyectos en los que participa, selecciona un proyecto en el Navegador,selecciona la pestaña Actividades y selecciona el identificador de la actividad que tiene la anotación con la imputación que desea eliminar. Se despliega la actividad escogida, selecciona la pestaña Histórico y el botón Seleccionar de la anotación que tiene dicha imputación a eliminar, selecciona la pestaña Dedicación inferior y pulsa el botón Eliminar de la imputación a borrar. Tabla 9: Tabla de Pruebas 52/54 Departamento de Ingeniería Telemática Documento de Diseño 9 Plan de pruebas técnico 9.2 Matriz de Trazabilidad REQUISITOS USUARIOS PRUEBAS PRU-01 PRU-02 PRU-03 PRU-04 PRU-05 PRU-06 PRU-07 PRU-08 PRU-09 PRU-10 PRU-11 PRU-12 PRU-13 PRU-14 PRU-15 PRU-16 PRU-17 PRU-18 R2.1.1 X R2.1.2 X R2.2.1 X X R2.2.2 R2.2.3 X X R2.2.4 X X R2.2.5 X X X X X R2.3.1 R2.3.2 R2.3.3 R2.3.4 X X R2.4.1 R2.4.2 R2.4.3 R2.4.4 R2.5.1 R2.5.2 R2.5.3 R2.5.4 Tabla 10: Matriz de Trazabilidad (Prueba01-Prueba18) 53/54 REQUISITOS USUARIOS PRUEBAS PRU-19 PRU-20 PRU-21 PRU-22 PRU-23 PRU-24 PRU-25 PRU-26 PRU-27 PRU-28 PRU-29 PRU-30 PRU-31 PRU-32 PRU-33 PRU-34 PRU-35 R2.1.1 R2.1.2 R2.2.1 R2.2.2 R2.2.3 R2.2.4 R2.2.5 R2.3.1 X R2.3.2 X X R2.3.3 X X R2.3.4 R2.4.1 X R2.4.2 R2.4.3 X R2.4.4 X X R2.5.1 X R2.5.2 X R2.5.3 X R2.5.4 X X Tabla 11: Matriz de Trazabilidad (Prueba9-Prueba35) Como se puede observar, con cada prueba se comprueban uno o varios requisitos de los establecidos al comienzo del proyecto en el documento de Análisis. 10 Requisitos de implantación Los requisitos de implantación del módulo de gestión de proyectos de la aplicación son: •Versión Waine 0.5.4 •Versión PostgreSQL superior o igual a 8.1.19. •Versión PHP superior o igual a 4.3.10. •Versión Apache superior o igual a 1.3.34. •Winter 0.2. 54/54 Departamento de Ingeniería Telemática Memoria de construcción Memoria de construcción de Módulo de Gestión de Proyectos de GTI Pablo Mora Galindo, [email protected] 10/02/2020 Índice 1 Introducción.......................................................................................................................................4 2 Construcción del Modelo físico de datos...........................................................................................4 3 Construcción de las interfaces de usuario........................................................................................10 3.1 Administrador del módulo........................................................................................................10 3.1.1 Clasificación de proyectos................................................................................................11 3.1.2 Definición de tipos de proyectos......................................................................................12 3.1.3 Definición de tipos de actividades....................................................................................13 3.1.4 Ámbitos y administradores...............................................................................................14 3.2 Administrador de proyectos.....................................................................................................15 3.2.1 Administración de proyectos............................................................................................15 3.2.2 Gestión de actividades ampliada......................................................................................22 3.3 Gestor de proyectos..................................................................................................................29 3.3.1 Gestión de proyectos........................................................................................................29 3.3.2 Gestión de proyectos ampliada.........................................................................................30 3.3.3 Gestión de actividades......................................................................................................31 3.3.4 Gestión de actividades ampliada......................................................................................33 3.4 Técnico.....................................................................................................................................33 3.4.1 Lista de actividades..........................................................................................................34 3.4.2 Visualización de proyecto.................................................................................................35 3.4.3 Edición de actividades......................................................................................................37 3.5 Usuario.....................................................................................................................................40 3.5.1 Visualización de proyectos para usuarios.........................................................................40 3.5.2 Visualización de actividades para usuarios......................................................................44 4 Manuales de Usuario........................................................................................................................46 4.1 Manual de usuario de GTI.PM.................................................................................................46 4.1.1 Introducción......................................................................................................................46 4.1.2 Roles.................................................................................................................................46 4.1.3 Notas.................................................................................................................................46 4.2 Manual de usuario del administrador del módulo GTI.PM.....................................................46 4.2.1 Introducción......................................................................................................................46 4.2.2 Funcionalidades................................................................................................................46 4.2.3 Clasificación de proyectos................................................................................................46 4.2.4 Definición de tipos de proyectos......................................................................................47 4.2.4.1 Definición de tipos de actividades............................................................................48 1/120 4.2.4.2 Ámbitos y Administradores......................................................................................49 4.3 Manual de usuario del administrador de proyectos del módulo GTI.PM................................50 4.3.1 Introducción......................................................................................................................50 4.3.2 Funcionalidades................................................................................................................50 4.3.3 Administración de proyectos............................................................................................50 4.3.4 Gestión de actividades ampliada......................................................................................54 4.4 Manual de usuario del gestor de proyectos del módulo GTI.PM............................................57 4.4.1 Introducción......................................................................................................................57 4.4.2 Funcionalidades................................................................................................................57 4.4.3 Gestión de proyectos........................................................................................................57 4.4.4 Gestión de proyectos ampliada.........................................................................................58 4.4.5 Gestión de actividades......................................................................................................62 4.4.6 Gestión de actividades ampliada......................................................................................63 4.5 Manual de usuario del técnico del módulo GTI.PM................................................................66 4.5.1 Introducción......................................................................................................................66 4.5.2 Funcionalidades................................................................................................................66 4.5.3 Lista de actividades..........................................................................................................67 4.5.4 Visualización de proyecto.................................................................................................68 4.5.5 Edición de actividades......................................................................................................72 4.6 Manual de usuario del usuario regular del módulo GTI.PM...................................................75 4.6.1 Introducción......................................................................................................................75 4.6.2 Funcionalidades................................................................................................................75 4.6.3 Visualización de proyectos para usuarios.........................................................................75 4.6.4 Visualización de actividades para usuarios......................................................................77 5 Anexos....................................................................................................................................80 5.1 Fichero gti.pm.asl................................................................................................................80 5.2 Fichero gtipm_CREATE.sql..............................................................................................112 Índice de figuras Figura 1: Esquema Menú Admin. del módulo....................................................................................10 Figura 2: Interfaz de usuario Clasif. de proyectos..............................................................................11 Figura 3: Interfaz de usuario Def. tipos de proyectos.........................................................................12 Figura 4: Interfaz de usuario Def. tipos de actividades......................................................................13 Figura 5: Interfaz de usuario Ámbitos y Administradores..................................................................14 Figura 6: Esquema Menú Admin. de proyectos..................................................................................15 Figura 7: Interfaz de usuario Administración de proyectos................................................................15 Figura 8: Interfaz de usuario Notas del formulario Proyecto.............................................................16 Figura 9: Interfaz de usuario Detalles del formulario Proyecto..........................................................16 Figura 10: Interfaz de usuario Actividades (Administración de proyectos).......................................17 Figura 11: Interfaz de usuario Propiedades (Administración de proyectos).......................................18 Figura 12: Interfaz de usuario Adjuntos (Administración de proyectos)............................................18 Figura 13: Interfaz de usuario Miembros (Administración de proyectos)..........................................19 Figura 14: Interfaz de usuario Histórico (Administración de proyectos)...........................................19 Figura 15: Interfaz de usuario Dedicación (Administración de proyectos)........................................20 Figura 16: Interfaz de usuario Esfuerzo (Administración de proyectos)............................................21 Figura 17: Interfaz de usuario Gestión de actividades ampliada........................................................22 Figura 18: Interfaz de usuario Detalles del formulario Actividad......................................................23 Figura 19: Interfaz de usuario Histórico (Gestión de actividades ampliada)......................................24 2/120 Departamento de Ingeniería Telemática Memoria de construcción 2 Construcción del Modelo físico de datos VALUES ((SELECT fk FROM pm.Activ WHERE pk=a.pk),(SELECT subj FROM pm.Activ WHERE pk=a.pk), (SELECT descr FROM pm.Activ WHERE pk=a.pk),0,0,(SELECT cun FROM pm.Activ WHERE pk=a.pk), (SELECT cts FROM pm.Activ WHERE pk=a.pk),(SELECT MAX(pk) FROM pm.Proj),(SELECT et FROM pm.Activ WHERE pk=a.pk)); -- OBTENER PK DE LA ACTIVIDAD INSERTADA Y ASIGNAR A INSactiv INSactiv=(SELECT MAX(pk) FROM pm.Activ); PERFORM pm.CopyProj($1::bigint,a.pk,INSactiv); END LOOP; ELSE FOR a IN (SELECT pk FROM pm.Activ WHERE fkproj=$1 AND fkactiv=OLDactiv) LOOP RAISE NOTICE 'Tratando activ %', a.pk; -- INSERTAR COPIA DE ACTIVIDAD CON PADRE NewActiv INSERT INTO pm.Activ (fk,subj,descr,s,wd,cun,cts,fkproj,fkactiv,et) VALUES ((SELECT fk FROM pm.Activ WHERE pk=a.pk), (SELECT subj FROM pm.Activ WHERE pk=a.pk), (SELECT descr FROM pm.Activ WHERE pk=a.pk),0,0, (SELECT cun FROM pm.Activ WHERE pk=a.pk), (SELECT cts FROM pm.Activ WHERE pk=a.pk),(SELECT MAX(pk) FROM pm.Proj),NEWactiv,(SELECT et FROM pm.Activ WHERE pk=a.pk)); -- OBTENER PK DE LA ACTIVIDAD INSERTADA Y ASIGNAR A INSactiv INSactiv=(SELECT MAX(pk) FROM pm.Activ); PERFORM pm.CopyProj($1::bigint,a.pk,INSactiv); END LOOP; END IF; RETURN 1; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; 9/120 3 Construcción de las interfaces de usuario Del Modelo de Dominio se derivan el Modelo de Diálogo y el Modelo de Presentación, que son descritos en el lenguaje ASL[20, 21]. El Modelo de Diálogo incluye un conjunto de opciones de menú accesibles a los usuarios conforme a su rol en la aplicación. El Modelo de Presentación describe la IU Abstracta a partir de espacios de trabajo y se compone principalmente de formularios (form) y contenedores (struct). El diseño de las principales interfaces accesibles a los usuarios del sistema se pueden observar en el documento de Diseño en el apartado 5. A continuación, se muestra el resultado de la construcción las interfaces de usuario finales partiendo de esos diseños. 3.1 Administrador del módulo La descripción en ASL del Modelo de Diálogo para el usuario administrador del módulo es: <main id="gti.pm.main_adm" caption="es=PM.Menu del administrador del modulo PM|en=PM.Module admin. menu"> <menu caption="Clasificacion" tooltip="Clasificacion de proyectos"> <option caption="es=Clasificacion de proyectos|en=Project catalog" call="gti.pm.cprojcatalog1"/> </menu> <menu caption="Tipos" tooltip="Definicion de tipos"> <option caption="es=Definicion de tipos de proyectos|en=Project types" call="gti.pm.ctiposproy"/> <option caption="es=Definicion de tipos de actividades|en=Activity types" call="gti.pm.ctiposactiv"/> </menu> <menu caption="Ambito" tooltip="Ambitos y Administradores"> <option caption="es=Ambitos y Administradores|en=Scope and Admins" call="gti.pm.cscope"/> </menu> <menu caption="Misc" tooltip="Otras cosas"> <option caption="es=Sobre este programa|en=About" call="gti.pm.cmodinfo" /> <option caption="es=Ayuda|en=Help" url="http://waine.us.es/dokuwiki/ doku.php?id=waine:help:app:gti:pm:menu:administrador_modulo" /> <option caption="es=Sobre WAINE|en=About WAINE" url="http://www.waine.org" /> <option caption="es=Salir|en=Logout" url="logout.php" /> </menu> </main> 10/120 Figura 1: Esquema Menú Admin. del módulo Departamento de Ingeniería Telemática Memoria de construcción 3.1.1 Clasificación de proyectos La descripción en ASL del Modelo de Presentación para esta interfaz es: <struct id="gti.pm.cprojcatalog1" type="relation"> <param name="form_split" value="rows=180,*"/> <param name="formid" value="gti.ffkdescr"/> <param name="form_source" value="pm.PCL1"/> <param name="form_type" value="form"/> <param name="navigator_position" value="W"/> <param name="navigator_fields" value="1"/> <param name="navigator_size" value="3"/> <param name="button_insert" value="1"/> <param name="button_delete" value="1"/> <param name="button_update" value="1"/> <param name="form_caption" value="Categoria"/> <param name="fields_remove" value="3"/> <param ord="2" name="formid" value="gti.ffkdescr"/> <param ord="2" name="form_source" value="pm.PCL2"/> <param ord="2" name="form_type" value="form"/> <param ord="2" name="navigator_position" value="W"/> <param ord="2" name="navigator_fields" value="1"/> <param ord="2" name="navigator_size" value="3"/> <param ord="2" name="button_insert" value="1"/> <param ord="2" name="button_delete" value="1"/> <param ord="2" name="button_update" value="1"/> <param ord="2" name="form_caption" value="Subcategoria"/> <param ord="2" name="fields_modify[0]" value="search#DATA:pm.PCL1;;;#3"/ > <param ord="2" name="source_filter_field" value="fk"/> </struct> A continuación, se presenta la interfaz de usuario final Clasificación de proyectos: 11/120 Figura 2: Interfaz de usuario Clasif. de proyectos 3.1.2 Definición de tipos de proyectos La descripción en ASL del Modelo de Presentación para esta interfaz es: <struct id="gti.pm.ctiposproy" type="relation"> <param name="form_split" value="rows=33%,*"/> <param name="formid" value="gti.ffkdescr"/> <param name="form_source" value="pm.ProjType"/> <param name="form_type" value="form"/> <param name="form_caption" value="Tipos de Proyectos"/> <param name="navigator_position" value="W"/> <param name="navigator_fields" value="1"/> <param name="button_insert" value="1"/> <param name="button_delete" value="1"/> <param name="button_update" value="1"/> <param name="fields_remove" value="2:3"/> <param ord="2" name="formid" value="wcaval.form.attr"/> <param ord="2" name="form_source" value="pm.ProjType_wcaval_attr"/> <param ord="2" name="form_type" value="table"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> A continuación, se presenta la interfaz de usuario final Def. de tipos de proyectos: 12/120 Figura 3: Interfaz de usuario Def. tipos de proyectos Departamento de Ingeniería Telemática Memoria de construcción 3.1.3 Definición de tipos de actividades La descripción en ASL del Modelo de Presentación para esta interfaz es: <struct id="gti.pm.ctiposactiv" type="relation"> <param name="form_split" value="rows=33%,*"/> <param name="formid" value="gti.ffkdescr"/> <param name="form_source" value="pm.ActivType"/> <param name="form_type" value="form"/> <param name="form_caption" value="Tipos de Actividades"/> <param name="navigator_position" value="W"/> <param name="navigator_fields" value="1"/> <param name="button_insert" value="1"/> <param name="button_delete" value="1"/> <param name="button_update" value="1"/> <param name="fields_remove" value="2:3"/> <param ord="2" name="formid" value="wcaval.form.attr"/> <param ord="2" name="form_source" value="pm.ActivType_wcaval_attr"/> <param ord="2" name="form_type" value="table"/> <param ord="2" name="button_data" value="1"/> <param ord="2" name="source_filter_field" value="fk"/> </struct> A continuación, se presenta la interfaz de usuario final Def. de tipos de actividades: 13/120 Figura 4: Interfaz de usuario Def. tipos de actividades 3.1.4 Ámbitos y administradores La descripción en ASL del Modelo de Presentación para esta interfaz es: <struct id="gti.pm.cscope" type="relation"> <param name="form_split" value="rows=40%,*"/> <param name="formid" value="gti.ffkdescr"/> <param name="form_source" value="gti.Scope"/> <param name="form_type" value="form"/> <param name="form_caption" value="Ambitos"/> <param name="navigator_position" value="W"/> <param name="navigator_fields" value="1"/> <param name="button_data" value="0"/> <param name="fields_remove" value="3"/> <param ord="2" name="formid" value="gti.pm.frelscopeu"/> <param ord="2" name="form_type" value="table"/> <param ord="2" name="form_subtype" value="tab"/> <param ord="2" name="form_tabs" value="Administradores:1"/> <param ord="2" name="source_filter_field" value="fkscope"/> <param ord="2" name="button_insert" value="1"/> <param ord="2" name="button_update" value="0"/> <param ord="2" name="button_delete" value="1"/> <param ord="2" name="fields_hidden" value="2"/> </struct> A continuación, se presenta la interfaz de usuario final Ámbitos y Administradores: 14/120 Figura 5: Interfaz de usuario Ámbitos y Administradores Departamento de Ingeniería Telemática Memoria de construcción 3.2 Administrador de proyectos La descripción en ASL del Modelo de Diálogo para el usuario administrador de proyectos es: <main id="gti.pm.main_adm_proy" caption="es=PM.Menu de administrador de proyectos|en=PM.Projects admin. menu"> <menu caption="Proyectos" tooltip="Proyectos"> <option caption="es=Administracion de proyectos|en=Activities Admin." call="gti.pm.cproj"/> </menu> <menu caption="Misc" tooltip="Otras cosas"> <option caption="es=Sobre este programa|en=About" call="gti.pm.cmodinfo" /> <option caption="es=Ayuda|en=Help" url="http://waine.us.es/dokuwiki/ doku.php?id=waine:help:app:gti:pm:menu:administrador" /> <option caption="es=Sobre WAINE|en=About WAINE" url="http://www.waine.org" /> <option caption="es=Salir|en=Logout" url="logout.php" /> </menu> </main> 3.2.1 Administración de proyectos La interfaz de usuario final Administración de proyectos se presenta en la siguiente figura: 15/120 Figura 6: Esquema Menú Admin. de proyectos Figura 7: Interfaz de usuario Administración de proyectos En el formulario Proyecto se contemplan tres pestañas (Información, Notas, Detalles). La pestaña Información, la cuál es mostrada en la anterior Figura 22, contiene los principales datos del proyecto. La pestaña Notas únicamente contiene un campo de texto, como se ve en la siguiente figura: La pestaña Detalles contiene el resto de campos del proyecto: La descripción en ASL del Modelo de Presentación para este formulario Proyecto es: <struct id="gti.pm.cproj2" type="relation"> <param name="form_split" value="rows=60%,*"/> <param name="formid" value="gti.pm.fproj"/> <param name="form_type" value="form"/> <param name="form_subtype" value="tab"/> <param name="form_tabs" value="Informacion:1,2,3,4,5,6,7;Notas:11;Detalles:8,9,10,12"/> <param name="source_filter_field" value="fkpcl2"/> <param name="form_modify[0]" value="filter#fkscope in (select fkscope from pm.REL_Scope_u where uid=%useruid)"/> <param name="fields_modify[0]" value="search#DATA:gti.Scope;pk in (select fkscope from pm.REL_Scope_u where uid=%useruid);;#6"/> 16/120 Figura 8: Interfaz de usuario Notas del formulario Proyecto Figura 9: Interfaz de usuario Detalles del formulario Proyecto Departamento de Ingeniería Telemática Memoria de construcción <param name="navigator_fields" value="name"/> <param name="navigator_position" value="W"/> <param name="navigator_width" value="20"/> <param name="source_order" value="pk ASC"/> <param name="button_misc" value="0"/> <param name="button_insert" value="1"/> <param name="button_update" value="1"/> <param name="button_delete" value="1"/> <param ord="2" name="structid" value="gti.pm.cproj3"/> </struct> Además, en la parte inferior de dicha interfaz de usuario final se contemplan siete pestañas (Actividades, Propiedades, Adjuntos, Miembros, Histórico, Dedicación, Esfuerzo), las cuáles dependen del proyecto seleccionado en el navegador. La pestaña Actividades muestra todas las actividades pertenecientes al proyecto seleccionado con sus datos principales: La descripción en ASL para esta tabla Actividad es: <struct id="gti.pm.cproj3" type="tab"> <param name="form_split" value="rows=22%,*"/> <param name="formid" value="gti.pm.factiv"/> <param name="tab_name" value="Actividades"/> <param name="form_type" value="table"/> <param name="source_filter_field" value="fkproj"/> <param name="source_order" value="pk ASC"/> <param name="fields_modify[0]" value="widget#urlbox3#1"/> <param name="fields_modify[1]" value="wdgparam#struct.php? structid=gti.pm.cactiv&source_filter_field=pk&source_filter_value=;_blan k;;#1"/> <param name="button_insert" value="1"/> <param name="button_update" value="1"/> <param name="button_delete" value="1"/> <param name="button_action" value="0"/> <param name="button_misc" value="0"/> <param name="fields_hidden" value="10-13:14:15:17-19"/> <param name="fields_remove" value="4:8-9"/> 17/120 Figura 10: Interfaz de usuario Actividades (Administración de proyectos) La pestaña Propiedades muestra los campos personalizables del proyecto, así como sus valores: La descripción en ASL para esta tabla Propiedades es: <param ord="2" name="tab_name" value="Propiedades"/> <param ord="2" name="formid" value="wcaval.form.value"/> <param ord="2" name="form_source" value="pm.Proj_wcaval_value"/> <param ord="2" name="form_type" value="table"/> <param ord="2" name="source_filter_field" value="fk"/> <param ord="2" name="form_theme" value="wcaval_0.1/buttons.cfg"/> <param ord="2" name="fields_modify[0]" value="search#DATA:pm.Proj_wcaval_atfull;;;#1"/> <param ord="2" name="button_update" value="1"/> La pestaña Adjuntos expone los documentos anexos al proyecto: La descripción en ASL para esta tabla Adjuntos es: <param ord="3" name="tab_name" value="Adjuntos"/> <param ord="3" name="formid" value="attach.form.catattach"/> <param ord="3" name="form_type" value="table"/> <param ord="3" name="fields_modify[0]" value="defvalue#1#3"/> <param ord="3" name="fields_remove" value="5:7"/> <param ord="3" name="fields_readonly" value="3"/> <param ord="3" name="button_data" value="1"/> <param ord="3" name="source_filter_field" value="fk"/> 18/120 Figura 11: Interfaz de usuario Propiedades (Administración de proyectos) Figura 12: Interfaz de usuario Adjuntos (Administración de proyectos) Departamento de Ingeniería Telemática Documento de Implantación Documento de implantación del módulo de gestión de proyectos Antonio Luis Delgado González, [email protected] 10/02/2020 Índice 1Introducción........................................................................................................................................3 2Procedimiento de despliegue..............................................................................................................3 3Paquete gti-base..................................................................................................................................6 3.1Instalador del paquete gti-base...................................................................................................8 4Paquete gti-pm....................................................................................................................................9 5Informe de despliegue......................................................................................................................12 5.1Informe de despliegue de gti.install..........................................................................................12 5.2Informe de instalación del paquete gti-pm...............................................................................25 6Anexos..............................................................................................................................................32 6.1winter.install..............................................................................................................................32 1/32 2/32 Departamento de Ingeniería Telemática Documento de Implantación 1 Introducción 1 Introducción Este documento presenta el procedimiento de despliegue así como el contenido de los paquetes y scripts necesesarios para la correcta instalación del módulo de gestión de proyectos de GTI. 2 Procedimiento de despliegue En esta sección se detalla el procedimiento de despliegue completo para la instalación del módulo de gestión de proyectos. Los requisitos que se están teniendo en cuenta para esta instalación son los siguientes: •BD winter: BD (sqlite2) •RMIU winter: MBD (sqlite2) •BD gti: gti (PostgreSQL 8.4) En caso de desplegar con un software base distinto el procedimiento podría diferir ligeramente. Los pasos para realizar el despligue son los siguientes: 1. Creación de la base de datos 2. Creación de la instancia de la aplicación 3. Configuración de orígenes de datos y utilidades para paquetes ◦db.cfg: usando driver sqlite2 y base de datos DB ◦mdb.cfg: usando driver sqlite2 y base de datos MDB ◦dbupd: usando sqlite2 y base de datos DB ◦mdbupd: usando sqlite2 y base de datos DB 4. Instalación de la aplicación winter y sus dependencias 5. Reconfiguración de orígenes de datos y utilidades para paquetes ◦mdbupd: usando driver sqlite2 y base de datos DB ◦dbupd: usando driver pgsql y base de datos gtidb 6. Instalación del paquete gti-base y sus dependencias 7. Instalación del paquete gti-pm 3/32 El procedimiento anterior se ha implementado en el script gti.install que se detalla a continuación: PDIR=gti.stuff DBOPTS="-U waine" DATABASE=gtidb WDIR=/usr/local/lib/waine-0.5.4 INSTANCE=gti function message(){ echo -e "\ n=========================================================================" echo $1 - `date '+%F %T.%N'` echo -e "=========================================================================\n\n" } ######################################################### # 1. Creacion de la base de datos ######################################################### message "Creating database $DATABASE" dropdb $DBOPTS $DATABASE createdb $DBOPTS $DATABASE ( cat << EOF CREATE LANGUAGE plpgsql; EOF ) | psql $DBOPTS $DATABASE ######################################################### # 2. Creacion de la instancia de la aplicaion ######################################################### message "Creating application instance $INSTANCE" rm -rf $INSTANCE $WDIR/bin/mkapp $INSTANCE ################################################################ # 3. Configuracion de origenes de datos y utilidades para paquetes ################################################################ message "Setting sqlite DB and MDB for winter in $INSTANCE" sed -i 's/sqlite3/sqlite/g' $INSTANCE/_CONF/DOM/db.cfg sed -i 's/sqlite3/sqlite/g' $INSTANCE/_CONF/DOM/mdb.cfg rm $INSTANCE/packages/bin/dbupd rm $INSTANCE/packages/bin/mdbupd pushd . cd $INSTANCE/packages/bin/ 4/32 Departamento de Ingeniería Telemática Documento de Implantación 2 Procedimiento de despliegue ln -s dbupd.sqlite2 dbupd ln -s mdbupd.sqlite2 mdbupd popd ######################################################### # 4. Instalacion de la aplicacion winter y sus dependencias ######################################################### message "Installing winter on $INSTANCE" ./winter.install ################################################################## # 5. Reconfiguracion de origenes de datos y utilidades para paquetes ################################################################## message "Setting sqlite DB and MDB for gti in $INSTANCE" sed -i 's-/MDB-/DB-g' $INSTANCE/packages/bin/mdbupd sed -i s/"OPTIONS=''"/OPTIONS="'$DBOPTS'"/g $INSTANCE/packages/bin/dbupd.pgsql sed -i s/"DATABASE=''"/DATABASE="'$DATABASE'"/g $INSTANCE/packages/bin/dbupd.pgsql rm $INSTANCE/packages/bin/dbupd pushd . cd $INSTANCE/packages/bin/ ln -s dbupd.pgsql dbupd popd ######################################################### # 6. Instalacion del paquete gti-base y sus dependencias ######################################################### message "Installing gti-base on $INSTANCE" ./gti-base.install Finalmente se realizaría el último paso, las instalación del paquete gti-pm. /usr/local/lib/waine-0.5.4/bin/wpkg install APP.gti-pm_1.0.wpk gti Como se puede apreciar en codigo del script gti.install, se invoca a otros dos scripts: winter.install y gti-base.install. El primero de ellos dado que no presenta relevancia para este proyecto se presenta en el anexo 6.1. El script gti-base.install se muestra en la sección 3.1. 5/32 3 Paquete gti-base El paquete gti-base contiene los elementos básicos y dependencias comunes del sistema GTI. La relación de artefactos suministrados con el paquete es la siguiente: •ASL/gti.asl: código ASL con elementos e inclusiones comunes del APM. •doc/gti_CREATE.sql: código SQL con definiciones de elementos comunes del DOM. •doc/gti_DATA.sql: código SQL con inserciones de datos básicos. •files/blob/DS/GTI.cfg: datasource de la aplicación GTI. •files/g.cfg: archivo de configuración para la página de redirección g.php. •files/g.php: página para redirecciones a IUs de la aplicación (empleado conjuntamente con wikitextbox). •files/packages/bin/gti-mdb-update: script de actualización tras la instalación de paquetes gti. Este script se encarga de eliminar opciones (como la de abandonar el programa) que ya no tienen sentido al integrarse dentro de la aplicación winter, así como de asignar el origen de datos files/blob/DS/GTI.cfg (que no se ha empleado durante el desarrollo) a formularios y otros elementos. CMDPATH=`echo $0 | cut -d/ -f1` echo GTI Updating $CMDPATH/DB ( cat <<EOF DELETE FROM _option WHERE url='logout.php'; DELETE FROM _option WHERE url='http://www.waine.org'; UPDATE _form SET dsource='blob/DS/GTI.cfg' WHERE formid LIKE 'wcaval%' AND dsource=''; UPDATE _form SET dsource='blob/DS/GTI.cfg' WHERE formid LIKE 'attach%' AND dsource=''; UPDATE _form SET dsource='blob/DS/GTI.cfg' WHERE formid LIKE 'gti.%' AND dsource=''; UPDATE _field SET search=substr(search,1,length(search)-3)||';;;blob/DS/GTI.cfg' WHERE search LIKE 'DATA%'; UPDATE _parameter SET value= substr(value,1,length(value)-2)||'blob/DS/GTI.cfg'|| substr(value,length(value)-1,2) WHERE value LIKE '%DATA:%#_'; UPDATE _parameter SET value= substr(value,1,length(value)-3)||'blob/DS/GTI.cfg'|| substr(value,length(value)-2,3) WHERE value LIKE '%DATA:%#__'; INSERT INTO _parameter(parameterid,structid,ord,name,value) SELECT parameterid||'b',structid,ord,'form_datasource', 'blob/DS/GTI.cfg' FROM _parameter WHERE name='form_source'; EOF ) | sqlite "$CMDPATH/DB" 6/32 Departamento de Ingeniería Telemática Documento de Implantación 3 Paquete gti-base •meta/meta.xml: Archivo con metainformación sobre el paquete: dependencias, funcionalidades ofrecidas, etc. A continuación se muestra el contenido de este fichero: <wpkg> <package> <name>APP.gti-base</name> <ver>1.0</ver> <author>aldelgado</author> <date>2020-02-06</date> <description> GTI base models and artifacts </description> </package> <provides> <func>APP.gti-base_1.0</func> <func>gti.ffkdescr</func> <func>gti.username</func> <func>gti.fmeta</func> <func>gti.OUL1</func> <func>gti.OUL2</func> <func>gti.OUL3</func> <func>gti.VIEW_OU</func> <func>gti.Site</func> <func>gti.LL1</func> <func>gti.LL2</func> <func>gti.VIEW_Loc</func> <func>gti.Scope</func> <func>g.php</func> <func>g.cfg</func> <func>blob/DS/GTI.cfg</func> <func>packages/bin/gti-mdb-update</func> </provides> <depends> <package>WAINE-0.4.8</package> <package>APP.winter_0.2</package> <package>CP.WDG.stcombo_1.0.wpk</package> <package>CP.WDG.fstextbox_1.0.wpk</package> <package>CP.WDG.wikitextbox_1.0.wpk</package> <package>MM.attach_1.0.wpk</package> <package>MMI.wcaval_0.2.wpk</package> </depends> </wpkg> •meta/postins.sh: script que se ejecuta de forma posterior a la instalación del paquete. En gti-base este archivo se encarga de instalar los objetos básicos del modelo de datos y de configurar el origen de datos DSRCGTI en el fichero _CONF/DOM/dsource.inc. El contenido de este fichero es el siguiente: 7/32 addline '_CONF/DOM/dsource.inc' "// Added by wpkg $PKGNAME `date +%Y-%m-%d`" addline '_CONF/DOM/dsource.inc' '$DSRCGTI="blob/DS/GTI.cfg";' echo 'Setting DB' echo '1) install DB' echo '0) not install DB' echo echo -n 'Select an option (1,0): ' read RESP case "$RESP" in 1) echo "Executing DB creation script" ; $WPKGDIR/bin/dbupd $SRCDIR/doc/gti_CREATE.sql ; echo "Executing DB data script" ; $WPKGDIR/bin/dbupd $SRCDIR/doc/gti_DATA.sql ; echo "Executing wcaval creation script" ; $WPKGDIR/bin/dbupd $SRCDIR/doc/wcaval_CREATE.sql ;; 0) echo 'DB creation scripts will be available in the doc directory' ;; *) echo 'Unknown option. Skiping...' ;; esac •meta/preins.sh: script de ejecución previa a la instalación del paquete. En el caso concreto del paquete gti-base este archivo está vacío. 3.1 Instalador del paquete gti-base A continuación se presenta el instador que se ha implementado para el despliegue del paquete gti-base. WDIR=/usr/local/lib/waine-0.5.4 PDIR=gti-base.stuff INSTANCE=gti function pkginst () { local TMPFILE TMPFILE=`mktemp` || exit 1 echo -e "\n------------------------------------------------------------" echo -e Instalando paquete $1 - `date '+%F %T.%N'` echo -e "------------------------------------------------------------" echo -e "ejecutando: $WDIR/bin/wpkg install $PDIR/$1 $INSTANCE \n\n" cat - > $TMPFILE echo wpkg inputs echo ----------- cat $TMPFILE echo -e "\n\n" cat $TMPFILE | $WDIR/bin/wpkg install $PDIR/$1 $INSTANCE --force echo -e "\n\n---------------------------------------------------------" echo Fin Instalacion paquete $1 - `date '+%F %T.%N'` echo -e "-------------------------------------------------------\n\n" rm -rf $TMPFILE || exit 2 8/32 Departamento de Ingeniería Telemática Documento de Implantación 3 Paquete gti-base } echo | pkginst CP.WDG.stcombo_1.0.wpk echo | pkginst CP.WDG.fstextbox_1.0.wpk echo | pkginst CP.WDG.wikitextbox_1.0.wpk ( cat <<EOF y 1 EOF ) | pkginst MM.attach_1.0.wpk ( cat <<EOF y 0 EOF ) | pkginst MMI.wcaval_0.2.wpk ( cat <<EOF 1 1 EOF ) | pkginst APP.gti-base_1.0.wpk 4 Paquete gti-pm El paquete gti-pm contiene los elementos del módulo de gestión de proyectos. Su contenido es el siguiente: •ASL/gti.pm.asl: Código ASL del módulo de gestión de proyectos. •doc/gestion_proy.asl: Versión original del código del módulo. •doc/gtipm_CREATE.sql: Script de creación de la BD del módulo de gestión de proyectos. •doc/gtipm_DATA.sql: Script con la carga de datos básica del módulo. 9/32 •doc/gtipm_DATA_proj.sql: Script con la carga de proyectos tipo. •doc/wcaval_CREATE.pm.Activ.sql: Script con el modelo de datos de wcaval instanciado para la tabla Activ. •doc/wcaval_CREATE.pm.Proj.sql: Script con el modelo de datos de wcaval instanciado para la tabla Proj. •files/_CONF/CPM/reports/gti.png: Imagen con el logo GTI empleado en los informes. •files/_CONF/CPM/reports/reportactiv.fig: Informe de actividades. •files/_CONF/CPM/reports/reportproy.fig: Informe de proyectos. •files/_CONF/DOM/GTI/g.pm.inc: Definición de las funciones necesarias para la redirección de enlaces de proyectos y actividades (empleado por wikitextbox). <?php function redirProj($IN_u,$IN_k){ $rol=waine_DsGetCol('role', 'pm.rel_proj_u',"uid='$IN_u' and fkproj='$IN_k'","DSRCGTI"); switch($rol){ case 1: redirStruct('gti.pm.cproj2',$IN_k); break; case 2: redirStruct('gti.pm.cproj2_ro',$IN_k); break; case 3: redirStruct('gti.pm.cproj2_ro2',$IN_k); break; case 4: redirStruct('gti.pm.cprojuser2',$IN_k); break; default: redirStruct('gti.pm.cprojuser_na',$IN_k); break; } return true; } function redirActiv($IN_u,$IN_k){ $rol=waine_DsGetCol('role', 'pm.rel_proj_u',"uid='$IN_u' and fkproj='$IN_k'","DSRCGTI"); switch($rol){ case 1: redirStruct('gti.pm.cactiv',$IN_k); break; case 2: redirStruct('gti.pm.cactiv',$IN_k); break; case 3: redirStruct('gti.pm.cactiv_ro',$IN_k); break; case 4: redirStruct('gti.pm.cactiv_user',$IN_k); break; default: redirStruct('gti.pm.cactivuser_na',$IN_k); break; } return true; } ?> 10/32 Departamento de Ingeniería Telemática Documento de Implantación 5 Informe de despliegue Codemirror widget config 1) use codemirror widget 0) don't use codemirror Select an option (1,0): sqlite command (default:sqlite ): sqlite command (default:/MDB): updating sqlite gti//MDB - sqlite gti//MDB /tmp/tmp.tdQtbB5044/APP.winter_0.2/ doc/mdb.codemirror.upd.sql Setting permissions Setting fdm and fpm datasources done ! Waine INTEgratoR ------------------------------------------------------------------------ Fin Instalacion paquete APP.winter_0.2.wpk - 2020-02-10 07:54:51.371679237 ------------------------------------------------------------------------ ========================================================================= Setting sqlite DB and MDB for gti in gti - 2020-02-10 07:54:51.375458899 ========================================================================= /mnt/ramdisk/test /mnt/ramdisk/test /mnt/ramdisk/test ========================================================================= Installing gti-base on gti - 2020-02-10 07:54:51.382549488 ========================================================================= ------------------------------------------------------------------------ Instalando paquete CP.WDG.stcombo_1.0.wpk - 2020-02-10 07:54:51.387118358 ------------------------------------------------------------------------ ejecutando: /usr/local/lib/waine-0.5.4/bin/wpkg install gtibase.stuff/CP.WDG.stcombo_1.0.wpk gti wpkg inputs ----------- 17/32 Installing gti-base.stuff/CP.WDG.stcombo_1.0.wpk modified _CONF/CPM/userwdg.inc: addline // Added by wpkg CP.WDG.stcombo_1.0 2020-02-10 modified _CONF/CPM/userwdg.inc: addline require_once('widgets/stcolcombo.inc'); modified _CONF/CPM/userwdg.inc: addline require_once('widgets/stcombo.inc'); done ! A combo box with allowed transitions ------------------------------------------------------------------------ Fin Instalacion paquete CP.WDG.stcombo_1.0.wpk - 2020-02-10 07:54:51.432288448 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Instalando paquete CP.WDG.fstextbox_1.0.wpk - 2020-02-10 07:54:51.437223197 ------------------------------------------------------------------------ ejecutando: /usr/local/lib/waine-0.5.4/bin/wpkg install gtibase.stuff/CP.WDG.fstextbox_1.0.wpk gti wpkg inputs ----------- Installing gti-base.stuff/CP.WDG.fstextbox_1.0.wpk modified _CONF/CPM/userwdg.inc: addline // Added by wpkg CP.WDG.fstextbox_1.0 2020-02-10 modified _CONF/CPM/userwdg.inc: addline require_once('widgets/fstextbox.inc'); done ! A textbox widget displaying always the same width and height ------------------------------------------------------------------------ Fin Instalacion paquete CP.WDG.fstextbox_1.0.wpk - 2020-02-10 07:54:51.483082610 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Instalando paquete CP.WDG.wikitextbox_1.0.wpk - 2020-02-10 07:54:51.487638967 ------------------------------------------------------------------------ ejecutando: /usr/local/lib/waine-0.5.4/bin/wpkg install gtibase.stuff/CP.WDG.wikitextbox_1.0.wpk gti wpkg inputs ----------- 18/32 Departamento de Ingeniería Telemática Documento de Implantación 5 Informe de despliegue Installing gti-base.stuff/CP.WDG.wikitextbox_1.0.wpk modified _CONF/CPM/userwdg.inc: addline // Added by wpkg CP.WDG.wikitextbox_1.0 2020-02-10 modified _CONF/CPM/userwdg.inc: addline require_once('widgets/wikitextbox.inc'); done ! Wiki configurable textbox ------------------------------------------------------------------------ Fin Instalacion paquete CP.WDG.wikitextbox_1.0.wpk - 2020-02-10 07:54:51.532080004 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Instalando paquete MM.attach_1.0.wpk - 2020-02-10 07:54:51.536798134 ------------------------------------------------------------------------ ejecutando: /usr/local/lib/waine-0.5.4/bin/wpkg install gtibase.stuff/MM.attach_1.0.wpk gti wpkg inputs ----------- y 1 Installing gti-base.stuff/MM.attach_1.0.wpk This package requires functional gti/packages/bin/mdbupd and gti/packages/bin/dbupd Are these scripts ready ? (y/N): working with ASL in /tmp/tmp.yGmtjh5243/MM.attach_1.0/ASL/attach.asl Updating gti/DB with /tmp/tmp.yGmtjh5243/MM.attach_1.0/ASL/attach.asl asl2mdb.gensqlite Init asl2mdb.Message: gti/DB already exists. Appending. cp: cannot create regular file `/tmp/last': Permission denied asl2mdb.Message: Generating sql /tmp/tmp.yxBnCf5268. asl2mdb.Message: Generating sqlite file gti/DB. Available options: 1) attach_CREATE.pgsql.sql 2) attach_CREATE.sqlite.sql 0) not install DB Select an option (1,2,0): Updating gtidb with /tmp/tmp.yGmtjh5243/MM.attach_1.0/ doc/attach_CREATE.pgsql.sql NOTICE: CREATE TABLE will create implicit sequence "attach_category_pk_seq" for serial column "attach_category.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "attach_category_pkey" for table "attach_category" CREATE TABLE 19/32 NOTICE: CREATE TABLE will create implicit sequence "attach_item_pk_seq" for serial column "attach_item.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "attach_item_pkey" for table "attach_item" CREATE TABLE CREATE FUNCTION CREATE TRIGGER done ! A package providing generic categorized attachements ------------------------------------------------------------------------ Fin Instalacion paquete MM.attach_1.0.wpk - 2020-02-10 07:54:51.954822527 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Instalando paquete MMI.wcaval_0.2.wpk - 2020-02-10 07:54:51.959894626 ------------------------------------------------------------------------ ejecutando: /usr/local/lib/waine-0.5.4/bin/wpkg install gtibase.stuff/MMI.wcaval_0.2.wpk gti wpkg inputs ----------- y 0 Installing gti-base.stuff/MMI.wcaval_0.2.wpk This package requires functional gti/packages/bin/mdbupd , gti/packages/bin/dbupd, gti/packages/bin/wmcodeinst and gti/packages/bin/wmcoderpl Are these scripts ready ? (y/N): wcaval data model: +--------+ * 1 +-------------+ | Entity +------------------------| Entity_type | +---+----+ +------+------+ |1 |1 | | | | | | |* |* +--------+-----------+ * 1 +-----------+-------------+ |Entity_wcaval_value +------------| Entity_type_wcaval_attr | +--------------------+ +-------------------------+ Use an instance for each Entity with custom attributes in your schema 20/32 Departamento de Ingeniería Telemática Documento de Implantación 5 Informe de despliegue Found instantiable file /tmp/tmp.SkEkxw5308/MMI.wcaval_0.2/doc/wcaval_CREATE.sqlt Processing macros in /tmp/tmp.SkEkxw5308/MMI.wcaval_0.2/doc/wcaval_CREATE.sql Found macro ENTITY_TYPE_TABLE_NAME (Entity type table name) in /tmp/tmp.SkEkxw5308/MMI.wcaval_0.2/doc/wcaval_CREATE.sql Found macro ENTITY_TYPE_TABLE_PK (Entity type table primary key) in /tmp/tmp.SkEkxw5308/MMI.wcaval_0.2/doc/wcaval_CREATE.sql Found macro ENTITY_TABLE_PK (Entity table primary key) in /tmp/tmp.SkEkxw5308/MMI.wcaval_0.2/doc/wcaval_CREATE.sql working with ASL in /tmp/tmp.SkEkxw5308/MMI.wcaval_0.2/ASL/wcaval.asl Updating gti/DB with /tmp/tmp.SkEkxw5308/MMI.wcaval_0.2/ASL/wcaval.asl asl2mdb.gensqlite Init asl2mdb.Message: gti/DB already exists. Appending. cp: cannot create regular file `/tmp/last': Permission denied asl2mdb.Message: Generating sql /tmp/tmp.MTNpPt5349. asl2mdb.Message: Generating sqlite file gti/DB. modified _CONF/CPM/userwdg.inc: addline // Added by wpkg MMI.wcaval_0.2 2020-02- 10 modified _CONF/CPM/userwdg.inc: addline require_once('_CONF/CPM/widgets/wcaval_0.1/wcaval.inc'); Available options: 1) install wcaval database 0) not install DB Select an option (1,0): DB creation scripts will be available in the doc directory done ! Waine Custom Attribute-VAlue. A package allowing custom fields for any Entity in the Domain Model ------------------------------------------------------------------------ Fin Instalacion paquete MMI.wcaval_0.2.wpk - 2020-02-10 07:54:52.096439167 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Instalando paquete APP.gti-base_1.0.wpk - 2020-02-10 07:54:52.102129112 ------------------------------------------------------------------------ ejecutando: /usr/local/lib/waine-0.5.4/bin/wpkg install gti-base.stuff/APP.gtibase_1.0.wpk gti wpkg inputs ----------- 1 1 21/32 Installing gti-base.stuff/APP.gti-base_1.0.wpk working with ASL in /tmp/tmp.gPplpK5390/APP.gti-base_1.0/ASL/gti.asl Updating gti/DB with /tmp/tmp.gPplpK5390/APP.gti-base_1.0/ASL/gti.asl asl2mdb.gensqlite Init asl2mdb.Message: gti/DB already exists. Appending. cp: cannot create regular file `/tmp/last': Permission denied asl2mdb.Message: Generating sql /tmp/tmp.UhLPUi5415. asl2mdb.Message: Generating sqlite file gti/DB. Setting DB 1) install DB 0) not install DB Select an option (1,0): Executing DB creation script Updating gtidb with /tmp/tmp.gPplpK5390/APP.gti-base_1.0/doc/gti_CREATE.sql ERROR: language "plpgsql" already exists gti_CREATE: Creating schema ----------------------------- (1 row) ERROR: schema "gti" does not exist CREATE SCHEMA COMMENT gti_CREATE: Creating OUs -------------------------- (1 row) NOTICE: CREATE TABLE will create implicit sequence "oul1_pk_seq" for serial column "oul1.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "oul1_pkey" for table "oul1" CREATE TABLE COMMENT NOTICE: CREATE TABLE will create implicit sequence "oul2_pk_seq" for serial column "oul2.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "oul2_pkey" for table "oul2" CREATE TABLE COMMENT NOTICE: CREATE TABLE will create implicit sequence "oul3_pk_seq" for serial column "oul3.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "oul3_pkey" for table "oul3" CREATE TABLE COMMENT CREATE VIEW COMMENT gti_CREATE: Creating Locations -------------------------------- (1 row) NOTICE: CREATE TABLE will create implicit sequence "site_pk_seq" for serial column "site.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "site_pkey" for table "site" 22/32 Departamento de Ingeniería Telemática Documento de Implantación 5 Informe de despliegue CREATE TABLE COMMENT NOTICE: CREATE TABLE will create implicit sequence "ll1_pk_seq" for serial column "ll1.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "ll1_pkey" for table "ll1" CREATE TABLE COMMENT NOTICE: CREATE TABLE will create implicit sequence "ll2_pk_seq" for serial column "ll2.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "ll2_pkey" for table "ll2" CREATE TABLE COMMENT CREATE VIEW COMMENT gti_CREATE: Creating Scope ---------------------------- (1 row) NOTICE: CREATE TABLE will create implicit sequence "scope_pk_seq" for serial column "scope.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "scope_pkey" for table "scope" CREATE TABLE Executing DB data script Updating gtidb with /tmp/tmp.gPplpK5390/APP.gti-base_1.0/doc/gti_DATA.sql gti_DATA: Inserting OUs ------------------------- (1 row) INSERT 1078468 1 INSERT 1078469 1 INSERT 1078470 1 INSERT 1078471 1 INSERT 1078472 1 INSERT 1078473 1 INSERT 1078474 1 INSERT 1078475 1 INSERT 1078476 1 INSERT 1078477 1 INSERT 1078478 1 INSERT 1078479 1 INSERT 1078480 1 INSERT 1078481 1 gti_DATA: Inserting Locations ------------------------------- (1 row) INSERT 1078482 1 INSERT 1078483 1 INSERT 1078484 1 INSERT 1078485 1 INSERT 1078486 1 23/32 INSERT 1078487 1 INSERT 1078488 1 INSERT 1078489 1 INSERT 1078490 1 INSERT 1078491 1 INSERT 1078492 1 INSERT 1078493 1 INSERT 1078494 1 INSERT 1078495 1 INSERT 1078496 1 INSERT 1078497 1 INSERT 1078498 1 INSERT 1078499 1 INSERT 1078500 1 INSERT 1078501 1 INSERT 1078502 1 INSERT 1078503 1 INSERT 1078504 1 INSERT 1078505 1 INSERT 1078506 1 INSERT 1078507 1 INSERT 1078508 1 INSERT 1078509 1 INSERT 1078510 1 INSERT 1078511 1 INSERT 1078512 1 INSERT 1078513 1 INSERT 1078514 1 INSERT 1078515 1 INSERT 1078516 1 INSERT 1078517 1 INSERT 1078518 1 gti_DATA: Inserting Scope --------------------------- (1 row) INSERT 1078519 1 Executing wcaval creation script Updating gtidb with /tmp/tmp.gPplpK5390/APP.gti-base_1.0/doc/wcaval_CREATE.sql ERROR: language "plpgsql" already exists ERROR: table "wcaval_regexp" does not exist NOTICE: CREATE TABLE will create implicit sequence "wcaval_regexp_pk_seq" for serial column "wcaval_regexp.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "wcaval_regexp_pkey" for table "wcaval_regexp" CREATE TABLE INSERT 1078527 1 INSERT 1078528 1 INSERT 1078529 1 INSERT 1078530 1 INSERT 1078531 1 INSERT 1078532 1 INSERT 1078533 1 INSERT 1078534 1 INSERT 1078535 1 INSERT 1078536 1 INSERT 1078537 1 INSERT 1078538 1 24/32 Departamento de Ingeniería Telemática Documento de Implantación 5 Informe de despliegue done ! ------------------------------------------------------------------------ Fin Instalacion paquete APP.gti-base_1.0.wpk - 2020-02-10 07:54:54.467350775 ------------------------------------------------------------------------ 5.2 Informe de instalación del paquete gti-pm En esta sección se presenta la salida de la instalación del paquete gti-pm (sección 4). Installing APP.gti-pm_1.0.wpk Verfiying dependences WAINE-0.4.8 ok APP.gti-base_1.0 ok Dependences ok Checking conflicts No conflicts working with ASL in /tmp/tmp.Pgidzc5474/APP.gti-pm_1.0/ASL/gti.pm.asl Updating gti/DB with /tmp/tmp.Pgidzc5474/APP.gti-pm_1.0/ASL/gti.pm.asl asl2mdb.gensqlite Init asl2mdb.Message: gti/DB already exists. Appending. cp: cannot create regular file `/tmp/last': Permission denied asl2mdb.Message: Generating sql /tmp/tmp.hizEMX5515. asl2mdb.Message: Generating sqlite file gti/DB. Updating UIMs GTI Updating gti/DB modified _CONF/CPM/widgets/wikitextbox.cfg: addline // Added by wpkg APP.gtipm_1.0 2020-02-10 modified _CONF/CPM/widgets/wikitextbox.cfg: addline $TAGREPLACE[]=array('/[Pp] [Mm].[Pp]#(\d+)/','<a target="_blank" href="g?p=pm.P${1}">pm.P#${1}</a>'); modified _CONF/CPM/widgets/wikitextbox.cfg: addline $TAGREPLACE[]=array('/[Pp] [Mm].[Aa]#(\d+)/','<a target="_blank" href="g?p=pm.A${1}">pm.A#${1}</a>'); modified g.cfg: addline // Added by wpkg APP.gti-pm_1.0 2020-02-10 modified g.cfg: addline $REDIRFUNC->register("pm.P", "redirProj"); modified g.cfg: addline $REDIRFUNC->register("pm.A", "redirActiv"); modified g.cfg: addline require_once '_CONF/DOM/GTI/g.pm.inc'; Setting DB 1) install DB 0) not install DB 25/32 Select an option (1,0): Updating gtidb with /tmp/tmp.Pgidzc5474/APP.gtipm_1.0/doc/gtipm_CREATE.sql gtipm_CREATE: Creating schema ------------------------------- (1 row) ERROR: schema "pm" does not exist CREATE SCHEMA gtipm_CREATE: Creating PCLs ----------------------------- (1 row) NOTICE: CREATE TABLE will create implicit sequence "pcl1_pk_seq" for serial column "pcl1.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "pcl1_pkey" for table "pcl1" CREATE TABLE NOTICE: CREATE TABLE will create implicit sequence "pcl2_pk_seq" for serial column "pcl2.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "pcl2_pkey" for table "pcl2" CREATE TABLE gtipm_CREATE: Creating Proj ----------------------------- (1 row) NOTICE: CREATE TABLE will create implicit sequence "projtype_pk_seq" for serial column "projtype.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "projtype_pkey" for table "projtype" CREATE TABLE NOTICE: CREATE TABLE will create implicit sequence "proj_pk_seq" for serial column "proj.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "proj_pkey" for table "proj" CREATE TABLE gtipm_CREATE: Creating Activ ------------------------------ (1 row) NOTICE: CREATE TABLE will create implicit sequence "activtype_pk_seq" for serial column "activtype.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "activtype_pkey" for table "activtype" CREATE TABLE NOTICE: CREATE TABLE will create implicit sequence "activ_pk_seq" for serial column "activ.pk" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "activ_pkey" for table "activ" CREATE TABLE gtipm_CREATE: Creating Entry ------------------------------ (1 row) 26/32 CONCLUSIONES En este trabajo fin de grado se ha desarrollado el módulo de gestión de proyectos para la aplicación GTI. Este módulo está destinado a la planificación, control y seguimiento de los proyectos TIC de una organización. El producto desarrollado tiene 19 tablas, 9 vistas, 5 menús, 16 unidades de interacción y 18 formularios. Tablas Vistas Menús Unidades de interacción Formularios 19 9 5 16 18 Se han codificado 409 líneas de código SQL y 1555 líneas de código ASL. Por modelos la carga en líneas de código para cada uno de ellos es: DOM(SQL) % UM % DM % PM % TOTAL 409 20,8 51 2,6 73 3,7 1431 72,9 1964 Para realizar el desarrollo de las interfaces de usuario de la forma más rápida y con mayor calidad se ha empleado la reutilización de componentes de la interfaz de usuario con las técnicas ofrecidas por WAINE. Se han reutilizado de forma sistemática los componentes de los paquetes attach y wcaval. Se ha empleado esta técnica para reutilizar los fragmentos ASL y SQL en tiempo de desarrollo de los paquetes wcaval para los campos personalizados tanto de proyectos como de actividades y attach para los documentos anexos a proyectos y actividades. Algunos contenedores y formularios se han reutilizado con frecuencia en el Modelo de Presentación empleando la subespecificación. Por ejemplo, el contenedor gti.pm.cproj3 del rol administrador de proyectos se ha reutilizado para el rol gestor de proyectos. La técnica Adaptación ha dado la posibilidad de incrementar la reusabilidad de los formularios definidos en el Modelo de Presentación únicamente modificando sus propiedades. Por ejemplo, la definición de formulario gti.pm.fproj_NoAdmin con 12 campos para manejar la información de los proyectos en roles distintos de administrador de proyectos fue referenciado 3 veces desde diferentes contenedores usando parámetros para obtener distintas variantes. Asimismo, se ha reutilizado de forma pragmática el formulario gti.pm.factivfilter para el filtro de la interfaz de usuario Lista de actividades del rol técnico ya que era similar al filtro de la interfaz de usuario Gestión de actividades del rol gestor de proyectos creado previamente. También, se ha utilizado la etiqueta estándar XInclude como técnica de inclusión para la reutilización de fragmentos de otros códigos ASL en tiempo de desarrollo. Por ejemplo, el formulario gti.ffkdescr referenciado 5 veces. A continuación, se muestra una tabla con el número de veces que se han reutilizado algunos elementos del APM: attach.form.catattach gti.ffkdescr gti.pm.fproj_NoAdmin gti.pm.factivfilter gti.pm.cproj3 11 veces 5 veces 3 veces 4 veces 2 veces El trabajo se ha dividido en 4 actividades principales: Formación y Aprendizaje, Plan de Trabajo, Diseño y Construcción. •El tiempo dedicado a la Formación y Aprendizaje ha sido 26 horas y 15 minutos. Se empezó a mediados de Julio y se terminó a finales de Agosto. Al principio, para familiarizarse y aprender a utilizar el entorno WAINE, el proceso de desarrollo y la codificación ASL se llevó a cabo un proceso de lectura y comprensión de varios documentos y artículos científicos, concretamente IJHCS2016 Reusing UI elements with Model-Based User Interface Development, tesis de Antonio Luis Delgado González Propuestas para la reutilización en el Desarrollo de Interfaces de Usuario Basado en Modelos y artículo WAINE Automatic generator of web based applications. Una vez conocidos los principales aspectos de WAINE se realizaron 3 ejercicios de ejemplo de distinta dificultad, el primer ejemplo se realizó en 45 minutos, el segundo en 1 hora y 30 minutos y el tercero en 2 horas. Después, se realizó un estudio de las aplicaciones de ejemplo creadas en dicho entorno, así como una lectura de sus correspondientes códigos ASL. Finalmente, para terminar esta actividad se realizó un repaso del lenguaje SQL y del empleo de base de datos PostgreSQL. •El tiempo dedicado al Plan de Trabajo ha sido 7 horas y 30 minutos. Al principio de esta actividad, para realizar la introducción del plan, se llevó a cabo un proceso de búsqueda de información, el cual duró en torno a 2 horas y 30 minutos. Después, se redactaron los apartados Introducción y Alcance en 2 horas y 45 minutos. Finalmente, se creó y se redactó la descripción del Diagrama de Gantt en 2 horas y 15 minutos. •El tiempo dedicado al Diseño ha sido 21 horas y 30 minutos. Esta actividad se compone de la creación de los Diagramas entidad-relación anotados y de la realización del documento de Diseño. Se ha tardado en torno a 7 horas y 30 minutos en crear y modificar los DER anotados. Asimismo, la creación del documento de Diseño ha llevado alrededor de 14 horas, ya que se compone de muchos apartados en los cuales se han tenido que describir el modelo físico de datos, las funciones y eventos a utilizar, el diseño de las interfaces de usuario, los casos de uso y las pruebas a realizar, etc. •El tiempo dedicado a la Construcción ha sido alrededor de 132 horas. Esta actividad se compone de la creación del código SQL para generar las tablas de la base de datos del módulo de gestión de proyectos, del código ASL donde se especifican los modelos de la interfaz de usuario de WAINE, de los Manuales de Usuario y de la memoria de construcción. El código SQL se realizó en 24 horas y 50 minutos, ya que se tuvieron que crear todas las tablas, vistas, funciones y triggers necesarios. Además dicho código se tuvo que adaptar varias veces durante el ciclo de vida del proyecto. El código ASL ha sido el que más tiempo ha requerido de todo el trabajo, en torno a 82 horas y 15 minutos, ya que se tuvieron que crear menús, formularios, eventos, botones, contenedores, etc. Además de resolver todos los errores y fallos que iban apareciendo al ir probando la aplicación. La creación de los Manuales de Usuario duró 15h, ya que primeramente se realizó una versión pero después se tuvieron que rehacer debido a modificaciones realizadas en las interfaces de usuario. Los Manuales de Usuario se encuentran disponibles en la wiki de WAINE. Finalmente, la creación de la memoria de construcción duró 11h, a causa del proceso de descripción de cada interfaz de usuario final por cada rol concreto. Formación y Aprendizaje Plan de Proyecto Diseño Construcción 26 horas y 15 minutos 7 horas y 30 minutos 21 horas y 30 minutos 132 horas Como resultado de las actividades anteriores se han generado los siguientes documentos: •Documento de Análisis. •Plan de Trabajo. •Documento de Diseño. •Memoria de Construcción. •Memoria de Implantación. Una vez finalizada la realización del trabajo se puede concluir que el manejo de la aplicación que integra el módulo desarrollado es sencillo, ágil e intuitivo para cualquier usuario. Lo cual la convierte en una herramienta óptima para su utilización en la gestión de proyectos. En cuanto al resultado obtenido ha sido satisfactorio, ya que se han superado gratamente las complicaciones que fueron surgiendo durante el desarrollo de este trabajo y se han cumplido los objetivos y requisitos inicialmente marcados. No obstante, es cierto que la duración del proceso de desarrollo no ha sido corto ya que han surgido ciertas dificultades durante el desarrollo de la aplicación. Al ser WAINE un entorno tecnológico creado en el Departamento de Telemática, la documentación existente tanto en Internet como en bibliotecas sobre su uso y empleo fue muy escasa y limitada. La mínima complicación encontrada podía llegar a convertirse en una dificultad seria. Por suerte, mi tutor siempre se mostró colaborativo para resolver cualquier duda surgida no solucionada mediante la ayuda de la documentación. En este trabajo de fin de grado, he aprendido a desarrollar un proyecto de principio a fin, pasando por todas sus fases. He adquirido nuevos conocimientos, o ampliado muchos de ellos sobre XML, SQL, PHP, aplicaciones web y otros conocimientos necesarios que se han requerido durante las distintas fases del proyecto. Además, he podido comprobar de primera mano la importancia de un buen diseño en cualquier proyecto, ya que de no ser así puede llegar a condicionar todo el desarrollo restante del mismo. Por experiencia propia, han sido varios diagramas entidad-relación anotados los que se han tenido que rediseñar una y otra vez hasta llegar al modelo definitivo. También cabe destacar el aprendizaje del entorno WAINE y del paradigma del formulario. Los cuáles no sabía de su existencia y realizar este trabajo me ha servido para aprender a desarrollar rápidamente interfaces de usuario de cualquier complejidad en este entorno y conocer así todas sus ventajas e inconvenientes. Finalmente, se exponen algunas mejoras y líneas de avance que, desde mi punto de vista, podrían ser interesantes: •Incorporar la funcionalidad de creación de diagramas de Gantt en el módulo para poder permitir un mejor seguimiento de los proyectos y sus actividades. •Añadir la opción de notificaciones al usuario mediante correo electrónico para configurar fácilmente el aviso de actividades asignadas, así como cuando cambian de estado o avance. •Incorporación de chats o foros por cada uno de los proyectos para mejorar la comunicación entre los miembros del proyecto.