IMPLEMENTACIÓN DE UN SISTEMA DE INFORMACIÓN GEOGRÁFICA QUE PLANTEE RUTAS OPTIMAS DE EVACUACIÓN PARA UNA PRONTA

RESPUESTA EN CASO DE SINIESTRO EN LA FACULTAD DE INGENIERÍA DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

AUTOR:

SEBASTIÁN PALMA MORENO COD. 20101025071C.C. 1013620663

PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO CATASTRAL Y GEODESTA

DIRECTOR INTERNO:

ING. EDWIN PEREZ CARVAJAL

DIRECTOR EXTERNO:

ING. JHON GABRIEL CASTELLANOS

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDASOFICINA ASESORA DE SISTEMAS U.D.

FACULTAD DE INGENIERÍAINGENIERÍA CATASTRAL

BOGOTÁ D.C, 2016

1

TABLA DE CONTENIDO

CAPÍTULO 1. INTRODUCCIÓN...................................................................................4CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA...................................................5CAPÍTULO 3. OBJETIVOS...........................................................................................6

3.1. Objetivo General................................................................................................63.2. Objetivos específicos.........................................................................................6

CAPÍTULO 4. JUSTIFICACIÓN....................................................................................7CAPÍTULO 5. MARCO TEÓRICO................................................................................8

5.1. El Proceso OPENUP/OAS................................................................................85.1.1. Generalidades............................................................................................85.1.2. El Método de Trabajo...............................................................................10

5.1.2.1. Fases del Proceso OpenUP/OAS....................................................115.1.2.2. Subprocesos openup/oas.................................................................145.1.2.3. Roles openup/oas.............................................................................175.1.2.4. Artefactos del Proceso OpenUp/OAS...............................................18

5.1.3. Proceso de Desarrollo..............................................................................205.1.3.1. Ficha de Caracterización de Subproceso.........................................205.1.3.2. Guías.................................................................................................21

5.1.3.2.1. Integración Continua.................................................................215.1.3.2.2. Reconstrucción..........................................................................225.1.3.2.3. Transformar el diseño en Puesta en Funcionamiento..............235.1.3.2.4. Elevar los Cambios al Siguiente Nivel de Operación................235.1.3.2.5. Reutilización de Software..........................................................235.1.3.2.6. Estándares para la Escritura de Código...................................245.1.3.2.7. Puesta en Funcionamiento........................................................24

5.2 Sistema de información geográfica..................................................................255.3 NetLogo............................................................................................................25

CAPÍTULO 6. DESCRIPCIÓN DE LOS RESULTADOS............................................27CAPÍTULO 7. ANÁLISIS DE RESULTADOS..............................................................28

7.1 Descripción del sistema de información geográfica Sabio Caldas y Administrativo.........................................................................................................28

7.1.1 Cartografiá.................................................................................................287.1.2 Modelo en NetLogo...................................................................................29

7.2 Producto...........................................................................................................34CAPÍTULO 8. EVALUACIÓN Y CUMPLIMIENTO DE LOS OBJETIVOS..................37CAPÍTULO 9. CONCLUSIONES Y RECOMENDACIONES......................................39

9.1 Conclusiones....................................................................................................399.2 Recomendaciones............................................................................................39

CAPÍTULO 10. BIBLIOGRAFÍA..................................................................................40ANEXOS.....................................................................................................................41

2

Índice de ilustraciones

Figura 1. Método de trabajo.......................................................................................14 Figura 2: Proceso de desarrollo OpenUP/OAS.........................................................19 Figura 3: Estructura del equipo de desarrollo OpenUP/OAS....................................21 Figura 4: Ficha desarrollo de solución proceso OpenUP/OAS.................................24 Figura 5: Subproceso de desarrollo OpenUP/OAS...................................................25 Figura 6: Simbologia para la representación del edificio Sabio Caldas y Administrativo.............................................................................................................31 Figura 7: Cartografiá final para cargar a NetLogo.....................................................34 Figura 8: Variables de control para el modelo de movimiento..................................37 Figura 9. Gráfica de cada uno de los escenarios propuestos en el modelo.............39 Figura 10. Cartografiá Generada en Qgis para ser cargada a NetLogo...................41

Índice de tablas

Tabla 1. Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.....................15Tabla 2. Fuente : Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.....................17Tabla 3. Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.....................20Tabla 4. Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.....................22Tabla 5. Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.....................24Tabla 6. Escenarios con variables creados para correr la simulación en Netlogo.....30

3

CAPÍTULO 1. INTRODUCCIÓN

En el presente trabajo llevó a cabo un modelo en el cual se generaron 8 escenarios para el edificio Sabio Caldas en caso de ocurrencia de siniestro en la facultad de Ingeniería de la Universidad Distrital Francisco José de Caldas, utilizando un sistema de información geográfica, para evaluar los tiempos de evacuación del edificio, mediante agentes autónomos, utilizando Netlogo para simular cada una de las personas y su movimiento dentro del edificio y Qgis para generar la cartografiá, con una simbología que entendieran los agentes autónomos e implementarla en Netlogo para hacer los cálculos y el análisis espacial. En la actualidad, los sistemas de atención del riesgo de desastre juegan un papel muy importante debido a que evitan pérdidas humanas en casos de episodios naturales de rango extraordinario1, por ello, la implementación de un sistema que permita calcular la mejor ruta de evacuación en el edificios Sabio Caldas y Administrativo de la facultad de Ingeniería, permitirá desplazar al cuerpo laboral y académico fuera de las instalaciones en el menor tiempo posible.

El tiempo de respuesta mediante la ocurrencia de un siniestro (fortuito) será de vital importancia, ya que la comunidad tanto administrativa como académica es numerosa, lo que hace que los tiempos de traslado entre un punto de reunión a un punto de encuentro varíen de forma positiva y/o negativa.

En Colombia, existe normativa directamente relacionada con la Gestión de Riesgo. Para el presente caso, se tratará de la ley 1523 de 2012, que reglamenta la Gestión de Riesgo de desastres y la Norma Técnica Colombiana 1700 que trata temas sobre “Higiene, Seguridad, Medidas de Seguridad en Edificaciones y Medidas de Evacuación”; esto con el objetivo de profundizar sobre los casos de riesgo, vulnerabilidad y amenaza a los que la facultad es susceptible y establecer las medidas y tiempos de respuesta en caso de ocurrencia.

1 Ayala, F.J. y Olcina, J. (2002). «Riesgos naturales. Conceptos fundamentales y clasificación». En: Ayala, F.J. y Olcina, J. (coords.) Riesgos naturales. Ariel Ciencia. Barcelona. Págs. 41-73 (Ver. pág. 55 y sigs.)

4

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA

Todas las instituciones públicas y privadas deben contar con un plan de evacuación y seguridad en caso de siniestro, según la NORMA TÉCNICA COLOMBIANA NTC 1700 que establece “los requisitos mínimos que deben cumplir los medios de salida para la evacuación de los ocupantes de una edificación, en caso de fuego u otra emergencia”. Por lo anterior es necesario que la Universidad Distrital Francisco José de Caldas cree un plan de emergencia que incluya rutas de evacuación que reduzcan los efectos que pueda causar alguna catástrofe, ya que al momento no se ha planteado un sistema de emergencia en caso de algún evento fortuito.

