Jairo Andrés Quevedo Bolívar Julián Esteban Cisneros Anteproyecto de grado para optar al título de: Ingeniero de Sistemas

Transcripción

1 Diseño e Implementación de una aplicación web para el registro de los datos de contacto de los servidores públicos de la Secretaría Distrital de Planeación. Jairo Andrés Quevedo Bolívar Julián Esteban Cisneros Anteproyecto de grado para optar al título de: Ingeniero de Sistemas UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2017

2 Contenido Capítulo I: introducción Capítulo II: formulación Antecedentes Descripción del problema Formulación de la pregunta central del trabajo Capítulo III: justificación Capítulo IV: objetivo general Capítulo V: objetivos específicos Capítulo VI: alcance Capítulo VII: marco referencial Capítulo VIII: marco tecnológico OpenLDAP Java Server Faces Capítulo IX: marco metodológico SCRUM Manifiesto Ágil Gestión de la evolución del proyecto Revisión de las Iteraciones Desarrollo incremental Auto-Organización Colaboración Capítulo X: recursos para el desarrollo del proyecto Capítulo XI: cronograma Capítulo XII: Implementación y desarrollo Fase de requerimientos Desarrollo de Ingeniería Definición de términos Fase de inicio... 26

3 Personas y roles de proyecto Fase de elaboración Elaboración sprint Descripción usuarios Definición de requerimientos Servicios de búsquedas Búsqueda por externos Funcionalidades del Directorio Activo de la SDP Importación Masiva Administración de funcionario Administración de externo Administración de campos secundarios Creación entidad Creación cargo Creación de Ubicación Creación de tipo de contrato Creación de dependencia Funcionalidades adicionales Funcionalidad de Navegación Integración con otros aplicativos Auditoría sobre la información del Sistema Requerimientos no funcionales Rendimiento Disponibilidad Seguridad Visualización Front End Entorno de aplicación Modelo de Negocio Diagrama de casos de uso Análisis funcional Registrar funcionario diagrama de estado... 55

4 Registrar externo diagrama de estado Importe masivo Modelo lógico Diccionario de datos Diagramas de paquetes Diagramas de clases Paquete model Paquete daos Paquete exportador Paquete utilidades Paquete mensajes Paquete controlador Especificaciones técnicas Patrones de diseño Dependencias librerías y frameworks Frameworks Librerías Base de datos Estrategias de pruebas Pruebas de unitarias Manual de usuario resumido Módulo de administración Crear funcionario Inactivar funcionario Crear externo Gestión de campos complementarios Crear entidad Crear dependencia Crear ubicación Módulo de búsquedas Búsqueda funcionario Exportar archivos... 80

5 Módulo para la administración de noticias y eventos Publicar noticia Módulo auditoría Capítulo XII: recomendaciones Capítulo XII: conclusiones REFERENCIAS... 87

6 Ilustraciones Ilustración 1 Cronograma de actividades Ilustración 2 Mockup Formulario búsqueda de servidores Ilustración 3 Mockup Resultado búsqueda funcionario Ilustración 4 Mockup Formulario búsqueda externos Ilustración 5 Mockup Resultado búsqueda externos Ilustración 6 Mockup Formulario importación masivo Ilustración 7 Mockup Formulario crear funcionario Ilustración 8 Mockup Formulario crear externo Ilustración 9 Mockup Formulario crear entidad Ilustración 10 Mockup Formulario crear cargo Ilustración 11 Mockup Formulario crear ubicación Ilustración 12 Mockup Formulario crear tipo de contrato Ilustración 13 Mockup Formulario crear dependencia Ilustración 14 División de paneles en ventana de Administrador Ilustración 15 Diagrama de casos de uso módulo funcionario Ilustración 16 Diagrama de casos de uso módulo administrador área de comunicaciones Ilustración 17Diagrama de casos de uso módulo administrador área de contratos Ilustración 18 Diagrama de casos de uso módulo administrador RRHH Ilustración 19 Diagrama de casos de uso módulo administrador general Ilustración 20 Diagrama de casos de uso para administrador general Ilustración 21 Diagrama de estado registrar funcionario Ilustración 22 Diagrama de estado registrar externo Ilustración 23 Diagrama de secuencia importe masivo Ilustración 24 Diagrama de secuencia acceso plataforma Ilustración 25 Modelo relacional Ilustración 26 Estructura de paquetes Ilustración 27 Diagrama de clases del paquete model Ilustración 28 Diagrama de clases del paquete daos Ilustración 29 Clase exportador Ilustración 30 Clase JSFUtil Ilustración 31 Clase mensajes Ilustración 32 Diagrama de clases del paquete controlador Ilustración 33 Ventana de autenticación Ilustración 34 Ventana para registrar funcionario Ilustración 35 Módulo completo de administración de funcionario Ilustración 36 Ventana editar funcionario Ilustración 37 Ventana para la creación de externo Ilustración 38 Módulo de administración externo Ilustración 39 Panel detalle externo... 76

7 Ilustración 40 Menú campos complementarios Ilustración 41 Ventana registrar entidad Ilustración 42 Modificar entidad Ilustración 43 Ventana registrar dependencias Ilustración 44 Mensaje de error crear dependencia Ilustración 45 Error de valores vacíos Ilustración 46 Modificar dependencia Ilustración 47 Ventana registrar ubicación Ilustración 48 Lista de ubicaciones Ilustración 49 Ventana búsqueda funcionario Ilustración 50 Listado resultado de búsqueda Ilustración 51 Resultado de búsqueda vacío Ilustración 52 Ventana exportar archivos Ilustración 53 Ventana módulo administración de noticias Ilustración 54 Ventana registrar noticia Ilustración 55 Editar noticia Ilustración 56 Ventana registros de auditoría Ilustración 57 Campos de búsquedas log de auditoría

8 Tablas Tabla 1 Presupuesto del proyecto Tabla 2 Definición de términos scrum Tabla 3 Personas y roles de proyecto Tabla 4 Sprint Tabla 5 Sprint Tabla 6 Sprint Tabla 7 Sprint Tabla 8 Sprint Tabla 9 Sprint Tabla 10 Sprint Tabla 11 Sprint Tabla 12 Sprint Tabla 13 Sprint Tabla 14 Sprint Tabla 15 Sprint Tabla 16 Sprint Tabla 17 Sprint Tabla 18 Sprint Tabla 19 Sprint Tabla 20 Sprint Tabla 21 Sprint Tabla 22 Sprint Tabla 23 Descripción de usuarios Tabla 24 Diagrama de proceso crear entidad Tabla 25 Diagrama de proceso crear cargo Tabla 26 Diagrama de proceso crear ubicación Tabla 27 Diagrama de proceso crear tipo de contrato Tabla 28 Diagrama de proceso crear dependencia Tabla 29 Diagrama de procesos funcionalidad de navegación Tabla 30 Uso del Directorio Activo para la aplicación Tabla 31 Tabla administrador Tabla 32 Tabla funcionario Tabla 33 Tabla externo Tabla 34 Tabla eventos Tabla 35 Tabla cargo Tabla 36 Tabla ubicación Tabla 37 Tabla entidad Tabla 38 Tabla dependencia Tabla 39 Tabla tipo contrato Tabla 40 Tabla log de auditoria... 61

9 Tabla 41 Detalle patrón dao Tabla 42 Detalle MVC Tabla 43 Detalle patrón fachada Tabla 44 Detalle JDK Tabla 45 Detalle JSF Tabla 46 Detalle librería primefaces Tabla 47 Detalle librería JasperReports Tabla 48 Detalle librería itext Tabla 49 Detalle librería Cupertino Tabla 50 Detalle driver JDBC Tabla 51 Pruebas de gestión de tablas básicas Tabla 52 Pruebas de gestión de noticias Tabla 53 Pruebas de gestión de noticias Tabla 54 Formato de direcciones... 77

