DISEÑO Y DESARROLLO DE LA SOLUCIÓN DE SOFTWARE DE

GESTIÓN DE ESPACIOS FÍSICOS EN LA UNIVERSIDAD DISTRITAL

Javier Sebastián Reyes Mogollón, ingjsreyesm@gmail.com

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS 

Bogotá D.C, 2017 

1

DISEÑO Y DESARROLLO DE LA SOLUCIÓN DE SOFTWARE DE

GESTIÓN DE ESPACIOS FÍSICOS EN LA UNIVERSIDAD DISTRITAL

Trabajo de grado presentado para optar por el título de:

INGENIERO DE SISTEMAS

Director Interno: Alejandro Daza

Director Externo: John Castellanos

Revisor:

José Álvarez

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

Bogotá D.C, 2017

2

3

TABLA DE CONTENIDO

INTRODUCCIÓN 9

CAPÍTULO 1. PLANTEAMIENTO DEL PROBLEMA 11

CAPÍTULO 2. OBJETIVOS 12 2.1. Objetivo general 12 2.2. Objetivos específicos 12

CAPÍTULO 3. JUSTIFICACIÓN 13

CAPÍTULO 4. MARCO REFERENCIAL 14

4.1 Oficina Asesora de Planeación y Control 14

CAPÍTULO 5. MARCO TEÓRICO 16

5.1 El Kanban 16

5.2 Api Rest 20

5.3 Selenium 22

5.3.1 Definición 22

5.3.2 Características 23

5.3.3 Ventajas 23

5.4 JMeter 23

5.4.1 Definición 23

CAPÍTULO 6. ALCANCES Y LIMITACIONES 25

CAPÍTULO 7. METODOLOGÍA 26

CAPÍTULO 8. RECURSOS 30

CAPÍTULO 9. PRESUPUESTO 32

CAPÍTULO 10. CRONOGRAMA 33

CAPÍTULO 11. DESARROLLO 34

CAPÍTULO 12. TRABAJOS FUTUROS 52

CONCLUSIONES 53

BIBLIOGRAFÍA 54

4

LISTA DE FIGURAS

5-1: Bermejo, Marcos(2010), ilustracion Gestión equipo según Kanban,recuperado de https://www.exabyteinformatica.com

5-2: Bermejo, Marcos(2010), ilustración Flujo de trabajo vs Prioridad,recuperado de https://www.exabyteinformatica.com

6-1: Oficina Asesora de Sistemas, Arquitectura de referencia, ilustración recuperada de: https://tuleap.udistrital.edu.co

6-2: Oficina Asesora de sistemas,Herramientas utilizadas en componentes de la arquitectura de referencia, ilustración recuperada de: https://tuleap.udistrital.edu.co

10-1: Reyes, Javier, (2017) Cronograma del proyecto.

11-1: Reyes, Javier, (2017) Tableros metodología KANBAN.

Tomado de: https://tuleap.udistrital.edu.co/plugins/agiledashboard/?group_id=161

11-2: Reyes, Javier, (2017) Diagrama macro de asignar dependencia

11-3: Reyes, Javier, (2017) Diagrama detallado de asignar dependencia

11-4: Reyes, Javier, (2017) Registro dependencia version 1.

11-5: Reyes, Javier, (2017) Registro dependencia version 2.

11-6: Reyes, Javier, (2017) Consultar dependencia version 1.

11-7: Reyes, Javier, (2017) Consultar dependencia version 2.

11-8: Reyes, Javier, (2017) Recuperar dependencia version 1.

11-9: Reyes, Javier, (2017) Recuperar dependencia version 2.

11-10: Reyes, Javier, (2017) Registrar edificio version 1.

11-11: Reyes, Javier, (2017) Registrar edificio version 2.

11-12: Reyes, Javier, (2017) Consultar edificio version 2.

11-13: Reyes, Javier, (2017) Consultar edificio version 2

11-14: Reyes, Javier, (2017) Recuperar edificio version 1.

11-15: Reyes, Javier, (2017) Recuperar edificio version 2.

11-16: Reyes, Javier, (2017) Registrar Espacio Físico version 1.

11-17: Reyes, Javier, (2017) Registrar Espacio Físico version 1.

11-18: Reyes, Javier, (2017) Consultar Espacio Físico version 1.

11-19: Reyes, Javier, (2017) Consultar Espacio Físico version 2.

11-20: Reyes, Javier, (2017) Consultar Espacio Físico version 1.

11-21: Reyes, Javier, (2017) Consultar Espacio Físico version 2

11-22: REGISTRO SEDE VERSIÓN 2

5

11-23: CONSULTAR SEDE VERSIÓN 1

11-24: CONSULTAR SEDE VERSIÓN 2

11-25: RECUPERAR SEDE VERSIÓN 1

11-26: RECUPERAR SEDE VERSIÓN 2

11-27: Reyes, Javier, (2017) Arquitectura de información para OIKOS.

11-28: Reyes, Javier, (2017) Modelo de datos OIKOS.

11-29: Reyes, Javier, (2017) Espacio físico.

11-30: Reyes, Javier, (2017) Tipo uso.

11-31: Reyes, Javier, (2017) Tipo uso espacio físico.

11-32: Reyes, Javier, (2017) Tipo espacio físico.

11-33: Reyes, Javier, (2017) Espacio físico padre.

11-34: Reyes, Javier, (2017) Dependencia.

11-35: Reyes, Javier, (2017) Dependencia padre.

6

LISTA DE TABLAS

8-1. Recursos del proyecto.

9-1. Presupuesto del proyecto.

11-1: Descripción entidad espacio_fisico.

11-2: Descripción entidad tipo_uso.

11-3: Descripción entidad tipo_uso_espacio_fisico.

11-4: Descripción entidad tipo_espacio_fisico.

11-5: Descripción entidad espacio_fisico_padre

11-6: Descripción entidad dependencia.

11-7: Descripción entidad dependencia padre.

7

INTRODUCCIÓN La Universidad Distrital Francisco José de Caldas es un ente autónomo de Educación Superior que se fundó en el año 1948, su misión se centra en las funciones de docencia, investigación y extensión. Dentro de la institución se cuenta con la necesidad de una correcta gestión de procesos donde el software toma un papel relevante ya que permite llevar a cabo actividades imprescindibles que infieren en el funcionamiento y consecución de resultados en la universidad. La gestión de espacios físicos se dimensiona dentro de la utilidad de poder conocer con qué espacios cuenta la universidad en cuestión de lugares tanto administrativos como académicos en la totalidad de la universidad, para ello es necesario un software donde se puedan registrar espacios con los distintos atributos y entidades que puede tener un modelo acorde a las características de la universidad. Con el fin de realizar mejoras y congruencias de unificación en el proceso de gestión de espacios físicos de la universidad distrital, la Oficina Asesora de Sistema (OAS), en su potestad de crear nuevas soluciones de software para el ente educativo, crea el proyecto denominado “Solución de software para apoyar el proceso de gestión de espacios físicos de la universidad Distrital”, realizando un proceso de llamado y selección a estudiantes de últimos semestres que cursan ingeniería de sistemas que deseen participar en el mismo, donde finalmente se cuenta con 9 integrantes divididos en subproyectos correspondientes a: gestión de requerimientos, arquitectura de software y desarrollo de software, a cargo de los roles respectivos de analistas, arquitectos y desarrolladores. Este proyecto en el que se participará con el rol de Analista y desarrollador, tiene como objetivo analizar, diseñar y construir una solución modular, integral y escalable que permita apoyar los procesos relacionados a la gestión de espacios físicos de la Universidad Distrital soportado en tecnologías libres siguiendo el proceso de desarrollo bajo la metodología Kanban. El Software que maneja la Universidad Distrital para soportar los proceso de la dependencia de planeación para la gestión de espacios físicos muestra como principal problemática la desactualización normal que posee cualquier software y la integrabilidad, no acomodación del mismo a los procesos y procedimientos de la Universidad. El proyecto plantea dotar a la Universidad Distrital Francisco José de Caldas de un sistema de información de la dependencia de planeación que supla las particularidades en el manejo de la información para la gestión de espacios y su articulación con el sistema integrado de información de la universidad, que pueda mantener y adaptar la misma institución y que esté acorde a las nuevas tecnologías de la información y las comunicaciones como los son Web services.

8

Para ello se presenta una propuesta con los módulos que tendrá el sistema, la arquitectura que se manejará y los costos tanto humanos como de infraestructura desde su etapa de concepción hasta la estabilización y puesta total en producción, se aclara que se entregarán periódicamente módulos funcionales del sistema para que entren en funcionamiento de manera iterativa.

9