El subsistema de Seguridad y Salud en el trabajo de la Facultad de Ingeniería ha tratado de implementar y fomentar en las diferentes dependencias planes de contingencia en caso de estos eventos, sin embargo a la fecha no se ha logrado consolidar un plan de Gestión de Riesgo que evite este tipo de amenazas; por ello, se trabajará en conjunto al Subsistema de seguridad y salud, La oficina Asesora de Planeación y La Oficina Asesora de Sistemas para dar solución al mencionado.

El Sistema de Información Geográfica que se implementará para plantear las rutas de evacuación, buscará e indicará la ruta de menor distancia y mayor seguridad para ser recorrida por el usuario; Para ello, se empleará el método de agentes autónomos definiendo las distancias más cortas al momento de desplazarse al punto de encuentro2. Éstos agentes permitirán seguir ordenes de evacuación programadas mediante Netlogo.

El Sistema de Información Geográfica que se implemento, modela posibles escenarios de evacuación del edificio Sabio Caldas perteneciente a la facultad de ingeniería de la Universidad, ya que en este edificio se han identificado varias amenazas, las cuales tienden a disminuir el tiempo de salida de las personas, aumentando el riesgo de afectar la integridad de los ocupantes en caso de un siniestro.

2ICONTEC, (2004). «Requisitos mínimos que deben cumplir los medios de salida para la evacuación de los ocupantes en casos de fuego u otra emergencia». https://books.google.com.co/books?id=BZ_VMgEACAAJ

5

CAPÍTULO 3. OBJETIVOS

3.1. Objetivo General

Realizar un Sistema de Información Geográfica en el cual se identifiquen las mejores rutas de evacuación para la sede de ingeniería implementando simulaciones de posibles escenarios en caso de ocurrencia de un evento fortuito con agentes autónomos.

3.2. Objetivos específicos

● Revisar la información cartográfica correspondiente a los planos arquitectónicos de la facultad de Ingeniería y su sede administrativa.

● Georeferenciar la información cartográfica de la Facultad de Ingeniería, incluyendo la sede Administrativa.

● Transformar los datos para que tengan compatibilidad con Qgis3 y NetLogo4 en cuanto a la representación gráfica y espacial.

● Plantear rutas de evacuación preliminares y realizar la señalización pertinente según las normas de evacuación.

● Evaluar las rutas de evacuación utilizando agentes autónomos con ayuda de NetLogo para medir tiempos de desplazamiento entre un punto de reunión y un punto de encuentro.

● Implementar a la cartografía las rutas de evacuación finales y visualizarlas en el sistema de Información geográfica.

3 QGIS,(2016). Acerca de QGIS. Retrieved from http://qgis.org/es/site/about/index.html4 Laboratorio de aprendizaje de NetLogo, (2016) Retrieved 17 May 2016, from http://online.sfsu.edu/jjohnson/NetlogoTranslation/laboratorio_0102.html

6

CAPÍTULO 4. JUSTIFICACIÓN

Debido a la falta de indicaciones para la correcta evacuación de la Facultad de Ingeniería, de acuerdo a la Ley 1523 de 2012 y consecuentemente con la Norma Técnica Colombiana NTC 1700, se ha observado que a parte de una falta de rutas de evacuación establecidas, hay una gran falencia en las rutas de desplazamiento entre un punto de reunión y las salidas principales de la sede de forma rápida y eficiente en caso de riesgo, amenaza o vulnerabilidad de los espacios físicos que la comprenden, por esto se ha planteado realizar un estudio utilizando agentes autónomos y posteriormente implementar un Sistema de Información Geográfica para administrar las rutas óptimas de evacuación y reducir los costos en términos de tiempos en la Facultad de Ingeniería de la Universidad Distrital Francisco José de Caldas.

7

CAPÍTULO 5. MARCO TEÓRICO

5.1. El Proceso OPENUP/OAS

En el marco de la resolución 461 de Rectoría del 29 de Julio de 2011, la Universidad Distrital Francisco José de Caldas avaló el método de desarrollo OPENUP/OAS, como el marco de trabajo institucional en el análisis, diseño, desarrollo e implementación de productos de software al interior de la Universidad. A continuación se describen sus principales directrices y fundamentos.

5.1.1. Generalidades

El proceso openUP/OAS es un método de trabajo que involucra un conjunto mínimo de prácticas tendientes a guiar a un equipo de trabajo pequeño en el análisis, diseño, desarrollo y despliegue de un producto de software. Los objetivos que persiguen son:

● Promover la colaboración y compartir conocimientos alineando intereses del equipo de trabajo y los usuarios.

● Ayudar al equipo a enfocarse en la arquitectura de forma rápida; de tal forma que se minimicen los riesgos y se organice el desarrollo.

● Ayudar al equipo a balancear prioridades en conflicto para maximizar el valor obtenido por los interesados en el proyecto.

● Ayudar al equipo en la evolución continua del producto para obtener retroalimentación continua y fomentar el mejoramiento.

● Permitir a los administradores del proyecto realizar seguimientos a las avances basados en metas e indicadores

● Permitir que los integrantes del equipo entiendan rápidamente como realizar el trabajo para alcanzar los objetivos y metas proyectadas.

Los principios en que se enmarca el método de trabajo OPENUP/OAS son:

a. Conocer a los Interesados: Se deben identificar, conocer a los grupos de interés y trabajar de cerca con ellos para asegurarse que sus necesidades son claramente definidas e incrementalmente satisfechas a medida que se evoluciona en el desarrollo de la solución. Debe mantenerse una comunicación abierta y frecuente además de una colaboración entre ellos y el equipo de trabajo.

b. Separar el Problema de la Solución: Se debe estar seguro que se conoce el problema (o una parte de él) antes de definir una solución (o una parte de ella). Al separar claramente el problema (que necesita el cliente - no que necesita el equipo de desarrollo) de la solución (el sistema que tiene que hacer), es fácil mantener un enfoque y encontrar vías alternativas para solucionar el problema.

8

c. Crear un conocimiento compartido del dominio: Se debe fomentar un ambiente de intercambio y trabajo en el que todos los involucrados puedan obtener constantemente la información adecuada para lograr tener una visión compartida de lo que se debe hacer, el por qué hacerlo y cómo se está haciendo.

d. Establecer y mantener contratos de prioridades: Se deben priorizar los requisitos y requerimientos de implementación basado en un trabajo continuo con los grupos de interés y tomar decisiones que lleven a que el sistema siempre incremente los beneficios ofrecidos y reduzca los riesgos.

e. Realizar negociaciones que maximicen el beneficio obtenido: Las negociaciones costo beneficio dentro del proyecto no pueden ser independientes de la arquitectura. Los requisitos y requerimientos establecen los beneficios que se deben alcanzar al implementar el sistema mientras que la arquitectura es una medida base para calcular el costo del mismo. El costo asociado con un beneficio puede influenciar en gran medida la percepción del usuario acerca del valor real obtenido.

f. Gestionar el entorno :El cambio es inevitable, y aunque presenta oportunidades para mejorar los beneficios dados a los grupos de interés, un entorno incontrolado de cambios fácilmente decantará en sistemas deficientes, sobre dimensionados y que no satisfacen las necesidades reales de los clientes. Se debe gestionar los cambios manteniendo contratos específicos con los grupos de interés.