10 Capítulo I: introducción Los sistemas de información de un negocio significan una gran inversión de tiempo, esfuerzo y dinero que se realizó al momento de su adquisición. Debido a que los negocios se encuentran en un ambiente competitivo, cambiante y conectado. Resulta fundamental para todas las organizaciones y más aún para las organizaciones con muchas dependencias que trabajan conjuntamente, tener una limitación clara y concisa que evite redundar esfuerzos (Fincham & Rhodes, 2005). Los sistemas de información ocupan un papel fundamental en la comunicación de las diferentes dependencias, no solo dentro sino fuera de la organización con entidades externas y las soluciones tecnológicas ayudan en gran medida a hacer esto posible. Un directorio interno se define como un repositorio virtual que le permite a los miembros internos (trabajadores o servidores públicos) a encontrar información de contacto (Nombres y apellidos del(a) servidor(a), ubicación funcional y dependencia a la que pertenece, extensión o teléfono, dirección de correo electrónico, fotografía). Este trabajo aportará a la implementación de las políticas de gobierno abierto, transparencia y participación (Concha & Naser, 2012). Inicialmente se busca mejorar los procesos de comunicación para los empleados directos o de planta y los externos, los contratistas quienes por medio de la aplicación podrán encontrar a un servidor de la secretaría distrital de planeación de una manera más sencilla y rápida. De esta manera sirve de base para sincronizar los procesos internos de la organización ahorrando tiempo en los trámites de comunicación (Ley 1712, 2014). La aplicación web Desarrollada se realizó siguiendo todas las etapas del ciclo de vida de un software, que comienza con el levantamiento de información continua con la toma de requerimientos, funcionales y no funcionales, luego el análisis y diseño de la aplicación, seguido de la implementación o desarrollo, dando paso a las pruebas y posterior puesta en marcha del sistema (Pow-Sang & Imbert,2004). Todo esto respaldado por una documentación dirigida a los diferentes interesados o stakeholders.

11 Capítulo II: formulación Antecedentes La secretaría de planeación distrital es una entidad pública que se encarga diseñar y liderar la planeación territorial, económica social y ambiental, y la articulación de las políticas públicas en la ciudad de Bogotá (Secretaria Distrital de Planeación,2017). Para dicho fin la SPD vive en una continua actualización de componentes tecnológicas (software y hardware). Uno de los muchos sistemas de información con los que cuenta esta es entidad es un software que fue desarrollado con el objetivo de registrar a todos los trabajadores de la entidad junto con sus datos principales de contacto. Esto orientado a agilizar los trámites de comunicación dentro y fuera de la entidad. Sin embargo, este software no se integró con los demás sistemas de manera exitosa debido a problemas de compatibilidad con navegadores web. Por esta razón se planea volver a desarrollar el proyecto bajo unos nuevos lineamientos tecnológicos como es la utilización de estándares para facilitar la interoperabilidad con sistemas internos. Descripción del problema Sumado al problema de la no utilización de estándares en la primera versión del software de directorios digitales, también manifiesta otro tipo de problemas relacionados con rendimiento, ya que los tiempos de consulta no son los óptimos y el modelo actual de la base de datos no está en tercera forma normal provocando una redundancia innecesaria. Por lo cual el actual motor de bases de datos presenta muchas fallas de seguridad y concurrencia, posee además una interfaz de usuario anticuada y difícil de interactuar para usuarios externos a la entidad. Sumado a esto la aplicación tienen el problema de no actualizar sus registros debido a no tener un componente o servicio web que pueda actualizar la base de datos esto se evidencia en consultas erróneas. Formulación de la pregunta central del trabajo Cuáles serían las decisiones arquitectónicas ideales para garantizar el cumplimiento de los requerimientos funcionales del software y además el mejoramiento de los inconvenientes anteriormente mencionados?

12 Capítulo III: justificación El desarrollo del módulo directorio activo es de gran ayuda para los lineamientos de trabajo cooperativo de la secretaría de planeación distrital, además es una muestra de las sofisticación que pueden tener los procesos cotidianos de la entidad por medio de soluciones tecnologías, todo esto es útil en cumplimiento de estándares de calidad implícitos en el proyecto que especifica criterios que pueden usarse para juzgar la operación de un sistema. La calidad de software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad (Lovelle, 1999). Si bien las necesidades de software en su gran mayoría son prioritarias y deben satisfacerse en el menor tiempo posible, no utilizar procedimientos, mejores prácticas o seguir algún lineamiento para la evaluación de procesos de calidad en los productos de software puede llevar a generar un producto con muy poco tiempo de vida y no lo suficientemente útil para la organización. Pocas son las que organizaciones que están certificadas o han identificado sus niveles de madurez y se han dado cuenta de la importancia que tiene el hecho de considerar este seguimiento y mejoras continuas en sus procesos de desarrollo. Para un director de TI y todo su equipo de trabajo, los sistemas de información deben estar en orden y bien documentados para futuras revisiones, y operaciones, que implica la creación, manejo y seguimiento de un sistema de información. Al día de hoy en las organizaciones es un problema el no cuantificar la cantidad de mantenimiento, nuevos trabajos o nuevas implementaciones se realizan producto del desarrollo de mala calidad, o no se mide el impacto de estos malos proyectos, muchas veces por querer dar una respuesta rápida las empresas se enfrentan más adelante a situaciones críticas como la inoperancia del sistema, el costo excesivo de licencias, la caducidad de las tecnologías utilizadas y la no disposición del software para su extensión por nombrar algunas(vega, Rivera & García, 2008).

13 Capítulo IV: objetivo general Desarrollar e Implementar una aplicación web para el registro de los datos de contacto de los funcionarios públicos de la secretaría distrital de planeación que permita gestionar la información de contactos.

14 Capítulo V: objetivos específicos Elaborar el análisis, diseño de la aplicación. Definición de requerimientos funcionales y no funcionales para la aplicación web de directorios activos. Desarrollar un software cliente que consuma los datos del directorio activo base de la organización para las actualizaciones. Desarrollar módulo que satisfaga requerimientos funcionales. Proponer componentes tecnológicos para cumplir con los requerimientos de calidad de la aplicación.

15 Capítulo VI: alcance Realizar un módulo web que se soporte en una base de datos con la información de contacto de los servidores o empleados de la secretaría de planeación distrital. Esta base de datos debe ser interoperable con el directorio activo (LDAP) que actualmente utiliza la Secretaría Distrital de Planeación, para obtener información del registro de los empleados. Además, tendrá dos tipos de usuarios, un administrador que pueda hacer modificaciones (crear, actualizar, eliminar, leer) de la información de cualquier empleado y otro usuario cliente que solo tendrá privilegios de lectura. Además, deberá permitir realizar consultas a todos los usuarios y tendrá la opción de generar Pdf s sobre dichas consultas.

16 Capítulo VII: marco referencial En 1933 se creó el Departamento de Urbanismo, primera entidad encargada de planear Bogotá, de plantear la legislación y todo lo relacionado con lo urbanístico de la ciudad. Posteriormente, se expidió el Decreto Ley 3133 de 1968 con el cual se modificó la denominación a Departamento administrativo de Planeación. Hoy, la Secretaría desarrolla funciones que apuntan a orientar y liderar la formulación y seguimiento de las políticas y la planeación territorial, económica, social y ambiental del Distrito Capital, juntamente con los demás sectores, de acuerdo al Decreto 16 de Entre las funciones principales que ejecuta la SDP está coordinar la elaboración, ejecución y seguimiento de los planes de desarrollo distrital y locales; coordinar la elaboración, reglamentación, ejecución y evaluación del Plan de Ordenamiento Territorial -POT-; al igual que la regulación del uso del suelo, de conformidad con la normativa que expida el Concejo Distrital y en concordancia con la normatividad nacional. El Área de Sistemas tiene una función transversal dentro de la institución y el módulo de software que se desarrollo tiene la función de ayudar a la comunicación interna de la SDP proporcionando información de contacto a todos los funcionarios.

17 Capítulo VIII: marco tecnológico La aplicación de la Secretaría Distrital de Planeación (SDP) cuyo objetivo es funcionar en diferentes exploradores de Internet de uso habitual en la Entidad (Chrome, Firefox, Explorer), para la búsqueda y ubicación de las personas que trabajan en la Secretaría. También realizar consulta del directorio de Servidores y Servidoras de la Secretaría Distrital de Planeación, mostrar el directorio de Servidores y Servidoras de la Secretaría. Y buscar personas por nombre o apellido. Este aplicativo fue realizado para la SDP en el año 2017 (Dirección de sistemas, 2016) OpenLDAP La arquitectura del servidor OpenLDAP estaba dividida entre un frontend que maneja el acceso a la red y el procesamiento de protocolos, y un backend que trata estrictamente con el almacenamiento de datos. [9] Este diseño partido era una característica del código original de la Universidad de Michigan escrito en 1996 y continuado en todos los lanzamientos subsecuentes de OpenLDAP. El código original incluía un backend de base de datos principal y dos backends experimentales / demo. La arquitectura es modular y muchos backends diferentes están ahora disponibles para la interconexión con otras tecnologías, no sólo las bases de datos tradicionales. En las primeras versiones los términos "backend" y "database" se usaban a menudo de forma intercambiable. Para ser exactos, un "backend" es una clase de interfaz de almacenamiento, y una "base de datos" es una instancia de un backend. El servidor slapd puede utilizar arbitrariamente muchos backends a la vez, y puede tener arbitrariamente muchas instancias de cada backend activas a la vez (The OpenLDAP Project, 2016) Java Server Faces JSF es un marco de trabajo para crear aplicaciones java J2EE basadas en el patrón MVC de tipo 1. JSF tiene como características principales: Utiliza páginas JSP para generar las vistas, añadiendo una biblioteca de etiquetas propia para crear los elementos de los formularios HTML(Oracle, 2013) Asocia a cada vista con formularios un conjunto de objetos java manejados por el controlador (managed beans) que facilitan la recogida, manipulación y visualización de los valores mostrados en los diferentes elementos de los formularios. Introduce una serie de etapas en el procesamiento de la petición, como por ejemplo la de validación, reconstrucción de la vista, recuperación de