CAPÍTULO 1. PLANTEAMIENTO DEL PROBLEMA El orden de los espacios físicos de la universidad Distrital se establece con la correcta gestión e información actualizada sobre lo que cuenta la universidad para el desarrollo de sus actividades de la comunidad universitaria, esto contempla espacios físicos de tipo académico como de tipo administrativo, dicha información va relacionada con los recursos que los estudiantes y funcionarios de la universidad pueden acaparar en sus actividades, por ello se hace necesario un software que contemple de manera adaptable, eficaz y eficiente todos aquellos procesos pertenecientes a la gestión de espacios físicos. Es necesario por parte de los trabajadores de la universidad contar con dicho software que provea información estructurada completa y actualizada sobre los espacios físicos que cuenta la universidad, que satisfaga las necesidades pertinentes, que provea consultas que pueden dar concisa respuesta a los requerimientos de los involucrados, esto con el fin de hacer los procesos más rápidos y eficaces. Debido a que el sistema de información actual fue concebido para manejar la información de forma propia de acuerdo a las necesidades de la dependencia de planeación y no de forma integrada, se han presentados varios problemas con la calidad de la información que maneja. Estos y otros problemas han sido evidenciados en diversas auditorías que se han hecho al interior de la Universidad y también por entes externos a la misma institución. ¿Cómo integrar un sistema de información con arquitectura orientada a servicios que se articule con los demás sistemas y permitir la gestión de los espacios físicos académicos y administrativos por parte de la dependencia de planeación?. El sistema de información para la gestión de espacios físicos es una solución para los requerimientos de la dependencia de planeación que permitirá un mejor acceso a la información de los espacios físicos con los que cuenta la universidad, esto con tecnologías que dan respuesta a las características de un software moderno y eficiente como son los web services.

10

CAPÍTULO 2. OBJETIVOS

2.1. Objetivo general Desarrollar una solución modular, integral y escalable, que permita apoyar los procesos relacionados a la gestión de espacio físicos de la Universidad Distrital, soportado en tecnologías libres de acuerdo a los estándares definidos por la OAS (Oficina Asesora de Sistemas).

2.2. Objetivos específicos

● Establecer mecanismos de acceso, consulta y modificación de datos respecto a los espacios físicos y organigrama institucional de la Universidad Distrital con el fin de optimizar la gestión de estos.

● Definir un modelo de datos único de espacios físicos y organigrama institucional que

soporte los procesos de gestión de la información.

● Articular la solución de software con los servicios ya implementados en la OAS, con el fin de integrar la información.

● Definir un ciclo de pruebas para la solución de software que se enmarque en la

consecución de la calidad del sistema a integrar.

11

CAPÍTULO 3. JUSTIFICACIÓN Debido a que la universidad cuenta con un sistema de espacios físicos antiguo con errores de diseño en el modelo de base de datos, se busca solucionar el problema de la gestión de espacios físicos con un nuevo software utilizando tecnologías modernas, con el fin de elaborar y contemplar las nuevas necesidades de la universidad en cuanto a crecimiento de los espacios físicos. El proyecto de gestión de espacios físicos se lleva a cabo de acuerdo al requerimiento de modernización de los sistemas de información actuales; teniendo en cuenta que el antiguo sistema tiene una arquitectura monolítica, que funciona aisladamente y no se integra con todas las herramientas, por tanto al no integrarse con los sistemas actuales de la universidad su funcionamiento se ve limitado y no comparte a nivel de diseño las características deseables de un óptimo sistema de información ya que tiene un diseño de base de datos no normalizado, por tal razón con el nuevo sistema de información se pretende dar una solución de software coherente con las necesidades actuales con tecnologías validadas por la OAS que convergen a una planeación de arquitectura dinámica y escalable.

12

CAPÍTULO 4. MARCO REFERENCIAL

4.1 Oficina Asesora de Planeación y Control La dependencia Oficina Asesora de Planeación y Control tiene como misión: Coordinar y orientar el diseño y la implementación de Políticas, Planes, Programas y Proyectos, brindando métodos, procedimientos y herramientas técnicas que apoyen a la toma de decisiones y permitan responder adecuadamente a los cambios del entorno y el desarrollo de la Universidad.

4.1.1¿Qué es la planeación?

En el Plan Estratégico de Desarrollo se materializa los cambios en las relaciones de poder y los recursos (financieros, económicos, culturales y tecnológicos) para consolidar el ser y proyectar el devenir de la Universidad.

4.1.2 ¿Cuáles son las dimensiones del proceso de planeación?

1. Definición de los fines y los objetivos colectivos de mediano y largo plazo de la universidad: La planeación implica una identificación y definición de una idea de futuro representada a través de objetivos de mediano y largo plazo que recogen los intereses de los diferentes grupos en disputa. Estos objetivos señalan las líneas de la discusión y proyectan los requerimientos y asignación de recursos de la universidad. Los enfoques de prospectiva pueden ser útiles para establecer estos objetivos de mediano y largo plazo, las cuales están influenciadas por los objetivos.

2. Distribución de la incertidumbre: La planeación afecta los flujos de información en la comunidad universitaria, es decir, la planeación afecta la disponibilidad de la información, las formas de comunicación, las dependencias encargadas de su flujo y las personas que tienen acceso a ella. En consecuencia, la planeación distribuye la incertidumbre entre las personas de la comunidad universitaria, esta distribución puede ser desigual o igualitaria y depende de la idea de futuro.

3. Distribución de las responsabilidades: Otra de las dimensiones sobre las cuales se representa la distribución del poder, está relacionada con las responsabilidades que se establecen en los procesos de planeación. En los procesos de planeación se redistribuyen las cargas en la universidad.

4. Cambios en los roles sociales: Los planes crean y altera los roles sociales y las oportunidades de los grupos de interés en la toma de decisiones en la universidad.

13

Por ejemplo, la creación de un comité o una nueva dependencia en las universidades implica nuevas funciones, limitaciones, posibilidades y relaciones.

4.1.3 Sobre el proyecto educativo institucional y planeación

El Proyecto Educativo Institucional (PEI) y los Planes de Desarrollo son dos elementos fundamentales para la gobernanza de las Universidades. En el Proyecto Educativo Institucional se concreta el ser de la Universidad (presente) y la Universidad que quiere ser (futuro) a partir de su desarrollo histórico (pasado).

14

CAPÍTULO 5. MARCO TEÓRICO

5.1 El Kanban

5.1.1 Definición Kanban (en kanji, donde kan significa "visual", y ban significa "tarjeta" o "tablero") es un concepto de producción justo-a-tiempo (JIT). El kanban es una tarjeta física que se utiliza en el Sistema de Producción de Toyota (TPS - Toyota Production System) para soportar un control productivo descentralizado por demanda (“pull”). Kanban es una herramienta proveniente de la filosofía Lean, de tipo “pull”, lo que significa que los recursos deciden cuándo y cuánto trabajo se comprometen a hacer. Los recursos toman (“pull”) el trabajo cuando están listos, en lugar de tener que recibirlo (“push”) desde el exterior. Al igual que una impresora tira en la página siguiente sólo cuando está lista para imprimir sobre ella. Kanban se basa en la optimización de procesos continuos y empíricos, que se corresponde con el principio de Kaizen Lean. Enfatiza la respuesta al cambio por sobre seguir un plan (generalmente Kanban permite una respuesta más rápida que Scrum). El Kanban es un sistema de gestión donde se produce exactamente aquella cantidad de trabajo que el sistema es capaz de asumir. El Kanban es un sistema de gestión del trabajo en curso, que sirve principalmente para asegurar una producción continua y sin sobrecargas en el equipo de producción multimedia. El Kanban es un sistema de gestión donde se produce exactamente aquella cantidad de trabajo que el sistema es capaz de asumir. El Kanban es un sistema de trabajo just in time, lo que significa que evita sobrantes innecesarios de stock, que en la gestión de proyectos multimedia equivale a la inversión innecesaria de tiempo y esfuerzo en lo que no necesitaremos (o simplemente es menos prioritario) y evita sobrecargar al equipo. El Kanban es una aproximación a la gestión del cambio organizativo, no es un proceso de desarrollo de productos multimedia o de gestión de proyectos. El Kanban es una aproximación a la introducción de cambios en el ciclo de vida de desarrollo de productos multimedia o metodología de gestión de proyectos ya existente. Con el Kanban, se empieza con algo en lo que estás ahora mismo en la gestión de nuestro equipo de producción. No hay que empezar de cero en la organización de una empresa para adoptar el Kanban. En la gestión del trabajo en curso con Kanban, se busca un concepto clave como es limitar el trabajo en curso. Está demostrado que, cuanto más trabajo en curso se gestione a la vez, los índices de calidad disminuyen drásticamente. En la producción de proyectos multimedia, aumentar el trabajo en curso implica aumentar la cantidad de errores que este proyecto multimedia tendrá como consecuencia de la poca capacidad de concentración que los desarrolladores podrán dedicar a las tareas. Limitar el WIP implica un aumento considerable de la calidad del software generado en la producción de un proyecto multimedia. Limitar el trabajo en curso mediante la gestión del trabajo con Kanban también tiene una consecuencia importante y es que disminuimos el tiempo de servicio de una tarea desde que entra al sistema hasta que sale. Disminuyendo la cantidad de trabajo en curso, conseguimos que el enfoque en cada una de las tareas sea mayor y que el tiempo dedicado a todas ellas, sumado, sea menor que el empleado en asumirlas todas de golpe.