g. Conocer cuándo se debe parar : Sobre recargar de características un sistema no sólo es una pérdida de tiempo y recursos sino que conduce a sistemas innecesariamente complejos. El desarrollo debe parar cuando la calidad esperada del sistema se alcanza.

h. Mantenga un entendimiento común: Sea proactivo comunicando y compartiendo información con los participantes del proyecto y no asuma que todos y cada uno encontrarán justo lo que ellos necesitan saber o que cada persona tiene la misma comprensión del proyecto que todos los demás.

i. Aprender continuamente: Desarrolle continuamente sus habilidades técnicas e interpersonales, aprenda de los ejemplos de sus colegas, aproveche la oportunidad, tanto de ser un estudiante de sus colegas, así como maestro de ellos. Siempre incremente su habilidad personal para sobrellevar su propio antagonismo hacia otros miembros del equipo.

j. Organice alrededor de la arquitectura: La comunicación entre los miembros del equipo empieza a ser compleja incrementalmente. Por consiguiente, organice el equipo alrededor de la arquitectura, el vocabulario y el modelo mental compartido del sistema.

9

j. Desarrolle su proyecto en iteraciones: Divida su proyecto en una serie de iteraciones encajadas en el tiempo y planee su proyecto iterativamente. Esta estrategia iterativa lo habilita para entregar capacidades incrementalmente, como un conjunto ejecutable, subconjunto utilizable de requisitos y requerimientos probados e implementados, que pueden ser evaluados por los interesados al final de cada iteración.

k. Gestione los riesgos: Ataque tempranamente los riesgos que atacarán el proyecto. Continuamente identifique y priorice los riesgos y entonces idee estrategias para mitigarlos.

l. Adopte y gestione el cambio: Adoptar los cambios ayuda a construir un sistema que se encamina a las necesidades de los interesados y manejar los cambios permite reducir costos y mejorar la predicción de estos cambios. Los cambios hechos tempranamente en el proyecto se pueden hacer usualmente a bajo costo. A medida que usted avanza en el proyecto, los cambios pueden empezar a incrementarse en términos de costos.

m. Mida el progreso objetivamente: Si no conoce objetivamente cómo su proyecto está progresando, no sabe si éste falla o tiene éxito. La incertidumbre y los cambios a un proyecto de software en progreso dificultan medirlo objetivamente, en tanto que las personas tienen una habilidad muy asombrosa para creer que todo está bien ante la catástrofe.

5.1.2. El Método de Trabajo

Para la implementación de la solución de software bajo el proceso OPENUP/OAS se contemplan los respectivos subprocesos bajo cierta intensidad por cada una de ellas en la fase en la que se está ejecutando como se puede evidenciar en la Figura 1.

10

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

El OPENUP/OAS es un proceso iterativo e incremental que se distribuyen a través de cuatro fases: Inicio, Elaboración, Construcción y Transición. En las cuales se desarrollan transversalmente una serie de subprocesos entendiéndose estos últimos como un conjunto de actividades, personas (Roles), prácticas (Guías) y productos de trabajo (Artefactos) que orientan el desarrollo de software a través del tiempo.

Cada fase puede tener tantas iteraciones como se requiera, dependiendo del grado de complejidad y desconocimiento del dominio, la tecnología a ser usada, la complejidad arquitectónica y el tamaño del proyecto, por nombrar algunos factores.

5.1.2.1. Fases del Proceso OpenUP/OAS

Fase de Inicio: Primera fase del proceso, donde los interesados (stakeholders) y los integrantes del equipo de desarrollo, colaboran para determinar el ámbito del proyecto, sus objetivos y determinar si el proyecto es viable.En la Tabla 1, se puede evidenciar las iteraciones de esta fase enfocan el esfuerzo de trabajo en las actividades y resultados

11

Figura 1. Método de trabajo.

Tabla 2:

Actividades de fase de inicio OpenUP/OAS

Actividad Resultados

Iniciar el proyecto

*Elaborar el documento Visión*Elaborar el Plan General del Proyecto*Elaborar el documento de Análisis de riesgo

Planear y gestionar la iteración

*Elaborar el Plan de Iteración* Elaborar el documento de evaluación de la iteración* Elaborar el documento de valoración de resultados de la iteración

Identificar y refinar los requerimientos y requisitos

Elaborar la especificación de casos de usoElaborar el documento de requisitos de soporteElaborar el documento casos de prueba

Llegar a un acuerdo sobre el enfoque técnico

Elaborar el documento Bloc de Notas de la Arquitectura

Tabla 1. Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

Al final de esta fase, como mínimo, el proyecto:● Ha definido el ámbito● Tiene un estimado inicial de los costos y el cronograma● Ha definido y priorizado un conjunto inicial de requerimientos funcionales y no

funcionales● Ha identificado un conjunto de riesgos y haya propuesto las estrategias de

mitigación.● Ha identificado un conjunto de interesados.● Ha creado un bosquejo de arquitectura.

Fase de Elaboración: La segunda fase dentro del ciclo de vida del proyecto. En ella los riesgos significativos que influyen en la arquitectura son identificados y considerados.En esta fase:

● Se obtiene un entendimiento más detallado de los requerimientos y requisitos● Se diseña, implementa válida y establece la línea base de la arquitectura.● Se mitigan los riesgos esenciales.● Se produce un cronograma detallado.● Se realiza una mejor estimación de costos.

12

Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las actividades y resultados contempladas en la Tabla 2, especificando tareas para cada una de las actividades.

Tabla 2:

Actividades Fase de elaboración OpenUP/OAS:

Actividad Tareas/Resultados

Planear y gestionar la iteración

-Elaborar el Plan de Iteración-Elaborar el documento de evaluación de la iteración-Elaborar el documento de valoración de resultados de la iteración

Identificar y refinar los requerimientos

-Actualizar, depurar y aumentar el contenido de la especificación de casos de uso-Actualizar, depurar y aumentar el contenido del documento de Requerimientos de soporte-Actualizar,depurar y aumentar el contenido del documento Casos de prueba

Desarrollar la arquitectura Agregar las vistas de arquitectura al documento Bloc de Notas de la Arquitectura

Desarrollar un incremento en la solución

*Actualizar, depurar y aumentar el contenido del documento Especificación de Diseño*Actualizar, depurar y aumentar el contenido del documento Pruebas efectuadas por el Realizador*Obtener el código fuente que realiza uno o varios elementos de diseño*Elaboración de una Construcción del Sistema que integre nuevos elementos (componentes desarrollados, clases, etc)*Elaborar el artefacto Registro de Pruebas que contenga los resultados de la ejecución de las pruebas hechas por el realizador.

Probar la Solución Construida Elaborar el artefacto Script de PruebaElaborar el artefacto Registro de Pruebas que contenga los resultados de la ejecución de las pruebas .

Gestionar las peticiones de cambio

Actualizar, depurar y aumentar el contenido del documento Lista de Unidades de Trabajo.

Tabla 2. Fuente : Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

13

Fase de Construcción : Esta es la tercera fase del proceso, se enfoca en detallar los requisitos y requerimientos, diseñar, implementar y probar el grueso del software y completar el desarrollo del sistema basado en la arquitectura.