18 los valores de los elementos, etc. Utiliza un sencillo fichero de configuración para el controlador en formato xml Es extensible, pudiendo crearse nuevos elementos de la interfaz o modificar los ya existentes. Y lo que es más importante: forma parte del estándar J2EE. En efecto, hay muchas alternativas para crear la capa de presentación y control de una aplicación web java, como Struts y otros frameworks, pero solo JSP forma parte del estándar. Normalmente las aplicaciones web se construyen como un conjunto de pantallas con las que va interactuando el usuario. Estas pantallas contienen textos, botones, imágenes, tablas y elementos de selección que el usuario modifica. Todos estos elementos están agrupados en formularios HTML, que es la manera en que las páginas web envían la información introducida por el usuario al servidor. La principal función del controlador JSF es asociar a las pantallas, clases java que recogen la información introducida y que disponen de métodos que responden a las acciones del usuario. JSF nos resuelve de manera muy sencilla y automática muchas tareas: Mostrar datos al usuario en cajas de texto y tablas. Recoger los datos introducidos por el usuario en los campos del formulario. Controlar el estado de los controles del formulario según el estado de la aplicación, activando, ocultando o añadiendo y eliminando controles y demás elementos Realizando validaciones y conversiones de los datos introducidos por el usuario Rellenando campos, listas, combos y otros elementos a medida que el usuario va interactuando con la pantalla Controlando los eventos que ocurren en los controles (pulsaciones de teclas, botones y movimientos del ratón). Las aplicaciones JSF están formadas por los siguientes elementos principales: Páginas JSP que incluyen los formularios JSF. Estas páginas generarán las vistas de la aplicación Beans java que se conectan con los formularios JSF Clases java para la lógica de negocio y utilidades. Ficheros de configuración, componentes a medida y otros elementos del framework. Resto de recursos de la aplicación web: recursos estáticos, javascript y otros elementos (Oracle, 2007) Capítulo IX: marco metodológico

19 SCRUM Scrum es un modelo de desarrollo ágil caracterizado por adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto. Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados. Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada. Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986) En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formación de scrum de los jugadores de Rugby, a raíz de lo cual quedó acuñado el término scrum para referirse a ella. Aunque esta forma de trabajo surgió en empresas de productos tecnológicos, es apropiada para proyectos con requisitos inestables y para los que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software. En 1995 Ken Schwaber presentó Scrum Development Process en OOPSLA 95 (Object-Oriented Programming Systems & Applications conference) (SCRUM Development Process), un marco de reglas para desarrollo de software, basado en los principios de scrum, y que él había empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation (compañía que en los macrojuegos de compras y fusiones, se integraría en VMARK, y luego en Informix y finalmente en Ascential Software Corporation). Manifiesto Ágil Se pone al descubierto mejores métodos para desarrollar software, haciendo y aportando a la realización y práctica de estos métodos. Con este trabajo se ha logrado valorar: - A los individuos y su interacción, por encima de los procesos y las herramientas. - El software que funciona, por encima de la documentación exhaustiva. - La colaboración con el cliente, por encima de la negociación contractual. - La respuesta al cambio, por encima del seguimiento de un plan. El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de Desarrollo (Development Team) y un Scrum Master. Los Equipos Scrum son auto-organizados y multifuncionales. Los equipos auto-organizados eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. Los equipos multifuncionales tienen todas las competencias

20 necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad. Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. Las entregas incrementales de producto Terminado aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto. Gestión de la evolución del proyecto Scrum maneja de forma empírica la evolución del proyecto con las siguientes tácticas: Revisión de las Iteraciones Al finalizar cada sprint se revisa funcionalmente el resultado, con todos los implicados en el proyecto. Es por tanto la duración del sprint, el período de tiempo máximo para descubrir planteamientos erróneos, mejorables o malinterpretaciones en las funcionalidades del producto. Desarrollo incremental No se trabaja con diseños o abstracciones durante toda la construcción del producto. El desarrollo incremental ofrece al final de cada iteración una parte de producto operativa, que se puede usar, inspeccionar y evaluar. Scrum resulta adecuado en proyectos con requisitos inciertos y, o inestables. Por qué predecir la versión definitiva de algo que va a estar evolucionando de forma continua? scrum considera a la inestabilidad como una premisa, y adopta técnicas de trabajo para facilitar la evolución sin degradar la calidad de la arquitectura y permitir que también evolucione durante el desarrollo. Durante la construcción se depura el diseño y la arquitectura, y no se cierran en una primera fase del proyecto. Las distintas fases que el desarrollo en cascada realiza de forma secuencial, en scrum se solapan y realizan de forma continua y simultánea. Auto-Organización Son muchos los factores impredecibles en un proyecto. La gestión predictiva asigna al rol de gestor del proyecto la responsabilidad de su gestión y resolución. En scrum los equipos son auto-organizados, con un margen de maniobra suficiente para tomar las decisiones que consideren oportunas. Colaboración Es un componente importante y necesario para que a través de la autoorganización se pueda gestionar con solvencia la labor que de otra forma realizaría un gestor de proyectos. Todos los miembros del equipo colaboran de forma abierta con los demás, según sus capacidades y no según su rol o su puesto (Palacio, 2014).

21 Capítulo X: recursos para el desarrollo del proyecto En la siguiente tabla se describen los aspectos de financiación y costos del proyecto.

22 ELEMENTO PRECIO DESCRIPCIÓN ASUMIDO POR Hardware Computa portátil $ Ninguna Estudiante Computa portátil $ Ninguna Estudiante Sub-total $ Software Enterprise Architect $ 0 Herramienta de modelado UML (Versión de Prueba) Estudiante IDE de desarrollo Desconocido Licencia EPL Secretaria de Planeación Distrital SQL developer Desconocido Herramienta visual de diseño para bases de datos Secretaria de Planeación Distrital Java Primefaces Desconocido Secretaria de Planeación Distrital Sub-total $ 0 Tabla 1 Presupuesto del proyecto Capítulo XI: cronograma El cronograma para el desarrollo de este proyecto se divide en las fases propuestas por el marco de la metodología ágil. Cada fase contiene un conjunto

23 de tareas a realizar en los tiempos estipulados en el cronograma. Ilustración 1 Cronograma de actividades Capítulo XII: Implementación y desarrollo

24 Fase de requerimientos Este componente describe la fase de análisis de requerimientos desarrollados a lo largo de la pasantía. Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. Un análisis adecuado de requerimientos no debe ser visto como una pérdida de tiempo y esfuerzo sino por el contrario es un factor decisivo a la hora de tener proyecto exitoso definido por tiempo y cumplimiento de las expectativas del usuario. Puntualmente la secretaria de planeación distrital en su primer intento por implementar una aplicación para el manejo de datos de contacto no tuvo en cuenta a la hora de definir la arquitectura, requerimientos no funcionales tal como la visualización de dicha aplicación web en todos los navegadores web y terminó fracasando el proyecto resultando y terminó menos costoso iniciar uno nuevo que modificar el que ya existía. Desarrollo de Ingeniería Para el seguimiento del proyecto se definió la metodología ágil scrum, que se puede catalogar como un conjunto de buenas prácticas para trabajar colaborativamente, en equipo. Con la intención de garantizar de alguna manera la ejecución exitosa del proyecto. Inicialmente se definió los roles y conceptos descritos por scrum para la interacción entre los diferentes agentes de la metodología. Luego las iteraciones de los entregables y la participación de los involucrados e interesados. Cabe resaltar que esto es una interpretación de la metodología y no va ceñido al pie de la letra, la razón principal es que scrum se adapta a proyectos más grandes y complejos donde hay un grupo más alto de involucrado e interesados dónde se necesita dar resultados de manera ágil.

