ServiceNow: gestión de proyectos y recursos a través de ITBM
Abstract
Grado en Ingeniería Informática
Full text
Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención Ingeniería de Software) ServiceNow: gestión de proyectos y recursos a través de ITBM Autor: D. Alejandro Muñoz García Tutora: Dª M. Mercedes Martínez González
Resumen Se ha realizado un desarrollo mediante la herramienta de ServiceNow la cual es una Plataforma como Servicio (PaaS), una categoría de servicios basados en la nube que provee de la infraestructura necesaria para desarrollar, ejecutar y administrar aplicaciones. Esta plataforma nos permite realizar desarrollos para cualquier departamento de una empresa, aunque habitualmente se la incluye como una plataforma de tipo ITSM (Informatic Technology Service Management). En este Trabajo de Fin de Grado se han desarrollado dos aplicaciones que se incluyen dentro de la herramienta para la gestión de la empresa. Por un lado, se ha desarrollado un sistema para crear y gestionar proyectos de la empresa en todas sus etapas, así como demandas, imputaciones de tiempo trabajado y otros recursos propios de la plataforma cuyo objetivo es permitir a la empresa medir la rentabilidad de los proyectos que realiza y poder mejorar la asignación de recursos que realiza en el futuro. Esto permite controlar tanto los proyectos como todas las subtareas asociadas a los mismos, calculando los gastos y las horas empleadas en el mismo, todo ello mediante planes de recursos, Time Cards y la asignación recursos entre los distintos trabajadores. También se pueden asociar pruebas a los proyectos creados. Por otro lado, se ha desarrollado otra parte denominada como Test Management, que permite subir a la aplicación y gestionar los distintos casos de pruebas y Testeos que se llevan a cabo dentro de un proyecto para comprobar que las implementaciones requeridas por un cliente están incluidas. Se pueden planear los distintos Test que se pretenden realizar agrupándolos en conjuntos, y en cada Test se registran tanto los tiempos de ejecución como los resultados de todos los pasos que se realizan para completar el Test. Ofrece un sistema intuitivo y flexible que permite adaptar los Testeos que se realizan con un sistema de versiones en caso de que el proyecto vaya evolucionando.
Índice General Resumen.................................................................................................................................................... 2 Índice General ........................................................................................................................................... 3 Indice de Figuras ....................................................................................................................................... 6 Índice de Tablas ......................................................................................................................................... 9 1 Introducción ..................................................................................................................................... 13 Motivación ................................................................................................................................ 13 Objetivos................................................................................................................................... 13 Contexto ................................................................................................................................... 14 Procedimiento .......................................................................................................................... 15 Tecnologías utilizadas ............................................................................................................... 15 Estructura del documento ........................................................................................................ 15 2 Metodología de trabajo ................................................................................................................... 18 Scrum ........................................................................................................................................ 18 Comunicado de requisitos iniciales .......................................................................................... 19 Desarrollos de requisitos de cliente ......................................................................................... 19 Desarrollos de elementos técnicos .......................................................................................... 23 Roles ......................................................................................................................................... 23 Desarrollo de historias de usuario ........................................................................................... 23 Casos de uso ............................................................................................................................. 31 Implementación de los elementos definidos ........................................................................... 50 Diagramas de flujo .................................................................................................................... 51 Retrospectiva ............................................................................................................................ 56 Despliegue y mantenimiento del desarrollo ............................................................................ 56 Línea temporal de trabajo ........................................................................................................ 56 3 ¿Por qué se necesitan estos desarrollos? ........................................................................................ 59 Desarrollo Gestión de Proyectos .............................................................................................. 59 Desarrollo Test Management ................................................................................................... 60 4 Elaboración de los ciclos de vida de las entidades del proceso ...................................................... 63 Ciclos de vida de Gestión de Proyectos .................................................................................... 63 Ciclos de vida de Test Management ........................................................................................ 65 5 Elementos técnicos de la aplicación ................................................................................................ 68 Entidades del proceso de proyecto .......................................................................................... 70 Entidades del proceso de Test Management:.......................................................................... 80 6 Implementación de entidades de funcionalidad ............................................................................. 97
Business Rules: ......................................................................................................................... 97 Client Script .............................................................................................................................. 99 Script Includes ........................................................................................................................ 100 7 Plan de pruebas ............................................................................................................................. 103 Plan de Prueba Gestión de Proyectos .................................................................................... 103 Mejoras para Gestión de Proyectos ....................................................................................... 116 Datos de Prueba Test Management ...................................................................................... 117 Mejoras para Test Management ........................................................................................... 128 8 Conclusiones .................................................................................................................................. 131 9 Bibliografía ..................................................................................................................................... 133 10 Anexos........................................................................................................................................ 136 Anexos Gestión de proyectos ................................................................................................ 136 Anexos Test Management ..................................................................................................... 149
Indice de Figuras Figura 2.1.1 Metodología Scrum ............................................................................................................ 18 Figura 2.12.1 Diagrama de tiempo del desarrollo .................................................................................. 57 Figura 4.1.1 Ciclo de Vida Time Card ...................................................................................................... 64 Figura 4.1.2 Ciclo de Vida Plan de Recursos ........................................................................................... 64 Figura 4.2.1 Ciclo de Vida de Versión de Test ........................................................................................ 65 Figura 5.1.1 Diagrama de clases de Gestión de proyectos ..................................................................... 71 Figura 10.1.1 Menu SilverStorm Implementation ................................................................................ 143 Figura 10.1.2 Menu Project y Project Task ........................................................................................... 143 Figura 10.1.3 Tabla de proyectos.......................................................................................................... 144 Figura 10.1.4 Campos Coste y Esfuerzo de Proyecto ........................................................................... 144 Figura 10.1.5 Pestaña Cost Price en Proyecto ...................................................................................... 144 Figura 10.1.6 Formulario Tarea de proyecto ........................................................................................ 144 Figura 10.1.7 Costes por Rol de Tarea de Proyecto.............................................................................. 145 Figura 10.1.8 Esfuerzo por Rol de Tareas de Proyecto ......................................................................... 145 Figura 10.1.9 Related list de Time Card en Tareas de Proyecto ........................................................... 145 Figura 10.1.10 Related list de Planes de Prueba en Tareas de Proyecto ............................................. 145 Figura 10.1.11 Formulario de creación de Plan de Recursos ............................................................... 146 Figura 10.1.12 Formulario de Plan de Recursos creado desde Demanda ............................................ 146 Figura 10.1.13 Formulario de Plan de Recursos ................................................................................... 146 Figura 10.1.14 Related list de Asignación de Recursos en Plan de Recursos ....................................... 146 Figura 10.1.15 Formulario de Asignación de Recursos ........................................................................ 147 Figura 10.1.16 Formulario de Time Card .............................................................................................. 147 Figura 10.1.17 Lista de Hojas de Tarifa de Gasto ................................................................................. 147 Figura 10.1.18 Formulario de Hoja de Tarifa de Gasto ........................................................................ 148 Figura 10.1.19 Lista de Recursos de Rol ............................................................................................... 148 Figura 10.2.1 Menú Test Management 2.0 ......................................................................................... 158 Figura 10.2.2 Dashboard Test Management pestaña 1 ....................................................................... 158 Figura 10.2.3 Dashboard Test Management pestaña 2 ....................................................................... 159 Figura 10.2.4 Dashboard Test Management pestaña 3 ....................................................................... 159 Figura 10.2.5 Lista de Conjunto de Test ............................................................................................... 159 Figura 10.2.6 Formulario Conjunto de Test y Related list a Test .......................................................... 160 Figura 10.2.7 UI Page Add Test to Test Set ........................................................................................... 160 Figura 10.2.8 UI Page Update Test Code con mensaje de error........................................................... 160 Figura 10.2.9 Lista de Test .................................................................................................................... 160 Figura 10.2.10 Formulario de Test con related list Versiones de Test ................................................ 161 Figura 10.2.11 Formulario de Version de Test y related list Paso ........................................................ 161 Figura 10.2.12 Formulario de Paso ....................................................................................................... 161 Figura 10.2.13 Formulario Resultado de Test ....................................................................................... 162 Figura 10.2.14 Formulario Test Run con related list Resultados de Test ............................................. 162 Figura 10.2.15 Formulario Plan de Test con related list Ciclo de Test ................................................. 162 Figura 10.2.16 Formulario Ciclo de Test con related list Software de Ejecución de Test .................... 163 Figura 10.2.17 Formulario Software de Ejecución de Test con related list Asignación Ejecución de Test .............................................................................................................................................................. 163
Figura 10.2.18 Tabla Asignación de Ejecución de Test .........................................................................163 Figura 10.2.19 Related list de Software de Ejecución de Test en formulario Story .............................164 Figura 10.2.20 UI Page Run Test ...........................................................................................................164 Figura 10.2.21 Run Test con Paso que necesita verificación en blocked .............................................164 Figura 10.2.22 Database View Test Export ...........................................................................................165 Figura 10.2.23 Database View Test Run Results ...................................................................................165
Índice de Tablas Tabla 2.6.1 Historia de usuario crear proyecto....................................................................................... 23 Tabla 2.6.2 Historia de Usuario crear tarea de proyecto ........................................................................ 23 Tabla 2.6.3 Historia de usuario Crear Hojas de Tarifa de Gasto ............................................................. 24 Tabla 2.6.4 Historia de Usuario Añadir esfuerzo planeado por rol en una tarea de proyecto .............. 24 Tabla 2.6.5 Historia de usuario ver esfuerzo y coste planeado a un proyecto ....................................... 24 Tabla 2.6.6 Historia de usuario Ver esfuerzo y coste actual por rol en el proyecto ............................... 24 Tabla 2.6.7 Historia de usuario Ver esfuerzo y coste actual de un proyecto ......................................... 25 Tabla 2.6.8 Historia de usuario Ver esfuerzo y coste proyectado por rol en una tarea de proyecto .... 25 Tabla 2.6.9 Historia de usuario Ver esfuerzo y coste proyectado de un proyecto................................. 25 Tabla 2.6.10 Historia de usuario Crear una Time Card ........................................................................... 25 Tabla 2.6.11 Historia de usuario Aprobar una Time Card ....................................................................... 25 Tabla 2.6.12 Historia de usuario Rechazar una Time Card ..................................................................... 26 Tabla 2.6.13 Historia de usuario crear un plan de recursos ................................................................... 26 Tabla 2.6.14 Historia de usuario Crear un plan de recursos ................................................................... 26 Tabla 2.6.15 Historia de usuario Crear asignaciones de recursos .......................................................... 26 Tabla 2.6.16 Historia de usuario Cancelar un plan de recursos.............................................................. 26 Tabla 2.6.17 Historia de usuario Completar un plan de recursos .......................................................... 27 Tabla 2.6.18 Historia de usuario Visualizar coste habitual de un proyecto ........................................... 27 Tabla 2.6.19 Historia de Usuario Crear un Conjunto de Test ................................................................. 27 Tabla 2.6.20 Historia de usuario Crear un Test ....................................................................................... 27 Tabla 2.6.21 Historia de Usuario Crear una Versión de Test .................................................................. 27 Tabla 2.6.22 Historia de usuario Crear un Paso ...................................................................................... 28 Tabla 2.6.23 Historia de Usuario Crear un Entorno de Test ................................................................... 28 Tabla 2.6.24 Historia de usuario Asignar Test a los Conjuntos de Test .................................................. 28 Tabla 2.6.25 Historia de usuario Actualizar los códigos de los Test de un conjunto de Test en bloque 28 Tabla 2.6.26 Historia de usuario Actualizar los códigos de los pasos automáticamente ....................... 28 Tabla 2.6.27 Historia de usuario Ejecutar un Test individualmente ....................................................... 28 Tabla 2.6.28 Historia de usuario Pausar la ejecución de un Test ........................................................... 29 Tabla 2.6.29 Historia de usuario Crear un Plan de Test .......................................................................... 29 Tabla 2.6.30 Historia de usuario Crear un Ciclo de Test ......................................................................... 29 Tabla 2.6.31 Historia de usuario Crear un Software de Ejecución de Test ............................................. 29 Tabla 2.6.32 Historia de usuario Asignar un Software de Ejecución de Test a una story ...................... 29 Tabla 2.6.33 Historia de usuario Crear Asignaciones de Ejecución de Test ........................................... 29 Tabla 2.6.34 Historia de usuario Ejecución de Test múltiple .................................................................. 30 Tabla 2.6.35 Historia de usuario Ejecución de Test múltiple .................................................................. 30 Tabla 2.7.1 Caso de uso crear proyecto .................................................................................................. 32 Tabla 2.7.2 Caso de uso crear tarea de proyecto ................................................................................... 32 Tabla 2.7.3 Caso de uso Crear tareas de proyecto simultáneamente .................................................... 33 Tabla 2.7.4 Caso de Uso crear una hoja de tarifa de gasto .................................................................... 33 Tabla 2.7.5 Caso de Uso actualizar los campos planned effort [rol] de una tarea de proyecto ............ 34 Tabla 2.7.6 Caso de Uso crear una Time Card ........................................................................................ 34 Tabla 2.7.7 Caso de uso Aprobación de una Time Card ......................................................................... 35 Tabla 2.7.8 Caso de uso rechazo de una Time Card ............................................................................... 36 Tabla 2.7.9 Caso de uso creación de un Plan de Recursos desde tarea de proyecto ............................. 36
16 • Metodología de trabajo: desarrolla del sistema que se ha seleccionado para el Trabajo de Fin de Grado y como ha ido el proyecto en el tiempo. • Ciclos de vida de las entidades: aparecen los ciclos de vida de los diferentes registros que hay en el proceso. • Elementos técnicos de la aplicación: definición de las distintas entidades desarrolladas, sus contenidos y como se relacionan entre ellas. • Implementación del proyecto en la instancia: como se han creado los campos y otras funcionalidades de la instancia. • Casos de prueba: datos que se han utilizado para realizar las pruebas que se han llevado a cabo en el Trabajo de Fin de Grado. Después se añaden las conclusiones sobre todo el trabajo realizado.
17
18 2 Metodología de trabajo Scrum En este Trabajo de Fin de grado se ha utilizado metodología Scrum. Scrum es un proceso de trabajo basado en entregas parciales y regulares del producto, en el que se priorizan las tareas según el beneficio que aportan al proyecto final, y que se utiliza en proyectos donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales [4]. En scrum se utilizan ciclos temporales cortos y con una duración fija, que suele ser entre 2 y 3 semanas. Por cada iteración se realiza una entrega al cliente que conlleve un incremento del producto final. En este Trabajo de Fin de Grado el ciclo, también conocido como sprint, tendrá una duración de 3 semanas [5]. Los beneficios de haber realizado el proyecto en SCRUM son la gestión de resultados de una forma más tangible, ya que los resultados se han mostrado al cliente periódicamente, flexibilidad y adaptación respecto a las necesidades de clientes, mitigación de los riesgos del cliente, así como una productividad y calidad y mayor facilidad para el entendimiento entre cliente y equipo de desarrollo (en este caso solo un desarrollador). Habitualmente en un método de trabajo SCRUM encontraríamos 3 tipos de roles, el cliente que es la persona o empresa que requiere un nuevo servicio, el scrum master, que es el máximo responsable del proyecto que se realiza, y el desarrollador, que se encarga de implementar los requisitos a través de los documentos técnicos y de las historias de usuario. En el caso de este Trabajo de Fin de Grado, el papel tanto de cliente como de scrum master lo ha realizado la empresa SilverStorm, y el papel de desarrollador lo ha realizado el autor del Trabajo de Fin de Grado. Figura 2.1.1 Metodología Scrum Figura 2.1.1 Metodología Scrum
19 Comunicado de requisitos iniciales Se realizaron dos reuniones iniciales con el objetivo de transmitir los primeros requisitos que se debían comenzar a implementar y que son los primeros sobre los que se realizaría una reunión de revisión. A partir de ese punto se crearían las primeras historias de usuario para trabajar. Desarrollos de requisitos de cliente A medida que se fueron desarrollando las reuniones, se fueran creando más requisitos que fueron reflejados en las distintas historias de usuario que se han ido creando. Podemos dividir los requisitos en dos partes, los que corresponde a la parte de Gestión de Proyectos y los que corresponden a la parte de Test Management. Antes de identificar los requisitos de cada área, se explican unos breves conceptos sobre ambas partes del proyecto. 2.3.1 Requisitos de Gestión de Proyectos Antes de desarrollar los requisitos que tiene la Gestión de Proyectos es importante entender algunos conceptos propios de la empresa con los que se trabajan. En los proyectos con clientes externos trabaja el departamento de Delivery. En este departamento hay 4 tipos de roles que dividen a los trabajadores: DC (Deployment Consultant), SDC (Senior Deployment Consultant), PDM (Program Delivery Manager) y BPC (Business Program Consultant). Personas de estos 4 roles pueden estar asignadas a las distintas Tareas. Los recursos para la Gestión de los Proyectos se generan en los Planes de Recursos, que pueden ser asignados a través de usuarios concretos, de grupos concretos o de roles. Además se pueden asociar a una Demanda o a una Tarea de Proyecto. Además, para trabajar con Tareas de Proyectos y los registros asociados a ellas, es necesario que existan Hojas de Tarifas de Gasto que establezcan el precio de la hora trabajada para esas Tareas. Para el proceso de Gestión de Proyectos, los requisitos se fueron solicitando y transmitiendo al programador en el siguiente orden: • Requisitos iniciales: o REQ001: disponer de distintos campos en los que mostrar cuál es el esfuerzo previsto para una tarea de proyecto para los roles DC, SDC , PDM y BPC. o REQ002: disponer de distintos campos en los que mostrar cuál es el coste previsto para una tarea de proyecto para los roles DC, SDC, PDM y BPC. o REQ003: disponer de distintos campos en los que mostrar cuál es el esfuerzo actual para una tarea de proyecto para los roles DC, SDC, PDM y BPC. o REQ004: disponer de distintos campos en los que mostrar cuál es el coste actual para una tarea de proyecto para los roles DC, SDC, PDM y BPC. o REQ005: cuando la Task asociada a un Plan de Recursos es de tipo Demanda, el campo resource type del plan de recursos debe valer por defecto Role y no poder editarse. o REQ006: cuando la Task asociada a un Plan de Recursos es de tipo Demanda, los valores del campo rol serán QA y PDM. o REQ007: cuando la Task asociada a un Plan de Recursos es de tipo Demanda, el campo members se ocultará. o REQ008: cuando la Task asociada a un Plan de Recursos es de tipo Demanda, aparecerá un campo project task, que podrás asociarse a una Tarea de Proyecto. o REQ009: cuando la Task asociada a un Plan de Recursos es de tipo Demanda, el campo resource rate será obligatorio y no se autocompletará.
20 • Requisitos punto de control 2: o REQ001: cuando la Task asociada a un Plan de recursos es de tipo Demanda, se mostrará la Related list Requested Allocations. o REQ002: cuando se crea un registro Time Card se debe mostrar el campo resource plan que será autocompletado si existe algún plan de recurso con el mismo usuario y Tarea de Proyecto de la Time Card. Además, la fecha de la Time Card debe estar entre las fechas de los campos start date y end date del plan de recursos. o REQ003: desde el formulario de Tarea de Proyecto, se tiene que poder crear un plan de recursos asociado a la misma. • Requisitos punto de control 3: o REQ001: disponer de distintos campos en los que mostrar cuál es la proyección de esfuerzo prevista para una tarea de proyecto como resultado del esfuerzo realizado hasta ahora y el que queda por realizar para los roles DC, SDC, PDM y BPC. o REQ002: disponer de distintos campos en los que mostrar cuál es la proyección de costes prevista para una tarea de proyecto como resultado del coste invertido hasta ahora y el que queda por invertir para los roles DC, SDC, PDM y BPC. o REQ003: para calcular cual es la proyección de esfuerzo de un Proyecto, se deben sumar todas las proyecciones de esfuerzo por rol de las tares de proyecto asociadas. o REQ004: para calcular cual es el esfuerzo previsto realizar en un Proyecto, se deben sumar todas las previsiones de esfuerzo de las tares de proyecto asociadas. o REQ005: para calcular cual es el esfuerzo actualmente realizado en un proyecto, se deben sumar todos los campos de esfuerzo actualmente realizado de las tareas de proyecto asociadas. o REQ006: para calcular cual es el coste previsto realizar en un Proyecto, se deben sumar todos los campos de coste previsto de las tareas de proyecto asociadas. o REQ007: para calcular cual es el coste invertido actualmente en un Proyecto, se deben sumar todos los campos de coste invertido actualmente de las tareas de proyecto asociadas. • Requisitos punto de control 4: o REQ001: cuando un Plan de Recursos se cierra, se deben recalcular cual es la proyección de esfuerzo de una Tarea de Proyecto para los roles DC, SDC, PDM y BPC. o REQ002: cuando un Plan de Recursos se cierra, se deben recalcular cual es la proyección de coste de una tarea de proyecto para los roles DC, SDC, PDM y BPC. • Requisitos del punto de control 5: o REQ001: los campos que contienen el coste previsto de cada tarea de proyecto por rol deben ser no editables. o REQ002: los campos que contienen el coste previsto de cada tarea de proyecto por rol se calculan multiplicando el campo que contiene el esfuerzo previsto para esa tarea de proyecto. o REQ003: al menos un campo que contiene el esfuerzo previsto para cada rol tiene que ser mayor que 0 en cada tarea de proyecto.
21 o REQ004: el campo que contiene el esfuerzo general previsto para una tarea de proyecto debe ser no editable. o REQ005: el campo que contiene el esfuerzo general previsto para una tarea de proyecto se calculara sumando el esfuerzo previsto para cada rol en esa tarea de proyecto. o REQ006: el campo que contiene el coste general previsto para una tarea de proyecto debe ser no editable. o REQ007: el campo que contiene el coste general previsto para una tarea de proyecto se calculara sumando el coste previsto para cada rol en esa tarea de proyecto. o REQ008: el campo que contiene el esfuerzo general actualmente realizado para una tarea de proyecto debe ser no editable. o REQ009: el campo que contiene el esfuerzo general actualmente realizado para una tarea de proyecto se calculara sumando el esfuerzo actualmente realizado para cada rol en esa tarea de proyecto. o REQ010: el campo que contiene el coste general actualmente invertido para una tarea de proyecto debe ser no editable. o REQ011: el campo que contiene el coste general actualmente invertido para una tarea de proyecto se calculara sumando el coste actualmente invertido para cada rol en esa tarea de proyecto. 2.3.2 Requisitos de Test Management Antes de desarrollar los requisitos que tiene Test Management es importante entender algunos conceptos propios de la empresa con los que se trabajan. Test Management es una aplicación que ServiceNow proporciona de caja, y en el Trabajo de Fin de Grado se ha adaptado a las necesidades de SilverStorm. Los Entornos de Test se refieren a las instancias reales que tienen los distintos clientes en ServiceNow. Un Trasnform Map permite importar registros de fuera de la instancia a ella desde distintos formatos como Excel, lo que ahorra trabajo de creación de registros. Las Database Views no son registros ni tablas como tal, sino que asocian registros de varias tablas que tienen algún tipo de relación y los muestran en un mismo formulario. Para el proceso de Test Management, los requisitos se fueron solicitando y transmitiendo al programador en el siguiente orden: • Requisitos iniciales: o REQ001: creación de campos, related list y modificación de formularios y campos que se muestran en las tablas (1ª fase). Las tablas afectadas son Test, Pasos, Versión de Test, y Asignación de Ejecución de Test. o REQ002: modificación de datos del proceso de carga del mapa de transformación SS – Test Importer 2 y creación de campos en tabla auxiliar denominada SS - Test Importer 2. (1ª fase). o REQ003: creación de la Database View Test Step Results. o REQ004: creación del Dashboard Test Management. o REQ005: creación y visualización de módulos y menús Test Dashboard y Test Results. • Requisitos punto de control 2:
22 o REQ001: creación de campos, related list y modificación de formularios y campos que se muestran en las tablas (2ª fase). La tabla afectada es Conjunto de Test. o REQ002: modificación de datos del proceso de carga del mapa de transformación SS – Test Importer 2 y creación de campos en tabla auxiliar denominada SS - Test Importer 2. (2ª fase). o REQ003: posibilidad de exportar los resultados de los Test. • Requisitos punto de control 3: o REQ001: creación de campos, related list y modificación de formularios y campos que se muestran en las tablas (3ª fase). La tabla afectada son Asignación de Ejecución de Test, Software de Ejecución de Test, Test Run, Resultados de Test y Conjunto de Test. o REQ002: modificación de datos del proceso de carga del mapa de transformación SS – Test Importer 2 y creación de campos en tabla auxiliar denominada SS - Test Importer 2. (3ª fase). • Requisitos punto de control 4: o REQ001: creación de campos, related list y modificación de formularios y campos que se muestran en las tablas (4ª fase). Las tablas afectadas son Conjunto de Test y Test Result. • Requisitos punto de control 5: o REQ001: creación de campos, related list y modificación de formularios y campos que se muestran en las tablas (5ª fase). La tabla afectada es Conjunto de Test. o REQ002: modificación de las reglas de negocia que asocian la tabla Conjunto de Test con la tabla Test. o REQ003: modificación de la funcionalidad de la UI (User Interface) Action Create New Version de la tabla Versión de Test. o REQ004: creación de campos, related list y modificación de formularios y campos que se muestran en las tablas (5ª fase). La tabla afectada es Software de Ejecución de Test. o REQ005: modificación de las reglas de negocia que asocian la tabla Software de Ejecución de Test con la tabla Asignación de Ejecución de Test. o REQ006: creación de campos, related list y modificación de formularios y campos que se muestran en las tablas (5ª fase). La tabla afectada es Stories. o REQ007: creación y visualización del módulo Stories Execution Suites. o REQ008: modificación del orden en el que se muestran los Test a realizar en la UI Macro activable con los botones Run. • Requisitos punto de control 6: o REQ001: creación de una UI Action en la tabla Versión de Test que permita devolver un registro al estado Draft. o REQ002: creación de campos, related list y modificación de formularios y campos que se muestran en las tablas (6ª fase). La tabla afectada es Entorno. o REQ003: creación y visualización del módulo Environments. o REQ004: creación de un sistema para autogenerar los valores del campo code de la tabla Test. o REQ005: crear una nueva Database View que relacione un registro Paso con el Resultado de Test y el Test.
23 A medida que se generan los requisitos se buscan las formas más adecuadas de implementar cada uno de ellos. Desarrollos de elementos técnicos Esta fase se realizó teniendo en cuenta todos los requisitos que surgieron a lo largo de los puntos de control de desarrollo. Para poder realizarla el cliente (SilverStorm) proporcionó plantillas de dos estilos. Por un lado, documentos de tipo Word en los que se especificaron los distintos requisitos propios del desarrollo a realizar y por otro lado entidades Stories que especificaron los plazos y el encargado de supervisar esa parte. En esta entidad también especificaron tanto la descripción técnica de los requisitos como los criterios de aceptación que tenía que cumplir el desarrollo. Roles En este proyecto se trabaja con distintos roles. Para la parte de Gestión de Proyectos tenemos el rol admin, que pueden realizar todas las acciones que conlleva la aplicación. Además, existe el usuario sin roles, que puede solo crear las Time Cards que luego el admin aprobará o rechazará. En la parte de Test Managemnet, nos encontramos con el rol test manager, que puede realizar todas las acciones que se aplican en esta parte de la aplicación Desarrollo de historias de usuario Tras conocer los requisitos y desarrollar los elementos técnicos, se comenzó con los desarrollos de historias de usuario. Primero empezó el desarrollo de Test Management, iniciando la customización de las entidades que ofrece ServiceNow para adaptarlas a las necesidades del cliente. Más tarde continuó el desarrollo de Gestión de Proyectos, comenzando con la customización de las tareas de proyecto con los campos de esfuerzo y costes necesarios y más tarde, a medida que el proyecto avanzó, se incluyeron nuevas historias en ambas áreas de trabajo a la vez que las anteriores se iban cerrando o redefiniendo cuando es necesario. 2.6.1 Historias de usuario Gestión de Proyectos Dentro de la gestión de proyectos se han establecido las siguientes historias de usuarios: ID HU01 Historia de Usuario Crear proyecto Descripción Como admin, quiero crear proyectos para gestionar los distintos contratos con los clientes Criterios de aceptación El admin puede crear un proyecto Tabla 2.6.1 Historia de usuario crear proyecto ID HU02 Historia de Usuario Crear tarea de proyecto Descripción Como admin, quiero crear tareas de proyecto para dividir los proyectos en partes más pequeñas Criterios de aceptación El admin puede crear tareas de proyecto desde un proyecto Tabla 2.6.2 Historia de Usuario crear tarea de proyecto
24 ID HU03 Historia de Usuario Crear Hojas de Tarifa de Gasto Descripción Como admin, quiero crear una hoja tarifa de gasto para saber cuánto se cobra a un cliente por cada hora de servicio de un usuario Criterios de aceptación El admin puede crear hojas de tarifas de gasto Tabla 2.6.3 Historia de usuario Crear Hojas de Tarifa de Gasto ID HU04 Historia de Usuario Añadir esfuerzo planeado por rol en una tarea de proyecto Descripción Como admin, quiero añadir el esfuerzo planeado a una tarea de proyecto dependiendo del rol para saber cuanto tiempo está previsto que invierta cada rol en un proyecto Criterios de aceptación El admin puede añadir esfuerzo planeado por rol en una tarea de proyecto. Cuando se añaden esfuerzos planeados en los roles, se calculan los costes planeados por rol en las tareas de proyecto. Cuando se modifican los esfuerzos y los costes planeados por rol, se calcula el esfuerzo planeado y el coste planeado general de la tarea de proyecto Tabla 2.6.4 Historia de Usuario Añadir esfuerzo planeado por rol en una tarea de proyecto ID HU05 Historia de Usuario Ver esfuerzo y coste planeado a un proyecto Descripción Como admin, quiero poder visualizar el esfuerzo y coste planeado en un proyecto para saber cuánto está previsto invertir en total en un proyecto Criterios de aceptación El admin puede ver el esfuerzo y el coste planeado en un proyecto Tabla 2.6.5 Historia de usuario ver esfuerzo y coste planeado a un proyecto ID HU06 Historia de Usuario Ver esfuerzo y coste actual en una tarea de proyecto Descripción Como admin, quiero poder visualizar el esfuerzo y coste actual de una tarea de proyecto para saber cuánto se ha invertido actualmente por rol y en total en una tarea proyecto Criterios de aceptación El admin puede ver el esfuerzo y el coste actual por [rol] en una tarea de proyecto. El admin puede ver el esfuerzo y el coste actual total en una tarea de proyecto. Tabla 2.6.6 Historia de usuario Ver esfuerzo y coste actual por rol en el proyecto
25 ID HU07 Historia de Usuario Ver esfuerzo y coste actual de un proyecto Descripción Como admin, quiero poder visualizar el esfuerzo y coste actual de un proyecto para saber cuánto se ha invertido actualmente en total en un proyecto Criterios de aceptación El admin puede ver el esfuerzo y el coste actual de un proyecto Tabla 2.6.7 Historia de usuario Ver esfuerzo y coste actual de un proyecto ID HU08 Historia de Usuario Ver esfuerzo y coste proyectado por rol en una tarea de proyecto Descripción Como admin, quiero poder visualizar el esfuerzo y coste proyectado de una tarea de proyecto para saber cuánto se tiene previsto invertir teniendo en cuenta lo invertido hasta el momento por rol y en total en una tarea proyecto Criterios de aceptación El admin puede ver el esfuerzo y el coste proyectado por [rol] en una tarea de proyecto. El admin puede ver el esfuerzo y el coste proyectado total en una tarea de proyecto. Tabla 2.6.8 Historia de usuario Ver esfuerzo y coste proyectado por rol en una tarea de proyecto ID HU09 Historia de Usuario Ver esfuerzo y coste proyectado de un proyecto Descripción Como admin, quiero poder visualizar el esfuerzo y coste proyectado de un proyecto para saber cuánto se tiene previsto invertir teniendo en cuenta lo invertido hasta el momento en total en un proyecto Criterios de aceptación El admin puede ver el esfuerzo y el coste proyectado de un proyecto Tabla 2.6.9 Historia de usuario Ver esfuerzo y coste proyectado de un proyecto ID HU10 Historia de Usuario Crear una Time Card Descripción Como usuario, quiero que se puedan crear time cards para saber cuánto tiempo ha trabajado un usuario en una tarea de proyecto Criterios de aceptación El usuario puede crear una Time Card con lo trabajado durante una semana en una tarea de proyecto Tabla 2.6.10 Historia de usuario Crear una Time Card ID HU11 Historia de Usuario Aprobar una Time Card Descripción Como admin, quiero poder aprobar una time card para imputar el tiempo como invertido en la tarea de proyecto asociada Criterios de aceptación El admin puede aprobar time cards El tiempo se suma al esfuerzo y el coste actual de la tarea de proyecto asociada Tabla 2.6.11 Historia de usuario Aprobar una Time Card
32 Figure 2.7.2 Casos de uso usuario CU-01 Crear un proyecto Descripción El sistema debe permitir crear un proyecto Precondición Secuencia normal Paso Acción 1 El actor admin accede a Project->Projects->All 2 El sistema muestra la lista de proyectos 3 El actor admin pulsa New 4 El sistema muestra el formulario de un nuevo proyecto 5 El actor admin rellena los datos obligatorios 6 El actor admin pulsa el botón Save 7 El sistema registra el proyecto Excepciones Paso Acción 1a,3a,5a,6a El actor admin cancela la operación y el caso de uso queda sin efecto 7a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.1 Caso de uso crear proyecto CU-02 Crear una tarea de proyecto Descripción El sistema debe permitir crear una tarea de proyecto Precondición El actor admin está en el formulario de un proyecto activo Secuencia normal Paso Acción 1 El actor admin pulsa el botón Create Test Phase 2 El sistema muestra el formulario de una nueva tarea de proyecto 3 El actor admin rellena los datos obligatorios 4 El actor admin pulsa el botón Save 5 El sistema registra la tarea de proyecto Excepciones Paso Acción 1a,3a,4a El actor admin cancela la operación y el caso de uso queda sin efecto 5a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 3 Tabla 2.7.2 Caso de uso crear tarea de proyecto
33 CU-03 Crear tareas de proyecto simultáneamente Descripción El sistema debe permitir crear tareas de proyecto sin especificar los datos Precondición El actor admin está en el formulario de un proyecto activo Secuencia normal Paso Acción 1 El actor admin pulsa el botón del menú Project Task Creator 2 El sistema muestra la ventana para crear las tareas de proyecto 3 El actor admin introduce el número de tareas de proyecto para crear 4 El actor admin pulsa el botón OK 5 El sistema registra la tareas de proyecto Excepciones Paso Acción 1a,3a,4a El actor admin cancela la operación y el caso de uso queda sin efecto 5a El sistema comprueba que no se ha introducido el número, muestra una alerta de error y vuelve al paso 3 Tabla 2.7.3 Caso de uso Crear tareas de proyecto simultáneamente CU-04 Crear una hoja de tarifa de gasto Descripción El sistema debe permitir crear una hoja de tarifa de gasto Precondición Secuencia normal Paso Acción 1 El actor admin accede a SilverStorm Implementation->Rates- >Task Card Rate 2 El sistema muestra la lista de proyectos 3 El actor admin pulsa New 4 El sistema muestra el formulario de una nueva hoja de tarifa de gasto 5 El actor admin rellena los datos obligatorios 6 El actor admin pulsa el botón Save 7 El sistema registra la hoja de tarifa de gasto Excepciones Paso Acción 1a,3a,5a,6a El actor admin cancela la operación y el caso de uso queda sin efecto 7a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.4 Caso de Uso crear una hoja de tarifa de gasto
34 CU-05 Actualizar campos planned effort [rol] de una tarea de proyecto Descripción El sistema debe permitir actualizar los campos planned effort [rol] de una tarea de proyecto Precondición El actor admin está en el formulario de una tarea de proyecto activa Secuencia normal Paso Acción 1 El actor admin cambia los campos que considera 2 El actor admin pulsa el botón Save 3 El sistema calcula los campos planned cost [rol] de la tarea de proyecto con los datos planned effort [rol] introducidos. 4 El sistema calcula los campos planned effort y planned cost de la tarea de proyecto y actualiza el registro 5 El sistema calcula los campos planned effort, planned cost y planned cost (cost price) del proyecto asociado y actualiza el registro Excepciones Paso Acción 1a,2a El actor admin cancela la operación y el caso de uso queda sin efecto 3a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 1 3b El sistema comprueba que todos los datos de campos Planned Effort [rol] son 0, muestra un mensaje de error y vuelve al paso 1 3c El sistema comprueba que uno o más campos Planned Effort [rol] mayor que 0 no tienen hoja de tarifa de gasto asociada, , muestra un mensaje de error y vuelve al paso 1 Tabla 2.7.5 Caso de Uso actualizar los campos planned effort [rol] de una tarea de proyecto CU-06 Crear una Time Card Descripción El sistema debe permitir crear una time card Precondición El actor usuario está en el formulario de una tarea de proyecto activa Secuencia normal Paso Acción 1 El actor usuario pulsa en la related list Time Card 2 El sistema muestra la lista de Time Cards relacionadas con la tarea de proyecto 3 El actor usuario pulsa el botón New 4 El sistema muestra el formulario de creación de una time card 5 El actor usuario rellena los campos 6 El actor usuario pulsa el botón Save 7 El sistema registra la Time Card Excepciones Paso Acción 1a,3a,5a,6a El actor usuario cancela la operación y el caso de uso queda sin efecto 7a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 7b El sistema comprueba que no existe una hoja de tarifa de gasto asociada al rol y a la tarea de proyecto indicadas, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.6 Caso de Uso crear una Time Card
35 CU-07 Aprobación de una Time Card Descripción El sistema debe permitir aprobar un registro Time Card Precondición El sistema esta en una tarea de proyecto con Time Cards en estado Pending asociadas Secuencia normal Paso Acción 1 El actor admin pulsa en la related list Time Card 2 El sistema muestra la lista de Time Cards relacionadas con la tarea de proyecto 3 El actor admin accede a una Time Card 4 El sistema muestra el formulario de creación de una time card 5 El actor pulsa el botón Approved 6 El sistema cambia el estado de la Time Card a processed y la actualiza 7 El sistema calcula los campos actual effort [rol] y actual cost [rol] de la tarea de proyecto asociada 8 El sistema calcula los campos actual effort y actual cost de la tarea de proyecto asociada 9 El sistema calcula los campos projected effort [rol] y projected cost [rol] de la tarea de proyecto asociada 10 El sistema calcula los campos projected effort y projected cost de la tarea de proyecto asociada y actualiza el registro 11 El sistema calcula los campos actual effort, actual cost, actual cost (cost price), projected effort, projected cost y projected cost (cost price), del proyecto asociado y actualiza el registro Excepciones Paso Acción 1a,3a,5a El actor admin cancela la operación y el caso de uso queda sin efecto 6a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.7 Caso de uso Aprobación de una Time Card
36 CU-08 Rechazo de una Time Card Descripción El sistema debe permitir rechazar un registro Time Card Precondición El sistema está en una tarea de proyecto con Time Cards en estado Pending asociadas Secuencia normal Paso Acción 1 El actor admin pulsa en la related list Time Card 2 El sistema muestra la lista de Time Cards relacionadas con la tarea de proyecto 3 El actor admin accede a una Time Card 4 El sistema muestra el formulario de creación de una time card 5 El actor pulsa el botón Rejected 6 El sistema cambia el estado de la Time Card a reject y la actualiza Excepciones Paso Acción 1a,3a,5a El actor admin cancela la operación y el caso de uso queda sin efecto 6a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.8 Caso de uso rechazo de una Time Card CU-09 Creación de un Plan de Recursos desde tarea de proyecto Descripción El sistema debe permitir crear un registro Plan de Recursos Precondición El actor admin está en el formulario de una tarea de proyecto activa Secuencia normal Paso Acción 1 El actor admin pulsa en la related list Resource Plans 2 El sistema muestra la lista de planes de recursos relacionadas con la tarea de proyecto 3 El actor admin pulsa el botón New 4 El sistema muestra el formulario de creación de un Plan de Recursos con la tarea de proyecto en el campo Task 5 El actor admin completa los campos del formulario del Plan de recursos 6 El actor admin pulsa el botón Save 7 El sistema registra el plan de recursos con state en Planning Excepciones Paso Acción 1a,3a,5a,6a El actor admin cancela la operación y el caso de uso queda sin efecto 7a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 7b El sistema comprueba que no existe una hoja de tarifa de gasto asociada al rol y a la tarea de proyecto indicadas, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.9 Caso de uso creación de un Plan de Recursos desde tarea de proyecto
37 CU-10 Creación de las asignaciones de recursos Descripción El sistema debe permitir crear registros de asignación de recursos para los planes de recursos Precondición El actor admin está en el formulario de una tarea de proyecto con al menos un plan de recursos sin sus asignaciones creadas Secuencia normal Paso Acción 1 El actor admin pulsa en la related list Resource Plans 2 El sistema muestra la lista de planes de recursos relacionadas con la tarea de proyecto 3 El actor admin pulsa en un Plan de Recursos 4 El sistema muestra el formulario de un Plan de Recursos 5 El actor pulsa el botón Create Soft Allocation 6 El sistema crea las Asignaciones de Recursos asociadas al Plan de recursos 7 El sistema suma el esfuerzo y el coste del plan de recursos a los campos projected effort [rol], projected effort, projected cost [rol] y projected cost en la tarea de proyecto asociada 8 El sistema calcula los campos projected effort, projected cost y projected cost (cost price) en el proyecto asociado a la tarea de proyecto Excepciones Paso Acción 1a,3a,5a El actor admin cancela la operación y el caso de uso queda sin efecto 6a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.10 Caso de uso creación de las asignaciones de recursos en un plan de recursos asociado a una tarea de proyecto
38 CU-11 Cancelar un plan de recursos asociado a una tarea de proyecto Descripción El sistema debe permitir cancelar un Plan de Recursos Precondición El Plan de Recursos está en estado Planning. Secuencia normal Paso Acción 1 El actor admin pulsa en la related list Resource Plans 2 El sistema muestra la lista de planes de recursos relacionadas con la tarea de proyecto 3 El actor admin pulsa en un Plan de Recursos 4 El sistema muestra el formulario de un Plan de Recursos 5 El actor pulsa el botón Cancel 6 El sistema cambia el estado del Plan de recursos a Cancelled y actualiza el registro 7 El sistema resta el esfuerzo y el coste del plan de recursos los campos projected effort [rol], projected effort, projected cost [rol] y projected cost en la tarea de proyecto asociada 8 El sistema calcula los campos projected effort, projected cost y projected cost (cost price) en el proyecto asociado a la tarea de proyecto Excepciones Paso Acción 1a,3a,5a El actor admin cancela la operación y el caso de uso queda sin efecto 6a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.11 Caso de uso cancelar un plan de recursos asociado a una tarea de proyectos CU-12 Completar un plan de recursos asociado a una tarea de proyectos Descripción El sistema debe permitir cancelar un Plan de Recursos Precondición El Plan de Recursos está en estado Allocated. Secuencia normal Paso Acción 1 El actor admin pulsa en la related list Resource Plans 2 El sistema muestra la lista de planes de recursos relacionadas con la tarea de proyecto 3 El actor admin pulsa en un Plan de Recursos 4 El sistema muestra el formulario de un Plan de Recursos 5 El actor pulsa el botón Complete 6 El sistema cambia el estado del Plan de recursos a Completed y actualiza el registro 7 El sistema resta el esfuerzo y el coste del plan de recursos los campos projected effort [rol], projected effort, projected cost [rol] y projected cost en la tarea de proyecto asociada 8 El sistema calcula los campos projected effort, projected cost y projected cost (cost price) en el proyecto asociado a la tarea de proyecto Excepciones Paso Acción 1a,3a,5a El actor admin cancela la operación y el caso de uso queda sin efecto 6a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.12 Caso de uso completar un plan de recursos asociado a una tarea de proyectos
39 CU-13 Creación de un Plan de Recursos desde demanda Descripción El sistema debe permitir crear un registro Demanda Precondición El actor admin está en el formulario de una demanda de tipo project Secuencia normal Paso Acción 1 El actor admin pulsa en la related list Resource Plans 2 El sistema muestra la lista de planes de recursos relacionadas con la tarea de proyecto 3 El actor admin pulsa el botón New 4 El sistema muestra el formulario de creación de un Plan de Recursos con la demand en el campo Task, el campo resource type con valor Role Resource y las opciones del campo project task: 01-Initiate, 02-Prepare, 03-Create, 04-Transition, 05Closed, 06-Management 5 El actor admin completa los campos del formulario del Plan de recursos 6 El actor admin pulsa el botón Save 7 El sistema registra el plan de recursos con state en Planning Excepciones Paso Acción 1a,3a,5a,6a El actor admin cancela la operación y el caso de uso queda sin efecto 7a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.13 Caso de uso creación de un Plan de Recursos desde demanda
40 CU-14 Creación de un Plan de Recursos desde demanda Descripción El sistema debe permitir crear un registro Demanda Precondición El actor admin está en el formulario de una demanda de tipo service improvement Secuencia normal Paso Acción 1 El actor admin pulsa en la related list Resource Plans 2 El sistema muestra la lista de planes de recursos relacionadas con la tarea de proyecto 3 El actor admin pulsa el botón New 4 El sistema muestra el formulario de creación de un Plan de Recursos con la demand en el campo Task, el campo resource type con valor Role Resource y las opciones del campo project task: 00-SERVICE TRANSITION, 01-ADVANCE PLATFORM SUPPORT, 02-BASIC CONFIGURATION SUPPORT, 03ENHANCEMENT SERVICES, 04-ARQUITECTURAL SERVICES, 05 - UPGRADE, 06 – MANAGEMENT 5 El actor admin completa los campos del formulario del Plan de recursos 6 El actor admin pulsa el botón Save 7 El sistema registra el plan de recursos con state en Planning Excepciones Paso Acción 1a,3a,5a,6a El actor admin cancela la operación y el caso de uso queda sin efecto 7a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.14 Caso de uso Creación de un Plan de Recursos desde demanda
41 2.7.2 Casos de uso Test Management Figure 2.7.3 Casos de uso Test Manager Parte 1 Figure 2.7.4 Casos de uso Test Manager Parte 2
48 CU-12 Asignar Tests a un Software de ejecución de Test Descripción El sistema debe permitir asignar tests a un software de ejecución de test Precondición Secuencia normal Paso Acción 1 El actor test manager accede a Test Management 2.0 -> Test Execution Suite 2 El sistema muestra la lista de software de ejecución de test 3 El actor test manager pulsa en un software de ejecución de test 4 El sistema muestra el formulario del software de ejecución de test 5 El actor test pulsa el botón Add Test 6 El sistema muestra el listado de Test y el botón Add To Execution Suite 7 El actor test manager selecciona los tests que quiere añadir al software de ejecución de test 8 El actor test manager pulsa el botón Add To Execution Suite 9 El sistema añade un registro asignación de ejecución de test por cada test asignado, relacionando cada test con el software de ejecución de test Excepciones Paso Acción 1a,3a,5a,7a,8a El actor test manager cancela la operación y el caso de uso queda sin efecto 9a El sistema comprueba que no se ha seleccionado ningún test, muestra un mensaje de error y vuelve al paso 7 Tabla 2.7.26 Caso de uso Asignar Tests a un Software de ejecución de Test
49 CU-13 Ejecutar tests de manera simultanea Descripción El sistema permite ejecutar test de forma simultánea Precondición El actor test manager tiene software de ejecución de test asignados así mismo que están activos Secuencia normal Paso Acción 1 El actor test manager accede a Test Management 2.0 -> Test Assigned To Me 2 El sistema muestra la lista de asignaciones de ejecución de test agrupadas según el software de ejecución de test al que están asignadas 3 El actor test manager selecciona los test que quiere ejecutar 4 El actor test manager pulsa el botón Run 5 El sistema carga la ventana de ejecución de Test 6 El actor test manager rellena los datos para comenzar 7 El actor test manager pulsa Run 8 El sistema carga la ventana con los pasos del primer Test 9 El actor test manager completa los pasos que necesitan verificación de todos los test 10 El actor test manager pulsa el botón done 11 El sistema crea un registro Test Run general y un registro resultado de test por cada test seleccionado con el resultado del testeo Excepciones Paso Acción 1a,3a,4a,6a,9a,10a El actor test manager cancela la operación y el caso de uso queda sin efecto 10b El actor test manager pulsa el botón Pause y el caso de uso queda en pausa Tabla 2.7.27 Caso de uso Ejecutar test de manera simultanea CU-14 Continuar ejecutando un test pausado Descripción El sistema permite continuar ejecutando un test pausado Precondición El actor test manager ha pausado algún testeo previamente Secuencia normal Paso Acción 1 El actor test manager accede a Test Management 2.0 -> Runs 2 El sistema muestra la lista de Test Run ejecutados por el actor test manager 3 El actor test manager pulsa en un Test Run en estado In progress 4 El sistema muestra el formulario del Test Run 5 El actor test manager pulsa el botón Continue Run 6 El sistema carga la ventana de ejecución de test en el mismo estado en el que se pauso Excepciones Paso Acción 1a,3a,5a El actor test manager cancela la operación y el caso de uso queda sin efecto Tabla 2.7.28 Caso de uso Continuar ejecutando un test pausado
50 CU-15 Crear Entorno de Test Descripción El sistema permite crear un Entorno de Test Precondición Secuencia normal Paso Acción 1 El actor test manager accede a Test Management 2.0 -> Environment 2 El sistema muestra la lista de Entornos de Test 3 El actor test manager pulsa New 4 El sistema muestra el formulario de un nuevo entorno de test 5 El actor test manager rellena los datos obligatorios 6 El actor test manager pulsa el botón Save 7 El sistema registra el entorno de test Excepciones Paso Acción 1a,3a,5a,6a El actor test manager cancela la operación y el caso de uso queda sin efecto 7a El sistema comprueba que hay datos obligatorios sin rellenar, muestra un mensaje de error y vuelve al paso 5 Tabla 2.7.29 Caso de uso Crear Entorno de Test Implementación de los elementos definidos Una vez se crearon las historias de usuario de un sprint, comenzó el desarrollo de estas. Durante esta parte el desarrollador se comunicó con el Scrum Master (en este caso el mismo que el cliente final) para resolver las dudas que surgieron, además de proponerle mejoras para que se cumplieran los distintos requisitos.
51 Diagramas de flujo Para las aplicaciones se han desarrollado algunos diagramas de flujo que clarificaran más el funcionamiento de algunas partes de la story. 2.9.1 Diagramas de flujo Gestión de proyectos • Actualización tarea de proyecto Figure 2.9.1 Actualización tarea de proyecto parte 1
52 Figure 2.9.2 Actualización tarea de proyecto parte 2 • Aprobar Time Card Figure 2.9.3 Aprobar Time Card • Actualizar proyecto tras la actualización de una de sus tareas de proyecto Figure 2.9.4 Actualizar proyecto tras la actualización de las tareas de proyecto
53 • Crear asignaciones de recursos: Figure 2.9.5 Crear asignaciones de recursos. • Actualizar estado de un plan de recursos: Figure 2.9.6 Actualizar estado de un plan de recursos parte 1
54 Figure 2.9.7 Actualizar estado de un plan de recursos parte 2 2.9.2 Diagramas de flujo Test Management • Actualización de códigos de Test Figure 2.9.8 Actualización de códigos de Test
55 • Añadir Test a conjunto de Test Figure 2.9.9 Añadir Test a conjunto de Test • Preparación y ejecución de un Test (desde una Versión de Test ya creada: Figure 2.9.10 Preparar ejecución de Test
56 Figure 2.9.11 Ejecución de Test Retrospectiva Tras la realización de la implementación se realizaron reuniones de retrospectiva. En estas reuniones se mostró el trabajo realizado hasta el momento, y se evaluó la evolución de este, a la vez que se marcaron las pautas para el siguiente ciclo del proceso. Se fueron añadiendo requisitos cuando era necesario y se decidió que historias de usuario debidamente creadas se incluían en el siguiente sprint. Despliegue y mantenimiento del desarrollo Tras la finalización del proyecto, SilverStorm, como cliente, decidió si mover todo lo desarrollado a su instancia de producción, en la que los trabajadores tienen todas las funcionalidades desarrolladas disponibles para su uso diario. Desde allí pueden reportar defectos o fallos del sistema, que, de confirmarse, serán solucionados en la instancia de desarrollo, y si se confirma que la solución es correcta, subir está a la instancia de producción. El despliegue no tiene por qué hacerse solo al final, sino que puede irse desplegando por partes a medida que van finalizando los sprints. Línea temporal de trabajo Durante el desarrollo del Trabajo de Fin de Grado se han realizado diversas reuniones y eventos que han ido marcando el avance de esta a lo largo de los meses que ha durado el desarrollo del Trabajo de Fin de Grado. Esos eventos son los siguientes: • Reunión inicial de contacto: fue la primera reunión realizada con el cliente para tener una primera toma de contacto sobre los objetivos generales del Trabajo de Fin de Grado. • Reunión inicial de requisitos: reunión con las diferentes partes de los responsables tanto de Test Management como de Gestión de Proyectos para fijar los requisitos iniciales del mismo. • Reunión revisión documento de diseño inicial: se presentaron los primeros documentos de diseño con las distintas entidades, menús, dashboards y demás requerimientos para implementar. • Reunión historias de usuario iniciales: se presentaron las historias de usuario que entraban en el desarrollo del primer sprint.
57 • Reuniones retrospectivas: se realizaron periódicamente para mostrar los avances realizados y determinar los requisitos e historias de usuario asignadas al siguiente sprint. También se han propuesto mejoras para el proyecto. • Presentación demo final: demostración realizada ante el cliente de la herramienta solicitada con todos los requisitos implementados. Además de todas estas reuniones se han hecho otras reuniones más a demanda del desarrollador de cara a consultar dudas que han ido surgiendo en el desarrollo de historias de usuario concretas, de cara a agilizar el desarrollo y que esta finalizara de la mejor manera posible. Figura 2.12.1 Diagrama de tiempo del desarrollo
64 • Rejected: la Time Card queda rechazada. • Processed: la Time Card se ha procesado y sus horas se han añadido a la Tarea de Proyecto correspondiente. El ciclo de vida de la Time Card es el siguiente: Figura 4.1.1 Ciclo de Vida Time Card 4.1.4 Ciclo de Vida Plan de Recursos Para la entidad Plan de Recursos, un registro puede tener los siguientes estados: • Planning: el Plan de Recursos está en proceso de planificación. • Requested: se solicita a los encargados que se apruebe el Plan de Recurso. • Allocated: los recursos solicitados por el proceso están asignados. • Completed: el Plan de Recursos ha finalizado. • Cancelled: se cancela el plan de recursos. El ciclo de vida de la Plan de Recursos es el siguiente: Figura 4.1.2 Ciclo de Vida Plan de Recursos
65 Ciclos de vida de Test Management 4.2.1 Ciclo de vida Versión de Test Para la entidad Versión de Test, un registro puede estar en los estados: • Draft: el registro todavía está en preparación. • Ready: se están realizando Testeos basados en ese registro. • Retired: el registro está ya retirado. El ciclo de vida de la Versión de Test es el siguiente: Figura 4.2.1 Ciclo de Vida de Versión de Test Para la entidad Test Run, un registro puede estar en los estados: • In Progress: el Test Run está en proceso. • Closed: el Test Run está terminado. 4.2.2 Ciclo de vida de Plan de Test Para la entidad Plan de Test, un registro puede estar en los estados: • Pending: estado inicial del Plan de Test, indica que está pendiente de aprobación. • Open: estado cuando un Plan de Test está aprobado, pero no ha empezado su desarrollo. • Work In Progress: un Plan de Test se está desarrollando. • Closed Complete: el Plan de Test ha terminado definitivamente. • Closed Incomplete: el Plan de Test ha terminado, pero han quedado cosas por hacer. • Closed Skipped: el Plan de Test ha terminado antes de tiempo. En esta entidad se puede pasar de cualquier estado a cualquier otro, por lo que no se puede definir un ciclo de vida como tal. 4.2.3 Ciclo de Vida de Ciclo de Test Para la entidad Ciclo de Test, un registro puede estar en los estados: • Pending: estado inicial del Ciclo de Test, indica que está pendiente de aprobación. • Open: estado cuando un Ciclo de Test está aprobado, pero no ha empezado su desarrollo. • Work In Progress: un Ciclo de Test se está desarrollando. • Closed Complete: el Ciclo de Test ha terminado definitivamente. • Closed Incomplete: el Ciclo de Test ha terminado, pero han quedado cosas por hacer. • Closed Skipped: el Ciclo de Test ha terminado antes de tiempo. En esta entidad se puede pasar de cualquier estado a cualquier otro, por lo que no se puede definir un ciclo de vida como tal.
66 4.2.4 Ciclo de Vida de Software de Ejecución de Test Para la entidad Proyecto, un registro puede estar en los estados: • Draft: estado inicial del Software de Ejecución de Test, indica que está a la espera de planearse. • Planning: estado cuando un Software de Ejecución de Test está planeándose. • Current: un Software de Ejecución de Test se está desarrollando. • Complete: el Software de Ejecución de Test ha terminado definitivamente. • Cancelled: el Software de Ejecución de Test se ha cancelado. En esta entidad se puede pasar de cualquier estado a cualquier otro, por lo que no se puede definir un ciclo de vida como tal.
67
68 5 Elementos técnicos de la aplicación Dentro de la herramienta se utilizan distintos elementos técnicos que proporcionan la funcionalidad necesaria para poder implementar tanto los requisitos y objetivos de este trabajo de fin de grado como los necesarios para cualquier otro fin. Las distintas entidades con las que hemos contado para ello son: • Campos: contienen los datos concretos que forman una entidad. Cada tabla o entidad tiene muchos de ellos. ServiceNow ofrece campos de muchos tipos. Para este trabajo estos son los tipos que han tenido relevancia [6]. Tipo Contenido String Código alfanumérico Choice Selección de una opción entre distintas mostradas Reference Referencia a un registro, de otra tabla o de la misma Currency Valor monetario Integer Numero entero Decimal Numero decimal Percent Complete Porcentaje Date Fecha Datetime Fecha y hora Duration Registro que marca la duración, en distintos formatos de tiempo List Lista de registros asociados Checkbox Campo booleano URL URL True/false Campo booleano Tabla 4.2.1 Tipos de Campo Cada uno de los campos tiene asociados unas reglas de obligatoriedad (mandatory), editabilidad (read only) y visibilidad (visibility). Los campos se crean asociados a unas tablas. Para acceder a las distintas tablas y crear los campos debemos usar el buscador del menú y buscar el módulo System Definition > Tables. En el podremos encontrar cualquier tabla que necesitemos configurar a través del Label. Tras configurar los campos de la tabla, creamos el formulario con los campos necesarios que queramos mostrar, usando para ello la Related Link denominada Form Layout [7]. Para configurar las Related list, que son las listas de objetos relacionadas, se hace a través del botón related list [8]. La vista de los campos de un registro en la lista de registros de una tabla se configura a través del botón Layout List.
69 Para una misma entidad se pueden crear distintas vistas tanto para mostrar los campos en el formulario como para mostrar los campos en la lista. En el Trabajo de Fin de Grado se trabajará principalmente con las Default View. Algunas entidades pueden tener otras vistas cuando se crean los registros o según los roles que tenga el usuario. • UI Action: son acciones que se llevan a cabo como respuesta a la acción de pulsar un botón en un formulario o una lista. Las UI Actions [8] pueden ser de distintos tipos y una misma UI Action puede ser de varios tipos a la vez. Los tipos son los siguientes: Tipo Descripción Form button Botón que aparece en el formulario Form Context Menu Opción que aparece en el menú desplegable de un formulario Form Link Botón que se muestra como un enlace en la parte de abajo del formulario List banner button Botón que aparece en el banner de la lista de registros de una tabla List bottom button Botón que aparece en la parte de debajo de la tabla que se muestra. List context menú Opción que aparece al seleccionar un registro de la tabla con el botón derecho List choice Opción que aparece en el menú desplegable situado debajo de una tabla. Tabla 4.2.2 Tipos de UI Action Hay una serie de UI Actions que son en general comunes a todas las tablas de registros y que se utilizan en este proyecto: o Submit: UI Action de tipo form button que inserta un registro en el sistema y vuelve a la página cargada anteriormente. o Update: UI Action de tipo form button que actualiza un registro en el sistema y vuelve a la página cargada anteriormente. o Delete: UI Action de tipo form button que elimina un registro del sistema y vuelve a la página cargada anteriormente. o Cancel: UI Action de tipo form button que cancela el proceso del registro en el que se activa. o Save: UI Action de tipo form context menú que inserta o actualiza un registro del sistema y se mantiene en el registro.
70 o Insert: UI Action de tipo form context menú que inserta un registro en el sistema copiando los datos de un registro ya existente. Tras realizar la acción, la página se mantiene en el registro inicial. o Insert and Stay: UI Action de tipo form context menú que inserta un registro en el sistema copiando los datos de un registro ya existente. Tras realizar la acción, la página carga el nuevo registro. o New: UI Action de tipo list banner button que accede al formulario de creación de un registro de la lista en la que estaba el botón, para que se pueda rellenar. • Business Rule: acciones que se producen en el servidor tras realizar una acción de inserción, actualización o borrado del registro de una tabla. • Client Scripts: acciones que se ejecutan en el cliente cuando se produce una acción de carga, cambio de algún campo o actualización de un registro de una tabla. • Script Include: registro que contiene distintas funciones y métodos que se ejecutan al ser llamadas desde otro. • UI Policy: registro de tipo cliente en el que se crean unas condiciones por las que se modifican las reglas asociadas a algún campo. • UI Formatter: es un elemento usado para mostrar información que no se encuentra en la propia entidad, y que se muestra a través del formulario. • UI Page: es un elemento que se usa para añadir una interfaz de usuario al formulario de una entidad. Contiene tres scripts para rellenar, el primero el HTML, en el que se programan en HTML los componentes de la interfaz, el Client Script, en el que se desarrolla en JavaScript los componentes de cliente y por último el Processing Script, donde se desarrollan, también en JavaScript, los componentes dedicados a servidor. • Menús y Módulos: estos permiten visualizar los distintos elementos y entidades que encontramos en la herramienta, concediéndonos el acceso a las mismas. El menú que nos ofrece esto se llama Application Navigator, y nos permite buscar por nombre los módulos a los que queremos acceder. También nos permite guardar favoritos y acceder a el historial de búsquedas y accesos que hemos realizado. Además, cuando accedemos a una lista o registro, el resto del contenido se divide en dos partes, una el Banner Frame, donde se muestran distintas opciones para que el usuario modifique los datos que se muestran (vistas, filtros) así como distintas UI Actions, y la otra el Content Frame, que muestra los datos requeridos. Entidades del proceso de proyecto En este apartado se explica el funcionamiento de cada entidad relacionada con el proceso de proyecto, centrándonos en los campos de relevancia de cara al Trabajo de Fin de Grado que tienen influencia en el mismo. Para entender este proceso, resaltar antes la tabla User (sys_user) es la tabla que proporciona ServiceNow en la que se muestran los distintos usuarios disponibles, los cuales son transversales a toda la herramienta. En dicha tabla existe el siguiente campo: • Role: rol asociado a la empresa Silverstorm en el que se define la categoría en la que se encuentra el empleado en cuestión. De cara a este proyecto los roles relevantes son los siguientes: Deployment Consultant (DC), Senior Deployment Consultant (SDC), Program Delivery Management (PDM) y Business Process Consultant (BPC).
71 5.1.1 Diagrama de clases A continuación, se muestra el diagrama de clases que relaciona las distintas entidades en las que se basa la aplicación. La entidad inicial es la de Proyecto, cada uno de ellos relacionado con una o más Tareas de Proyecto. Sada tarea de proyecto también se relaciona con uno o más Planes de Recursos. Las Tareas de Proyectos también se relacionan con un número indeterminado de Time Cards, las cuales se relacionan con un solo usuario, y cada usuario se puede asociar a un número indeterminado de Time Cards. Cada Time Card se relaciona también con uno o ningún Plan de Recursos (que se relaciona con un número indeterminado de Time Cards). El Plan de Recursos se relaciona con los usuarios en una relación de varios a varios, al igual que lo hace con las Asignaciones de Recursos, siendo esta relación del tipo uno a varios. Figura 5.1.1 Diagrama de clases de Gestión de proyectos 5.1.2 Entidad Proyecto El proyecto es la entidad en la que se muestran los datos generales sobre la realización de actividades relacionadas y ofrecerá una lista de las tareas de proyecto asociadas. Es una tabla que ServiceNow incluye directamente en sus servicios. Los campos asociados a esta tabla que a su vez tienen relevancia para la funcionalidad implementada son: • Number: Autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • State: de tipo choice que muestra el estado actual en el que encuentra un proyecto. Las opciones son Pending, Open, Work in progress, Closed Completed, Closed Incompleted, Closed Skipped, Closed in Warranty. • Active: de tipo true/false que marca si un proyecto está activo actualmente. • Project name: string que contiene el nombre del proyecto.
72 • Planned Effort: campo de tipo duration que muestra el esfuerzo planeado a realizar por los usuarios en torno a un Proyecto. Es el resultado de la suma de todos los campos Planned Effort de cada tarea de proyecto asociada. • Actual effort: campo de tipo duration que muestra el esfuerzo realizado actualmente para un Proyecto. Es el resultado de la suma de todos los campos actual effort de cada tarea de proyecto asociada. • Projected effort: campo de tipo duration que muestra el esfuerzo previsto a realizar para un Proyecto. Es el resultado de la suma de todos los campos Projected Effort de cada tarea de proyecto asociada. • Actual Cost: campo de tipo currency que muestra la inversión monetaria realizada hasta el momento en un Proyecto. Es la suma de los campos Actual Cost de cada tarea de proyecto asociada. • Projected Cost: campo de tipo currency que muestra la inversión monetaria prevista a realizar en un Proyecto teniendo en cuenta la realizada hasta el momento. Es la suma de los campos Projected Cost de cada tarea de proyecto asociada. • Planned Start Date: campo Datetime. Es la fecha en la que se prevé que empiece el Proyecto. • Planned End Date: campo Datetime. Es la fecha en la que se prevé que termine el Proyecto. • Planned Cost (cost price): campo de tipo currency que muestra la suma de los campos Planned Effort [Rol] de cada Tarea de Proyecto asociada, multiplicando previamente cada una de estas por el precio que se indica en el registro de la entidad Recursos de Rol asociada a cada rol. • Actual Cost (cost price): campo de tipo currency que muestra la suma de los campos Actual Effort [Rol] de cada Tarea de Proyecto asociada, multiplicando previamente cada una de estas por el precio que se indica en el registro de la entidad Recursos de Rol asociada a cada rol. • Projected Cost (cost price): campo de tipo currency que muestra la suma de los campos Projected Effort [Rol] de cada Tarea de Proyecto asociada, multiplicando previamente cada una de estas por el precio que se indica en el registro de la entidad Recursos de Rol asociada a cada rol. Esta tabla contiene una serie de listas relacionadas que muestran las siguientes relaciones: • Tareas de proyectos: relación con las Tareas de Proyecto hijas del Proyecto. • Time Cards: Time Cards asociados a cualquiera de las tareas de Proyecto, con las horas trabajadas en cada una ellas. • Planes de recursos (Tarea de Proyecto): planes de recursos con los recursos previstos a asignar a las Tareas de Proyecto hijas de este Proyecto. Además de las UI Actions nombradas como generales, la entidad proyecto tiene otras relacionadas exclusivamente para su uso: • Project Task Creator: de tipo context menú, permite crear automáticamente el número de tareas de proyecto indicado, que se asociaran al proyecto. • Copy Project: de tipo context menú, permite crear automáticamente una copia del proyecto actual, indicando un nuevo nombre.
73 • Create Test Phase: de tipo form link, permite crear una tarea de proyecto en la que se indican todos los datos referentes a ella. 5.1.3 Entidad Tarea de Proyecto La tarea de proyecto son las subtareas en las que se divide un proyecto y que están asociadas al mismo. Cada tarea está asociado a un solo proyecto, pero cada proyecto puede estar asociado a distintas tareas. Los campos asociados a esta tabla que a su vez tienen relevancia para la funcionalidad son: • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • State: de tipo integer que muestra el estado actual en el que encuentra la tarea de proyecto. Las opciones son Pending, Open, Work in progress, Closed Completed, Closed Incompleted, Closed Skipped, Closed in Warranty. • Short Description: string que contiene una descripción de la Tarea de Proyecto. • Planned Effort DC: campo de tipo duration que muestra el esfuerzo planeado a realizar por personas con el rol DC asociado en una Tarea de Proyecto. • Planned Effort SDC: campo de tipo duration que muestra el esfuerzo planeado a realizar por personas con el rol SDC asociado en una Tarea de Proyecto. • Planned Effort PDM: campo de tipo duration que muestra el esfuerzo planeado a realizar por personas con el rol PDM asociado en una Tarea de Proyecto. • Planned Effort BPC: campo de tipo duration que muestra el esfuerzo planeado a realizar por personas con el rol BPC asociado en una Tarea de Proyecto. • Planned Effort: campo de tipo duration que muestra el esfuerzo planeado a realizar por los usuarios en torno a una tarea de proyecto. Es el resultado de la suma de los campos Planned Effort DC, Planned Effort SDC, Planned Effort PDM y Planned Effort BPC de la Tarea de Proyecto. • Actual Effort DC: campo de tipo duration que muestra el esfuerzo realizado actualmente por personas con el rol DC asociado en una tarea de proyecto. Es la suma de las horas totales invertidas de cada Time Card en estado processed con un usuario cuyo rol es DC. • Actual Effort SDC: campo de tipo duration que muestra el esfuerzo realizado actualmente por personas con el rol SDC asociado en una tarea de proyecto. Es la suma de las horas totales invertidas de cada Time Card en estado processed con un usuario cuyo rol es SDC. • Actual Effort PDM: campo de tipo duration que muestra el esfuerzo realizado actualmente por personas con el rol PDM asociado en una tarea de proyecto. Es la suma de las horas totales invertidas de cada Time Card en estado processed con un usuario cuyo rol es PDM. • Actual Effort BPC: campo de tipo duration que muestra el esfuerzo realizado actualmente por personas con el rol BPC asociado en una tarea de proyecto. Es la suma de las horas totales invertidas de cada Time Card en estado processed con un usuario cuyo rol es BPC. • Actual effort: campo de tipo duration que muestra el esfuerzo realizado actualmente para una tarea de proyecto. Es el resultado de la suma de los campos Actual Effort DC, Actual Effort SDC, Actual Effort PDM y Actual Effort BPC de la tarea de proyecto. • Projected Effort DC: campo de tipo duration que muestra el esfuerzo que está previsto realizar por personas con el rol DC en una tarea de proyecto, teniendo en cuenta el realizado hasta el momento. Es la suma del Actual Effort DC y las horas previstas en las Asignaciones de Recursos activas para el rol DC asociados a los planes de recursos asociados a la tarea de
80 5.1.9 Entidad Recursos de Rol Esta entidad indica el coste por hora trabajada asociado a cada rol de forma genérica, sin tener en cuenta el Proyecto concreto en el que se trabaja. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Name: de tipo string, indica el rol al que corresponde el registro. • Hourly Rate: de tipo currency indica el coste por hora trabajada para ese rol. 5.1.10 Menús y Módulos relacionados con Gestión de Proyectos Los menús y módulos por los que se puede acceder a las entidades de Test son los siguientes: Project: • Project: modulo separador que contiene módulos relacionados con Project. o Rolled Up Report: muestre un dashboard que contiene todos los proyectos y en el que se pueden ver distintos campos según esfuerzo requerido, duración, fecha… o Project Workspace: muestra un dashboard que contiene todos los proyectos activos los cuales tienen el campo parent vacío. o Work In Progress: muestra una lista que contiene todos los proyectos activos (el campo active tiene valor true). o All: muestra una lista que contiene todos los proyectos. o Import: permite importar un proyecto desde fuera de la herramienta. • Project Task: modulo separador que contiene módulos relacionados con Project Task. o Work In Progress: muestra una lista que contiene todas las tareas de proyectos activas (el campo active tiene valor true). o All: muestra una lista que contiene todas las tareas de proyectos. SilverStorm Implementations: • Rates: modulo separador que contiene módulos relacionados con Rates. o Task Rate Cards: muestra una lista que contiene todas las Hoja de Tarifas de Tarea. • Resource Management: modulo separador que contiene módulos relacionados con recursos. o Resource Plans: muestra una lista que contiene todos los planes de recursos. Entidades del proceso de Test Management: El proceso de gestión de pruebas es un proceso con el cual se prevé llevar un control de las pruebas que se realizan en los distintos desarrollos que se llevan a cabo en un proceso concreto. Este proceso permite gestionar las pruebas en grupos, guardar resultados y mostrar el progreso general en las distintas pruebas realizadas: 5.2.1 Diagrama de clases En el proceso de gestión de pruebas nos encontramos las entidades que definen los Test a realizar para comprobar que un proceso funciona correctamente. Un Conjunto de Test es una entidad que está formado por un número indeterminado de Test con los que se relaciona mediante la clase asociativa Conjunto de Test. El Test a su vez este compuesto por un número indeterminado de Versiones de Test, cada una con un número de Pasos correspondiente, también indeterminado. Además, cada Versión de Test se relaciona con los Resultados de Test propios de la misma. Cada uno de estos resultados se asocia con un Test Run. Por otro lado, están las entidades que definen los plazos y las duraciones de los distintos Test. En este caso, la entidad Plan de Test nos muestra los datos generales, y se compone
81 de un número indeterminado de ciclos de Test, que a su vez se divide en un número indeterminado de software de ejecución de Test. Ambas partes se relacionan mediante la entidad Asignación de Ejecución de Test, la cual se relaciona con un Test y con un Software de ejecución de Test. Tabla 5.2.1 Diagrama de clases de Test Management 5.2.2 Entidad Conjunto de Test El conjunto de Test es una entidad cuya función es definir los datos generales de un grupo de Test que se tienen unas características en común. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • Company: campo de tipo referencia a la tabla Company, que indica a que compañía están asociados los Test. • Process: campo de tipo choice que indica el proceso de ejecución al que pertenece el Conjunto de Test. • Owner: campo de tipo referencia a la tabla User, que indica que usuario es el responsable del Conjunto de Test • Category: campo de tipo string que indica a que tipo pertenecen los Test. • Name: campo de tipo string que indica el nombre que se le da al conjunto de Test Esta tabla contiene una serie de listas relacionadas que muestran las siguientes relaciones: • Test Set Test: tabla asociativa que relaciona un conjunto de Test con un Test concreto. Además de las UI Actions nombradas como generales, la entidad Conjunto de Test tiene otras relacionadas exclusivamente para su uso: • Add to Execution Suite: de tipo list banner button, solo se muestra cuando se ha accedido a la tabla Test Set desde el botón Add Test Set de un registro software de ejecución de Test. Los
82 Test que forman los Conjuntos de Test seleccionados se añadirán automáticamente al software de ejecución de Test desde el cual se accedió. • Update Code Test: de tipo form button, dispara una interfaz a través de una UI Page para gestionar los campos code de las entidades Test asociadas[10]. La ventana muestra tres campos: o Prefix: muestra el prefijo que tendrá el código que vamos a generar. Es obligatorio. o Number o digits: determina el número de dígitos con el que va a contar el código. Es obligatorio y tiene que ser mayor que 0. o Initial Number: indica el número en el que empezará el código. El campo puede estar vacío o ser un número entero mayor de 0. Si se aceptan los datos, se generan automáticamente todos los Test. 5.2.3 Entidad Conjunto de Test Test Entidad asociativa cuyo único objetivo es relacionar a los conjuntos de Test con los Test concretos. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Test Set: campo de tipo referencia a Test Set, que muestra el conjunto de Test asociado. Un conjunto de Test puede aparecer en cualquier número de registros en esta tabla. • Test: campo de tipo referencia a Test, que muestra el Test asociado. Un Test puede aparecer en tan solo un registro en esta tabla. Además de las UI Actions nombradas como generales, la entidad Conjunto de Test Test tiene otras relacionadas exclusivamente para su uso: • New: de tipo list banner button, este New es distinto del resto, ya que no crea un registro en la tabla de Conjunto de Test Test, sino que nos muestra el formulario de Versión de Test, a través del cual se generaran los registros en ambas tablas y en la tabla Test. Se asocian al Test el Test Set y su company. 5.2.4 Entidad Test La entidad Test muestra una prueba concreta que se realiza dentro un conjunto de Test. Cuando se crea una entidad Test no se crea directamente, sino que se crea una Versión de Test que mapea automáticamente los datos necesarios para generar el Test. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • Company: campo de tipo referencia a la tabla Company, que indica a que compañía están asociados los Test. • Test Set: campo de tipo referencia a la tabla Test Set Test, donde se asocia con el conjunto de Test correspondiente. Solo se puede asociar un Test con un conjunto de Test con el mismo valor para el campo Company. • Code: campo de tipo string que muestra un código asociado al set. • Test Version: campo de tipo referencia a la tabla Test Version, que indica cual es el la última Versión de Test que se ha creado para ese Test. • Runnable Version: campo de tipo referencia a la tabla Test Version, que indica cual es el la Versión de Test que esta activa actualmente para ese Test.
83 • User logged: campo de tipo stringque indica el usuario con el que se ha realizado un Test. • Previous requirements: campo de tipo string que indica los requisitos previos a la realización de una prueba. • Short Descriptión: campo de tipo string que proporciona un breve resumen sobre el Test. • Description: campo de tipo string que proporciona un resumen sobre el Test. Esta tabla contiene una serie de listas relacionadas que muestran las siguientes relaciones: • Version Test: versiones asociadas al mismo Test en las que se pueden ejecutar las pruebas. Además de las UI Actions nombradas como generales, la entidad Test tiene otras relacionadas exclusivamente para su uso: • Add to Test Set: de tipo list banner button, abre una UI page en la que se muestra un solo campo, Test Set, que hace referencia a dicha tabla. El Test Set seleccionado se mapea con el campo Test Set de los registros Test que se habían seleccionado, y crea en la tabla Test Set Test el registro que asocia ambos[11]. • Add to Execution Suite: de tipo list banner button, solo se muestra cuando se ha accedido a la tabla Test desde el botón Add Test de un registro software de ejecución de Test. Los Test seleccionados se añadirán automáticamente al software de ejecución de Test desde el cual se accedió. • New: de tipo list banner button, este button New es distinto del resto, ya que no crea un registro en la tabla Test, sino que nos muestra el formulario de Versión de Test, a través del cual se generaran los registros. Esta entidad tiene deshabilitados las UI Action Insert y Insert and Stay. 5.2.5 Entidad Versión de Test La entidad Versión de Test es una variante de un Test concreto, que se puede ejecutar para ver el resultado de las pruebas. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Test: campo de tipo referencia a la tabla Test, que muestra el Test al que pertenece la versión. • Owner: campo de tipo referencia a la tabla User, que muestra el usuario al que pertenece la versión del Test. • State: campo de tipo string que muestra el estado en el que se encuentra la Version de Test. Las opciones son Draft, Ready o Retired. • Version: campo de tipo integer que muestra el número de versión con respecto al Test al que está asociada. • Short Description: campo de tipo string que proporciona un breve resumen sobre la versión de Test. Además, la tabla contiene varios campos gemelos de los campos de Test cuyo objetivo es mapear datos de un registro a otro. Esta tabla contiene una serie de listas relacionadas que muestran las siguientes relaciones: • Other Version: muestra el resto de las versiones que están asociadas al mismo Test que la versión actual. • Steps: muestra los pasos a realizar para cumplimentar el Test asociado. • Test Results: resultado de los Test realizados para la versión de Test.
84 Por otro lado, en esta tabla se muestra un UI Formatter, denominado Test Version Steps, el cual muestra a través de una UI Macro del mismo nombre los Steps relacionados con la versión de Test, y permite declarar cuales de ellos necesitan verificación. Solo se pueden añadir nuevos pasos a la versión de Test cuando esta se encuentra en estado Draft. Además de las UI Actions nombradas como generales, la entidad Versión de Test tiene otras relacionadas exclusivamente para su uso: • Run: de tipo form button, abre una ventana emergente en la que se permite guardar los datos de todos los pasos que se realizan en un Test, y guarda el resultado creando un registro Test Result asociado. • Ready: de tipo form button, cambia el estado Draft de una versión de Test al estado Ready. En el momento que una versión de Test pasa a Ready, cualquier versión anterior del Test que estuviera en ese estado para a estar en estado Retired. Además, no se puede pasar a Ready ningún registro que no tenga al menos un Paso con el campo needs verification en true. • Edit Version: de tipo form button, cambia el estado Ready de una versión de Test al estado Draft, para poder modificar la Version de Test sin necesidad de crear una nueva. • Create New Version: de tipo form button, crea un nuevo registro con los mismos datos que el registro origen, excepto el campo state, que será Draft, y el campo Version, cuyo valor será el número entera siguiente a la última versión creada para ese Test. • Delete Test: de tipo form button, elimina el registro Test padre de la versión de Test, y todos los registros asociados. Esta entidad tiene deshabilitados las UI Action Insert y Insert and Stay. 5.2.6 Entidad Paso La entidad Paso muestra todos los pasos que se han de realizar para completar un Test de manera individual. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Step: campo de tipo string que describe el paso a realizar. • Order: campo de tipo integer que define el orden de los pasos, teniendo en cuenta el Order del resto y empezando por el más bajo. • Needs Verification: campo de tipo checkbox que marco si un paso concreto necesita verificación. • Code: campo de tipo string que indica el código del paso • Test Version: campo de tipo referencia a la tabla Test Version que relaciona el paso con la versión de Test a la que pertenece. 5.2.7 Entidad Resultado de Test La entidad Resultado de Test muestra los resultados de cada Test realizado por los usuarios. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • Result: campo de tipo string que muestra en resultado de la última prueba realizada para ese Test. Los resultados posibles son Passed, Blocked, Failed y Not Finished. • Updated: campo de tipo datetime que muestra el momento de ejecución del Test. • Test Run: campo de tipo referencia a la tabla Test Run que muestra el registro que contiene los datos sobre la ejecución del Test.
85 • Test Version: campo de tipo referencia a la tabla Test Version que relaciona el resultado de Test con la versión de Test a la que pertenece. Por otro lado, en esta tabla se muestra un UI Formatter, denominado Test Step, el cual muestra a través de una UI Macro del mismo nombre el resultado concreto de cada paso que se ha realizado en la ejecución del Test. En los campos que necesitan verificación, marca los resultados de este, así como muestra los comentarios añadidos por el usuario y los archivos adjuntos. 5.2.8 Entidad Test Run La entidad Test Run muestra los datos del resultado de la ejecución de un Test en concreto. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • Name: campo de tipo string que indica el nombre del funcionamiento de Test realizado. • Started: campo del tipo datetime que indica momento del inicio del Test. • Finished: campo del tipo datetime que indica momento del final del Test. • Duration: campo de tipo duration que indica la duración del Test. • State: campo de tipo string que indica la situación actual del Test. Las opciones son In Progress o Closed. • Execution Environment: campo de tipo referencia a la tabla Test Environment, que muestra el entorno de ejecución en el que se ha realizado el Test. Solo se puede asociar uno que pertenezca a la Compañía del Test. • Run by: campo de tipo referencia a la tabla User que muestra que usuario fue el que realizó la ejecución del Test. • Total Test: campo de tipo integer que muestra el número de Test totales realizados para el Test Run. • Passed: campo de tipo integer que muestra el número de Test correctos realizados para el Test Run. • Failed: campo de tipo integer que muestra el número de Test fallidos realizados para el Test Run. • Blocked: campo de tipo integer que muestra el número de Test bloqueados realizados para el Test Run. • Not Finished: campo de tipo integer que muestra el número de Test no finalizados realizados para el Test Run. Esta tabla contiene una serie de listas relacionadas que muestran las siguientes relaciones: • Test Results: muestra todos los Resultados de Test asociados al Test Run en concreto. Además de las UI Actions nombradas como generales, la entidad Test Run tiene otras relacionadas exclusivamente para su uso: • Continue Run: de tipo form button, permite retomar la ejecución de un Testeo que se había quedado en pausa durante su ejecución. 5.2.9 Entidad Entorno de Test Es una entidad en la que están registrados los distintos entornos disponibles en los que se ha podido realizar un Test. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son:
86 • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • Name: de tipo string que nombra el entorno. • Short Description: campo de tipo string que aporta una pequeña descripción del entorno. • Type: de tipo string que determina el tipo del que es un entorno. Las opciones son Development, Production, QA, Staging, Support y UAT. • Company: de tipo reference, hace referencia a un registro de la tabla Company. Contiene la empresa a la que pertenece ese Entorno de Test. • URL: de tipo url, indica la url para acceder al entorno. 5.2.10 Entidad Plan de Test Entidad que nos muestra un plan de Test creado por un usuario concreto que permite juntar los Test en distintas agrupaciones. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • Planned Start Date: campo de tipo datetime que indica cuando está previsto que empiece el plan de Test. • Planned End Date: campo de tipo datetime que indica cuando está previsto que finalice el plan de Test. • Planned Duration: campo de tipo duration que indica cual es la duración prevista. • Name: campo de tipo string que nombra el plan de Test. • State: campo de tipo integer que indica el estado actual en el que está el plan de Test. Las opciones son Pending, Work in Progress, Open, Closed Completed, Closed Incompleted y Closed Skipped. • Owner: campo de tipo referencia a User, que indica que usuario es el encargado de la gestión de ese Plan de Test concreto. • Description: campo de tipo string que aporta una explicación del plan de Test. • Percent Complete: campo de tipo percent complete que indica que porcentaje del plan de Test se ha ejecutado. • Percent Passed: campo de tipo percent complete que indica que porcentaje del plan de Test se ha ejecutado con éxito. • Percent Failed: campo de tipo percent complete que indica que porcentaje del plan de Test se ha ejecutado fallidamente. • Percent Blocked: campo de tipo percent complete que indica que porcentaje del plan de Test se ha bloqueado. Esta tabla contiene una lista relacionada que muestra la siguiente relación: • Test Cycles: establece la relación entre el plan de Test y los distintos ciclos de Test que componen el mismo. 5.2.11 Entidad Ciclo de Test Entidad que nos muestra una parte de un plan de Test que está previsto ejecutar en un periodo concreto que se incluye dentro del plan de Test. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son:
87 • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • Planned Start Date: campo de tipo datetime que indica cuando está previsto que empiece el ciclo de Test. • Planned End Date: campo de tipo datetime que indica cuando está previsto que finalice el ciclo de Test. • Planned Duration: campo de tipo duration que indica cual es la duración prevista. • Name: campo de tipo string que nombra el ciclo de Test. • State: campo de tipo integer que indica el estado actual en el que está el ciclo de Test. Las opciones son Pending, Work in Progress, Open, Closed Completed, Closed Incompleted y Closed Skipped. • Test Plan: campo de tipo referencia a Test Plan, que indica en que plan de Test está incluido en ciclo de Test concreto • Description: campo de tipo string que aporta una explicación del ciclo de Test. • Percent Complete: campo de tipo percent complete que indica que porcentaje del ciclo de Test se ha ejecutado. • Percent Passed: campo de tipo percent complete que indica que porcentaje del ciclo de Test se ha ejecutado con éxito. • Percent Failed: campo de tipo percent complete que indica que porcentaje del ciclo de Test se ha ejecutado fallidamente. • Percent Blocked: campo de tipo percent complete que indica que porcentaje del ciclo de Test se ha bloqueado. Esta tabla contiene una lista relacionada que muestra la siguiente relación: • Test Execution Suite: establece la relación entre el ciclo de Test y los distintos softwares de ejecución de Test que componen el mismo. 5.2.12 Entidad Software de Ejecución de Test Entidad que muestra un plan de ejecución de Test, asignando los encargados de ejecutar estos y delimitando los plazos en los que estos se tienen que ejecutar. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Number: autonumérico que proporciona ServiceNow, que se usa para identificar el número de registro dentro de la tabla. • Planned Start Date: campo de tipo datetime que indica cuando está previsto que empiece el software de ejecución de Test. • Planned End Date: campo de tipo datetime que indica cuando está previsto que finalice el software de ejecución de Test. • Planned Duration: campo de tipo duration que indica cual es la duración prevista. • Name: campo de tipo string que nombra el software de ejecución del Test. • Test Cycle: campo de tipo referencia a la tabla Test cycle que muestra a que ciclo de Test está asociado el software de ejecución de Test. • State: campo de tipo choice que indica el estado actual en el que está el software de ejecución de Test. Las opciones son Draft, Planning, Current, Complete y Cancelled. • Assignment Group: campo de tipo referencia a la tabla Group que indica que grupo se encargará de ejecutar estas ejecuciones de Test.
88 • Assigned To: campo de tipo referencia a la tabla User que indica que usuario se encargará de ejecutar estas ejecuciones de Test. • Story: campo de tipo referencia a la tabla Storie, que asocia el software de ejecución de Test con una story concreta. Esta tabla contiene una lista relacionada que muestra la siguiente relación: • Test Execution Assignment: establece la relación entre un Test y el software de ejecución de Test asociado correspondiente. Además de las UI Actions nombradas como generales, la entidad Software de Ejecución de Test tiene otras relacionadas exclusivamente para su uso: • Add Test Set: de tipo form button, te direcciona a la tabla Test Set, donde te muestra el listado de conjuntos de Test y el botón Add To Execution Suite. • Add Test: de tipo form button, te direcciona a la tabla Test, donde te muestra el listado de Test y el botón Add To Execution Suite. 5.2.13 Entidad Asignación de ejecución de Test Entidad que relaciona los distintos Test con un software de ejecución de Test y se lo asigna a un usuario. Los campos asociados a esta tabla que a su vez tienen relevancia en el proyecto son: • Test: campo de tipo referencia a la tabla Test que indica el Test asociado. • Test Execution Suite: campo de tipo referencia a la tabla Test Execution Suite que indica el software de ejecución de Test asociado. • Assigned To: campo de tipo referencia a la tabla User que indica que usuario se encargará de este Test en concreto. Además de las UI Actions nombradas como generales, la entidad Asignación de Ejecución de Test tiene otras relacionadas exclusivamente para su uso: • Run: de tipo list banner button, permite la ejecución de una serie de Test que se muestran en la tabla uno detrás de otro, de forma que todos formen parte del mismo Test Run. Para que el botón se muestre, la tabla tiene que tener un filtro en el que solo se muestre las asignaciones de ejecución de Test de un mismo Test y que el usuario logueado sea el que se encuentra en el campo Assigned To de todos los registros. La versión de Test que ejecuta es la cual cuyo campo state tiene valor Ready. 5.2.14 Entidad Storie Es una entidad en las que se definen los desarrollos técnicos que se tienen que realizar en una determinada tarea, además de los criterios de aceptación de esta. Además, define quien se debe encargar de ella, los plazos que tiene para ello y quien es el encargado de supervisar la correcta realización de la tarea. El desarrollo de esta entidad no es realizado en sí para este Trabajo de Fin de Grado, pero si la capacidad de asociar esta entidad con la entidad Software de Ejecución de Test. Para ello, cuenta con la siguiente Related list: • Software de ejecución de Test: permite crear un registro en la entidad Test Execution Suites, que tendrá el campo Storie completado con el registro de la entidad Storie desde el que se ha creado.
89 5.2.15 Database View Test Run Step Results Test Run Step Results es una Database View que permite crear una relación entre distintas tablas basándose en campos referencia contenidas en las mimas. Las tablas utilizadas para crear esta Database View son Test Set Test (Conjunto de Test Test), Test Version (Version de Test), Test Result (Resultado de Test) y Step Result (Resultado de paso). Además, a cada tabla se le asocia un prefijo distinto para luego poder mostrar sus campos en caso de que estos tengan el mismo nombre. Los prefijos son las siguientes: Tabla Prefijo Test Set Test tsm2m Test Version tv Test Result tr Step Result sr Tabla 5.2.2 Relación de tablas Test Run Step Results Los distintos campos que se muestran en los formularios son los siguientes (se indica entre paréntesis de donde proviene el campo): Number (sr_Test_result.Test_run) Run by (sr_Test_result.Test_run) Test Run (sr_Test_result) Updated (sr_Test_result) Execution Environment (sr_Test_result.Test_run) Test Set (tsm2m_Test_set) Company (tsm2m_Test_set) Code (tsm2m_Test) User logged (tsm2m_Test) Previous requirement(tsm2m_Test) Short Description (tsm2m_Test) Description (tsm2m_Test) Code (sr_step) Needs Verification (sr_step) Step (sr_step) Result (sr_result) Comments (sr_comments) Tabla 5.2.3 Formulario de Test Run Step Results Los campos que se muestran en el listado del registro para esta Database View son los siguientes, mostrándose estos en el orden en el que señalan (entre paréntesis a que registro están asociados): • Company (Test Set). • Owner. • Test Run. • Process (Test Set). • Category (Test Set). • Test Set. • Code (Test Set). • Short Description. • Description (Test). • Previous Requirements (Test). • User logged (Test). • Code (Step).
96
97 6 Implementación de entidades de funcionalidad Además de las tablas y los campos que sirven para crear entidades, hay otras en ServiceNow que aportan funcionalidad al proyecto. En estas entidades se programa a través de JavaScript [16] para conseguir que todos los procesos funcionen correctamente. Estas entidades se dividen en cliente, que son las que se ejecutan de cara a cliente y que no acceden a la base de datos de ServiceNow directamente, si no que tendrán que llamar a una entidad de servidor para que lo haga por ellas. Las llamadas desde cliente no pueden actualizar campos de otros registros que no sea en el que se está ejecutando. Las entidades de servidor son aquellas que si pueden acceder a la base de datos, obtener información de los distintos registros de cualquier entidad, y hacer cambios en cualquier registro. Además de las reglas normales de programación en JavaScript, ServiceNow proporciona una serie de objetos y funciones predefinidas que facilitan la labor de implentación en la herramienta. Estos objetos se dividen, de manera que hay algunos disponibles en el lado del cliente [17] y otros que solo lo están en el lado del servidor [18]. Business Rules: Una Business Rule es una entidad de tipo servidor que contiene un script de servidor que se ejecuta cuando en el registro de una tabla asociada se produce una acción, como puede ser la creación, borrado o inserción de un registro [19]. Esta tabla es una tabla propia de ServiceNow y proporciona algunas funcionalidades predefinidas. En las Business Rules hay varios campos que delimitan cuando se ejecutarán. Estos campos de especial relevancia son: • Table: de tipo referencia, determina la tabla para la que se ejecuta la Business Rule. • When: de tipo string, indica, en relación con otra serie de campos, cuando se ejecuta la Business Rule. Puede ser Before, After, Display o Async. • Insert, Update, Delete y Query: campos de tipo True/False que determina cuando se ejecuta la Business Rule en combinación con el campo when. Puede haber varios marcados a la vez. Campo When Campo True False marcado Momento de ejecución Before Insert Antes de insertar el registro Update Antes de actualizar el registro Delete Antes de borrar el registro Query Antes de la query After Insert Después de insertar el registro Update Después de actualizar el registro Delete Después de borrar el registro Query Después de la query Async Insert Asíncronamente al insertar el registro Update Asíncronamente al actualizar el registro Delete Asíncronamente al borrar el registro Query Asíncronamente al lanzar la query Display Al cargar el formulario Tabla 6.1.1Funcionamiento de las Business Rules • Filter condition: de tipo condition, establece condiciones para la ejecución de la Business Rule. • Conditions: de tipo condition, establece condiciones para la ejecución de la Business Rule a través de código escrito. • Script: de tipo script, parte de código que se ejecutara cuando se cumplan todas las condiciones.
98 6.1.1 Business Rules de Gestión de Proyecto Las Business Rules asociadas a las tablas de Gestión de Proyectos son las siguientes: • SS - Calculate Projected SDC: calcula el valor de los campos projected effort y cost del SDC para una tarea de proyecto cuando los campos Actual SDC se actualizan. • SS - Calculate Projected BPC: calcula el valor del campo projected effort y cost BPC para una tarea de proyecto cuando los campos Actual BPC se actualizan. • SS - Calculate Projected PDM: calcula el valor del campo projected effort y cost PDM para una tarea de proyecto cuando los campos Actual PDM se actualizan. • SS - Calculate Projected DC: calcula el valor del campo projected effort y cost DC para una tarea de proyecto cuando los campos Actual DC se actualizan. • SS - Projected Cost/Effort Project Task: calcula el valor del campo projected effort y cost para una tarea de proyecto. • SS - Projected Cost/Effort Project: calcula el valor del campo projected effort y cost para un proyecto. • SS - Calculated Planned Effort and cost: calcula todos los campos planned cost asociados a cada rol, y además los campos planned effort y planned cost de la tarea de proyecto. • SS - Planned Effort Mandatory: comprueba que al menos uno de los campos planned effort de rol de la tarea de proyecto es mayor que 0. • SS - Update Actual Cost and Effort: calcula el valor de los campos actual cost y effort para los roles cuando se aprueba una Time Card. • SS - Calculated Projected Cost Effort RP: calcula el valor de los campos projected cost y effort de una tarea de proyecto para todos los roles cuando un Plan de Recursos de aprueba o se cancela. • Populate Resource Plan: popula el campo resource plan cuando se inserta o actualiza una Time Card. • SS - Calculate Projected SDC: calcula el valor de los campos projected effort y cost del SDC para una tarea de proyecto cuando una Asignación de Recursos de ese rol se actualiza. • SS - Calculate Projected BPC: calcula el valor del campo projected effort y cost BPC para una tarea de proyecto cuando una Asignación de Recursos de ese rol se actualiza. • SS - Calculate Projected PDM: calcula el valor del campo projected effort y cost PDM para una tarea de proyecto cuando una Asignación de Recursos de ese rol se actualiza. • SS - Calculate Projected DC: calcula el valor del campo projected effort y cost DC para una tarea de proyecto cuando una Asignación de Recursos de ese rol se actualiza. 6.1.2 Business Rules de Test Management Las Business Rules asociadas a las tablas de Test Management son las siguientes: • SS - Autopopulate Test Version's Company: popula el campo Company de las entidades Versión de Test asociadas a un Test. • SS - Updated Relation Test Set – Test: crea y elimina registros de la tabla Conjunto de Test Test, de forma que cada entidad Test solo pueda estar asociado a un registro de esta tabla. • Create Test: cuando se crea una Versión de Test original (número de versión 1) se crea el Test asociado al que se asocia, populando todos los campos. • SS - Insert Code Step: popula los code Steps cuando se crea una copia de una Version de Test.
99 • SS - Update Assignment To: actualiza los campos Assigned To de los registros Asignación de Ejecución de Test con el mismo campo del registro Software de Ejecución de Test con el que se relaciona. Client Script Un Client Script es una entidad de tipo cliente que contiene un script de cliente que se ejecuta cuando en el registro de una tabla asociada se produce una acción, como puede ser la carga del formulario o la modificación de algún campo [20]. Esta tabla es una tabla propia de ServiceNow y proporciona algunas funcionalidades predefinidas. En los Client Scripts hay varios campos que delimitan cuando se ejecutarán. Estos campos de especial relevancia son: • Table: de tipo referencia, determina la tabla para la que se ejecuta el Client Script. • Inherited: de tipo True/False, si está activo todas las tablas que extiendan de la tabla indicada en el campo table también tendrán dicha funcionalidad. • Type: de tipo string, determina cuando se ejecuta el Client Script, como se indica en la siguiente tabla: Nombre Cuando se ejecuta onLoad Cuando se carga el formulario onSubmit Cuando se actualiza el formulario onChange Cuando un campo designado en el campo field name cambia, pudiendo incluir durante la carga del formulario. onCellEdit Cuando un campo designado en el campo field name es modificado dese el listado. Tabla 6.2.1 Campo type en los Client Script • Field Name: de tipo field, indica que campo de la tabla hará que se disparé la ejecución (solo aplica en Client Scripts de tipo onChange o onCellEdit). • Script: de tipo script, parte de código que se ejecutara cuando se cumplan todas las condiciones. 6.2.1 Client Scripts de Gestión de Proyecto Los Client Scripts asociados a las tablas de Gestión de Proyectos son los siguientes: • SS - Resource Type "Role": de tipo onChange, en un Plan de Recursos si el campo project hace referencia a la tabla Demanda, el campo resource type tiene valor Role Type y pasa a ser un campo no editable. • SS - Change Resource Type: de tipo onChange, en un Plan de Recursos si el campo resource type cambia, el campo resource rate se vacía automáticamente. • SS - R.Rate & Message Member List Role: de tipo onChange, en un Plan de Recursos si el campo member list cambia, se popula el campo resource rate con el valor encontrado en la tabla Hojas de Tarifas de Gasto para el rol que tengan los miembros del campo. También comprueba si todos los usuarios de la lista tienen el mismo rol. • SS - Resource Rate & Message User Role: de tipo onChange, en un Plan de Recursos si el campo user cambia, se popula el campo resource rate con el valor encontrado en la tabla Hojas de Tarifas de Gasto para el rol que tenga el usuario.
100 • SS - Set Resource Rate When Task Changes: de tipo onChange, en un Plan de Recursos si el campo project cambia, se popula el campo resource rate con el valor encontrado en la tabla Hojas de Tarifas de Gasto para la tarea. • SS - Check Rate Before Approve: de tipo onSubmit, cuando se aprueba una Time Card se comprueba que hay una Hoja de Tarifa de gasto asociada a los datos que contiene. 6.2.2 Client Scripts de Test Management Los Client Scripts asociados a las tablas de Test Management son los siguientes: • SS - Short Description Editable: de tipo onLoad, cuando se crea un Test el campo short Description es editable. • SS - Test Version New View Form: de tipo onLoad, en un registro Versión de Test se muestra unos campos u otros para la vista New View según si el registro es nuevo o no. Script Includes Los scripts includes son registros en los que se desarrolla código JavaScript para proveer de funciones y clases que aportan funcionalidad a la instancia en el lado del servidor [21]. Para que un Script Include se le pueda llamar desde el lado de cliente debe tener activado el campo de tipo True/False client callable. Cuando un Script Include se marca como Client Callable se suele finalizar su nombre con el sufijo Ajax. Normalmente un Script Include con el campo client callable activo, tiene una pareja con el mismo desactivado. Esta pareja comparte nombre, y el que tiene el campo client callable activo añade el sufijo Ajax, como se ha indicado en el párrafo anterior. 6.3.1 Script Includes de Gestión de Proyecto Los Script Includes que desarrollan funcionalidad para la parte de Gestión de Proyectos son: • SSTimeCardAutoUtilAjax: da funcionalidad a las Time Card. Es el script include de tipo client callable. Aporta funcionalidad para buscar y obtener Planes de Recursos asociados a través de la función populateResourcePlan(). • SSTimeCardAutoUtil: da funcionalidad a las Time Card para completar campos de las mismas. Entre las funciones que tiene: o getStartOfWeek(): calcula el día que empieza la semana en la que se genera la Time Card. o populateResourcePlan(): popula el campo resource plan de la Time Card. o getResourcePlan(): obtiene el resource plan. • SS_TimeCardTaskRateProcessor: da funcionalidad a las Time Cards para comprobar el buen funcionamiento de estas. Entre las funciones que tiene: o processTaskTimecard(): procesa la Time Card cuando este ya está completada y no va tener más modificaciones. o getRate(): comprueba que existe una Hoja de Tarifa de Gasto asociada al Time Card mediante el Task y el rol del User asociado. • SS_ProjectedCostInProject: proporciona funcionalidad para los campos projected effort y projected cost dentro de Project. Entre las funciones que tiene: o setProjectedCostAndEffort(): calcula los campos projected cost y projected effort de Proyecto. • SS_ResourcePlanMessagesAjax: proporciona funcionalidad para rellenar los campos de la entidad Plan de Recursos. Entre las funciones que tiene están: o validateTaskRate(): obtiene el valor del campo task rate de la Hoja de Tarifa de Gasto asociada para rellenar el campo task rate del Plan de Recursos.
101 o getProjectClass(): determina a que entidad pertenece el campo project. o getUserRole(): determina el rol del usuario del campo user. o validateUser(): determina que el usuario del campo user es válido. o validateValuesMember(): determina que dos usuarios del campo member list tienen el mismo rol. • SS_ProjectedCostInProjectTask: proporciona funcionalidad para los distintos campos de esfuerzo y coste que se encuentran dentro de la entidad Tarea de Proyecto. Entre las funciones que tiene están: o calculatedCostEffortProjectTaskDC(): modifica los campos projected cost y projected effort del rol DC y actualiza la Tarea de Proyecto. o calculatedCostEffortProjectTaskSDC(): modifica los campos projected cost y projected effort del rol SDC y actualiza la Tarea de Proyecto. o calculatedCostEffortProjectTaskPDM(): modifica los campos projected cost y projected effort del rol PDM y actualiza la Tarea de Proyecto. o calculatedCostEffortProjectTaskBPC(): modifica los campos projected cost y projected effort del rol BPC y actualiza la Tarea de Proyecto. o calculateProjectedCostEffort(): calcula el valor de los campos projected cost y projected effort basándose en un rol y en una Tarea de Proyecto. o calculatedPlannedCostRol(): calcula el valor del campo projected cost de un rol para una Tarea de Proyecto, un rol, y un esfuerzo planeado. 6.3.2 Script Includes de Test Management Los Script Includes que desarrollan funcionalidad para la parte de Test Management son: • SS_TestUtils: aporta funcionalidad a todo el módulo de Test Management, incluyendo la creación de registros a través del importador. Entre las funciones que tiene están: o createTestSetRecord(): es llamada desde el importador para crear un registro Conjunto de Test en caso de que este no exista previamente. o createTestRecord(): es llamada desde el importador para crear un registro Test en caso de que este no exista previamente. o createTestVersionRecord(): es llamada desde el importador para crear un registro Versión de Test en caso de que este no exista previamente. o creaTestepRecord(): es llamada desde el importador para crear un registro Paso en caso de que este no exista previamente. o createRelationTestTestSet(): crea un registro Conjunto de Test Test. o deleteRelationTestTestSet(): elimina un registro Conjunto de Test Test. o updateTestAssignmentTo(): actualiza el campo assigned to de los registros Asignación Ejecución de Test a través de un registro Software de Ejecución de Test. o canUpdateCodes(): comprueba si existen registros Conjunto de Test Test asociados a un Conjunto de Test.
102
103 7 Plan de pruebas Durante la implementación de los distintos procesos que se han realizado en el Trabajo de Fin de Grado, se ha ido ejecutando un plan de pruebas para comprobar el correcto funcionamiento de los desarrollos y las posibles mejoras a realizar. Los planes de prueba de Gestión de Proyectos y los de Test Management se probaron de manera independiente. Este plan de pruebas se adapta a lo dispuesto por el cliente para la creación de este[22]. No cuenta con pruebas de carácter no funcional, ya que el cliente SilverStorm no ha considerado necesario centrarse a los aspectos que abarcan estas pruebas durante los desarrollos. Tampoco se han desarrollado pruebas para empleados con poco conocimiento técnico, ya que todas las personas que van a utilizar las funcionalidades desarrolladas son personas con conocimiento tanto en informática como en ServiceNow, y dominan el vocabulario que contienen estas pruebas[23]. Además, al finalizar la implementación, se reproduce un proceso completo en el que se incluyó todo lo implementado en la herramienta de ServiceNow, para comprobar que los desarrollos realizados funcionaban correctamente y todos los cambios estaban correctamente integrados entre sí. Los procesos de Gestión de Proyectos y los de Test Management, igual que en el caso anterior se probaron de manera independiente. Además, al formar parte de un proyecto más grande, en la demo se pasará por puntos del proceso que no han desarrollado específicamente para este proceso. Todo el plan de pruebas se ha llevado a cabo en la instancia de desarrollo de SilverStorm. Esta instancia es en la que se realizan todos los desarrollos internos de la compañía, y es un espejo de la instancia de producción. Cuando un desarrollo se termina y cumple los requisitos, se sube desde esta instancia a la de producción. Periódicamente se clona la instancia de producción en la de desarrollo, para que sea lo más parecida posible. Plan de Prueba Gestión de Proyectos 7.1.1 Pasos Previos: Para poder probar el proceso necesitamos crear previamente una serie de datos registrados que permitan comprobar la funcionalidad. Se han creado una serie de usuarios con los roles asociados para poder realizar el proceso: Nombre Rol User DC DC User SDC SDC User PDM PDM User BPC BPC Tabla 7.1.1 - Usuarios creados También se ha creado un grupo al que pertenecen los cuatro usuarios creados previamente, que se denomina como “TFG Users Group”. Además, en la tabla Resources Roles contamos con los siguientes registros:
104 Nombre Ratio Hora DC 25€ SDC 50€ PDM 50€ BPC 55€ Tabla 7.1.2 Registros Resource Role que nos permitirán calcular algunos campos del proceso más adelante. 7.1.2 Creación de Proyecto Caso 1: • Descripción: a través de la tabla de proyectos creamos un nuevo proyecto. • Pasos a seguir: o En el Menú, accedemos a Project->All. o Click en New. o El formulario se carga correctamente. o Se rellenan los campos obligatorios. o Click en Save. • Pruebas realizadas: o Prueba 1: crear proyecto ▪ Resultado esperado (salida): se crea un proyecto con los datos incluidos. ▪ Resultado obtenido: se ha creado un proyecto con el número PRJ0010683. OK. 7.1.3 Creación de Tarea de Proyecto Caso 1: • Descripción: a través de la related link Create Test Phase de proyectos creamos una nueva Tarea de Proyecto. • Requisitos previos: hemos accedido al Proyecto PRJ0010683. • Pasos a seguir: o Click en Create Test Phase. o El formulario de Tarea de Proyecto se carga correctamente. o Se rellenan los campos obligatorios. o Click en Save. • Pruebas realizadas: o Prueba 1: crear Tarea de Proyecto a través de Create Test Phase ▪ Resultado esperado: se crea una Tarea de Proyecto con los datos incluidos. ▪ Resultado obtenido: se ha creado una Tarea de Proyecto con el número PRJTASK0015657. OK. Caso 2: • Descripción: a través del context menú Project Task Creator del formulario de proyecto creamos nuevas Tarea de Proyecto. • Requisitos previos: hemos accedido al Proyecto PRJ0010683.
105 • Pasos a seguir: o Click con botón derecho en el banner. o Click en Project Task Creator. o La UI Page se carga correctamente. o Se rellenan los datos correctamente. o Se crean las tareas de proyecto marcadas. • Pruebas realizadas: o Prueba 1: crear Tarea de Proyecto a través de Project Task Creator ▪ Datos de entrada: Number of Task: 2. ▪ Resultado esperado (salida): se crea un proyecto con los datos incluidos. ▪ Resultado obtenido: se han creado dos Tareas de Proyecto con el número PRJTASK0015658 y PRJTASK0015659. OK. 7.1.4 Cálculo de campos Planned Cost y Planned Effort en las Tareas de Proyecto Caso 1: • Descripción: actualizar los campos de planned effort y planned cost relacionados con los roles (DC, SDC, PDM y BPC). • Requisitos previos: acceder a la Tarea de Proyecto PRJTASK0015657. • Pasos a seguir: o Editar campos de planned effort. o Editar campos de planned cost. o Click en Save. • Pruebas realizadas: o Prueba 1: actualizar campos planned effort [rol] y planned cost [rol]. ▪ Datos de entrada: Planned Effort DC: 2 horas. Planned Cost DC: 500€ Planned Cost SDC 700€. ▪ Resultado esperado: se actualizan los campos indicados. El campo Planned Cost se actualiza con la suma de los campos Planned Cost y el campo Planned Effort se actualiza con los campos de Planned Effort. En proyecto se actualizan los campos Planned Cost y Planned Effort. En Proyecto se actualizan Planned Effort y Planned Cost (cost price). ▪ Resultado obtenido: el registro se ha actualizado correctamente. OK. o Prueba 2: actualizar campos planned effort [rol] sin Hojas de Tarifas de Proyecto Asociadas. ▪ Requisitos previos adicionales: no existen Hojas de Tarifas de Proyecto asociadas. ▪ Datos de entrada: Planned Effort DC: 2 horas. Planned Effort SDC: 2 horas ▪ Resultado esperado: la Tarea de Proyecto no se actualiza y se imprime el mensaje de error “There are not Task Rate Cards associated with roles: DC, SDC”. ▪ Resultado obtenido: se imprime él mensaje y el registro no se actualiza. OK. o Prueba 3: actualizar campos planned effort [rol] con Hojas de Tarifas de Proyecto Asociadas. ▪ Requisitos previos adicionales: existen Hojas de Tarifas de Proyecto asociadas a todos los roles (creadas en el apartado 6.1.5). ▪ Datos de entrada: Planned Effort DC: 2 horas, Planned Effort SDC: 2 horas, Planned Effort DC: 2 horas, Planned Effort SDC: 2 horas.
112 ▪ Resultado esperado: el registro se crea con los datos correspondientes. En el campo Resource Rate se carga el gasto asociado en la Hoja de Tarifas de Gasto. El campo state tiene valor Planning. ▪ Resultado obtenido: OK. o Prueba 9: crear Plan de Recursos para usuario con rol SDC con Hoja de Tarifas de Gastos asociada. ▪ Requisitos previos adicionales: activar las Hojas de Tarifas de Gastos asociadas a la Tarea de proyecto y al proyecto del que proviene. ▪ Datos de entrada: Project: PRJTASK0015657; Resource Type: User Resource; User SDC; End Date: después del día actual. ▪ Resultado esperado: el registro se crea con los datos correspondientes. En el campo Resource Rate se carga el gasto asociado en la Hoja de Tarifas de Gasto. El campo state tiene valor Planning. ▪ Resultado obtenido: OK. Caso 2: • Descripción: crear registro en la tabla Planes de Recursos desde Demanda. • Requisitos previos: acceder a la Demanda y abrir una demanda. • Pasos a seguir: o Ir a la related list Planes de Recursos. o Click en New. o Rellenar los campos. o Click en Save. • Pruebas realizadas: o Prueba 1: crear Plan de Recursos para una demanda con el campo type con valor Project. ▪ Requisitos previos adicionales: la demanda es de tipo Project. ▪ Datos de entrada: End Date: después del día actual. ▪ Resultado esperado: Resource Type = Role Resource; Task type: Demand; Opciones Project Task: 01-Initiate, 02-Prepare, 03-Create, 04-Transition, 05Closed, 06-Management, Resource Rate: se rellena manualmente. ▪ Resultado obtenido: OK. Todos los campos cumplen los parámetros esperados. El registro se crea correctamente con ellos. o Prueba 2: crear Plan de Recursos para una demanda con el campo type con valor Service Improvent – Enchacement. ▪ Requisitos previos adicionales: la demanda es de tipo Service Improvent – Enchacement. ▪ Datos de entrada: End Date: después del día actual. ▪ Resultado esperado: Resource Type = Role Resource; Task type: Demand; Opciones Project Task: 01-Initiate, 02-Prepare, 03-Create, 04-Transition, 05Closed, 06-Management, Resource Rate: se rellena manualmente. ▪ Resultado obtenido: OK. Todos los campos cumplen los parámetros esperados. El registro se crea correctamente con ellos. o Prueba 2: crear Plan de Recursos para una demanda con el campo type con valor Service Improvement . ▪ Requisitos previos adicionales: la demanda es de tipo Service Improvent – Enchacement.
113 ▪ Datos de entrada: End Date: después del día actual. ▪ Resultado esperado: Resource Type = Role Resource; Task type: Demand; Opciones Project Task: 00 - SERVICE TRANSITION, 01 - ADVANCE PLATFORM SUPPORT, 02 - BASIC CONFIGURATION SUPPORT, 03 - ENHANCEMENT SERVICES, 04 - ARQUITECTURAL SERVICES, 05 - UPGRADE, 06 – MANAGEMENT; Resource Rate: se rellena manualmente. ▪ Resultado obtenido: OK. Todos los campos cumplen los parámetros esperados. El registro se crea correctamente con ellos. 7.1.10 Creación de Asignaciones de Recursos: Caso 1: • Descripción: crear registros en la tabla Asignación de Recursos asociado a un Plan de Recursos creado previamente. • Requisitos previos: acceder a un registro de la tabla Plan de Recursos para el que no se han creado las asignaciones de recursos. • Pasos a seguir: o Ir a SilverStorm Implementation>Resource Management>Resource Plans. o Acceder a un registro. o Click en Create Soft Allocation. • Pruebas realizadas: o Prueba 1: crear las Asignaciones de Recursos para un Plan de Recursos asociado a una Tarea de Proyecto para un usuario DC. ▪ Requisitos previos adicionales: el campo Task del Plan de Recursos es una Tarea de Proyecto, el usuario asociado tiene rol DC. ▪ Resultado esperado: en la related list Resource Allocation se generan los registros que Asignan los recursos al usuario dividiéndolo semanalmente La suma total de los campos requested hours de estos registros son iguales a las horas planificadas. En la Tarea de Proyecto asociada los campos projected effort DC y projected cost DC se actualizan sumando las nuevas horas y coste previsto. Además, los campos projected effort y projected cost se les suman también. En el Proyecto asociado, se actualizan los campos projected effort, projected cost y projected cost (cost price). ▪ Resultado obtenido: OK. o Prueba 2: crear las Asignaciones de Recursos para un Plan de Recursos asociado a una Tarea de Proyecto para un usuario PDM. ▪ Requisitos previos adicionales: el campo Task del Plan de Recursos es una Tarea de Proyecto, el usuario asociado tiene rol PDM. ▪ Resultado esperado: en la related list Resource Allocation se generan los registros que Asignan los recursos al usuario dividiéndolo semanalmente, la suma total de los campos requested hours de estos registros son iguales a las horas planificadas. En la Tarea de Proyecto asociada los campos projected effort PDM y projected cost PDM se actualizan sumando las nuevas horas y coste previsto. Además, los campos projected effort y projected cost se les suman también. En el Proyecto asociado, se actualizan los campos projected effort, projected cost y projected cost (cost price). ▪ Resultado obtenido: OK
114 o Prueba 3: crear las Asignaciones de Recursos para un Plan de Recursos asociado a una demanda. ▪ Requisitos previos adicionales: el campo Task del Plan de Recursos es una Demanda. ▪ Resultado esperado: en la related list Resource Allocation se generan los registros que Asignan los recursos al usuario dividiéndolo semanalmente, la suma total de los campos requested hours de estos registros son iguales a las horas planificadas. ▪ Resultado obtenido: OK. 7.1.11 Solicitar Plan de Recursos Caso 1: • Descripción: un plan de Recursos pasa a estado Requested. • Requisitos previos: acceder a un registro de la tabla Plan de Recursos en estado Planning. • Pasos a seguir: o Ir a SilverStorm Implementation>Resource Management>Resource Plans. o Acceder a un registro. o Click en Request. • Pruebas realizadas: o Prueba 1: solicitar la aprobación de un Plan de Recursos. ▪ Resultado esperado: el estado del Plan de Recursos pasa a ser Requested. ▪ Resultado obtenido: OK. 7.1.12 Asignar Plan de Recursos • Descripción: un plan de Recursos pasa a estado Allocated. • Requisitos previos: acceder a un registro de la tabla Plan de Recursos en estado Requested. • Pasos a seguir: o Ir a SilverStorm Implementation>Resource Management>Resource Plans. o Acceder a un registro. o Click en Confirm and Allocation. • Pruebas realizadas: o Prueba 1: solicitar la aprobación de un Plan de Recursos. ▪ Resultado esperado: el estado del Plan de Recursos pasa a ser Allocated. ▪ Resultado obtenido: OK. 7.1.13 Rechazar Plan de Recursos • Descripción: un plan de Recursos es rechazado. • Requisitos previos: acceder a un registro de la tabla Plan de Recursos en estado Requested. • Pasos a seguir: o Ir a SilverStorm Implementation>Resource Management>Resource Plans. o Acceder a un registro. o Click en Reject. • Pruebas realizadas:
115 o Prueba 1: solicitar la aprobación de un Plan de Recursos. ▪ Resultado esperado: el estado del Plan de Recursos pasa a ser Planning. ▪ Resultado obtenido: OK. 7.1.14 Finalización de Plan de Recursos Caso 1: • Descripción: completar un Plan de Recursos • Requisitos previos: el Plan de Recursos se encuentra en estado Allocated • Pasos a seguir: o Ir a SilverStorm Implementation>Resource Management>Resource Plans o Acceder a un registro o Click en Complete. • Pruebas realizadas: o Prueba 1: completar un Plan de Recursos asociado a una Tarea de Proyecto con user con rol DC. ▪ Requisitos previos adicionales: el campo task contiene un registro de tipo Tarea de Proyecto y el campo user un registro con rol DC. ▪ Resultado esperado: en el Plan de Recursos, el estado pasa a Complete. En la Tarea de Proyecto asociada los campos projected effort DC y projected cost DC se actualizan restando horas y coste que estaban asignadas a ese plan. Además, los campos projected effort y projected cost se les restan también. En el Proyecto asociado, se actualizan los campos projected effort, projected cost y projected cost (cost price). ▪ Resultado obtenido: OK. o Prueba 2: completar un Plan de Recursos asociado a una Tarea de Proyecto con user con rol PDM. ▪ Requisitos previos adicionales: el campo task contiene un registro de tipo Tarea de Proyecto y el campo user un registro con rol PDM. ▪ Resultado esperado: en el Plan de Recursos, el estado pasa a Complete. En la Tarea de Proyecto asociada los campos projected effort PDM y projected cost PDM se actualizan restando horas y coste que estaban asignadas a ese plan. Además, los campos projected effort y projected cost se les restan también. En el Proyecto asociado, se actualizan los campos projected effort, projected cost y projected cost (cost price). ▪ Resultado obtenido: OK. o Prueba 3: completar un Plan de Recursos asociado a una Demanda. ▪ Requisitos previos adicionales: el campo task contiene un registro de tipo Demanda. ▪ Resultado esperado: en el Plan de Recursos, el estado pasa a Complete. ▪ Resultado obtenido: OK. Caso 2: • Descripción: cancelar un Plan de Recursos . • Requisitos previos: el Plan de Recursos se encuentra en estado Planning.
116 • Pasos a seguir: o Ir a SilverStorm Implementation>Resource Management>Resource Plans. o Acceder a un registro. o Click en Cancel.. • Pruebas realizadas: o Prueba 1: completar un Plan de Recursos asociado a una Tarea de Proyecto con user con rol SDC. ▪ Requisitos previos adicionales: el campo task contiene un registro de tipo Tarea de Proyecto y el campo user un registro con rol SDC. ▪ Resultado esperado: en el Plan de Recursos, el estado pasa a Cancelled. En la Tarea de Proyecto asociada los campos projected effort SDC y projected cost SDC se actualizan restando horas y coste que estaban asignadas a ese plan. Además, los campos projected effort y projected cost se les restan también. En el Proyecto asociado, se actualizan los campos projected effort, projected cost y projected cost (cost price). ▪ Resultado obtenido: OK. o Prueba 2: completar un Plan de Recursos asociado a una Tarea de Proyecto con user con rol BPC. ▪ Requisitos previos adicionales: el campo task contiene un registro de tipo Tarea de Proyecto y el campo user un registro con rol BPC. ▪ Resultado esperado: en el Plan de Recursos, el estado pasa a Cancelled. En la Tarea de Proyecto asociada los campos projected effort BPC y projected cost BPC se actualizan restando horas y coste que estaban asignadas a ese plan. Además, los campos projected effort y projected cost se les restan también. En el Proyecto asociado, se actualizan los campos projected effort, projected cost y projected cost (cost price). ▪ Resultado obtenido: OK. o Prueba 3: completar un Plan de Recursos asociado a una Demanda. ▪ Requisitos previos adicionales: el campo task contiene un registro de tipo Demanda. ▪ Resultado esperado: en el Plan de Recursos, el estado pasa a Cancelled. ▪ Resultado obtenido: OK. Mejoras para Gestión de Proyectos Durante el proceso de plan de pruebas se han observado algunas mejoras que se podrían realizar en el proceso para sacar un mayor partido a los desarrollos realizados: • Añadir las horas y el coste del Plan de Recursos antes de crear las asignaciones: en el desarrollo las horas de los Planes de Recursos se añaden a los campos correspondientes en Tareas de Proyecto al crear las Asignaciones de Recursos. Si se hace desde que se crea el plan, se podrían prever los esfuerzos y costes con mayor facilidad. • Crear unos ciclos de vida para Proyectos y Tareas de Proyectos más lineal: en estos registros se puede pasar de unos estados a otros como se quiera. Organizando mejor estos cambios de estados, se mediría mejor en qué momento está el proyecto.
117 Datos de Prueba Test Management 7.3.1 Pasos previos Antes de realizar el proceso crearemos registros en distintas entidades Entorno de para tenerlos disponibles de cara a hacer las pruebas. Primero en la tabla de compañías (Company) creamos los siguientes registros: Name Code TFG DEMO 1 tfg_Number_1 TFG DEMO 2 tfg_Number_2 TFG DEMO 3 tfg_Number_3 Tabla 7.3.1 Registros de Compañías 7.3.2 Creación de Conjuntos de Test Caso 1: • Descripción: creación de un Conjunto de Test. • Pasos a seguir: o Ir a Test Management 2.0>Test Set. o Click en New. o Rellenar los campos. o Click en Save. • Pruebas realizadas: o Prueba 1: crear un Conjunto de Test. ▪ Resultado esperado: se crea un Conjunto de Test con los datos indicados. ▪ Resultado obtenido: OK. 7.3.3 Creación de Test y Versiones de Test versión 1 Caso 1: • Descripción: creación de un Test y Versión de Test 1 desde la tabla Test . • Pasos a seguir: o Ir a Test Management 2.0>Test. o Click en New. o Se abre el formulario de Versión de Test. o Rellenar los campos. o Click en Save. • Pruebas realizadas: o Prueba 1: crear un Test desde la lista de la tabla Test. ▪ Resultado esperado: se crea un Test y una Version de Test con el valor 1 en el campo version. ▪ Resultado obtenido: OK. Caso 2: • Descripción: creación de un Test y Versión de Test 1 desde un Conjunto de Test. • Pasos a seguir: o Ir a Test Management 2.0>Test Set. o Abrir un Conjunto de Test. o Ir a la Related List Test.
118 o Click en New. o Rellenar los campos. o Click en Save. • Pruebas realizadas: o Prueba 1: crear un Test desde un Conjunto de Test. ▪ Resultado esperado: se crea un Test y una Version de Test con el valor 1 en el campo version. El campo company es el mismo que el conjunto de Test y el campo Test Set es el conjunto de Test desde el que se ha creado la prueba. Ambos son no editables. ▪ Resultado obtenido: OK. 7.3.4 Asignación de Test ya creados a Conjuntos de Test Caso 1: • Descripción: creación de un Test y Versión de Test 1 desde la tabla Test. • Pasos a seguir: o Ir a Test Management 2.0>Test. o Seleccionar Test para añadir al Conjunto de Test. o Click en Add to Test Set. o Se abre una UI Page. o Seleccionar el Conjunto de Test. o Click en Add. • Pruebas realizadas: o Prueba 1: no seleccionar ningún Test antes de pulsar Add To Test Set. ▪ Resultado esperado: se imprime en la pantalla el mensaje “Please, select a Test” ▪ Resultado obtenido: OK. o Prueba 2: seleccionamos Test antes de pulsar Add To Test Set. La company del Conjunto de Test es distinta que la del Test. ▪ Resultado esperado: no se modifica el campo Test Set de los Test seleccionados. ▪ Resultado obtenido: OK. o Prueba 3: seleccionamos Test antes de pulsar Add To Test Set. La company del Conjunto de Test es la misma que la de los Test. ▪ Resultado esperado: se modifica el campo Test Set de los Test seleccionados cambiándolo al Conjunto de Test elegido. ▪ Resultado obtenido: OK. 7.3.5 Actualización campo code en Test desde Conjunto de Test • Descripción: actualización del campo code de los Test a través del botón Update Test Codes. • Requisitos previos: el Conjunto de Test tiene varios Test asociados. • Pasos a seguir: o Ir a Test Management 2.0>Test Set. o Acceder a un Conjunto de Test. o Click en Update Test Codes. o Se carga la ventana “Select Code Condition”. o Rellenar los campos de “Select Code Condition”. o Click en Accept.
119 • Pruebas realizadas: o Prueba 1: dejar vacíos los campos obligatorios Prefix y Number of digits. ▪ Datos de entrada: Prefix:””; Number of digits:””; Initial Value. ▪ Resultado esperado: aparece un mensaje de error con las normas para rellenar los campos. ▪ Resultado obtenido: OK. o Prueba 2: el campo Number of digits no es un número. ▪ Datos de entrada: Prefix: ap ; Number of digits: ap ; Initial Value. ▪ Resultado esperado: aparece un mensaje de error con las normas para rellenar. ▪ Resultado obtenido: OK. o Prueba 3: el campo Number of digits es menor que 0. ▪ Datos de entrada: Prefix: ap ; Number of digits: -1 ; Initial Value. ▪ Resultado esperado: aparece un mensaje de error con las normas para rellenar. ▪ Resultado obtenido: OK o Prueba 4: el campo Number of digits es un número decimal. ▪ Datos de entrada: Prefix: ap; Number of digits: 3,4 ; Initial Value. ▪ Resultado esperado: aparece un mensaje de error con las normas para rellenar. ▪ Resultado obtenido: OK. o Prueba 5: el campo Initial Value no es un número. ▪ Datos de entrada: Prefix: ap ; Number of digits: 2 ; Initial Value: ap. ▪ Resultado esperado: aparece un mensaje de error con las normas para rellenar. ▪ Resultado obtenido: OK. o Prueba 6: el campo Initial Value es menor que 0. ▪ Datos de entrada: Prefix: ap ; Number of digits: 2 ; Initial Value:-1. ▪ Resultado esperado: aparece un mensaje de error con las normas para rellenar. ▪ Resultado obtenido: OK. o Prueba 7: el campo Initial Value es un número decimal. ▪ Datos de entrada: Prefix: ap; Number of digits: 2 ; Initial Value: 3,4. ▪ Resultado esperado: aparece un mensaje de error con las normas para rellenar. ▪ Resultado obtenido: OK. o Prueba 8: el campo Initial Value es un número mayor que 10 elevado al campo Number of digits. ▪ Datos de entrada: Prefix: ap; Number of digits: 2 ; Initial Value: 102. ▪ Resultado esperado: aparece un mensaje de error con las normas para rellenar. ▪ Resultado obtenido: OK. o Prueba 9: los campos se han rellenado correctamente ▪ Requisitos previos adicionales: el Conjunto de Test tiene 3 Test asociados. ▪ Datos de entrada: Prefix: ap; Number of digits: 2; Initial Value: 10. ▪ Resultado esperado: los Test se rellenan con los códigos ap10, ap11 y ap12. ▪ Resultado obtenido: OK.
120 7.3.6 Creación de Pasos Caso 1 • Descripción: creación de un Paso. • Pasos a seguir: o Ir a Test Management 2.0>Test. o Acceder a un Test. o Ir a la related list Test Version. o Acceder a la Version de Test. o En el formulario click en Add Step. o Rellenar los campos. • Pruebas realizadas: o Prueba 1: la Version de Test está en un estado distinto de Draft. ▪ Resultado esperado: No se pueden crear Pasos. ▪ Resultado obtenido: OK. o Prueba 2: la Version de Test está en estado de Draft, no se marca Needs Verification. ▪ Resultado esperado: se crea un Paso que no necesita verificación. ▪ Resultado obtenido: OK. o Prueba 3: la Version de Test está en estado de Draft, se marca Needs Verification. ▪ Resultado esperado: se crea un Paso que necesita verificación. ▪ Resultado obtenido: OK. 7.3.7 Ordenar Pasos Caso 1 • Descripción: ordenar los pasos a través del Test Step. • Requisitos previos: la Versión de Test está en estado Draft. • Pasos a seguir: o Ir a Test Management 2.0>Test. o Acceder a un Test. o Ir a la related list Test Version. o Acceder a la Version de Test. o En Test Steps, se mueven los Pasos entre sí. • Pruebas realizadas: o Prueba 1: en la Versión de Test se mueven los Pasos entre si. ▪ Resultado esperado: El order de los registros Pasos cambia teniendo el del Paso que esta primero el menor y el que está el último el mayor. ▪ Resultado obtenido: OK. Caso 2 • Descripción: ordenar los Pasos a través de los propios registros Pasos. • Requisitos previos: la Versión de Test está en estado Draft. • Pasos a seguir: o Ir a Test Management 2.0>Test. o Acceder a un Test. o Ir a la related list Test Version. o Acceder a la Version de Test.
121 o Ir a la related list Steps. o Modificar el campo order. o Click Update. • Pruebas realizadas: o Prueba 1: acceder a un Paso que no tenga el order más alto, y ponerle el más alto. ▪ Resultado esperado: En la Versión de Test, el Paso modificado aparece el último de la lista. ▪ Resultado obtenido: OK. o Prueba 2: acceder a un Paso que no tenga el order más bajo, y ponerle el más bajo. ▪ Resultado esperado: En la Versión de Test, el Paso modificado aparece el primero de la lista. ▪ Resultado obtenido: OK. 7.3.8 Crear Versiones de Test procedentes de otra Caso 1 • Descripción: ordenar los pasos a través del Test Step. • Requisitos previos: la Versión de Test está en estado Draft o Ready. • Pasos a seguir: o Ir a Test Management 2.0>Test. o Acceder a un Test. o Ir a la related list Test Version. o Acceder a la Version de Test. o Click Create New Version. • Pruebas realizadas: o Prueba 1: el Test al que está asociado la Versión de Test donde pulsamos el botón solo tiene una Versiones de Test. ▪ Resultado esperado: se crea una nueva Version de Test y todos los pasos asociados a ella iguales a la versión 1. El número del campo versión es 2. En el Test asociado, la Test versión es el 2. ▪ Resultado obtenido: OK. o Prueba 2: el Test al que está asociado la Versión de Test donde pulsamos el botón tiene tres Versiones de Test. ▪ Resultado esperado: se crea una nueva Version de Test y todos los pasos asociados a ella iguales a la versión 1. El número del campo versión es 4. En el Test asociado, la Test versión es el 4. ▪ Resultado obtenido: OK. 7.3.9 Establecer Version de Test como la actual en ejecución Caso 1 • Descripción: pasar Versiones de Test a estado Ready. • Requisitos previos: la Versión de Test está en estado Draft. El Test tiene al menos un Paso con el campo Needs Verification marcado. • Pasos a seguir: o Ir a Test Management 2.0>Test. o Acceder a un Test.
128 Caso 2 • Descripción: pausar la ejecución de Test Runs desde una la tabla de Asignación de Ejecución de Test. • Requisitos previos: el usuario tiene registros asignados en esta tabla. • Pasos a seguir: o Ir a Test Management 2.0>Test Assigned To Me. o Seleccionar Tests. o Click Run. o Rellenar los campos. o Click Pause. • Pruebas realizadas: o Prueba 1: ejecutar 3 Test y pulsar el botón Pause. ▪ Resultado esperado: aparece un mensaje indicando la pause. Se crea un registro Test Run con el campo total Test en 3, el campo state como In Progress. Se crea un registro Resultado de Test por cada Test con campo Result vacio. Los pasos que necesitan verificación aparecen en verde si son “passed”, en amarillo si son “blocked”, en rojo si son “failed” y en negro si son “not executed”. ▪ Resultado obtenido: OK. 7.3.18 Reiniciar la Ejecución de un Test pausado Caso 1 • Descripción: continuar la ejecución de Test Runs pausado. • Requisitos previos: el estado del Test Run es In Progress. • Pasos a seguir: o Ir a Test Management 2.0>Test Runs. o Acceder a un Test Run. o Click en Continue Run. • Pruebas realizadas: o Prueba 1: continuar ejecutando una prueba pausada. ▪ Resultado esperado: se vuelve a abrir la ventana de ejecución del Test Run en el estado en el que estaba y se termina de manera normal. ▪ Resultado obtenido: OK. Mejoras para Test Management Durante el proceso de plan de pruebas se han observado algunas mejoras que se podrían realizar en el proceso para sacar un mayor partido a los desarrollos realizados: • Hacer Test desde los Conjuntos de Test: al contener los Conjuntos de Test Test que tienen una relación entre sí, sería interesante implementar un botón Run desde el propio conjunto de Test. Ahora mismo se podría realizar añadiendo el Conjunto de Test a un Software de Ejecución de Test, pero el método propuesto es más rápido e intuitivo. • Controlar los Test que se añaden a un Software de Ejecución de Test y los que se ejecutan en conjuntos: ahora mismo se permite seleccionar cualquier tipo de Test en estas opciones, pero
129 para que el proceso sea eficiente solo deberían poder seleccionarse Test del mismo cliente (campo company). • Entornos de Test seleccionables en la ejecución: igualmente, cuando se ejecuta un Test se puede seleccionar un entorno de cualquier cliente. Sería mejor controlar este campo para que solo mostrara los Entornos de Test cuya company es la misma que el Test ejecutado, ya que esas pruebas solo serán validad en instancias de ese cliente. • Campo runnable versión en Test: cuando en una Versión de Test en Ready se pulsa el botón Edit Version, el campo runnable versión del Test asociado no se borra, cuando en ese momento no se puede ejecutar.
130
131 8 Conclusiones El trabajo de fin de grado me ha servido para trabajar varios conceptos que creo que me pueden ser muy útiles tanto en mi vida laboral como en la vida diaria. El uso de la herramienta ServiceNow me ha servido para ampliar mis conocimientos sobre los requisitos y las capacidades con las que cuenta esta aplicación, lo que creo que me será muy útil actualmente ya que es la herramienta con la que trabajo diariamente. Tener un mejor conocimiento sobre esta me permitirá ser más eficiente en mis tareas diarias y conocer módulos de esta que habría tardado más en dominar y en conocer. En referencia a la parte más técnica de programación, he ampliado mis conocimientos en Javascript y HTML5, además de Angular. Todos ellos son lenguajes que ahora mismo se usan en muchas empresas y entornos, por lo que un buen conocimiento sobre ellos me permitirá tener más opciones una vez finalizado este Trabajo de Fin de Grado. El trabajo con metodologías agiles y Scrum es muy útil ya que es un sistema que ahora mismo se usa en muchas empresas y entidades, y se el desarrollador de este Trabajo de Fin de Grado me ha permitido mejorar a nivel de organización de trabajo, de las relaciones con un cliente, y también a la hora de dar feedback a un cliente y proponer mejoras sobre los desarrollos que se están realizando, que es algo que no es mi papel diariamente, y me vendrá bien cuando en el futuro tenga que asumir más responsabilidades. Finalmente, creo que este proyecto ha motivado mi responsabilidad personal a la hora de hacer tareas cuando no hay nadie detrás exigiendo resultados tan de continuo, ya que es algo de lo que soy el único responsable (a nivel de estudios).
132
133 9 Bibliografía [1] SilverStorm. “¿QUIÉNES SOMOS?”. SilverStorm. https://silver-storm.com/conocenos/ (acceso: 9 de mayo de 2021) [2] ServiceNow. “ServiceNow”. ServiceNow. https://www.ServiceNow.es/now-platform.html acceso: 9 de mayo de 2021) [3] ServiceNow. ServiceNow Fundamentals Participant Guide. 1st Edition. Santa Clara, CA: ServiceNow, 2019 [4] K. Schwaber y J. Sutherland. La guía de scrum. 2020 [5] “Qué es SCRUM”. Proyectosagiles.org. https://proyectosagiles.org/que-es-scrum/ (acceso: 10 de abril de 2021). [6] ServiceNow. ”Field Types”. ServiceNow Product Documentation. https://docs.ServiceNow.com/bundle/quebec-platform-administration/page/administer/referencepages/reference/r_FieldTypes.html (acceso: 20 de enero de 2021). [7] ServiceNow. “Form Layout”. ServiceNow Product Documentation https://docs.ServiceNow.com/bundle/quebec-platform-administration/page/administer/formadministration/concept/configure-form-layout.html (acceso: 10 de febrero de 2021) [8] ServiceNow. “Related lists”. ServiceNow Product Documentation. https://docs.ServiceNow.com/bundle/quebec-platform-user-interface/page/use/usingforms/concept/c_RelatedLists.html (acceso: 20 de marzo de 2021). [9] ServiceNow. ” UI actions”. ServiceNow Product Documentation. https://docs.servicenow.com/bundle/quebec-platform-administration/page/administer/listadministration/concept/c_UIActions.html (acceso: 17 de febrero de 2021). [10] “Introducción a Bootstrap”. Bootstrap. https://getbootstrap.com/docs/5.0/gettingstarted/introduction/ (acceso: 12 de abril de 2021). [11] ServiceNow . “Extensions to Jelly syntax”. ServiceNow Product Documentation. https://docs.ServiceNow.com/bundle/paris-application-development/page/script/generalscripting/concept/c_ExtensionsToJellySyntax.html (acceso: 17 de mayo de 2021). [12] ServiceNow. ” Create a widget that displays a ServiceNow UI page”. ServiceNow Product Documentation. https://docs.ServiceNow.com/bundle/quebec-nowintelligence/page/use/dashboards/task/create_widget_displays_webpage.html (acceso: 2 de febrero de 2021). [13] ServiceNow. ” Interactive Filters” . ServiceNow Product Documentation. https://docs.servicenow.com/bundle/quebec-nowintelligence/page/use/dashboards/concept/c_HomepagePublishers.html (acceso: 15 de abril de 2021). [14] ServiceNow. “Create a reference field interactive filter”. ServiceNow Product Documentation https://docs.ServiceNow.com/bundle/quebec-nowintelligence/page/use/dashboards/task/t_CreateAReferenceFieldPublisher.html (acceso: 15 de abril de 2021). [15] ServiceNow. “Transform Maps”. ServiceNow Product Documentation https://docs.ServiceNow.com/bundle/quebec-platform-administration/page/script/serverscripting/concept/c_CreatingNewTransformMaps.html (acceso: 15 de enero de 2021).
134 [16] ServiceNow. Scripting in ServiceNow Fundamentals Participant Guide. 1st Edition. Santa Clara, CA: ServiceNow, 2019. [17] ServiceNow. “API Reference – Client”. ServiceNow Developer https://developer.ServiceNow.com/dev.do#!/reference/api/quebec/client/ (acceso: 10 de mayo de 2021). [18] ServiceNow. “API Reference – Server Global”. ServiceNow Developer https://developer.ServiceNow.com/dev.do#!/reference/api/quebec/server_legacy/ (acceso: 12 de mayo de 2021). [15] ServiceNow. “Business Rule”. ServiceNow Product Documentation. https://docs.ServiceNow.com/bundle/quebec-application-development/page/script/businessrules/concept/c_BusinessRules.html (acceso: 10 de abril de 2021). [16] ServiceNow. “Client Scripts”. ServiceNow Product Documentation. https://docs.ServiceNow.com/bundle/paris-application-development/page/script/clientscripts/concept/client-scripts.html (acceso: 13 de abril de 2021). [16] ServiceNow. “Scripts Include”. ServiceNow Product Documentation. https://docs.ServiceNow.com/bundle/paris-application-development/page/script/serverscripting/concept/c_ScriptIncludes.html (acceso: 17 de abril de 2021). [22] “Pruebas de software: 10 pasos para elaborar el plan de pruebas”. PMOinformatica.com. http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-software.html (acceso: 30 de abril de 2021). [23] J.M Sanchez Peño. Pruebas de Software. Fundamentos y Técnicas. 1ªed. Madrid: Universidad Politécnica de Madrid, 2015. [24] “Guía temática sobre citas bibliográficas UC3M: IEEE v01.29.2021”. Universidad Carlos III de Madrid. https://uc3m.libguides.com/guias_tematicas/citas_bibliograficas/IEEE#s-lg-box-wrapper13407990 (acceso: 18 de junio de 2021). [25] IEEE Publishing Operations. IEEE REFERENCE GUIDE. 1ªed. Piscataway, NJ: Institute of Electrical and Electronics Engineers.
135
136 10 Anexos Anexos Gestión de proyectos 10.1.1 Lógica de Proyecto Campos: La tabla de proyectos es la base para la gestión de lo desarrollado. En ella se utilizarán los siguientes campos para realizar la gestión del proyecto: Nombre del campo Type Mandatory Read Only Number String No Si State Choice No No Active True/False No No Project Name String Si No Planned Effort Duration No Si Actual Effort Duration No Si Projected Effort Duration No Si Actual Cost Currency No Si Projected Cost Currency No Si Planned Start Date Datetime No No Planned End Date Datetime No No Planned Cost (cost Price) Currency No Si Actual Cost (cost Price) Currency No Si Projected Cost (cost Price) Currency No Si Tabla 10.1.1 Lógica de campos de proyecto Estos campos se muestran en el formulario principal del siguiente modo (se incluyen campos que no han sido mencionados en el proyecto, ya que no se han desarrollado para el mismo): Number Special follow up Deployment ServiceNow State Offer Active Po Number Status Project Net Amount Project Manager Company Commercial Assigned Language Business Process Consultant Type Quality Assurance Consultant Schedule Senior Deployment Consultant Senior Deployment Consultant Project Name Description Tabla 10.1.2 Formulario de proyecto
137 A parte del formulario principal, encontramos dos formularios secundarios que se muestran como pestañas: La pestaña Project Information: Planned Effort Calculation Actual Effort Plannd Start Date Projected Effort Planned End Date Actual Cost Invoiced Projected Cost Pending Tabla 10.1.3 Pestaña Project Information de Proyecto La pestaña Project Task incluye la lista relacionada de tareas de proyecto que son hijas del proyecto en el que se encuentra. La pestaña Cost Price: Planned Cost (cost Price) Actual Cost (cost Price) Projected Cost (cost Price) Tabla 10.1.4 Pestaña Cost Price de Proyecto En la lista general de la tabla, se muestran los siguientes campos en cada registro: Number Company Project Manager Project Name State Plannd Start Date Planned End Date Percent Complete Planned Effort Actual Effort Planned Cost Actual Cost Service Aware Candidate Net Amount Project Net Amount Invoiced Pending Tabla 10.1.5 Vista de tabla de Proyecto 10.1.2 Lógica de Tareas de Proyecto Campos: los campos relacionados con este proyecto de la entidad de tareas de proyecto son: Nombre del campo Type Mandatory Read Only Number String No Si State Integer No No Short Description String No No Planned Effort DC Duration Solo 1 de los 4 campos No Planned Effort SDC Duration No Planned Effort PDM Duration No Planned Effort BPC Duration No Planned Effort Duration No Si Planned Cost DC Currency No Si Planned Cost SDC Currency No Si Planned Cost PDM Currency No Si Planned Cost BPC Currency No Si Planned Cost Currency No Si Actual Effort DC Duration No Si Actual Effort SDC Duration No Si Actual Effort PDM Duration No Si Actual Effort BPC Duration No Si Actual Effort Duration No Si
144 Figura 10.1.3 Tabla de proyectos Figura 10.1.4 Campos Coste y Esfuerzo de Proyecto Figura 10.1.5 Pestaña Cost Price en Proyecto Figura 10.1.6 Formulario Tarea de proyecto
145 Figura 10.1.7 Costes por Rol de Tarea de Proyecto Figura 10.1.8 Esfuerzo por Rol de Tareas de Proyecto Figura 10.1.9 Related list de Time Card en Tareas de Proyecto Figura 10.1.10 Related list de Planes de Prueba en Tareas de Proyecto
146 Figura 10.1.11 Formulario de creación de Plan de Recursos Figura 10.1.12 Formulario de Plan de Recursos creado desde Demanda Figura 10.1.13 Formulario de Plan de Recursos Figura 10.1.14 Related list de Asignación de Recursos en Plan de Recursos
147 Figura 10.1.15 Formulario de Asignación de Recursos Figura 10.1.16 Formulario de Time Card Figura 10.1.17 Lista de Hojas de Tarifa de Gasto
148 Figura 10.1.18 Formulario de Hoja de Tarifa de Gasto Figura 10.1.19 Lista de Recursos de Rol
149 Anexos Test Management 10.2.1 Lógica de Conjunto de Test Campos: los campos relacionados con este proyecto de la entidad de Conjunto de Test son: Nombre del campo Type Mandatory Read Only Reference Number String No Si Company Reference No No core_company Process Choice No No Owner Reference No No sys_user Category String No No Name String No No Tabla 10.2.1 Lógica de campos de Conjunto de Test Estos campos se muestran en el formulario principal del siguiente modo (se incluyen campos que no han sido mencionados en el Conjunto de Test Test, ya que no se han desarrollado para el mismo): Number Owner Company Category Process Name Tabla 10.2.2 Formulario de Conjunto de Test En la lista general de la tabla, se muestran los siguientes campos en cada registro: Number Name Process Company Owner Tabla 10.2.3 Vista de tabla de Conjunto de Test 10.2.2 Lógica de Conjunto de Test Test Campos: los campos relacionados con este proyecto de la entidad de Conjunto de Test Test son: Nombre del campo Type Mandatory Read Only Reference Test Set Reference Si No Conjunto de Test Test Reference Si No Test Tabla 10.2.4 Lógica de campos de Conjunto de Test Test Estos campos se muestran en el formulario principal del siguiente modo (se incluyen campos que no han sido mencionados en el conjunto de Test Test, ya que no se han desarrollado para el mismo): Domain Test Set Test Tabla 10.2.5 Formulario de Conjunto de Test Test En la lista general de la tabla, se muestran los siguientes campos en cada registro: Domain Test Test Set Tabla 10.2.6 Vista de tabla de Conjunto de Test Test Además, la tabla presenta una vista distinta en la Related list de las Versiones de Test: Test Set Tabla 10.2.7 Vista de tabla de Conjunto de Test Test en RL Versiones de Test 10.2.3 Lógica de Test Campos: los campos relacionados con este proyecto de la entidad de Test son: Nombre del campo Type Mandatory Read Only Reference Number String No Si
150 Runnable Version Reference No Si Versión de Test Company Reference No No Company Test Set Reference No No Conjunto de Test Latest Version Reference No Si Versión de Test Code String Si No User logged String No No Previous Requirements String No No Short Description String No Si Description String No No Tabla 10.2.8 Lógica de campos de Test Estos campos se muestran en el formulario principal del siguiente modo (se incluyen campos que no han sido mencionados en el Test, ya que no se han desarrollado para el mismo): Number LaTest Version Runnable Version LaTest Version.Result Company Code Test Set User logged Previous Requirements Short Description Description Tabla 10.2.9 Formulario de Test En la lista general de la tabla, se muestran los siguientes campos en cada registro: Number Company Test Set Short Description LaTest Version Runnable Version Tabla 10.2.10 Vista de tabla de Test Además, la tabla presenta una vista distinta en la Related list de los Conjuntos de Test: Test Code Tabla 10.2.11 Vista de tabla de Test en RL de Conjunto de Test 10.2.4 Lógica de Versión de Test Campos: los campos relacionados con este proyecto de la entidad de Versión de Test son: Nombre del campo Type Mandatory Read Only Reference Test Reference No Si Test Owner Reference No Si User State Choice No Si Version Integer No Si Short Description String No Si state ¡= Draft Tabla 10.2.12 Lógica de campos de Versión de Test Estos campos se muestran en el formulario principal del siguiente modo (se incluyen campos que no han sido mencionados en la Versión de Test, ya que no se han desarrollado para el mismo): Test State Owner Version Test.Company Test.Code Test.User logged Test.Previous Requirements
151 Short Description Test.Description Test Steps Tabla 10.2.13 Formulario de Versión de Test En la lista general de la tabla, se muestran los siguientes campos en cada registro: Short Description State Owner Version Test Tabla 10.2.14 Vista de tabla de Versión de Test Además, la tabla presenta una vista distinta en la Related list de los Conjuntos de Test: Short Description State Version Tabla 10.2.15 Vista de tabla de Versión de Test en RL de Test También aparece en la Related list de la propia entidad Versión de Test, denominada Other Version. En este caso la lista de campos es la misma que la lista general de la tabla. 10.2.5 Lógica de Paso Campos: los campos relacionados con este proyecto de la entidad de Paso son: Nombre del campo Type Mandatory Read Only Reference Order String No No Code String No No Step String No No Needs Verification True/False No No Test Version Reference Si Si Versión de Test Tabla 10.2.16 Lógica de campos de Paso Estos campos se muestran en el formulario principal del siguiente modo (se incluyen campos que no han sido mencionados en el Paso, ya que no se han desarrollado para el mismo): Order Code Step Needs Verification Tabla 10.2.17 Formulario de Paso En la lista general de la tabla, se muestran los siguientes campos en cada registro: Needs Verification Order Step Domain Test Version Tabla 10.2.18 Vista de tabla de Paso Además, la tabla presenta una vista distinta en la Related list de la Versión de Test: Order Step Needs Verification Code Tabla 10.2.19 Vista de tabla de Paso en RL de Versión de Test 10.2.6 Lógica de Resultado de Test Campos: los campos relacionados con este proyecto de la entidad de los Resultados de Test son: Nombre del campo Type Mandatory Read Only Reference Number String No Si Result String No Si Updated Datetime No Si Test Run Reference No Si Test Run Test Version Reference Si Si Versión de Test Tabla 10.2.20 Lógica de campos de Resultado de Test
152 Estos campos se muestran en el formulario principal del siguiente modo (se incluyen campos que no han sido mencionados en el Resultado de Test, ya que no se han desarrollado para el mismo): Number Test Version.Test Result Test Version.Version Test Run.Execution Enviroment Updated Test Run.Run by Test Run Steps Tabla 10.2.21 Formulario de Resultado de Test En la lista general de la tabla, se muestran los siguientes campos en cada registro: Number Test Version.Short Description Execution Status Result Tabla 10.2.22 Vista de tabla de Resultado de Test Además, la tabla presenta una vista distinta en las distintas Related list: Related list de Versión de Test: Number Result Test Run Updated Tabla 10.2.23 Vista de tabla de Resultado de Test en RL de Versión de Test Related list de Test Run: Number Test Version.Short Description Test Version.Test.Code Result Tabla 10.2.24 Vista de tabla de Resultado de Test en RL de Test Run
153 10.2.7 Lógica de Test Run Campos: los campos relacionados con este proyecto de la entidad de los Test Run son: Nombre del campo Type Mandatory Read Only Reference Number String No Si Started Datetime No Si Finished Datetime No Si Duration Duration No Si State String No Si Name String No Si Execution Environment Reference No Si Entorno de Test Run by Reference No Si User Total Sets Integer No Si Passed Integer No Si Failed Integer No Si Blocked Integer No Si Not Finished Integer No Si Tabla 10.2.25 Lógica de campos de Test Run Estos campos se muestran en el formulario principal del siguiente modo (se incluyen campos que no han sido mencionados en el Test Run, ya que no se han desarrollado para el mismo): Name Started Number Finished Execution Environment Duration Run by Closed Total Test Tabla 10.2.26 Formulario de Test Run A parte del formulario principal, encontramos el formulario secundario Results: Passed Blocked Failed Not Finished Tabla 10.2.27 Pestaña Results en Test Run En la lista general de la tabla, se muestran los siguientes campos en cada registro: Number Name State Started Finished Duration Execution Environment Execution Environment. Company Passed Failed Blocked Not Finished Tabla 10.2.28 Vista de tabla de Test Run