Se describen los requisitos y requerimientos restantesSe completan en detalles los diseños, la implementación y las pruebas del software. Se libera la primera versión operativa del software (beta) del sistema.

Las actividades de esta fase son

1. Planificación y gestión de la iteración2. Identificar y refinar requisitos y requerimientos3. Desarrollar un incremento de solución4. Probar la solución construida

Fase de Transición

Es la cuarta fase del proceso. Se enfoca en la transición del producto de sistema de información geográfica al cliente logrando que los interesados convengan que el desarrollo del producto cumple con los requerimientos planteados.Los objetivos de esta fase son lograr:

● La prueba beta valida que satisfaga las expectativas del usuario. Esto típicamente requiere algunas actividades de afinamiento, tales como depuración de errores y mejora del desempeño y la usabilidad.

● El consentimiento de los interesados en que el desarrollo está completo. Esto puede involucrar varios niveles de pruebas para la aceptación del producto, incluyendo pruebas formales e informales y pruebas beta.

● Mejorar el desempeño en futuros proyectos a través de lecciones aprendidas.

● Documentar las lecciones aprendidas y mejorar el ambiente de los procesos y las Herramientas para el proyecto.

5.1.2.2. Subprocesos openup/oas

Como se había señalado anteriormente un subproceso es un conjunto de actividades desarrolladas por personas con unos roles determinados, las cuales se guían por medio de una serie de prácticas o guías para obtener unos productos de trabajo denominados Artefactos y que permiten cumplir direccionar las fases y actividades propuestas en las cuatro fases del proceso de desarrollo de software openup/oas.Estos subprocesos se relacionan entre sí, siendo unos entradas o insumos iniciales para que otros subprocesos se puedan desarrollar. En la Figura 2, podemos evidenciar el respectivo proceso de desarrollo OPENUP/OAS a ejecutar con los respectivos subprocesos arraigados:

14

Figura 2: Proceso de desarrollo OpenUP/OAS.

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

En la Tabla 3, se evidencia en detalle cada uno de los subprocesos pertenecientes a OpenUp/OAS, junto con sus objetivos y artefactos a destinar:

15

Subproceso Objetivo Artefactos de Salida

Gestión de Requerimientos y Requisitos

Recolectar, analizar, aprobar y seguir la evolución de los requerimientos funcionales del Cliente o interesado y los requisitos del Sistema de información geográfica (Sig) través de la vida del producto y/o servicio.

-Visión-Glosario-Requisitos de Soporte-Actas de Trabajo-Listadode requerimientos funcionales y no funcionales

Gestión del Proyecto

Planear, ejecutar, controlar y socializar las actividades y resultados de un proyecto Sig

Plan General del proyectoPlan de IteraciónCierre de iteraciónLista de Unidades de trabajo

Gestión del Riesgo

Identificación, valoración, relevancia, prevención, mitigación, control y respuesta a posibles riesgos que se generen en un proyecto de Sig.

Plan y tratamiento de Riesgos

Arquitectura y diseño

Transformar los requerimientos y requisitos significativos en una arquitectura que describa su estructura e identifique los componentes del Sig.

Diagramas de Clases,Diagrama de componentes Diagramas de Secuencia

Diagramas de Colaboración Arquitectura de Datos.Bloc de Notas de la Arquitectura

Desarrollo

Implementar una solución técnica que cumpla con la arquitectura definida y soporte los requerimientos de los grupos interesados.

Código Fuente

Gestión de Pruebas

Diseñar, implementar, ejecutar y evaluar pruebas en cada uno de los componentes desarrollados.

Casos de PruebaResultados casos de

prueba

Gestión de Cambios

Registrar,revisar y llevar a cabo solicitudes de cambios generadas en un proceso de desarrollo de software.

Control de Cambios

Implantación

Planificar y llevar a cabo la producción de una solución de software mediante el alineamiento de las necesidades de capacitación de los usuarios y el desarrollo de pruebas de funcionamiento.

Plan de despliegue socialización, capacitación o acompañamiento

Tabla 3. Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

16

5.1.2.3. Roles openup/oas

Los productos de Sig los crean personas con diferentes intereses y competencias. Un ambiente de grupo saludable potencia la colaboración efectiva requiriendo una cultura compartida que fomente la creatividad y el cambio positivo.

Los roles son el rostro humano del proceso de desarrollo del Sig. Dependiendo del número de personas que conforman el equipo de trabajo y las condiciones del proyecto una persona puede asumir uno o varios roles, Figura 3.

Figura 3: Estructura del equipo de desarrollo OpenUP/OAS.

Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

Teniendo en cuenta los diferentes roles presentes en el proyecto a ejecutar, bajo el método de desarrollo OPENUP/OAS , en la Tabla 4 se especifica las funciones principales para cada uno de ellos.

17

Rol Función Principal

Director del Proyecto Este rol garantiza la continuidad del proyecto al gestionar los recursos necesarios y mantener el interés institucional en el proyecto.

Jefe de Proyecto Este rol se encarga de la supervisión y dirección directa de las actividades y resultados de cada uno de los miembros del equipo de desarrollo.

Líder del Proyecto Lidera la planeación del proyecto, coordina interacciones con los interesados y conserva el equipo del proyecto enfocado en alcanzar los objetivos del proyecto

Analista Realizar tareas de relevamiento, análisis y diseño de los requerimientos y requisitos en el proyecto.

Arquitecto

Responsable de diseñar la arquitectura del Sig, la cual incluye tomar las principales decisiones técnicas que condicionan globalmente el diseño y la implementación del proyecto.

Realizador o desarrollador Es responsable de desarrollar una parte del sistema, incluyendo diseñar esta, para que se ajuste a la arquitectura

Inspector de Pruebas Identificar, definir, implementar y dirigir las pruebas necesarias, así como verificar y analizar sus resultados.

Tabla 4. Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

5.1.2.4. Artefactos del Proceso OpenUp/OAS

Bajo el proceso de desarrollo OpenUp/OAS se proponen como realizables los artefactos a describir en la Tabla 5, como se puede evidenciar:

18

Nombre

Descripción

Plan General del Proyecto

Este artefacto define los parámetros para realizar el direccionamiento y seguimiento al proyecto. Especifica los objetivos de alto nivel de las iteraciones y sus correspondientes hitos.

Plan de Iteración Comunica los objetivos, la asignación de tareas y los criterios de evaluación para una iteración dada.

Unidades de Trabajo Diarias

Contiene una lista de los trabajos programados diariamente y que responden a los objetivos definidos en la Iteración y en el proyecto

Cierre de iteración Este documento registra los resultados de una iteración

Visión Contiene los lineamientos de los requerimientos nucleares visionados del sistema, especificado las necesidades y características claves de los Interesados.

Requisitos de soporte Captura requisitos en el ámbito del sistema que no hayan sido capturados en escenarios o casos de uso, incluye requisitos sobre atributos de calidad y de desempeño global.

Especificación de Casos de Uso

Captura la secuencia de acciones que un sistema realiza y que genera un resultado observable que es de valor para aquellos que interactúan con el sistema.

Glosario Este artefacto define términos importantes usados en el proyecto

Listado de requerimientos y requisitos

En este documento se registran los requerimientos y requisitos que surjan a lo largo del proyecto, y sirve para priorizar y organizar las tareas, objetivos y metas del mismo.