25 Definición de términos Sprint Concepto Especulación Exploración Revisión Cierre Reuniones Backlog Scrum master Son Iteraciones o entregas del producto. Forma general de las características del proyecto. Desarrollar y revisar los requerimientos generales. Mantener la lista de las funcionalidades que se esperan. Se establecen las fechas de las nuevas entregas y las iteraciones. Se incrementa el producto en el que se añaden las funcionalidades de la fase de especulación. El equipo revisa todo lo que se ha construido y se contrasta con el objetivo deseado. Se entrega en una fecha deseada una versión. Planificación del backlog. Seguimiento del sprint. Revisión del sprint. Revisión del incremento generado se presenta un demo para la retro alimentación con el cliente. Es una lista ordenada de todo el trabajo pendiente. En una pila organizado por su prioridad. Es el encargado de comprobar que funciona el modelo y la metodología. Gestor de Producto Es el encargado de lleva el control y registro en la lista de pila del producto de las historias de usuario que definen el sistema. Pila sprint Tabla 2 Definición de términos scrum Es el documento de registro de los requisitos detallados o tareas que va a desarrollar el equipo técnico en la iteración (actual o que está preparándose para comenzar)

26 Fase de inicio Personas y roles de proyecto Persona Contacto Rol Víctor Manuel vgutierrez@sdp.gov.co Coordinador, Scrum Gutiérrez Campos Manager María Teresa Stackholder y Gestor Gonzáles Bejarano mtgonzalezb@gmail.com de Producto Julián Esteban julianesteban2p21@gmail. Cisneros com Jairo Andrés jandres.diez@gmal.com Quevedo Bolívar Tabla 3 Personas y roles de proyecto Team Team Fase de elaboración Backlog ID HT1 Elaboración sprint Tarea Tipo Estado Responsable Definición de modelo de datos Análisis Completo Jairo Andrés Quevedo Bolívar Julián Cisneros Duración Prioridad Realimentación Autorizado por 1 semanas Alta Corrección modelo Tabla 4 Sprint 0 (Definición de cardinalidad entre entidades) Víctor Manuel Gutiérrez Campos Backlog ID Tarea Tipo Estado Responsable

27 HT2 Mapeo de tablas (Incluir operaciones crud ) Duración Prioridad 1 semanas Tabla 5 Sprint 1 Alta Desarrollo Completo Jairo Andrés Quevedo Bolívar Julián Cisneros Realimentación Autorizado Validaciones del cliente y servidor por Víctor Manuel Gutiérrez Campos Backlog ID HT2-1 Tarea Tipo Estado Responsable Crud noticias Validar reglas fecha inicial final de evento Frontend Incremento - HT1 Completo Duración Prioridad Realimentación Autorizado por 1 semanas Media Deshabilitar textfield fechas Tabla 6 Sprint 2 Víctor Manuel Gutiérrez Campos Jairo Andrés Quevedo Bolívar Backlog ID Tarea Tipo Estado Responsable

28 HT3 Realización búsquedas de funcionarios y externos Duración Prioridad 1 semanas Tabla 7 Sprint 3 Baja Desarrollo Completo Julián Cisneros Realimentación Autorizado por Limpia botones Víctor de selección Manuel Gutiérrez Campos Backlog ID HT2-2 Tarea Tipo Estado Responsable Crud dependencias Establecer árbol de dependencias Duración Prioridad 1 semanas Tabla 8 Sprint 4 Media Desarrollo Incremento HT2 Completo Realimentación Autorizado por Corregir niveles Víctor árbol de Manuel dependencia, Gutiérrez puede ser mayor Campos de 2 Jairo Andrés Quevedo Bolívar Backlog ID HT3-1 Tarea Tipo Estado Responsable Exportar listados de búsquedas Duración Prioridad 1 semanas Tabla 9 Sprint Desarrollo Incremento HT3 Medio Estado por defecto de listas por exportar Completo Realimentación Autorizado por Víctor Manuel Gutiérrez Campos Julián Cisneros Backlog ID Tarea Tipo Estado Responsable

29 HT2-3 Crud entidad Definir formato de direcciones Duración Prioridad 1 semanas Tabla 10 Sprint 6 Media Desarrollo Incremento HT2 Completo Realimentación Autorizado por Víctor Manuel Gutiérrez Campos Jairo Andrés Quevedo Bolívar Backlog ID HT2-4 Tarea Tipo Estado Responsable Crud Ubicación Definición parametrización ubicación Duración Prioridad 1 semanas Tabla 11 Sprint 7 Media Desarrollo Incremento HT2 Completo Realimentación Autorizado por Víctor Manuel Gutiérrez Campos Jairo Andrés Quevedo Bolívar Backlog ID HT4 Tarea Tipo Estado Responsable Implementar Crud funcionario Duración Prioridad 2 semanas Tabla 12 Sprint Medio Desarrollo Completo Julián Cisneros Realimentación Autorizado por Guardar foto de Víctor funcionario Manuel como un blob en Gutiérrez la bd Campos

30 Backlog ID HT2-4 Tarea Tipo Estado Responsable Crud Sector Definir planos imágenes Diseño Incremento HT2 Completo Duración Prioridad Realimentación Autorizado por 0.5 Medio semanas Tabla 13 Sprint 9 Víctor Manuel Gutiérrez Campos Jairo Andrés Quevedo Bolívar Backlog ID HT4-1 Tarea Tipo Estado Responsable Implementar Crud externo Duración Prioridad 2 semanas Tabla 14 Sprint 10 Desarrollo Incremento HT3 Medio Mensaje de confirmar Borrado Completo Realimentación Autorizado por Víctor Manuel Gutiérrez Campos Julián Cisneros Backlog ID HT2-5 Tarea Tipo Estado Responsable Crud Cargo Caracteres alfanuméricos Validar duplicidad Duración Prioridad 0.5 semanas Tabla 15 Sprint 11 Medio Desarrollo Incremento HT2 Completo Realimentación Autorizado por Aplicar para los Víctor demás campos Manuel secundarios Gutiérrez Campos Jairo Andrés Quevedo Bolívar

31 Backlog ID HT2-1 Tarea Tipo Estado Responsable Crud noticias Validar reglas fecha inicial final de evento Frontend Incremento - HT1 Completo Duración Prioridad Realimentación Autorizado por 1 semanas Media Deshabilitar textfield fechas Tabla 16 Sprint 12 Víctor Manuel Gutiérrez Campos Jairo Andrés Quevedo Bolívar Backlog ID HT5 Tarea Tipo Estado Responsable Login Administrativos Duración Prioridad 0.5 semanas Tabla 17 Sprint 13 Diseño Completo Víctor Manuel Gutiérrez Campos Realimentación Autorizado por alto Aplicar estilos Víctor Manuel Gutiérrez Campos Backlog Tarea Tipo Estado Responsable ID HT6 Implementar Desarrollo Completo Julián log de Cisneros auditoria Duración Prioridad Realimentación Autorizado por 2 semanas Tabla 18 Sprint 14 alto Manejarlo sin triggers a nivel de sesiones Víctor Manuel Gutiérrez Campos

32 Backlog ID HT7 Tarea Tipo Estado Responsable Conectar directorio activo Desarrollo Completo Víctor Manuel Gutiérrez Campos Duración Prioridad Realimentación Autorizado por 1 alto semanas Tabla 19 Sprint 15 Víctor Manuel Gutiérrez Campos Backlog Tarea Tipo Estado Responsable ID HT8 Lista de Frontend Completo Jairo Andrés mensajes para mostrar Quevedo Bolívar Julián en el Cisneros frontend Duración Prioridad Realimentación Autorizado por 1 semanas alto Víctor Manuel Gutiérrez Campos Tabla 20 Sprint 16 Backlog ID HT9 Tarea Tipo Estado Responsable Desarrollo frontend todas las paginas Duración Prioridad 4 semanas Tabla 21 Sprint 17 alto Frontend Completo Jairo Andrés Quevedo Bolívar Julián Cisneros Realimentación Autorizado Utilizar librerías de primefaces por Víctor Manuel Gutiérrez Campos

33 Backlog ID HT10 Tarea Tipo Estado Responsable Manejo de sesiones Desarrollo Completo Víctor Manuel Gutiérrez Campos Duración Prioridad Realimentación Autorizado por 2 alto semanas Tabla 22 Sprint 18 Víctor Manuel Gutiérrez Campos

