diseño e implementación de una aplicación web para el...

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 20112020112 Julián Esteban Cisneros 20082020023

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

Contenido Capítulo I: introducción ............................................................................................................... 10

Capítulo II: formulación .............................................................................................................. 11

Antecedentes .......................................................................................................................... 11

Descripción del problema ....................................................................................................... 11

Formulación de la pregunta central del trabajo ..................................................................... 11

Capítulo III: justificación .............................................................................................................. 12

Capítulo IV: objetivo general ...................................................................................................... 13

Capítulo V: objetivos específicos ................................................................................................ 14

Capítulo VI: alcance ..................................................................................................................... 15

Capítulo VII: marco referencial ................................................................................................... 16

Capítulo VIII: marco tecnológico ................................................................................................. 17

OpenLDAP ............................................................................................................................... 17

Java Server Faces .................................................................................................................... 17

Capítulo IX: marco metodológico ............................................................................................... 18

SCRUM .................................................................................................................................... 19

Manifiesto Ágil ........................................................................................................................ 19

Gestión de la evolución del proyecto ..................................................................................... 20

Revisión de las Iteraciones ...................................................................................................... 20

Desarrollo incremental ........................................................................................................... 20

Auto-Organización .................................................................................................................. 20

Colaboración ........................................................................................................................... 20

Capítulo X: recursos para el desarrollo del proyecto .................................................................. 21

Capítulo XI: cronograma ............................................................................................................. 22

Capítulo XII: Implementación y desarrollo.................................................................................. 23

Fase de requerimientos .......................................................................................................... 24

Desarrollo de Ingeniería .......................................................................................................... 24

Definición de términos ........................................................................................................ 25

Fase de inicio ........................................................................................................................... 26

Personas y roles de proyecto .............................................................................................. 26

Fase de elaboración ................................................................................................................ 26

Elaboración sprint ............................................................................................................... 26

Descripción usuarios ............................................................................................................... 34

Definición de requerimientos ................................................................................................. 35

Servicios de búsquedas ........................................................................................................... 35

Búsqueda por externos ....................................................................................................... 36

Funcionalidades del Directorio Activo de la SDP .................................................................... 37

Importación Masiva ............................................................................................................ 38

Administración de funcionario ................................................................................................ 38

Administración de externo ..................................................................................................... 39

Administración de campos secundarios ................................................................................. 40

Creación entidad ................................................................................................................. 40

Creación cargo .................................................................................................................... 41

Creación de Ubicación ........................................................................................................ 42

Creación de tipo de contrato .............................................................................................. 43

Creación de dependencia ................................................................................................... 44

Funcionalidades adicionales ............................................................................................... 45

Funcionalidad de Navegación ............................................................................................. 46

Integración con otros aplicativos ........................................................................................ 46

Auditoría sobre la información del Sistema ............................................................................ 47

Requerimientos no funcionales .............................................................................................. 47

Rendimiento ........................................................................................................................ 47

Disponibilidad ..................................................................................................................... 47

Seguridad ............................................................................................................................ 47

Visualización ........................................................................................................................ 47

Front End ............................................................................................................................. 47

Entorno de aplicación ............................................................................................................. 48

Modelo de Negocio. .................................................................................................................... 49

Diagrama de casos de uso ....................................................................................................... 54

Análisis funcional .................................................................................................................... 55

Registrar funcionario diagrama de estado .......................................................................... 55

Registrar externo diagrama de estado ............................................................................... 55

Importe masivo ................................................................................................................... 56

Modelo lógico ......................................................................................................................... 58

Diccionario de datos ........................................................................................................... 58

Diagramas de paquetes .......................................................................................................... 61

Diagramas de clases ................................................................................................................ 61

Paquete model .................................................................................................................... 61

Paquete daos ...................................................................................................................... 62

Paquete exportador ............................................................................................................ 62

Paquete utilidades .............................................................................................................. 63

Paquete mensajes ............................................................................................................... 64

Paquete controlador ........................................................................................................... 65