Acta de Trabajo Registra los acuerdos o compromisos definidos entre los interesados y el equipo de desarrollo

Plan de Riesgos Contiene la identificación, valoración, relevancia, prevención, mitigación, control y respuesta a posibles riesgos que se generen en un proyecto de software.

Bloc de notas de la Arquitectura

Contiene las decisiones, razonamientos, asunciones, explicaciones e implicaciones sobre la arquitectura en formación.

Documento de Diseño

Artefacto documenta las especificaciones técnicas en cuanto al diseño del software y se complementa con diagramas de clases, diagramas de colaboración, diagramas de secuencia entre otros.

Control de Cambios Este artefacto es utilizado para documentar las solicitudes de cambio de los diferentes subprocesos que surgen al interior del proyecto por parte de los interesados o miembros del equipo del proyecto.

Caso de prueba Son la especificación de un conjunto de pruebas de entradas, condiciones de ejecución y resultados esperados, los cuales son identificados para el propósito de realizar una evaluación de una aspecto particular en un escenario específico.

19

Registro de Pruebas Este artefacto recolecta los resultados de la ejecución de una o más pruebas en un ciclo completo de pruebas.

Tabla 5. Fuente: Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

5.1.3. Proceso de Desarrollo

5.1.3.1. Ficha de Caracterización de Subproceso

En la Figura 4. Se presenta la respectiva ficha de caracterización de subproceso, referente al desarrollo de la solución:

Fuente : Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

Se evidencia de igual manera en la Figura 5, el subproceso desarrollo de la solución respectiva a continuación:

20

Fuente : Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.

5.1.3.2. Guías

5.1.3.2.1. Integración Continua

La integración continua introduce la práctica de integrar continuamente los conjuntos de cambios para reducir el esfuerzo requerido para mezclar desarrollos en paralelo y para encontrar fallos de forma temprana. Con este concepto se conduce el trabajo colaborativo. La integración continua es una práctica de puesta en funcionamiento donde los integrantes del equipo integran su trabajo con los trabajos de otros realizadores de software y lo prueban de forma local antes de hacer su trabajo disponible. Esto habilita la detección de errores de integración al determinar errores de compilación, notificaciones del sistema o fallos reportados por las herramientas de pruebas. Idealmente la integración se realiza de forma automática antes de elevar los cambios al siguiente nivel de operaciónLa integración continua provee los siguientes beneficios:

1. Mejora la retroalimentación. La integración continua muestra un progreso constante y demostrable.

21

2. Mejora la detección de errores. La integración continua permite que los errores se detecten de forma temprana muchas veces a los pocos minutos después de que se han inyectado dentro del producto. Para aumentar la efectividad de la integración se recomienda el uso de herramientas para la realización de pruebas.

3. Mejora la colaboración. La integración continua facilita que los integrantes del equipo trabajen colaborativamente de forma segura. Fomenta la realización de cambios, la integración local y la detección temprana de conflictos en el código.

4. Mejora la integración del sistema. Cada uno de los realizadores se cerciora que el sistema puede ser integrado mitigando la posibilidad de error asociada a esta actividad.

5. Reduce el número de cambios – a partir de trabajos paralelos – que necesitan ser mezclados y verificados.

6. Reduce el número de errores encontrados durante las pruebas al sistema ya que todos los conflictos son resueltos antes de hacer disponible el conjunto de cambios.

7. Reduce los riesgos técnicos. Siempre se podrá contar con un sistema actualizado frente al cual realizar las pruebas.

8. Reduce la administración del riesgo. La integración continua permite conocer claramente cual es la nueva funcionalidad que se está agregando al sistema limitando el impacto de nuevos cambios.

5.1.3.2.2. Reconstrucción

Este concepto explica los mecanismos para mejorar el diseño de código existente de tal forma que no se afecte -si no es necesario su comportamiento externo.La reconstrucción es una vía disciplinada para reestructurar el código cuando pequeños cambios se han realizado para mejorar el diseño. Un aspecto importante es que se mejora el diseño pero sin cambiar el comportamiento. Una reconstrucción no adiciona ni remueve funcionalidad.La reconstrucción fomenta la evolución del código a través del tiempo con un enfoque iterativo e incremental hacia la puesta en funcionamiento.Estos son los tipos de reconstrucción:

1. Reconstrucción de código. Consiste en la reconstrucción del código fuente fruto de la programación. Algunos ejemplos pueden incluir el renombrado de métodos, la encapsulación de campos, la extracción de clases, la introducción de comentarios y la reestructuración de métodos.

2. Reconstrucción de bases de datos. Son cambios a los esquemas de la base de datos que mejoran el desempeño mientras que mantienen la semántica en la información y el desempeño. Ejemplos incluyen renombrar columnas, dividir una tabla, mover algún método , reestructurar procedimientos almacenados, reemplazar LOB con Table, agregar restricciones a las columnas y utilizar fuentes de datos oficiales.

22

3. Reconstrucción de Interfaz de Usuario (IU). La reconstrucción de IU consiste en realizar cambios simples en la interfaz gráfica mientras se mantiene su semántica. Ejemplos incluyen la reacomodación de campos en los formularios, aplicar estilos, etc.

5.1.3.2.3. Transformar el diseño en Puesta en Funcionamiento

Transformar el diseño en código que implemente la estructura del sistema utilizando el lenguaje de programación seleccionado. También hace referencia a implementar el comportamiento del sistema definido en los requerimientos funcionales. Implementar el comportamiento del sistema significa escribir el código fuente que permite que diferentes partes de la aplicación (clases o componentes) colaboren en la realización del comportamiento esperado del sistema. Así pues existen varias técnicas para que de forma automática se transforme el diseño en artefactos de puesta en funcionamiento

5.1.3.2.4. Elevar los Cambios al Siguiente Nivel de Operación

Durante el desarrollo iterativo de software los grupos de trabajo crean numerosos conjuntos de Cambio que son agrupados en una Construcción. Una construcción se inicia combinando el trabajo completado por uno o más realizadores y resolviendo los conflictos que pueden existir entre los diversos cambios. Idealmente, la construcción es después sometida a una completa batería de pruebas para poder determinar si tiene la calidad suficiente que le permita moverse al ambiente de producción.A medida que los cambios progresan desde el desarrollo a la producción es benéfico conocer en la presente construcción:Ámbito de pruebas– identificar los elementos y las versiones que deben ser verificadas.

● Qué cambios se tienen (unidades de trabajo completas)● Qué cambios se han implementado parcialmente (unidades de trabajo que se

han implementado parcialmente)● Que cambios no se tienen (unidades de trabajo que no se ven reflejadas)● Nivel de Verificación – identificar la cantidad de pruebas que se han

completado.● Unidades probadas● Integración probada● Sistema probado

5.1.3.2.5. Reutilización de Software

Maximizar la reutilización de software es una meta importante dentro del desarrollo de software. Es mejor reutilizar código y diseño existente que gastar tiempo, y recursos creando, probando y lanzando nuevo código; con los riesgos asociados que tienen todo nuevo software. Los lenguajes de programación, especialmente aquellos orientados a objetos, han sido diseñados para facilitar la reutilización. Pero

23