15

5.1.2 Funcionamiento del kanban Visualiza el “Workflow” Divide el trabajo en piezas, y escribe cada una de ellas en tarjetas que se colocan en el tablero (“kanban board”). o Utiliza columnas con nombres para ilustrar dónde se encuentra dentro del proceso o workflow cada ítem o tarea. Limita el “WIP” (work in progress) – asigna limites específicos de cuantos items pueden estar siendo procesados a la vez dentro de cada columna del workflow. Mide el “Lead Time” (también llamado “Cycle Time”) es el tiempo promedio para completar un item, o sea, que el mismo haya pasado por todas las columnas del workflow hasta llegar al final. El Kanban tiene por objetivo optimizar el proceso para hacer el lead time lo más pequeño y predecible que se pueda.

5.1.3 Aplicación práctica del kanban Para hacer más comprensible la aplicación práctica del Kanban, en este apartado vamos a imaginar un caso típico de la producción de proyectos multimedia, donde tenemos un equipo dedicado a dar servicio de esta clase de productos. En concreto, el servicio que proporciona este equipo se basa en el desarrollo de pequeñas tareas evolutivas de un producto ya instalado en casa del cliente. Nuestro equipo trabaja para diferentes clientes, que tienen contratado un servicio de mantenimiento donde desarrolla estos pequeños plug-ins a medida que los clientes van pidiendo. El equipo está dividido en tres programadores, uno de ellos es analista-programador (el que tiene más experiencia) y un técnico experto en sistemas, este último es el que se dedica a solucionar problemas relacionados con configuraciones de servidor, además de pasar la fase de pruebas y calidad. Supongamos que la realidad actual de este equipo es algo caótica. Están trabajando en varias tareas previstas para el mes que viene, además, día a día apagan varios fuegos debido a errores en desarrollos anteriores y podemos decir que el tiempo dedicado a testear es más bien corto, debido a las constantes tomas para cumplir los tiempos de entrega. Las predicciones y fechas de entrega no sirven, ya que se ven rotas por tareas más urgentes que les roban tiempo.

5-1: Bermejo, Marcos(2010), ilustracion Gestión equipo según Kanban,recuperado de

https://www.exabyteinformatica.com

16

Entras en este equipo y nos piden gestionarlo. Por suerte, conoces el Kanban y empiezas a aplicarlo. Lo primero que tenemos que hacer en este equipo es representar su realidad actual de forma visual. La forma más habitual de aplicar el Kanban en la producción de productos multimedia es mediante el visual management, es decir, la representación visual del flujo de trabajo mediante paneles que tienen que reflejar la realidad del equipo en cada instante.

● Tenemos que dar luz a todas las fases por las que pasan las tareas desde que entran en el sistema hasta que salen.

● Representar visualmente las tareas que el equipo está llevando a cabo ahora

mismo.

● Aporta mucha información visual indicar qué miembro del equipo está ejecutando cada tarea.

Asegurate de que el panel Kanban refleja las fases, las tareas y el equipo. Un panel Kanban típico se implementaría tal como se muestra en la imagen siguiente:

5-2: Bermejo, Marcos(2010), ilustración Flujo de trabajo vs Prioridad

,recuperado de https://www.exabyteinformatica.com

En esta imagen se observa un panel constituido por tres columnas, que representan las diferentes fases por las que una tarea tiene que fluir para ser desarrollada (análisis, desarrollo y puesta en marcha). Cada fase está subdividida en dos estados, que son en curso y lista, para pasar a la siguiente fase; esta división está representada por la línea discontinua de cada fase. El estado en curso significa que el equipo está actualmente trabajando en esta tarea, en esta fase y el estado lista significa que el equipo ya ha acabado el trabajo que tenía que ejecutar en esta fase y la tarea está esperando a que el sistema pueda asumirla para la siguiente fase. Esta división ayuda a localizar atascos en el proceso

17

de producción, se aprenderá más adelante en el módulo. Las filas podrían ser diferentes proyectos en los que la empresa está trabajando, pero lo más habitual es que las filas indiquen prioridad, donde las tareas más superiores son las más prioritarias. Separar en cada fase las tareas en el estado en curso y lista ayuda a localizar atascos en el proceso de producción de productos multimedia. El panel Kanban tiene que ser estudiado y juzgado en cada iteración para detectar fases que falten o sobren. Nunca hay que adoptar un panel como solución universal. En la gestión del trabajo en curso con Kanban, no existe un único modelo de panel adecuado para todos los equipos ni que cumpla todas las necesidades de la empresa. Un error frecuente de aquellos que empiezan a implantar Kanban en el equipo es intentar adoptar las fases de un modelo de panel externo en la realidad de la producción de su equipo. No se trata de cambiar las fases por otras, sino de estudiarlas, comprenderlas y hacerlas visibles. Cuando se adopta Kanban, el panel tiene que ser construido y mejorado constantemente. En la gestión ágil de proyectos, una de las claves fundamentales es la iteración constante y la mejora a cada iteración. Como buenos agilistas, el panel Kanban tiene que ser estudiado y juzgado en cada iteración para detectar fases que falten o sobren. En el Kanban no existe un único modelo de panel adecuado para todos los equipos ni todas las situaciones. Simplemente representa de forma fiel la producción del equipo. Al acabar el primer mes como jefe de proyecto en el equipo del ejemplo presentado en la introducción de este apartado, se tiene un bonito panel Kanban en una de las paredes de la sala donde tenemos representada la realidad de nuestro equipo. El equipo lo mantiene actualizado de forma constante para que realmente represente el estado actual de los proyectos en curso. En el panel del ejemplo, tenemos tareas que fluyen de izquierda a derecha de la siguiente manera:

• Los dos programadores están actualmente produciendo la funcionalidad de D, E y F en simultáneo. A la vez, el experto de sistemas está testeando en la actualidad la funcionalidad M. • Mientras tanto, el analista-programador ha hecho el análisis y la estimación de algunas tareas nuevas que les han encomendado, esta estimación es muy importante, puesto que en ella se basa el presupuesto que la empresa hace de las tareas que el equipo lleva a cabo. • A medida que el tiempo va pasando, los dos programadores van desarrollando a buen ritmo, tienen acabados seis módulos y están programando otros. • El experto en sistemas está teniendo problemas, el módulo M no pasa algunos de los requerimientos de calidad de la empresa y solo él sabe cómo se hace, además, tiene problemas para instalar algunas tareas ya terminadas (N) en algunos clientes debido a la configuración de sus servidores

18

• Solo una tarea ha sido registrada como finalizada en este mes (la tarea O) y, por lo tanto, solo un cliente ha recibido su petición con éxito. El panel Kanban parece que señala el problema clave del equipo: ¿por qué seguimos programando más y más funcionalidades cuando muy pocas salen del sistema? En definitiva: Un porcentaje muy bajo del esfuerzo y tiempo del equipo se está convirtiendo finalmente en ingresos y satisfacción del cliente.

5.2 Api Rest

5.2.1 Definición REST cambió por completo la ingeniería de software a partir del 2000. Este nuevo enfoque de desarrollo de proyectos y servicios web fue definido por Roy Fielding, el padre de la especificación HTTP y uno los referentes internacionales en todo lo relacionado con la Arquitectura de Redes, en su disertación ‘Architectural Styles and the Design of Network-based Software Architectures’. En el campo de las APIs, REST (Representational State Transfer- Transferencia de Estado Representacional) es, a día de hoy, el alfa y omega del desarrollo de servicios de aplicaciones. En la actualidad no existe proyecto o aplicación que no disponga de una API REST para la creación de servicios profesionales a partir de ese software. Twitter, YouTube, los sistemas de identificación con Facebook… hay cientos de empresas que generan negocio gracias a REST y las APIs REST. Sin ellas, todo el crecimiento en horizontal sería prácticamente imposible. Esto es así porque REST es el estándar más lógico, eficiente y habitual en la creación de APIs para servicios de Internet.

Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que use HTTP para obtener datos o generar operaciones sobre esos datos en todos los formatos posibles, como XML y JSON. Es una alternativa en auge a otros protocolos estándar de intercambio de datos como SOAP (Simple Object Access Protocol), que disponen de una gran capacidad pero también mucha complejidad. A veces es preferible una solución más sencilla de manipulación de datos como REST.