Especificaciones técnicas ........................................................................................................ 66

Patrones de diseño ............................................................................................................. 66

Dependencias librerías y frameworks ..................................................................................... 67

Frameworks ........................................................................................................................ 67

Librerías ............................................................................................................................... 67

Base de datos .......................................................................................................................... 68

Estrategias de pruebas ................................................................................................................ 68

Pruebas de unitarias ............................................................................................................... 68

Manual de usuario resumido .................................................................................................. 70

Módulo de administración .................................................................................................. 71

Crear funcionario ................................................................................................................ 71

Inactivar funcionario ........................................................................................................... 74

Crear externo ...................................................................................................................... 75

Gestión de campos complementarios .................................................................................... 76

Crear entidad ...................................................................................................................... 77

Crear dependencia .............................................................................................................. 77

Crear ubicación ................................................................................................................... 78

Módulo de búsquedas ............................................................................................................ 79

Búsqueda funcionario ......................................................................................................... 79

Exportar archivos ................................................................................................................ 80

Módulo para la administración de noticias y eventos. ........................................................... 81

Publicar noticia .................................................................................................................... 81

Módulo auditoría ................................................................................................................ 83

Capítulo XII: recomendaciones ................................................................................................... 85

Capítulo XII: conclusiones ........................................................................................................... 86

REFERENCIAS ............................................................................................................................... 87

Ilustraciones

Ilustración 1 Cronograma de actividades .................................................................... 23

Ilustración 2 Mockup Formulario búsqueda de servidores .......................................... 36

Ilustración 3 Mockup Resultado búsqueda funcionario ............................................... 36

Ilustración 4 Mockup Formulario búsqueda externos .................................................. 37

Ilustración 5 Mockup Resultado búsqueda externos ................................................... 37

Ilustración 6 Mockup Formulario importación masivo .................................................. 38

Ilustración 7 Mockup Formulario crear funcionario ...................................................... 39

Ilustración 8 Mockup Formulario crear externo ........................................................... 40

Ilustración 9 Mockup Formulario crear entidad ........................................................... 41

Ilustración 10 Mockup Formulario crear cargo ........................................................... 42

Ilustración 11 Mockup Formulario crear ubicación ...................................................... 43

Ilustración 12 Mockup Formulario crear tipo de contrato ............................................. 44

Ilustración 13 Mockup Formulario crear dependencia ................................................. 45

Ilustración 14 División de paneles en ventana de Administrador ................................. 48

Ilustración 15 Diagrama de casos de uso módulo funcionario .................................... 49

Ilustración 16 Diagrama de casos de uso módulo administrador área de

comunicaciones .......................................................................................................... 50

Ilustración 17Diagrama de casos de uso módulo administrador área de contratos ..... 51

Ilustración 18 Diagrama de casos de uso módulo administrador RRHH ..................... 52

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

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

Ilustración 21 Diagrama de estado registrar funcionario ............................................. 55

Ilustración 22 Diagrama de estado registrar externo ................................................... 55

Ilustración 23 Diagrama de secuencia importe masivo ............................................... 56

Ilustración 24 Diagrama de secuencia acceso plataforma .......................................... 57

Ilustración 25 Modelo relacional ................................................................................. 58

Ilustración 26 Estructura de paquetes ......................................................................... 61

Ilustración 27 Diagrama de clases del paquete model ............................................... 62

Ilustración 28 Diagrama de clases del paquete daos .................................................. 62

Ilustración 29 Clase exportador .................................................................................. 63

Ilustración 30 Clase JSFUtil ........................................................................................ 64

Ilustración 31 Clase mensajes. ................................................................................... 64

Ilustración 32 Diagrama de clases del paquete controlador ........................................ 65

Ilustración 33 Ventana de autenticación ..................................................................... 71

Ilustración 34 Ventana para registrar funcionario ........................................................ 72

Ilustración 35 Módulo completo de administración de funcionario. .............................. 73

Ilustración 36 Ventana editar funcionario .................................................................... 74