ha de tenerse en cuenta que el lenguaje por si solo no es suficiente para lograr una reutilización costo efectiva. La mayoría del software reutilizable proviene de expertos realizadores de software y arquitectos quienes han sido capaces de identificar y apalancar las oportunidades de reutilización. Para dicha reutilización es pertinente tener en cuenta las siguientes recomendaciones :

● Identificar Oportunidades de Reutilización● Técnicas de Reutilización● Herencia y Agregación● Encontrar Código Reutilizable● Evitar Reutilizar Todo

5.1.3.2.6. Estándares para la Escritura de Código

Son estándares que describen varias convenciones acerca de como escribir el código fuente. Su principal tarea es asegurar la consistencia, calidad y una puesta en funcionamiento fácil de entender.

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 como é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 estará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.

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

5.1.3.2.7. Puesta en Funcionamiento

La puesta en funcionamiento es una versión funcional del sistema o una parte del sistema que implementa un subconjunto de las capacidades que proveerá el producto final.Entregar productos, incrementando cada vez la funcionalidad, con valor para los usuarios y los clientes. Proveer un artefacto que pueda ser probado.Las versiones del sistema son el resultado de poner en funcionamiento el sistema a través de un proceso de construcción (usualmente automatizado por medio de un

24

script de construcción) que crea una versión ejecutable del sistema o una versión que pueda ser ejecutada. Esta versión ejecutable tendrá un conjunto de archivos de soporte que son considerados como parte del artefacto.Son los Archivos de código, archivos de datos y archivos de soporte - tales como ayuda en línea - que representan partes específicas del sistema que pueden ser construidas que representan las partes “físicas” que hacen que el sistema sea construido y organizado en una forma que sea fácil de entender y administrar.Este artefacto es una combinación de uno o más de estos elementos:

● Archivos de código fuente● Archivos de datos● Scripts de construcción● Otros archivos que son creados como ejecutables dentro del sistema.

5.2 Sistema de información geográfica

Se define un sistema de información geográfica como “sistema de información diseñado para trabajar con datos referenciados mediante coordenadas espaciales o geográficas. En otras palabras, un SIG es tanto un sistema de base de datos con capacidades específicas para datos georreferenciados, como un conjunto de operaciones para trabajar con esos datos. En cierto modo, un SIG es un mapa de orden superior”5, al nombrarse “un mapa de orden superior”, se puede entender que un SIG es un elemento que nos ayuda a realizar tareas de forma mas eficiente, como calcular el área de varios elementos, distancias o interceptar capas; con ayuda de una computadora, lo cual se hacia de forma análoga con mapas y tomaba un mayor tiempo.

“Debe entenderse, pues, un SIG, como un elemento complejo que engloba una serie de otros elementos conectados, cada uno de los cuales desempeña una función particular… los datos, los procesos, la visualización, la tecnología y el factor organizativo.” 6

5.3 NetLogo

Netlogo es un entorno de programación que permite la simulación de fenómenos naturales y sociales. Fue creado por Uri Wilensky en 1999 y está en continuo desarrollo por el Center for Connected Learning and Computer-Based Modeling.

Netlogo es particularmente útil para modelar sistemas complejos que evolucionan en el tiempo. Los implementadores de modelos pueden dar instrucciones a cientos o miles de agentes para que todos ellos operen de manera independiente, entre sí y con el entorno. Esto hace posible explorar la relación entre el comportamiento a bajo

5 J. Star and J. Estes. Geographic Information Systems: An Introduction. Prentice-Hall, 1990.6 Víctor Olaya. Sistemas de Información Geográfica, 2014.

25

nivel de los individuos y los patrones macroscópicos que surgen a partir de la interacción de muchos individuos entre sí.7

Netlogo es un lenguaje de programación que sigue la filosofía del modelado basado en agentes, en Netlogo existen 3 tipos de agentes:

• Turtles (tortugas).

• Patches (celdas).

• Links (relaciones entre tortugas).

• Observer (observador).

Las tortugas son los agentes que se mueven por el mundo. Interaccionan entre sí y con el medio. Cada tortuga viene identificada por un identificador que es único para cada tortuga.

Netlogo denomina “mundo” (world) al terreno en el que se mueven las tortugas. Cada porción cuadrada de mundo se denomina patch. Cada patch está identificado por las coordenadas de su punto central.

Las tortugas se mueven por el mundo (y, por tanto, por encima de los patches). Las tortugas interaccionan entre sí según unas reglas de comportamiento y con el medio (es decir, con los patches).

Se pueden modelar la relación entre distintas tortugas mediante links, que es el tercer tipo de agente presente en Netlogo. Los links se designan mediante un par (tortuga1, tortuga2), que indica las dos tortugas relacionadas mediante dicho link.

Finalmente, la última figura presente en los modelos de Netlogo es el observador. Éste no está representado en el mundo, pero puede interactuar con él (crea y destruye agentes, asigna propiedades a los agentes, etc).

7 The NetLogo 6,0 User Manual.

26

CAPÍTULO 6. DESCRIPCIÓN DE LOS RESULTADOS

Se desarrollo una simulación en Netlogo, en la cual se crearon 8 escenarios para evaluar los tiempos de evacuación del edificio, tomando situaciones que se encuentran actualmente en la facultad y comparando este con escenarios óptimos, organizados según la Tabla 6, donde el color azul representa los obstáculos que se van agregando a cada uno de los modelos a evaluar.

Escenario

Variables

Sede con escaleras bloqueadas

Salida principal solo auxiliar

Puertas administrativo abiertas

Escaleras ubicadas en los baños deshabilitada

1

2

3

4

5

6

7

8

Tabla 6. Escenarios con variables creados para correr la simulación en Netlogo.

Para cada uno de los escenarios se corrió el modelo 5 veces aumentando el numero de estudiantes por salón de 25 – 50 respectivamente (Ver Anexo 1) y tomando el tiempo de evacuación del total de los estudiantes en minutos, luego se procedió a la depuración de estos los datos ya que se generaron datos atípicos debido a que en el algoritmo algunas de las tortugas se creaba dentro de una pared y aumentaba el tiempo de evacuación, se eliminaron de acuerdo a los datos del promedio, luego se procedió a graficar cada uno de los promedios como se puede observa en la Figura9, con colores que van desde verde, el cual representa el menor riesgo evacuando el edificio en el menor tiempo, pasando por el amarillo, donde se pueden encontrar los escenarios mas probables, llegando hasta el rojo el cual representa el peor escenario.

27

CAPÍTULO 7. ANÁLISIS DE RESULTADOS

7.1 Descripción del sistema de información geográfica Sabio Caldas y Administrativo

Para realizar el sistema de información geográfica, se utilizaron dos herramientas por separado, para la cartográfica, se implemento Qgis y para la simulación de movimiento de las personas se utilizo NetLogo.

7.1.1 Cartografiá