5.2.2 Características

● Protocolo cliente/servidor sin estado: cada petición HTTP contiene toda la información necesaria para ejecutarla, lo que permite que ni cliente ni servidor necesiten recordar ningún estado previo para satisfacerla. Aunque esto es así, algunas aplicaciones HTTP incorporan memoria caché. Se configura lo que se conoce como protocolo cliente-caché-servidor sin estado: existe la posibilidad de definir algunas respuestas a peticiones HTTP concretas como cacheables, con el objetivo de que el cliente pueda ejecutar en un futuro la misma respuesta para

19

peticiones idénticas. De todas formas, que exista la posibilidad no significa que sea lo más recomendable.

● Las operaciones más importantes relacionadas con los datos en cualquier sistema

REST y la especificación HTTP son cuatro: POST (crear), GET (leer y consultar), PUT (editar) y DELETE (eliminar).

● Los objetos en REST siempre se manipulan a partir de la URI. Es la URI y ningún

otro elemento el identificador único de cada recurso de ese sistema REST. La URI nos facilita acceder a la información para su modificación o borrado, o, por ejemplo, para compartir su ubicación exacta con terceros.

● Interfaz uniforme: para la transferencia de datos en un sistema REST, este aplica

acciones concretas (POST, GET, PUT y DELETE) sobre los recursos, siempre y cuando estén identificados con una URI. Esto facilita la existencia de una interfaz uniforme que sistematiza el proceso con la información.

● Sistema de capas: arquitectura jerárquica entre los componentes. Cada una de

estas capas lleva a cabo una funcionalidad dentro del sistema REST.

● Uso de hipermedios: hipermedia es un término acuñado por Ted Nelson en 1965 y que es una extensión del concepto de hipertexto. Ese concepto llevado al desarrollo de páginas web es lo que permite que el usuario puede navegar por el conjunto de objetos a través de enlaces HTML. En el caso de una API REST, el concepto de hipermedia explica la capacidad de una interfaz de desarrollo de aplicaciones de proporcionar al cliente y al usuario los enlaces adecuados para ejecutar acciones concretas sobre los datos.

● Para cualquier API REST es obligatorio disponer del principio HATEOAS

(Hypermedia As The Engine Of Application State - Hipermedia Como Motor del Estado de la Aplicación) para ser una verdadera API REST. Este principio es el que define que cada vez que se hace una petición al servidor y éste devuelve una respuesta, parte de la información que contendrá serán los hipervínculos de navegación asociada a otros recursos del cliente.

5.2.3 Ventajas

1. Separación entre el cliente y el servidor: el protocolo REST separa totalmente la interfaz de usuario del servidor y el almacenamiento de datos. Eso tiene algunas ventajas cuando se hacen desarrollos. Por ejemplo, mejora la portabilidad de la interfaz a otro tipo de plataformas, aumenta la escalabilidad de los proyectos y permite que los distintos componentes de los desarrollos se puedan evolucionar de forma independiente.

20

2. Visibilidad, fiabilidad y escalabilidad. La separación entre cliente y servidor tiene una ventaja evidente y es que cualquier equipo de desarrollo puede escalar el producto sin excesivos problemas. Se puede migrar a otros servidores o realizar todo tipo de cambios en la base de datos, siempre y cuando los datos de cada una de las peticiones se envían de forma correcta. Esta separación facilita tener en servidores distintos el front y el back y eso convierte a las aplicaciones en productos más flexibles a la hora de trabajar.

3. La API REST siempre es independiente del tipo de plataformas o lenguajes: la API

REST siempre se adapta al tipo de sintaxis o plataformas con las que se estén trabajando, lo que ofrece una gran libertad a la hora de cambiar o probar nuevos entornos dentro del desarrollo. Con una API REST se pueden tener servidores PHP, Java, Python o Node.js. Lo único que es indispensable es que las respuestas a las peticiones se hagan siempre en el lenguaje de intercambio de información usado, normalmente XML o JSON.

5.3 Selenium

5.3.1 Definición

La automatización de pruebas que consiste en utilizar una herramienta de software para ejecutar las pruebas repetibles en contra de la aplicación a ensayar. Para las pruebas de regresión esta establece que la capacidad de respuesta.

Selenium es un entorno de pruebas de software para aplicaciones basadas en la web. Selenium provee una herramienta llamada (Selenium IDE) para crear pruebas sin usar un lenguaje de scripting. Incluye también un lenguaje específico de dominio para pruebas para escribir pruebas en un amplio número de lenguajes de programación populares incluyendo Java, C#, Ruby, Groovy, Perl, Php y Python. Las pruebas pueden ejecutarse entonces usando la mayoría de los navegadores web modernos en diferentes sistemas operativos como Windows, Linux y OSX.

Es definido también como un conjunto de herramientas de software diferentes, cada uno con un enfoque diferente para el apoyo a la automatización de pruebas. La mayoría de los ingenieros del QA de selenium se centran en uno o dos herramientas que la mayoría satisfacer las necesidades de su proyecto, sin embargo el aprendizaje de todas las herramientas le dará muchas opciones diferentes para abordar diferentes problemas de automatización de pruebas. Todo el conjunto de herramientas se traduce en un amplio conjunto de funciones de prueba dirigidos específicamente a las necesidades de las pruebas de aplicaciones web de todo tipo. Estas operaciones son muy flexibles, lo que permite muchas opciones para la localización de elementos de la interfaz y la comparación de los resultados esperados de la prueba contra el comportamiento de la aplicación real. Una de las características clave de selenium es el apoyo para la ejecución de las pruebas de uno en múltiples plataformas de navegadores.

21

5.3.2 Características El selenium se compone de múltiples herramientas de software, las cuales varían en sus características.

Selenium 2

Es la dirección futura del proyecto y la nueva adición a la caja de herramientas de selenio. Esta nueva herramienta de automatización ofrece todo tipo de características impresionantes, incluyendo una API más coherente y orientado a objetos, así como una respuesta a las limitaciones de la aplicación de edad.

5.3.3 Ventajas La automatización de pruebas tiene ventajas específicas para la mejora de la eficacia a largo plazo de los procesos de prueba de un equipo de software. La automatización de pruebas es compatible con:

● Pruebas de regresión frecuentes. ● Una rápida retroalimentación a los desarrolladores. ● Iteraciones prácticamente ilimitadas de ejecución de casos de prueba. ● Soporte para Ágil y metodologías de desarrollo extremas. ● Documentación disciplinado de casos de prueba. ● Notificación de defectos personalizado. ● Encontrar defectos pasados por alto por las pruebas manuales.

5.4 JMeter

5.4.1 Definición Es una aplicación de software de código abierto, una aplicación Java puro 100% diseñado para cargar la conducta funcional de prueba y medida de rendimiento. Fue diseñado originalmente para aplicaciones Web de prueba, pero desde entonces se ha expandido a otras funciones de prueba. Jmeter se puede utilizar para probar el rendimiento tanto en recursos estáticos y dinámicos, aplicaciones dinámicas Web. Se puede utilizar para simular una carga pesada en un servidor, grupo de servidores, la red o el objeto a probar su resistencia o para analizar el rendimiento general bajo diferentes tipos de carga.

22

Jmeter características incluyen: ● Capacidad de cargar y pruebas de rendimiento muchos tipos diferentes aplicaciones

/ servidor / protocolo: ○ Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ...) ○ SOAP / REST Servicios Web. ○ FTP. ○ Base de datos a través de JDBC. ○ LDAP. ○ Middleware orientado a mensajes (MOM) a través de JMS. ○ Correo - SMTP (S), POP3 (S) e IMAP (S). ○ Comandos o scripts de shell nativa. ○ TCP. ○ Objetos Java.

● IDE con todas las funciones de prueba que permite Plan de prueba rápida de

grabación (de navegadores o aplicaciones nativas), construcción y depuración . ● El modo de línea de comandos (modo sin cabeza para no GUI /) para cargar de

prueba desde cualquier sistema operativo compatible con Java (Linux, Windows, Mac OS X, ...).

● Una completa y el informe listo para presentar HTML dinámico. ● Fácil de correlación a través de la capacidad para extraer datos de la mayoría de los

formatos de respuesta populares, HTML , JSON , XML o formato de cualquier texto ● La portabilidad completa y 100% de pureza de Java. ● Completa multi-threading marco permite el muestreo simultáneo de muchos hilos y

muestreo simultáneo de funciones diferentes por grupos de hilos separados. ● El almacenamiento en caché y fuera de línea de análisis / Reproducción de

resultados de la prueba. ● Núcleo altamente extensible:

○ Samplers enchufables permiten capacidades de prueba ilimitadas. ○ Samplers de secuencias de comandos (idiomas compatible con JSR223

como Groovy y BeanShell). ○ Varias estadísticas de carga se pueden elegir con temporizadores

enchufables. ○ Análisis de datos y visualización plugins permiten una gran extensibilidad, así

como la personalización. ○ Las funciones pueden ser utilizados para proporcionar la entrada dinámica a

una prueba o proporcionar la manipulación de datos. ○ Integración Continua fácil a través de 3 rd bibliotecas partido de código

abierto para Maven, Graddle y Jenkins.

23

CAPÍTULO 6. ALCANCES Y LIMITACIONES

6.1 Alcances Para el proyecto se pretende desarrollar un sistema propio para la Universidad, que permita ser mantenido y adaptado a las particularidades que la institución tenga, el proyecto contempla todas las etapas del ciclo de vida del desarrollo del software usando la metodología kanban. Se va a desarrollar un sistema que permita gestionar los espacios físicos administrativos de la universidad y organigrama institucional, permitiendo insertar, modificar y eliminar información de uso propio de la institución, se podrán hacer consultas y revisiones de cómo está organizada en cuestión de espacios físicos y organigrama la universidad. El desarrollo de este sistema va desde el levantamiento de requerimientos, consecución de modelos, estudios de articulación con otros sistemas de la institución, despliegue en pruebas y las fases necesarias para su correcta consecución con una sólida etapa de pruebas unitarias. Se llevará a cabo la migración del modelo, generación de servicios REST, clientes estáticos y basado en integración continua.

6.2 Limitación Las limitaciones del proyecto son:

● Requerimientos ambiguos e información insuficiente, desordenada y sin depurar de los espacios físicos de la universidad.

● Comunicación en espacios reducidos con la dependencia de planeación y procesos

estructurados que afectan el tiempo de consecución del proyecto.

● La solución de software estará basada en los lineamientos del software libre dando respuesta a políticas distritales e institucionales.

24

CAPÍTULO 7. METODOLOGÍA El nuevo desarrollo al ser orientado a servicios, permite adoptar software de código abierto/libre, bajando el tiempo de desarrollo de las soluciones adoptadas y se integraría a las diferentes soluciones existentes (Terceros, Nómina, Contratación,Almacén, Sistema de Gestión Académica, Gestión Docente, BI) o que se encuentran en desarrollo (SSO) en la Universidad, de acuerdo, a la arquitectura adoptada por la Oficina Asesora de Sistemas. Arquitectura de referencia:

6-1:: Oficina Asesora de sistemas,Arquitectura de referencia, ilustración recuperada de:

https://tuleap.udistrital.edu.co

25

Herramientas utilizadas en los componentes de la arquitectura de referencia:

6-2: Oficina Asesora de sistemas,Herramientas utilizadas en componentes de la arquitectura de

referencia, ilustración recuperada de: https://tuleap.udistrital.edu.co Teniendo en cuenta el diseño arquitectural así como la metodología a utilizar es seguir un lineamiento de acciones en cuanto al desarrollo de la aplicación cuyas características son: Identificar las oportunidades de reutilización de código: esta actividad consiste en identificar módulos de código existente u otros elementos que puedan ser utilizados en el proceso de desarrollo del sistema, lo cual es importante para tener un manejo adecuado del diseño y desarrollo. Se debe tener siempre en consideración elementos de software libre o de propiedad de la institución manteniendo un especial cuidado por el respeto de las normas y legislación relacionada con el derecho de autor. La mejor manera de lograr que un equipo encuentre oportunidades de reciclaje es ejercitar buenas prácticas de generación de código y diseño. Entre las consideraciones a tener en cuenta se encuentra que las clases deben ser pequeñas, cohesivas y fáciles de entender para poder ofrecer oportunidades de reutilización. Se deben tener clases separadas cuando se encuentre funcionalidad que pueda ser separada, entre otras.

26

Cabe recalcar que además del código específico que un realizador está escribiendo para un proyecto específico existen otras fuentes que puede ser reutilizado, como librerías de código internas (propiedad de la institución), librerías de terceros,Librerías construidas dentro del lenguaje,ejemplos de código de tutoriales, libros, colegas, código de sistemas existentes, productos de software libre (asegurando que se siguen todos los acuerdos de licencia aplicables). Transformar el diseño en puesta en funcionamiento: Es importante utilizar herramientas de modelado sofisticadas que permiten obtener gran cantidad de código fuente directamente de la transformación de los modelos, agregando tareas de programación sobre el código generado para completar la puesta en funcionamiento. Existen varias técnicas para que de forma automática se transforme el diseño en artefactos de puesta en funcionamiento:

● Se pueden aplicar patrones estándar para generar elementos de puesta en producción y de diseño a partir de artefactos relacionados. Por ejemplo, un patrón de transformación estándar puede ser aplicado sobre tablas de datos para crear clases Java que permiten acceder a tales tablas. Otro ejemplo consiste en utilizar marcos de trabajo tales como el Eclipse Modeling Framework para generar código que almacene datos de acuerdo al modelo y que además cree interfaces de usuario para poblar tales estructuras de datos. Un motor de patrones o de transformación puede ser usado para crear la puesta en funcionamiento, o la puesta en funcionamiento puede ser hecha de forma no automatizada. Los motores de patrones son fáciles de emplear y ofrecen mayor confiabilidad. En todo caso escribir código que implemente un determinado patrón tendrá menos errores que aquel código que implemente técnicas novedosas o diseños únicos.

● Los modelos pueden ser detallados y utilizados para generar una puesta en

funcionamiento. Tanto los diagramas de estructura (diagramas de clases y diagramas de paquetes) como los de comportamiento (diagramas de colaboración, diagramas de estado y diagramas de actividades) pueden ser utilizados para generar código ejecutable. Estas versiones generadas podrán ser refinadas de acuerdo a las necesidades.

● El diseño debe ser independiente, en varios grados, de la plataforma en la cual se

implementa. Modelos de diseño específicos para una plataforma o aún el código ejecutable pueden ser generados si se aplican diferentes reglas de transformación a abstracciones de alto nivel. Este es el enfoque de la Arquitectura Conducida por Modelos que propone el Object Management Group (OMG).

● Modelos específicos para la plataforma pueden ser empleados para generar un

marco de trabajo con código incompleto. Este se enriquecerá más adelante (“a mano”) con código no especificado en el diseño o que no haya podido ser transformado.

27

En todos los casos algunas abstracciones de diseño (clases, componentes,etc)deben ser detalladas para poder ser transformadas en puesta en funcionamiento. Escribir el código fuente: Escribir el código fuente para hacer una puesta en funcionamiento que cumpla con el diseño y el comportamiento esperado. teniendo en cuenta los siguiente aspectos:

● Examinar los requerimientos: como no toda la información de los requerimientos se puede colocar en los modelos, se debe verificar lo que no se cumple en la implementación, para depurar a través de la programación directa

● Reconstruir el código para mejorar el diseño, por medio de re-adaptación, que es una técnica con la que se mejora la calidad del código a partir de pequeños, y seguros cambios

● Afine los resultados de implementaciones existentes mejorando el desempeño, la interfaz de usuario, la seguridad y otras áreas no funcionales.

Estas consideraciones se deben poner en práctica teniendo en cuenta estándares que describen varias convenciones acerca de cómo escribir el código fuente. Su principal tarea es asegurar la consistencia, calidad y una puesta en funcionamiento fácil de entender. El uso de los estándares para la escritura de código es una de las prácticas más extendidas en la práctica de realización de software y se vuelve imperativa cuando se labora en ámbitos de alta colaboración. Los grupos de desarrollo deben tener una forma estándar para nombrar y dar formato a las cosas de tal manera que el código fuente se pueda entender rápidamente y la propiedad del mismo pueda ser cambiada sin detrimento de la calidad. Idealmente los estándares para la escritura de código debe ser el resultado de un consenso entre el equipo de trabajo ya que esta tarea ayuda a la rápida adopción de los estándares. Los estándares mencionados pueden cubrir áreas como:

● Estándares para asignación de nombres: Esto incluye la forma en que se le da nombre a todos los elementos dentro del código. Cuando se cubren elementos de gran escala pueden solapar los estándares de diseño.

● Organización de los archivos: Incluye convenciones para colocar nombres a los

archivos y cómo éstos deben ser organizados dentro del árbol de directorios del sistema.

● Estándares para los comentarios: Poner demasiado énfasis en los comentarios denota una pérdida de confianza en cuanto la calidad del software que se está escribiendo. Además, se tendrá siempre una impresión de que los comentarios están desactualizados. La idea es estandarizar la forma en la cual se comenta el código para soportar la capacidad de soporte y la capacidad de generar documentación a partir del código.

28