Ilustración 37 Ventana para la creación de externo ................................................... 75

Ilustración 38 Módulo de administración externo ........................................................ 75

Ilustración 39 Panel detalle externo ............................................................................ 76

Ilustración 40 Menú campos complementarios. .......................................................... 76

Ilustración 41 Ventana registrar entidad ...................................................................... 77

Ilustración 42 Modificar entidad .................................................................................. 77

Ilustración 43 Ventana registrar dependencias ........................................................... 78

Ilustración 44 Mensaje de error crear dependencia .................................................... 78

Ilustración 45 Error de valores vacíos ......................................................................... 78

Ilustración 46 Modificar dependencia .......................................................................... 78

Ilustración 47 Ventana registrar ubicación .................................................................. 78

Ilustración 48 Lista de ubicaciones ............................................................................. 79

Ilustración 49 Ventana búsqueda funcionario ............................................................. 79

Ilustración 50 Listado resultado de búsqueda ............................................................. 80

Ilustración 51 Resultado de búsqueda vacío ............................................................... 80

Ilustración 52 Ventana exportar archivos .................................................................... 81

Ilustración 53 Ventana módulo administración de noticias .......................................... 81

Ilustración 54 Ventana registrar noticia ....................................................................... 82

Ilustración 55 Editar noticia ......................................................................................... 83

Ilustración 56 Ventana registros de auditoría .............................................................. 83

Ilustración 57 Campos de búsquedas log de auditoría. ............................................... 84

Tablas

Tabla 1 Presupuesto del proyecto .............................................................................. 22

Tabla 2 Definición de términos scrum ......................................................................... 25

Tabla 3 Personas y roles de proyecto ......................................................................... 26

Tabla 4 Sprint 0 .......................................................................................................... 26

Tabla 5 Sprint 1 .......................................................................................................... 27

Tabla 6 Sprint 2 .......................................................................................................... 27

Tabla 7 Sprint 3 .......................................................................................................... 28

Tabla 8 Sprint 4 .......................................................................................................... 28

Tabla 9 Sprint 5 .......................................................................................................... 28

Tabla 10 Sprint 6 ....................................................................................................... 29

Tabla 11 Sprint 7 ........................................................................................................ 29

Tabla 12 Sprint 8 ........................................................................................................ 29

Tabla 13 Sprint 9 ....................................................................................................... 30

Tabla 14 Sprint 10 ..................................................................................................... 30

Tabla 15 Sprint 11 ..................................................................................................... 30

Tabla 16 Sprint 12 ..................................................................................................... 31

Tabla 17 Sprint 13 ..................................................................................................... 31

Tabla 18 Sprint 14 ..................................................................................................... 31

Tabla 19 Sprint 15 ...................................................................................................... 32

Tabla 20 Sprint 16 ...................................................................................................... 32

Tabla 21 Sprint 17 ...................................................................................................... 32

Tabla 22 Sprint 18 ...................................................................................................... 33

Tabla 23 Descripción de usuarios ............................................................................... 34

Tabla 24 Diagrama de proceso crear entidad ............................................................. 40

Tabla 25 Diagrama de proceso crear cargo ................................................................ 41

Tabla 26 Diagrama de proceso crear ubicación .......................................................... 43

Tabla 27 Diagrama de proceso crear tipo de contrato ................................................ 43

Tabla 28 Diagrama de proceso crear dependencia ..................................................... 44

Tabla 29 Diagrama de procesos funcionalidad de navegación ................................... 46

Tabla 30 Uso del Directorio Activo para la aplicación. ................................................ 46

Tabla 31 Tabla administrador ..................................................................................... 58

Tabla 32 Tabla funcionario ......................................................................................... 59

Tabla 33 Tabla externo ............................................................................................... 59

Tabla 34 Tabla eventos .............................................................................................. 60

Tabla 35 Tabla cargo .................................................................................................. 60

Tabla 36 Tabla ubicación ............................................................................................ 60

Tabla 37 Tabla entidad ............................................................................................... 60

Tabla 38 Tabla dependencia ...................................................................................... 60