Se implemento la cartografiá realizada por la oficina de planeación de la universidad, la cual se encontraba en formato DWG, privativo de AutoCad, al encontrarse en este formato solo se pudo pasar la información georeferenciada la cual contenía un error, los datos tenían un origen Magna Sirgas, Colombia Bogotá zona, con centro en 1000000, 1000000, pero las coordenadas venían con un cero faltante en su origen, con centro en 100000, 100000, por lo que se tubo que generar un sistema de referencia con este centro para que correspondiera con las imágenes satelitales de Google Eart. A partir de la información corregida geográficamente se pasaron las anotaciones del DWG como formato punto para interceptar con los polígonos y adicionar a los atributos, los nombres correspondientes a cada uno de los polígonos, y el tipo de espacio que esta representando cada polígono, por ejemplo, polígonos con atributo de salón, hall, escaleras, ascensores, etc. Con esto se complemento la cartografiá y los atributos necesarios para realizar la simbología (Figura 6), Con lo que se completo la cartografiá, lo que no dio la Figura 7

28

7.1.2 Modelo en NetLogo

Para generar el modelo se plantearon un conjunto de reglas, las cuales debe seguir cada agente autónomo, según la posición geográfica en que se encuentre en el mapa, y los objetos que lo rodean, las reglas básicas que se programaron para los agentes son:

• No puede pasar por un espacio con color negro (paredes), o con piel (bloqueos).

• No puede ocupar el mismo espacio que otro agente.

• Buscar la salida mas cercana, ya sea una puerta o una escalera.

Luego de tener las reglas programadas se diseñaron un conjunto de botones y monitores (Figura 8), a los cuales se les asocio una función respectivamente, para controlar las variables de modelo y poder hacer el análisis espacial, así completando el SIG, los botones cumplen las siguientes funciones:

• Estudiantes Salón: Slide, para marcar el numero de agentes por salón a crear.

• Setup: inicializa las variables del programa.

• Go: Inicia la función go.

• Tiempo: Monitor que va marcando el tiempo que le toma al programa, resolver el algoritmo.

• Ingresar Cartografiá: Carga las diferentes cartografiás generadas para el programa.

29

• MouseX y MouseY: Monitores que muestran la posición sobre el espacio de trabajo.

• Print-Xycoor-Mouse: Inicializa la función Print-Xycoor-Mouse.

• Acomodar estudiantes: Inicializa la función Acomodar estudiantes

• Conunt Estudiantes: Monitor que muestra la cantidad de estudiantes que están en el edificio y no han evacuado.

• Salida Principal: esta se encarga de seleccionar una de las dos variables para crear escenarios a simular, según la salida que queda ubicada sobre la Cr 8va, las opciones son:

◦ Abierta totalmente: Cuando se baja la puerta de emergencia de la universidad.

◦ Solo puerta principal: Cuando solo esta habilitada la puerta de salida pequeña.

• Escalera Administrativa: Esta selecciona el escenario para las escaleras que conectan a el edificio Sabio Caldas con el Administrativo, con las siguientes opciones:

◦ Solo 3 y 6 piso: unicamente el acceso actual al edificio administrativo por estos dos niveles.

◦ Habilitada: en caso que se pudieran mantener todas las puertas que conectan los dos edificios, abiertas.

• Escenario de escaleras: esta variable comprende las escaleras correspondientes a la parte del sabio caldas donde se encuentran ubicados los baños entre pisos, ya que en caso de un siniestro, si estas quedan sin luz, no podrían ser utilizadas, tienen las siguientes dos opciones:

◦ Solo escalera principal: en dado caso que no se pueda utilizar las

escaleras de los baños.◦ Todas las escaleras: Si tanto la escalera de caracol que da hacia la 8va, y

las escaleras de los baños están habilitadas.

Luego se procedió a crear un conjunto de razas de agentes que representan un objeto espacial sobre el espacio, cada uno de estos fue referenciado según el sistema de coordenadas que utiliza el programa, las razas que se utilizaron para resolver el problema son:

• Salidas

• Estudiantes

• Escaleras

• Pisos

30

Los procedimientos que se utilizaron para representar cada una de las reglas ya mencionadas, y configurar el movimiento de los agentes son:

• Acomodar Estudiantes: Esta función se encarga de desplazar a los estudiantes, si estos fueron creados sobre una pared, o sobre otro estudiante, ya que la salida de los estudiantes se genera de forma aleatoria en cada uno de los salones.

• Coordenada: Esta función se encarga de darle una coordenada aleatoria a los estudiantes según un punto central ubicado en cada salón u oficina.

• Distancia Cercana: Esta función se encarga de buscar la salida mas cercana a cada uno de los agentes, según su posición.

• Go: Esta función arranca todo el programa y lo mantiene funcionando hasta que se resuelve el problema.

• Move estudiante: Función que se encarga del movimiento de los agentes, donde se incluyeron las reglas que estos siguen.

• Move turtles: esta regla se encarga de ir desplazando a los agentes de piso a piso, cada ves que uno de ellos llega a una escalera y cumple con el ciclo respectivo de desplazamiento por ella.

• Print-Xycoor-Mouse: Función que va mostrando la coordenada x, y, en el espacio de trabajo, por la cual se va desplazando el cursor.

• Quitar Paredes: Función que se encarga de que en el movimiento de los agentes, estos eviten atravesar las paredes.

• Setup: inicializa las variables como, numero de salidas, y estudiantes por salón.

• Setup-turtles: Genera las coordenadas de los centros de los salones, donde van a nacer los estudiantes.

• Setup2: Esta función se creo para re acomodar a los agentes cada vez que se termina una iteración, sin tener que re acomodar las variables iniciales y con esto hacer que el algoritmo se resuelva en menor tiempo por iteración.

• Stop-estudiante: Función que detiene a un estudiante cuando otro estudiante se encuentra en frente, evitando que este ocupe el mismo espacio.

Adicional mente, se genero una función que realiza 5 iteraciones, aumenta el numero de estudiantes en una unidad, y vuelve a realizar las 5 iteraciones, con cada iteración imprime el tiempo que tomo evacuar la sede, así sucesivamente hasta llegar a 50 estudiantes por salón, simulando una saturación extrema del edificio; esta función tiene el objetivo de solucionar varias veces el problema para generar estadísticas y con ello ver resultados de manera mas clara.

31

7.2 Producto

El producto final de la presente pasantía, es un sistema de información geográfica, desarrollado en Netlogo, el cual evaluá 8 escenarios distintos donde se pueden seleccionar distintas variables como:

32

Figura 8: Variables de control para el modelo de movimiento.

• Numero de estudiantes.

• Bloqueo de las escaleras.

• La salida principal por la 8 va total mente abierta o solo abierta la salida auxiliar.

• Las entradas al edificio administrativo abiertas o solo habilitadas las de los pisos 3 y 6.

• Las escaleras del edificio Sabio Caldas habilitadas, tanto las principales como las que están ubicadas en los baños, o bien solo habilitadas las principales.

En la Figura 9, podemos observar una gran diferencia en términos de tiempo con respecto a la evacuación, entre los escenarios 1, que es un escenario optimo, donde todas las entradas de la conexión entre el edificio sabio caldas y el administrativo están habilitadas, así como todas las escaleras para salir del edificio y la salida principal por la calle 8 va se encuentra abierta totalmente, entre estos dos escenario se puede observar una diferencia en el tiempo de evacuación de 9,47 minutos, si tomamos en cuenta que el tiempo de evacuación del escenario optimo es de 6,64 minutos, según la simulación, se ve que el aumento del tiempo es casi el doble (1,42 veces).