34 Descripción usuarios En la tabla 23 se observa los tipos de usuarios que van a interactuar con el sistema y qué permisos y actividades tiene en él Perfil Responsabilidades Perfil Responsabilidades Perfil Responsabilidades Perfil Responsabilidades Perfil Responsabilidades Administrador General Consulta de listado de funcionarios, extensiones, Ubicación funcional y Ubicación física de la Secretaría Distrital de Planeación. Actualización, eliminación, modificación e inclusión de toda la información en el directorio. Administrador Área Comunicaciones Consulta de listado de funcionarios, extensiones, Ubicación funcional y Ubicación física de la Secretaría Distrital de Planeación. Creación y Edición de Noticias. Administrador Área Contratos Consulta de listado de funcionarios, extensiones, Ubicación funcional y Ubicación física de la Secretaría Distrital de Planeación. Creación y Edición de Registros de Servidor Interno. Administrador Área Recursos Humanos Consulta de listado de funcionarios, extensiones, Ubicación funcional y Ubicación física de la Secretaría Distrital de Planeación. Creación y Edición de Registros de Servidor Interno y Externo. Funcionario SDP Consulta de listado de funcionarios, extensiones, Ubicación funcional y Ubicación física de la Secretaría Distrital de Planeación. Tabla 23 Descripción de usuarios

35 Definición de requerimientos Se requiere de un aplicativo Directorio de Servidores(as) de la Secretaría Distrital de Planeación (SDP) que funcione en diferentes exploradores de Internet de uso habitual en la Entidad (Chrome, Firefox, Explorer) dentro de la intranet de la SDP, para la búsqueda y Ubicación de las personas que trabajan en la Secretaría. La aplicación permite la administración del directorio de Servidores y Servidoras de la Secretaría Distrital de Planeación con la siguiente información: 1. Nombres y apellidos del(a) Servidor(a) 2. Extensión o teléfono 3. Correo Institucional 4. Ubicación 5. Dependencia a la que pertenezca 6. Sector (Mapa con Ubicación física) 7. Fotografía 8. Género 9. Fecha de Cumpleaños Para Registros de personas en Funcionarios Externos 1. Nombres y apellidos del representante legal 2. Tratamiento 3. Conmutador 4. Horario 5. Entidad 6. Cargo 7. Teléfono 8. Fax 9. Correo institucional Servicios de búsquedas La aplicación debe permitir la búsqueda de funcionarios por nombre, apellido, dependencia y ubicación (edificio y piso) para los Servidores; y nombre, apellido, entidad, cargo para los representantes de las entidades externas. Además de poder exportarlas en formatos: pdf, xml, xls y csv.

36 Búsqueda por funcionarios La aplicación debe permitir seleccionar a los servidores de la SDP por: - Nombre de la dependencia - Ubicación (Nombre del edificio + Piso) Ilustración 2 Mockup Formulario búsqueda de servidores Ilustración 3 Mockup Resultado búsqueda funcionario Búsqueda por externos La aplicación debe permitir seleccionar a los contactos externos por: - Entidad - Cargo

37 Ilustración 4 Mockup Formulario búsqueda externos Ilustración 5 Mockup Resultado búsqueda externos Funcionalidades del Directorio Activo de la SDP LDAP son las siglas de Lightweight Directory Access Protocol (en español Protocolo Ligero de Acceso a Directorios). Hace referencia a un protocolo a nivel de aplicación el cual permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también es considerado una base de datos a la que se puede realizar consultas. Habitualmente, almacena la información de autenticación (usuario y contraseña) y es utilizado para autenticarse, aunque es posible almacenar otra información (datos de contacto del usuario, ubicación de diversos recursos de la red, permisos, certificados, etc). A manera de síntesis, LDAP es un protocolo de acceso unificado a un conjunto de información sobre una red.

38 La aplicación debe conectarse con dicho directorio y traer los datos básicos de contacto, con el propósito de hacer actualizaciones permanentes en la base de datos de la aplicación sin mayor esfuerzo. Importación Masiva Es posible realizar un cargue masivo, de los contactos Ilustración 6 Mockup Formulario importación masivo Administración de funcionario La aplicación debe permitir la administración de información de un funcionario, entiéndase por funcionario de la secretaria de planeación distrital a él empleado que tiene un contrato activo con la entidad. Crear funcionario: Sólo el administrador puede crear un funcionario, los datos que se necesitan guardar son: número de Cedula, apellido, extensión de teléfono, fecha de nacimiento, correo institucional, tipo de contrato, estado de contrato, genero, dependencia donde trabaja, ubicación representada en edificio y piso, fotografía y sector. Editar funcionario: Para la edición el administrador puede cambiar todos los cambios ingresados en la creación de un funcionario. Borrar funcionario; Se debe aplicar un borrado lógico a un funcionario más no físico, lo que quiere decir en sólo cambiar el estado de funcionario a inactivo. Esto con el propósito de perder reintegrarlo fácilmente si un funcionario tiene un retiro temporal de la entidad.

39 Ilustración 7 Mockup Formulario crear funcionario Administración de externo Este módulo facilita la administración de información de un externo, entiéndase por externo un empleado de una empresa o entidad que tiene permanente contacto con los funcionarios de la SDP y se necesita almacenar sus datos de contacto. Crear externo: Sólo el administrador puede crear un externo, los datos que se necesitan guardar son tratamiento, nombre apellido conmutador, horario, teléfono, estado, fax, correo externo. seleccionar cargo y seleccionar entidad Editar externo: Para la edición el administrador puede cambiar todos los cambios ingresados en la creación de un externo. Borrar externo; Se debe aplicar un borrado físico a un externo.

40 Ilustración 8 Mockup Formulario crear externo Administración de campos secundarios El administrador utiliza los campos secundarios o complementarios, para darle valores de integridad a los registros principales, funcionario y externo. Creación entidad Un externo debe tener una entidad a la cual representa y en la entidad se deben guardar: el nombre y dirección de la entidad. ENTRADA El Administrador debe llenar los campos entidad en caso de crear una nueva entidad detalla en el nombre PROCESO 1.La aplicación confirma que la entidad no exista o no se haya registrado 2. La aplicación crea la nueva entidad en la base de datos. SALIDA Mensaje de confirmación exitoso o de error en caso de mal diligenciamiento de los campos o error de conexión con la base de datos. Tabla 24 Diagrama de proceso crear entidad

41 . Ilustración 9 Mockup Formulario crear entidad Creación cargo El administrador debe poder agregar y administrar (crear, editar y borrar) un cargo a un externo. Entiéndase por cargo a la responsabilidad o función que tiene un externo en una organización. Para guardar un cargo basta con ingresar el nombre del cargo. ENTRADA PROCESO SALIDA Tabla 25 Diagrama de proceso crear cargo El Administrador debe llenar los campos Ubicación en caso de crear una nueva ubicación detalla en el nombre del cargo 1.La aplicación confirma cargo no exista o no se haya registrado 2.La aplicación crea el cargo en la base de datos. Mensaje de confirmación exitoso o de error en caso de mal diligenciamiento de los campos o error de conexión con la base de datos.

42 Ilustración 10 Mockup Formulario crear cargo Creación de Ubicación La aplicación debe relacionar un funcionario con un espacio físico permanente, para ello debe administrarse un dato secundario de ubicación organizado en dos partes: (Nombre edificio y piso). ENTRADA PROCESO SALIDA El Administrador debe llenar los campos Ubicación en caso de crear una nueva ubicación detalla en el nombre de la sede y el piso. 1.La aplicación confirma que el tipo de contrato no exista. 2.La aplicación crea La Dependencia en la base de datos. Mensaje de confirmación exitoso o de error en caso de mal diligenciamiento de los campos o error de conexión con la base de datos.

43 Tabla 26 Diagrama de proceso crear ubicación Ilustración 11 Mockup Formulario crear ubicación Creación de tipo de contrato El Administrador debe llenar el campo nombre contrato para crear un nuevo Contrato y este se relaciona con un funcionario. ENTRADA El Administrador debe llenar los campos nombre contrato en caso de crear un nuevo tipo de contrato. PROCESO 1.La aplicación confirma que el tipo de contrato no exista. 2.La aplicación crea La Dependencia en la base de datos. SALIDA Mensaje de confirmación exitoso o de error en caso de mal diligenciamiento de los campos o error de conexión con la base de datos. Tabla 27 Diagrama de proceso crear tipo de contrato