Tabla 39 Tabla tipo contrato ....................................................................................... 60

Tabla 40 Tabla log de auditoria ................................................................................... 61

Tabla 41 Detalle patrón dao ........................................................................................ 66

Tabla 42 Detalle MVC ................................................................................................. 66

Tabla 43 Detalle patrón fachada ................................................................................. 66

Tabla 44 Detalle JDK .................................................................................................. 67

Tabla 45 Detalle JSF .................................................................................................. 67

Tabla 46 Detalle librería primefaces............................................................................ 67

Tabla 47 Detalle librería JasperReports. ..................................................................... 67

Tabla 48 Detalle librería iText. .................................................................................... 68

Tabla 49 Detalle librería Cupertino. ............................................................................ 68

Tabla 50 Detalle driver JDBC ..................................................................................... 68

Tabla 51 Pruebas de gestión de tablas básicas .......................................................... 69

Tabla 52 Pruebas de gestión de noticias .................................................................... 70

Tabla 53 Pruebas de gestión de noticias .................................................................... 70

Tabla 54 Formato de direcciones ................................................................................ 77

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.

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?

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).

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.

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.

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.

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 2013.

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.

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

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

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

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 auto-organizació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).

Capítulo X: recursos para el desarrollo del proyecto

En la siguiente tabla se describen los aspectos de financiación y costos del proyecto.

ELEMENTO PRECIO DESCRIPCIÓN ASUMIDO POR

Hardware

Computa portátil $ 1.600.000 Ninguna Estudiante

Computa portátil $ 1.200.000 Ninguna Estudiante

Sub-total $ 2.800.000

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

de tareas a realizar en los tiempos estipulados en el cronograma.

Ilustración 1 Cronograma de actividades

Capítulo XII: Implementación y desarrollo

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.

Definición de términos

Sprint Son Iteraciones o entregas del producto.

Concepto Forma general de las características del proyecto.

Especulación 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.

Exploración Se incrementa el producto en el que se añaden las funcionalidades de la fase de especulación.

Revisión El equipo revisa todo lo que se ha construido y se contrasta con el objetivo deseado.

Cierre Se entrega en una fecha deseada una versión.

Reuniones

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.

Backlog Es una lista ordenada de todo el trabajo pendiente. En una pila organizado por su prioridad.

Scrum master 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 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)

Tabla 2 Definición de términos scrum

Fase de inicio

Personas y roles de proyecto

Persona Contacto Rol

Víctor Manuel Gutiérrez Campos

[email protected] Coordinador, Scrum Manager

María Teresa Gonzáles Bejarano

[email protected]

Stackholder y Gestor de Producto

Julián Esteban Cisneros

[email protected]

Team

Jairo Andrés Quevedo Bolívar

[email protected] Team

Tabla 3 Personas y roles de proyecto

Fase de elaboración

Elaboración sprint

Backlog ID

Tarea Tipo Estado Responsable

HT1 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 (Definición de cardinalidad entre entidades)


Tabla 4 Sprint 0

Backlog ID


HT2 Mapeo de tablas (Incluir operaciones crud )

Desarrollo Completo Jairo Andrés Quevedo Bolívar Julián Cisneros


1 semanas

Alta Validaciones del cliente y servidor


Tabla 5 Sprint 1

Backlog ID


HT2-1 Crud noticias Validar reglas fecha inicial –final de evento

Frontend Incremento - HT1

Completo Jairo Andrés Quevedo Bolívar


1 semanas

Media Deshabilitar textfield fechas


Tabla 6 Sprint 2

Backlog ID


HT3 Realización búsquedas de funcionarios y externos

Desarrollo Completo Julián Cisneros


1 semanas

Baja Limpia botones de selección


Tabla 7 Sprint 3

Backlog ID


HT2-2 Crud dependencias Establecer árbol de dependencias

Desarrollo Incremento HT2



1 semanas

Media Corregir niveles árbol de dependencia, puede ser mayor de 2


Tabla 8 Sprint 4