● Convenciones para la escritura de código: Aplicación de convenciones específicas a nivel de código.

● Espacio en blanco: Aunque algunos autores lo consideran como de menor impacto es un hecho que el manejo adecuado de los espacios en blanco, los saltos de línea, las sangrías y las líneas en blanco facilitan la lectura del código.

● Evaluar la implementación: verificar que el funcionamiento de lo implementado

este en concordancia con el propósito por el cual fue fue construido. es un paso fundamental para evaluar la calidad del producto.

Esto se dará a medida que se realicen las respectivas pruebas funcionales y no funcionales que permitan tener un acercamiento a la calidad del software implementado en concordancia con las especificaciones del usuario, teniendo en cuenta que dichas pruebas harán parte de la gestión de cambios del proyecto.

● Comunicar decisiones importantes: Comunicar rápidamente el impacto de cambios no esperados en el diseño o los requerimientos. Los problemas y restricciones que no se hayan tenido en consideración deben ser comunicados al equipo de desarrollo. El impacto de problemas descubiertos durante la puesta en funcionamiento deben ser incorporados para las decisiones futuras. Esto se llevará a cabo a través de comunicación continua entre los grupos de trabajo y además cada una de las decisiones deberá ser incluida en los documentos de gestión de cambios para mantener la información registrada y al alcance de todos los involucrados.

29

CAPÍTULO 8. RECURSOS Se contempla en la Tabla 1, los recursos que se estiman serán necesarios en el proceso de desarrollo a la solución de software mediante el rol desarrollador. Recursos del Proyecto

Tipo de Recurso Recurso Cantidad

Humano Desarrollador 2

Infraestructura Computador 1

Infraestructura Control de versiones y avance del proyecto en

Tuleap.

1

Infraestructura Servidor de aplicaciones para pruebas y servidor de

bases de datos

1

Infraestructura Almacenamiento disponible en google drive para

guardar documentación

1 Giga

Tiempo Meses 6

8-1. Recursos del proyecto.

30

CAPÍTULO 9. PRESUPUESTO El presupuesto que se contempla desde el punto de vista del grupo desarrollador se evidencia en la tabla 2, expresada de la siguiente manera: Presupuesto del proyecto, rol desarrollador.

Tipo de Recurso

Recurso Cantidad Tiempo Valor mensual unitario

Valor cuatrimestral

unitario

Valor total

Humano Desarrollador 2 4 meses 3.000.000 12.000.000 24.000.000

Humano DBA 1 4 meses 3.000.000 12.000.000 12.000.000

Humano Scrum master 1 4 meses 3.895.000 15.580.000 15.580.000

Humano Product owner 1 4 meses 5.000.000 20.000.000 20.000.000

Infraestructura Servidor de desarrollo

1 4 meses 3.000.000 12.000.000 12.000.000

Infraestructura Servicio de internet

2 4 meses 100.000 400.000 800.000

Infraestructura Alquiler de computadores

2 4 meses 200.000 800.000 1.600.000

Infraestructura Servicio de luz 2 4 meses 40.000 160.000 320.000

Transporte Transporte 2 4 meses 20.000 80.000 160.000

Varios Imprevistos, Fotocopias.

1 4 meses 2.700.000 10.800.000 10.800.000

Presupuesto Total: 96.460.000

9-1. Presupuesto del proyecto.

31

CAPÍTULO 10. CRONOGRAMA El siguiente es el cronograma a llevar a cabo para la realización del proyecto:

10-1: Reyes, Javier, (2017) Cronograma del proyecto.

32

CAPÍTULO 11. DESARROLLO 11.1 Desarrollo metodología KANBAN

De acuerdo a la metodología KANBAN y la herramienta de seguimiento Tuleap, se creó el proyecto de “Sistema de Espacios Físicos” en la cual se crearon 4 tableros “Aplicación”, “Base de datos”, “Proyecto” y “Kanban Task”, como se observa en la siguiente imagen

11-1: Reyes, Javier, (2017) Tableros metodología KANBAN.

Tomado de: https://tuleap.udistrital.edu.co/plugins/agiledashboard/?group_id=161 De acuerdo a la clasificación de la tarea se iban creando en el tablero correspondiente y se hacía pasar la tarea por las diferentes fases que se tienen establecidas en la OAS.

11.2 Integración Continua

La integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas. La integración continua se refiere en su mayoría a la fase de creación o integración del proceso de publicación de software y conlleva un componente de automatización (p. ej., CI o servicio de versiones) y un componente cultural (p. ej., aprender a integrar con frecuencia). Los objetivos claves de la integración continua consisten en encontrar y arreglar errores con mayor rapidez, mejorar la calidad del software y reducir el tiempo que se tarda en validar y publicar nuevas actualizaciones de software.

33

Anteriormente, era común que los desarrolladores de un equipo trabajasen aislados durante un largo periodo de tiempo y combinarán los cambios en la versión maestra una vez que habían completado el trabajo. Este proceso por lotes hacía que la combinación de todos los cambios en el código resultase complicada y llevase mucho tiempo. Esto se agravaba cuando numerosos errores leves se acumulaban durante mucho tiempo sin que se arreglaran. La combinación de estos factores hacía que resultase más difícil proporcionar las actualizaciones a los clientes con rapidez. Con la integración continua, los desarrolladores envían los cambios de forma periódica a un repositorio compartido con un sistema de control de versiones como Git. Antes de cada envío, los desarrolladores pueden elegir ejecutar pruebas de unidad local en el código como medida de verificación adicional antes de la integración. El servicio de integración continua detecta los envíos al repositorio compartido y crea y ejecuta de forma automática pruebas de unidad en los cambios en el código para detectar al instante cualquier error funcional o de integración. (AWS AMAZON). 11.2.1 Integración Continua en la Oficina Asesora de Sistemas En la oficina asesora de sistemas se definieron algunas herramientas que conforman el ecosistema de integración continua tales como: Jenkins, Gogs, github, travis, etc. Jenkins gestiona todas las tareas que comprenden propiamente la automatización de despliegues en los diferentes entornos, por ahora Oikos hace sus despliegues en un entorno de pruebas en una dirección local.

11.3 Diagramas BPMN

Los diagramas fueron realizados con la herramienta estandarizada en la OAS para modelar procesos como lo es Tooling, siguiendo la respectiva documentación del software se procedieron a crear los BPMN correspondientes al manejo que facilitara el aplicativo OIKOS (Espacios Físicos). Los respectivos diagramas de procesos para representar la forma en cómo se gestionan los espacios físicos y dependencias, además de cómo estas se relacionan entre sí. En el siguiente diagrama se refleja lo correspondiente a cómo se asigna un espacio físico a una dependencia teniendo en cuenta las gestión preestablecida para poder contar con el registro de cada espacio físico y dependencia respectivamente.

11-2: Reyes, Javier, (2017) Diagrama macro de asignar dependencia

.

34

Para conocer a un grado de detalle alto los subprocesos que suceden en los procesos Gestionar Espacio Físico y Gestionar Dependencia, se crea el subproceso que se lleva a cabo en cada uno de estos, con el fin de tener claro el procedimiento al “Asignar Dependencia”, tal y como se muestra en el siguiente diagrama.

11-3: Reyes, Javier, (2017) Diagrama detallado de asignar dependencia

Los BPMN fueron revisados y avalados en las constantes revisiones llevadas a cabo con los arquitectos del proyecto, quienes en momentos determinados sugirieron modificaciones y cambios con respecto a los BPMN diseñados en el transcurso del proyecto.

11.4 Diseño de Mockups

En la Oficina Asesora De Sistemas se realizaban los mockups en la herramienta Pencil, la cual estaba establecida anteriormente y en las cuales se diseñaron los primeros mockups que suplieron las necesidades del sistema de acuerdo a lo analizado, por tal razón se realizaron las diversas versiones de mockups en las cuales se evidencian las modificaciones de las interfaces del Sistema de Gestión de Espacios Físicos de la Universidad Distrital Francisco José de Caldas de la versión 1 y 2 de los mockups, adicionalmente las variaciones en cada uno de los respectivos formularios. 11.4.1 MOCKUPS DE DEPENDENCIA

11-4: Reyes, Javier, (2017) Registro dependencia version 1.

35

11-5: Reyes, Javier, (2017) Registro dependencia version 2.

En la versión 1 hay un formulario que se compone de dos campos: CÓDIGO DEPENDENCIA- NOMBRE DEPENDENCIA. Mientras que en la versión 2 se ha reemplazado el Código dependencia por: TELÉFONO DEPENDENCIA Y DEPENDENCIA PADRE.

11-6: Reyes, Javier, (2017) Consultar dependencia version 1.

11-7: Reyes, Javier, (2017) Consultar dependencia version 2.