44 Ilustración 12 Mockup Formulario crear tipo de contrato Creación de dependencia ENTRADA El Administrador debe llenar los campos Nombre Dependencia y Seleccionar Dependencia Padre en caso de querer crear una Sub-Dependencia, para crear una nueva Dependencia PROCESO 1.La aplicación confirma que la Dependencia ya no exista. 2.La aplicación crea La Dependencia en la base de datos. SALIDA Mensaje de confirmación exitoso o de error en caso de mal diligenciamiento de los campos o error de conexión con la base de datos. Tabla 28 Diagrama de proceso crear dependencia

45 Ilustración 13 Mockup Formulario crear dependencia Funcionalidades adicionales 1. La aplicación debe tener una ventana con la información de cumpleaños de los servidores de la SDP, allí se puede ver los cumpleaños próximos y realizar búsquedas de los cumpleaños por intervalos a lo largo del año entre los servidores con estado activo (campo sólo modificable por el administrador) además de tener acceso rápido a los cumpleaños de cada mes. 2. Botones de navegación para exploración de listados de búsqueda encontrados (primero, anterior, siguiente, último) 3. Conversión de listas de búsquedas a archivos de extensiones.pdf,.xlsx, y csv. Estas listas son el resultado de la búsqueda por funcionario y por externos.

46 4. Mostrar al inicio Cumpleaños y Noticias del Día previamente cargados por el Administrador. 5. La Aplicación debe enviar un correo de felicitación de Cumpleaños vía correo Institucional. 6. Debe incorporar un módulo de noticias, destinado a la publicación y difusión de noticias de interés no mayor a 300 caracteres a todos los usuarios finales de la aplicación. Funcionalidad de Navegación ENTRADA PROCESO SALIDA Botones de navegación regresar a primer listado, ir al último listado, saltar al siguiente listado de registros, regresar al listado anterior Navegar entre listados encontrados Según listado seleccionado, permite navegar entre el los (primero, último, siguiente, anterior) Tabla 29 Diagrama de procesos funcionalidad de navegación Integración con otros aplicativos La aplicación debe poder realizar una conexión para consultar información del directorio activo de la SDP con el fin de facilitar la creación de un Servidor en la aplicación. Ver tabla 30. Cuándo se necesita? En el aplicativo (consumidor) se recurre al aplicativo (proveedor) en busca de (datos) con el fin de (acción) Ocasionalmente En los casos de Uso creación de Usuario e Importación de datos Masivos Directorio Activo Número de cédula Validar y extraer datos Datos básicos de Identificación del Usuario. (Nombres Apellidos, Correo Electrónico, extensión) generando en el aplicativo consumidor generando en el aplicativo proveedor Ningún Cambio Tabla 30 Uso del Directorio Activo para la aplicación.

47 Auditoría sobre la información del Sistema Se debe implementar el registro de acciones realizadas por los usuarios a las principales transacciones: persona, acción, fecha y hora y los registros del sistema en lo relacionado con la creación, modificación y eliminación. De igual manera se debe disponer de la administración de estos logs y poderlos visualizar por el administrador. Requerimientos no funcionales Rendimiento El tiempo de respuesta promedio para la navegación entre las páginas, realizar inserciones de datos, ediciones y cambios de estado de registros, debe ser menor o igual a 3 segundos. Disponibilidad Alta Disponibilidad. El Sistema debe estar disponible el 98% del tiempo en el primer año y el 99.5% de ahí en adelante. Seguridad El sistema debe permitir por usuario por lo menos una sesión abierta. Visualización La apariencia debe ser simple, de fácil lectura, comprensible, el texto debe poder ser seleccionado y copiado, logos actualizados. Front End (Look and Field) La aplicación debe presentarse según la siguiente distribución: Área 1: Botones de Administración Área 2: Selección tipo de Búsqueda Área 3: Búsqueda. Área 4: Cumpleaños Área 5: Información de Contacto Área 6: Resultado de Búsqueda Área 7: Botones de Exportación y desactivación de Contactos. Área 8. Botones de navegación en listado de búsqueda.

48 Ilustración 14 División de paneles en ventana de Administrador Entorno de aplicación 1. Entorno web, acceso mediante intranet. Consulta de contactos y Ubicación física de funcionarios de la SDP. 2. Periodicidad de las operaciones realizadas (frecuencia de uso) 3. Consulta permanente de la información contenida en el Directorio 4. Número de usuarios concurrentes: indeterminado. 5. Se estima que podría darse el caso que se tenga concurrencia máxima de hasta 700 consultas. 6. Crecimiento proyectado de la información: según número de funcionarios(as) (planta, temporales y contratistas) que hagan parte de la entidad, bajo.

49 Modelo de Negocio. Existen 5 tipos de usuarios, con sus respectivos permisos dentro del software. Ilustración 15 Diagrama de casos de uso módulo funcionario Funcionario: Es el servidor promedio de la SDP su interés en el software radica en ser capaz de buscar rápidamente a otros funcionarios internos y externos para consultar información almacenada en el sistema como fecha de cumpleaños, teléfono, correo institucional etc. También es posible exportar las listas de búsqueda y consultar las noticias a fines a la institución. Administrador Área Comunicaciones: Su interés en el software radica en ser capaz de Administrar Noticias Importantes en la SDP, además de los permisos de Búsqueda y Exportación de funcionarios Internos y Externos.

50 Ilustración 16 Diagrama de casos de uso módulo administrador área de comunicaciones Administrador Área Contratos: Su interés en el software radica en la gestión de funcionarios Internos (que pertenecen a la SDP) y por extensión de las tablas básicas que pertenecen al funcionario, que son: Tipos de Contratos, Dependencias, Sectores y Ubicaciones.

51 Ilustración 17Diagrama de casos de uso módulo administrador área de contratos Administrador Área de Recursos Humanos: Su interés en el software radica en la gestión de funcionarios Internos y También de la gestión de Externos a la entidad, por lo tanto, también puede gestionar las tablas básicas de Entidad, Cargo, Dependencia, Tipo de Contrato, Sector y Ubicación.

52 Ilustración 18 Diagrama de casos de uso módulo administrador RRHH Administrador General: Tiene acceso a todos los componentes del software que son: Gestión de Funcionario Interno y Externo como de las tablas básicas: Tipo de Contrato, Dependencia, Sector, Ubicación, Cargo y Entidad, También puede gestionar la tabla de noticias, Realizar importación Múltiple de Funcionarios Internos a partir de LDAP el directorio activo de la SDP y tiene acceso de solo lectura a los Logs del sistema que es donde se consignan los registros de Creación, Modificación y Borrado que haya realizado cualquier Administrador.

53 Ilustración 19 Diagrama de casos de uso módulo administrador general

54 Diagrama de casos de uso Ilustración 20 Diagrama de casos de uso para administrador general

55 Análisis funcional Registrar funcionario diagrama de estado El flujo de datos para el caso de uso registrar funcionario es el siguiente: 1. Verificar si el funcionario está en el directorio activo e importarlo. 2. Agregar datos particulares del funcionario. 3. Agregar dependencia 4. Agregar ubicación 5. Agregar sector 6. Finalmente guardar los datos Ilustración 21 Diagrama de estado registrar funcionario Registrar externo diagrama de estado El flujo de datos para el caso de uso registrar funcionario es el siguiente. 1. Agregar datos particulares del externo 2. Agregar cargo 3. Agregar entidad 4. Finalmente guardar los datos. Ilustración 22 Diagrama de estado registrar externo

56 Importe masivo Para realizar el importe masivo la aplicación debe comunicarse con el directorio activo de la SPD. Estas actualizaciones se harán manualmente y cuando el administrador lo considere necesario. Ilustración 23 Diagrama de secuencia importe masivo Acceso a la plataforma Para el acceso a la plataforma para usuarios que no son administradores, definidos como usuarios de consulta no necesita autenticación. Los datos de sesión se toman por el directorio activo. Mientras que los administradores si deben autenticarse para acceder a sus respectivos módulos.

57 Ilustración 24 Diagrama de secuencia acceso plataforma

58 Modelo lógico El modelo relacional formulado para la implementación y desarrollo de la aplicación. Ilustración 25 Modelo relacional Diccionario de datos El diccionario de datos tiene como función la descripción del modelo lógico relacional planteado. La tabla administradores es dónde se guardan las credenciales de los diferentes roles para los administradores. Los usuarios no administradores no necesitan tener un usuario ni contraseña debido a que su sesión se crea en el directorio activo. Datos de Entrada Nombre Tipo Campo Dato de Longitud / Obligatoried Descripción Formato ad user varchar 45 Si Nombre de usuario password varchar 45 Si Tabla 31 Tabla administrador