Backlog ID


HT3-1 Exportar listados de búsquedas


Completo Julián Cisneros


1 semanas

Medio Estado por defecto de listas por exportar


Tabla 9 Sprint

Backlog ID


HT2-3 Crud entidad Definir formato de direcciones




1 semanas

Media Víctor Manuel Gutiérrez Campos

Tabla 10 Sprint 6

Backlog ID


HT2-4 Crud Ubicación Definición parametrización ubicación




1 semanas

Media Víctor Manuel Gutiérrez Campos

Tabla 11 Sprint 7

Backlog ID


HT4 Implementar Crud funcionario

Desarrollo



2 semanas

Medio Guardar foto de funcionario como un blob en la bd


Tabla 12 Sprint

Backlog ID


HT2-4 Crud Sector Definir planos imágenes

Diseño Incremento HT2



0.5 semanas

Medio Víctor Manuel Gutiérrez Campos

Tabla 13 Sprint 9

Backlog ID


HT4-1 Implementar Crud externo




2 semanas

Medio Mensaje de confirmar Borrado


Tabla 14 Sprint 10

Backlog ID


HT2-5 Crud Cargo Caracteres alfanuméricos Validar duplicidad




0.5 semanas

Medio Aplicar para los demás campos secundarios


Tabla 15 Sprint 11

Backlog ID


HT2-1 Crud noticias Validar reglas fecha inicial –final de evento

Frontend Incremento - HT1



1 semanas

Media Deshabilitar textfield fechas


Tabla 16 Sprint 12

Backlog ID


HT5 Login Administrativos

Diseño

Completo Víctor Manuel Gutiérrez Campos


0.5 semanas

alto Aplicar estilos Víctor Manuel Gutiérrez Campos

Tabla 17 Sprint 13

Backlog ID


HT6 Implementar log de auditoria

Desarrollo



2 semanas

alto Manejarlo sin triggers a nivel de sesiones


Tabla 18 Sprint 14

Backlog ID


HT7 Conectar directorio activo

Desarrollo



1 semanas

alto Víctor Manuel Gutiérrez Campos

Tabla 19 Sprint 15

Backlog ID


HT8 Lista de mensajes para mostrar en el frontend

Frontend

Completo Jairo Andrés Quevedo Bolívar Julián Cisneros


1 semanas


Tabla 20 Sprint 16

Backlog ID


HT9 Desarrollo frontend todas las paginas

Frontend

Completo Jairo Andrés Quevedo Bolívar Julián Cisneros


4 semanas

alto Utilizar librerías de primefaces


Tabla 21 Sprint 17

Backlog ID


HT10 Manejo de sesiones

Desarrollo



2 semanas


Tabla 22 Sprint 18

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 Administrador General

Responsabilidades 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.

Perfil Administrador Área Comunicaciones

Responsabilidades 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.

Perfil Administrador Área Contratos

Responsabilidades 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.

Perfil Administrador Área Recursos Humanos

Responsabilidades 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.

Perfil Funcionario SDP

Responsabilidades 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

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.

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

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.

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.

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.

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

. 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 El Administrador debe llenar los campos Ubicación en caso de crear una nueva ubicación detalla en el nombre del cargo

PROCESO 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.


Tabla 25 Diagrama de proceso crear cargo

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 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.

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.


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.


Tabla 27 Diagrama de proceso crear tipo de contrato

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.


Tabla 28 Diagrama de proceso crear dependencia

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.

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 Botones de navegación regresar a primer listado, ir al último listado, saltar al siguiente listado de registros, regresar al listado anterior

PROCESO Navegar entre listados encontrados

SALIDA 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? Ocasionalmente

En el aplicativo (consumidor)

En los casos de Uso creación de Usuario e Importación de datos Masivos

se recurre al aplicativo (proveedor) Directorio Activo

en busca de (datos) Número de cédula

con el fin de (acción) Validar y extraer datos

generando en el aplicativo consumidor

Datos básicos de Identificación del Usuario. (Nombres Apellidos, Correo Electrónico, extensión)