En ésta instancia se puede identificar que la versión 1 cuenta con un motor de búsqueda de la dependencia, en la cual están las siguientes opciones: CÓDIGO DE DEPENDENCIA, NOMBRE DE DEPENDENCIA, DEPENDENCIA PADRE, MODIFICAR Y ELIMINAR. En la

36

versión 2 sin embargo cambia el código de dependencia por el TELEFÓNO DE DEPENDENCIA.

11-8: Reyes, Javier, (2017) Recuperar dependencia version 1.

11-9: Reyes, Javier, (2017) Recuperar dependencia version 2.

En la versión 1 la recuperación de la dependencia arroja una serie de datos éstos son: CÓDIGO DE DEPENDENCIA, NOMBRE DE DEPENDENCIA, DEPENDENCIA PADRE Y OPCIÓN A RESTAURAR. Mientras que en la versión 2 cambia el código de dependencia por: TELEFÓNO DE DEPENDENCIA, adicionalmente se elimina la opción; dependencia padre de la versión 1.

37

11.4.1 MOCKUPS DE EDIFICIO

11-10: Reyes, Javier, (2017) Registrar edificio version 1.

11-11: Reyes, Javier, (2017) Registrar edificio version 2.

Se mantienen formularios iguales en la versión 1 y 2, ya que no se necesitaron o surgieron cambios en el transcurso.

38

11-12: Reyes, Javier, (2017) Consultar edificio version 2.

11-13: Reyes, Javier, (2017) Consultar edificio version 2. En ésta instancia se mantienen formularios iguales en ambas versiones.

11-14: Reyes, Javier, (2017) Recuperar edificio version 1.

39

11-15: Reyes, Javier, (2017) Recuperar edificio version 2.

La versión 1 muestra una información previa del edificio a recuperar, los cuales son: NOMBRE EDIFICIO, FACULTAD Y DIRECCIÓN. Sin embargo la versión 2 tiene adicional a la versión 1: SEDE. 11.4.1 MOCKUPS DE ESPACIOS FÍSICOS

11-16: Reyes, Javier, (2017) Registrar Espacio Físico version 1.

11-17: Reyes, Javier, (2017) Registrar Espacio Físico version 1.

40

En ésta instancia la versión 1 cuenta con los siguientes campos: NOMBRE ESPACIO FÍSICO, CÓDIGO, TIPO, FACULTAD, SEDE, DEPENDENCIA Y ESTADO. Por otra parte la versión 2 varía, pues se reemplaza código por EDIFICIO, facultad por ÁREA y sede por CONEXIÓN A INTERNET.

11-18: Reyes, Javier, (2017) Consultar Espacio Físico version 1.

11-19: Reyes, Javier, (2017) Consultar Espacio Físico version 2.

En la versión 1 están los siguientes datos: NOMBRE ESPACIO, CÓDIGO, TIPO, FACULTAD y opción de ELIMINAR. Sin embargo la versión 2 cambia los siguientes datos: código por FACULTAD, tipo por SEDE, facultad por DIRECCIÓN y adicionalmente tiene una opción de MODIFICAR.

41

11-20: Reyes, Javier, (2017) Consultar Espacio Físico version 1.

11-21: Reyes, Javier, (2017) Consultar Espacio Físico version 2.

En la versión 1 se encuentran los siguientes datos: NOMBRE ESPACIO, CÓDIGO, TIPO y la opción de RESTAURAR. Sin embargo en la versión 2 se modifican los siguientes datos: código por FACULTAD y tipo por SEDE, adicionalmente se anexa: DIRECCIÓN. 11.4.1 MOCKUPS DE SEDE

11-22: REGISTRO SEDE VERSIÓN 2

42

El formulario de la versión 1 varía totalmente con la versión 2 simplificandose éste último, la versión 1 posee: NOMBRE SEDE, ABREVIATURA SEDE, DIRECCIÓN, LATITUD, LONGITUD y ESTADO, sin embargo la versión 2 contiene: NOMBRE SEDE, SEDE y ESTADO.

11-23:CONSULTAR SEDE VERSIÓN 1

11-24: CONSULTAR SEDE VERSIÓN 2

El formulario de consulta de sede varía en los siguientes datos, en la versión 1 están: NOMBRE SEDE, DIRECCIÓN, ABREVIATURA SEDE, MODIFICAR y ELIMINAR. Sin embargo en la versión 2 se suprimen DIRECCIÓN y ABREVIATURA SEDE por ESTADO.

43

11-25: RECUPERAR SEDE VERSIÓN 1

11-26: RECUPERAR SEDE VERSIÓN 2

En éste último formulario aparecen los siguientes datos en la versión 1: NOMBRE SEDE, DIRECCIÓN, ABREVIATURA SEDE sin embargo en la versión 2 se resume a: NOMBRE SEDE, ESTADO. Cabe destacar que los mockups se fueron refinando de acuerdo a los estándares que se establecieron en la Oficina Asesora de Sistemas (OAS), en cuanto a estilos y nombramiento de variables utilizadas en los controladores de cada módulo, creando así un aplicativo con los lineamientos implantados y que permitiera interactuar de mejor manera con los demás sistemas, logrando así integración entre los sistemas que tiene a cargo la Oficina Asesora de Sistemas.

44

11.5 DISEÑO DE ARQUITECTURA DE INFORMACIÓN

Para realizar un primer acercamiento al nuevo sistema planteado para la gestión de espacio físicos, se utilizó el punto de vista de estructura de información ofrecido por la herramienta de modelamiento Archimate, donde se muestra la información a utilizar; se representa la información a nivel del negocio en la aplicación por medio de las estructuras de datos usadas.

11-27: Reyes, Javier, (2017) Arquitectura de información para OIKOS.

En el diagrama anterior se puede apreciar las dos clasificaciones que se maneja en el aplicativo teniendo en cuenta que por un lado tenemos la jerarquía de la parte física (espacios físicos) y por el otro lado tenemos la jerarquía de la parte lógica (dependencias) de la Universidad Distrital. Teniendo en cuenta la parte de la jerarquía de física se puede evidenciar que la entrada de datos (representadas por medio de objetos de datos) que tiene un espacio físico determinará caracteristicas tales como nombre, código y estado, además es importante tener en cuenta que al espacio físico también lo componen caracteristicas tales como tipo espacio físico (Indicando si es sede, edificio u otro tipo de espacio físico que sea de la Universidad Distrital), tipo uso (Indicando si es deportivo, académico o administrativo) y el espacio físico padre teniendo en cuenta el nivel jerárquico que corresponda. En el diagrama anterior pueden apreciarse las entradas de datos que alimentarán al sistema de gestión de espacios físicos. Finalmente se tiene la jerarquía nivel lógico en la cual se pueden encontrar las dependencias de la Universidad Distrital, y por medio de la entrada de datos se obtienen caracteristicas tales como nombre, teléfono, correo electrónico y dependencia padre con el fin de identificar su nivel jerárquico dentro de la organización.

45

11.6 MODELO DE DATOS

En el presente apartado y a partir del punto de vista de arquitectura de información, se propuso el modelo de datos OIKOS. Este modelo fue plasmado en el software PGmodeler y está orientado hacia el motor PostgreSQL, es trabajado y exigido por la Oficina Asesora de Sistemas. El modelo fue revisado y avalado para su despliegue por el Ingeniero Jhon Castellanos e Ingeniero Alejandro Daza. El modelo se basa en dos grandes componentes los cuales son espacio físico y dependencia, a continuación se explicara cada uno de los componentes con sus tablas asociadas de acuerdo a los requerimientos de sistema y acorde a las apreciaciones del Ingeniero Alejandro Daza y Jhon Castellanos, arquitectos del proyecto.

11-28: Reyes, Javier, (2017) Modelo de datos OIKOS.

La tabla de espacio físico dentro de sus atributos cuenta con su correspondiente identificador y un campo tipo espacio que hace alusión a la tabla tipo_espacio_físico, cuyos valores fueron pensados con base a las opciones de tipos de espacios existentes en la universidad, por ejemplo algunos valores que contiene dicha tabla son sede, edificio, aulas de clase, oficina. Se encontró también el correspondiente código del espacio físico y el nombre, atributos esenciales inherentes a la descripción del objeto en cuestión. En la abstracción que se llevó a cabo se puede evidenciar la tabla espacio_fisico_padre espacio_físico_padre la cual es útil para establecer la jerarquía del espacio físico, definiendo así un orden coherente traída del mundo real al sistema, por ejemplo la sede Calle 40 es padre del edificio Sabio Caldas, y este último es padre del salon 204, de esta

46