59 Nombre Campo Tipo de Dato Longi tud / Form ato Obligator iedad Descripción Cedula varchar 45 N/A Dato que se obtiene del LADP Funcionario_nom bre varchar 45 N/A Nombres del funcionario completos Funcionario_Apell idos varchar 45 N/A Apellidos del funcionario completos Funcionario_exte Número telefónico interno a la red de la Int N/A nsion entidad Funcionario_gene ro char 2 N/A F/ M / O Funcionario_Corr eo varchar 45 N/A Correo institucional del funcionario Id_ubicación int 11 N/A Hace referencia a la tabla ubicación Id_dependencia int 11 N/A Hace referencia a la tabla dependencia Id_sector int 11 N/A Ruta para una imagen sector (plano de la entidad) Id_tipo_contrato Int 11 N/A Hace referencia a la tabla sector Fecha nacimiento de date N/A N/A Funcionario_foto blob N/A N/A Boolea Estado n Tabla 32 Tabla funcionario 1 Si Almacena una imagen que representa la foto del funcionario Valor lógico representado para eliminar de manera lógica a un funcionario. Nombre Campo Tipo de Dato Longitud / Formato Obligatoriedad Descripción externo_correo varchar 45 Correo institucional del externo externo_nombre varchar 45 N/A Nombres del externo completos externo_apellidos varchar 45 N/A Apellidos del externo completos externo_tratamiento varchar 45 N/A Anteposición al nombre: Sr, Sra, Ing, Dr conmutador Int 10 N/A Numero de PBX externo_horario varchar 45 N/A Horario de consulta del externo Id_entidad varchar 45 N/A Hace referencia a la tabla entidad Id_cargo varchar 45 N/A Hace referencia a la tabla cargo externo_telefono1 Int 15 N/A Número telefónico principal externo_telefono2 Int Número telefónico alternativo externo_telefono3 Int Número telefónico alternativo externo_fax Int 15 N/A Número de fax Estado Boolean 1 Si Valor lógico representado para eliminar de manera lógica a un externo. Tabla 33 Tabla externo

60 Nombre Campo Tipo Dato de Longitud / Formato Obligatorieda d Validaciones / Descripción evento_titulo VARCHAR 45 SI Titulo o nombre del evento evento_descripcion VARCHAR 200 SI eve_fecha_ini DATE NO Descripción breve del evento no mayor a 200 caracteres Por defecto se toma el día del registro/ representa la fecha de comienzo del evento eve_fecha_fin DATE SI Fecha de finalización del evento Tabla 34 Tabla eventos Nombre Tipo de Longitud / Obligatoriedad Validaciones / Campo Dato Formato Restricciones Referente al nombre del cargo del funcionario cargo_detalle VARCHAR 100 SI ejemplo: pasante, asesor Tabla 35 Tabla cargo Nombre Campo Tipo de Longitud / Obligatoriedad Validaciones / Dato Formato Restricciones sede_piso_detalle VARCHAR 100 SI Describe la ubicación de un grupo de funcionario compuesto entre el nombre del edificio y el piso Ejemplo: CAD piso 5 Tabla 36 Tabla ubicación Nombre Campo Tipo Dato de Longitud / Formato entidad_nombre VARCHAR 45 SI entidad_ubicacion VARCHAR 45 Si Tabla 37 Tabla entidad Obligatoriedad Validaciones / Restricciones Nombre de la entidad Ejemplo: Empresa de Acueducto, Alcantarillado y Aseo de Bogotá Dirección de la entidad ejemplo: Carrera 11 #109-80, Bogotá Nombre Campo Tipo Dato de Longitud / Formato dependencia_nombre VARCHAR 45 SI id_dependencia_padre Tabla 38 Tabla dependencia INT Obligatoriedad Validaciones / Restricciones Nombre de la dependencia Ejemplo: Subdireccion de sistemas Código que identifica a la dependencia mayor. Nombre Tipo de Longitud / Obligatoriedad Validaciones / Campo Dato Formato Restricciones Referente al nombre del tipo de contrato a Tc_detalle VARCHAR 45 SI registrar, ejemplo: Prestación de servicios Tabla 39 Tabla tipo contrato

61 Nombre Campo Tipo Dato de Longitud / Formato Obligatoriedad Validaciones / Restricciones persona VARCHAR 100 SI Administrador que realiza la acción accion VARCHAR 45 SI Crear, eliminar, actualizar o leer algún registro fecha DATE SI Fecha en la que se realizó la acción Tabla 40 Tabla log de auditoria Diagramas de paquetes El modelo de paquetes representa la agrupación lógica de clases siguiendo el patrón de diseño MVC (modelo vista controlador) Ilustración 26 Estructura de paquetes Diagramas de clases Paquete model Representa el diagrama de clases para el paquete model que tiene como función mapear las entidades de la base de datos.

62 Ilustración 27 Diagrama de clases del paquete model Paquete daos Las clases del paquete daos tiene como misión separar el acceso a los datos de la lógica del negocio. En dicho paquete se implementa una clase conexión que va a ser invocada por las otras clases que desarrollan los métodos básicos de acceso a la base de datos como son: leer, escribir, actualizar y eliminar. Ilustración 28 Diagrama de clases del paquete daos Paquete exportador La clase exportador es un modelo bastante útil para disenar la plantilla de datos para exportar en los diferentes formatos de archivos: pdf, xml, xls y cvs.

63 Ilustración 29 Clase exportador Paquete utilidades Se definió una clase Util con el fin de agrupar tareas repetitivas en este caso, la impresión de mensajes, operaciones de acceso o login entre otras.

64 Ilustración 30 Clase JSFUtil Paquete mensajes Este paquete solo lo compone una clase y tiene como función imprimir mensajes del lado del servidor para realizar procesos de auditoria. Ilustración 31 Clase mensajes.

65 Paquete controlador Las clases del paquete controlador, en este caso es un contenedor de managed bean cuyas propiedades se discuten más adelante. Tiene como finalidad implementar los datos de los daos por medio del patrón fachada y cargarlos para ser publicados en las vistas (Facelets). Ilustración 32 Diagrama de clases del paquete controlador

66 Especificaciones técnicas Patrones de diseño Para dar garantía de escalabilidad del software a través del tiempo se implementaron los siguientes patrones de diseño. Nombre DAO Problema Re-utilización de operaciones para las tablas básicas. Solución Implementación del patrón dao (data access object ) Referencia Paquete daos Uso Tabla 41 Detalle patrón dao Nombre MVC Problema Modelos y clases con responsabilidad multiple Solución Separación del código en tres capas Modelo, vista, Controlador Referencia Estructura de paquetes (paquete model + managedbean + facelests) Uso Tabla 42 Detalle MVC Nombre Problema Solución Referencia Uso Tabla 43 Detalle patrón fachada Fachada Modelos y clases con responsabilidad multiple Implementar los métodos expuestos en las clases dao para usarlos en los managed bean Paquete controlador y paquete dao

67 Dependencias librerías y frameworks Frameworks Para la implementación se designaron los siguientes framework Nombre Java Development Kit (JDK) Versión 1.7+ Descripción Software que provee herramientas de desarrollo para la creación de programas en Java. Puede instalarse en una computadora local o en una unidad de red. Tabla 44 Detalle JDK Nombre Java Server Faces (JSF) Versión 2.2 Descripción Es un framework basado en el patrón MVC (Modelo Vista Controlador) para aplicaciones Java basadas en web que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE Tabla 45 Detalle JSF Librerías Para la implementación se designaron las siguientes librerías Nombre Primefaces Versión 5.0 Descripción Es un popular framework usado por JavaServer Faces (JSF) UI framework. Es útil para desarrollar rápidamente aplicaciones sofisticadas Tabla 46 Detalle librería primefaces. Nombre JasperReports Versión Descripción JasperReports es una librería para la generación de reportes de código abierto. Está completamente escrito en Java y es capaz de utilizar datos procedentes de cualquier tipo de fuente de datos y producir documentos perfectos en píxeles que se pueden ver, imprimir o exportar en una variedad de formatos de documentos incluyendo HTML, PDF, Excel, OpenOffice y Word. Tabla 47 Detalle librería JasperReports.