generando en el aplicativo proveedor Ningún Cambio Tabla 30 Uso del Directorio Activo para la aplicación.

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.

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.

Modelo de Negocio. Existen 5 tipos de usuarios, con sus respectivos permisos dentro del software.

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.

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

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.

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.

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.

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

Diagrama de casos de uso

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

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

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.

Ilustración 24 Diagrama de secuencia acceso plataforma

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 Campo

Tipo de Dato

Longitud / Formato

Obligatoriedad

Descripción

user varchar 45 Si Nombre de usuario

password varchar 45 Si

Tabla 31 Tabla administrador

Nombre Campo

Tipo de Dato

Longitud / Formato

Obligatoriedad

Descripción

Cedula varchar 45 N/A Dato que se obtiene del LADP

Funcionario_nombre

varchar 45 N/A Nombres del funcionario completos

Funcionario_Apellidos

varchar 45 N/A Apellidos del funcionario completos

Funcionario_extension

Int N/A Número telefónico interno a la red de la entidad

Funcionario_genero

char 2 N/A F/ M / O

Funcionario_Correo

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 de nacimiento

date N/A N/A

Funcionario_foto blob N/A N/A Almacena una imagen que representa la foto del funcionario

Estado Boolean

1 Si Valor lógico representado para eliminar de manera lógica a un funcionario.

Tabla 32 Tabla 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


Longitud / Formato

Obligatoriedad

Validaciones / Descripción

evento_titulo VARCHAR 45 SI Titulo o nombre del evento

evento_descripcion VARCHAR 200 SI Descripción breve del evento no mayor a 200 caracteres

eve_fecha_ini DATE NO 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 Campo

Tipo de Dato

Longitud / Formato

Obligatoriedad Validaciones / Restricciones

cargo_detalle VARCHAR 100 SI Referente al nombre del cargo del funcionario ejemplo: pasante, asesor

Tabla 35 Tabla cargo


Longitud / Formato


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


Longitud / Formato


entidad_nombre VARCHAR 45 SI Nombre de la entidad Ejemplo: Empresa de Acueducto, Alcantarillado y Aseo de Bogotá

entidad_ubicacion VARCHAR 45 Si Dirección de la entidad ejemplo: Carrera 11 #109-80, Bogotá

Tabla 37 Tabla entidad


Longitud / Formato


dependencia_nombre VARCHAR 45 SI Nombre de la dependencia Ejemplo: Subdireccion de sistemas

id_dependencia_padre INT Código que identifica a la dependencia mayor.

Tabla 38 Tabla dependencia

Nombre Campo

Tipo de Dato

Longitud / Formato


Tc_detalle VARCHAR 45 SI Referente al nombre del tipo de contrato a registrar, ejemplo: Prestación de servicios

Tabla 39 Tabla tipo contrato

Nombre Campo

Tipo de Dato

Longitud / Formato


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.

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.

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.

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.

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

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 Fachada

Problema Modelos y clases con responsabilidad multiple

Solución Implementar los métodos expuestos en las clases dao para usarlos en los managed bean

Referencia Paquete controlador y paquete dao

Uso Tabla 43 Detalle patrón fachada

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 6.3.1.

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.

Nombre iText

Versión 2.1.7

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 1.0.4

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

Estrategias de pruebas

Pruebas de unitarias

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

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

No valida que los inputs sean campos alfanuméricos. Se puede ingresar números solamente en un campo que no debería ser así.

Tester y administrador

Implementar validador de primefaces del lado del cliente Se solucionó

Crear entidad Crear tipo contrato Crear dependencia Crear cargo

Se guardan registros duplicados


Poner restricción de valores únicos en la base de datos, para campos sensibles Se solucionó

Actualizar entidad Actualizar tipo contrato Actualizar dependencia Actualizar cargo

Al oprimir click en el registro para actualizar se despliega una ventana alterna que no trae los datos para modificar


Se solucionó

Eliminar entidad Eliminar tipo contrato Eliminar dependencia Eliminar cargo