manera la depuración llevada a cabo de la base de datos incluye por supuesto un orden lógico y organizado. Cabe destacar que se realizó el modelo de datos teniendo en cuenta los modelos multi organizacionales de acuerdo a la jerarquía de la Universidad Distrital en cuanto a la parte físico como lógica. Lo anterior se ve evidenciado en las tablas espacio_fisico y espacio_fisico_padre en las cuales se encuentran los distintos tipos de espacios físicos que tiene la Universidad, dicha información del tipo de espacio físico se obtiene de la tabla tipo_espacio_fisico. Por otro lado, si se observa la jerarquía lógica de la Universidad Distrital se evidencia que las tablas dependencia, dependencia_padre y tipo_dependencia cumplen a cabalidad las ventajas de ser un modelo multi organizacional, ya que se puede crear cualquier tipo de dependencia y asociarlo con una dependencia en específico Se realizará una descripción de las tablas importantes en el modelo OIKOS, como se explica a continuación, primero se tiene la tabla espacio_fisico la cual es base para mantener la parte física de la Universidad Distrital:

11-29: Reyes, Javier, (2017) Espacio físico.

Tabla: espacio_fisico

Descripción: Tabla en la que se registran los espacios físicos de la Universidad Distrital.

Atributo Descripción Tipo Dominio Null Pk Uk Fk Tabla referenciada

id Identificador de la tabla espacio_fisico

serial X

estado Estado del espacio físico character varying

Activo/Inactivo

nombre Nombre del espacio físico

character varying

codigo Código del espacio físico character varying

tipo_espacio identificador del tipo de espacio físico

integer X tipo_espacio_fisico

11-1: Descripción entidad espacio_fisico.

47

Ahora se tiene la tabla tipo_uso, como se evidencia en la imagen 11-30 y se describe en la tabla 11-6.

11-30: Reyes, Javier, (2017) Tipo uso.

Tabla: tipo_uso

Descripción: Tabla de registro el tipo de uso de los espacios físicos

Atributo Descripción Tipo(longitud) Dominio Null Pk Uk Fk Tabla referenciada

id Identificador de la tabla tipo_uso

serial X

nombre Campo que indica el nombre del tipo de uso

varchar(50) X

11-2: Descripción entidad tipo_uso.

Ahora se tiene la tabla tipo_uso_espacio_fisico, como se evidencia en la imagen 11-30 y se describe en la tabla 11-3.

11-31: Reyes, Javier, (2017) Tipo uso espacio físico.

Tabla: tipo_uso_espacio_fisico

Descripción: Tabla de rompimiento entre tipo uso y espacio físico

Atributo Descripción Tipo Dominio Null Pk

Uk

Fk

Tabla referen

ciada

id Identificador de la tabla movimiento_contable

serial X

tipo_uso_id Identificador de la tabla tipo_uso que se referencia para diferenciar que tipo de uso tiene el espacio_fisico

integer X tipo_uso

espacio_fisico_id Identificador de la tabla espacio_fisico_id para referencia el espacio_fisico

integer X espacio_fisico

11-3: Descripción entidad tipo_uso_espacio_fisico.

48

Ahora se tiene la tabla tipo_espacio_fisico, como se evidencia en la imagen 11-32 y se describe en la tabla 11-4.

11-32: Reyes, Javier, (2017) Tipo espacio físico.

Tabla: tipo_espacio_fisico

Descripción: Tabla en la que se registran el tipo de espacio físico de la Universidad

Atributo Descripción Tipo Domin

io

Null

Pk

Uk

Fk

Tabla referenciada

id Identificador de la tabla tipo_espacio_fisico serial X

nombre Campo que indica el nombre del tipo de espacio físico

varchar(60) X

11-4: Descripción entidad tipo_espacio_fisico.

Ahora se tiene la tabla espacio_fisico_padre, como se evidencia en la imagen 11-33 y se describe en la tabla 11-5.

11-33: Reyes, Javier, (2017) Espacio físico padre.

Tabla: espacio_fisico_padre

Descripción: Tabla en la que se registran los identificadores padre e hijo correspondiente a abstracción de los niveles de espacio físico

Atributo Descripción Tipo(longitud) Dominio Null Pk Uk Fk Tabla referenciada

id Identificador de la tabla espacio_fisico_padre

serial X

padre Campo con el identificador del espacio físico padre de la tabla espacio_fisico

integer X espacio_fisico

hijo Campo con el identificador del espacio físico hijo de la tabla espacio_fisico

integer X espacio_fisico

11-5: Descripción entidad espacio_fisico_padre.

49

Ahora se tiene la tabla dependencia la cual es la que soporta la organización a nivel lógico, como se evidencia en la imagen 11-34 y se describe en la tabla 11-6.

11-34: Reyes, Javier, (2017) Dependencia.

Tabla: dependencia

Descripción: Tabla en la que se registran las dependencias que pertenecen a la Universidad Distrital

Atributo Descripción Tipo Dominio

Null Pk Uk Fk Tabla referenciada

id Identificador de la tabla dependencia

serial X

nombre Campo que contiene el nombre de la dependencia

character varying

X

telefono_dependencia

Campo que contiene el número de teléfono de la dependencia

character varying

correo_electrónico

Campo que contiene el correo electrónico de la dependencia

character varying

X

11-6: Descripción entidad dependencia.

Ahora se tiene la tabla dependencia_padre, como se evidencia en la imagen 11-35 y se describe en la tabla 11-12.

11-35: Reyes, Javier, (2017) Dependencia padre.

Tabla: dependencia_padre

Descripción: Tabla en la que se registra la jerarquia de las dependencias de la Universidad Distrital

Atributo Descripción Tipo Dominio Null Pk Uk Fk Tabla referenciada

id Identificador de la tabla dependencia_padre

integer X

padre Campo que contiene el id del dependencia padre

integer X X dependencia

hija Campo que contiene el id del dependencia hija

integer X X dependencia

11-7: Descripción entidad dependencia padre.

50

CAPÍTULO 12. TRABAJOS FUTUROS

A partir de este proyecto se pueden generar diferentes tableros Kanban con sus respectivas task, que pueden derivarse OIKOS (Sistema de Gestión De Espacios Físicos), con el fin de que se pueden agregar funcionalidades y mejorar aspectos de los que se presentaron en el aplicativo, por tal motivo se propone:

● Asignación de espacios físicos académicos por calendario teniendo en cuenta los roles que pueden hacer la separación.

● Control de roles, de acuerdo al proceso que corresponda a determinado rol visualizar lo correspondiente teniendo en cuenta menús, acciones o botones que ejerzan determinada función sobre las vistas.

● Autenticación única, se propone conocer e implementar WSO2 Identity Server, el

cual permite autenticar en determinados aplicativos de acuerdo a parámetros relacionados con la identidad del usuario.

51

CONCLUSIONES A lo largo del proceso de desarrollo se presentaron varias incidencias que llevaron a definir un conjunto de argumentaciones presentadas a continuación:

● La estructuración del modelo relacional tanto para la parte física (espacio_fisico), como para la parte organizacional (dependencias) cumple con un modelo multi organizacional, el cual permite gestionar todos los espacios físicos y dependencias por tablas base las cuales guardan la información, teniendo en cuenta valores de tablas parámetricas tales como tipo_uso, tipo_dependencia y tipo_espacio_fisico.

● Los servicios personalizados desarrollados para el aplicativo permite

visualizar e interactuar de una manera amigable la jerarquía que tiene la Universidad Distrital con respecto a la parte física y organizacional.

● El aplicativo OIKOS permite hacer la parametrización para el tipo de dependencias y el tipo de espacios físicos, ya que el anterior aplicativo no permite realizar esta parametrización.

● El manejo de los procesos que lleva a cabo el aplicativo OIKOS facilita

la gestión de todos los espacios físicos que posee la Universidad Distrital, permitiendo así clasificarlos.

52

BIBLIOGRAFÍA

● Anderson, David J.; Reinertsen, Donald G. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Disponible en: http://www.amazon.com/kanban-successful-evolutionary-technology-business/dp/0984521402

● Figuerola, Norberto. (2011) Kanban Su uso en el desarrollo de software

https://articulosit.files.wordpress.com/2011/11/kanban.pdf

● Bermejo, Marcos(2010), Introduccion a Agile https://www.exabyteinformatica.com/uoc/Audiovisual/Produccion_multimedia/Produccion_multimedia_(Modulo_4).pdf

● Universidad Distrital Francisco José de caldas , Oficina asesora de

planeación y control (2017), http://planeacion.udistrital.edu.co:8080/

● W3C España, (2017) Guía Breve de Servicios web,http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb

● BBVAOPEN4U,(2016)API REST: qué es y cuáles son sus ventajas en el

desarrollo de proyectos,https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-sus-ventajas-en-el-desarrollo-de-proyectos

● JMeter, jmeter.apache.org

● Selenium, http://www.seleniumhq.org/

● AWS, Amazon. Qué es la integración continua. 2017

53