68 Nombre itext Versión Descripción Text es un conjunto de herramientas de desarrollo de software que permite a los usuarios integrar funcionalidades PDF dentro de sus aplicaciones, procesos o productos. Tabla 48 Detalle librería itext. Nombre Cupertino Versión Descripción Es una librería de primefaces para el diseño de las hojas de estilo Tabla 49 Detalle librería Cupertino. Base de datos Para el manejo de la persistencia e interacción con la fuente de datos desde la aplicación, se hará uso del siguiente framework: Nombre JDBC Versión 4.0 Descripción Java Database Connectivity, es una API que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java, independientemente del sistema operativo donde se ejecute o de la base de datos a la cual se accede, utilizando el dialecto SQL del modelo de base de datos que se utilice. Tabla 50 Detalle driver JDBC Pruebas de unitarias Estrategias de pruebas Para la realización de pruebas se centró en la captura de errores de los diferentes procesos de entrada y salida de datos de la aplicación. El siguiente formato muestra la representación histórica de la captura y solución de los errores. Módulo de Gestión de tablas básicas

69 Descripción Revisar los procesos de crear, editar, leer y actualizar registros de las tablas básicas: cargo, tipo de contrato, entidad, dependencia, ubicación. Acción Error encontrado Usuario que reporta Solución Crear entidad Crear tipo contrato Crear dependencia Crear cargo Crear entidad Crear tipo contrato Crear dependencia Crear cargo No valida que los inputs sean campos alfanuméricos. Se puede ingresar números solamente en un campo que no debería ser así. Se guardan registros duplicados Tester administrador Tester administrador y y Implementar validador de primefaces del lado del cliente Se solucionó Poner restricción de valores únicos en la base de datos, para campos sensibles Actualizar entidad Actualizar tipo contrato Actualizar dependencia Actualizar cargo Eliminar entidad Eliminar tipo contrato Eliminar dependencia Eliminar cargo Al oprimir click en el registro para actualizar se despliega una ventana alterna que no trae los datos para modificar No muestra un mensaje de confirmación a la hora de eliminar un registro Tester administrador Tester administrador y y Se solucionó Se solucionó Se solucionó Tabla 51 Pruebas de gestión de tablas básicas Módulo de Gestión de noticias

70 Descripción Revisar los procesos de crear, editar, leer y actualizar para los registros de una noticia. Acción Error encontrado Usuario que reporta Solución Crear noticia No válida para el campo título y descripción sean valores alfanuméricos. Tester administrador y Implementar validador de primefaces del lado del cliente Crear noticia Leer noticia Tabla 52 Pruebas de gestión de noticias La fecha final del evento tiene que ser mayor o igual a la fecha inicial La publicación de noticias sólo debe aplicar para aquellas cuyo rango de fechas no se haya vencido Tester administrador Tester administrador y y Se solucionó Se solucionó Se solucionó Módulo exportar listados Descripción Exportar en formatos xml, pdf, xls y csv las consultas filtradas Acción Error encontrado Usuario que reporta Solución Exportar datos No hay un estado Tester y por defecto si se le da exportar en el icono del formato. administrador Se solucionó Tabla 53 Pruebas de gestión de noticias Manual de usuario resumido La Dirección de Sistemas de la Secretaría Distrital de Planeación Distrital pensando en su Organización y el mejoramiento de los procesos de comunicación entre los funcionarios y los colaboradores de la entidad nótese como entidades externas, creó la herramienta informática para la gestión de datos de contacto. Ingreso al sistema

71 Los perfiles de acceso al sistema hacen referencia a los tipos de usuarios que van a acceder al directorio activo y que posteriormente se verá reflejado en el manejo de la información. Para acceder al sistema se debe usar un nombre de usuario y contraseña que sean válidos. Cada perfil de acceso tiene opciones diferentes que permiten al usuario realizar las acciones necesarias para ejecutar de forma adecuada su rol dentro del sistema. Ilustración 33 Ventana de autenticación Módulo de administración Crear funcionario Con esta opción el Administrador puede crear un funcionario de la sdp. Se necesitan los siguientes datos Foto: Se debe agregar desde un directorio local. No tiene ningún tipo de restricción en cuanto a tamaño o resolución, sólo la recomendación de ser una foto personal, donde el funcionario esté solo y enfocado. Ubicación, tipo de contrato y ubicación deben seleccionarse obligatoriamente dentro de la entidad, número de extensión, fecha de nacimiento.

72 Ilustración 34 Ventana para registrar funcionario Una vez agregado el funcionario se puede desplegar su información por medio del enlace

73 Ilustración 35 Módulo completo de administración de funcionario. Para modificar un funcionario se oprime el botón Una vez se haya desplegado la información en la parte superior. Luego de oprimir este enlace se muestra una ventana alterna con los datos de dicho funcionario la cual se puede editar.

74 Ilustración 36 Ventana editar funcionario Inactivar funcionario Inactivar un funcionario es cambiar su estado a activo o inactivo según su estado inicial. Basta con desplegar el funcionario y luego oprimir el botón

75 Crear externo Ilustración 37 Ventana para la creación de externo Ilustración 38 Módulo de administración externo

76 Para el despliegue de la información de un externo se oprime el botón se despliega una tabla con los datos relacionados. Luego Ilustración 39 Panel detalle externo Para modificar un externo se debe oprimir el botón. Luego se abre una ventana con la información del externo. Para borrar un externo basta con seleccionar el registro y oprimir Gestión de campos complementarios Para acceder a la administración de campos secundarios o campos complementarios crear, actualizar y eliminar debe oprimir el botón Ilustración 40 Menú campos complementarios.

77 Crear entidad La administración para el campo entidad está definido en el formulario. Se aceptan datos alfanuméricos lo que quiere decir: letras y números, el valor para la dirección debe llevar la siguiente abreviatura Calle:cl Carrera: cra Diagonal: dg Transversal:Tv Tabla 54 Formato de direcciones Número y acompañ ante b 13 bis # Número y acompañante b 26 sur - Número y acompañan te b Nombre de la ciudad Bogotá Ilustración 41 Ventana registrar entidad Ilustración 42 Modificar entidad Crear dependencia Para agregar una dependencia se debe tener ingresar el nombre de la dependencia cuyo valor debe ser alfanumérico (Letras y números). Sí se ingresan números el aplicativo manda un mensaje de error

78 Ilustración 43 Ventana registrar dependencias Ilustración 44 Mensaje de error crear dependencia Ilustración 45 Error de valores vacíos Ilustración 46 Modificar dependencia Crear ubicación Ilustración 47 Ventana registrar ubicación

79 Ilustración 48 Lista de ubicaciones Módulo de búsquedas Búsqueda funcionario Para poder agrupar uno o un grupo de funcionario se ingresa al formulario Ilustración 49 Ventana búsqueda funcionario Luego de oprimir el botón

80 Ilustración 50 Listado resultado de búsqueda Sin embargo, puede haber resultados de búsqueda como se muestra en la Ilustración 51 Ilustración 51 Resultado de búsqueda vacío Exportar archivos Luego de realizar el proceso de búsqueda se puede exportar los resultados de datos mediante la funcionalidad de exportar archivos ver Ilustración 52.

81 Ilustración 52 Ventana exportar archivos El usuario debe chequear qué campos desea exportar en los formatos referenciados:.pdf,.xls,.cvs y.xml. El archivo se guarda en descargas Módulo para la administración de noticias y eventos. Publicar noticia El módulo de gestión de noticias y eventos tiene como objetivo difundir anuncios cortos de interés general de la entidad como lo son: cursos, capacitaciones, reuniones todas los que el administrador considere pertinente agregar. Ilustración 53 Ventana módulo administración de noticias Para agregar un nuevo registro hay que oprimir

82 Luego se abre una ventana con un formulario sencillo. El formulario cuenta con los siguientes datos de registro: - Título: Enunciado del comunicado, tiene que ser corto y conciso. - Descripción: Provee una información un poco más detallada del evento, sin embargo, no puede superar los 300 caracteres. - Fecha de inicio: día mes y año de iniciado el evento. - Fecha final: día mes y año de finalizado el evento. Aclaración: Un evento puede iniciar y finalizar o no el mismo día, el evento dejará de aparecer en difusión sólo cuando la fecha de finalización haya pasado. Ilustración 54 Ventana registrar noticia Para editar una noticia se oprime el botón ventana con los datos de dicho registro que luego despliega una

83 Ilustración 55 Editar noticia Módulo auditoría Para usar el módulo de auditoría. Muestra qué usuario realizó qué acción en determinado momento. Ilustración 56 Ventana registros de auditoría