No muestra un mensaje de confirmación a la hora de eliminar un registro


Se solucionó

Tabla 51 Pruebas de gestión de tablas básicas

Módulo de Gestión de noticias

Descripción Revisar los procesos de crear, editar, leer y actualizar para los registros de una noticia.


Crear noticia No válida para el campo título y descripción sean valores alfanuméricos.


Implementar validador de primefaces del lado del cliente Se solucionó

Crear noticia La fecha final del evento tiene que ser mayor o igual a la fecha inicial


Se solucionó

Leer noticia La publicación de noticias sólo debe aplicar para aquellas cuyo rango de fechas no se haya vencido


Se solucionó

Tabla 52 Pruebas de gestión de noticias

Módulo exportar listados

Descripción Exportar en formatos xml, pdf, xls y csv las consultas filtradas


Exportar datos No hay un estado por defecto si se le da exportar en el icono del formato.


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

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.

Ilustración 34 Ventana para registrar funcionario

Una vez agregado el funcionario se puede desplegar su información

por medio del enlace

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.

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

Crear externo

Ilustración 37 Ventana para la creación de externo

Ilustración 38 Módulo de administración externo

Para el despliegue de la información de un externo se oprime el botón Luego se despliega una tabla con los datos relacionados.

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.

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

Número y acompañante 13 13 b 13 bis

# Número y acompañante 26 26 b 26 sur

- Número y acompañante 39 39 b

Nombre de la ciudad Bogotá

Tabla 54 Formato de direcciones

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

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

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

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.

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

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 que luego despliega una ventana con los datos de dicho registro

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

Al presentarse tantos datos dicho módulo cuenta con unos selectores en la parte superior para poder filtrar los registros

Ilustración 57 Campos de búsquedas log de auditoría.

Capítulo XII: recomendaciones A continuación, se establece una serie de recomendaciones orientadas al buen uso y la implementación de la aplicación. Lo primero que se analizó fue el entorno de despliegue de la aplicación y los componentes que se decidieron para su desarrollo, en temas referentes al aseguramiento de la calidad. La seguridad es el factor más complejo de abordar por ser éste muy extenso. Sin embargo, en la definición de la arquitectura, el tipo de información que se maneja (información de contacto no sensible) limita los puntos internos tenidos en cuenta. La creación de un control de acceso es fundamental para la auditoría de procesos en tiempo de ejecución. Para ello la sdp utiliza Active Directory Lightweight Directory Services (AD LDS). Autentica la identidad de los usuarios que solicitan acceso al directorio y sólo concede acceso a aquellos usuarios que pueden autenticarse correctamente. Los usuarios o entidades de seguridad solicitan datos de directorio de AD LDS mediante aplicaciones habilitadas para el uso de directorios que, a su vez, realizan una solicitud a AD LDS mediante el protocolo de acceso ligero (LDAP). Antes de realizar una solicitud de datos, la aplicación habilitada para el uso de directorios debe presentar a AD LDS las credenciales del usuario para su autenticación o enlace. Esta solicitud incluye un nombre de usuario, una contraseña y, según el tipo de enlace, un nombre de dominio o de equipo. Una recomendación muy importante para el buen funcionamiento de la aplicación tiene que ver con la calidad de los datos. Si bien el software tiene validaciones en los formularios de registro por parte del cliente, implementadas por medio de la librería primefaces en su versión 5.0. Es necesario actualizar aquellos registros no lógicos que puedan pasar a la base de datos y es misión de los diferentes roles administrativos hacerles mantenimiento a los datos inmediatamente se descubra una incongruencia. Esto se extiende para el administrador general quien se encargará de hacer los importes masivos de funcionarios del directorio activo para evitar desactualizaciones en ambas bases de datos. Para aspectos de mantenimiento se recomienda cambiar las librerías periódicamente por actualizaciones estables y compatibles, con el fin de no perder vigencia y lograr solventar vulnerabilidades no detectadas en el momento. El uso del patrón DAO (Data access object) garantiza la separación de los métodos de consulta a la base de datos o mejor dicho la capa de persistencia de datos por consiguiente cualquier nueva entidad que se quiera agregar al modelo en un futuro debe ser mapeada en la capa de persistencia o en el paquete destinado para las clases DAO, comunicándolo con la capa de negocio usando patrón MVC (Modelo vista controlador)