Al analizar cada uno de los escenarios se encontró que la sede en el momento del presente estudio se encuentra entre el escenario No 3, donde las escaleras ubicadas en los baños del edificio no se encuentran habilitadas por no cumplir las normas mínimas de seguridad (Luz natural) y el escenario No 8, el cual se presenta cuando los estudiantes a modo de protesta bloquean las escaleras principales y la salida impidiendo un correcto flujo de personas a las salidas y la imposibilidad de abrir la salida de emergencia ubicada en la carrera 8va.

33

Figura 9. Gráfica de cada uno de los escenarios propuestos en el modelo

25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 500

2

4

6

8

10

12

14

16

18

Tiempo Promedio de Evacuación vs Numero de estudiantes

Escenario 1

Escenario 2

Escenario 3

Escenario 4

Escenario 5

Escenario 6

Escenario 7

Escenario 8

Numero de Estudiantespor salón

Tie

mp

o d

e e

vacu

aci

ón

(m

in)

CAPÍTULO 8. EVALUACIÓN Y CUMPLIMIENTO DE LOS OBJETIVOS

Para la evaluación de cada uno de los objetivos, se realizo un análisis de acuerdo a las actividades realizadas.

1. Revisar la información cartográfica correspondiente a los planos arquitectónicos de la facultad de Ingeniería y su sede administrativa.

Para este objetivo se realizo una petición por medio de la OAS (Oficina asesora de sistemas), a la oficina de planeación de la universidad, para obtener los planos del edificio, los cuales fueron entregados en formato DWG (Auto CAD) para ser previamente procesados.

2. Georeferenciar la información cartográfica de la Facultad de Ingeniería, incluyendo la sede Administrativa.

Luego de obtener la información cartográfica se procedió a transformar los archivos a formato SHP, para poderlos utilizar en Qgis y poder generar la cartografiá para NetLogo, para este punto se utilizo AutoCAD, ya que no existe software libre que abra este tipo de archivos, se dejaron georeferenciados según se trasformaron de AutoCAD, ya que estos no tenían la rotación ni coordenadas en un sistema que se pudiese utilizar en Qgis.

2. Transformar los datos para que tengan compatibilidad con Qgis8 y NetLogo9 en cuanto a la representación gráfica y espacial.

Al tener los archivos en SHP, para ser utilizados en Qgis, se procedió a organizar la información espacial para darle simbología a cada elemento, ya que los agentes autónomos en NetLogo, reaccionan a los colores por los cuales se van movilizando (ver Figura 10).

3. Plantear rutas de evacuación preliminares y realizar la señalización pertinente según las normas de evacuación.

Este objetivo no se cumplió ya que la cartografiá que proporciono la oficina asesora de sistemas tenia varias inconsistencias en los espacios físicos ademas de algunas capas que no se podían cargar bien desde el backup de postgis.

8 QGIS,(2016). Acerca de QGIS. Retrieved from http://qgis.org/es/site/about/index.html9 Laboratorio de apredizaje de NetLogo, (2016) Retrieved 17 May 2016, from http://online.sfsu.edu/jjohnson/NetlogoTranslation/laboratorio_0102.html

35

4. Evaluar las rutas de evacuación utilizando agentes autónomos con ayuda de NetLogo para medir tiempos de desplazamiento entre un punto de reunión y un punto de encuentro.

Se realizo una evaluación de las posibles rutas de evacuación de acuerdo a cada uno de los escenarios planteados tomando en tiempo de evacuación hasta las salidas principales, no se realizo en calculo hasta los puntos de reunión ya que estos no se han podido establecer con claridad según las normas existentes (Ver Anexo 2).

5. Implementar a la cartografía las rutas de evacuación finales y visualizarlas en el sistema de Información geográfica.

Este objetivo no se cumplió por los inconvenientes en el objetivo No 3, ademas las rutas que según los resultados de los modelos llegan a ser optimas no se pueden implementar actual mente debido a que las puertas ubicadas entre la sede administrativa y la sede de ingeniería no se encuentran habilitadas, las actuales rutas de evacuación contemplan este inconveniente (Ver Anexo 2).

36

Figura 10. Cartografiá Generada en Qgis para ser cargada a NetLogo

CAPÍTULO 9. CONCLUSIONES Y RECOMENDACIONES

9.1 Conclusiones

A partir de los resultados obtenidos por los modelos, se puede observar que el mejor flujo para la evacuación del edificio se obtiene habilitando todas las escaleras incluyendo las puertas que conectan los edificios administrativo y Sabio Caldas, ya que con esto se muestran resultados óptimos en términos de tiempo de salida, sin embargo se encontró que el edificio no cumple con las normas establecidas según la norma vigente.

9.2 Recomendaciones

1. Se recomienda abrir las puertas que conectan el edificio sabio caldas y la sede administrativa para ser utilizada por algunos salones y mejorar el tiempo de evacuación.

2. Se debería plantear las rutas de evacuación de acuerdo al mejor escenario planteado según el modelo, y con esto poner la señalización adecuada, ya que el edificio no cuenta con esta o es mínima.

3. Es recomendable realizar jornadas de concientización entre las personas que se encuentran frecuentemente en el edificio para socializar estas rutas de evacuación, ya que la mayoría de la comunidad académica ignora los procedimientos a seguir en cada una de las situaciones que pueden llegar a presentarse.

4. Se debería coordinar entre la oficina de planeación y la OAS, la actualización de los datos geográficos en el SIG de la universidad, para implementar estas rutas de evacuación y socializarlas de forma eficiente.

37

CAPÍTULO 10. BIBLIOGRAFÍA

● Calderón Bahamon, Inocencio.(2011), Por medio de la cual se adopta el método del proceso de desarrollo openup/oas como marco de trabajo institucional en el análisis, diseño, desarrollo e implantación de productos de software al interior de la Universidad Distrital Francisco José de Caldas. SISGRAL, Rectoría Resolución N° 461.

● Oficina Asesora de Sistemas. (2011) ,Guía rápida proceso de desarrollo OpenUP/OAS, Universidad Distrital Francisco José de Caldas, Colombia.

● Oficina Asesora de Sistemas. Proceso de desarrollo OPENUP/OAS. Generalidades del Proceso de desarrollo. Universidad Distrital Francisco José de Caldas. Colombia.

● Oficina Asesora de Sistemas, “OAS. Proceso de Desarrollo OPENUP/OAS, Capítulo 9: Proceso de desarrollo OPENUP/OAS, Universidad Distrital Francisco José de Caldas, Colombia.

● Universidad Distrital Francisco José de caldas (2003), acuerdo 003, Colombia.

● Oficina asesora de sistemas.(2016), Sistema de Información Geográfica (SIRENE). Planteamiento de Rutas de Evacuación facultad de Ingeniería

● Norma técnica colombiana ntc 1700: higiene y seguridad. Medios de seguridad en edificaciones, medios de evacuación.

● Ley 1523 : "por el cual se adopta la política nacional de gestión del riesgo de desastres y se establece el sistema nacional de gestión del riesgo de desastres y se dictan otras disposiciones".

● Víctor Olaya. Sistemas de Información Geográfica, 2014.● J. Star and J. Estes. Geographic Information Systems: An Introduction.

Prentice-Hall, 1990.

38

ANEXOS

1. Tablas con los resultados 2. Programa desarrollado en la pasantía.

39