Repositorio Institucional de Documentos

Proyecto Fin de Carrera Optimización en los procesos de reporte de información de actividad Autor Cristian Garrido Méndez Director Diego Martín Aranda Ponente Francisco José López Pellicer Ingeniería en Informática Curso 2013/2014 AGRADECIMIENTOS A mis padres y hermana por su apoyo y comprensión durante todos estos DUROS años de aprendizaje. A Francisco José López Pellicer por su infatigable ayuda durante el proyecto y en la redacción de este documento. A Diego Martín y Víctor Vidaller por haberme dado la oportunidad de integrarme en un entorno empresarial y de aprender una tecnología puntera. A Patricia Moreno por demostrarme que la gente eciente y trabajadora existe y que no es una leyenda; y a María José Esteban por sus consejos sobre Sharepoint. A David Iruzubieta por haber sido un gran compañero de prácticas y no prácticas durante la carrera. Al doctor TorreIglesias y a su ayudante de campo por esas tardes de desconexión previas a exámenes. Y por último, a Raquel Sanz por su apoyo en los peores momentos de esta etapa que está a punto de nalizar. GRACIAS A TODOS!! i RESUMEN GENERAL El presente documento conforma la memoria del proyecto n de carrera (PFC) desarrollado durante el curso 2013-2014, en él se resume todo el trabajo elaborado en el proyecto consistente en el diseño e implementación de una aplicación contenida en una Intranet empresarial. Ésta planica, ordena y centraliza toda la información de los distintos proyectos en curso gestionados en una consultora informática. Para el desarrollo de la aplicación, se ha utilizado Sharepoint 2010 así como otras herramientas como Sharepoint Designer 2010 o Visual Studio 2010, las cuales han permitido realizar las modicaciones más avanzadas. iii Índice general 1. Introducción 1 1.1. ContextoProfesional.............................. 1 1.1.1. HiberusTecnología........................... 1 1.2. ContextoTecnológico.............................. 2 1.2.1. Microsoft Sharepoint 2010 . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.2. Tecnologías.NET............................ 2 1.2.3. Microsoft SQL Server 2008 R2 . . . . . . . . . . . . . . . . . . . . . 3 1.2.4. Microsoft Reporting Services 2008 R2 . . . . . . . . . . . . . . . . . 3 1.2.5. JavaScript................................ 3 1.3. Objetivos y motivación del proyecto . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Metodología................................... 4 1.5. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Trabajo realizado 7 2.1. Análisisderequisitos.............................. 7 2.1.1. Obraencurso.............................. 7 2.1.2. Ingresosygastos ............................ 9 2.1.3. Informes................................. 10 2.1.4. Procedimientos internos . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.5. MigraciónSEDA ............................ 15 2.2. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Diseño...................................... 17 2.3.1. Obraencurso.............................. 18 2.3.2. Ingresosygastos ............................ 18 2.3.3. Informes................................. 19 2.3.4. Procedimientos internos . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3.5. MigraciónSEDA ............................ 23 2.4. Implementación................................. 24 2.4.1. Obraencurso.............................. 24 2.4.2. Ingresosygastos ............................ 25 2.4.3. Informes................................. 25 2.5. Vericación y validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 v 2.5.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.5.2. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6. ResultadoFinal................................. 27 3. Conclusiones 31 3.1. Valoracióntécnica................................ 31 3.2. Continuidad del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3. Valoraciónpersonal............................... 32 Bibliografía 32 A. Diagramas Casos de Uso 37 B. Fórmulas obra en curso 41 C. Diagramas de ujo en procedimientos 43 D. Tipos de dato en procedimientos 47 D.1. Asignación de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 D.2. Desasignación de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 D.3.BajaVoluntaria................................. 52 D.4.Cambiocontractual............................... 52 D.5.Vacaciones.................................... 54 D.6.Gastos...................................... 55 E. Alertas de Procedimientos 57 E.1. Asignación de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 E.2. Desasignación de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 E.3.Bajavoluntaria................................. 61 E.4.Cambiocontractual............................... 62 E.5.Vacaciones.................................... 63 E.6.Gastos...................................... 64 vi Índice de guras 1.1. Interacción entre sistemas antes y despues del proyecto . . . . . . . . . . . 4 1.2. Metodología iterativa e incremental . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Ejemplo informe rentabilidad . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Arquitecturalógica............................... 17 2.3. Mapa de navegación de la aplicación . . . . . . . . . . . . . . . . . . . . . 17 2.4. Diagrama que muestra el comportamiento de la obra en curso . . . . . . . 19 2.5. Relaciones entre asignación, desasignación y baja voluntaria . . . . . . . . 22 2.6. Captura de pantalla de la biblioteca Obra en Curso . . . . . . . . . . . . . 28 2.7. Captura de pantalla de la lista de permisos . . . . . . . . . . . . . . . . . . 28 2.8. Captura de pantalla de la página de generación de informes de rentabilidad 29 A.1. Diagrama de casos de uso de la obra en curso . . . . . . . . . . . . . . . . 37 A.2. Diagrama de casos de uso de la obra en curso . . . . . . . . . . . . . . . . 38 A.3. Diagrama de casos de uso de los informes . . . . . . . . . . . . . . . . . . . 38 A.4. Diagrama de casos de uso de los procedimientos internos . . . . . . . . . . 39 A.5. Diagrama de casos de uso de la migración de SEDA . . . . . . . . . . . . . 40 C.1. Diagrama de ujo del procedimiento de desasignación de recursos . . . . . 43 C.2. Diagrama de ujo del procedimiento de asignación de recursos . . . . . . . 44 C.3. Diagrama de ujo del procedimiento de baja voluntaria . . . . . . . . . . . 45 C.4. Diagrama de ujo del procedimiento de cambio contractual . . . . . . . . . 45 C.5. Diagrama de ujo del procedimiento de cambio solicitud de vacaciones . . 46 C.6. Diagrama de ujo del procedimiento de solicitud de gastos . . . . . . . . . 46 vii 1.4 Metodología 1. Introducción todos los empleados que ofrece una eciente vía de acceso a la gestión, colaboración e información. SEDA : Sistema de gestión Comercial y Clientes, es una utilidad corporativa de registro, gestión, seguimiento y análisis unicado de la información. ADN : Sistema de Gestión y Control de Tareas y Recursos, es una aplicación corporativa de registro, gestión, seguimiento y análisis de todas las actividades/proyectos/servicios desarrolladas en la empresa. La nalidad de este proyecto es la integración de parte de ellos en una única aplicación haciendo uso de las posibilidades y potencialidad que ofrece Sharepoint. Esta unión, reejará una mejora de la gestión y automatización de los procedimientos. La gura 1.1 muestra la interacción entre los sistemas antes y depues del desarrollo de este proyecto. Figura 1.1: Interacción entre sistemas antes y despues del proyecto A nivel personal, se plantean otra serie de objetivos orientados a la consecución del título de Ingeniero Superior en Informática: Conseguir una mejor visión de la estructura de una empresa. Mejora de la capacidad de autoaprendizaje. Integración en un grupo de trabajo. Búsqueda de soluciones óptimas ante un problema real. 1.4. Metodología Para la realización de este proyecto se ha utilizado una metodología de desarrollo iterativo e incremental [2] ( véase Figura 1.2 ). Esta metodología de trabajo se caracteriza por dividir el proyecto en bloques o tareas. En cada bloque se repite un proceso de trabajo 4 1. Introducción 1.5 Estructura del documento similar para proporcionar un resultado completo sobre el producto nal. Las etapas han seguido una metodología en cascada en la que cada fase no puede comenzar hasta que su fase previa haya terminado. Las fases de cada tarea han sido las siguientes: Análisis de requisitos, diseño, implementación, pruebas y mantenimiento. Figura 1.2: Metodología iterativa e incremental 1.5. Estructura del documento A continuación, se detallan las siguientes secciones que forman parte de este documento: Capítulo 1 : Es el apartado en el que nos encontramos y que sirve de introducción al resto de la memoria. Capítulo 2 : Esta sección describe el trabajo realizado para la consecución del proyecto. Se especica la arquitectura utilizada y las diferentes etapas de todo proyecto software: análisis, diseño, implementación, vericación y validación. Capítulo 3 : Muestra una conclusión general sobre el desarrollo del proyecto, su continuidad y valoraciones técnicas y personales. 5 Capítulo 2 Trabajo realizado En este apartado de la memoria, se especica todo el trabajo desarrollado durante el transcurso del proyecto. 2.1. Análisis de requisitos En esta sección se describe el comportamiento que debe tener cada uno de los componentes que forman la aplicación de este proyecto n de carrera. En el anexo A se pueden consultar los diagramas de casos de uso de cada uno de los componentes de la aplicación. 2.1.1. Obra en curso La obra en curso es un informe de rentabilidad que crea mensualmente Hiberus , en él aparecen reejados diversos datos (jos y variables por mes) ligados a los proyectos que maneja la compañía. A continuación, se detallan los datos jos que se manejan de cada proyecto: código, cliente, proyecto, importe total, costes derivados, importe para proyecto, total facturado, pendiente facturar, estado, DIM 1, DIM 2, DIM 3, DIM 4, DIM 6 y proyecto cerrado. Cada proyecto está identicado por 6 dimensiones: DIM 1 (o dirección general), DIM 2 (o unidad de gestión), DIM 3 (o responsable comercial), DIM 4 (o tipo de servicio), código y DIM 6 (o delegación). Proyecto cerrado nos indica si en realidad es un proyecto o una asistencia técnica. Los datos que varían cada mes por proyecto son los siguientes: horas totales, horas periodo, avance total, avance periodo, incurrido total, incurrido periodo, coste derivado, facturado mes y estado facturas. Toda esta información se extrae de la base de datos SIIC (base de datos de SEDA) a través de la ejecución de un procedimiento almacenado cuyos parámetros de entrada son: 7 2.1 Análisis de requisitos 2. Trabajo realizado fecha de inicio, fecha de n y el identicador de la unidad de gestión (0 para extraer de todas). El problema que se plantea es la necesidad de extraer todos estos datos en una tabla Excel (.xlsx) calculando nuevos datos mensuales por proyecto usando como fuente los datos descritos anteriormente. Esta tabla se podrá aceptar (consolidar toda la información en base de datos) o rechazar (volver a generar). Los nuevos datos calculados mensualmente son los siguientes: Horas: Horas acumuladas hasta el periodo actual. Incurrido : Importe trabajado hasta la fecha actual. Facturado : Facturado acumulado hasta el mes actual. Costes Derivados : Costes totales del proyecto hasta el periodo actual. Obra Producida Periodo : Indicador que evalúa el trabajo interno realizado durante cada periodo. Obra Producida Acumulada : Indicador que evalúa el trabajo interno realizado en el año en curso. Generado Periodo : Indicador que valora el trabajo realizado durante cada periodo. Generado Acumulado : Indicador que valora el trabajo realizado durante todos los meses del año actual. Obra En Curso : Indicador que valora el trabajo realizado frente a la facturación. Euro/Hora Periodo : Indicador que indica el valor de cada hora respecto a la obra producida del último mes. Euro/Hora Acumulado : Indicador que indica el valor de cada hora respecto a la obra producida desde el inicio del curso. Tipo Hora: Distingue cinco tipos de horas (Inversión, productivas, externas, comerciales y de garantía). La tabla 2.1 detalla los requisitos de este componente de la aplicación. 8 2. Trabajo realizado 2.1 Análisis de requisitos ID Descripción R1 La aplicación guardará backups en base de datos de la obra en curso consolidada mensualmente R2 La aplicación generará automáticamente la tabla .xlsx el día 6 de cada mes R3 La aplicación permitirá consolidar el documento excel deseado en base de datos R4 La aplicación permitirá volver a generar los datos de la tabla excel, siempre y cuando dicha tabla no esté ya consolidada en base de datos R5 La aplicación mostrará errores en el caso de que los hubiera, indicando la columna de qué proyecto da el error en la tabla .xlsx R6 Cada documento .xlsx tendrá cinco estados: pendiente, consolidado, rechazado, en proceso y con errores R7 Los cálculos entre columnas deberán aparecer reejados en el documento (Ej: =H2+J2/K2) R8 Cada columna de la tabla deberá tener ltros con el n de ordenar las distintas las por el criterio deseado R9 La aplicación deberá estar orientada a Sharepoint y a su arquitectura Tabla 2.1: Requisitos obra en curso 2.1.2. Ingresos y gastos Mensualmente, la administración de Hiberus actualiza un documento Excel en el que van apareciendo reejados los diferentes ingresos y gastos (tanto directos como indirectos) de cada proyecto que desarrolla la empresa. Algunas de las columnas más representativas de dicho documento son: mes, cliente SEDA, epígrafe, varios (es el código del proyecto), medio, submedio, cliente/proveedor, importe, descripción, tipo de ingreso (directo, indirecto o ninguno) y tipo de gasto (directo, indirecto o ninguno). El único objetivo de esta parte es que exista una forma de consolidar este archivo en base de datos como con el componente anterior. La tabla 2.2 detalla los requisitos de este componente de la aplicación. ID Descripción R1 La aplicación permitirá consolidar una hoja de ingresos y gastos en base de datos R2 La aplicación avisará de posibles fallos en la hoja en el caso de que los hubiera R3 La aplicación deberá estar orientada a Sharepoint y a su arquitectura Tabla 2.2: Requisitos ingresos y gastos 9 2.1 Análisis de requisitos 2. Trabajo realizado 2.1.3. Informes Mensualmente, se realizan dos tipos distintos de informes: de rentabilidad y de horas. Ambos utilizan los datos de las hojas Excel citadas en los dos apartados anteriores y se realizan mediante el uso de tablas dinámicas en Excel. 2.1.3.1. Informe de rentabilidad Este informe se divide en otros dos subinformes: Ingreso-Gasto (Rentabilidad): Muestra la cantidad de gastos e ingresos de cada medio y submedio durante los meses transcurridos del año en curso junto a la obra e interno producidos por cada uno. Generado-Gasto: Muestra la cantidad de generado y de gastos de cada medio y submedio durante los meses transcurridos del año actual. Ambos subinformes poseen unos ltros jos comunes: tipo de usuario, costes (directos o indirectos), meses, medios y submedios. El ltro tipo de usuario modica la vista del informe de tal forma que se pueden ver medios contenidos dentro de submedios y viceversa. Existen cinco ltros optativos que en función de su valor aumentan el número de niveles de cada la, por defecto es dos: medio y submedio (véase gura 2.1). Estos ltros poseen los siguientes valores: cliente SEDA, cliente/proveedor, epígrafe, varios (o código de proyecto) o descripción. 2.1.3.2. Informe por horas Representa la cantidad de horas de cada tipo (productivas, de inversión, comerciales y de garantía) invertidas por cada medio/ unidad de gestión de la compañía en cada uno de los meses transcurridos del año actual. El informe permite ltrar las columnas por meses y las las por unidad de gestión. El objetivo principal de la aplicación es que genere dinámicamente los distintos informes. En el caso del informe de rentabilidad, la aplicación permitirá al departamento de operaciones asignar un listado de medios y submedios visibles por cada usuario. También debe existir la posibilidad de reportar los detalles de un informe de rentabilidad al departamento de operaciones para su posterior revisión. Destacar que en Excel, al pulsar sobre cualquier celda de un informe, ésta nos redirige a la tabla fuente de datos ltrada de tal forma que muestra únicamente los detalles de la celda. 10 2. Trabajo realizado 2.1 Análisis de requisitos Figura 2.1: Ejemplo informe rentabilidad Otra de las tareas a realizar será mostrar ambos informes de forma gráca mediante un gráco de barras en el que se muestren las cantidades por meses, así como una tabla debajo del gráco que detalle las cantidades en forma numérica. La tabla 2.3 detalla los requisitos de este componente de la aplicación. ID Descripción Requisitos generales para los informes R1 La aplicación deberá estar orientada a Sharepoint y a su arquitectura R2 Exisitirán dos tipos de informe: rentabilidad y horas R3 La aplicación permitirá generar un gráco del tipo de informe elegido R4 Tanto los informes como las grácas se podrán exportar a formato .xls o .pdf R5 Existirá la posibilidad de ver los detalles de cualquier dato de un informe Requisitos dedicados del informe por horas R6 El informe por horas contendrá los ltros: medio y mes (desde enero hasta el mes actual). Ambos ltros serán de elección multiple. R7 El informe por horas representará la cantidad de horas de cada tipo (ordenadas por mes) de los medios y meses seleccionados R8 En el informe por horas se mostrarán cifras totales, tanto por las como por columnas R9 El gráco del informe por horas estará formado por un diagrama de barras en el que aparecerá la cantidad de cada tipo de horas por mes y una tabla en la que podremos ver los mismos datos de forma numérica Requisitos dedicados del informe de rentabilidad 11 2.1 Análisis de requisitos 2. Trabajo realizado R10 Se podrán reportar los detalles de un informe de rentabilidad para que sea revisado por el Departamento de Operaciones R11 Los tipos de reporte son: OC, generado, ingresos y gastos, varios y error - tipo proyecto R12 Al realizar un reporte se introducirá un comentario y se indicará el tipo de reporte R13 El reporte deberá contener un archivo excel en el que aparezcan reejados los datos reportados por el usuario R14 El Departamento de Operaciones podrá añadir un comentario a un reporte dado R15 Un reporte podrá tener uno de los siguientes estados: solicitado, desestimado, aceptado, pendiente modicación admin, pendiente modicación operaciones, subsanado o cancelado por el usuario R16 La aplicación tendrá la opción de administrar los medios y submedios que cada usuario podrá seleccionar R17 El informe de rentabilidad contendrá los siguientes ltros: tipo de informe, tipo de usuario, costes, medio, submedio, mes (desde enero hasta el mes actual), mostrar obra, mostrar interno y cinco ltros optativos (servirán para desglosar cada medio/submedio en función de su: cliente SEDA, cliente/proveedor, epígrafe, código de proyecto o descripción) R18 El ltro tipo de informe permitirá elegir entre dos subinformes: rentabilidad(ingresogasto) o generado-gasto. En función del tipo seleccionado cada mes del informe se dividirá en ingresos y gastos o en generado y gastos R19 El ltro tipo de usuario tendrá los siguientes valores: MAC y Responsable. En función de la selección, los medios se desglosarán en submedios (MAC) o los submedios se dividirán en medios (Responsable) R20 El ltro costes tendrá dos valores: todos y directos. En función de la selección, se utilizarán en el informe gastos directos o indirectos y directos R21 El ltro mostrar obra nos permitirá mostrar la obra como un mes más si el tipo de subinforme elegido es 'rentabilidad' R22 El ltro mostrar interno nos permitirá mostrar el interno como un mes más si el tipo de subinforme elegido es 'rentabilidad' R23 Los valores de los ltros medio y submedio serán dedicados en función del usuario. El departamento de Operaciones tiene que poder asignar a cada usuario los medios y submedios que un usuario puede visualizar R24 En los dos subinformes se mostrarán cifras totales, tanto por las como por columnas R25 El gráco del informe de rentabilidad estará formado por un diagrama de barras en el que aparecerá la cantidad de ingresos-gastos/generado-gasto (dependiendo del tipo de subinforme elegido) por mes y una tabla en la que podremos ver los mismos datos de forma numérica Tabla 2.3: Requisitos de informes 12 2. Trabajo realizado 2.1 Análisis de requisitos 2.1.4. Procedimientos internos Hiberus posee un conjunto de procedimientos internos para la gestión de sus empleados. De este conjunto, se ha decidido que se implanten en una arquitectura Sharepoint: asignación de recursos, desasignación de recursos, baja voluntaria, cambios contractuales, vacaciones y gastos. 2.1.4.1. Asignación de recursos El proceso se inicia cuando un responsable de área detecta la necesidad de incorporación de un nuevo recurso a su equipo de trabajo. Inicialmente, se buscan reasignaciones internas que cumplan con el perl del puesto y en caso de no haber, se buscan externas. Una vez elegidos uno o varios candidatos por el solicitante, el Departamento de Operaciones decidirá cuál de ellos será el elegido. Para nalizar, se da de alta al usuario en el sistema. Una solicitud de este tipo puede tener los siguientes estados: pendiente de evaluación, pendiente de información, evaluada negativamente, evaluada positivamente, asignación interna, asignación externa, pendiente de validar por el solicitante, validado, seleccionado, en proceso de tramitación y incorporado. 2.1.4.2. Desasignación de recursos El proceso se inicia cuando un responsable detecta la necesidad de desasignar a un recurso de su unidad de gestión. Desde el Departamento de Operaciones se intentará reasignar el recurso en otro centro de trabajo. Si no ha sido posible la reasignación, se procederá a la desvinculación del recurso y a la baja de éste en el sistema. Una solicitud de este tipo puede tener los siguientes estados: pendiente de evaluación, pendiente de información, evaluada negativamente, evaluada positivamente, en proceso de reasignación, reasignado, desasignado pendiente de desvinculación, pendiente de evaluar condiciones, aceptado, rechazado y desvinculado. 2.1.4.3. Baja voluntaria El proceso se inicia cuando cualquier recurso de la empresa desea desvincularse de ésta. El Departamento de Operaciones informa al responsable del recurso de la desvinculación y se da de baja al recurso en el sistema. Una solicitud de este tipo puede tener los siguientes estados: pendiente de evaluación, pendiente de información, evaluada positivamente y desvinculado. 2.1.4.4. Cambio contractual El proceso se inicia cuando un responsable tiene la necesidad de realizar una revisión contractual de un recurso de su equipo de trabajo. El CEO de la compañía evaluará la situación y comunicará su decisión al solicitante y a los departamentos de Operaciones y Recursos Humanos. Una solicitud de este tipo puede tener los siguientes estados: pendiente 13 2.3 Diseño 2. Trabajo realizado sualizar los detalles de una celda dada de los anteriores y otro que muestre el gráco de barras junto a la tabla de cantidades. Para gestionar los permisos de los ltros medio y submedio, se creará una lista Sharepoint con las siguientes columnas destacables: Persona : Será de tipo persona e indicará el usuario al que se le asignan los permisos. Medios : Será de tipo datos externos y obtendrá los datos de la tabla de medios existente en SIIC. Submedios : Será de tipo datos externos y obtendrá los datos de la tabla de submedios existente en SIIC. En cuanto a la funcionalidad de reportes de un informe detallado, se generará una lista de reportes en la que cada ítem tendrá como adjunto un archivo Excel con los mismos datos que el usuario haya reportado. En cuanto al informe por horas, se crearán tres tipos de informe: general, detallado y gráco. Para mostrar ambos tipos de informe en el sitio web, se crearán dos páginas ASP.NET que ofrecerán las funcionalidades de cada uno de los informes por separado. 2.3.4. Procedimientos internos En este apartado se va a describir el comportamiento que debe tener cada uno de los procedimientos por separado, excepto, los procedimientos de asignación, desasignación y baja voluntaria ya que están muy ligados entre sí. En el anexo C se muestran los diagramas de ujo de cada uno de los procedimientos existentes. En el anexo D se pueden encontrar una serie de tablas que muestran el tipo de dato de cada uno de los campos de los diferentes archivos que participan en cada procedimientos. En el anexo E se muestran las alertas y efectos surgidos de los diferentes cambios de estado de cada tipo de solicitud. 20 2. Trabajo realizado 2.3 Diseño La generación de un código alfanumérico para distinguir a las diferentes solicitudes es un problema que aparece en todos los procedimientos. Por defecto, cada ítem de una lista/biblioteca tiene un campo llamado ID que es único y autoincremental. A priori, se podría utilizar este campo para generar el código como campo de tipo calculado, pero no se puede de forma directa porque el ID es asignado una vez el ítem ha sido ya creado. Para solucionar este inconveniente: Se hará uso de una columna intermedia, de tipo línea de texto y oculta, llamada Identicador que por defecto tendrá el valor Generando . Se creará un workow que hará la siguiente asignación: Item.Identicador:= Item.ID Este workow se ejecutará al crear un nuevo ítem en la lista. Código será un campo de tipo calculado que usará la columna intermedia, si ésta tiene el valor Generando sabremos que aún podemos generar el código. 2.3.4.1. Asignación de recursos / Desasignación de recursos / Baja voluntaria Tras revisar los documentos que participan en el proceso, se ha decidido que el único que seguirá existiendo será el Curriculum Vitae (CV). Los campos del resto de documentos serán columnas de listas/bibliotecas que serán cumplimentadas mediante el uso de formularios. Se crearán las siguientes listas en base a las relaciones que se muestran en la gura 2.5: Lista de bajas voluntarias: En el desplegable de un ítem, aparecerá una nueva acción que servirá para informar de la baja a sistemas. Esta acción nos mandará a un nuevo formulario de creación de un ítem de la lista bajas de sistemas, a este formulario se le pasará como parámetro el ID del ítem de baja voluntaria/desasignación. De esta forma, se creará una baja de sistemas que estará referenciada con su origen mediante una columna de búsqueda. Biblioteca de CV : Para facilitar la creación de entrevistas desde un CV, se creará una acción en la lista desplegable de cada ítem llamada entrevistar. Lista de entrevistas: Como una entrevista puede ser asignada a una solicitud de asignación que permita asignar una entrevista a una o varias solicitudes de asignación existentes. Se creará un evento que referencie la entrevista con las solicitudes de asignación seleccionadas. La lista poseerá una columna de tipo vericación que indicará la disponibilidad de ésta con el n de que no pueda ser asignada a ninguna otra solicitud de asignación. Lista de solicitudes de asignacion: Tendrá seis columnas de tipo búsqueda para gestionar entrevistas: candidatas externas, candidatas internas, validadas externas, 21 2.3 Diseño 2. Trabajo realizado validadas internas, seleccionada externa y seleccionada interna. Tendrá una acción en el despegable de un ítem que permita crear una solicitud de alta de sistemas. Lista de solicitudes de desasignación: Tendrá una columna de búsqueda para relacionar una solicitud de desasignación con una de asignación para el caso en el que se haya procedido a una reasignación interna. También tendrá dos columnas llamadas medio origen y medio destino para dejar constancia del cambio y una acción en el despegable de un ítem que permita crear una solicitud de baja de sistemas. Lista de bajas de sistemas: Tendrá una columna de tipo búsqueda que relacione un ítem con una solicitud de desasignación. Lista de altas de sistemas: Tendrá una columna de tipo búsqueda que relacione un ítem con una solicitud de asignación. Las columnas de búsqueda no aplican ltros, entonces una solicitud de asignación podrá validar de entre las candidatas alguna entrevista que posteriormente haya sido marcada como no disponible. Para solucionar este problema, se utilizará una característica implementada por Codeplex 1 que permitirá tener columnas de búsqueda que usen consultas para ltrar elementos 2 . Figura 2.5: Relaciones entre asignación, desasignación y baja voluntaria 2.3.4.2. Cambios contractuales Al eliminarse el único documento que participa, se ha decidido que se creará una lista de solicitudes de cambios contractuales en la que aparecerán los campos del documento como columnas de la lista. Este documento utiliza una hoja maestra oculta con salarios en función de la categoría seleccionada. Estos datos, son usados en algunas de las columnas calculadas de la lista de solicitudes de cambios contractuales. Esta información 1 https://www.codeplex.com 2 http://lteredlookup.codeplex.com/ 22 2. Trabajo realizado 2.3 Diseño debe seguir existiendo, por lo que deberá existir una lista que almacene la información de categoría/convenio. 2.3.4.3. Vacaciones Al eliminarse el único documento que participaba, se ha decidido que se creará una lista de solicitudes de vacaciones en la que aparecerán los campos del documento como columnas de la lista. 2.3.4.4. Gastos Al eliminarse el único documento que participaba, se ha decidido que se creará una lista de solicitudes de gastos en la que aparecerán los campos del documento como columnas de la lista. Un gasto tiene recibos asociados con el n de justicar dicho gasto, éstos aparecerán como archivos adjuntos de un gasto dado. En el documento aparecen sumatorios por categorías (gasolina, peaje...). Por defecto en Sharepoint, se puede activar la vista hoja de datos que muestra la lista con aspecto tabla excel y ofrece la posibilidad de mostrar los totales de cada una de las columnas. 2.3.5. Migración SEDA Tras examinar las páginas relevantes para la migración de SEDA, se ha decidido convertirlas en controles de usuario que puedan ser llamados desde diferentes páginas ASP.NET en Sharepoint. Para ello, se modicará el código necesario para su correcto funcionamiento, prestando especial atención a fragmentos de código en JavaScript que pueden ser críticos en un entorno Sharepoint. SEDA utiliza una biblioteca que actúa como capa intermedia entre la aplicación y las bases de datos SIIC y BDADN . Esta biblioteca será transformada en una dll a través de la cual se puedan utilizar los diferentes métodos implementados en ella. Se intentará conservar una interfaz lo más similar posible a la actual con el n de que sea lo más cercana al usuario. 23 2.4 Implementación 2. Trabajo realizado 2.4. Implementación En esta sección se citan y explican algunas de las funciones más representativas de la aplicación. En todos los componenetes se hace uso de la biblioteca ClosedXML 3 creada por Codeplex para el tratamiento de archivos Excel. Se ha descartado la biblioteca ocial de Microsoft porque para usarla es obligatorio que en el servidor esté instalado Microsoft Oce. 2.4.1. Obra en curso La función más representativa de este componente es aquella en la que se sube un archivo Excel que contiene la obra en curso a una biblioteca de documentos. Esta función se ejecuta con privilegios de administrador para evitar problemas de permisos. Para subir un archivo a una biblioteca de documentos, se debe convertir previamente el archivo a un array de bytes. Mediante el uso de HashTable se asignan los diferentes atributos que tendrá el ítem y por último, se agrega toda la información a la biblioteca. A continuación se muestra el fragmento de código de dicha función. using Microsoft.SharePoint; ... protected void UploadDocumentToSP(byte[] byt, String filename, int anyo, int mes){ try { SPSecurity.RunWithElevatedPrivileges(delegate(){ using (SPSite objSite = new SPSite(sp_site)){ using (SPWeb objWeb = objSite.OpenWeb(sp_sitio_excel)){ objWeb.AllowUnsafeUpdates = true; SPFolder mylibrary = objWeb.Folders[sp_biblio_produccion]; Hashtable properties = new Hashtable(); properties.Add("vti_title", Path.GetFileNameWithoutExtension(filename)); properties.Add("Estado","Pendiente"); properties.Add("Anyo", anyo); properties.Add("Mes", mes); mylibrary.Files.Add(filename, byt, properties, true); mylibrary.Update(); objWeb.AllowUnsafeUpdates = false; } } }); } catch (Exception ex){ LogError("UploadDocumentToSP:" + ex.Message + " - " + ex.StackTrace); } } 3 https://closedxml.codeplex.com 24 2. Trabajo realizado 2.4 Implementación 2.4.2. Ingresos y gastos En este componente, la función más representativa es aquella perteneciente al evento que consolida los datos en BDApuntes al agregar un archivo a la biblioteca de ingresos y gastos. Para ello, primero se guarda un archivo temporal con el contenido de los ingresos y gastos. Una vez guardado, se procede a la lectura de este y conversión en un DataTable para su posterior paso a BD. Por último, se borra el archivo temporal del servidor y se actualiza el ítem. using Microsoft.SharePoint; ... public override void ItemAdded(SPItemEventProperties properties){ base.ItemAdded(properties); EventFiringEnabled = false; try{ if (properties.ListItem != null){ SPListItem oItem = properties.ListItem; byte[] binFile = oItem.File.OpenBinary(); System.IO.Directory.CreateDirectory("C:/Temporales"); String ruta = "C:/Temporales/temporalAxapta.xlsx"; FileStream fstream = File.Create(ruta); fstream.Write(binFile, 0, binFile.Length); XLWorkbook libro = new XLWorkbook(fstream); fstream.Close(); File.Delete(ruta); Directory.Delete("C:/Temporales"); //Debo parsear para pasar a la tabla IXLRange rango = libro.Worksheet(1).RangeUsed(); DataTable tabla_Axapta = XLSXToTabla(libro, rango); //Se manda a BD bool hayError = false; String error = saveAxapta(tabla_Axapta, ref hayError); oItem["Info Error"] = error; oItem.Update(); } } catch (Exception ex){ LogError("ItemAdded:" + ex.Message + " - " + ex.StackTrace); } EventFiringEnabled = true; } 2.4.3. Informes La función más destacable para la gestión de informes sería aquella que carga los medios y submedios de un usuario para el caso de un informe de rentabilidad. Para ello se busca en la lista de permisos al usuario y en el caso de aparecer, se rellenan los listados con el contenido de las columnas de la lista referentes a los medios y submedios visibles por el usuario. Se aplican privilegios de administrador para evitar problemas. using Microsoft.SharePoint; 25 2.5 Vericación y validación 2. Trabajo realizado ... protected void LoadMediosSubmedios(){ try{ SPSecurity.RunWithElevatedPrivileges(delegate(){ using (SPSite objSite = new SPSite(sp_site)){ using (SPWeb objWeb = objSite.OpenWeb(sp_sitio_admin)){ objWeb.AllowUnsafeUpdates = true; String nombre_usuario = SPContext.Current.Web.CurrentUser.LoginName; SPList oList = objWeb.Lists[sp_lista_permisos]; SPQuery myQuery = new SPQuery(); myQuery.Query = "<Where>" +"<Eq>" +"<FieldRef Name=\"Persona\"/>" +"<Value Type=\"Text\">" + nombre_usuario + "</Value>" +"</Eq>" +"</Where>"; SPListItemCollection myItems = oList.GetItems(myQuery); if(myItems.Count==1){ SPListItem item = myItems[0]; String[] Medios = item["Medios"].ToString().Split(’;’); foreach (String Medio in Medios) if (Medio.Replace("#","") != null && Medio.Replace("#","") != "") ListaMedios.Items.Add(Medio.Replace("#","")); String[] Submedios = item["Submedios"].ToString().Split(’;’); foreach (String Submedio in Submedios) if (Submedio.Replace("#","") != null && Submedio.Replace("#","") != "") ListaSubmedios.Items.Add(Submedio.Replace("#","")); } objWeb.AllowUnsafeUpdates = false; } } }); } catch (Exception ex){ LogError("LoadMediosSubmedios: " + ex.Message + " - " + ex.StackTrace); } } 2.5. Vericación y validación En esta sección se van a explicar algunas de las pruebas realizadas más signicativas en el transcurso del proyecto. Cabe destacar, que aquellas pruebas que en un principio no se han realizado satisfactoriamente, se ha hecho todo lo posible por encontrar los errores hasta lograr realizarlas con éxito. 2.5.1. Pruebas unitarias Las pruebas unitarias se realizan sobre cada uno de los componentes del sistema por separado. Algunas de las más destacables se explican a continuación: Generar una obra en curso de enero a diciembre y comprobar que no hay error de overow en el número de columnas Rechazar varias obras en curso a la vez con el n de observar que no se sobrepasa ningún Timeout. Comprobación de los cálculos en la obra en curso y del uso de fórmulas excel. 26 2. Trabajo realizado 2.6 Resultado Final Consolidación correcta en BD para la obra en curso y para los ingresos y gastos. Creación de ofertas, acciones, clientes y su posterior modicación en SEDA (migrado). Comprobar los efectos en el informe de rentabilidad al asignar/desasignar permisos a un determinado usuario. Comprobar la generación correcta de un reporte de un informe de rentabilidad. 2.5.2. Pruebas de integración Este tipo de pruebas se realizan una vez se han integrado los componentes en el sistema. Algunas de las más destacables se explican a continuación: Creación en SEDA (migrado) de ofertas, facturaciones e incurridos y la posterior comprobación de la existencia de estos datos en la obra en curso al volver a generarla. Eliminación de las tablas tabHojaRentabilidad y tabAxapta para posteriormente ver los resultados presentados en la generación de informes. 2.6. Resultado Final En esta sección se muestran capturas de pantalla de la aplicación con el n de poder apreciar parte del trabajo desarrollado. En la gura 2.6 se puede observar una captura de pantalla de la biblioteca de documentos de obras en curso. En la gura 2.7 se puede visualizar una captura de pantalla de la lista de permisos para los informes de rentabilidad. En la gura 2.8 se puede apreciar una captura de pantalla de la generación de informes de rentabilidad. 27 2.6 Resultado Final 2. Trabajo realizado Figura 2.6: Captura de pantalla de la biblioteca Obra en Curso Figura 2.7: Captura de pantalla de la lista de permisos 28 2. Trabajo realizado 2.6 Resultado Final Figura 2.8: Captura de pantalla de la página de generación de informes de rentabilidad 29