Capítulo XII: conclusiones La utilización de JSF como framework de desarrollo fue una decisión acertada siempre que se siga manejando en un entorno de intranet. Su trabajo de renderización sobrecarga al servidor de aplicaciones fuertes críticas para el rendimiento de este framework se han hecho en la comunidad global de internet. Sin embargo, la aplicación no maneja muchos usuarios controlando la concurrencia de manera adecuada. Trabajar con JSF y Primefaces puede traer problemas de compatibilidad con el

Explorador “Internet Explorer” que en nuestro caso afecta directamente los

requerimientos que exigen que el software funcione en los 3 navegadores

principales Chrome Firefox y Internet Explorer.

El desarrollo de Software en una empresa con tantos años como la SDP exige

un gran esfuerzo para un pasante en el aprendizaje de los métodos de trabajo,

documentación y los conductos regulares de la empresa.

El uso de metodologías ágiles facilita el trabajo cooperativo entre grupos de

desarrolladores

REFERENCIAS

Concha, G., & Naser, A. (2012). El desafío hacia el gobierno abierto en la hora

de la igualdad. Comisión Económica para América Latina y el Caribe (CEPAL)

Congreso de Colombia. (6 de Marzo de 2014). Por medio de la cual se crea la ley de transparencia y del derecho de acceso a la información pública nacional y se dictan otras disposiciones. [Ley 1712 de 2014]. Recuperado de http://www.mintic.gov.co/portal/604/articles-7147_documento.pdf

Dirección de sistemas (2016) Solicitud de requerimiento de usuario (sistemas de información / aplicaciones de software). Versión 4. Acta de mejoramiento 277 de abril 7 de 2016 proceso a-ca-007.

Fincham, R., & Rhodes, P. (2005). Principles of organizational behaviour. OUP Oxford.

Lovelle, J. M. C. (1999). Calidad del Software. Oct, 21, 1999. Oracle (2007). The Java EE 5 Tutorial. Recuperado de:

http://docs.oracle.com/javaee/5/tutorial/doc/ Oracle (2013).JavaServer Faces Technology Tutorial. Recuperado de:

http://docs.oracle.com/javaee/6/tutorial/doc/bnaph.html Palacio J. (2014). Gestión de proyectos Scrum Manager. Pow-Sang, J., & Imbert, R. (2004). Estimación y Planificación de Proyectos

Software con Ciclo de Vida Iterativo-Incremental y empleo de Casos de Uso. InProceedings IDEAS.

Secretaria Distrital de Planeación (2017) .Direccionamiento Estratégico. Recuperado de: http://www.sdp.gov.co/PortalSDP/entidad/Direccionamientoestrategico/misioVision

The OpenLDAP Project (2016). OpenLDAP Software 2.4 Administrator's Guide. Recuperado: https://www.openldap.org/doc/admin24/

Vega C., Rivera L & García A.: (2008) “MEJORES PRÁCTICAS PARA EL ESTABLECIMIENTO Y ASEGURAMIENTO DE CALIDAD DE SOFTWARE” Edición Electrónica. Texto completo en www.eumed.net/

http://www.mintic.gov.co/portal/604/articles-7147_documento.pdf

http://docs.oracle.com/javaee/5/tutorial/doc/

http://docs.oracle.com/javaee/6/tutorial/doc/bnaph.html

http://www.sdp.gov.co/PortalSDP/entidad/Direccionamientoestrategico/misioVision

http://www.sdp.gov.co/PortalSDP/entidad/Direccionamientoestrategico/misioVision

https://www.openldap.org/doc/admin24/

http://www.eumed.net/

diseño e implementación de una aplicación web para el...

Documents